linux-kernel - Re: Aquantia PHY in OCSGMII mode?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aJDH56uXX9UVMZOf@FUE-ALEWI-WINX>
Date: Mon, 4 Aug 2025 16:47:03 +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 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@...t:~# 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@...t:~# 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