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

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

 



On Fri, Nov 03, 2023 at 04:46:24PM +0100, Sebastian Andrzej Siewior wrote:
> On 2023-10-20 11:19:49 [-0400], Alan Stern wrote:
> > Hmmm...  This turns out not to be as easy as one might think.
> > 
> > Sebastian, if you can instead suggest a way to call drivers' interrupt 
> > handlers (i.e., simulate an interrupt) without causing problems for RT 
> > kernels, I think that would be a better approach.
> 
> So there is generic_handle_irq_safe(). It should get all the details
> right like incrementing the counter in /proc/interrupts, doing nothing
> if the interrupt has been masked or waking the interrupt thread if the
> interrupt has happen to be threaded.
> It triggers the interrupt so for a shared handler it will invoke _all_
> registered interrupt handler and for threaded interrupts it will return
> before the thread had a chance to run (free_irq() will handle it
> properly and wait for the interrupt thread/handler to complete).

Good.  Meng Li, can you test a patch that replaces the
local_irq_disable() - usb_hcd_irq() - local_irq_enable() lines with a
single call to generic_handle_irq_safe()?

> > The fundamental problem here is that the uhci-hcd driver was not written 
> > with unexpected hardware removal in mind.  It doesn't have timeouts to 
> > handle situations where the device doesn't generate an IRQ to indicate 
> > completion of an I/O operation.  And since it's been ten years since 
> > I've done any significant work on the driver, I'd really like to avoid 
> > the need for such a far-reaching change (not least because I don't have 
> > any way to test it).
> 
> I see. Don't over complicate or "correct" things here. What should work
> is that the removal callback can be called at any time and things
> continue work. That means it will purge all queues, cancel all requests,
> timers, whatever and free all resources associated with the driver/
> device.

The driver _does_ work under those circumstances -- provided the
hardware is still present and accessible.

> If it comes to PCI-hotplug you have to have a so called PCI-hotplug
> slot. This "slot" will let the OS know if the hardware has been removed
> or added. If you don't have such a thing you have to maintain the state
> yourself by using the "remove" and "rescan" sysfs files of the PCI slot.
> 
> I'm not aware of any requirement for a PCI-driver to check if its device
> has been removed.

That's the problem: The driver doesn't really support PCI-hotplug.
The code that Meng Li wants to change was sort of a half-baked way to
add such support.

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