devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Rob Herring <robh@kernel.org>
Cc: Matthias Kaehlcke <mka@chromium.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Frank Rowand <frowand.list@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Linux USB List <linux-usb@vger.kernel.org>,
	Bastien Nocera <hadess@hadess.net>,
	Stephen Boyd <swboyd@chromium.org>,
	Ravi Chandra Sadineni <ravisadineni@chromium.org>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>, Peter Chen <peter.chen@nxp.com>
Subject: Re: [PATCH v4 1/2] dt-bindings: usb: Add binding for discrete onboard USB hubs
Date: Wed, 30 Sep 2020 11:00:39 -0700	[thread overview]
Message-ID: <CAD=FV=WhowcppEhmd=QG7YFk5iSVaCKsfGJkGBQJTwMs=bwekA@mail.gmail.com> (raw)
In-Reply-To: <CAD=FV=WcDzgcHNn1+gH+gq_WEwpD0XXdJGm2fBVpAB=3fVbzZA@mail.gmail.com>

Hi,

> On Wed, Sep 30, 2020 at 7:44 AM Rob Herring <robh@kernel.org> wrote:
> >
> > We already have hubs in DT. See [1][2][3][4]. What's new here?

After I sent my response I kept thinking about this and I realized
that I have prior art I can point out too!  :-)  Check out
"smsc,usb3503a".  That is describing a USB hub too and, at least on
"exynos5250-spring.dts" is is a top level node.  Since "smsc,usb3503a"
can be optionally connected to an i2c bus too, it could be listed
under an i2c controller as well (I believe it wasn't hooked up to i2c
on spring).

Interestingly enough, the USB Hub that Matthias is trying to add
support for can _also_ be hooked up to i2c.  We don't actually have
i2c hooked up on our board, but conceivably it could be.  Presumably,
if i2c was hooked up, we would have no other choice but to represent
this chip as several device tree nodes: at least one under the i2c
controller and one (or two) under the USB controller.  Just because
(on this board) i2c isn't hooked up doesn't change the fact that there
is some extra control logic that could be represented in its own
device tree node.  To me, this seems to give extra evidence that the
correct way to model this device in device tree is with several nodes.

I'll point out that on "exynos5250-spring.dts" we didn't have to solve
the problem that Matthias is trying to solve here because we never
actually supported waking up from USB devices there.  Thus the
regulator for the hub on spring can be unconditionally powered off in
suspend.  On newer boards we'd like to support waking up from USB
devices but also to save power if no wakeup devices are plugged into
USB.  In order to achieve this we need some type of link from the
top-level hub device to the actual USB devices that were enumerated.

-Doug

  reply	other threads:[~2020-09-30 18:00 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-28 17:13 [PATCH v4 1/2] dt-bindings: usb: Add binding for discrete onboard USB hubs Matthias Kaehlcke
2020-09-28 17:13 ` [PATCH v4 2/2] USB: misc: Add onboard_usb_hub driver Matthias Kaehlcke
2020-09-28 18:47   ` Alan Stern
2020-09-29  1:43     ` Matthias Kaehlcke
2020-09-29 16:00       ` Alan Stern
2020-09-29 16:50         ` Matthias Kaehlcke
2020-09-28 22:03   ` Doug Anderson
2020-09-29  1:59     ` Matthias Kaehlcke
2020-09-28 22:13 ` [PATCH v4 1/2] dt-bindings: usb: Add binding for discrete onboard USB hubs Doug Anderson
2020-09-29  2:14   ` Matthias Kaehlcke
2020-09-29 20:17 ` Rob Herring
2020-09-29 22:09   ` Matthias Kaehlcke
2020-09-30  1:32     ` Alan Stern
2020-09-30 12:49       ` Matthias Kaehlcke
2020-09-30 14:44         ` Rob Herring
2020-09-30 15:28           ` Doug Anderson
2020-09-30 18:00             ` Doug Anderson [this message]
2020-09-30 19:19               ` Rob Herring
2020-10-01 21:39                 ` Matthias Kaehlcke
2020-09-30 19:19             ` Alan Stern
2020-09-30 20:20             ` Rob Herring
2020-10-01  1:24               ` Alan Stern
2020-10-01 21:54                 ` Matthias Kaehlcke
2020-10-02  1:21                   ` Alan Stern
2020-10-02 16:08                     ` Matthias Kaehlcke
2020-10-02 18:48                       ` Alan Stern
2020-10-02 17:08               ` Doug Anderson
2020-10-02 18:36                 ` Alan Stern
2020-10-02 22:58                   ` Rob Herring
2020-10-03 12:41                     ` Alan Stern
2020-10-05 16:06                       ` Matthias Kaehlcke
2020-10-05 16:15                         ` Alan Stern
2020-10-05 19:18                           ` Matthias Kaehlcke
2020-10-05 19:36                             ` Alan Stern
2020-10-05 19:59                               ` Rob Herring
2020-10-05 23:29                                 ` Matthias Kaehlcke
2020-10-05 19:36                             ` Rob Herring
2020-10-05 19:20                         ` Rob Herring
2020-10-02 22:28                 ` Rob Herring
2020-10-02 23:09                   ` Doug Anderson
2020-10-06  0:45                     ` Matthias Kaehlcke
2020-10-06 14:18                       ` Alan Stern
2020-10-06 16:59                         ` Matthias Kaehlcke
2020-10-06 17:15                           ` Alan Stern
2020-10-06 19:25                             ` Matthias Kaehlcke
2020-10-07  1:00                               ` Alan Stern
2020-10-07 16:03                                 ` Matthias Kaehlcke
2020-10-07 16:38                                   ` Alan Stern
2020-10-07 17:28                                     ` Matthias Kaehlcke
2020-10-07 19:25                                       ` Alan Stern
2020-10-07 19:42                                         ` Matthias Kaehlcke
2020-10-07 20:17                                           ` Alan Stern
2020-10-07 21:42                                             ` Matthias Kaehlcke
2020-10-08 14:09                                               ` Alan Stern
2020-10-09 23:13                                                 ` Matthias Kaehlcke

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='CAD=FV=WhowcppEhmd=QG7YFk5iSVaCKsfGJkGBQJTwMs=bwekA@mail.gmail.com' \
    --to=dianders@chromium.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --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=mka@chromium.org \
    --cc=peter.chen@nxp.com \
    --cc=ravisadineni@chromium.org \
    --cc=robh@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).