On 2020-09-25 16:14:09 [+0200], Jerome Brunet wrote: > Looks like we need to do manually what IRQF_ONESHOT was doing for us :( IRQF_ONESHOT disables the IRQ at the irqchip level. You must ensure that the device keeps quite. Usually you mast the interrupt source at the device lee. > This brings a few questions: > > * The consideration you described is not mentioned near the description > of IRQF_ONESHOT. Maybe it should so other drivers with same intent > don't end up in the same pitfall ? >From request_threaded_irq() -> | * If you want to set up a threaded irq handler for your device | * then you need to supply @handler and @thread_fn. @handler is | * still called in hard interrupt context and has to check | * whether the interrupt originates from the device. If yes it | * needs to disable the interrupt on the device and return | * IRQ_WAKE_THREAD which will wake up the handler thread and run | * @thread_fn. This split handler design is necessary to support | * shared interrupts. Just the line that saying what needs to be done before returning IRQ_WAKE_THREAD. > * Why doesn't RT move the IRQ with this flag ? Seems completly unrelated > to RT (maybe it is the same documentation problem) It is unrelated to RT. Mostly. You end up with the same problem booting with `threadirqs'. RT has the additional restrictions that you may not acquire any sleeping locks in hardirq context. This you can see with addinional lockdep magic. > * Can't we have flag doing the irq disable in the same way while still > allowing to RT to do its magic ? seems better than open coding it in > the driver ? Puh. That should be forwarded the IRQ department. So we have IRQF_NO_THREAD to avoid force threading. This is documented as such. Then we have IRQF_TIMER and IRQF_PERCPU which are also not force threaded and it is not documented as such. However it is used for the timer-IRQ, IPI, perf and such - things you obviously don't want to thread and need to run in hard-IRQ context. What you have ist a primary and secondary and IRQF_ONESHOT and don't want the primary handler to be force-threaded. I can't answer why we don't. However, drivers usually disable the source themself if they providing both handler. Sebastian
