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

Message-ID: <b18dcd60-8e14-4328-82b1-f4e5c75cfe96@solid-run.com>
Date: Wed, 24 Sep 2025 15:56:23 +0000
From: Josua Mayer <josua@...id-run.com>
To: Vladimir Oltean <vladimir.oltean@....com>, Rob Herring <robh@...nel.org>
CC: "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


Am 24.09.25 um 17:45 schrieb Vladimir Oltean:
> Hi Rob,
>
> On Wed, Sep 24, 2025 at 08:54:29AM -0500, Rob Herring wrote:
>>> +description: |
>> Don't need '|' if no formatting to preserve.
> Thanks, will drop.
>
>>> +  "#address-cells":
>>> +    const: 1
>>> +    description: "Address cells for child lane nodes"
>> You don't need generic descriptions of common properties.
> Ok, I'll also drop the description from #size-cells but keep it in
> #phy-cells (less obvious).
>
>>> +
>>> +  "#size-cells":
>>> +    const: 0
>>> +    description: "Size cells for child lane nodes"
>>> +
>>>    "#phy-cells":
>>> +    description: "Number of cells in PHY specifier (legacy binding only)"
>>>      const: 1
>>>  
>>> @@ -32,9 +124,51 @@ examples:
>>>      soc {
>>>        #address-cells = <2>;
>>>        #size-cells = <2>;
>>> -      serdes_1: phy@...0000 {
>>> -        compatible = "fsl,lynx-28g";
>>> +
>>> +      serdes_1: serdes@...0000 {
>>> +        compatible = "fsl,lx2160a-serdes1";
>>>          reg = <0x0 0x1ea0000 0x0 0x1e30>;
>>> -        #phy-cells = <1>;
>>> +        #address-cells = <1>;
>>> +        #size-cells = <0>;
>>> +
>>> +        phy@0 {
>>> +          reg = <0>;
>>> +          #phy-cells = <0>;
>>> +        };
>> 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


> It's not
> so clear. Compared to 8 phy providers, each with its OF node => much
> easier to structure and to understand.
>
> This is essentially what the discussion with Josua from v1 boils down to.