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: <20251114103411.rzigaoictyinmx66@DEN-DL-M31836.microchip.com>
Date: Fri, 14 Nov 2025 11:34:11 +0100
From: Horatiu Vultur <horatiu.vultur@...rochip.com>
To: Vladimir Oltean <olteanv@...il.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

The 11/13/2025 18:30, Vladimir Oltean wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi Horatiu,
> 
> On Tue, Nov 11, 2025 at 10:50:16AM +0100, Horatiu Vultur wrote:
> > The 11/10/2025 13:42, Vladimir Oltean wrote:
> > >
> > > Hi Horatiu,
> >
> > Hi Vladimir,
> >
> > >
> > > On Mon, Nov 10, 2025 at 12:05:34PM +0100, Horatiu Vultur wrote:
> > > > Allow to invert the N and P signals of the Serdes for both RX and TX. This
> > > > is used to allow the board designer to trace more easily the signals.
> > > >
> > > > Horatiu Vultur (2):
> > > >   phy: microchip: lan966x: Add support for inverting the rx/tx lanes
> > > >   dt-bindings: phy: lan966x: Add optional microchip,sx-tx/rx-inverted
> > > >
> > > >  .../phy/microchip,lan966x-serdes.yaml         | 24 +++++++++++++++++++
> > > >  drivers/phy/microchip/lan966x_serdes.c        | 23 ++++++++++++++++++
> > > >  2 files changed, 47 insertions(+)
> > > >
> > > > --
> > > > 2.34.1
> > >
> > > For context, I am trying to describe the lane polarity property
> > > generically, and I've already blocked Daniel Golle's attempt to
> > > introduce the similar in intent "maxlinear,rx-inverted" and
> > > "maxlinear,tx-inverted".
> > > https://lore.kernel.org/netdev/20251028000959.3kiac5kwo5pcl4ft@skbuf/
> > >
> > > I am trying to find out all there is to know in order about this
> > > feature, and I just noticed your patch, so I have to ask some questions
> > > in order to understand, had a generic property existed, whether you
> > > would have used it.
> >
> > Yes, if there was something generic that would fit, I would like to use it.
> >
> > >
> > > So I see that you don't have OF nodes for individual SerDes lanes, so
> > > this makes your device tree structure incompatible with simple
> > > "tx-polarity"/"rx-polarity" properties. Are those something you're not
> > > willing to introduce?
> >
> > Do you propose to change the device tree to describe each SerDes lane
> > individualy?
> > Apparently in the lan966x_serdes we have also the port muxing which I am
> > not sure it should be there as it should be in the switch. I have done
> > it this way because I have use the phy-ocelot-serdes.c as an example.
> > If I change the device tree to describe each lane, then first I need to
> > take the port muxing which is fine for me. But there might be a problem,
> > if someone will use a newer kernel with an older device tree, it would
> > break the things?
> >
> > > What about other stuff that's in
> > > Documentation/devicetree/bindings/phy/transmit-amplitude.yaml?
> > > You also won't be able to make use of the existing device tree
> > > properties if you don't have OF node containers for each lane.
> >
> > To be honest, I haven't look at transmit-amplitude.yaml yet.
> >
> > --
> > /Horatiu
> >
> 
> ffs :-/
> 
> The radioactive piece of #### that is my work inbox moved your reply to
> the Junk folder, _even though_ you were already in the list of safe
> senders and domains. I just checked this thread to see what was going on
> and why you didn't respond...

No worries.

> 
> Yeah, the device tree binding I want to propose is per lane, so there
> needs to be an OF node for each lane.
> 
> I can't easily parse the lan966x_serdes_muxes[] macros, assuming this is
> what you are talking about.

Yes, I was talking about lan966x_serdes_muxes and I totally understand
that is not that easy to parse it.

> 
> 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.

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

-- 
/Horatiu