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: > > On Mon, Aug 22, 2022 at 03:13:54PM +0200, Johan Hovold wrote: > > > On Tue, Aug 02, 2022 at 05:26:42PM +0200, Johan Hovold wrote: > > > > Move the USB-controller wakeup-source property to the dwc3 glue node to > > > > match the updated binding. > > > > > > > > Signed-off-by: Johan Hovold <johan+linaro@xxxxxxxxxx> > > > > --- > > > > > > > > This one can be applied once the following series has been merged: > > > > > > > > https://lore.kernel.org/all/20220802151404.1797-1-johan+linaro@xxxxxxxxxx > > > > > > The above series has now been merged (for 6.0): > > > > > > https://lore.kernel.org/all/Yv56fFpuUsxCSxJ8@xxxxxxxxx/ > > > > > > 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@xxxxxxxxxx/ > Only in the latter case, does this patch need to be held of until [1] > has been merged AFAICT. > > Johan > > > [1] https://patchwork.kernel.org/project/linux-arm-msm/patch/20220822115246.2.If09027f73daa6e1ed95f5eab02326b543c67132e@changeid/
