linux-kernel - Re: [PATCH v2 03/22] usb: ulpi: Support device discovery via device properties

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] [day] [month] [year] [list]

Date:   Tue, 23 Aug 2016 18:06:31 -0700
From:   Stephen Boyd <stephen.boyd@...aro.org>
To:     Rob Herring <robh@...nel.org>
Cc:     Linux USB List <linux-usb@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Andy Gross <andy.gross@...aro.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Neil Armstrong <narmstrong@...libre.com>,
        Arnd Bergmann <arnd@...db.de>, Felipe Balbi <balbi@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v2 03/22] usb: ulpi: Support device discovery via device properties

On Tue, Aug 23, 2016 at 4:06 PM, Rob Herring <robh@...nel.org> wrote:
> On Tue, Aug 23, 2016 at 3:00 PM, Stephen Boyd <stephen.boyd@...aro.org> wrote:
>> On Fri, Aug 5, 2016 at 2:40 PM, Stephen Boyd <stephen.boyd@...aro.org> wrote:
>>> Quoting Rob Herring (2016-07-17 19:23:55)
>>>> On Thu, Jul 07, 2016 at 03:20:54PM -0700, Stephen Boyd wrote:
>>>> > +-------
>>>> > +
>>>> > +usb {
>>>> > +     compatible = "vendor,usb-controller";
>>>> > +
>>>> > +     ulpi {
>>>> > +             phy {
>>>> > +                     compatible = "vendor,phy";
>>>> > +                     ulpi-vendor = /bits/ 16 <0x1d6b>;
>>>> > +                     ulpi-product = /bits/ 16 <0x0002>;
>>>> > +             };
>>>> > +     };
>>>>
>>>> I'm still having concerns about describing both phys and devices. If I
>>>> have a controller with 2 ports and 2 devices attached, I'd have
>>>> something like this under the USB controller:
>>>>
>>>> ulpi {
>>>>         phy@1 {
>>>>         };
>>>>         phy@2 {
>>>>         };
>>>> };
>>>
>>> My understanding is there would only be one status="ok" node on the ULPI
>>> bus for the single phy that a usb controller would have. At the least,
>>> the kernel's ULPI layer only seems to support one ULPI phy for a
>>> controller right now. So even if there are two ports, it doesn't mean
>>> there are two phys.
>>>
>>>>
>>>> dev@1 {
>>>> ...
>>>> };
>>>>
>>>> dev@2 {
>>>> ...
>>>> };
>>>>
>>>>
>>>> That doesn't seem the best, but I don't have a better suggestion. Maybe
>>>> the device nodes need to go under the phy nodes?
>>>>
>>>
>>> What if we moved the dev@1 and dev@2 to another sub node like "ports" or
>>> "usb-devices"? Legacy code can support having those devices directly
>>> underneath the usb controller, but future users would always need to put
>>> them in a different sub-node so that we can easily differentiate the
>>> different busses that a usb controller node may support?
>>>
>>> I'm not sure I see any need to relate the phy to the ports that are on
>>> the controller, but if that is needed then perhaps you're right and we
>>> should move the ports underneath the phy. USB core could be modified to
>>> go through the legacy path or through the phy, if it even exists, to
>>> find ports.
>>>
>>> Do we typically do this for other phy designs like sata or pci? The phy
>>> always seemed like a parallel thing to the logical bus that the phy is
>>> used for.
>>
>> Rob does this sound ok to you?
>
> Well, if there's only ever 1 phy under the controller, then as you had
> it is fine.
>

Ok. For ULPI I believe that's the case, but in general usb controllers
can have more than one phy.