mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
To: Pengpeng Hou <hppiscas@163.com>
Cc: "patrice.chotard@foss.st.com" <patrice.chotard@foss.st.com>,
	Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"p.zabel@pengutronix.de" <p.zabel@pengutronix.de>
Subject: Re: [PATCH v2] usb: dwc3: st: balance reset ownership on deassert failure
Date: Fri, 2 Oct 2026 01:59:07 +0000	[thread overview]
Message-ID: <ar8Or_quJnEiHknR@vbox> (raw)
In-Reply-To: <20260922004312.3589-1-hppiscas@163.com>

On Tue, Sep 22, 2026, Pengpeng Hou wrote:
> The ST DWC3 glue ignores reset deassert failures in probe and resume.
> Probe may publish the child device, and resume may access glue registers,
> without both reset operations having succeeded.
> 
> Check both results. Balance a failed shared softreset deassert through
> undo_softreset, since the reset core increments its shared count before
> calling the provider and does not drop it on a provider error.
> 
> Record whether this driver holds the completed deassert pair. A failed
> resume unwinds the pair and leaves that state clear. A later suspend or
> remove must not assert the shared reset a second time, and a subsequent
> resume can acquire the pair again. Unwind the resets on DRD setup errors
> as well. Exclusive powerdown and shared softreset remain distinct reset
> controls.
> 
> The issue was found by our static-analysis tool.
> 
> Fixes: f83fca0707c6 ("usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC")
> Assisted-by: gpt 5
> Signed-off-by: Pengpeng Hou <hppiscas@163.com>
> ---
> Changes since v1:
> - use undo_softreset for a failed shared deassert, as Thinh requested
> - guard later suspend/remove against a pair already unwound during resume
> - unwind DRD setup failure and preserve the original failure code
> - omit the earlier Reviewed-by because the lifecycle handling changed
> 
> Previous version:
> https://urldefense.com/v3/__https://lore.kernel.org/all/20260624055728.46078-1-pengpeng@iscas.ac.cn/__;!!A4F2R9G_pg!fLyuQUcLEdsSfSAVcTYR6KpFs-RnCNN6RGlDt1Z-G_XIHGMXAEEffsm-JlJ07OQhxy2W-W0JyHoHVeqCj0gknA$ 
> 
>  drivers/usb/dwc3/dwc3-st.c | 46 +++++++++++++++++++++++++++++++++++++---------
>  1 file changed, 37 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
> index 5d513decaacd..f954234d2b83 100644
> --- a/drivers/usb/dwc3/dwc3-st.c
> +++ b/drivers/usb/dwc3/dwc3-st.c
> @@ -84,6 +84,7 @@
>   * @dr_mode:		drd static host/device config
>   * @rstc_pwrdn:		rest controller for powerdown signal
>   * @rstc_rst:		reset controller for softreset signal
> + * @resets_active:	whether this driver holds its deasserted reset pair
>   */
>  
>  struct st_dwc3 {
> @@ -94,6 +95,7 @@ struct st_dwc3 {
>  	enum usb_dr_mode dr_mode;
>  	struct reset_control *rstc_pwrdn;
>  	struct reset_control *rstc_rst;
> +	bool resets_active;
>  };
>  
>  static inline u32 st_dwc3_readl(void __iomem *base, u32 offset)
> @@ -242,7 +244,9 @@ static int st_dwc3_probe(struct platform_device *pdev)
>  				     "could not get power controller\n");
>  
>  	/* Manage PowerDown */
> -	reset_control_deassert(dwc3_data->rstc_pwrdn);
> +	ret = reset_control_deassert(dwc3_data->rstc_pwrdn);
> +	if (ret)
> +		return ret;
>  
>  	dwc3_data->rstc_rst =
>  		devm_reset_control_get_shared(dev, "softreset");
> @@ -253,7 +257,10 @@ static int st_dwc3_probe(struct platform_device *pdev)
>  	}
>  
>  	/* Manage SoftReset */
> -	reset_control_deassert(dwc3_data->rstc_rst);
> +	ret = reset_control_deassert(dwc3_data->rstc_rst);
> +	if (ret)
> +		goto undo_softreset;
> +	dwc3_data->resets_active = true;
>  
>  	/* Allocate and initialize the core */
>  	ret = of_platform_populate(node, NULL, NULL, dev);
> @@ -305,16 +312,22 @@ static void st_dwc3_remove(struct platform_device *pdev)
>  
>  	of_platform_depopulate(&pdev->dev);
>  
> -	reset_control_assert(dwc3_data->rstc_pwrdn);
> -	reset_control_assert(dwc3_data->rstc_rst);
> +	if (dwc3_data->resets_active) {
> +		reset_control_assert(dwc3_data->rstc_pwrdn);
> +		reset_control_assert(dwc3_data->rstc_rst);
> +		dwc3_data->resets_active = false;
> +	}
>  }
>  
>  static int st_dwc3_suspend(struct device *dev)
>  {
>  	struct st_dwc3 *dwc3_data = dev_get_drvdata(dev);
>  
> -	reset_control_assert(dwc3_data->rstc_pwrdn);
> -	reset_control_assert(dwc3_data->rstc_rst);
> +	if (dwc3_data->resets_active) {
> +		reset_control_assert(dwc3_data->rstc_pwrdn);
> +		reset_control_assert(dwc3_data->rstc_rst);
> +		dwc3_data->resets_active = false;
> +	}
>  
>  	pinctrl_pm_select_sleep_state(dev);
>  
> @@ -326,21 +339,36 @@ static int st_dwc3_resume(struct device *dev)
>  	struct st_dwc3 *dwc3_data = dev_get_drvdata(dev);
>  	int ret;
>  
> +	if (dwc3_data->resets_active)

Why? Can resets_active be true here?

Thanks,
Thinh

> +		return 0;
> +
>  	pinctrl_pm_select_default_state(dev);
>  
> -	reset_control_deassert(dwc3_data->rstc_pwrdn);
> -	reset_control_deassert(dwc3_data->rstc_rst);
> +	ret = reset_control_deassert(dwc3_data->rstc_pwrdn);
> +	if (ret)
> +		return ret;
> +
> +	ret = reset_control_deassert(dwc3_data->rstc_rst);
> +	if (ret)
> +		goto undo_softreset;
>  
>  	ret = st_dwc3_drd_init(dwc3_data);
>  	if (ret) {
>  		dev_err(dev, "drd initialisation failed\n");
> -		return ret;
> +		goto undo_softreset;
>  	}
>  
>  	/* ST glue logic init */
>  	st_dwc3_init(dwc3_data);
> +	dwc3_data->resets_active = true;
>  
>  	return 0;
> +
> +undo_softreset:
> +	/* A shared deassert holds its reference even if the provider fails. */
> +	reset_control_assert(dwc3_data->rstc_rst);
> +	reset_control_assert(dwc3_data->rstc_pwrdn);
> +	return ret;
>  }
>  
>  static DEFINE_SIMPLE_DEV_PM_OPS(st_dwc3_dev_pm_ops, st_dwc3_suspend, st_dwc3_resume);
> 
> base-commit: f0100363d8c374bd8e9ea7c9ba02744f0b802ca4
> -- 
> 2.50.1 (Apple Git-155)
> 

      reply	other threads:[~2026-10-02  1:59 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-22  0:43 Pengpeng Hou
2026-10-02  1:59 ` Thinh Nguyen [this message]

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=ar8Or_quJnEiHknR@vbox \
    --to=thinh.nguyen@synopsys.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hppiscas@163.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=patrice.chotard@foss.st.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

all inboxes | Powered by JetHome®