Re: [PATCH 2/2] usb: dwc3: Keep the host bus suspended, not torn down, across suspend-to-idle

[Arun Iyengar]

Hi Vlad,

On Wed, Nov 11, 2026 at 02:15:56PM +0200, Vlad wrote:
> This is the third point of the Sashiko review seen on hardware:
> device_set_awake_path() does nothing for a domain without the flag,
> and the core is treated as kept although its power went away. I would
> expect 2/2 to bring this failure to SM8750 controllers with wakeup
> disabled too, unless [1] is applied.

Thanks for the data point from SM8750. I agree, and I have dropped
this patch.

Its replacement is an opt-in: the core keeps the host bus in
suspend-to-idle only when the glue sets keep_host_bus_in_s2idle, and
only the Rockchip glue sets it, for RK3588, whose PD_USB has
GENPD_FLAG_ACTIVE_WAKEUP. SM8750 and all other platforms stay as they
are. The RFC credits your report:

https://lore.kernel.org/r/20261112-dwc3-s2idle-optin-v1-0-842e3f8413d0@xxxxxxxxx

Best regards,
Arun

On Wed, Nov 11, 2026 at 4:16 AM Vlad <tvlad744@xxxxxxxxx> wrote:
>
> From: Vladyslav Tymoshchuk <tvlad744@xxxxxxxxx>
>
> On Tue, Nov 10, 2026 at 07:16:44AM +0000, Arun Iyengar wrote:
> > Suspend-to-idle does not power anything down behind the drivers'
> > back, so there is no reason to end the power sessions there. Keep the
> > core, its PHYs and the suspended ports, as is already done for wakeup,
> > and mark the device as being on the awake path so that a power domain
> > with GENPD_FLAG_ACTIVE_WAKEUP stays on as well.
>
> A data point from a Qualcomm board where the first sentence does not
> hold. I have not run this series; what follows is the existing "kept
> for wakeup" path, which this patch extends to every suspend-to-idle.
>
> On SM8750 (OnePlus Pad 3, v7.3-rc5 plus board patches) the controller
> node is a wakeup source, so dwc3 keeps the core in host mode. The USB
> GDSCs are PWRSTS_OFF_ON in gcc-sm8750 and the qcom GDSC driver does not
> set GENPD_FLAG_ACTIVE_WAKEUP, so genpd powers them off in s2idle all
> the same. With a USB stick on the port the xHCI then comes back like
> this, in 3 of 3 cycles of 150 s:
>
>   arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x669fd3200, fsynr=0x370011, cbfrsynra=0x40, cb=5
>   xhci-hcd xhci-hcd.3.auto: WARNING: Host System Error
>   xhci-hcd xhci-hcd.3.auto: xHCI host not responding to stop endpoint command
>   xhci-hcd xhci-hcd.3.auto: xHCI host controller not responding, assume dead
>   xhci-hcd xhci-hcd.3.auto: HC died; cleaning up
>
> With the GDSCs in retention [1], as SM8650 and X1E80100 have them, the
> same 150 s cycle passed 5 of 5 times, and two shorter cycles of 25 s
> passed as well.
>
> This is the third point of the Sashiko review seen on hardware:
> device_set_awake_path() does nothing for a domain without the flag,
> and the core is treated as kept although its power went away. I would
> expect 2/2 to bring this failure to SM8750 controllers with wakeup
> disabled too, unless [1] is applied.
>
> [1] https://lore.kernel.org/all/20261110213346.1359-1-tvlad744@xxxxxxxxx/