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 v3] usb: dwc3: st: balance reset ownership on deassert failure
Date: Wed, 4 Nov 2026 00:42:23 +0000 [thread overview]
Message-ID: <aup8I9j62dCGIc-g@vbox> (raw)
In-Reply-To: <20261014031920.8390-1-hppiscas@163.com>
On Wed, Oct 14, 2026, Pengpeng Hou wrote:
> The ST DWC3 glue ignores reset deassert failures in probe and resume.
> It may publish the child device or access the glue registers without both
> reset operations having succeeded.
>
> Check both results and unwind DRD setup failures as well. A shared
> softreset provider failure must go through undo_softreset: the reset core
> has already incremented its deassert count before calling the provider.
>
> Track whether this driver owns the deassert pair so suspend and remove do
> not release it again after failed resume has unwound it. This is reference
> ownership, not a guarantee about the physical reset-line state. Resume
> itself needs no early-return guard: the paired suspend callback clears
> the ownership state before resume is entered.
>
> The issue was found by our static-analysis tool and manually reviewed.
>
> Fixes: f83fca0707c6 ("usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC")
> Assisted-by: gpt 5
Checkpatch complains about this:
WARNING: Non-standard signature: Assisted-by:
> Signed-off-by: Pengpeng Hou <hppiscas@163.com>
> ---
> Changes since v2:
> - remove the redundant resets_active early return in resume, as Thinh queried
> - keep failed shared deasserts routed through undo_softreset
> - retain the independently needed suspend/remove ownership guards
> - rebase on current mainline
>
> Previous version:
> https://urldefense.com/v3/__https://lore.kernel.org/all/20260922004312.3589-1-hppiscas@163.com/__;!!A4F2R9G_pg!ed-PtQ6dNZKwvke0Bhh8nFcmp0TimjR_PxBUqZqXoH4lbX3ApURINkrG-iASUYnZh2QyKVL0svNI47gsG7hDbQ$
>
Looking at this again, my concern is that this was found by static
analysis and hasn't been tested on real hardware. On this platform the
reset deassert is not expected to fail, so I don't see the need for
this. It adds complexity (the resets_active tracking, and unwinding that
depends on reset core internals) without fixing an observed problem.
BR,
Thinh
prev parent reply other threads:[~2026-11-04 0:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 3:19 Pengpeng Hou
2026-10-14 9:21 ` Philipp Zabel
2026-11-04 0:42 ` 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=aup8I9j62dCGIc-g@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®