Re: [PATCH v3 4/6] PCI/acpiphp: update ACPI hotplug slot information when PCI hotplug happens

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Sunday, January 13, 2013 11:13:28 PM Jiang Liu wrote:
> On 01/10/2013 04:23 AM, Rafael J. Wysocki wrote:
> > On Thursday, January 10, 2013 12:29:55 AM Jiang Liu wrote:
> >> On 01/09/2013 08:04 AM, Rafael J. Wysocki wrote:
> >>> On Wednesday, January 09, 2013 12:52:23 AM Jiang Liu wrote:
> >>>> Currently the acpiphp driver fails to update hotplug slot information under
> >>>> several conditions, such as:
> >>>> 1) The bridge device is removed through /sys/bus/pci/devices/.../remove
> >>>> 2) The bridge device is added/removed by PCI hotplug driver other than the
> >>>>    acpiphp driver itself. For example, if an IO expansion box with ACPI
> >>>>    hotplug slots available is hot-added by the pciehp driver, all ACPI
> >>>>    hotplug slots won't be discovered by the acpiphp driver.
> >>>>
> >>>> So hook the BUS_NOTIFY_ADD_DEVICE/BUS_NOTIFY_DEL_DEVICE events to
> >>>> update ACPI hotplug slot information when PCI hotplug event happens.
> >>>>
> >>>> Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
> >>>> Signed-off-by: Yijing Wang <wangyijing@huawei.com>
> >>>> ---
> >>>>  drivers/pci/hotplug/acpiphp_glue.c |   62 ++++++++++++++++++++++++++++++++++--
> >>>>  1 file changed, 60 insertions(+), 2 deletions(-)
> >>>>
> >> snip
> >>>> +static struct notifier_block acpi_pci_hp_notifier = {
> >>>> +	.notifier_call = &acpi_pci_hp_notify_fn,
> >>>> +};
> >>>> +
> >>>>  static struct acpi_pci_driver acpi_pci_hp_driver = {
> >>>>  	.add =		add_bridge,
> >>>>  	.remove =	remove_bridge,
> >>>> @@ -1448,6 +1503,8 @@ int __init acpiphp_glue_init(void)
> >>>>  	else
> >>>>  		acpi_pci_register_driver(&acpi_pci_hp_driver);
> >>>>  
> >>>> +	bus_register_notifier(&pci_bus_type, &acpi_pci_hp_notifier);
> >>>
> >>> Your previous patch adds a PCI bus notifier for a similar thing.  Why are
> >>> you adding another one here?
> >> Hi Rafael,
> >> 	The acpiphp driver could be built as a module, and this bus notifier
> >> is used to setup/tear down ACPI based PCI hotplug controllers under a PCI bridge.
> >> The previous patch is to add/remove PCI slots. The PCI slot and PCI hotplug
> >> controller are related but different objects, so we use two notifiers to support
> >> them all.
> > 
> > I would be much happier if those notifiers were not needed.  At least, I'm not
> > sure why they need to be invoked by the driver core during device registration.
> > 
> > In my opinion it would be much better if they were called only for the devices
> > that might need them instead of all PCI devices.
> > 
> Hi Rafael,
> 	The whole thing seems a little complex, and I will try my best to explain
> about it:)
> 	Essentially a PCI slot is associated with a PCI bus, and a PCI bus is 
> associated with a host bridge or P2P bridge. When hot-adding/hot-removing a PCI bus,
> we need to create/destroy PCI slots associated with it. So the pci_slot and acpiphp
> drivers need to be notified when hot-adding/hot-removing a PCI bus.
> 	But there's no common mechanism to get notified when PCI buses are being
> hot-added/hot-removed. So my first implementation has introduced a dedicated notifier
> chain for PCI bus addition/removal. Later with ongoing changes to the PCI core, 
> I found we could rely on the existing bus notification mechanism too, so that becomes
> the current implementation.
> 	I have a proposal to unify the process for boot time and hotplug as below:
> 1) Change pci_slot and acpiphp as built-in instead of modules.

Sure, go ahead with that.

> 2) Get rid of acpi_pci_driver for pci_slot and acpiphp driver.

Again, I have no objection here.  Moreover, I think we might be better off
without the acpi_pci_driver things at all.

> 3) Register some forms of callbacks to create/destroy hotplug controllers/slots
>    when creating/destroying PCI buses.
> 3.a) Rely on the bus notification mechanism to invoke callbacks. This solution is
>      simple, but with a little overhead
> 3.b) Introduce a dedicated notifier chain for PCI bus hot-adding/hot-removing.
>      This solution could get rid of the overhead, but with more code changes.
> 3.c) Invoke callbacks from acpi_bus_type->setup/cleanup. This solution could
>      only support ACPI based slots, such as pci_slot and acpiphp.

As I said before, I'd prefer these notifications to be done specifically for
PCI buses or bridges, so I'd vote for 3.b), depending on the implementation.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.