linux-kernel - RE: [PATCH v2 3/3] dt-bindings: phy: realtek: Add the doc about the Realtek SoC USB 2.0/3.0 PHY

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: <44015844858c42a79e0e7f9207d01496@realtek.com>
Date:   Tue, 30 May 2023 03:08:29 +0000
From:   Stanley Chang[昌育德] <stanley_chang@...ltek.com>
To:     Conor Dooley <conor@...nel.org>
CC:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Vinod Koul <vkoul@...nel.org>,
        Kishon Vijay Abraham I <kishon@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Alan Stern <stern@...land.harvard.edu>,
        Flavio Suligoi <f.suligoi@...m.it>,
        Mathias Nyman <mathias.nyman@...ux.intel.com>,
        Douglas Anderson <dianders@...omium.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        Ray Chi <raychi@...gle.com>,
        Michael Grzeschik <m.grzeschik@...gutronix.de>,
        "linux-phy@...ts.infradead.org" <linux-phy@...ts.infradead.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>
Subject: RE: [PATCH v2 3/3] dt-bindings: phy: realtek: Add the doc about the Realtek SoC USB 2.0/3.0 PHY

Hi Conor,

> > +properties:
> > +  compatible:
> > +    enum:
> > +      - realtek,usb2phy
> > +      - realtek,rtd-usb2phy
> > +      - realtek,rtd1295-usb2phy
> > +      - realtek,rtd1395-usb2phy
> > +      - realtek,rtd1619-usb2phy
> > +      - realtek,rtd1319-usb2phy
> > +      - realtek,rtd1619b-usb2phy
> > +      - realtek,rtd1312c-usb2phy
> > +      - realtek,rtd1319d-usb2phy
> > +      - realtek,rtd1315e-usb2phy

> > +properties:
> > +  compatible:
> > +    enum:
> > +      - realtek,usb3phy
> > +      - realtek,rtd-usb3phy
> > +      - realtek,rtd1295-usb3phy
> > +      - realtek,rtd1619-usb3phy
> > +      - realtek,rtd1319-usb3phy
> > +      - realtek,rtd1619b-usb3phy
> > +      - realtek,rtd1319d-usb3phy

> Ignoring everything else, because I really want Krzysztof or Rob to
> review this rather than me, but what's going on here with the
> compatibles?
> What hardware do "usbNphy" and "rtd-usbNphy" represent?
> 
> You have device-specific compatibles, which is great, but you also allow
> only those two generic ones. I had a _brief_ look at the driver, and it
> seems like there is no decision making done based on the compatibles,
> only on the properties. Is that correct?
> If it is, I would understand having "realtek,usb3phy" as a fallback
> compatible for "realtek,rtd1619-usb3phy", but I do not get the current
> setup.

This driver is compatible with all Realtek RTD SoCs without specifying different settings.
So use "realtek,usb3phy" as fallback compatible for all SoCs.
This is the compatible name we use.
Other compatible names simply indicate that the driver supports the SoCs.

The name "usbNphy" and "rtd-usbNphy" seem to be more generic for all RTD SoCs,
but they are not device-specific compatible.
Do you have a better suggestion?

> 
> Also, I really think this should be broken down into two patches, one
> for each of USB 2 & 3.

Okay, I will split to two patches.

Thanks,
Stanley