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

[Greg Kroah-Hartman]

On Mon, Apr 13, 2026 at 12:59:11PM +0400, Alexey Charkov wrote:
> 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()

Ah, it's this last thing that I, and the compiler test, misses, sorry
about that.

So all is good here, thanks.

greg k-h