linux-kernel - Re: [PATCH 0/2] phy: microchip: lan966x: Allow to invert N and P signals

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251119192326.4bflaqkh4zvz2rib@skbuf>
Date: Wed, 19 Nov 2025 21:23:26 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Horatiu Vultur <horatiu.vultur@...rochip.com>
Cc: Vladimir Oltean <vladimir.oltean@....com>, vkoul@...nel.org,
	kishon@...nel.org, robh@...nel.org, krzk+dt@...nel.org,
	conor+dt@...nel.org, linux-phy@...ts.infradead.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	Daniel Golle <daniel@...rotopia.org>
Subject: Re: [PATCH 0/2] phy: microchip: lan966x: Allow to invert N and P
 signals

Sorry for the delay. This time I got it but I forgot to answer.

On Fri, Nov 14, 2025 at 11:34:11AM +0100, Horatiu Vultur wrote:
> > Would it be possible to leave the SerDes muxing alone (with its
> > #phy-cells = <2>) and just add the lane OF nodes as an extra? You can
> > add new support for phys = <&phandle_directly_to_lane>, but that
> > wouldn't remove the existing support.
> 
> So you were thinking something like this
> ---
> 	serdes: serdes@...2c000 {
> 		compatible = "microchip,lan966x-serdes";
> 		reg = <0xe202c000 0x9c>,
> 		      <0xe2004010 0x4>;
> 		#phy-cells = <2>;
> 
> 		serdes_lane_0 {
> 		    reg = <0>;
> 		};
> 	};
> 
> 	port0 {
> 		phys = <&serdes_lane_0>;
> 	};
> ---
> 
> Maybe it is just a silly idea but what about doing like this:
> ---
> 	serdes: serdes@...2c000 {
> 		compatible = "microchip,lan966x-serdes";
> 		reg = <0xe202c000 0x9c>,
> 		      <0xe2004010 0x4>;
> 		#phy-cells = <2>;
> 		status = "disabled";
> 
> 		serdes_lane_0 {
> 		    serdes-properties
> 		};
> 	};
> ---
> Then there is no change to the ports and then in the lan966x-serdes I
> will iterate over all the child nodes and read the properties for each
> lane.

Well, if you re-read my message I think we are saying the same thing,
but in reverse order.

"Would it be possible to leave the SerDes muxing alone ... and just add
the lane OF nodes as an extra?" <- this would be your "silly" idea where
serdes_lane_0 just holds reg = <0> and the polarity properties.

"You can add new support for phys = <&phandle_directly_to_lane>, but
that wouldn't remove the existing support." <- this would correspond
to the first example you gave, presented as "So you were thinking
something like this".

Actually, I wasn't saying you have to implement the first way, just that
you can optionally do that as well.

To expand on your example. The base SerDes device tree node would look
like this:

	serdes: serdes@...2c000 {
		compatible = "microchip,lan966x-serdes";
		reg = <0xe202c000 0x9c>,
		      <0xe2004010 0x4>;
		#phy-cells = <2>;

		serdes_lane_0: phy@0 {
			reg = <0>;
			#phy-cells = <1>;
			tx-polarity = <PHY_POL_INV>;
		};
	};

and you could reference it like this (i.e. keep everything the same in
the consumer as until now, to avoid breaking compatibility):

	port0 {
		phys = <&serdes 0 CU(0)>;
	};

or like this (following the principle - if you have an OF node for the
lane, why not allow it be the PHY provider):

	port0 {
		phys = <&serdes_lane_0 CU(0)>;
	};

Just be careful that transitioning existing boards from one phandle
format to the other is a breaking change (old kernels won't understand
the "phys" with just 1 #phy-cell).

> Anyway I can wait with this patch series until you get your changes in.

I will keep you copied to the patch set which I hope to send later today.