Re: Aquantia PHY in OCSGMII mode?

Alexander Wilhelm
2025-08-04T14:47:31Z

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:
> > > 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.
>
> > 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.

> 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