Re: USB: add check to detect host controller hardware removal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Oct 19, 2023 at 11:09:57AM -0400, Alan Stern wrote:
> 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.

Oops...  Correction: pci_driver::remove _did_ get called, and the code 
in question is part of the remove handler.

Perhaps putting it there was a mistake.  At the time, I probably thought 
the problem was a general one which might affect all the PCI USB 
controller drivers, but looking back now, it might have been better to 
put in the individual device driver.

Perhaps that what we should do.

Alan Stern

>  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
> 




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux