public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Francesco Dolcini <francesco@dolcini.it>
To: Xu Yang <xu.yang_2@nxp.com>
Cc: heikki.krogerus@linux.intel.com, gregkh@linuxfoundation.org,
	andre.draszik@linaro.org, rdbabiera@google.com,
	m.felsch@pengutronix.de, dan.carpenter@linaro.org,
	emanuele.ghidoli@toradex.com, parth.pancholi@toradex.com,
	francesco.dolcini@toradex.com, u.kleine-koenig@baylibre.com,
	linux-usb@vger.kernel.org, imx@lists.linux.dev, jun.li@nxp.com
Subject: Re: [PATCH v2 2/2] usb: typec: tcpci: write ALERT_MASK after devm_request_threaded_irq()
Date: Mon, 16 Dec 2024 19:55:40 +0100	[thread overview]
Message-ID: <20241216185540.GA53932@francesco-nb> (raw)
In-Reply-To: <20241212122409.1420962-2-xu.yang_2@nxp.com>

On Thu, Dec 12, 2024 at 08:24:09PM +0800, Xu Yang wrote:
> With edge irq support, the ALERT event may be missed currently. The reason
> is that ALERT_MASK register is written before devm_request_threaded_irq().
> If ALERT event happens in this time gap, it will be missed and ALERT line
> will not recover to high level. However, we can't meet this issue with
> level irq. To avoid the issue, this will add a flag set_alert_mask. So
> ALERT_MASK can be written after devm_request_threaded_irq() is called. The
> behavior of tcpm_init() keeps unchanged.
> 
> Fixes: 77e85107a771 ("usb: typec: tcpci: support edge irq")
> Cc: stable@vger.kernel.org
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>

I wonder if this should be squashed together with the first commit,
given you re-introduce an issue with the previous commit.

 
> 
> ---
> Changes in v2:
>  - new patch
> ---
>  drivers/usb/typec/tcpm/tcpci.c | 22 +++++++++++++++++-----
>  1 file changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
> index db42f4bf3632..836f6d54d267 100644
> --- a/drivers/usb/typec/tcpm/tcpci.c
> +++ b/drivers/usb/typec/tcpm/tcpci.c
> @@ -37,6 +37,7 @@ struct tcpci {
>  	unsigned int alert_mask;
>  
>  	bool controls_vbus;
> +	bool set_alert_mask;
>  
>  	struct tcpc_dev tcpc;
>  	struct tcpci_data *data;
> @@ -700,7 +701,10 @@ static int tcpci_init(struct tcpc_dev *tcpc)
>  
>  	tcpci->alert_mask = reg;
>  
> -	return tcpci_write16(tcpci, TCPC_ALERT_MASK, reg);
> +	if (tcpci->set_alert_mask)
> +		ret = tcpci_write16(tcpci, TCPC_ALERT_MASK, reg);
> +
> +	return ret;
>  }
>  
>  irqreturn_t tcpci_irq(struct tcpci *tcpci)
> @@ -931,12 +935,20 @@ static int tcpci_probe(struct i2c_client *client)
>  					_tcpci_irq,
>  					IRQF_SHARED | IRQF_ONESHOT,
>  					dev_name(&client->dev), chip);
> -	if (err < 0) {
> -		tcpci_unregister_port(chip->tcpci);
> -		return err;
> -	}
> +	if (err < 0)
> +		goto unregister_port;
>  
> +	/* Enable the interrupt on chip at last */
> +	err = tcpci_write16(chip->tcpci, TCPC_ALERT_MASK, chip->tcpci->alert_mask);
what's the content of alert_mask here? 

I am not fully understanding why this flag is needed, can't we just ensure
that within probe the alert mask is set to 0, after probe return with
success we have the interrupt handler enabled and we can just write the
alert mask unconditionally.

Or I am just misunderstanding all of it?

If you disable the interrupt in the porbe

Francesco


  reply	other threads:[~2024-12-16 18:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-12 12:24 [PATCH v2 1/2] usb: typec: tcpci: fix NULL pointer issue on shared irq case Xu Yang
2024-12-12 12:24 ` [PATCH v2 2/2] usb: typec: tcpci: write ALERT_MASK after devm_request_threaded_irq() Xu Yang
2024-12-16 18:55   ` Francesco Dolcini [this message]
2024-12-17  8:54     ` Xu Yang
2024-12-17  9:20       ` Francesco Dolcini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241216185540.GA53932@francesco-nb \
    --to=francesco@dolcini.it \
    --cc=andre.draszik@linaro.org \
    --cc=dan.carpenter@linaro.org \
    --cc=emanuele.ghidoli@toradex.com \
    --cc=francesco.dolcini@toradex.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=imx@lists.linux.dev \
    --cc=jun.li@nxp.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=m.felsch@pengutronix.de \
    --cc=parth.pancholi@toradex.com \
    --cc=rdbabiera@google.com \
    --cc=u.kleine-koenig@baylibre.com \
    --cc=xu.yang_2@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox