summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/gecko.py
diff options
context:
space:
mode:
authorVladimir Oltean <vladimir.oltean@nxp.com>2025-09-03 16:07:28 +0300
committerJakub Kicinski <kuba@kernel.org>2025-09-05 19:03:40 -0700
commit5d59109d47c00e3e98aba612529b3871e69efb9d (patch)
treedcf5b1fcb604651094a1cc843ba6427c82b29215 /tools/perf/scripts/python/gecko.py
parent7b0376d0e06358592de4997931a657683d0fa3df (diff)
net: phy: aquantia: report and configure in-band autoneg capabilities
The Global System Configuration registers for each media side link speed have bit 3 which controls auto-negotiation for the system interface. Since bits 2:0 of the same register indicate the SerDes protocol for the same system interface, it makes sense to filter these registers for the SerDes protocol matching phydev->interface, and to read/write the auto-negotiation bit. However, experimentally, USXGMII in-band auto-negotiation is unaffected by this bit, and instead reacts to bit 3 of register 4.C441 (PHY XS Transmit Reserved Vendor Provisioning 2). Both the Global System Configuration as well as the aforementioned register 4.C441 are documented as PD (Provisioning Defaults), i.e. each PHY firmware may provision its own values. I was initially planning to only read these values and not support changing them (instead just the MAC PCS reconfigures itself, if it can). But there is one problem: Linux expects that the in-band capability is configured the same for all speeds where a given SerDes protocol is used. I was going to add logic that detects mismatched vendor provisioning (in-band autoneg enabled for speed X, disabled for speed Y) and warn about it and return 0 (unknown capabilities). Funnily enough, there is already a known instance where speed 2500 has "autoneg 1" and the lower speeds have "autoneg 0": https://lore.kernel.org/netdev/aJH8n0zheqB8tWzb@FUE-ALEWI-WINX/ I don't think it's worth fighting the battle with inconsistent firmware images built by Aquantia/Marvell, and reporting that to the user, when we have the ability to modify these fields to values that make sense to us. We see the same situation with all the aqr*_get_features() functions which fix up nonsensical supported link modes. Furthermore, altering the in-band auto-negotiation setting can be considered a minor change, compared to changing the SerDes protocol in its entirety, for which we are still not prepared. Testing was done on: - AQR107 (Gen2) in USXGMII mode, as found on the NXP LX2160A-RDB. - AQR112 (Gen3) in USXGMII mode, as found on the NXP SCH-30842 riser card, plugged into LS1028A-QDS. - AQR412C (Gen3) in 10G-QXGMII mode, as found on the NXP SCH-30841 riser card, plugged into the LS1028A-QDS. - AQR115 (Gen4) in SGMII mode, as found on the NXP LS1046A-RDB rev E. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20250903130730.2836022-5-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/gecko.py')
0 files changed, 0 insertions, 0 deletions