lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <878qfivctr.fsf@prevas.dk>
Date: Thu, 04 Dec 2025 10:03:12 +0100
From: Rasmus Villemoes <ravi@...vas.dk>
To: Daniel Golle <daniel@...rotopia.org>
Cc: Vladimir Oltean <olteanv@...il.com>,  Hauke Mehrtens <hauke@...ke-m.de>,
  Andrew Lunn <andrew@...n.ch>,  "David S. Miller" <davem@...emloft.net>,
  Eric Dumazet <edumazet@...gle.com>,  Jakub Kicinski <kuba@...nel.org>,
  Paolo Abeni <pabeni@...hat.com>,  netdev@...r.kernel.org,
  linux-kernel@...r.kernel.org,  "Benny (Ying-Tsan) Weng"
 <yweng@...linear.com>
Subject: Re: [PATCH net-next] net: dsa: mxl-gsw1xx: fix SerDes RX polarity

On Wed, Dec 03 2025, Daniel Golle <daniel@...rotopia.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@...vas.dk>
>> > Signed-off-by: Daniel Golle <daniel@...rotopia.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ