On Tue, Sep 15, 2020 at 10:14:21PM -0400, Alan Stern wrote: > On Tue, Sep 15, 2020 at 04:03:45PM -0700, Matthias Kaehlcke wrote: > > Hi Peter, > > > > On Tue, Sep 15, 2020 at 07:05:38AM +0000, Peter Chen wrote: > > > > Whether or not it is a wakeup_source, it could get through its or its children's > > > /sys/../power/wakeup value, you have already used usb_wakeup_enabled_descendants > > > to know it. > > > > I conceptually agree, but in practice there are some conflicting details: > > > > wakeup for the hubs on my system is by default disabled, yet USB wakeup works > > regardless, so the flag doesn't really provide useful information. I guess we > > could still use it if there is no better way, but it doesn't seem ideal. > > The wakeup setting for USB hubs affects only the following events: port > connect, port disconnect, and port overcurrent. It does not refer to > forwarding wakeup requests from downstream USB devices; that is always > enabled. So maybe your wakeup flag really is accurate and you didn't > realize it. Thanks for the clarification! > > Similar for udev->bus->controller, according to sysfs it doesn't even have wakeup > > support. Please let me know if there is a reliable way to check if wakeup is > > enabled on the controller of a device. > > The host controller's sysfs wakeup setting should always be correct. If > it isn't, that indicates there is a bug in the host controller driver or > the corresponding platform-specific code. Good to know :) > What driver does your system use? The driver is dwc3-qcom, Peter pointed me to a patch he recently sent to add the missing wakeup entry (https://patchwork.kernel.org/patch/11717835/). It seems that should solve the problem, except for some confusion on my side about the wakeup flag of the xHCI device vs. that of the platform device (details in my reply to Peter).
