Re: [PATCH v4 net-next 5/5] net: pcs: pcs-mtk-lynxi: deprecate "mediatek,pnswap"

[Vladimir Oltean]

On Thu, Apr 02, 2026 at 05:50:33AM +0000, Frank Wunderlich wrote:
> Hi,

Hi,

Please don't top-post :(

> i tried using these properties in sgmiisys0 node (which should be mapped to mac0 and the mt7530 switch) without success [1].
> 
> it looks like these properties are not read somewhere.

Can you please clarify whether your problem is with the SerDes connected
to a switch port or to a GMAC?

Because if to a switch port, mt7531_create_sgmii() doesn't have any
phandle to the SGMIISYS. That was from existing code.

		pcs = mtk_pcs_lynxi_create(priv->dev, NULL, regmap,
					   MT7531_PHYA_CTRL_SIGNAL3);

The LynxI PCS will be instantiated without a fwnode and only the
defaults will apply.

> the flow is
> 
> mtk_probe (eth driver)
> 
> if (MTK_HAS_CAPS(eth->soc->caps, MTK_SGMII)) {
> 	err = mtk_sgmii_init(eth);
> 
> and there calling mtk_pcs_lynxi_create with the sgmiisys-node (for each mac, so imho mac0=sgmiisys0)
> but handling the sgmiisys only as syscon, not a "real" pcs node [2].
> 
> but your new code calls phy_get_tx_polarity and should read out this properties, but from subnode "pcs", so next try was
> 
> &sgmiisys0 {
> 	pcs {
> 		rx-polarity = <PHY_POL_NORMAL>;
> 		tx-polarity = <PHY_POL_INVERT>;
> 	};
> };
> 
> which results in completely strange behaviour (looks like sgmiisys1 is mapped to mac0, but based on code in mtk_sgmii_init 0=0 should be right):
> 
> [    2.765218] SGMSYS_QPHY_WRAP_CTRL = 0x501, will write 0x500
> [    9.143849] SGMSYS_QPHY_WRAP_CTRL = 0x500, will write 0x501
> 
> but nevertheless i tried changing sgmiisys0 to sgmiisys1 and got the dame result as before
> 
> [    2.713644] SGMSYS_QPHY_WRAP_CTRL = 0x501, will write 0x500
> [    9.061509] SGMSYS_QPHY_WRAP_CTRL = 0x500, will write 0x500
> 
> i can only change the second serdes with sgmiisys0, but not the first.

I assume the second SerDes is mapped to a GMAC port which does
instantiate the LynxI PCS with a fwnode, right? If so, the behaviour is
consistent with the code. Only mtk-soc-eth uses mediatek,sgmiisys AFAICS.

> mapping between mac and sgmiisys in dts in mt7986a.dtsi [3] are like this:
> 
> eth: ethernet@15100000 {
> 	compatible = "mediatek,mt7986-eth";
> 	mediatek,sgmiisys = <&sgmiisys0>, <&sgmiisys1>;
> 	...
> };
> 
> &eth {
> 	status = "okay";
> 
> 	gmac0: mac@0 {
> 		compatible = "mediatek,eth-mac";
> 	...
> 	};
> 
> 	gmac1: mac@1 {
> 		compatible = "mediatek,eth-mac";
> 	...
> 	};
> };
> 
> maybe it is time to revive the PCS framework discussion ([4]-[6])?
> 
> [1] https://github.com/frank-w/BPI-Router-Linux/commit/4846a7bb352fe5911136cba33813f099bac035fd
> [2] https://elixir.bootlin.com/linux/v7.0-rc4/source/drivers/net/ethernet/mediatek/mtk_eth_soc.c#L5001
> [3] https://elixir.bootlin.com/linux/v7.0-rc4/source/arch/arm64/boot/dts/mediatek/mt7986a.dtsi#L528
> 
> [4] * https://patchwork.kernel.org/project/netdevbpf/patch/20250610233134.3588011-4-sean.anderson@xxxxxxxxx/ (v6)
> > pcs-framework itself had not yet got a response from netdev maintainer (only other parts)
> [5] * https://patchwork.kernel.org/project/netdevbpf/patch/20250511201250.3789083-4-ansuelsmth@xxxxxxxxx/ (v4)
> > discussion: https://lore.kernel.org/netdev/20250511201250.3789083-1-ansuelsmth@xxxxxxxxx/
> [6] * https://patchwork.kernel.org/project/netdevbpf/patch/ba4e359584a6b3bc4b3470822c42186d5b0856f9.1721910728.git.daniel@xxxxxxxxxxxxxx/
> > discussion: https://patchwork.kernel.org/project/netdevbpf/patch/8aa905080bdb6760875d62cb3b2b41258837f80e.1702352117.git.daniel@xxxxxxxxxxxxxx/

I'm not exactly sure how device+driver for the PCS devices would help in
this case though? Because the LynxI PCS driver would just retrieve the
fwnode on its own, rather than it being passed by the mtk_pcs_lynxi_create()
caller?

We need to have a very good model of what happens when the PCS provider
goes away, especially in multi-port scenarios. It is a similar issue as
to what happens when a phy_device goes away.
https://lore.kernel.org/netdev/20260311153421.u454m3e4blkstymt@skbuf/

I'm not saying "let's not do that", but we'd effectively introducing an
issue that currently does not exist, with the PCS lifetime being managed
by the consumer.

Do you have any better idea by now why SGMSYS_QPHY_WRAP_CTRL is 0x501
for SGMIISYS #0? Is that its out-of-reset value?