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). > 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. 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. > I suppose an alternative approach would be to add a new callback pointer > to the hc_driver structure -- something that could tell the driver to > check for hardware removal. I'll do that if there's no other choice. > But simulating an interrupt seems easier, provided it can be done at > all. > > Alan Stern Sebastian
