Re: [PATCH 0/1] usb: dwc3: qcom: Keep wakeup option default off

[Peter Chen <peter.chen@oss.qualcomm.com>]

On 26-11-12 01:14:44, Thinh Nguyen wrote:
> > Current policy
> > --------------
> > When the controller node has the "wakeup-source" property, dwc3-qcom
> > calls device_init_wakeup(dev, true). USB is then a system wakeup
> > source by default. Users who do NOT want the system woken up by USB
> > have to disable it:
> > 
> >   echo disabled > /sys/devices/.../<dwc3 device>/power/wakeup
> > 
> > Proposed policy
> > ---------------
> > "wakeup-source" only describes that the controller is capable of
> > waking up the system (see
> > Documentation/devicetree/bindings/power/wakeup-source.txt), so with
> > this patch the driver only marks the device as wakeup capable, and
> > power/wakeup starts out "disabled". Users who NEED USB as a wakeup
> > source have to enable it:
> > 
> >   echo enabled > /sys/devices/.../<dwc3 device>/power/wakeup
> 

Thinh, thanks for reviewing it.

> That won't work in host mode.

At some platforms, USB2 wakeup logic works since there are
USB2 wakeup signal detection logic beyond controller and at SoC level.
For wakeup signal detected by controller, you are right, it needs
to enable controller level wakeup option, eg, WKCN/WKDN at PORTSC.

> dwc->sys_wakeup is read only once in
> dwc3_core_probe(), so enabling wakeup later from sysfs won't reach the
> xhci-plat device, and xhci_suspend() clears the port wake bits. Moving
> the wakeup setup before dwc3_core_probe() won't work either, since
> wakeup is off at that point. The setting needs to be passed to xhci at
> suspend time (perhaps in dwc3_pm_prepare()?).
> 

When talking about whole system wakeup chain for USB:
dwc3 -> xhci-plat -> roothub -> downstream device
it usually depends on user program (per user option), but not bind to
kernel driver, considering some situations that USB device are disconnected
and re-connected, its wakeup option may need to re-set, and one typical
solution is enable wakeup options before system suspend.

> 
> > 
> > Comparison
> > ----------
> >                        Current (default on)       Proposed (default off)
> >                        --------------------       ----------------------
> > Initial power/wakeup   enabled                    disabled
> > User action            write "disabled" if USB    write "enabled" if USB
> >                        wakeup is NOT wanted       wakeup IS wanted
> > Unexpected wakeups     possible (connect,         none unless the user
> >                        disconnect, noise)         opted in
> > Suspend power          higher, even if USB        lower, USB fully powered
> >                        wakeup is never used       off
> > Attached devices on    stay suspended, resume     reset-resumed or
> > resume                 quickly                    re-enumerated
> > 
> > Possible regression
> > -------------------
> 
> This rings my alarm bells for me any time we mention a user behavior
> change or possible regression. Perhaps you can add this to the commit
> message.
> 

Sure.

> > This is a user-visible change for existing platforms. Many Qualcomm
> > arm64 DTs set "wakeup-source" on the USB controller. With this patch:
> > 
> > - USB wakeup stops working until userspace (or a udev rule) writes
> >   "enabled" to the controller's power/wakeup.
> > 
> > - In host mode, because device_may_wakeup() is now false by default,
> 
> This will be the default in host mode for every qcom platform with
> "wakeup-source". Which platforms have you tested?
> 

Yes, it affects all Qcom platforms, that's why I sent RFC patch for it
last week, most probably it have "regression" since it may never
be tested under the situation the PHY is powered down at suspend and
power on at resume, but that kinds of "regression" is the bug we need
to fix, right?

I have tested at Glymur CRD, external ports work (USB3/USB2), but
the port with USB2 Footprint IC (USB2) hard-wired does not work
sometimes, maybe the initial sequence between power-on and suspend/resume
are different, it needs to debug more.

> >   system suspend takes the full power down path in
> >   dwc3_suspend_common() (dwc3_core_exit()). Platforms where this
> >   power down path has not been tested may fail to resume.
> > 
> 

-- 

Thanks,
Peter Chen