linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Doug Anderson <dianders@chromium.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 14:19:32 -0500	[thread overview]
Message-ID: <CAL_Jsq+mzUV53U1h6YixT=d+Q6oouNNNeFGHvpauMh054x-3Jg@mail.gmail.com> (raw)
In-Reply-To: <CAD=FV=WhowcppEhmd=QG7YFk5iSVaCKsfGJkGBQJTwMs=bwekA@mail.gmail.com>

On Wed, Sep 30, 2020 at 1:00 PM Doug Anderson <dianders@chromium.org> wrote:
>
> 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.

Yes, in a prior version I mentioned we already had 2 ways to describe
hubs. I view this as a 3rd way.

There's prior art in how we reference an i2c bus for a slave device
that's already on another bus. That's 'i2c-bus' and 'ddc-i2c-bus'. But
that's not really this case.

Rob

  reply	other threads:[~2020-09-30 19:19 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
2020-09-30 19:19               ` Rob Herring [this message]
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='CAL_Jsq+mzUV53U1h6YixT=d+Q6oouNNNeFGHvpauMh054x-3Jg@mail.gmail.com' \
    --to=robh@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.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=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).