On Fri, 15 Sep 2000, Linus Torvalds wrote:
> On Fri, 15 Sep 2000, Gérard Roudier wrote:
> >
> > > Just as an example: imagine that the IO windows haven't been set up
> > > correctly. If the low-level driver just blindly enables IO cycles by
> > > writing to the PCI_COMMAND register, that device may come up in an invalid
> > > state, and mess up the whole system. The driver simply does not KNOW
> > > enough. It doesn't know where other devices are, and it _shouldn't_ know.
> >
> > How do you want this to happen ? Could you elaborate.
>
> It's really easy.
>
> Call "pci_enable_device()".
>
> What's so hard about that?
This function delegates too much as a whole to the PCI generic layer, IMO.
Imagine that for sanity I want to allocate all the device resources, but
only _enable_ part of device features (for example only memory
transactions). Imagine some special handling to be necessary due to some
chip bug.
> You don't seem to realize, but it's entirely possible to have a setup
> where some device CANNOT be allocated it's IO region. The BIOS may have
> left the device disabled on purpose, simply because there wasn't enough
> free space in the memory map to enable the device anywhere.
PCI specs said corresponding BAR must be set to ZERO, here.
> You can't just have the device driver enable such a device. It _has_ to
> ask the PCI layer to do it for it - because the PCI layer is the only one
> that can figure out that "Oh, damn, this machine has 3GB of memory, and 4
> video cards that want a 256MB aperture each, and we don't have any place
> to map this card any more".
I want to say the generic layer "What to do" in some more fine-grained way
than just a single verb, at least. I may accept to delegate it some "How
to do it".
> No ifs, why's or buts. A driver that just enables the IO windows is a
> buggy driver.
In PCI, you donnot enable windows, but you enable/disable devices to
generate and/or respond to transactions. OTOH, if you look at all the bits
in the COMMAND register, you will see that some other features are also to
be addressed by the enabling/disabling kernel interface.
> > > In contrast, the general PCI layer _does_ know. It keeps track of
> > > resources, makes sure that different cards do not have overlapping address
> > > ranges, knows about PCI bridges (a card behind a PCI bridge can only be
> > > enabled after the _bridge_ has been enabled and can only be mapped in the
> > > region that the bridge maps).
> >
> > Yes, it is expected to do its work (e.g. assigning ressources to all
> > agents on the BUS hierachy).
>
> Right.
>
> And sometimes it CANNOT.
>
> End of story.
>
> Linus
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:26 EST