[PATCH v3] usb: dwc3: st: balance reset ownership on deassert failure
Thinh Nguyen
Thinh.Nguyen at synopsys.com
Tue Nov 3 16:42:23 PST 2026
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 at 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
More information about the linux-arm-kernel
mailing list