From: Alan Stern <email@example.com>
To: Matthias Kaehlcke <firstname.lastname@example.org>
Cc: Rob Herring <email@example.com>,
Doug Anderson <firstname.lastname@example.org>,
Greg Kroah-Hartman <email@example.com>,
Frank Rowand <firstname.lastname@example.org>,
Linux USB List <email@example.com>,
Bastien Nocera <firstname.lastname@example.org>,
Stephen Boyd <email@example.com>,
Ravi Chandra Sadineni <firstname.lastname@example.org>,
Krzysztof Kozlowski <email@example.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<firstname.lastname@example.org>, Peter Chen <email@example.com>
Subject: Re: [PATCH v4 1/2] dt-bindings: usb: Add binding for discrete onboard USB hubs
Date: Fri, 2 Oct 2020 14:48:47 -0400 [thread overview]
Message-ID: <20201002184847.GB296334@rowland.harvard.edu> (raw)
On Fri, Oct 02, 2020 at 09:08:47AM -0700, Matthias Kaehlcke wrote:
> On Thu, Oct 01, 2020 at 09:21:53PM -0400, Alan Stern wrote:
> > On Thu, Oct 01, 2020 at 02:54:12PM -0700, Matthias Kaehlcke wrote:
> > > Hi,
> > >
> > > thanks for providing more insights on the USB hardware!
> > Sure.
> > > On Wed, Sep 30, 2020 at 09:24:13PM -0400, Alan Stern wrote:
> > > > A hub that attaches only to the USB-3 data wires in a cable is not USB
> > > > compliant. A USB-2 device plugged into such a hub would not work.
> > > >
> > > > But ports can be wired up in weird ways. For example, it is possible
> > > > to have the USB-3 wires from a port going directly to the host
> > > > controller, while the USB-2 wires from the same port go through a
> > > > USB-2 hub which is then connected to a separate host controller. (In
> > > > fact, my office computer has just such an arrangement.)
> > >
> > > It's not clear to me how this case would be addressed when (some of) the
> > > handling is done in xhci-plat.c We have two host controllers now, which one
> > > is supposed to be in charge? I guess the idea is to specify the hub only
> > > for one of the controllers?
> > I don't grasp the point of this question. It doesn't seem to be
> > relevant to the case you're concerned about -- your board isn't going to
> > wire up the special hub in this weird way, is it?
> When doing upstream development I try to look beyond my specific use case
> and aim for solutions that are generally useful.
> I don't know how common a configuration like the one on your office computer
> is. If it isn't a fringe case it seems like we should support it if feasible.
It isn't very common. I think it was probably adopted as a stopgap kind
of approach at a time when USB-3 was still relatively new and the
chipsets didn't yet have full support for it. On the other hand, it
certainly isn't unheard of and it is compliant with the spec.
Of course, on any system that does this, the designers will be aware of
it and could add the appropriate description (whatever it turns out to
be) to DT.
> > _All_ of the handling could be done by xhci-plat. Since the xHCI
> > controller is the parent of both the USB-2 and USB-3 incarnations of
> > the special hub, it won't get suspended until they are both in
> > suspend, and it will get resumed before either of them. Similarly,
> > the power to the special hub could be switched on as part of the host
> > controller's probe routine and switched off during the host
> > controller's remove routine.
> > Using xhci-plat in this way would be better than a dedicated driver in
> > the sense that it wouldn't then be necessary to make up a fictitious
> > platform device and somehow describe it in DT.
> > The disadvantage is that we would end up with a driver that's
> > nominally meant to handle host controllers but now also manages (at
> > least in part) hubs. A not-so-clean separation of functions. But
> > that's not terribly different from the way your current patch works,
> > right?
> Yes, this muddling of the xhci-plat code with the handling of hubs was
> one of my concerns, but who am I to argue if you as USB maintainer see
> that preferable over a dedicated driver. I suppose you are taking into
> account that there will be a need for code for different hub models that
> has to live somewhere (could be a dedicated file or directory).
This isn't really a difference in the hubs but rather in their support
circuitry. Still, if you look through the various *-platform.c files in
drivers/usb/host (and also in pci-quirks.c), you'll see plenty of
examples of platform-specific code for particular devices.
Ideally the new code would go into the hub driver. But that won't work,
since the hub driver doesn't get involved until the hub has been
discovered on the USB bus, and that won't happen until its power has
> And even if it is not my specific use case it would be nice to support
> hubs that are part of a hierarchy and not wired directly to the host
> controller. We don't necessarily have to implement all support for this
> initially, but should have it in mind at least for the bindings.
> Also we would probably lose the ability to use a sysfs attribute to
> configure whether the hub should be always powered during suspend or
> not. This could be worked around with a DT property, however DT
> maintainers tend to be reluctant about configuration entries that
> don't translate directly to the hardware.
In theory the sysfs attribute could go under the host controller, but I
agree it would be awkward.
This is just one example of a more general problem, as I mentioned in a
recent email to Doug Anderson.
next prev parent reply other threads:[~2020-10-02 18:48 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
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 [this message]
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
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).