On Thu, Oct 19, 2023 at 02:38:23PM +0200, Sebastian Andrzej Siewior wrote: > On 2023-10-18 11:20:46 [-0400], Alan Stern wrote: > > > > If you hadn't removed the card suddenly, the exception would not have > > occurred. So the logical conclusion isn't that we should get rid of the > > usb_hcd_irq(0, hcd) call -- the logical conclusion is that you shouldn't > > remove PCIe cards while the system is running. Not unless your computer > > uses the special hardware from Stratus Technologies. > > So the card was removed and the kernel complained that it can't access > the memory behind the PCI-bar? > > How odd… > > > > so I think we don't need to add usb_hcd_irq(0, hcd) on the logical path of unbinding pcie driver. > > > > What about cardbus or PCMCIA cards? Removing one of those cards > > suddenly, while the system is running, is a perfectly reasonable thing > > to do and it will not cause any hardware damage. So I think we should > > keep the usb_hcd_irq(0, hcd) call. > > Don't you invoke pci_driver::remove in such case to properly let the > physical device go? This can also be tested via unbind from sysfs. I don't know any more. The code in question was added in 2010 in order to handle a specially designed high-availability hot-swap-capable system, and it may not be relevant now. The original problem: When a particular PCI device was disabled (to simulate a failure), pci_driver::remove did not get called. Maybe they wanted to have it fail over to a backup device and appear to the kernel as though nothing had happened? It's hard to tell exactly what was going on thirteen years ago. So while this function call may not be needed any more, I prefer to keep it around if that's not too much trouble. Alan Stern
