Hi,

On 7-Jan-26 10:52, 张永波 wrote:

quoted

Still ideally we would solve this in another way then
switching to a threaded IRQ handler.

As the commit message of the mei-vsc fix mentions
the root cause of these errors is typically an interrupt
chip driver which uses IRQF_NO_THREAD disabling the auto
threading of all interrupt handlers in RT mode.

So the first question here would be to see if that flag is
used in the interrupt chip and if yes, is that flag really
necessary ?

This is very similar to the issue addressed in commit 24b176d8827d
("drm/msm/dsi: Remove spurious IRQF_ONESHOT flag").
The IRQF_ONESHOT flag is preventing forced threading here.

In irq_setup_forced_threading(), the conversion to threaded interrupts
is explicitly skipped if any of the IRQF_NO_THREAD, IRQF_PERCPU,
or IRQF_ONESHOT flags are present. In this case, IRQF_ONESHOT
appears to be the reason.

Ah, well the code effectively does its own IRQF_ONESHOT handling,
since it needs to do its own threaded-irq like handling for
suspend/resume reasons. It disables the IRQ when it fires and
then only re-enables it once the work has done processing the IRQ.

So it should be perfectly safe to drop the IRQF_ONESHOT flag.

If that also works to resolve the lockdep issue that would be
the preferred way of fixing this IMHO.

Regards,

Hans