Messages in this thread |  | | Date | Wed, 6 Feb 2013 10:59:11 -0800 | Subject | Re: [PATCH v3 00/22] PCI: Iterate pci host bridge instead of pci root bus | From | Yinghai Lu <> |
| |
On Wed, Feb 6, 2013 at 9:54 AM, Bjorn Helgaas <bhelgaas@google.com> wrote: > I think you're missing the point. > > Search the tree for uses of "for_each_pci_dev()." Almost every > occurrence is a bug because that code doesn't work correctly for > hot-added devices. That code gets run for devices that are present at > boot, but not for devices hot-added later. > > You're proposing to add "for_each_pci_host_bridge()." That will have > the exact same problem as for_each_pci_dev() already does. Code that > uses it will work for host bridges present at boot, but not for > bridges hot-added later. > > Why would we want to add an interface when every use of that interface > will be a design bug? I think we should fix the existing users of > pci_root_buses by changing their designs so they will work correctly > with host bridge hotplug.
I'm a little confused about what you want.
In boot stage using for_each_pci_host_bridge or pci_root_buses is fine.
For those cases that it should support host-bridge by nature. there are two solutions: 1. use for_each_pci_host_bridge, and it is hotplug-safe. and make sgi_hotplug to use acpi_pci_driver interface. and acpi_pci_root_add() will call .add in the acpi_pci_driver.
2. make them all to be built-in, and those acpi_pci_driver should be registered much early before acpi_pci_root_add is called. then we don't need to call for_each_host_bridge for it.
So difference between them: 1. still keep the module support, and register acpi_pci_driver later. 2. built-in support only, and need to register acpi_pci_driver early.
Please let me which one you like.
Thanks
Yinghai
|  |