On Fri, 15 Sep 2000, Linus Torvalds wrote:
> On Fri, 15 Sep 2000, Richard B. Johnson wrote:
> > The PCI Specification states, in part, that either the BIOS or the
> > driver has to enable the device. So, many drivers find that the device
> > has not been enabled. This is normal and necessary because many/most
> > PCI hardware had better not be enabled until an ISR is in-place.
> But that's why we have the "pci_enable_device()" function. And that's why
> we have the generic PCI setup functionality that finds and enables devices
> at the right addresses.
> DO NOT USE ANY LOCAL HACKS. Use the proper function. Don't go mucking
> around with random configuration state information: enabling a device
> involves a lot more than just writing stuff to configuration ports. Things
> like making sure the interrupt routing on the motherboard has been
> enabled, etc. Things that the driver does not know about, and should not
> even _try_ to understand.
> The PCI layer should be used to handle generic PCI issues. A low-level
> driver should _never_ try to handle resource allocation and enabling in
Disagreed about `enabling'.
> 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.
> 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).
> To make a long story short: a driver that touches the PCI_COMMAND or other
> generic PCI registers by hand is a _buggy_ driver. It's a sure recipe for
I disagree 100% with this statement. The genericity of PCI configuration
is only here to facilitate configuration of all the devices on a BUS
hierarchy. Indeed a PCI device driver must not tamper the resources the
device got from the generic PCI layer. But it is expected to know better
about the PCI devices it supports that any generic PCI layer. Not
everything are generic in PCI. What about device bugs, for example? About
bridges, part of their configuration can be handled generically, but not
everything. The generic PCI layer that deals with bridges have to know
bridge quirks and special features as you know. In some way, the PCI
generic layer acts as PCI device drivers for the bridges. Configuring and
enabling are 2 different issues. Configuring has been designed to be
generic in PCI but the `enabling' should be performed by the entity that
knows the best about the real device, thus the PCI device driver.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
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