From: sashiko-bot@kernel.org
To: "Fabrice Gasnier" <fabrice.gasnier@foss.st.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: [PATCH v2 1/5] usb: dwc2: fix recovery after PM domain off
Date: Tue, 13 Oct 2026 13:37:27 +0000 [thread overview]
Message-ID: <sashiko-outbox-169831@kernel.org> (raw)
In-Reply-To: <20261013-dwc2-low-power-fixes-stm32-v2-1-79865a4f1b63@foss.st.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] usb: dwc2: missing host registers init on resume
- [Medium] usb: dwc2: race condition in dwc2_resume between global interrupt enable and lx_state update
--
commit bd24950c54847e44e3eeedd3dbd8cfa4f9839041
Author: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
usb: dwc2: fix recovery after PM domain off
This commit addresses a freeze during platform low power transitions
by modifying how registers are recovered after the PM domain turns off.
Instead of backing up registers that cause hangs during clock gating,
it re-initializes the core via dwc2_core_init() and restores the canary
detection logic later in the resume sequence.
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index ef0d730770347..5aa5526720783 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
[ ... ]
> @@ -786,6 +748,25 @@ static int __maybe_unused dwc2_resume(struct device *dev)
> dwc2_drd_resume(dwc2);
> }
>
> + /*
> + * During suspend it's possible that the power domain for the
> + * DWC2 controller is disabled and all register values get lost.
> + * In case the GUSBCFG register is not initialized, it's clear the
> + * registers must be restored. So invoke here the necessary init
> + * as done by dwc2_hcd_init() during probe.
> + */
> + if (!(dwc2_readl(dwc2, GUSBCFG) & GUSBCFG_TOUTCAL_MASK)) {
> + if (dwc2->dr_mode != USB_DR_MODE_PERIPHERAL) {
> + ret = dwc2_core_init(dwc2, true);
> + if (ret)
> + return ret;
[Severity: High]
Does this adequately initialize the host registers? dwc2_core_init()
only performs global initialization and doesn't configure host-specific
registers like HCFG, FIFO sizing, or the GUSBCFG_TOUTCAL canary.
While _dwc2_hcd_resume() does call dwc2_core_host_init() via
dwc2_hcd_reinit(), it unconditionally skips this step if the PHY
detects a connected device:
drivers/usb/dwc2/hcd.c:_dwc2_hcd_resume() {
...
hprt0 = dwc2_read_hprt0(hsotg);
/*
* Added port connection status checking which prevents exiting from
* Partial Power Down mode from _dwc2_hcd_resume() if not in Partial
* Power Down mode.
*/
if (hprt0 & HPRT0_CONNSTS) {
set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
hsotg->lx_state = DWC2_L0;
goto unlock;
}
...
}
Will this cause host registers to never be initialized if a device is
connected during resume, potentially breaking host mode?
Also, since the GUSBCFG_TOUTCAL canary is never restored to 7, will
subsequent resumes repeatedly misinterpret the canary as missing and trigger
redundant resets?
> + dwc2_enable_global_interrupts(dwc2);
> + }
> + /* Also ensure device mode resume takes place in dwc2_hsotg_resume() */
> + if (dwc2_is_device_mode(dwc2))
> + dwc2->lx_state = DWC2_L0;
[Severity: Medium]
Can this introduce a race condition? Global interrupts are unmasked before
the lockless update of lx_state to DWC2_L0.
If an interrupt fires immediately, the handler (dwc2_handle_common_intr)
could take the lock and read a stale DWC2_L2 state for dwc2->lx_state.
Could this lead to incorrect state transitions or a controller freeze?
> + }
> +
> if (dwc2_is_device_mode(dwc2))
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261013-dwc2-low-power-fixes-stm32-v2-0-79865a4f1b63@foss.st.com?part=1
next prev parent reply other threads:[~2026-10-13 13:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 13:15 [PATCH v2 0/5] usb: dwc2: fix low power issues found on stm32mp1 Fabrice Gasnier
2026-10-13 13:15 ` [PATCH v2 1/5] usb: dwc2: fix recovery after PM domain off Fabrice Gasnier
2026-10-13 13:37 ` sashiko-bot [this message]
2026-10-13 13:15 ` [PATCH v2 2/5] usb: dwc2: fix a possible interrupt storm on stm32mp1 Fabrice Gasnier
2026-10-13 13:57 ` sashiko-bot
2026-10-13 13:15 ` [PATCH v2 3/5] usb: dwc2: hcd: fix possible successive vbus supply enables Fabrice Gasnier
2026-10-13 14:17 ` sashiko-bot
2026-10-13 13:15 ` [PATCH v2 4/5] usb: dwc2: hcd: don't disable/enable external vbus by system suspend/resume Fabrice Gasnier
2026-10-13 14:28 ` sashiko-bot
2026-10-13 13:15 ` [PATCH v2 5/5] usb: dwc2: platform: fix stm32mp15 detection logic power management Fabrice Gasnier
2026-10-13 14:41 ` sashiko-bot
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=sashiko-outbox-169831@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=fabrice.gasnier@foss.st.com \
--cc=linux-usb@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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