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

[Alexey Charkov]

Hi Greg,

On Fri, Apr 3, 2026 at 10:36 AM Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Tue, Mar 17, 2026 at 08:30:15PM +0400, Alexey Charkov wrote:
> > FUSB302 fails to probe with -EINVAL if its interrupt line is connected via
> > an I2C GPIO expander, such as TI TCA6416.
> >
> > Switch the interrupt handler to a threaded one, which also works behind
> > such GPIO expanders.
> >
> > Cc: stable@xxxxxxxxxxxxxxx
> > Fixes: 309b6341d557 ("usb: typec: fusb302: Revert incorrect threaded irq fix")
> > Signed-off-by: Alexey Charkov <alchark@xxxxxxxxxxx>
> > ---
> > Changes in v2:
> > - Re-added the IRQF_ONESHOT flag to the request_threaded_irq() call
> >   (thanks Hans de Goede and Sebastian Andrzej Siewior)
> > - Link to v1: https://lore.kernel.org/r/20260311-fusb302-irq-v1-1-7e7105706629@xxxxxxxxxxx
> > ---
> >  drivers/usb/typec/tcpm/fusb302.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/typec/tcpm/fusb302.c b/drivers/usb/typec/tcpm/fusb302.c
> > index ce7069fb4be6..889c4c29c1b8 100644
> > --- a/drivers/usb/typec/tcpm/fusb302.c
> > +++ b/drivers/usb/typec/tcpm/fusb302.c
> > @@ -1764,8 +1764,9 @@ static int fusb302_probe(struct i2c_client *client)
> >               goto destroy_workqueue;
> >       }
> >
> > -     ret = request_irq(chip->gpio_int_n_irq, fusb302_irq_intn,
> > -                       IRQF_TRIGGER_LOW, "fsc_interrupt_int_n", chip);
> > +     ret = request_threaded_irq(chip->gpio_int_n_irq, NULL, fusb302_irq_intn,
> > +                                IRQF_ONESHOT | IRQF_TRIGGER_LOW,
> > +                                "fsc_interrupt_int_n", chip);
> >       if (ret < 0) {
> >               dev_err(dev, "cannot request IRQ for GPIO Int_N, ret=%d", ret);
> >               goto tcpm_unregister_port;
> >
>
> I'll take this, but the testing systems rightly point out that
> chip->gpio_int_n_irq may NOT be initialized before this call is made in
> some situations, so this whole irq handler might never be set up.

Thanks for the heads up. I've been staring at this code from different
angles for a while but I can't see how gpio_int_n_irq can remain
uninitialized and the function still reach this point in the control
flow:
- The whole `chip` struct gets zero-initialized at the beginning of
the probe function
- For non-zero values of `client->irq` this field is explicitly set to
the (non-zero) value of client->irq
- For zero values of `client->irq`, the helper function `init_gpio()`
is always called. This function either sets this field to the result
of a `gpiod_to_irq()` call (which must be a valid interrupt number) or
it errors out early, terminating the entire probe before control
reaches request_threaded_irq()

Please let me know if I've missed anything here.

What can be problematic is that the check `if (chip->irq)` is too lax,
because any negative errno or IRQ_NOTCONNECTED (a.k.a. -2147483648)
would be treated as a usable interrupt, which it is not. I believe
request_threaded_irq() would fail on them anyway, but the code's
intent seems to have rather been `if (chip->irq > 0)`.

> I know your change didn't cause that logic bug to show up, but can you
> send a patch to fix that, as you have the ability to test these types of
> changes?

Sure, I'll test the change on chip->irq to filter out negative values
and send a patch if all goes well.

Best regards,
Alexey