Skip to contentSkip to conversation

marvell10g tunable and power saving support

PATCH Superseded Russell King - ARM Linux admin 4 participants 25 messages Mar 3, 2020 – Apr 14, 2020

Subsystems (4)
Networking Network drivers Ethernet PHY Marvell MV88X3310 PHY driver

v2 of 3 Superseded Latest is v3 →

lore
Share & tools
lore

Russell King - ARM Linux admin

author maintainer
#0 lore raw

v2 cover marvell10g tunable and power saving support

Hi,

This patch series adds support for:
- mdix configuration (auto, mdi, mdix)
- energy detect power down (edpd)
- placing in edpd mode at probe

for both the 88x3310 and 88x2110 PHYs.

Antione, could you test this for the 88x2110 PHY please?

v2: fix comments from Antione.

 drivers/net/phy/marvell10g.c | 177 +++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 170 insertions(+), 7 deletions(-)
Signature · 3 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
#1 lore raw

PATCH v2 1/3 net: phy: marvell10g: add mdix control

Add support for controlling the MDI-X state of the PHY.

Signed-off-by Russell King <[email protected]>
---
 drivers/net/phy/marvell10g.c | 61 ++++++++++++++++++++++++++++++++++--
 1 file changed, 59 insertions(+), 2 deletions(-)
drivers/net/phy/marvell10g.c +59 -2
index 9a4e12a2af07..9d4fed782b19 100644
@@ -23,6 +23,7 @@
  * link takes priority and the other port is completely locked out.
  */
 #include <linux/ctype.h>
+#include <linux/delay.h>
 #include <linux/hwmon.h>
 #include <linux/marvell_phy.h>
 #include <linux/phy.h>

@@ -39,6 +40,12 @@ enum {
 	MV_PCS_BASE_R		= 0x1000,
 	MV_PCS_1000BASEX	= 0x2000,
 
+	MV_PCS_CSCR1		= 0x8000,
+	MV_PCS_CSCR1_MDIX_MASK	= 0x0060,
+	MV_PCS_CSCR1_MDIX_MDI	= 0x0000,
+	MV_PCS_CSCR1_MDIX_MDIX	= 0x0020,
+	MV_PCS_CSCR1_MDIX_AUTO	= 0x0060,
+
 	MV_PCS_CSSR1		= 0x8008,
 	MV_PCS_CSSR1_SPD1_MASK	= 0xc000,
 	MV_PCS_CSSR1_SPD1_SPD2	= 0xc000,

@@ -216,6 +223,26 @@ static int mv3310_hwmon_probe(struct phy_device *phydev)
 }
 #endif
 
+static int mv3310_reset(struct phy_device *phydev, u32 unit)
+{
+	int retries, val, err;
+
+	err = phy_modify_mmd(phydev, MDIO_MMD_PCS, unit + MDIO_CTRL1,
+			     MDIO_CTRL1_RESET, MDIO_CTRL1_RESET);
+	if (err < 0)
+		return err;
+
+	retries = 20;
+	do {
+		msleep(5);
+		val = phy_read_mmd(phydev, MDIO_MMD_PCS, unit + MDIO_CTRL1);
+		if (val < 0)
+			return val;
+	} while (val & MDIO_CTRL1_RESET && --retries);
+
+	return val & MDIO_CTRL1_RESET ? -ETIMEDOUT : 0;
+}
+
 static int mv3310_sfp_insert(void *upstream, const struct sfp_eeprom_id *id)
 {
 	struct phy_device *phydev = upstream;

@@ -316,6 +343,8 @@ static int mv3310_config_init(struct phy_device *phydev)
 	    phydev->interface != PHY_INTERFACE_MODE_10GBASER)
 		return -ENODEV;
 
+	phydev->mdix_ctrl = ETH_TP_MDI_AUTO;
+
 	return 0;
 }
 

@@ -345,14 +374,42 @@ static int mv3310_get_features(struct phy_device *phydev)
 	return 0;
 }
 
+static int mv3310_config_mdix(struct phy_device *phydev)
+{
+	u16 val;
+	int err;
+
+	switch (phydev->mdix_ctrl) {
+	case ETH_TP_MDI_AUTO:
+		val = MV_PCS_CSCR1_MDIX_AUTO;
+		break;
+	case ETH_TP_MDI_X:
+		val = MV_PCS_CSCR1_MDIX_MDIX;
+		break;
+	case ETH_TP_MDI:
+		val = MV_PCS_CSCR1_MDIX_MDI;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	err = phy_modify_mmd_changed(phydev, MDIO_MMD_PCS, MV_PCS_CSCR1,
+				     MV_PCS_CSCR1_MDIX_MASK, val);
+	if (err > 0)
+		err = mv3310_reset(phydev, MV_PCS_BASE_T);
+
+	return err;
+}
+
 static int mv3310_config_aneg(struct phy_device *phydev)
 {
 	bool changed = false;
 	u16 reg;
 	int ret;
 
-	/* We don't support manual MDI control */
-	phydev->mdix_ctrl = ETH_TP_MDI_AUTO;
+	ret = mv3310_config_mdix(phydev);
+	if (ret < 0)
+		return ret;
 
 	if (phydev->autoneg == AUTONEG_DISABLE)
 		return genphy_c45_pma_setup_forced(phydev);
Signature · 1 line
2.20.1
#5 lore raw

PATCH v2 2/3 net: phy: marvell10g: add energy detect power down tunable

In reply to Russell King - ARM Linux admin

Add support for the energy detect power down tunable, which saves around 600mW when the link is down. The 88x3310 supports off, rx-only and NLP every second. Enable EDPD by default for 88x3310.

Signed-off-by Russell King <[email protected]>
---
 drivers/net/phy/marvell10g.c | 86 +++++++++++++++++++++++++++++++++++-
 1 file changed, 85 insertions(+), 1 deletion(-)
drivers/net/phy/marvell10g.c +85 -1
index 9d4fed782b19..148c07b59a9e 100644
@@ -41,6 +41,10 @@ enum {
 	MV_PCS_1000BASEX	= 0x2000,
 
 	MV_PCS_CSCR1		= 0x8000,
+	MV_PCS_CSCR1_ED_MASK	= 0x0300,
+	MV_PCS_CSCR1_ED_OFF	= 0x0000,
+	MV_PCS_CSCR1_ED_RX	= 0x0200,
+	MV_PCS_CSCR1_ED_NLP	= 0x0300,
 	MV_PCS_CSCR1_MDIX_MASK	= 0x0060,
 	MV_PCS_CSCR1_MDIX_MDI	= 0x0000,
 	MV_PCS_CSCR1_MDIX_MDIX	= 0x0020,

@@ -243,6 +247,59 @@ static int mv3310_reset(struct phy_device *phydev, u32 unit)
 	return val & MDIO_CTRL1_RESET ? -ETIMEDOUT : 0;
 }
 
+static int mv3310_get_edpd(struct phy_device *phydev, u16 *edpd)
+{
+	int val;
+
+	val = phy_read_mmd(phydev, MDIO_MMD_PCS, MV_PCS_CSCR1);
+	if (val < 0)
+		return val;
+
+	switch (val & MV_PCS_CSCR1_ED_MASK) {
+	case MV_PCS_CSCR1_ED_NLP:
+		*edpd = 1000;
+		break;
+	case MV_PCS_CSCR1_ED_RX:
+		*edpd = ETHTOOL_PHY_EDPD_NO_TX;
+		break;
+	default:
+		*edpd = ETHTOOL_PHY_EDPD_DISABLE;
+		break;
+	}
+	return 0;
+}
+
+static int mv3310_set_edpd(struct phy_device *phydev, u16 edpd)
+{
+	u16 val;
+	int err;
+
+	switch (edpd) {
+	case 1000:
+	case ETHTOOL_PHY_EDPD_DFLT_TX_MSECS:
+		val = MV_PCS_CSCR1_ED_NLP;
+		break;
+
+	case ETHTOOL_PHY_EDPD_NO_TX:
+		val = MV_PCS_CSCR1_ED_RX;
+		break;
+
+	case ETHTOOL_PHY_EDPD_DISABLE:
+		val = MV_PCS_CSCR1_ED_OFF;
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	err = phy_modify_mmd_changed(phydev, MDIO_MMD_PCS, MV_PCS_CSCR1,
+				     MV_PCS_CSCR1_ED_MASK, val);
+	if (err > 0)
+		err = mv3310_reset(phydev, MV_PCS_BASE_T);
+
+	return err;
+}
+
 static int mv3310_sfp_insert(void *upstream, const struct sfp_eeprom_id *id)
 {
 	struct phy_device *phydev = upstream;

@@ -345,7 +402,8 @@ static int mv3310_config_init(struct phy_device *phydev)
 
 	phydev->mdix_ctrl = ETH_TP_MDI_AUTO;
 
-	return 0;
+	/* Enable EDPD mode - saving 600mW */
+	return mv3310_set_edpd(phydev, ETHTOOL_PHY_EDPD_DFLT_TX_MSECS);
 }
 
 static int mv3310_get_features(struct phy_device *phydev)

@@ -594,6 +652,28 @@ static int mv3310_read_status(struct phy_device *phydev)
 	return 0;
 }
 
+static int mv3310_get_tunable(struct phy_device *phydev,
+			      struct ethtool_tunable *tuna, void *data)
+{
+	switch (tuna->id) {
+	case ETHTOOL_PHY_EDPD:
+		return mv3310_get_edpd(phydev, data);
+	default:
+		return -EINVAL;
+	}
+}
+
+static int mv3310_set_tunable(struct phy_device *phydev,
+			      struct ethtool_tunable *tuna, const void *data)
+{
+	switch (tuna->id) {
+	case ETHTOOL_PHY_EDPD:
+		return mv3310_set_edpd(phydev, *(u16 *)data);
+	default:
+		return -EINVAL;
+	}
+}
+
 static struct phy_driver mv3310_drivers[] = {
 	{
 		.phy_id		= MARVELL_PHY_ID_88X3310,

@@ -608,6 +688,8 @@ static struct phy_driver mv3310_drivers[] = {
 		.config_aneg	= mv3310_config_aneg,
 		.aneg_done	= mv3310_aneg_done,
 		.read_status	= mv3310_read_status,
+		.get_tunable	= mv3310_get_tunable,
+		.set_tunable	= mv3310_set_tunable,
 	},
 	{
 		.phy_id		= MARVELL_PHY_ID_88E2110,

@@ -621,6 +703,8 @@ static struct phy_driver mv3310_drivers[] = {
 		.config_aneg	= mv3310_config_aneg,
 		.aneg_done	= mv3310_aneg_done,
 		.read_status	= mv3310_read_status,
+		.get_tunable	= mv3310_get_tunable,
+		.set_tunable	= mv3310_set_tunable,
 	},
 };
Signature · 1 line
2.20.1
#7 lore raw

PATCH v2 3/3 net: phy: marvell10g: place in powersave mode at probe

In reply to Russell King - ARM Linux admin

Place the 88x3310 into powersaving mode when probing, which saves 600mW per PHY. For both PHYs on the Macchiatobin double-shot, this saves about 10% of the board idle power.

Signed-off-by Russell King <[email protected]>
---
 drivers/net/phy/marvell10g.c | 30 ++++++++++++++++++++++++++----
 1 file changed, 26 insertions(+), 4 deletions(-)
drivers/net/phy/marvell10g.c +26 -4
index 148c07b59a9e..5939b8ab9a96 100644
@@ -227,6 +227,18 @@ static int mv3310_hwmon_probe(struct phy_device *phydev)
 }
 #endif
 
+static int mv3310_power_down(struct phy_device *phydev)
+{
+	return phy_set_bits_mmd(phydev, MDIO_MMD_VEND2, MV_V2_PORT_CTRL,
+				MV_V2_PORT_CTRL_PWRDOWN);
+}
+
+static int mv3310_power_up(struct phy_device *phydev)
+{
+	return phy_clear_bits_mmd(phydev, MDIO_MMD_VEND2, MV_V2_PORT_CTRL,
+				  MV_V2_PORT_CTRL_PWRDOWN);
+}
+
 static int mv3310_reset(struct phy_device *phydev, u32 unit)
 {
 	int retries, val, err;

@@ -348,6 +360,11 @@ static int mv3310_probe(struct phy_device *phydev)
 
 	dev_set_drvdata(&phydev->mdio.dev, priv);
 
+	/* Powering down the port when not in use saves about 600mW */
+	ret = mv3310_power_down(phydev);
+	if (ret)
+		return ret;
+
 	ret = mv3310_hwmon_probe(phydev);
 	if (ret)
 		return ret;

@@ -357,16 +374,14 @@ static int mv3310_probe(struct phy_device *phydev)
 
 static int mv3310_suspend(struct phy_device *phydev)
 {
-	return phy_set_bits_mmd(phydev, MDIO_MMD_VEND2, MV_V2_PORT_CTRL,
-				MV_V2_PORT_CTRL_PWRDOWN);
+	return mv3310_power_down(phydev);
 }
 
 static int mv3310_resume(struct phy_device *phydev)
 {
 	int ret;
 
-	ret = phy_clear_bits_mmd(phydev, MDIO_MMD_VEND2, MV_V2_PORT_CTRL,
-				 MV_V2_PORT_CTRL_PWRDOWN);
+	ret = mv3310_power_up(phydev);
 	if (ret)
 		return ret;
 

@@ -392,6 +407,8 @@ static bool mv3310_has_pma_ngbaset_quirk(struct phy_device *phydev)
 
 static int mv3310_config_init(struct phy_device *phydev)
 {
+	int err;
+
 	/* Check that the PHY interface type is compatible */
 	if (phydev->interface != PHY_INTERFACE_MODE_SGMII &&
 	    phydev->interface != PHY_INTERFACE_MODE_2500BASEX &&

@@ -402,6 +419,11 @@ static int mv3310_config_init(struct phy_device *phydev)
 
 	phydev->mdix_ctrl = ETH_TP_MDI_AUTO;
 
+	/* Power up so reset works */
+	err = mv3310_power_up(phydev);
+	if (err)
+		return err;
+
 	/* Enable EDPD mode - saving 600mW */
 	return mv3310_set_edpd(phydev, ETHTOOL_PHY_EDPD_DFLT_TX_MSECS);
 }
Signature · 1 line
2.20.1
maintainer
#2 lore raw

Re: [PATCH net-next v2 1/3] net: phy: marvell10g: add mdix control

In reply to Russell King
Quoted 8 lines
drivers/net/phy/marvell10g.c +8 -0
+static int mv3310_reset(struct phy_device *phydev, u32 unit)
+{
+	int retries, val, err;
+
+	err = phy_modify_mmd(phydev, MDIO_MMD_PCS, unit + MDIO_CTRL1,
+			     MDIO_CTRL1_RESET, MDIO_CTRL1_RESET);
+	if (err < 0)
+		return err;

drivers/net/phy/marvell10g.c static int mv3310_hwmon_probe(struct phy_device *phydev) · line 243

Quoted 10 lines
drivers/net/phy/marvell10g.c +10 -0
+
+	retries = 20;
+	do {
+		msleep(5);
+		val = phy_read_mmd(phydev, MDIO_MMD_PCS, unit + MDIO_CTRL1);
+		if (val < 0)
+			return val;
+	} while (val & MDIO_CTRL1_RESET && --retries);
+
+	return val & MDIO_CTRL1_RESET ? -ETIMEDOUT : 0;

Hi Russell

I've often seen people get this sort of polling loop wrong. So i generally point people towards include/linux/iopoll.h.

I wonder if it would be helpful to add phy_read_mmd_poll_timeout() and maybe phy_read_poll_timeout() to phy-core.c?

Just an idea, not a blocker for the patch.

Andrew

maintainer
#6 lore raw

Re: [PATCH net-next v2 2/3] net: phy: marvell10g: add energy detect power down tunable

In reply to Russell King
Quoted 11 lines
drivers/net/phy/marvell10g.c +11 -0
+static int mv3310_get_tunable(struct phy_device *phydev,
+			      struct ethtool_tunable *tuna, void *data)
+{
+	switch (tuna->id) {
+	case ETHTOOL_PHY_EDPD:
+		return mv3310_get_edpd(phydev, data);
+	default:
+		return -EINVAL;
+	}
+}
+

drivers/net/phy/marvell10g.c static int mv3310_read_status(struct phy_device *phydev) · line 675

Quoted 10 lines
drivers/net/phy/marvell10g.c +10 -0
+static int mv3310_set_tunable(struct phy_device *phydev,
+			      struct ethtool_tunable *tuna, const void *data)
+{
+	switch (tuna->id) {
+	case ETHTOOL_PHY_EDPD:
+		return mv3310_set_edpd(phydev, *(u16 *)data);
+	default:
+		return -EINVAL;
+	}
+}

Hi Russell

Looking at other PHY drivers, all but mscc.c return EOPNOTSUPP. mscc.c is the only other driver which returns EINVAL. EOPNOTSUPP does seem more appropriate.

Thanks
Andrew

author maintainer
#3 lore raw

Re: [PATCH net-next v2 1/3] net: phy: marvell10g: add mdix control

In reply to Andrew Lunn
Quoted 21 lines · Andrew Lunn
Quoted 8 lines
drivers/net/phy/marvell10g.c +8 -0
+static int mv3310_reset(struct phy_device *phydev, u32 unit)
+{
+	int retries, val, err;
+
+	err = phy_modify_mmd(phydev, MDIO_MMD_PCS, unit + MDIO_CTRL1,
+			     MDIO_CTRL1_RESET, MDIO_CTRL1_RESET);
+	if (err < 0)
+		return err;

drivers/net/phy/marvell10g.c static int mv3310_hwmon_probe(struct phy_device *phydev) · line 243

Quoted 10 lines
drivers/net/phy/marvell10g.c +10 -0
+
+	retries = 20;
+	do {
+		msleep(5);
+		val = phy_read_mmd(phydev, MDIO_MMD_PCS, unit + MDIO_CTRL1);
+		if (val < 0)
+			return val;
+	} while (val & MDIO_CTRL1_RESET && --retries);
+
+	return val & MDIO_CTRL1_RESET ? -ETIMEDOUT : 0;

Hi Russell

Quoted 2 lines

I've often seen people get this sort of polling loop wrong. So i generally point people towards include/linux/iopoll.h.

The above comes from phy_poll_reset().

Quoted 2 lines

I wonder if it would be helpful to add phy_read_mmd_poll_timeout() and maybe phy_read_poll_timeout() to phy-core.c?

Maybe, if it becomes more prevalent.

We do have one version in aquantia_main.c which does the wrong test-register, sleep, timeout sequence, which looks to be the only case that is wrong.

So, if we want to do this, it should be a separate series, fixing all locations at the same time.

Signature · 3 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
maintainer
#4 lore raw

Re: [PATCH net-next v2 1/3] net: phy: marvell10g: add mdix control

Quoted 2 lines

So, if we want to do this, it should be a separate series, fixing all locations at the same time.

Hi Russell

A separate series is good for me.

Andrew

#9 lore raw

Re: [PATCH net-next v2 3/3] net: phy: marvell10g: place in powersave mode at probe

In reply to Russell King
Quoted 6 lines · Russell King

Place the 88x3310 into powersaving mode when probing, which saves 600mW per PHY. For both PHYs on the Macchiatobin double-shot, this saves about 10% of the board idle power.

Signed-off-by Russell King <[email protected]>

Hi,

I have a Macchiatobin double shot, and my 10G ports stop working after this change.
I reverted this commit on top of latest net-next and now the ports work again.

Bye,

Signature · 2 lines
Matteo Croce
per aspera ad upstream
author maintainer
#10 lore raw

Re: [PATCH net-next v2 3/3] net: phy: marvell10g: place in powersave mode at probe

Quoted 6 lines · Matteo Croce
Quoted 5 lines · Russell King

Place the 88x3310 into powersaving mode when probing, which saves 600mW per PHY. For both PHYs on the Macchiatobin double-shot, this saves about 10% of the board idle power.

Quoted 7 lines
Quoted 1 line
Signed-off-by Russell King <[email protected]>

Hi,

I have a Macchiatobin double shot, and my 10G ports stop working after this change.
I reverted this commit on top of latest net-next and now the ports work again.

Please describe the problem in more detail.

Do you have the interface up? Does the PHY link with the partner? Is the problem just that traffic isn't passed?

Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
author maintainer
#11 lore raw

Re: [PATCH net-next v2 3/3] net: phy: marvell10g: place in powersave mode at probe

Quoted 11 lines · Russell King - ARM Linux admin
Quoted 10 lines · Matteo Croce
Quoted 6 lines · Russell King

Place the 88x3310 into powersaving mode when probing, which saves 600mW per PHY. For both PHYs on the Macchiatobin double-shot, this saves about 10% of the board idle power.

Signed-off-by Russell King <[email protected]>

Hi,

Quoted 8 lines
Quoted 3 lines

I have a Macchiatobin double shot, and my 10G ports stop working after this change.
I reverted this commit on top of latest net-next and now the ports work again.

Please describe the problem in more detail.

Do you have the interface up? Does the PHY link with the partner? Is the problem just that traffic isn't passed?

I've just retested on my Macchiatobin double shot, and it works fine. What revision PHYs do you have? Unfortunately, you can't read the PHY ID except using mii-diag:

# mii-diag eth0 -p 32769

or

# mii-diag eth1 -p 33025

Looking at word 3 and 4, it will be either:

002b 09aa
002b 09ab

Thanks.

Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
#12 lore raw

Re: [PATCH net-next v2 3/3] net: phy: marvell10g: place in powersave mode at probe

Quoted 34 lines · Russell King - ARM Linux admin
Quoted 11 lines · Russell King - ARM Linux admin
Quoted 10 lines · Matteo Croce
Quoted 6 lines · Russell King

Place the 88x3310 into powersaving mode when probing, which saves 600mW per PHY. For both PHYs on the Macchiatobin double-shot, this saves about 10% of the board idle power.

Signed-off-by Russell King <[email protected]>

Hi,

Quoted 8 lines
Quoted 3 lines

I have a Macchiatobin double shot, and my 10G ports stop working after this change.
I reverted this commit on top of latest net-next and now the ports work again.

Please describe the problem in more detail.

Do you have the interface up? Does the PHY link with the partner? Is the problem just that traffic isn't passed?

I've just retested on my Macchiatobin double shot, and it works fine. What revision PHYs do you have? Unfortunately, you can't read the PHY ID except using mii-diag:

# mii-diag eth0 -p 32769

or

# mii-diag eth1 -p 33025

Looking at word 3 and 4, it will be either:

Quoted 9 lines

002b 09aa
002b 09ab

Thanks.

--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

Hi Russel,

I have the interface up connected via a DAC Cable to an i40e card. When I set the link up I detect the carrier:

mvpp2 f2000000.ethernet eth0: PHY [f212a600.mdio-mii:00] driver [mv88x3310] (irq=POLL)
mvpp2 f2000000.ethernet eth0: configuring for phy/10gbase-r link mode mvpp2 f2000000.ethernet eth0: Link is Up - 10Gbps/Full - flow control off

No traffic is received or can be sent.

How can I read the PHY revision?

Thanks,

Signature · 2 lines
Matteo Croce
per aspera ad upstream
author maintainer
#13 lore raw

Re: [PATCH net-next v2 3/3] net: phy: marvell10g: place in powersave mode at probe

Quoted 52 lines · Matteo Croce
Quoted 34 lines · Russell King - ARM Linux admin
Quoted 11 lines · Russell King - ARM Linux admin
Quoted 10 lines · Matteo Croce
Quoted 6 lines · Russell King

Place the 88x3310 into powersaving mode when probing, which saves 600mW per PHY. For both PHYs on the Macchiatobin double-shot, this saves about 10% of the board idle power.

Signed-off-by Russell King <[email protected]>

Hi,

Quoted 8 lines
Quoted 3 lines

I have a Macchiatobin double shot, and my 10G ports stop working after this change.
I reverted this commit on top of latest net-next and now the ports work again.

Please describe the problem in more detail.

Do you have the interface up? Does the PHY link with the partner? Is the problem just that traffic isn't passed?

I've just retested on my Macchiatobin double shot, and it works fine. What revision PHYs do you have? Unfortunately, you can't read the PHY ID except using mii-diag:

# mii-diag eth0 -p 32769

or

# mii-diag eth1 -p 33025

Looking at word 3 and 4, it will be either:

Quoted 9 lines

002b 09aa
002b 09ab

Thanks.

--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

Hi Russel,

I have the interface up connected via a DAC Cable to an i40e card. When I set the link up I detect the carrier:

Quoted 8 lines

mvpp2 f2000000.ethernet eth0: PHY [f212a600.mdio-mii:00] driver [mv88x3310] (irq=POLL)
mvpp2 f2000000.ethernet eth0: configuring for phy/10gbase-r link mode mvpp2 f2000000.ethernet eth0: Link is Up - 10Gbps/Full - flow control off

No traffic is received or can be sent.

How can I read the PHY revision?

I gave details in the email you just replied to - you have to use mii-diag, there's no other way.

Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
author maintainer
#14 lore raw

Re: [PATCH net-next v2 3/3] net: phy: marvell10g: place in powersave mode at probe

In reply to Matteo Croce
Quoted 52 lines · Matteo Croce
Quoted 34 lines · Russell King - ARM Linux admin
Quoted 11 lines · Russell King - ARM Linux admin
Quoted 10 lines · Matteo Croce
Quoted 6 lines · Russell King

Place the 88x3310 into powersaving mode when probing, which saves 600mW per PHY. For both PHYs on the Macchiatobin double-shot, this saves about 10% of the board idle power.

Signed-off-by Russell King <[email protected]>

Hi,

Quoted 8 lines
Quoted 3 lines

I have a Macchiatobin double shot, and my 10G ports stop working after this change.
I reverted this commit on top of latest net-next and now the ports work again.

Please describe the problem in more detail.

Do you have the interface up? Does the PHY link with the partner? Is the problem just that traffic isn't passed?

I've just retested on my Macchiatobin double shot, and it works fine. What revision PHYs do you have? Unfortunately, you can't read the PHY ID except using mii-diag:

# mii-diag eth0 -p 32769

or

# mii-diag eth1 -p 33025

Looking at word 3 and 4, it will be either:

Quoted 9 lines

002b 09aa
002b 09ab

Thanks.

--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

Hi Russel,

I have the interface up connected via a DAC Cable to an i40e card. When I set the link up I detect the carrier:

Quoted 6 lines

mvpp2 f2000000.ethernet eth0: PHY [f212a600.mdio-mii:00] driver [mv88x3310] (irq=POLL)
mvpp2 f2000000.ethernet eth0: configuring for phy/10gbase-r link mode mvpp2 f2000000.ethernet eth0: Link is Up - 10Gbps/Full - flow control off

No traffic is received or can be sent.

I've just tried with a DAC cable ("Molex Inc. 74752-9542")... works for me:

root@mcbin-ds:~# ip li set dev eth0 down
mvpp2 f2000000.ethernet eth0: Link is Down
root@mcbin-ds:~# ip li set dev eth0 up
mvpp2 f2000000.ethernet eth0: PHY [f212a600.mdio-mii:00] driver [mv88x3310] (irq=POLL)
mvpp2 f2000000.ethernet eth0: configuring for phy/10gbase-r link mode
root@mcbin-ds:~# mvpp2 f2000000.ethernet eth0: Link is Up - 10Gbps/Full - flow control off
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
root@mcbin-ds:~# ping6 -I eth0 fe80::202:c9ff:fe54:d70a
ping6: Warning: source address might be selected on device other than eth0.
PING fe80::202:c9ff:fe54:d70a(fe80::202:c9ff:fe54:d70a) from :: eth0: 56 data bytes
64 bytes from fe80::202:c9ff:fe54:d70a%eth0: icmp_seq=1 ttl=64 time=0.344 ms
64 bytes from fe80::202:c9ff:fe54:d70a%eth0: icmp_seq=2 ttl=64 time=0.129 ms
64 bytes from fe80::202:c9ff:fe54:d70a%eth0: icmp_seq=3 ttl=64 time=0.118 ms
^C
--- fe80::202:c9ff:fe54:d70a ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 54ms
rtt min/avg/max/mdev = 0.118/0.197/0.344/0.104 ms

where fe80::202:c9ff:fe54:d70a is the IPv6 link local address on a Mellanox card in a different machine at the other end of the DAC cable.

Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
#15 lore raw

Re: [PATCH net-next v2 3/3] net: phy: marvell10g: place in powersave mode at probe

Quoted 83 lines · Russell King - ARM Linux admin
Quoted 52 lines · Matteo Croce
Quoted 34 lines · Russell King - ARM Linux admin
Quoted 11 lines · Russell King - ARM Linux admin
Quoted 10 lines · Matteo Croce
Quoted 6 lines · Russell King

Place the 88x3310 into powersaving mode when probing, which saves 600mW per PHY. For both PHYs on the Macchiatobin double-shot, this saves about 10% of the board idle power.

Signed-off-by Russell King <[email protected]>

Hi,

Quoted 8 lines
Quoted 3 lines

I have a Macchiatobin double shot, and my 10G ports stop working after this change.
I reverted this commit on top of latest net-next and now the ports work again.

Please describe the problem in more detail.

Do you have the interface up? Does the PHY link with the partner? Is the problem just that traffic isn't passed?

I've just retested on my Macchiatobin double shot, and it works fine. What revision PHYs do you have? Unfortunately, you can't read the PHY ID except using mii-diag:

# mii-diag eth0 -p 32769

or

# mii-diag eth1 -p 33025

Looking at word 3 and 4, it will be either:

Quoted 9 lines

002b 09aa
002b 09ab

Thanks.

--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

Hi Russel,

I have the interface up connected via a DAC Cable to an i40e card. When I set the link up I detect the carrier:

Quoted 6 lines

mvpp2 f2000000.ethernet eth0: PHY [f212a600.mdio-mii:00] driver [mv88x3310] (irq=POLL)
mvpp2 f2000000.ethernet eth0: configuring for phy/10gbase-r link mode mvpp2 f2000000.ethernet eth0: Link is Up - 10Gbps/Full - flow control off

No traffic is received or can be sent.

I've just tried with a DAC cable ("Molex Inc. 74752-9542")... works for me:

root@mcbin-ds:~# ip li set dev eth0 down
mvpp2 f2000000.ethernet eth0: Link is Down
root@mcbin-ds:~# ip li set dev eth0 up
mvpp2 f2000000.ethernet eth0: PHY [f212a600.mdio-mii:00] driver [mv88x3310] (irq=POLL)
mvpp2 f2000000.ethernet eth0: configuring for phy/10gbase-r link mode
root@mcbin-ds:~# mvpp2 f2000000.ethernet eth0: Link is Up - 10Gbps/Full - flow control off
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
root@mcbin-ds:~# ping6 -I eth0 fe80::202:c9ff:fe54:d70a
ping6: Warning: source address might be selected on device other than eth0.
PING fe80::202:c9ff:fe54:d70a(fe80::202:c9ff:fe54:d70a) from :: eth0: 56 data bytes
64 bytes from fe80::202:c9ff:fe54:d70a%eth0: icmp_seq=1 ttl=64 time=0.344 ms
64 bytes from fe80::202:c9ff:fe54:d70a%eth0: icmp_seq=2 ttl=64 time=0.129 ms
64 bytes from fe80::202:c9ff:fe54:d70a%eth0: icmp_seq=3 ttl=64 time=0.118 ms
^C
--- fe80::202:c9ff:fe54:d70a ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 54ms
rtt min/avg/max/mdev = 0.118/0.197/0.344/0.104 ms
Quoted 8 lines

where fe80::202:c9ff:fe54:d70a is the IPv6 link local address on a Mellanox card in a different machine at the other end of the DAC cable.

--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

Hi Russel,

that's it:

# ./mii-diag eth0 -p 32769
Using the specified MII PHY index 32769.
Basic registers of MII PHY #32769:  2040 0082 002b 09ab 0071 009a c000 0009.
 Basic mode control register 0x2040: Auto-negotiation disabled, with
 Speed fixed at 100 mbps, half-duplex.
 Basic mode status register 0x0082 ... 0082.
   Link status: not established.
   *** Link Jabber! ***
 Your link partner is generating 100baseTx link beat  (no autonegotiation).
   End of basic transceiver information.
root@macchiatobin:~# ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
mode DEFAULT group default qlen 2048
    link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff

But no traffic in any direction

Thanks,

Signature · 2 lines
Matteo Croce
per aspera ad upstream
author maintainer
#16 lore raw

Re: [PATCH net-next v2 3/3] net: phy: marvell10g: place in powersave mode at probe

Quoted 109 lines · Matteo Croce
Quoted 83 lines · Russell King - ARM Linux admin
Quoted 52 lines · Matteo Croce
Quoted 34 lines · Russell King - ARM Linux admin
Quoted 11 lines · Russell King - ARM Linux admin
Quoted 10 lines · Matteo Croce
Quoted 6 lines · Russell King

Place the 88x3310 into powersaving mode when probing, which saves 600mW per PHY. For both PHYs on the Macchiatobin double-shot, this saves about 10% of the board idle power.

Signed-off-by Russell King <[email protected]>

Hi,

Quoted 8 lines
Quoted 3 lines

I have a Macchiatobin double shot, and my 10G ports stop working after this change.
I reverted this commit on top of latest net-next and now the ports work again.

Please describe the problem in more detail.

Do you have the interface up? Does the PHY link with the partner? Is the problem just that traffic isn't passed?

I've just retested on my Macchiatobin double shot, and it works fine. What revision PHYs do you have? Unfortunately, you can't read the PHY ID except using mii-diag:

# mii-diag eth0 -p 32769

or

# mii-diag eth1 -p 33025

Looking at word 3 and 4, it will be either:

Quoted 9 lines

002b 09aa
002b 09ab

Thanks.

--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

Hi Russel,

I have the interface up connected via a DAC Cable to an i40e card. When I set the link up I detect the carrier:

Quoted 6 lines

mvpp2 f2000000.ethernet eth0: PHY [f212a600.mdio-mii:00] driver [mv88x3310] (irq=POLL)
mvpp2 f2000000.ethernet eth0: configuring for phy/10gbase-r link mode mvpp2 f2000000.ethernet eth0: Link is Up - 10Gbps/Full - flow control off

No traffic is received or can be sent.

I've just tried with a DAC cable ("Molex Inc. 74752-9542")... works for me:

root@mcbin-ds:~# ip li set dev eth0 down
mvpp2 f2000000.ethernet eth0: Link is Down
root@mcbin-ds:~# ip li set dev eth0 up
mvpp2 f2000000.ethernet eth0: PHY [f212a600.mdio-mii:00] driver [mv88x3310] (irq=POLL)
mvpp2 f2000000.ethernet eth0: configuring for phy/10gbase-r link mode
root@mcbin-ds:~# mvpp2 f2000000.ethernet eth0: Link is Up - 10Gbps/Full - flow control off
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
root@mcbin-ds:~# ping6 -I eth0 fe80::202:c9ff:fe54:d70a
ping6: Warning: source address might be selected on device other than eth0.
PING fe80::202:c9ff:fe54:d70a(fe80::202:c9ff:fe54:d70a) from :: eth0: 56 data bytes
64 bytes from fe80::202:c9ff:fe54:d70a%eth0: icmp_seq=1 ttl=64 time=0.344 ms
64 bytes from fe80::202:c9ff:fe54:d70a%eth0: icmp_seq=2 ttl=64 time=0.129 ms
64 bytes from fe80::202:c9ff:fe54:d70a%eth0: icmp_seq=3 ttl=64 time=0.118 ms
^C
--- fe80::202:c9ff:fe54:d70a ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 54ms
rtt min/avg/max/mdev = 0.118/0.197/0.344/0.104 ms
Quoted 8 lines

where fe80::202:c9ff:fe54:d70a is the IPv6 link local address on a Mellanox card in a different machine at the other end of the DAC cable.

--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

Hi Russel,

that's it:

# ./mii-diag eth0 -p 32769
Using the specified MII PHY index 32769.
Basic registers of MII PHY #32769:  2040 0082 002b 09ab 0071 009a c000 0009.
 Basic mode control register 0x2040: Auto-negotiation disabled, with
 Speed fixed at 100 mbps, half-duplex.
 Basic mode status register 0x0082 ... 0082.
   Link status: not established.
   *** Link Jabber! ***
 Your link partner is generating 100baseTx link beat  (no autonegotiation).
   End of basic transceiver information.
Quoted 6 lines
root@macchiatobin:~# ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
mode DEFAULT group default qlen 2048
    link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff

But no traffic in any direction

So you have the same version PHY hardware as I do.

So, we need further diagnosis, which isn't possible without a more advanced mii-diag tool - I'm sorting that out now, and will provide a link to a git repo later this afternoon.

Thanks.

Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
#17 lore raw

Re: [PATCH net-next v2 3/3] net: phy: marvell10g: place in powersave mode at probe

Quoted 22 lines · Russell King - ARM Linux admin
Quoted 20 lines · Matteo Croce
Quoted 2 lines · Russell King - ARM Linux admin

On Fri, Apr 10, 2020 at 04:39:48PM +0200, Matteo Croce wrote:

# ./mii-diag eth0 -p 32769
Using the specified MII PHY index 32769.
Basic registers of MII PHY #32769:  2040 0082 002b 09ab 0071 009a c000 0009.
 Basic mode control register 0x2040: Auto-negotiation disabled, with
 Speed fixed at 100 mbps, half-duplex.
 Basic mode status register 0x0082 ... 0082.
   Link status: not established.
   *** Link Jabber! ***
 Your link partner is generating 100baseTx link beat  (no autonegotiation).
   End of basic transceiver information.
root@macchiatobin:~# ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
mode DEFAULT group default qlen 2048
    link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff
Quoted 8 lines
Quoted 1 line

But no traffic in any direction

So you have the same version PHY hardware as I do.

So, we need further diagnosis, which isn't possible without a more advanced mii-diag tool - I'm sorting that out now, and will provide a link to a git repo later this afternoon.

Ok, I'll wait for the tool

Thanks a lot,

Signature · 2 lines
Matteo Croce
per aspera ad upstream
author maintainer
#18 lore raw

Re: [PATCH net-next v2 3/3] net: phy: marvell10g: place in powersave mode at probe

Quoted 26 lines · Matteo Croce
Quoted 24 lines · Russell King - ARM Linux admin
Quoted 21 lines · Matteo Croce
Quoted 2 lines · Russell King - ARM Linux admin

On Fri, Apr 10, 2020 at 04:39:48PM +0200, Matteo Croce wrote:

# ./mii-diag eth0 -p 32769
Using the specified MII PHY index 32769.
Basic registers of MII PHY #32769:  2040 0082 002b 09ab 0071 009a c000 0009.
 Basic mode control register 0x2040: Auto-negotiation disabled, with
 Speed fixed at 100 mbps, half-duplex.
 Basic mode status register 0x0082 ... 0082.
   Link status: not established.
   *** Link Jabber! ***
 Your link partner is generating 100baseTx link beat  (no autonegotiation).
   End of basic transceiver information.
root@macchiatobin:~# ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
mode DEFAULT group default qlen 2048
    link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff

But no traffic in any direction

Quoted 8 lines
Quoted 6 lines

So you have the same version PHY hardware as I do.

So, we need further diagnosis, which isn't possible without a more advanced mii-diag tool - I'm sorting that out now, and will provide a link to a git repo later this afternoon.

Ok, I'll wait for the tool

Okay, please give this a go:

	git://git.armlinux.org.uk/~rmk/mii-diag/

Please send me the full output from:

# ./mii-diag eth0 -v -p 32768

It does colourise some of the output (which I should make conditional) so don't be surprised if there's some escape codes in the output. Please take this as alpha software; it needs a more work, and please don't bother Donald Becker about it either!

You should see something like this:

mii-diag.c:v2.11 3/21/2005 Donald Becker ([email protected])
http://www.scyld.com/diag/index.html
Using the new SIOCGMIIPHY value on PHY 0 (BMCR 0x2040).
Using the specified MII PHY index 32768.
No MII transceiver present!.
Use '--force' to view the information anyway.
libmii.c:v2.11 2/28/2005 Donald Becker ([email protected])
http://www.scyld.com/diag/index.html

MII PHY #0:1 PMA/PMD transceiver registers:
2040 0082 002b 09ab 0071 009a c000 0009 9701 0000 0000 01a4 0000 0000 002b 09ab 0000 0000 0000 0000 0000 0003 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:0a:c2:--:--:--, model 26 rev. 11.
Vendor/Part: Marvell Semiconductor 88X3310.
...

For a SFP cage connection, the relevant parts are:

MII PHY #0:3 PCS Subdevice #2 transceiver registers MII PHY #0:4 PHY XS Subdevice #2 transceiver registers MII PHY #0:7 AN Subdevice #2 transceiver registers MII PHY #0:7 AN Subdevice #3 transceiver registers

which should all say that link is established.

Also, note that the 88x3310 is setup to link with the _first_ media type that comes up, so if you have both a connection through the SFP+ cage and copper, the first that establishes link will be active and the other media will remain inactive. So, only have either the SFP+ cage populated or the RJ45, never both.

Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
#19 lore raw

Re: [PATCH net-next v2 3/3] net: phy: marvell10g: place in powersave mode at probe

Quoted 37 lines · Russell King - ARM Linux admin
Quoted 26 lines · Matteo Croce
Quoted 24 lines · Russell King - ARM Linux admin
Quoted 21 lines · Matteo Croce
Quoted 2 lines · Russell King - ARM Linux admin

On Fri, Apr 10, 2020 at 04:39:48PM +0200, Matteo Croce wrote:

# ./mii-diag eth0 -p 32769
Using the specified MII PHY index 32769.
Basic registers of MII PHY #32769:  2040 0082 002b 09ab 0071 009a c000 0009.
 Basic mode control register 0x2040: Auto-negotiation disabled, with
 Speed fixed at 100 mbps, half-duplex.
 Basic mode status register 0x0082 ... 0082.
   Link status: not established.
   *** Link Jabber! ***
 Your link partner is generating 100baseTx link beat  (no autonegotiation).
   End of basic transceiver information.
root@macchiatobin:~# ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
mode DEFAULT group default qlen 2048
    link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff

But no traffic in any direction

Quoted 8 lines
Quoted 6 lines

So you have the same version PHY hardware as I do.

So, we need further diagnosis, which isn't possible without a more advanced mii-diag tool - I'm sorting that out now, and will provide a link to a git repo later this afternoon.

Ok, I'll wait for the tool

Quoted 8 lines

Okay, please give this a go:

        git://git.armlinux.org.uk/~rmk/mii-diag/

Please send me the full output from:

# ./mii-diag eth0 -v -p 32768

Hi,

here it is:

# ./mii-diag eth0 -v -p 32768
mii-diag.c:v2.11 3/21/2005 Donald Becker ([email protected])
 http://www.scyld.com/diag/index.html
  Using the new SIOCGMIIPHY value on PHY 0 (BMCR 0x2040).
Using the specified MII PHY index 32768.
  No MII transceiver present!.
  Use '--force' to view the information anyway.
libmii.c:v2.11 2/28/2005  Donald Becker ([email protected])
 http://www.scyld.com/diag/index.html

MII PHY #0:1 PMA/PMD transceiver registers:
2040 0082 002b 09ab 0071 009a c000 0009
9701 0000 0000 01a4 0000 0000 002b 09ab
0000 0000 0000 0000 0000 0003 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:0a:c2:--:--:--, model 26 rev. 11.
Vendor/Part: Marvell Semiconductor 88X3310.
Control 1 register 2040: Speed determined by auto-negotiation. Status register 0082 ... 0082.
Receive link status: not established.
*Fault condition detected*
Speed capability 0071: 10G, 10G/1G, 100M, 10M. Control 2 register 0009: Type determined by auto-negotiation. Status 2 register 9701 ... 9701
Abilities: Local loopback, Transmit disable, Receive fault. *Receive fault reported*.
Extended Ability register 01a4
Abilities: 10GbaseT, 1000baseT, 100baseTX, 10baseT.
2.5G/5G Extended Ability register 0003
Abilities: 5GbaseT, 2.5GbaseT.

MII PHY #0:3 PCS transceiver registers:
2040 0082 002b 09ab 0001 009a c000 0003 8c08 0000 0000 0000 0000 0000 002b 09ab 0000 0000 0000 0000 000e 0003 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 3f00 0000 0000 0000 0000 0000 0000 0000 0be3 0b83 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:0a:c2:--:--:--, model 26 rev. 11.
Vendor/Part: Marvell Semiconductor 88X3310.
Control 1 register 2040: Speed 10Gb/s. Status register 0082 ... 0082.
Receive link status: not established. *Fault condition detected*
Supports low-power mode.
Speed capability 0001: 10G.
Control 2 register 0003: Type 10GbaseT. Status 2 register 8c08 ... 8c08
Abilities: 10GbaseT.
*Transmit fault reported*.
*Receive fault reported*.
baseR or 10GbaseT status 0000 3f00.
EEE control and capabilities 000e
10GBASE-T, 1000BASE-T, 100BASE-TX.
EEE wake error counter: 0000

MII PHY #0:3 PCS Subdevice #2 transceiver registers:
2040 0006 002b 09ab 0005 009e c000 0000 8013 0000 0000 0000 0000 0000 002b 09ab 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 100d 8000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:0a:c2:--:--:--, model 26 rev. 11.
Vendor/Part: Marvell Semiconductor 88X3310.
Control 1 register 2040: Speed 10Gb/s. Status register 0006 ... 0006.
Receive link status: established.
Supports low-power mode.
Speed capability 0005: 40G, 10G.
Control 2 register 0000: Type 10GbaseR. Status 2 register 8013 ... 8013
Abilities: 40GbaseR, 10GbaseR, 10GbaseX.
baseR or 10GbaseT status 100d 8000
PCS receive link up
PRBS9 pattern testing
PRBS31 pattern testing
Block lock
Block lock (latched).

MII PHY #0:3 PCS Subdevice #3 transceiver registers:
1140 0149 0141 0dab 0020 0000 0004 2001
0000 0000 0000 0000 0000 0000 0000 8000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:50:43:--:--:--, model 26 rev. 11.
Vendor/Part: Marvell Semiconductor 88X3310.
Basic mode control register 1140: Auto-negotiation enabled. Basic mode status register 0149 ... 0149.
With extended status register 8000.
Link status: not established.
Capable of 1000baseX-FD.
Able to perform Auto-negotiation, negotiation not complete.
I'm advertising 0020: 1000baseX-FD.

MII PHY #0:4 PHY XS transceiver registers:
2040 0082 0141 0dab 0001 001a 4000 0001 8403 0000 0000 0000 0000 0000 0141 0dab 0000 0000 0000 0000 0000 0000 0000 0000 0c00 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:50:43:--:--:--, model 26 rev. 11.
Vendor/Part: Marvell Semiconductor 88X3310.
Control 1 register 2040: Speed 10Gb/s. Status register 0082 ... 0082.
Transmit link status: not established. *Fault condition detected*
Supports low-power mode.
Speed capability 0001: 10G.
Lane Status 0c00:
pattern testing supported
loopback support.

MII PHY #0:4 PHY XS Subdevice #2 transceiver registers:
2040 0006 002b 09ab 0005 009e c000 0000
8013 0000 0000 0000 0000 0000 002b 09ab
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
100d 8000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:0a:c2:--:--:--, model 26 rev. 11.
Vendor/Part: Marvell Semiconductor 88X3310.
Control 1 register 2040: Speed 10Gb/s.
Status register 0006 ... 0006.
Transmit link status: established.
Supports low-power mode.
Speed capability 0005: 10G.
Lane Status 0000.

MII PHY #0:4 PHY XS Subdevice #3 transceiver registers:
1140 0149 0141 0dab 0020 0000 0004 2001
0000 0000 0000 0000 0000 0000 0000 8000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:50:43:--:--:--, model 26 rev. 11.
Vendor/Part: Marvell Semiconductor 88X3310.
Basic mode control register 1140: Auto-negotiation enabled. Basic mode status register 0149 ... 0149.
With extended status register 8000.
Link status: not established.
Capable of 1000baseX-FD.
Able to perform Auto-negotiation, negotiation not complete.
SGMII advertisement 0020: Link down, reserved bits are set. SGMII acknowledgement 0000: Unacknowledged.

MII PHY #0:7 AN transceiver registers:
3000 0008 002b 09ab 0000 009a c000 0000
0000 0000 0000 0000 0000 0000 002b 09ab
1de1 0000 0000 0081 0000 0000 2001 0000
0000 0000 0000 0000 0000 0000 0000 0000
1081 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:0a:c2:--:--:--, model 26 rev. 11.
Vendor/Part: Marvell Semiconductor 88X3310.
Control 1 register 3000: Auto-negotiation enabled.
Status register 0008 ... 0008.
Link status: not established.
Able to perform Auto-negotiation, negotiation not complete.
I'm advertising 1de1 1081.
10GbaseT 2.5GbaseT AsymPause Pause 100baseTx-FD 100baseTx 10baseT-FD 10baseT I'm part of a single-port device.
10GbaseT LD loop timing.
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner advertisment is 0081.
Advertising 100baseTx.
Negotiation did not complete.
10GbaseT status 0000
Local PHY slave, Local RX not ok, Remote RX not ok.
XNP advert is 2001: message page 1
XNP link partner is 0000: unformatted code 000

MII PHY #0:7 AN Subdevice #2 transceiver registers:
0000 000c 0141 0d90 0000 009e c000 0000
0000 0000 0000 0000 0000 0000 0141 0d90
0001 008a 0000 0000 0000 0000 2001 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0009 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:50:43:--:--:--, model 25 rev. 0.
Vendor/Part: Marvell Semiconductor (unknown type).
Control 1 register 0000: Auto-negotiation disabled. Status register 000c ... 000c.
Link status: established.
Able to perform Auto-negotiation, negotiation not complete.
I'm advertising 0000008a0001.
Advertising 10GbaseKR.
IEEE 802.3 CSMA/CD protocol.
baseR Status 0009: 10GbaseKR.

MII PHY #0:7 AN Subdevice #3 transceiver registers:
0000 000c 0141 0d90 0000 009e c000 0000
0000 0000 0000 0000 0000 0000 0141 0d90
0001 0096 0000 0000 0000 0000 2001 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0009 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:50:43:--:--:--, model 25 rev. 0.
Vendor/Part: Marvell Semiconductor (unknown type).
Control 1 register 0000: Auto-negotiation disabled. Status register 000c ... 000c.
Link status: established.
Able to perform Auto-negotiation, negotiation not complete.
I'm advertising 000000960001.
Advertising 10GbaseKR.
IEEE 802.3 CSMA/CD protocol.
baseR Status 0009: 10GbaseKR.

MII PHY #0:7 AN Subdevice #4 transceiver registers:
3000 0008 0141 0c00 0000 008a 0000 0000
0000 0000 0000 0000 0000 0000 0141 0c00
1de1 0000 0000 0081 0000 0000 2801 0000
0000 0000 0000 0000 0000 0000 0000 0000
1081 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:50:43:--:--:--, model 0 rev. 0.
Vendor/Part: Marvell Semiconductor (unknown type).
Control 1 register 3000: Auto-negotiation enabled.
Status register 0008 ... 0008.
Link status: not established.
Able to perform Auto-negotiation, negotiation not complete.
I'm advertising 1de1 1081.
10GbaseT 2.5GbaseT AsymPause Pause 100baseTx-FD 100baseTx 10baseT-FD 10baseT I'm part of a single-port device.
10GbaseT LD loop timing.
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner advertisment is 0081.
Advertising 100baseTx.
Negotiation did not complete.
10GbaseT status 0000
Local PHY slave, Local RX not ok, Remote RX not ok.
XNP advert is 2801: message page 1
XNP link partner is 0000: unformatted code 000

Other registers
8000: 0210 0000 7973 0000 0000 0000 fffe 8007
8008: 0000 1000 0000 0000 0101 0000 0000 0077

9000: 0010 014a 0000 0000 0000 0000 0000 0000
9008: 0000 0000 0000 0002 0001 0000 0000 0000

9800: 0010 014a 0000 0000 0000 0000 0000 0000
9808: 0000 0000 0000 0002 0001 0000 0000 0000

a000: 0210 0000 7973 0000 0404 0000 fffe 8007
a008: 0000 1000 0000 0000 0101 0000 0100 0010
a010: 0010 0000 0000 0000 0000 0000 0040 0000
...
a020: a400 0000 0000 05a1 0300 0003 0000 0000
a028: 0000 8317 0000 8000 1000 0000 0000 0000
a030: e49f 00ff 0000 0000 0000 0000 0000 0000

MII PHY #0:30 Vendor Specific 1 transceiver registers:
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000.

MII PHY #0:31 Vendor Specific 2 transceiver registers:
fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000 fffe 0000.

Signature · 2 lines
Matteo Croce
per aspera ad upstream
author maintainer
#20 lore raw

Re: [PATCH net-next v2 3/3] net: phy: marvell10g: place in powersave mode at probe

Quoted 43 lines · Matteo Croce
Quoted 41 lines · Russell King - ARM Linux admin
Quoted 26 lines · Matteo Croce
Quoted 24 lines · Russell King - ARM Linux admin
Quoted 21 lines · Matteo Croce
Quoted 2 lines · Russell King - ARM Linux admin

On Fri, Apr 10, 2020 at 04:39:48PM +0200, Matteo Croce wrote:

# ./mii-diag eth0 -p 32769
Using the specified MII PHY index 32769.
Basic registers of MII PHY #32769:  2040 0082 002b 09ab 0071 009a c000 0009.
 Basic mode control register 0x2040: Auto-negotiation disabled, with
 Speed fixed at 100 mbps, half-duplex.
 Basic mode status register 0x0082 ... 0082.
   Link status: not established.
   *** Link Jabber! ***
 Your link partner is generating 100baseTx link beat  (no autonegotiation).
   End of basic transceiver information.
root@macchiatobin:~# ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
mode DEFAULT group default qlen 2048
    link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff

But no traffic in any direction

Quoted 8 lines
Quoted 6 lines

So you have the same version PHY hardware as I do.

So, we need further diagnosis, which isn't possible without a more advanced mii-diag tool - I'm sorting that out now, and will provide a link to a git repo later this afternoon.

Ok, I'll wait for the tool

Okay, please give this a go:

        git://git.armlinux.org.uk/~rmk/mii-diag/
Quoted 8 lines
Quoted 4 lines

Please send me the full output from:

# ./mii-diag eth0 -v -p 32768

Hi,

here it is:

Thanks. It seems that the PHY is reporting that everything is fine, all the various blocks associated with the SFP+ cage are reporting that link is established, and link is established with the host.

I wonder - can you tcpdump to see whether any traffic is being received at either end of the link, in case it's only one direction that is a problem?

Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
#21 lore raw

Re: [PATCH net-next v2 3/3] net: phy: marvell10g: place in powersave mode at probe

Quoted 54 lines · Russell King - ARM Linux admin
Quoted 43 lines · Matteo Croce
Quoted 41 lines · Russell King - ARM Linux admin
Quoted 26 lines · Matteo Croce
Quoted 24 lines · Russell King - ARM Linux admin
Quoted 21 lines · Matteo Croce
Quoted 2 lines · Russell King - ARM Linux admin

On Fri, Apr 10, 2020 at 04:39:48PM +0200, Matteo Croce wrote:

# ./mii-diag eth0 -p 32769
Using the specified MII PHY index 32769.
Basic registers of MII PHY #32769:  2040 0082 002b 09ab 0071 009a c000 0009.
 Basic mode control register 0x2040: Auto-negotiation disabled, with
 Speed fixed at 100 mbps, half-duplex.
 Basic mode status register 0x0082 ... 0082.
   Link status: not established.
   *** Link Jabber! ***
 Your link partner is generating 100baseTx link beat  (no autonegotiation).
   End of basic transceiver information.
root@macchiatobin:~# ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
mode DEFAULT group default qlen 2048
    link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff

But no traffic in any direction

Quoted 8 lines
Quoted 6 lines

So you have the same version PHY hardware as I do.

So, we need further diagnosis, which isn't possible without a more advanced mii-diag tool - I'm sorting that out now, and will provide a link to a git repo later this afternoon.

Ok, I'll wait for the tool

Okay, please give this a go:

        git://git.armlinux.org.uk/~rmk/mii-diag/
Quoted 8 lines
Quoted 4 lines

Please send me the full output from:

# ./mii-diag eth0 -v -p 32768

Hi,

here it is:

Quoted 8 lines

Thanks. It seems that the PHY is reporting that everything is fine, all the various blocks associated with the SFP+ cage are reporting that link is established, and link is established with the host.

I wonder - can you tcpdump to see whether any traffic is being received at either end of the link, in case it's only one direction that is a problem?

Hi,

The problem is in both directions, I can't receive anything, and sent can't be received from the other end.

# ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
mode DEFAULT group default qlen 2048
    link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    0          0        0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    252        6        0       0       0       0

If it can help, I can provide you access to the box.

Regards,

Signature · 2 lines
Matteo Croce
per aspera ad upstream
#22 lore raw

Re: [PATCH net-next v2 3/3] net: phy: marvell10g: place in powersave mode at probe

Quoted 80 lines · Matteo Croce
Quoted 54 lines · Russell King - ARM Linux admin
Quoted 43 lines · Matteo Croce
Quoted 41 lines · Russell King - ARM Linux admin
Quoted 26 lines · Matteo Croce
Quoted 24 lines · Russell King - ARM Linux admin
Quoted 21 lines · Matteo Croce
Quoted 2 lines · Russell King - ARM Linux admin

On Fri, Apr 10, 2020 at 04:39:48PM +0200, Matteo Croce wrote:

# ./mii-diag eth0 -p 32769
Using the specified MII PHY index 32769.
Basic registers of MII PHY #32769:  2040 0082 002b 09ab 0071 009a c000 0009.
 Basic mode control register 0x2040: Auto-negotiation disabled, with
 Speed fixed at 100 mbps, half-duplex.
 Basic mode status register 0x0082 ... 0082.
   Link status: not established.
   *** Link Jabber! ***
 Your link partner is generating 100baseTx link beat  (no autonegotiation).
   End of basic transceiver information.
root@macchiatobin:~# ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
mode DEFAULT group default qlen 2048
    link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff

But no traffic in any direction

Quoted 8 lines
Quoted 6 lines

So you have the same version PHY hardware as I do.

So, we need further diagnosis, which isn't possible without a more advanced mii-diag tool - I'm sorting that out now, and will provide a link to a git repo later this afternoon.

Ok, I'll wait for the tool

Okay, please give this a go:

        git://git.armlinux.org.uk/~rmk/mii-diag/
Quoted 8 lines
Quoted 4 lines

Please send me the full output from:

# ./mii-diag eth0 -v -p 32768

Hi,

here it is:

Quoted 8 lines

Thanks. It seems that the PHY is reporting that everything is fine, all the various blocks associated with the SFP+ cage are reporting that link is established, and link is established with the host.

I wonder - can you tcpdump to see whether any traffic is being received at either end of the link, in case it's only one direction that is a problem?

Hi,

The problem is in both directions, I can't receive anything, and sent can't be received from the other end.

# ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
mode DEFAULT group default qlen 2048
    link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    0          0        0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    252        6        0       0       0       0
Quoted 6 lines

If it can help, I can provide you access to the box.

Regards,
--
Matteo Croce
per aspera ad upstream

Hi,

I noticed this: booting once an old kernel will fix the following net-next boots too as long as I don't unplug the power to the board.

Signature · 2 lines
Matteo Croce
per aspera ad upstream
author maintainer
#23 lore raw

Re: [PATCH net-next v2 3/3] net: phy: marvell10g: place in powersave mode at probe

In reply to Matteo Croce
Quoted 79 lines · Matteo Croce
Quoted 54 lines · Russell King - ARM Linux admin
Quoted 43 lines · Matteo Croce
Quoted 41 lines · Russell King - ARM Linux admin
Quoted 26 lines · Matteo Croce
Quoted 24 lines · Russell King - ARM Linux admin
Quoted 21 lines · Matteo Croce
Quoted 2 lines · Russell King - ARM Linux admin

On Fri, Apr 10, 2020 at 04:39:48PM +0200, Matteo Croce wrote:

# ./mii-diag eth0 -p 32769
Using the specified MII PHY index 32769.
Basic registers of MII PHY #32769:  2040 0082 002b 09ab 0071 009a c000 0009.
 Basic mode control register 0x2040: Auto-negotiation disabled, with
 Speed fixed at 100 mbps, half-duplex.
 Basic mode status register 0x0082 ... 0082.
   Link status: not established.
   *** Link Jabber! ***
 Your link partner is generating 100baseTx link beat  (no autonegotiation).
   End of basic transceiver information.
root@macchiatobin:~# ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
mode DEFAULT group default qlen 2048
    link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff

But no traffic in any direction

Quoted 8 lines
Quoted 6 lines

So you have the same version PHY hardware as I do.

So, we need further diagnosis, which isn't possible without a more advanced mii-diag tool - I'm sorting that out now, and will provide a link to a git repo later this afternoon.

Ok, I'll wait for the tool

Okay, please give this a go:

        git://git.armlinux.org.uk/~rmk/mii-diag/
Quoted 8 lines
Quoted 4 lines

Please send me the full output from:

# ./mii-diag eth0 -v -p 32768

Hi,

here it is:

Quoted 8 lines

Thanks. It seems that the PHY is reporting that everything is fine, all the various blocks associated with the SFP+ cage are reporting that link is established, and link is established with the host.

I wonder - can you tcpdump to see whether any traffic is being received at either end of the link, in case it's only one direction that is a problem?

Hi,

The problem is in both directions, I can't receive anything, and sent can't be received from the other end.

# ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
mode DEFAULT group default qlen 2048
    link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    0          0        0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    252        6        0       0       0       0
Quoted 1 line

If it can help, I can provide you access to the box.

Those statistics look suspicious - do you have IPv6 enabled? If so, those six packets are likely to be router discovery packets for IPv6.

Yes, I think having access to the box would be helpful to speed up the diagnosis. Also, having details of what is on the other end of the DAC cable would be useful too. Thanks.

Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
author maintainer
#24 lore raw

Re: [PATCH net-next v2 3/3] net: phy: marvell10g: place in powersave mode at probe

In reply to Matteo Croce
Quoted 6 lines · Matteo Croce
Quoted 5 lines · Russell King

Place the 88x3310 into powersaving mode when probing, which saves 600mW per PHY. For both PHYs on the Macchiatobin double-shot, this saves about 10% of the board idle power.

Quoted 7 lines
Quoted 1 line
Signed-off-by Russell King <[email protected]>

Hi,

I have a Macchiatobin double shot, and my 10G ports stop working after this change.
I reverted this commit on top of latest net-next and now the ports work again.

For the public record, I've been debugging this in-part on Matteo's board, and it looks like it's a PHY firmware issue.

Both my Macchiatobin boards use firmware 0.2.1.0 (which is not even mentioned on Marvell's extranet), whereas Matteo's board uses 0.3.3.0. It seems firmware 0.2.1.0 behaves "correctly" with my patch, but 0.3.3.0 does not - and neither does the latest 0.3.10.0. Both of these more recent versions seem to need a software reset to recover from power down mode... so a patch will be coming soon to add that.

I also think it would be a good idea to print the PHY firmware version when the PHY is probed - another patch coming for that.

Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up