Re: [PATCH] arm64: dts: qcom: sc7280: move USB wakeup-source property

On Tue, Aug 23, 2022 at 01:35:57PM +0200, Johan Hovold wrote:

On Mon, Aug 22, 2022 at 03:31:21PM -0700, Matthias Kaehlcke wrote:

quoted

On Mon, Aug 22, 2022 at 03:13:54PM +0200, Johan Hovold wrote:

quoted

On Tue, Aug 02, 2022 at 05:26:42PM +0200, Johan Hovold wrote:

quoted

Move the USB-controller wakeup-source property to the dwc3 glue node to
match the updated binding.

Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
---

This one can be applied once the following series has been merged:

	https://lore.kernel.org/all/20220802151404.1797-1-johan+linaro@kernel.org (local)

The above series has now been merged (for 6.0):

	https://lore.kernel.org/all/Yv56fFpuUsxCSxJ8@kroah.com/ (local)

so that this patch can be applied.

Please apply it together with "clk: qcom: gcc-sc7280: Keep USB GDSC power
domains on when USB wakeup is enabled" [1], otherwise USB wakeup won't work,
and worse, USB would be broken after returning from system suspend.

If you really need [1] for wakeup to work then it's already broken as
the hack added to 6.0-rc1 that kept the power domain on in suspend has
been reverted.

Yep, in v6.0-rc1 it is already broken, it should still work in the current
qcom tree. In any case wakeup isn't the primary concern, wakeup support for
sc7x80 just landed in a not-so-great shape, and your patches in v6.0-rc
generally improve it.

If [1] is also needed for USB to work after resume, we either have a
bigger problem as I alluded to in my comment to [1] (and the PD needs to
be always on) or this is due to the PHY no longer being powered down in
suspend.

Yes, it is apparently related with the PHYs no longer being powered down in
suspend. With your patch that reverts that [1] wakeup still works (as long as
wakeup for the dwc3 core remains enabled) and USB is operational after
resume.

So as long as the PHYs are powered down in suspend it shouldn't be necessary
to keep the GDSC PDs on. For Chrome OS we'll have to evaluate whether that
is an option (we observe high power consumption of an onboard USB hub
during system suspend when the PHYs are off) or whether sone mechanism (quirk,
kconfig option, ...) is needed to keep the PHYs on.

[1] https://patchwork.kernel.org/project/linux-usb/patch/20220823124047.14634-1-johan+linaro@kernel.org/

Only in the latter case, does this patch need to be held of until [1]
has been merged AFAICT.

Johan

quoted

[1] https://patchwork.kernel.org/project/linux-arm-msm/patch/20220822115246.2.If09027f73daa6e1ed95f5eab02326b543c67132e@changeid/