Re: Aquantia PHY in OCSGMII mode?

Vladimir Oltean
2025-08-06T14:59:02Z

On Tue, Aug 05, 2025 at 02:44:15PM +0200, Alexander Wilhelm wrote:
> Patch is applied. Here are the registers log:
>
> user@host:~# logread | grep AQR115
> Aquantia AQR115 0x0000000ffe4fd000:07: Speed 10 SerDes mode 4 autoneg 0 training 0 reset on transition 0 silence 0 rate adapt 2 macsec 0
> Aquantia AQR115 0x0000000ffe4fd000:07: Speed 100 SerDes mode 4 autoneg 0 training 1 reset on transition 0 silence 1 rate adapt 2 macsec 0
> Aquantia AQR115 0x0000000ffe4fd000:07: Speed 1000 SerDes mode 4 autoneg 0 training 1 reset on transition 0 silence 1 rate adapt 2 macsec 0
> Aquantia AQR115 0x0000000ffe4fd000:07: Speed 2500 SerDes mode 4 autoneg 1 training 1 reset on transition 0 silence 1 rate adapt 0 macsec 0
> Aquantia AQR115 0x0000000ffe4fd000:07: Speed 5000 SerDes mode 0 autoneg 0 training 0 reset on transition 0 silence 0 rate adapt 2 macsec 0
> Aquantia AQR115 0x0000000ffe4fd000:07: Speed 10000 SerDes mode 0 autoneg 0 training 0 reset on transition 0 silence 0 rate adapt 0 macsec 0
> fsl_dpaa_mac ffe4e4000.ethernet eth0: PHY [0x0000000ffe4fd000:07] driver [Aquantia AQR115] (irq=POLL)
>
> While 100M transfer, I see the MAC TX frame increasing and SGMII TX good frames
> increasing. But the receiving frames are counted as SGMII RX bad frames and MAC
> RX frames counter does not increase. The TX/RX pause frames always stay at 0,
> independently whether ping is working with 1G/2.5G or not with 100M. Do you have
> any idea here?
>
> user@host:~# ethtool -S eth0 --groups eth-mac eth-phy eth-ctrl rmon | grep -v ': 0' && ethtool --phy-statistics eth0 | grep -v ': 0' && ethtool -I --show-pause eth0
> Standard stats for eth0:
> eth-mac-FramesTransmittedOK: 529
> eth-mac-FramesReceivedOK: 67
> eth-mac-OctetsTransmittedOK: 79287
> eth-mac-OctetsReceivedOK: 9787
> eth-mac-MulticastFramesXmittedOK: 43
> eth-mac-BroadcastFramesXmittedOK: 451
> eth-mac-MulticastFramesReceivedOK: 32
> eth-mac-BroadcastFramesReceivedOK: 1
> rx-rmon-etherStatsPkts64to64Octets: 3
> rx-rmon-etherStatsPkts65to127Octets: 42
> rx-rmon-etherStatsPkts128to255Octets: 18
> rx-rmon-etherStatsPkts256to511Octets: 4
> tx-rmon-etherStatsPkts64to64Octets: 5
> tx-rmon-etherStatsPkts65to127Octets: 385
> tx-rmon-etherStatsPkts128to255Octets: 26
> tx-rmon-etherStatsPkts256to511Octets: 113
> PHY statistics:
> sgmii_rx_good_frames: 21149
> sgmii_rx_bad_frames: 176
> sgmii_rx_false_carrier_events: 1
> sgmii_tx_good_frames: 21041
> sgmii_tx_line_collisions: 1
> Pause parameters for eth0:
> Autonegotiate: on
> RX: off
> TX: off
> RX negotiated: on
> TX negotiated: on
> Statistics:
> tx_pause_frames: 0
> rx_pause_frames: 0

Sorry, I am not fluent enough with the Aquantia PHYs to be further
helpful here.

I have made a procedural mistake by suggesting you to print select
fields of the Global System Configuration registers instead of the raw
register values. I am unable to say with the required certainty whether
the configuration for 100M and 1G is identical or not. The printed
fields are the same, however there could still be differences in the
unprinted bits (looking at bit 12 'Low Delay Jitter'). That's something
you should explore further.

About MAC RX counters not increasing at all. The mEMAC has a catch-all
RERR counter which increments for each frame received with a wider
variety of errors (except for undersized/fragment frames):
- FIFO overflow error
- CRC error
- Payload length error
- Jabber and oversized error
- Alignment error (if supported)
- Reception of PHY/PCS error indication
The structured ethtool statistics API doesn't seem to have a counter for
received frame errors in general, only for specific errors. So I didn't
export it in the patch I sent. It's possible that this counter is
incrementing (but the more specific RFCS/RALN/... counters apparently not).

In any case, the T1023 host configuration is literally unchanged from
1G to 100M, so I am suspecting a misconfiguration in the Aquantia
provisioning somewhere. Maybe an FAE or AE from Marvell can help you
further with this issue.

If you do contact them, please also request them to fix the discrepancy
where the Global System Configuration register for speed 2500 has
"autoneg 1", but all the other speeds have "autoneg 0" for the same
SerDes mode 4. It is precisely this concern that I was expressing to
Russell that makes it difficult to implement .inband_caps() based on
reading PHY registers.