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

[Vladimir Oltean <olteanv@gmail.com>]

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

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.

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.