linux-kernel - RE: [PATCH 2/2] 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: <AM7PR04MB7157872B1019B748119B7DBA8B3E0@AM7PR04MB7157.eurprd04.prod.outlook.com>
Date:   Thu, 17 Sep 2020 01:24:30 +0000
From:   Peter Chen <peter.chen@....com>
To:     Matthias Kaehlcke <mka@...omium.org>
CC:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Alan Stern <stern@...land.harvard.edu>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Bastien Nocera <hadess@...ess.net>,
        Ravi Chandra Sadineni <ravisadineni@...omium.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        Stephen Boyd <swboyd@...omium.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Douglas Anderson <dianders@...omium.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Alexander A. Klimov" <grandmaster@...klimov.de>,
        Masahiro Yamada <masahiroy@...nel.org>
Subject: RE: [PATCH 2/2] USB: misc: Add onboard_usb_hub driver

> > >
> >
> > You may need both (glue & xhci), it depends on system design, and
> > usually, these two kinds of wakeup setting isn't conflict.
> 
> Ok, thanks. So if I understand correctly the onboard hub driver should check the
> wakeup state of the xHCI to determine if remote wakeup is enabled for the
> controller (after all it doesn't know anything about the platform device).
> Wakeup might not work properly if it is disabled for the platform device, but it's
> the responsability of the board software/config to make sure it is enabled
> (possibly this could be done by making the dwc3-qcom driver understand the
> 'wakeup-source' property, as the xhci-mtk driver does).

No, every level should handle its own wakeup setting. You may have to do this since the USB bus and platform bus
are two different buses, you should not visit device structure across the bus. And you don't need a device tree property
to do it. For platform driver, you could use device_may_wakeup, for onboard hub power driver, you could use
usb_wakeup_enabled_descendants since you need to cover descendants.

The purpose of these two wakeup logic is different, for USB bus, it is used to tell USB devices to enable remote wakeup
and do not power off its regulator; for platform bus, it is used to tell the controller to enable its wakeup setting and keep
the regulator for its USB controller and USB PHY (if needed).

Peter