On Mon 05 Oct 2020 at 10:55, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > 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. FYI: initial discussion can be found here https://lore.kernel.org/linux-amlogic/24a844c3-c2e0-c735-ccb7-83736218b548@xxxxxxxxx/
