From: Matthias Kaehlcke <mka@chromium.org>
To: Peter Chen <peter.chen@nxp.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Alan Stern <stern@rowland.harvard.edu>,
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: Thu, 17 Sep 2020 08:54:03 -0700 [thread overview]
Message-ID: <20200917155403.GA21107@google.com> (raw)
In-Reply-To: <AM7PR04MB7157872B1019B748119B7DBA8B3E0@AM7PR04MB7157.eurprd04.prod.outlook.com>
On Thu, Sep 17, 2020 at 01:24:30AM +0000, Peter Chen wrote:
> > > >
> > >
> > > You may need both (glue & xhci), it depends on system design, and
> > > usually, these two kinds of wakeup setting isn't conflict.
> >
> > Ok, thanks. So if I understand correctly the onboard hub driver should check the
> > wakeup state of the xHCI to determine if remote wakeup is enabled for the
> > controller (after all it doesn't know anything about the platform device).
> > Wakeup might not work properly if it is disabled for the platform device, but it's
> > the responsability of the board software/config to make sure it is enabled
> > (possibly this could be done by making the dwc3-qcom driver understand the
> > 'wakeup-source' property, as the xhci-mtk driver does).
>
> No, every level should handle its own wakeup setting. You may have to do this since the USB bus and platform bus
> are two different buses, you should not visit device structure across the bus. And you don't need a device tree property
> to do it. For platform driver, you could use device_may_wakeup, for onboard hub power driver, you could use
> usb_wakeup_enabled_descendants since you need to cover descendants.
>
> The purpose of these two wakeup logic is different, for USB bus, it is used to tell USB devices to enable remote wakeup
> and do not power off its regulator; for platform bus, it is used to tell the controller to enable its wakeup setting and keep
> the regulator for its USB controller and USB PHY (if needed).
Sorry, I didn't express myself clearly. With the platform device I was
referring to the dwc3-qcom ('glue') in this case, which could check
it's own 'wakeup-source' attribute to enable wakeup at boot. The driver
currently enables wakeup statically. The onboard_hub driver is agnostic
of this device.
next prev parent reply other threads:[~2020-09-17 16:19 UTC|newest]
Thread overview: 23+ 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:32 ` kernel test robot
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
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 [this message]
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=20200917155403.GA21107@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.