Re: [PATCH net-next v2 1/3] net: macb: fix SGMII with inband aneg disabled

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Wed, Mar 04, 2026 at 06:06:20PM +0000, Conor Dooley wrote:
> On Wed, Mar 04, 2026 at 04:55:37PM +0000, Russell King (Oracle) wrote:
> > On Wed, Mar 04, 2026 at 04:23:30PM +0000, Conor Dooley wrote:
> > > On Wed, Mar 04, 2026 at 06:59:35AM -0800, Charles Perry wrote:
> > > > On Wed, Mar 04, 2026 at 11:15:43AM +0000, Conor Dooley wrote:
> > > > > On Tue, Feb 24, 2026 at 12:28:52PM -0800, Charles Perry wrote:
> > > > > > Make it possible to connect a PHY which does not use inband
> > > > > > autoneg to a gem MAC using phylink's information.
> > > > > > 
> > > > > > The previous implementation relied on whether or not the link
> > > > > > was a fixed-link to disable SGMII autoneg. This commit extend
> > > > > > this to all link which are not configured for inband
> > > > > > autonegotiation.
> > > > > > 
> > > > > > Signed-off-by: Charles Perry <charles.perry@microchip.com>
> > > > > 
> > > > > This breaks the macb on mpfs-icicle-kit, I get stuck with:
> > > > > 
> > > > > [    7.189102] mpfs-sys-controller syscontroller: Registered MPFS system controller
> > > > > [    7.260946] macb 20110000.ethernet eth0: PHY [20112000.ethernet-ffffffff:08] driver [Vitesse VSC8662] (irq=POLL)
> > > > > [    7.273881] macb 20110000.ethernet eth0: configuring for phy/sgmii link mode
> > > > > [    7.296580] macb 20110000.ethernet: gem-ptp-timer ptp clock registered.
> > > > > [    7.345782] macb 20112000.ethernet eth1: PHY [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
> > > > > [    7.358082] macb 20112000.ethernet eth1: configuring for phy/sgmii link mode
> > > > > [    7.380479] macb 20112000.ethernet: gem-ptp-timer ptp clock registered.
> > > > > [   11.376763] macb 20110000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
> > > > > [   11.398403] Sending DHCP requests .
> > > > > [   11.472699] macb 20112000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
> > > > > [   13.938425] ..... timed out!
> > > > > [   93.598491] macb 20110000.ethernet eth0: Link is Down
> > > > > [   93.641823] macb 20110000.ethernet: gem-ptp-timer ptp clock unregistered.
> > > > > [   93.659433] macb 20112000.ethernet eth1: Link is Down
> > > > > [   93.691724] macb 20112000.ethernet: gem-ptp-timer ptp clock unregistered.
> > > > > [   93.703977] IP-Config: Retrying forever (NFS root)...
> > > > > [   93.758382] macb 20110000.ethernet eth0: PHY [20112000.ethernet-ffffffff:08] driver [Vitesse VSC8662] (irq=POLL)
> > > > > [   93.770655] macb 20110000.ethernet eth0: configuring for phy/sgmii link mode
> > > > > [   93.786497] macb 20110000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
> > > > > [   93.795840] macb 20110000.ethernet: gem-ptp-timer ptp clock registered.
> > > > > [   93.844481] macb 20112000.ethernet eth1: PHY [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
> > > > > [   93.856769] macb 20112000.ethernet eth1: configuring for phy/sgmii link mode
> > > > > [   93.870926] macb 20112000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
> > > > > [   93.880302] macb 20112000.ethernet: gem-ptp-timer ptp clock registered.
> > > > > 
> > > > 
> > > > Hello Conor,
> > > > 
> > > > I checked the driver for the VSC8662 and it doesn't have the
> > > > ->inband_caps() and ->config_inband() callbacks so Linux leaves whatever
> > > > the bootloader puts or uses the defaults. Looking at the datasheet, this
> > > > should be register 23 (Extended PHY Control Set 1) bit 13 (MAC interface
> > > > auto-negotiation)
> > > > 
> > > > My guess is that this bit is set and since this patch disable inband
> > > > autonegotiation (because phylink decides it), there is a mismatch.
> > > > 
> > > > Can you add 'managed = "in-band-status"' in your device tree under the macb
> > > > node? That's not necessarily the fix, I just want to confirm my theory.
> > > 
> > > No, it just produces a different error:
> > > [    5.769864] mpfs-sys-controller syscontroller: Registered MPFS system controller
> > > [    5.829146] macb 20110000.ethernet eth0: Could not attach PHY (-19)
> > > [    5.854232] IP-Config: Failed to open eth0
> > > [    5.897152] macb 20112000.ethernet eth1: Could not attach PHY (-19)
> > > [    5.921061] IP-Config: Failed to open eth1
> > > [    5.925592] IP-Config: No network devices available
> > > [    5.938800] clk: Disabling unused clocks
> > > [    5.944156] PM: genpd: Disabling unused power domains
> > > [    5.961029] check access for rdinit=/usr/sbin/init failed: -2, ignoring
> > 
> > -19 is -ENODEV (I wish everyone would use %pe so we get english
> > error messages rather than having to look up errno codes in the
> > header files.)
> > 
> > macb uses either phylink_of_phy_connect() or phylink_connect_phy().
> > I don't think phylink_connect_phy() would return -ENODEV, but
> > phylink_of_phy_connect() would - but I can't see that adding
> > 'managed = "in-band-status";' to DT would cause that. The only
> > case I can see is that fwnode_phy_find_device() fails to find the
> > phydev, but there is a PHY node specified in DT, but that would
> > fail without in-band-status.
> 
> It's as you say, and fwnode_phy_find_device() is the source.
> fwnode_mdio_find_device() is what fails, returning NULL.

Ah, I've just found the reason:

        /* With fixed-link, we don't need to register the MDIO bus,
         * except if we have a child named "mdio" in the device tree.
         * In that case, some devices may be attached to the MACB's MDIO bus.
         */
        mdio_np = of_get_child_by_name(np, "mdio");
        if (!mdio_np && of_phy_is_fixed_link(np))
                return macb_mii_probe(bp->dev);

of_phy_is_fixed_link() will return true as soon as you add that managed
property, and as the mac1 node just lists the PHYs without using a
mdio child:

&mac1 {
        phy-mode = "sgmii";
        phy-handle = <&phy1>;
        status = "okay";

        phy1: ethernet-phy@9 {
                reg = <9>;
        };

        phy0: ethernet-phy@8 {
                reg = <8>;
        };
};

it means mdio_np is NULL above. Hence, no MDIO bus will be created.

> > > > Also '#define DEBUG' in 'drivers/net/phy/phylink.c' can help if you can
> > > > recompile your kernel.
> > > 
> > > Setting this provided no further logs, seemingly.
> > 
> > It certainly would if you place it before the first #include - I
> > routinely build kernels with it set as such. The messages are produced
> > at debug level, so should appear via "dmesg". If you want to see them
> > on the console, you need to add "debug" to the kernel command line.
> 
> Clearly I'm too stupid for this, because I did it again and still got no
> more logs. I even disabled DYNAMIC_DEBUG since that has an interaction
> in the file.

I'm sorry, I don't know what's going on there. As I say, it works for
me. E.g. from two days ago:

[  101.279224] mvneta f1034000.ethernet eno2: configuring for inband/2500base-x link mode
[  101.287194] mvneta f1034000.ethernet eno2: major config, requested inband/2500base-x
[  101.294986] mvneta f1034000.ethernet eno2: interface 2500base-x inband modes: pcs=02 phy=00
[  101.303423] mvneta f1034000.ethernet eno2: major config, active inband/inband,an-enabled/2500base-x
[  101.312541] mvneta f1034000.ethernet eno2: phylink_mac_config: mode=inband/2500base-x/none adv=00000000,00000000,00008000,0000a240 pause=04
[  101.325123] mvneta f1034000.ethernet eno2: pcs link down
...
[  101.447124] mvneta f1034000.ethernet eno2: phylink_sfp_connect_phy()
[  101.453541] mvneta f1034000.ethernet eno2: copper SFP: interfaces=[mac=4,9-12,19,22-23, sfp=4,23,27]
[  101.462789] mvneta f1034000.ethernet eno2: copper SFP: chosen 2500base-x interface
[  101.470563] mvneta f1034000.ethernet eno2: PHY i2c:sfp:16 uses interfaces 4,23,27, validating 4,23
[  101.479636] mvneta f1034000.ethernet eno2:  interface 4 (sgmii) rate match none supports 2-3,5-6,13
[  101.488730] mvneta f1034000.ethernet eno2:  interface 23 (2500base-x) rate match none supports 6,13,47
[  101.498079] mvneta f1034000.ethernet eno2: PHY [i2c:sfp:16] driver [Broadcom BCM84881] (irq=POLL)
[  101.507043] mvneta f1034000.ethernet eno2: phy: 2500base-x setting supported 00000000,00000000,00008000,0000206c advertising 00000000,00000000,00008000,0000206c
[  101.522979] mvneta f1034000.ethernet eno2: major config, requested inband/2500base-x
[  101.530778] mvneta f1034000.ethernet eno2: interface 2500base-x inband modes: pcs=02 phy=01
[  101.539213] mvneta f1034000.ethernet eno2: 2500base-x: incompatible in-band capabilities, trying in-band
[  101.548732] mvneta f1034000.ethernet eno2: major config, active inband/inband,an-enabled/2500base-x
[  101.557842] mvneta f1034000.ethernet eno2: phylink_mac_config: mode=inband/2500base-x/none adv=00000000,00000000,00008000,0000206c pause=04
[  101.570425] mvneta f1034000.ethernet eno2: phylink_sfp_module_start()
[  101.576903] mvneta f1034000.ethernet eno2: phylink_sfp_link_up()
[  101.692254] mvneta f1034000.ethernet eno2: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi

with the following at the top of phylink.c:

// SPDX-License-Identifier: GPL-2.0
/*
 * phylink models the MAC to optional PHY connection, supporting
 * technologies such as SFP cages where the PHY is hot-pluggable.
 *
 * Copyright (C) 2015 Russell King
 */
#define DEBUG
#include <linux/acpi.h>
...

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!