linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Matthias Kaehlcke <mka@chromium.org>
Cc: Doug Anderson <dianders@chromium.org>,
	Rob Herring <robh@kernel.org>,
	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: Tue, 6 Oct 2020 21:00:23 -0400	[thread overview]
Message-ID: <20201007010023.GA438733@rowland.harvard.edu> (raw)
In-Reply-To: <20201006192536.GB191572@google.com>

On Tue, Oct 06, 2020 at 12:25:36PM -0700, Matthias Kaehlcke wrote:
> On Tue, Oct 06, 2020 at 01:15:24PM -0400, Alan Stern wrote:
> > You don't need a platform device or a new driver to do this.  The code 
> > can go in the existing hub driver.
> 
> Maybe. IIUC currently USB drivers don't support/use suspend_late. Could that
> be added? It would simplify matters, otherwise all hubs need to know their
> peers and check in suspend if they are the last hub standing, only then the
> power can be switched off. It would be simpler if a single instance (e.g. the
> hub with the DT entries) is in control.

Adding suspend_late would be a little painful.  But you don't really 
need it; you just need to make the "master" hub wait for its peer to 
suspend, which is easy to do.

And hubs would need to know their peers in any case, because you have to 
check if any devices attached to the peer have wakeup enabled.

> > Incidentally, the peering information is already present in sysfs, 
> > although it is associated with a device's port on its upstream hub 
> > rather than with the device itself.
> 
> That might also help the hub driver to determine its peers without needing the
> 'companion-hubs' property.

It wouldn't hurt to have that property anyway.  The determination of 
peer ports doesn't always work right, because it depends on information 
provided by the firmware and that information isn't always correct.

Alan Stern

  reply	other threads:[~2020-10-07  1: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
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 [this message]
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=20201007010023.GA438733@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --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=robh@kernel.org \
    --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).