linux-kernel - Re: [PATCH v2 phy 12/16] 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] [day] [month] [year] [list]

Message-ID: <20250925080317.2ocgybitliwddhcf@skbuf>
Date: Thu, 25 Sep 2025 11:03:17 +0300
From: Vladimir Oltean <vladimir.oltean@....com>
To: Josua Mayer <josua@...id-run.com>
Cc: Rob Herring <robh@...nel.org>,
	"linux-phy@...ts.infradead.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" <linux-kernel@...r.kernel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v2 phy 12/16] dt-bindings: phy: lynx-28g: add compatible
 strings per SerDes and instantiation

On Wed, Sep 24, 2025 at 03:56:23PM +0000, Josua Mayer wrote:
> >> There's really no difference between having child nodes 0-7 and 8 phy 
> >> providers vs. putting 0-7 into a phy cell arg and 1 phy provider. 
> >>
> >> The only difference I see is it is more straight-forward to determine 
> >> what lanes are present in the phy driver if the driver needs to know 
> >> that. But you can also just read all 'phys' properties in the DT with a 
> >> &serdes_1 phandle and determine that. Is that efficient? No, but you 
> >> have to do that exactly once and probably has no measurable impact.
> >>
> >> With that, then can't you simply just add a more specific compatible:
> >>
> >> compatible = "fsl,lx2160a-serdes1", "fsl,lynx-28g";
> >>
> >> Then you maintain some compatibility.
> >>
> >> Rob
> > With the patches that have been presented to you thus far -- yes, this
> > is the correct conclusion, there is not much of a difference. But this
> > is not all.
> >
> > If I want in the future to apply the properties from
> > Documentation/devicetree/bindings/phy/transmit-amplitude.yaml to just
> > one of the lanes, how would I do that with just 1 phy provider?
> I believe it is possible for a driver to create multiple phy objects
> during probe, and for the xlate function to return the correct one.
> 
> Then, whether you follow a phandle to the parent with 1 argument,
> or aÂ  phandle to the phy child with 0 arguments provides same results.
> 
> The driver already creates a phy object for each lane with:
> 
> phy = devm_phy_create(&pdev->dev, NULL, &lynx_28g_ops);
> 
> Once the second argument is changed to a valid lane node,
> it's properties will be accessible.
> 
> I prototyped this a while ago:
> https://github.com/SolidRun/lx2160a_build/blob/develop-ls-5.15.71-2.2.0/patches/linux/0030-phy-lynx-28g-add-support-for-device-tree-per-lane-ph.patch

Ok, so because I did not actually try to prototype this, it seems things
got mixed up in my head and I did not realize it would be possible to
keep forward compatibility of old kernels with new device trees as well.

Essentially, because #phy-cells = <1> goes into the top-level "serdes"
node, and #phy-cells = <0> goes into the child "phy" per-lane nodes, it
becomes possible to superimpose the legacy and the modern bindings onto
the same structure, and have compatible = "fsl,lx2160a-serdes1", "fsl,lynx-28g"
so that each kernel revision picks its own format in a way that doesn't
bother the other.

Because I do care about use cases such as bisections with the same (latest)
device tree blob, I can take this as an action item for v3 and keep bug
compatibility with "fsl,lynx-28g". What I said here:
https://lore.kernel.org/lkml/20250908093709.owcha6ypm5lqqdwz@skbuf/
about "fsl,lynx-28g" being unable to reject unsupported protocols on
SerDes #2 remains valid, but on the premise that it hasn't been a
practical problem for the current mainline users, it seems to not matter
regarding this decision.

For the next revision I will allow "fsl,lynx-28g" as a fallback
compatible for SerDes #1 and #2, but not #3 (i.e. the current mainline
users, but not more), and #phy-cells = <1> will be allowed to be present
in the top-level SerDes node only if "compatible" contains "fsl,lynx-28g".
Otherwise, we need to have #phy-cells = <0> in child "phy" nodes.

Is that ok with everyone?