Re: [PATCH] Make hot unplugging of PCI buses work

[Scott Murray]

On Sun, 23 Feb 2003, Linus Torvalds wrote:

> 
> On Sun, 23 Feb 2003, Russell King wrote:
> > 
> > Linus - this patch is for discussion, NOT for applying unless you have
> > zero problems with it since it actively breaks existing hotplug PCI.
> 
> Well, I definitely want it, and you should add Alan to the cc list since 
> he apparently even _has_ one of these devices.
> 
> I don't have any objections to the patch, but I won't apply it until the 
> otehr PCI people have had a chance to weigh in on it.

Having beaten out something roughly similiar for the cPCI hotplug code, 
I have a couple of comments:
1) The description of pci_remove_bus_device says "informing the drivers 
   that the device has been removed", yet unless I'm missing some sysfs
   wrinkle, no call will be made to an attached driver's remove callback.
2) The recursive bus handling in pci_remove_bus_device should probably 
   call pci_proc_detach_bus and potentially should also update the parent 
   bridge's subordinate field.  The latter is something that I'm doing
   at the moment in the cPCI hotplug code, but have just recently decided
   needs further investigation, as my solution does not handle multiple
   remove and insert cycles with different boards (e.g. it's easy to end
   up with overlapping ranges behind different bridges).

> > Furthermore, I propose that pci_remove_device() shall disappear -
> > and this devices makes it so (thereby breaking existing hotplug
> > drivers.)
> 
> Can't you just fix up the current users to use "pci_remove_bus_device()". 
> The breakage seems a bit spiteful ;)

The current device removal code in all of the PCI hotplug drivers are 
based to varying degrees on sets of callbacks driven by the pci_visit_* 
family of functions, and will hence need varying amounts of rework to be 
able to just call pci_remove_bus_device instead.  My cPCI hotplug driver 
and the ACPI based driver are likely the easiest to change over, since 
they attempt none of the more sophisticated resource management tricks 
that the Compaq and IBM drivers do.

Scott

-- 
Scott Murray
SOMA Networks, Inc.
Toronto, Ontario
e-mail: [e-mail]