Hi,

On 8-Jan-26 07:58, Anand Moon wrote:

Hi Hans,

On Wed, 7 Jan 2026 at 16:22, Hans de Goede [off-list ref] wrote:

quoted

Hi,

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

quoted

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.

Yes, the warning disappears

quoted

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

After applying these changes, the device initially triggered a hard reset;
And the board reboots. I need to find another way to fix this warning.

Hmm, I guess that without the oneshot flag fusb302_irq_intn() might
trigger a second time before it disables the IRQ causing an IRQ enable
unbalance issue.

So lets just go with your original fix of moving this to a threaded
IRQ handler.

Regards,

Hans