linux-kernel - Re: [PATCH v15 0/6] usb: misc: Add onboard_usb

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: <CAA8EJpq55e+fk9oDi8+JXDWiPcXDXK5oz1DL5eqfx+FkT-xhnw@mail.gmail.com>
Date:   Tue, 19 Oct 2021 19:24:41 +0300
From:   Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To:     Matthias Kaehlcke <mka@...omium.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Alan Stern <stern@...land.harvard.edu>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Mathias Nyman <mathias.nyman@...el.com>,
        Felipe Balbi <balbi@...nel.org>,
        Bastien Nocera <hadess@...ess.net>,
        Peter Chen <peter.chen@...nel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Michal Simek <michal.simek@...inx.com>,
        open list <linux-kernel@...r.kernel.org>,
        Douglas Anderson <dianders@...omium.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        linux-usb@...r.kernel.org,
        Ravi Chandra Sadineni <ravisadineni@...omium.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Al Cooper <alcooperx@...il.com>,
        Andrey Zhizhikin <andrey.zhizhikin@...ca-geosystems.com>,
        Andy Gross <agross@...nel.org>,
        Aswath Govindraju <a-govindraju@...com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Dmitry Osipenko <digetx@...il.com>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        Fabio Estevam <festevam@...il.com>,
        Guido Günther <agx@...xcpu.org>,
        Jagan Teki <jagan@...rulasolutions.com>,
        Nishanth Menon <nm@...com>,
        Pawel Laszczak <pawell@...ence.com>,
        Roger Quadros <rogerq@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>, Vinod Koul <vkoul@...nel.org>,
        Will Deacon <will@...nel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "open list:DRM DRIVER FOR MSM ADRENO GPU" 
        <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v15 0/6] usb: misc: Add onboard_usb_hub driver

On Tue, 27 Jul 2021 at 03:41, Matthias Kaehlcke <mka@...omium.org> wrote:
>
> This series adds:
> - the onboard_usb_hub_driver
> - glue in the xhci-plat driver to create and destroy the
>   onboard_usb_hub platform devices if needed
> - a device tree binding for the Realtek RTS5411 USB hub controller
> - device tree changes that add RTS5411 entries for the QCA SC7180
>   based boards trogdor and lazor
> - a couple of stubs for platform device functions to avoid
>   unresolved symbols with certain kernel configs
>
> The main issue the driver addresses is that a USB hub needs to be
> powered before it can be discovered. For discrete onboard hubs (an
> example for such a hub is the Realtek RTS5411) this is often solved
> by supplying the hub with an 'always-on' regulator, which is kind
> of a hack. Some onboard hubs may require further initialization
> steps, like changing the state of a GPIO or enabling a clock, which
> requires even more hacks. This driver creates a platform device
> representing the hub which performs the necessary initialization.
> Currently it only supports switching on a single regulator, support
> for multiple regulators or other actions can be added as needed.
> Different initialization sequences can be supported based on the
> compatible string.

I have the feeling that you might want to check if you can use pwrseq
subsystem being proposed at
https://lore.kernel.org/linux-arm-msm/20211006035407.1147909-1-dmitry.baryshkov@linaro.org/.
It has been created for exactly the same reason of handling complex
power up/down requirements in a bus-neutral way. So instead of
creating an onboard-usb-hub, you might want to populate the hub node
with the reference to pwrseq device and make usb core call into
pwrseq. How does that sound to you?

>
> Besides performing the initialization the driver can be configured
> to power the hub off during system suspend. This can help to extend
> battery life on battery powered devices which have no requirements
> to keep the hub powered during suspend. The driver can also be
> configured to leave the hub powered when a wakeup capable USB device
> is connected when suspending, and power it off otherwise.


-- 
With best wishes
Dmitry