On 2020-09-25 11:11:42 [+0200], Jerome Brunet wrote: > I'm not sure about this. > As you have explained on IRC, I understand that IRQF_ONESHOT is causing > trouble with RT as the hard IRQ part of the thread will not be migrated > to a thread. That was certainly not the intent when putting this flag. That is my understanding as well. > This seems pretty unsafe to me. Maybe we could improve the driver so it > copes with this case gracefully. ATM, I don't think it would. Running the primary handler in hardirq context is bad, because it invokes meson_mmc_request_done() at the very end. And here: - mmc_complete_cmd() -> complete_all() There is a lockdep_assert_RT_in_threaded_ctx() which should trigger. - led_trigger_event() -> led_trigger_event() This should trigger a might_sleep() warning somewhere. So removing IRQF_ONESHOT is okay but it should additionally disable the IRQ source in meson_mmc_irq() and re-enable back in meson_mmc_irq_thread(). Otherwise the IRQ remains asserted and may fire multiple times before the thread has a chance to run. Sebastian