> -----Original Message----- > From: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> > Sent: Saturday, November 4, 2023 4:42 AM > To: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> > Cc: Li, Meng <Meng.Li@xxxxxxxxxxxxx>; Steven Rostedt > <rostedt@xxxxxxxxxxx>; Ingo Molnar <mingo@xxxxxxxxxx>; USB mailing list > <linux-usb@xxxxxxxxxxxxxxx>; linux-rt-users <linux-rt-users@xxxxxxxxxxxxxxx> > Subject: Re: USB: add check to detect host controller hardware removal > > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and > know the content is safe. > > 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()? It needs an irq number as parameter, what I should pass to this function, 0 or dev->irq or other value? Thanks, Limeng > > > > 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
