From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5667237CD44; Mon, 13 Apr 2026 09:28:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776072526; cv=none; b=Mv/Xk3s9tYZPc41KcRZTYJHLo21+66psxyIc8NnTD/bz5qGno6FK003bRghtRzS9edYQJgAp/l0xbmcPovV4A/kHAZuy+Z7n2EiV1CCND50Sp5jcKVGdMKXy8Wj26PBsGh6Atv051oSSUL9NTjjUCrUcpElwpTQUHwhOWqoAhbs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776072526; c=relaxed/simple; bh=swrqoNRI7b5SyUeon1VlvSsyJjrUtH0QoZ70SUxzLKg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hS3fMtp8AnxeMDwlKMvZPXekTz+7mkUtWvIuyo8LcfMwrEzOUPH5QLrrIhPReZUM02BoPXlK2v5zmiy6PH5rHgn2hgxrwudfH4B28/usCwUJ3JI6PF8IXgkNkxXZH4izJiBOpriuKRnJmkdrOCdROIQFvGpMX7XOcq5IjREo/WE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=gyDZknSe; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="gyDZknSe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9ADE2C116C6; Mon, 13 Apr 2026 09:28:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1776072526; bh=swrqoNRI7b5SyUeon1VlvSsyJjrUtH0QoZ70SUxzLKg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gyDZknSe9kOXSE3sMi0i4SzDbRCLiYA4OE3DsVfsKOLbnn0On0cnQ/38++ZaxKvRQ uRDaSuFHypp2hIXrzmsT4vSVmIzRh7rQGEfL4aTtC+yXiKf/H50NlVt65Kw/FVRIGP 0RXDFEjxXTP3nhAgmtZZpG456tjmDtpUy3yZfKgk= Date: Mon, 13 Apr 2026 11:28:43 +0200 From: Greg Kroah-Hartman To: Alexey Charkov Cc: Heikki Krogerus , Sebastian Reichel , Hans de Goede , Sebastian Andrzej Siewior , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v2] usb: typec: fusb302: Switch to threaded IRQ handler Message-ID: <2026041357-diabolic-knickers-e504@gregkh> References: <20260317-fusb302-irq-v2-1-dbabd5c5c961@flipper.net> <2026040344-uncouple-maroon-69a1@gregkh> Precedence: bulk X-Mailing-List: linux-usb@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 > 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 > > > --- > > > 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