linux-kernel - Re: [PATCH phy 13/14] dt-bindings: phy: lynx-28g: add compatible strings per SerDes and instantiation

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: <20250905-pamperer-segment-ab89f0e9cdf8@spud>
Date: Fri, 5 Sep 2025 20:02:59 +0100
From: Conor Dooley <conor@...nel.org>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, linux-phy@...ts.infradead.org,
	Ioana Ciornei <ioana.ciornei@....com>,
	Vinod Koul <vkoul@...nel.org>,
	Kishon Vijay Abraham I <kishon@...nel.org>,
	linux-kernel@...r.kernel.org, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, devicetree@...r.kernel.org,
	Josua Mayer <josua@...id-run.com>
Subject: Re: [PATCH phy 13/14] dt-bindings: phy: lynx-28g: add compatible
 strings per SerDes and instantiation

On Fri, Sep 05, 2025 at 06:41:50PM +0300, Vladimir Oltean wrote:
> On Fri, Sep 05, 2025 at 10:29:33AM +0200, Krzysztof Kozlowski wrote:
> > >  properties:
> > >    compatible:
> > > -    enum:
> > > -      - fsl,lynx-28g
> > > +    oneOf:
> > > +      - items:
> > > +          - const: fsl,lynx-28g
> > 
> > Don't change that part. Previous enum was correct. You want oneOf and
> > enum.
> 
> Combining the feedback from Conor and Josua, I should only be permitting
> the use of "fsl,lynx-28g" as a fallback to "fsl,lx216{0,2}a-serdes{1,2}",
> or standalone. The description below achieves just that. Does it look ok
> to you?
> 
> properties:
>   compatible:
>     oneOf:
>       - enum:
>           - fsl,lx2160a-serdes1
>           - fsl,lx2160a-serdes2
>           - fsl,lx2160a-serdes3
>           - fsl,lx2162a-serdes1
>           - fsl,lx2162a-serdes2
>       - const: fsl,lynx-28g
>         deprecated: true

>       - items:
>           - const: fsl,lx2160a-serdes1
>           - const: fsl,lynx-28g
>         deprecated: true
>       - items:
>           - const: fsl,lx2160a-serdes2
>           - const: fsl,lynx-28g
>         deprecated: true
>       - items:
>           - const: fsl,lx2162a-serdes1
>           - const: fsl,lynx-28g
>         deprecated: true
>       - items:
>           - const: fsl,lx2162a-serdes2
>           - const: fsl,lynx-28g
>         deprecated: true

This doesn't really make sense, none of these are currently in use
right? Everything is just using fsl,lynx-28g right?
Adding new stuff and immediately marking it deprecated is a
contradiction, just don't add it at all if you don't want people using
it. Any users of it would be something you're going to retrofit in now,
so you may as well just retrofit to use what you want people to use
going forward, which has no fallbacks.

I didn't read the back and forth with Josua (sorry!) but is the fallback
even valid? Do those devices have a common minimum set of features that
they share?

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)