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]

Message-ID: <20201006165957.GA191572@google.com>
Date:   Tue, 6 Oct 2020 09:59:57 -0700
From:   Matthias Kaehlcke <mka@...omium.org>
To:     Alan Stern <stern@...land.harvard.edu>
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 Tue, Oct 06, 2020 at 10:18:20AM -0400, Alan Stern wrote:
> On Mon, Oct 05, 2020 at 05:45:10PM -0700, Matthias Kaehlcke wrote:
> > I did some prototyping, it seems a binding like this would work for
> > case a) or b):
> > 
> > &usb_1_dwc3 {
> >         hub_2_0: hub@1 {
> >                 compatible = "usbbda,5411";
> >                 reg = <1>;
> > 	};
> > 
> >         hub_3_0: hub@2 {
> >                 compatible = "usbbda,411";
> >                 reg = <2>;
> >                 vdd-supply = <&pp3300_hub>;
> > 		companion-hubs = <&hub_2_0>;
> >         };
> > };
> > 
> > It still requires specifying both hubs (which reflects the actual wiring).
> > Supporting something like "reg = <1 2>" seems more complex due to the need to
> > obtain the hub USB device at runtime (a DT node makes that trivial), possibly
> > this could be solved by adding new APIs.
> > 
> > In terms of implementation would I envision to keep a platform driver. This
> > would keep the hubby parts out of xhci-plat (except for populating the platform
> > devices), support systems with cascaded hubs and provide a device for the sysfs
> > attribute.
> 
> What will you do if a system has more than one of these power-regulated 
> hubs?  That is, how will the user know which platform device handles the 
> power control for a particular hub (and vice versa)?  You'd probably 
> have to create a pair of symlinks going back and forth in the sysfs 
> directories.

The platform device would use the same DT node as the USB device, hence the
sysfs path of the platform device could be derived from the DT.

> Wouldn't it be easier to put the power-control attribute directly in the 
> hub's sysfs directory (or .../power subdirectory)?

Not sure. In terms of implementation it would be more complex (but not rocket
science either), from a userspace perspective there are pros and cons.

A platform driver (or some other control instance) is needed anyway, to check
the connected devices on both hubs and cut power only after the USB devices
are suspended. With the sysfs attribute associated with the platform device
it wouldn't even be necessary to have a separate USB driver. The platform
driver would have to evaluate the sysfs attribute of the USB device(s), which
can be done but is a bit odd.

For a user it might be slightly simpler if they don't have to care about the
existence of a platform device (but it's just a matter of knowing). The
attribute must only be associated with one of the USB devices, which might
be confusing, however it would be messy if each hub had an attribute. The
attribute could be only associated with the 'primary hub', i.e. the one that
specifies 'vdd-supply' or other attributes needed by the driver.