2.4.0 pdev_enable_device() call in setup-bus.c
Hi Ivan, Can you explain why pci_assign_unassigned_resources() calls pdev_enable_device() for every PCI device instead of having each PCI *driver* call pci_enable_device() as part of driver initialization? I'm thinking I missed something that a comment in the code should have explained. After having written the bulk of PCI support for parisc port, I was clearly under the impression the PCI driver was supposed to call pci_enable_device(). IMHO, it's a *bad* idea to enable a device when it's driver might not be present. thanks, grant Code from drivers/pci/setup-bus.c: void __init pci_assign_unassigned_resources(void) { ... pci_for_each_dev(dev) { pdev_enable_device(dev); } } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 pdev_enable_device() call in setup-bus.c
On Wed, Feb 07, 2001 at 11:50:52AM -0800, Grant Grundler wrote: > Can you explain why pci_assign_unassigned_resources() > calls pdev_enable_device() for every PCI device instead > of having each PCI *driver* call pci_enable_device() > as part of driver initialization? Mainly because there are driverless devices like display adapters, PCI bridges, or PCI devices with legacy drivers (IDE, for example). OTOH, pdev_enable_device() most likely will be removed, but it's 2.5 material. Ivan. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 pdev_enable_device() call in setup-bus.c
Ivan Kokshaysky wrote: > Mainly because there are driverless devices like display adapters, > PCI bridges, or PCI devices with legacy drivers (IDE, for example). Ok. It seems that all of those would have to interact with the PCI code someplace. And that's were pci_enable_device() could be called. eg. PCI Bridges could be handled in it's "driver": pci_setup_bridge(). > OTOH, pdev_enable_device() most likely will be removed, but > it's 2.5 material. Agreed - standardizing the enable path would be good for above devices. I'd like to see arch hooks added for stuff like default latency and PCI_BRIDGE_CONTROL. My gut feeling is the "root" struct pci_bus allocation and initialization should be done by arch specific code *before* pci_scan_bus() is called. That would allow cfg space defaults to be set to arch specific values on a per bus basis *before* doing the bus walks instead of hacking this in pci_bus_fixup() later. thanks, grant Grant Grundler parisc-linux {PCI|IOMMU|SMP} hacker +1.408.447.7253 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/