On Mon, Oct 05 2020 at 10:22, Ulf Hansson wrote: > On Fri, 2 Oct 2020 at 18:49, Jerome Brunet <jbrunet@xxxxxxxxxxxx> wrote: >> >> IRQF_ONESHOT was added to this driver to make sure the irq was not enabled >> again until the thread part of the irq had finished doing its job. >> >> Doing so upsets RT because, under RT, the hardirq part of the irq handler >> is not migrated to a thread if the irq is claimed with IRQF_ONESHOT. >> In this case, it has been reported to eventually trigger a deadlock with >> the led subsystem. >> >> Preventing RT from doing this migration was certainly not the intent, the >> description of IRQF_ONESHOT does not really reflect this constraint: >> >> > IRQF_ONESHOT - Interrupt is not reenabled after the hardirq handler finished. >> > Used by threaded interrupts which need to keep the >> > irq line disabled until the threaded handler has been run. >> >> This is exactly what this driver was trying to acheive so I'm still a bit >> confused whether this is a driver or an RT issue. >> >> Anyway, this can be solved driver side by manually disabling the IRQs >> instead of the relying on the IRQF_ONESHOT. IRQF_ONESHOT may then be removed >> while still making sure the irq won't trigger until the threaded part of >> the handler is done. > > Thomas, may I have your opinion on this one. > > I have no problem to apply $subject patch, but as Jerome also > highlights above - this kind of makes me wonder if this is an RT > issue, that perhaps deserves to be solved in a generic way. > > What do you think? Let me stare at the core code. Something smells fishy.
