[PATCH v1 3/3] usb: typec: fusb302: Switch to threaded interrupt handler
Hans de Goede
hansg at kernel.org
Thu Jan 8 00:32:51 PST 2026
Hi,
On 8-Jan-26 07:58, Anand Moon wrote:
> Hi Hans,
>
> On Wed, 7 Jan 2026 at 16:22, Hans de Goede <hansg at kernel.org> wrote:
>>
>> Hi,
>>
>> On 7-Jan-26 10:52, 张永波 wrote:
>>>> 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
>> 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
More information about the linux-arm-kernel
mailing list