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

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

[Alexey Charkov]

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@vger.kernel.org
Fixes: 309b6341d557 ("usb: typec: fusb302: Revert incorrect threaded irq fix")
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
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@flipper.net
---
 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;

---
base-commit: 95c541ddfb0815a0ea8477af778bb13bb075079a
change-id: 20260311-fusb302-irq-316834765871

Best regards,
-- 
Alexey Charkov <alchark@flipper.net>

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

[Hans de Goede]

Hi,

On 17-Mar-26 17:30, 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@vger.kernel.org
> Fixes: 309b6341d557 ("usb: typec: fusb302: Revert incorrect threaded irq fix")
> Signed-off-by: Alexey Charkov <alchark@flipper.net>

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>

Regards,

Hans



> ---
> 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@flipper.net
> ---
>  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;
> 
> ---
> base-commit: 95c541ddfb0815a0ea8477af778bb13bb075079a
> change-id: 20260311-fusb302-irq-316834765871
> 
> Best regards,

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

[Heikki Krogerus]

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@vger.kernel.org
> Fixes: 309b6341d557 ("usb: typec: fusb302: Revert incorrect threaded irq fix")
> Signed-off-by: Alexey Charkov <alchark@flipper.net>

Reviewed-by: Heikki Krogerus <heikki.krogrerus@linux.intel.com>

> ---
> 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@flipper.net
> ---
>  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;
> 
> ---
> base-commit: 95c541ddfb0815a0ea8477af778bb13bb075079a
> change-id: 20260311-fusb302-irq-316834765871
> 
> Best regards,
> -- 
> Alexey Charkov <alchark@flipper.net>

-- 
heikki

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

[Greg Kroah-Hartman]

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@vger.kernel.org
> Fixes: 309b6341d557 ("usb: typec: fusb302: Revert incorrect threaded irq fix")
> Signed-off-by: Alexey Charkov <alchark@flipper.net>
> ---
> 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@flipper.net
> ---
>  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.

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?

thanks,

greg k-h

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@linuxfoundation.org> 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@vger.kernel.org
> > Fixes: 309b6341d557 ("usb: typec: fusb302: Revert incorrect threaded irq fix")
> > Signed-off-by: Alexey Charkov <alchark@flipper.net>
> > ---
> > 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@flipper.net
> > ---
> >  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

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@linuxfoundation.org> 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@vger.kernel.org
> > > Fixes: 309b6341d557 ("usb: typec: fusb302: Revert incorrect threaded irq fix")
> > > Signed-off-by: Alexey Charkov <alchark@flipper.net>
> > > ---
> > > 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@flipper.net
> > > ---
> > >  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