linux-kernel - Re: [PATCH net-next v3 01/47] dt-bindings: phy: Add Lynx 10G phy binding

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: <3a255b33-ae5b-0e2e-d1d0-0ac9548c5837@seco.com>
Date:   Tue, 26 Jul 2022 11:44:56 -0400
From:   Sean Anderson <sean.anderson@...o.com>
To:     Rob Herring <robh@...nel.org>
Cc:     "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Madalin Bucur <madalin.bucur@....com>,
        netdev <netdev@...r.kernel.org>, Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Russell King <linux@...linux.org.uk>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Kishon Vijay Abraham I <kishon@...com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Vinod Koul <vkoul@...nel.org>, devicetree@...r.kernel.org,
        "open list:GENERIC PHY FRAMEWORK" <linux-phy@...ts.infradead.org>
Subject: Re: [PATCH net-next v3 01/47] dt-bindings: phy: Add Lynx 10G phy
 binding

Hi Rob,

On 7/21/22 7:35 PM, Sean Anderson wrote:
> What about
> 
> 	phys = <&serdes1_lane1>;
> 
> and then under the serdes node do something like
> 
> 	serdes1: phy@foo {
> 		...
> 
> 		serdes1_lane1 {
> 			first-lane = <1>;
> 
> 			sgmii {
> 				fsl,pccr = <0x8>;
> 				fsl,idx = <2>;
> 				fsl,cfg = <1>;
> 				fsl,proto = "sgmii";
> 				// or PHY_TYPE_SGMII
> 			};
> 
> 			qsgmii {
> 				...
> 			};
> 
> 			xfi {
> 				...
> 			};
> 		};
> 	};
> 
> and this way you could have something like a fsl,reserved property to
> deal with not-yet-supported lanes. And this could be added piecemeal by
> board configs.

Does this sound good? I would like to start working on v4 of this series,
and reworking the binding will be a big part of that. Am I heading in the
right direction? This seems to be a more common approach (e.g. mediatek,tphy).

--Sean