Messages in this thread |  | | Date | Fri, 15 Sep 2000 10:57:19 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: New topic (PowerPC Linux PCI HELL) |
| |
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/
|  |