linux-kernel - Re: [PATCH v4 1/2] dt-bindings: usb: Add binding for discrete onboard USB hubs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 7 Oct 2020 12:38:38 -0400
From:   Alan Stern <stern@...land.harvard.edu>
To:     Matthias Kaehlcke <mka@...omium.org>
Cc:     Doug Anderson <dianders@...omium.org>,
        Rob Herring <robh@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Frank Rowand <frowand.list@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux USB List <linux-usb@...r.kernel.org>,
        Bastien Nocera <hadess@...ess.net>,
        Stephen Boyd <swboyd@...omium.org>,
        Ravi Chandra Sadineni <ravisadineni@...omium.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, Peter Chen <peter.chen@....com>
Subject: Re: [PATCH v4 1/2] dt-bindings: usb: Add binding for discrete
 onboard USB hubs

On Wed, Oct 07, 2020 at 09:03:36AM -0700, Matthias Kaehlcke wrote:
> On Tue, Oct 06, 2020 at 09:00:23PM -0400, Alan Stern wrote:
> > 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.
> 
> Ok, I wasn't sure if the hubs suspend asynchronously from each other. If they
> do it should indeed not be a problem to have the "master" wait for its peers.

Well, order of suspending is selectable by the user.  It can be either 
asynchronous or reverse order of device registration, which might pose a 
problem.  We don't know in advance which of two peer hubs will be 
registered first.  It might be necessary to introduce some additional 
explicit synchronization.

> > 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.
> 
> My concern was about all hubs (including 'secondaries') having to know their
> peers and check on each other, in the scenario we are now talking about only
> the "master" hub needs to know and check on its peers, which is fine.

Not all hubs would need this.  Only ones marked in DT as having a power 
regulator.

Alan Stern