2.4.0 pdev_enable_device() call in setup-bus.c

2.4.0 pdev_enable_device() call in setup-bus.c

[Grant Grundler]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 pdev_enable_device() call in setup-bus.c

[Ivan Kokshaysky]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 pdev_enable_device() call in setup-bus.c

[Grant Grundler]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/