mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

      reply	other threads:[~2026-11-11  3:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-22 22:42 Vladyslav Tymoshchuk
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 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®