linux-phy.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Horatiu Vultur <horatiu.vultur@microchip.com>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>,
	vkoul@kernel.org, kishon@kernel.org, robh@kernel.org,
	krzk+dt@kernel.org, conor+dt@kernel.org,
	linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Daniel Golle <daniel@makrotopia.org>
Subject: Re: [PATCH 0/2] phy: microchip: lan966x: Allow to invert N and P signals
Date: Wed, 19 Nov 2025 21:23:26 +0200	[thread overview]
Message-ID: <20251119192326.4bflaqkh4zvz2rib@skbuf> (raw)
In-Reply-To: <20251114103411.rzigaoictyinmx66@DEN-DL-M31836.microchip.com>

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@e202c000 {
> 		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@e202c000 {
> 		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@e202c000 {
		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.

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

      reply	other threads:[~2025-11-19 19:23 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-10 11:05 [PATCH 0/2] phy: microchip: lan966x: Allow to invert N and P signals Horatiu Vultur
2025-11-10 11:05 ` [PATCH 1/2] phy: microchip: lan966x: Add support for inverting the rx/tx lanes Horatiu Vultur
2025-11-10 11:05 ` [PATCH 2/2] dt-bindings: phy: lan966x: Add optional microchip,sx-tx/rx-inverted Horatiu Vultur
2025-11-10 18:43   ` Conor Dooley
2025-11-11  9:58     ` Horatiu Vultur
2025-11-11 10:06       ` Krzysztof Kozlowski
2025-11-11 17:39         ` Conor Dooley
2025-11-12  8:02           ` Horatiu Vultur
2025-11-12 18:32             ` Conor Dooley
2025-11-13 11:56               ` Horatiu Vultur
2025-11-13 19:13                 ` Conor Dooley
2025-11-10 11:42 ` [PATCH 0/2] phy: microchip: lan966x: Allow to invert N and P signals Vladimir Oltean
2025-11-11  9:50   ` Horatiu Vultur
2025-11-13 16:30     ` Vladimir Oltean
2025-11-14 10:34       ` Horatiu Vultur
2025-11-19 19:23         ` Vladimir Oltean [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251119192326.4bflaqkh4zvz2rib@skbuf \
    --to=olteanv@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=daniel@makrotopia.org \
    --cc=devicetree@vger.kernel.org \
    --cc=horatiu.vultur@microchip.com \
    --cc=kishon@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=robh@kernel.org \
    --cc=vkoul@kernel.org \
    --cc=vladimir.oltean@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).