Re: [PATCH net-next] net: dsa: mxl-gsw1xx: fix SerDes RX polarity

[Rasmus Villemoes <ravi@prevas.dk>]

On Wed, Dec 03 2025, Daniel Golle <daniel@makrotopia.org> wrote:

> On Wed, Dec 03, 2025 at 11:49:59AM +0200, Vladimir Oltean wrote:
>> On Tue, Dec 02, 2025 at 09:57:21AM +0000, Daniel Golle wrote:
>> > According to MaxLinear engineer Benny Weng the RX lane of the SerDes
>> > port of the GSW1xx switches is inverted in hardware, and the
>> > SGMII_PHY_RX0_CFG2_INVERT bit is set by default in order to compensate
>> > for that. Hence also set the SGMII_PHY_RX0_CFG2_INVERT bit by default in
>> > gsw1xx_pcs_reset().
>> > 
>> > Fixes: 22335939ec90 ("net: dsa: add driver for MaxLinear GSW1xx switch family")
>> > Reported-by: Rasmus Villemoes <ravi@prevas.dk>
>> > Signed-off-by: Daniel Golle <daniel@makrotopia.org>
>> > ---
>> 
>> This shouldn't impact the generic device tree property work, since as
>> stated there, there won't be any generically imposed default polarity if
>> the device tree property is missing.
>> 
>> We can perhaps use this thread to continue a philosophical debate on how
>> should the device tree deal with this situation of internally inverted
>> polarities (what does PHY_POL_NORMAL mean: the observable behaviour at
>> the external pins, or the hardware IP configuration?). I have more or
>> less the same debate going on with the XPCS polarity as set by
>> nxp_sja1105_sgmii_pma_config().
>
> In this case it is really just a bug in the datasheet, because the
> switch does set the GSW1XX_SGMII_PHY_RX0_CFG2_INVERT bit by default
> after reset, which results in RX polarity to be as expected (ie.
> negative and positive pins as labeled).

Well, that "by default" actually depends. When the switch is strapped
PS_NOWAIT=0, the observed reset value of the register is simply 0, and
the host must do all the configuration, including setting that bit.

I suppose that's also the "hardware" reset value, but then in
PS_NOWAIT=1 mode, the ROM/bootloader code inside the switch sets the
register to 0x053a, which is then from the host's POV effectively the
reset value.

I suppose it ended up like this because they realized they'd
accidentally done the swapping in hardware, but then they could sort-of
fix up that by changing the ROM code, but neglected to update the data
sheet or publish an errata. The data sheet claims a reset value of
0x0532, and doesn't say a word about that hardware quirk.

Aside: Can somebody explain why the data sheet would talk about
"incoming data on rx0_data[19:0]" - how and where does the number 20
come into the picture?

Rasmus