From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
To: Vladyslav Tymoshchuk <tvlad744@gmail.com>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
Prashanth K <prashanth.k@oss.qualcomm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>,
Faisal Hassan <faisal.hassan@oss.qualcomm.com>,
Abel Vesa <abelvesa@kernel.org>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] usb: dwc3: qcom: Defer VBUS override update during system suspend
Date: Wed, 11 Nov 2026 03:00:55 +0000 [thread overview]
Message-ID: <avPYz8Bph8D7LGSX@vbox> (raw)
In-Reply-To: <20261110172148.1640-1-tvlad744@gmail.com>
On Tue, Nov 10, 2026, Vladyslav Tymoshchuk wrote:
> On Thu, Nov 05, 2026 at 12:02:46AM +0000, Thinh Nguyen wrote:
> > Hi Vladyslav,
> >
> > Could you test this change instead to see if it resolves the issue?
>
> It does. OnePlus Pad 3 (SM8750, UCSI over pmic_glink), v7.3-rc5 plus
> board patches, with my dwc3-qcom v2 reverted and nothing else holding
> back pmic_glink notifications during suspend. I added debug prints to
> dwc3_usb_role_switch_set(), to __dwc3_set_mode() before the glue call,
> and to dwc3_qcom_set_role_notifier(), with the device's PM state.
>
> The same kernel without your change resets the SoC when the cable is
> unplugged in s2idle. The last lines in the ramoops console:
>
> PM: suspend-to-idle
> role_switch_set ->0 (pm suspended 1 late 1 noirq 1)
> qcom notifier: role 2->0, vbus override 0 (pm suspended 1 noirq 1)
>
> With your change there was no reset. Each suspend run was 150 s of
> s2idle ended by an RTC alarm, with the cable changed by hand during it:
>
> unplug 2 runs
> plug in 1 run
> unplug, plug back in 1 run
> cable left plugged in 1 run
>
> plus unplug and plug in while awake. In the suspend runs every role
> switch call came with dwc3 in the noirq phase and only stored the role.
> The glue was called once, with the last role, when the freezable
> workqueue was thawed:
>
> PM: suspend-to-idle
> role_switch_set ->0 (pm suspended 1 late 1 noirq 1)
> PM: resume of devices complete after 108.388 msecs
> Restarting tasks: Starting
> drd_work passes role 0 to the glue
> qcom notifier: role 2->0, vbus override 0 (pm suspended 0 noirq 0)
> Restarting tasks: Done
>
> Unplug and plug in during one suspend came down to a single DEVICE
> call, which dwc3-qcom skips since its role did not change. After every
> resume with the cable in, the NCM gadget was configured again within
> 5 s. While awake, the glue still gets NONE and DEVICE although the dr
> mode stays peripheral, so the call has to stay ahead of the early
> returns in __dwc3_set_mode(), where you put it.
>
> Host mode, with a USB stick on the port instead of the cable: plugging
> and unplugging the stick while awake works as before, and so did two
> suspends with the stick left in. With the stick unplugged in s2idle
> (3 runs) the NONE call again came in noirq and was only stored, and
> drd_work passed it on after thaw:
>
> PM: suspend-to-idle
> role_switch_set ->0 (pm suspended 1 late 1 noirq 1)
> PM: resume of devices complete after 2554.135 msecs
> Restarting tasks: Starting
> drd_work passes role 0 to the glue
> qcom notifier: role 1->0, vbus override 1 (pm suspended 0 noirq 0)
> xhci-hcd xhci-hcd.3.auto: remove, state 1
> Restarting tasks: Done
>
> The host-mode suspends were on a kernel that also keeps the USB GDSCs
> of gcc-sm8750 in retention. Without that the xHCI came back from
> s2idle with an SMMU fault and "HC died" in all three runs I tried,
> with the stick unplugged or left in. The dwc3 code was the same in
> both kernels, so that is a separate problem. I have no result for
> plugging the stick in during s2idle: the port did not detect the stick
> every time, also while awake, and I have not found out why yet.
>
> Two comments go stale with this change: dwc3_qcom_set_role_notifier()
> says role changes are protected by the usb_role_switch mutex, while now
> they are serialized by dwc->mutex in drd_work, and the @pre_set_role
> kerneldoc could say that it is called from drd_work, so not during
> system sleep.
Please update the comments.
>
> Will you post it, or would you like me to send it as v3 in place of my
> dwc3-qcom patch?
>
> Tested-by: Vladyslav Tymoshchuk <tvlad744@gmail.com> # SM8750
Thanks for the details and testing. Can you send it as v3 with my
Suggested-by tag?
Suggested-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Thanks,
Thinh
prev parent reply other threads:[~2026-11-11 3:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 22:42 [PATCH v2] usb: dwc3: qcom: Defer VBUS override update during system suspend Vladyslav Tymoshchuk
2026-10-22 22:52 ` sashiko-bot
2026-11-02 7:58 ` Krishna Kurapati
2026-11-04 2:37 ` Thinh Nguyen
2026-11-04 4:36 ` Prashanth K
2026-11-05 0:02 ` Thinh Nguyen
2026-11-10 17:21 ` Vladyslav Tymoshchuk
2026-11-11 3:00 ` 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=avPYz8Bph8D7LGSX@vbox \
--to=thinh.nguyen@synopsys.com \
--cc=abelvesa@kernel.org \
--cc=faisal.hassan@oss.qualcomm.com \
--cc=gregkh@linuxfoundation.org \
--cc=krishna.kurapati@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=prashanth.k@oss.qualcomm.com \
--cc=tvlad744@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.