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
hardware.
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.
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).
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
disaster.
Linus
-
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