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

["Frank Wunderlich" <frank.wunderlich@linux.dev>]

Hi,

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.

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.

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@linux.dev/ (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@gmail.com/ (v4)
> discussion: https://lore.kernel.org/netdev/20250511201250.3789083-1-ansuelsmth@gmail.com/
[6] * https://patchwork.kernel.org/project/netdevbpf/patch/ba4e359584a6b3bc4b3470822c42186d5b0856f9.1721910728.git.daniel@makrotopia.org/
> discussion: https://patchwork.kernel.org/project/netdevbpf/patch/8aa905080bdb6760875d62cb3b2b41258837f80e.1702352117.git.daniel@makrotopia.org/

Am 30. März 2026 um 21:04 schrieb "Vladimir Oltean" <vladimir.oltean@nxp.com mailto:vladimir.oltean@nxp.com?to=%22Vladimir%20Oltean%22%20%3Cvladimir.oltean%40nxp.com%3E >:
> 
> Hi Frank,
> 
> On Mon, Mar 30, 2026 at 05:52:17PM +0000, Frank Wunderlich wrote:
> 
> > 
> > Hi Vladimir
> >  
> >  Thanks for the patch and sorry for my delay...i was away this weekend so i was not able to test.
> >  
> >  traffic works again (but there is only read now) and this is the result of your debug prints:
> >  
> >  root@bpi-r3:~# mailto:root@bpi-r3:~#  dmesg | grep SGMSYS_QPHY_WRAP_CTRL
> >  [ 2.706963] SGMSYS_QPHY_WRAP_CTRL = 0x501, intending to write 0x500
> >  [ 9.134081] SGMSYS_QPHY_WRAP_CTRL = 0x500, intending to write 0x500
> >  
> >  R3/mt7986 has 2 MAC, and switch is on the first, so value will change, not sure why this is different.
> >  
> >  i have not found SGMSYS_QPHY_WRAP_CTRL or something related with polarity in ethernet/mac-
> >  (drivers/net/ethernet/mediatek/mtk_eth_soc.c) or switch-driver (drivers/net/dsa/mt7530{,-mdio}.c)
> >  in case they manipulate this register too (of course they should not). Also looked into the pcs-handling
> >  in both drivers, but see nothing related to polarity. And looked for possible duplicate register const
> >  definition (other name for 0xec).
> > 
> This result means that your default QPHY_WRAP_CTRL register value has
> the SGMII_PN_SWAP_TX bit set. Whether that comes from U-Boot or hardware
> default or otherwise, it doesn't really matter. Curious that the
> SGMII_SW_RESET doesn't clear TX inversion, though. I guess you wouldn't
> have documentation that would suggest this setting is sticky?
> 
> In Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml,
> it is not specified what happens when the "mediatek,pnswap" property is
> missing. I thought the most logical thing would be for the lane
> polarities to not be swapped - because how would you describe normal
> lane polarities otherwise? My bad for thinking the original vendor
> bindings were more sane than they were.
> 
> The only way to describe the polarities that this SGMSYS block needs on
> a particular board is to use the newly introduced 'rx-polarity =
> <PHY_POL_NORMAL>' and 'tx-polarity = <PHY_POL_INVERT>'. Which I strongly
> recommend you to do, even if the attached patch should restore
> functionality with your current device tree.
> 

regards Frank