From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
To: Uttkarsh Aggarwal <uttkarsh.aggarwal@oss.qualcomm.com>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] usb: dwc3: wait for USB2 PHY clock recovery during role switch
Date: Thu, 12 Nov 2026 00:22:36 +0000 [thread overview]
Message-ID: <avUBz_JfXLIqK5yj@vbox> (raw)
In-Reply-To: <20261030062509.3475322-1-uttkarsh.aggarwal@oss.qualcomm.com>
Hi,
On Fri, Oct 30, 2026, Uttkarsh Aggarwal wrote:
> During a device-to-host role switch, the USB2 PHY may still be
> suspended from the previous gadget session. After clearing SUSPHY,
> the PHY requires up to 1.5 ms before the UTMI clock is stable.
> This was observed during a device-to-host role switch with
> a USB earphone attached. Traces showed that SUSPHY remained asserted
> until __dwc3_set_mode() cleared it, after which host initialization
> immediately started accessing the xHCI PORTSC registers.
> The USB2 PHY specification requires up to 1.5 ms for clock recovery
Which spec is this? UTMI allows up to 5.6ms for the first clock
transition after SuspendM is released. The 1.5ms looks like it's
specific to this particular phy.
The controller assumes that utmi_clk is back within 990us after it
deasserts utmi_suspend_n. That's stricter than the UTMI spec, but it's
the controller's integration requirement. A phy that takes ~1.5ms is
UTMI compliant but doesn't meet this requirement.
There will be problems with fixing this with delays in the driver. When
SUSPHY is set, the controller also wakes the phy on its own (e.g. on
connect, resume, and port reset during root hub enumeration) without any
SW involvement. A delay here only covers the SW initiated path. Other
paths such as roothub enumeration, runtime resume, and disconnect in L2
would still be exposed.
> after exiting suspend. Accessing the controller before the UTMI clock has
> stabilized can therefore occur during this recovery interval.
> Wait for the PHY clock recovery when SUSPHY was set before switching
> to host mode. Avoid the delay when the PHY was already active.
> This change is limited to the role-switch path. Runtime suspend
> requires separate handling
>
> Signed-off-by: Uttkarsh Aggarwal <uttkarsh.aggarwal@oss.qualcomm.com>
> ---
> drivers/usb/dwc3/core.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index fd5c2cd36c59..885bb9301866 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -233,6 +233,20 @@ static void __dwc3_set_mode(struct work_struct *work)
> dwc3_writel(dwc, DWC3_GCTL, reg);
> }
>
> + /*
> + * If the USB2 PHY was left suspended (e.g. by
> + * dwc3_gadget_run_stop()/dwc3_gadget_exit() during a device->host
> + * switch), its UTMI clock needs time to become valid again before
> + * dwc3_set_prtcap() flips GCTL.PRTCAP and the new role starts
> + * driving further register accesses on it (e.g. host root hub
> + * PORTSC writes in dwc3_host_init()).
> + */
> + reg = dwc3_readl(dwc, DWC3_GUSB2PHYCFG(0));
> + if (reg & DWC3_GUSB2PHYCFG_SUSPHY) {
> + dwc3_enable_susphy(dwc, false);
> + usleep_range(1500, 2000);
Also note that this applies to every role switch, not just
device-to-host, and it only checks port 0 while dwc3_enable_susphy()
clears all ports.
If the PHY can't be configured to restore its clock within 990us,
please keep snps,dis_u2_susphy_quirk for these platforms.
Thanks,
Thinh
prev parent reply other threads:[~2026-11-12 0:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-30 6:25 [RFC PATCH] usb: dwc3: wait for USB2 PHY clock recovery during role switch Uttkarsh Aggarwal
2026-10-30 6:34 ` sashiko-bot
2026-11-12 0:22 ` 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=avUBz_JfXLIqK5yj@vbox \
--to=thinh.nguyen@synopsys.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=uttkarsh.aggarwal@oss.qualcomm.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