From: Matthias Kaehlcke <mka@chromium.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Peter Chen <peter.chen@nxp.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Krzysztof Kozlowski <krzk@kernel.org>,
Bastien Nocera <hadess@hadess.net>,
Ravi Chandra Sadineni <ravisadineni@chromium.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
Stephen Boyd <swboyd@chromium.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Douglas Anderson <dianders@chromium.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Alexander A. Klimov" <grandmaster@al2klimov.de>,
Masahiro Yamada <masahiroy@kernel.org>
Subject: Re: [PATCH 2/2] USB: misc: Add onboard_usb_hub driver
Date: Wed, 16 Sep 2020 12:27:15 -0700 [thread overview]
Message-ID: <20200916192715.GC3560556@google.com> (raw)
In-Reply-To: <20200916021421.GA1024554@rowland.harvard.edu>
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).
next prev parent reply other threads:[~2020-09-16 19:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-14 18:27 [PATCH 1/2] dt-bindings: usb: Add binding for onboard USB hubs Matthias Kaehlcke
2020-09-14 18:27 ` [PATCH 2/2] USB: misc: Add onboard_usb_hub driver Matthias Kaehlcke
2020-09-14 19:52 ` Matthias Kaehlcke
2020-09-14 20:14 ` Alan Stern
2020-09-14 21:14 ` Matthias Kaehlcke
2020-09-15 2:55 ` Peter Chen
2020-09-15 5:02 ` Matthias Kaehlcke
2020-09-15 7:05 ` Peter Chen
2020-09-15 23:03 ` Matthias Kaehlcke
2020-09-16 2:14 ` Alan Stern
2020-09-16 19:27 ` Matthias Kaehlcke [this message]
2020-09-16 8:19 ` Peter Chen
2020-09-16 19:16 ` Matthias Kaehlcke
2020-09-17 0:27 ` Peter Chen
2020-09-17 0:47 ` Matthias Kaehlcke
2020-09-17 1:24 ` Peter Chen
2020-09-17 15:54 ` Matthias Kaehlcke
2020-09-15 14:21 ` [PATCH 1/2] dt-bindings: usb: Add binding for onboard USB hubs Rob Herring
2020-09-16 0:00 ` Matthias Kaehlcke
2020-09-18 16:05 ` Rob Herring
2020-09-22 23:39 ` Matthias Kaehlcke
2020-09-15 14:21 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200916192715.GC3560556@google.com \
--to=mka@chromium.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=frowand.list@gmail.com \
--cc=grandmaster@al2klimov.de \
--cc=gregkh@linuxfoundation.org \
--cc=hadess@hadess.net \
--cc=krzk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=peter.chen@nxp.com \
--cc=ravisadineni@chromium.org \
--cc=robh+dt@kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=swboyd@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).