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.