Re: Aquantia PHY in OCSGMII mode?
From: Alexander Wilhelm <hidden>
Date: 2025-08-04 14:47:31
Also in:
lkml
Am Mon, Aug 04, 2025 at 04:41:15PM +0300 schrieb Vladimir Oltean:
Hi Alexander, On Mon, Aug 04, 2025 at 03:01:44PM +0200, Alexander Wilhelm wrote:quoted
quoted
Please find the attached patch.[...] Hi Vladimir, I’ve applied the patch you provided, but it doesn’t seem to fully resolve the issue -- or perhaps I’ve misconfigured something. I’m encountering the following error during initialization: mdio_bus 0x0000000ffe4e7000:00: AN not supported on 3.125GHz SerDes lane fsl_dpaa_mac ffe4e6000.ethernet eth0: pcs_config failed: -EOPNOTSUPP The relevant code is located in `drivers/net/pcs/pcs-lynx.c`, within the `lynx_pcs_config(...)` function. In the case of 2500BASE-X with in-band autonegotiation enabled, the function logs an error and returns -EOPNOTSUPP.Once I saw this I immediately realized my mistake. More details at the end.quoted
From what I can tell, autonegotiation isn’t supported on a 3.125GHz SerDes lane when using 2500BASE-X. What I’m unclear about is how this setup is supposed to work in practice. My understanding is that on the host side, communication always uses OCSGMII with flow control, allowing speed pacing via pause frames. But what about the line side -- should it be configurable, or is it expected to operate in a fixed mode?So there are two "auto-negotiation" processes involved. +-----+ internal +-----+ 2500base-x +-----------+ 2.5GBase-T +------------+ | MAC |==========| PCS |===========================| Local PHY |==============| Remote PHY | ... +-----+ GMII not +-----+ in-band autonegotiation +-----------+ clause 28 +------------+ represented in the autonegotiation device tree (1) (2)
[...] Hi Vladimir, thank you for the detailed explanation. I feel I now have a clearer understanding of what's happening under the hood.
quoted hunk ↗ jump to hunk
What I failed to consider is that the FMan mEMAC driver sets phylink's "default_an_inband" property to true, making it as if the device tree node had this property anyway. The driver needs to be further patched to prevent that from happening. Here's a line that needs to be squashed into the previous change, could you please retest with it?--- a/drivers/net/ethernet/freescale/fman/fman_memac.c +++ b/drivers/net/ethernet/freescale/fman/fman_memac.c@@ -1229,6 +1229,7 @@ int memac_initialization(struct mac_device *mac_dev, * those configurations modes don't use in-band autonegotiation. */ if (!of_property_present(mac_node, "managed") && + mac_dev->phy_if != PHY_INTERFACE_MODE_2500BASEX && mac_dev->phy_if != PHY_INTERFACE_MODE_MII && !phy_interface_mode_is_rgmii(mac_dev->phy_if)) mac_dev->phylink_config.default_an_inband = true;
I’ve applied this patch as well, which brought me a step further. Unfortunately,
I still don’t get a ping response, although the configuration looks correct to
me. Below are the logs and the `ethtool` output I’m seeing:
user@host:~# logread | grep eth
kern.info kernel: [ 20.777530] fsl_dpaa_mac ffe4e6000.ethernet: FMan MEMAC
kern.info kernel: [ 20.782840] fsl_dpaa_mac ffe4e6000.ethernet: FMan MAC address: 00:00:5b:05:a2:cb
kern.info kernel: [ 20.793126] fsl_dpaa_mac ffe4e6000.ethernet eth0: Probed interface eth0
kern.info kernel: [ 31.058431] usbcore: registered new interface driver cdc_ether
user.notice netifd: Added device handler type: veth
kern.info kernel: [ 48.171837] fsl_dpaa_mac ffe4e6000.ethernet eth0: PHY [0x0000000ffe4fd000:07] driver [Aquantia AQR115] (irq=POLL)
kern.info kernel: [ 48.171861] fsl_dpaa_mac ffe4e6000.ethernet eth0: configuring for phy/2500base-x link mode
kern.info kernel: [ 48.181338] br-lan: port 1(eth0) entered blocking state
kern.info kernel: [ 48.181363] br-lan: port 1(eth0) entered disabled state
kern.info kernel: [ 48.181399] fsl_dpaa_mac ffe4e6000.ethernet eth0: entered allmulticast mode
kern.info kernel: [ 48.181577] fsl_dpaa_mac ffe4e6000.ethernet eth0: entered promiscuous mode
kern.info kernel: [ 53.304459] fsl_dpaa_mac ffe4e6000.ethernet eth0: Link is Up - 2.5Gbps/Full - flow control rx/tx
kern.info kernel: [ 53.304629] br-lan: port 1(eth0) entered blocking state
kern.info kernel: [ 53.304642] br-lan: port 1(eth0) entered forwarding state
daemon.notice netifd: Network device 'eth0' link is up
daemon.info lldpd[6849]: libevent 2.1.12-stable initialized with epoll method
daemon.info charon: 10[KNL] flags changed for fe80::200:5bff:fe05:a2cb on eth0
user@host:~# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Full
100baseT/Full
1000baseT/Full
2500baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Full
100baseT/Full
1000baseT/Full
2500baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 100baseT/Full
1000baseT/Full
10000baseT/Full
2500baseT/Full
5000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 2500Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 7
Transceiver: external
Auto-negotiation: on
MDI-X: on
Current message level: 0x00002037 (8247)
drv probe link ifdown ifup hw
Link detected: yes
I will continue investigating why the ping isn’t working and will share any new
findings as soon as I have them. Thanks again for your support!
Best regards
Alexander Wilhelm