Re: [PATCH] usb: typec: fusb302: Switch to threaded IRQ handler

[Hans de Goede <hansg@kernel.org>]

Hi,

On 17-Mar-26 18:12, Sebastian Reichel wrote:
> Hi,
> 
> On Fri, Mar 13, 2026 at 05:21:33PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 12-Mar-26 13:04, Sebastian Andrzej Siewior wrote:
>>> On 2026-03-12 11:49:30 [+0100], Hans de Goede wrote:
>>>> Using a threaded interrupt handler should be ok, yes. This should
>>>> also fix the issue this patch tries to fix:
>>>>
>>>> https://lore.kernel.org/linux-usb/20260103083232.9510-4-linux.amoon@gmail.com
>>>
>>> This issue went away with commit a7fb84ea70aae ("usb: typec: fusb302:
>>> Remove IRQF_ONESHOT").
>>>
>>>> Normally an i2c device like this would use a threaded interrupt handler to
>>>> do all the work since I2C transfers can sleep combined with disabling the IRQ
>>>> on suspend to avoid the interrupt handler running while the parent i2c-adapter
>>>> may be suspended.
>>>>
>>>> The problem with the fusb302 is that it can be a wakeup source so we cannot
>>>> disable the IRQ. I worked around this in commit 207338ec5a2 ("usb: typec: fusb302:
>>>> Improve suspend/resume handling") by moving the actual work to a workqueue
>>>> and have a hard (non threaded) interrupt handler which disables the IRQ and
>>>> queues the work, with the work re-enabling the IRQ when done + special
>>>> handling for the suspended case. Basically our own manual oneshot.
>>>>
>>>> If we move the IRQ disabling to a threaded handler, which appears to be
>>>> necessary for some IRQ controllers (arguably a IRQ controller driver issue,
>>>> but this seems to be a re-occuring issue), then I wonder if we need
>>>> the ONESHOT flag again to avoid a level type IRQ re-triggering before
>>>> the threaded handler gets a chance to disable it (with the workqueue
>>>> item eventually re-enabling it).
>>>>
>>>> I think we need to re-add the ONESHOT flag, but maybe that is the default
>>>> with a primary NULL handler ?
>>>>
>>>> Sebastian Siewior I think you now the IRQ subsystem better then me,
>>>> any advice / remarks ?
>>
>> Sebastian, Thank you for your input.
>>
>>> You could do
>>> 	request_threaded_irq(chip->gpio_int_n_irq, NULL, fusb302_irq_intn,
>>> 			     IRQF_ONESHOT | IRQF_TRIGGER_LOW, "fsc_interrupt_int_n", chip);
>>
>> Ok, that is good to know.
>>
>>> which would ensure that the handler runs as a thread and the interrupt
>>> line is disable while it is active.
>>
>> That is what we want, thank you.
>>
>>> Then you could let fusb302_irq_intn() do what fusb302_irq_work() does.
>>> Since it is a thread, mutex_lock() works here.
>>
>> Right, but the resume handler needs to also schedule the work when the
>> IRQ is initially ignored if the IRQ triggers before the i2c_client's
>> resume-handler is called to ensure that the parent i2c-adapter is
>> ready when the IRQ handling code does i2c accesses.
>>
>>> Last step would be to replace fusb302_chip::irq_suspended with
>>> disable_irq() in fusb302_pm_suspend() and enable_irq() in
>>> fusb302_pm_resume().
>>
>> That unfortunately is not possible because the fusb302 maybe
>> a wake-up source so it cannot be disabled unconditionally
>> and without the disable_irq() / enable_irq() pair the IRQ
>> may trigger before the parent i2c-adapter is resumed.
>>
>> This is why the IRQ handling in this driver is as convoluted
>> as it is in the first place. With the IRQ handler setting
>> an irq_while_suspended flag if the IRQ runs before the
>> i2c_client resume and then with resume checking that flag
>> + queuing the work do to the actual IRQ handling once the
>> parent i2c-adapter is ready (if we hit this race).
> 
> After re-checking everything, I don't see anything special about the
> fusb302 and wondering a bit why this is not an issue with other
> devices like e.g. i2c-hid (which can also be wakeup sources, see
> e.g. HID devices on your Qualcomm T14s). Does that have the same
> issue and we are just not running into the race condition?

drivers/hid/i2c-hid/i2c-hid-core.c: i2c_hid_core_suspend()
does a disable_irq() AFAIK that is not really allowed for
a wakeup source. The wakeup source thingie likely still
works on x86 because x86 hw has a whole separate event
system in the hw for wakeup events.

The i2c-hid-core.c drivers also seems to miss calls
to enable_irq_wake() so they never configure the IRQ
as a wakeup source, further suggesting the handling there
is incomplete.

But on pure s2idle systems where there is only the 1 IRQ
mechanism disable_irq() will result in no wake-ups AFAIK
(as well as enable_irq_wake() being necessary to avoid the
IRQ getting disabled in the final stages of suspend).

Note I'm not very familiar with all this, so the above
could be very wrong ...

> In that case it might be sensible to move the logic for "interrupt
> function should only run after the device has been PM resumed" into
> the IRQ core behind a flag and simplify the drivers?

I do believe that having some sort of helpers for this,
either in the IRQ core, or in some drivers/base code
or some such, would be useful yes.

>> So as far as I can see the current state of fusb302 code
>> is good as is.
> 
> I think with the threaded irq handler, the code could be simplified
> to no longer use a worker thread. Instead the thread and the irq
> handler can be merged. It seems sensible to do this in a separate
> patch, though.

No that cannot be done, because the work will get scheduled
from fsusb302_resume() if the IRQ ran (and set a flag) before
fsusb302_resume() run and thus before the i2c-adapter parent
was ready.

One might be tempted to replace the queuing of the work
in fsusb302_resume() with a direct call to the threaded
interrupt handler. But the code relies on the workqueue
mechanism to also ensure that the threaded interrupt
handler does not run in parallel with itself.

If we drop the disable_irq() + queue-work + work does
enable_irq() pair currently done and instead bail early if
not resumed for the threaded handler and still set the flag
to redo the interrupt handling from the resume handler
then we may end up with 2 threads running the interrupt
handling in parallel.

I guess we could take some mutex for the entire run
of the threaded handler to deal with that but I'm not
sure if that would be an improvement.

Regards,

Hans