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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20251110114216.r6zdgg4iky7kasut@skbuf>
Date: Mon, 10 Nov 2025 13:42:16 +0200
From: Vladimir Oltean <vladimir.oltean@....com>
To: Horatiu Vultur <horatiu.vultur@...rochip.com>
Cc: 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

Hi Horatiu,

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.

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