On Tue, Oct 2, 2012 at 3:47 PM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: > On Tue, Oct 2, 2012 at 1:45 PM, Greg Kroah-Hartman > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >> I don't know what you are doing in the acpi code, but I do not think it >> requires a driver core change like this. >> >> Again, why is PCI different from any other bus type? (hint, it >> shouldn't be...) > > it is not pci susbsystem problem. > > the problem come from device-driver core for hotplug handling, and > acpi system is > forcing pci system to split the scan and registering. > aka: to scan all pci device under one pci_root from acpi_pci_root_add. > then do pci_bus_add_devices for that bus in acpi_pci_root_start. I don't believe there's anything in ACPI that forces this split between scanning and registering. Certainly we have Linux *implementation* issues that currently lead us to split them, but I don't think those are forced by the hardware or the spec. I'd rather address those implementation issues than add band-aids. > on hotplug path: > when acpi enumerating acpi devices, it will create acpi_device for pci_root, > then probe driver for that device : acpi_pci_root_driver. > <at that time no acpi_device under that pci_root acpi device is created> > device_add for root acpi_device will call bus_probe_device and ... and execute > acpi_pci_root_driver .add aka acpi_pci_root_add. > acpi_pci_root_add will call pci_acpi_scan_root. that will scan pci > root bus to find all > pci devices but does not add those pci device into devices. > If at the time device_add for pci device get called, platform_notify > will try to bind pci_dev > with acpi devices, but corresponding acpi device is not created yet. > that bind will fail. > So acpi_driver introduce .start in ops to add pci device later. We enumerate ACPI devices by doing a depth-first traversal of the namespace. We should be able to bind a driver to a device as soon as we discover it. For PNP0A03/08 host bridges, that will be the pci_root.c driver. That driver's .add() method enumerates all the PCI devices behind the host bridge, which is another depth-first traversal, this time of the PCI hierarchy. Similarly, we ought to be able to bind drivers to the PCI devices as we discover them. But the PCI/ACPI binding is an issue here, because the ACPI enumeration hasn't descended below the host bridge yet, so we have the pci_dev structs but the acpi_device structs don't exist yet. I think this is part of the reason for the .add()/.start() split. But I don't think the split is the correct solution. I think we need to think about the binding in a different way. Maybe we don't bind at all and instead search the namespace every time we need the association. Or maybe we do the binding but base it on the acpi_handle (which exists before the ACPI subtree has been enumerated) rather than the acpi_device (which doesn't exist until we enumerate the subtree). It's not even clear to me that we should build acpi_device structs for things that already have pci_dev structs. I don't know what the right answer is, but I do think it's better to resolve it inside PCI and ACPI rather than playing games with driver binding times in the driver core. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
