[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aJQ/8Nta6020On2O@FUE-ALEWI-WINX>
Date: Thu, 7 Aug 2025 07:56:00 +0200
From: Alexander Wilhelm <alexander.wilhelm@...termo.com>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>,
Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>,
"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
Subject: Re: Aquantia PHY in OCSGMII mode?
Am Wed, Aug 06, 2025 at 05:58:56PM +0300 schrieb Vladimir Oltean:
> On Tue, Aug 05, 2025 at 02:44:15PM +0200, Alexander Wilhelm wrote:
> > Patch is applied. Here are the registers log:
> >
> > user@...t:~# 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@...t:~# 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.
Hi Vladimir,
Now that I have 1G/2.5G working, I’ll be able to run some additional tests with
the device. I’ll revisit the 100M topic later and analyze it more thoroughly. I
suspect that some register settings in U-Boot might be causing issues when the
PHY is initialized again in the kernel.
I truly appreciate your detailed support, it has been incredibly helpful in
moving things forward.
Best regards
Alexander Wilhelm
Powered by blists - more mailing lists