[PATCH net-next v2 0/3] marvell10g tunable and power saving support

[PATCH net-next v2 0/3] marvell10g tunable and power saving support

[Russell King - ARM Linux admin]

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(-)

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

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

[Russell King]

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

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
 drivers/net/phy/marvell10g.c | 61 ++++++++++++++++++++++++++++++++++--
 1 file changed, 59 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 9a4e12a2af07..9d4fed782b19 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -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);
-- 
2.20.1

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

[Andrew Lunn]

> +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;

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

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

[Russell King - ARM Linux admin]

On Tue, Mar 03, 2020 at 06:03:16PM +0100, Andrew Lunn wrote:
> > +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;
> 
> Hi Russell
> 
> 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().

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

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

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

[Andrew Lunn]

> 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

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

[Russell King]

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 <rmk+kernel@armlinux.org.uk>
---
 drivers/net/phy/marvell10g.c | 86 +++++++++++++++++++++++++++++++++++-
 1 file changed, 85 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 9d4fed782b19..148c07b59a9e 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -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,
 	},
 };
 
-- 
2.20.1

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

[Andrew Lunn]

> +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;
> +	}
> +}

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

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

[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 <rmk+kernel@armlinux.org.uk>
---
 drivers/net/phy/marvell10g.c | 30 ++++++++++++++++++++++++++----
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 148c07b59a9e..5939b8ab9a96 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -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);
 }
-- 
2.20.1

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

[Andrew Lunn]

On Tue, Mar 03, 2020 at 03:54:20PM +0000, Russell King wrote:
> 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 <rmk+kernel@armlinux.org.uk>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

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

[Matteo Croce]

On Fri, Apr 10, 2020 at 3:24 PM Russell King <rmk+kernel@armlinux.org.uk> wrote:
>
> 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 <rmk+kernel@armlinux.org.uk>

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,
-- 
Matteo Croce
per aspera ad upstream

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

[Russell King - ARM Linux admin]

On Fri, Apr 10, 2020 at 03:48:34PM +0200, Matteo Croce wrote:
> On Fri, Apr 10, 2020 at 3:24 PM Russell King <rmk+kernel@armlinux.org.uk> wrote:
> >
> > 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 <rmk+kernel@armlinux.org.uk>
> 
> 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?

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

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

[Russell King - ARM Linux admin]

On Fri, Apr 10, 2020 at 03:19:14PM +0100, Russell King - ARM Linux admin wrote:
> On Fri, Apr 10, 2020 at 03:48:34PM +0200, Matteo Croce wrote:
> > On Fri, Apr 10, 2020 at 3:24 PM Russell King <rmk+kernel@armlinux.org.uk> wrote:
> > >
> > > 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 <rmk+kernel@armlinux.org.uk>
> > 
> > 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?

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.

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

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

[Matteo Croce]

On Fri, Apr 10, 2020 at 4:37 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Fri, Apr 10, 2020 at 03:19:14PM +0100, Russell King - ARM Linux admin wrote:
> > On Fri, Apr 10, 2020 at 03:48:34PM +0200, Matteo Croce wrote:
> > > On Fri, Apr 10, 2020 at 3:24 PM Russell King <rmk+kernel@armlinux.org.uk> wrote:
> > > >
> > > > 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 <rmk+kernel@armlinux.org.uk>
> > >
> > > 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?
>
> 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.
>
> --
> 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,
-- 
Matteo Croce
per aspera ad upstream

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

[Russell King - ARM Linux admin]

On Fri, Apr 10, 2020 at 04:39:48PM +0200, Matteo Croce wrote:
> On Fri, Apr 10, 2020 at 4:37 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Fri, Apr 10, 2020 at 03:19:14PM +0100, Russell King - ARM Linux admin wrote:
> > > On Fri, Apr 10, 2020 at 03:48:34PM +0200, Matteo Croce wrote:
> > > > On Fri, Apr 10, 2020 at 3:24 PM Russell King <rmk+kernel@armlinux.org.uk> wrote:
> > > > >
> > > > > 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 <rmk+kernel@armlinux.org.uk>
> > > >
> > > > 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?
> >
> > 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.
> >
> > --
> > 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?

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

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

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

[Russell King - ARM Linux admin]

On Fri, Apr 10, 2020 at 04:39:48PM +0200, Matteo Croce wrote:
> On Fri, Apr 10, 2020 at 4:37 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Fri, Apr 10, 2020 at 03:19:14PM +0100, Russell King - ARM Linux admin wrote:
> > > On Fri, Apr 10, 2020 at 03:48:34PM +0200, Matteo Croce wrote:
> > > > On Fri, Apr 10, 2020 at 3:24 PM Russell King <rmk+kernel@armlinux.org.uk> wrote:
> > > > >
> > > > > 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 <rmk+kernel@armlinux.org.uk>
> > > >
> > > > 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?
> >
> > 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.
> >
> > --
> > 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.

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.

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

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

[Matteo Croce]

On Fri, Apr 10, 2020 at 4:50 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Fri, Apr 10, 2020 at 04:39:48PM +0200, Matteo Croce wrote:
> > On Fri, Apr 10, 2020 at 4:37 PM Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > >
> > > On Fri, Apr 10, 2020 at 03:19:14PM +0100, Russell King - ARM Linux admin wrote:
> > > > On Fri, Apr 10, 2020 at 03:48:34PM +0200, Matteo Croce wrote:
> > > > > On Fri, Apr 10, 2020 at 3:24 PM Russell King <rmk+kernel@armlinux.org.uk> wrote:
> > > > > >
> > > > > > 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 <rmk+kernel@armlinux.org.uk>
> > > > >
> > > > > 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?
> > >
> > > 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.
> > >
> > > --
> > > 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.
>
> 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.
>
> --
> 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,
-- 
Matteo Croce
per aspera ad upstream

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

[Russell King - ARM Linux admin]

On Fri, Apr 10, 2020 at 04:59:44PM +0200, Matteo Croce wrote:
> On Fri, Apr 10, 2020 at 4:50 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Fri, Apr 10, 2020 at 04:39:48PM +0200, Matteo Croce wrote:
> > > On Fri, Apr 10, 2020 at 4:37 PM Russell King - ARM Linux admin
> > > <linux@armlinux.org.uk> wrote:
> > > >
> > > > On Fri, Apr 10, 2020 at 03:19:14PM +0100, Russell King - ARM Linux admin wrote:
> > > > > On Fri, Apr 10, 2020 at 03:48:34PM +0200, Matteo Croce wrote:
> > > > > > On Fri, Apr 10, 2020 at 3:24 PM Russell King <rmk+kernel@armlinux.org.uk> wrote:
> > > > > > >
> > > > > > > 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 <rmk+kernel@armlinux.org.uk>
> > > > > >
> > > > > > 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?
> > > >
> > > > 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.
> > > >
> > > > --
> > > > 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.
> >
> > 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.
> >
> > --
> > 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

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.

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

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

[Matteo Croce]

On Fri, Apr 10, 2020 at 5:16 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Fri, Apr 10, 2020 at 04:59:44PM +0200, Matteo Croce wrote:
> > On Fri, Apr 10, 2020 at 4:50 PM Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > >
> > > 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
>
> 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,
-- 
Matteo Croce
per aspera ad upstream

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

[Russell King - ARM Linux admin]

On Fri, Apr 10, 2020 at 05:18:41PM +0200, Matteo Croce wrote:
> On Fri, Apr 10, 2020 at 5:16 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Fri, Apr 10, 2020 at 04:59:44PM +0200, Matteo Croce wrote:
> > > On Fri, Apr 10, 2020 at 4:50 PM Russell King - ARM Linux admin
> > > <linux@armlinux.org.uk> wrote:
> > > >
> > > > 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
> >
> > 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 (becker@scyld.com)
 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 (becker@scyld.com)
 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.

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

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

[Matteo Croce]

On Fri, Apr 10, 2020 at 6:04 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Fri, Apr 10, 2020 at 05:18:41PM +0200, Matteo Croce wrote:
> > On Fri, Apr 10, 2020 at 5:16 PM Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > >
> > > On Fri, Apr 10, 2020 at 04:59:44PM +0200, Matteo Croce wrote:
> > > > On Fri, Apr 10, 2020 at 4:50 PM Russell King - ARM Linux admin
> > > > <linux@armlinux.org.uk> wrote:
> > > > >
> > > > > 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
> > >
> > > 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
>

Hi,

here it is:

# ./mii-diag eth0 -v -p 32768
mii-diag.c:v2.11 3/21/2005 Donald Becker (becker@scyld.com)
 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 (becker@scyld.com)
 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.

-- 
Matteo Croce
per aspera ad upstream

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

[Russell King - ARM Linux admin]

On Fri, Apr 10, 2020 at 06:07:46PM +0200, Matteo Croce wrote:
> On Fri, Apr 10, 2020 at 6:04 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Fri, Apr 10, 2020 at 05:18:41PM +0200, Matteo Croce wrote:
> > > On Fri, Apr 10, 2020 at 5:16 PM Russell King - ARM Linux admin
> > > <linux@armlinux.org.uk> wrote:
> > > >
> > > > On Fri, Apr 10, 2020 at 04:59:44PM +0200, Matteo Croce wrote:
> > > > > On Fri, Apr 10, 2020 at 4:50 PM Russell King - ARM Linux admin
> > > > > <linux@armlinux.org.uk> wrote:
> > > > > >
> > > > > > 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
> > > >
> > > > 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
> >
> 
> 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?

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

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

[Matteo Croce]

On Fri, Apr 10, 2020 at 6:23 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Fri, Apr 10, 2020 at 06:07:46PM +0200, Matteo Croce wrote:
> > On Fri, Apr 10, 2020 at 6:04 PM Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > >
> > > On Fri, Apr 10, 2020 at 05:18:41PM +0200, Matteo Croce wrote:
> > > > On Fri, Apr 10, 2020 at 5:16 PM Russell King - ARM Linux admin
> > > > <linux@armlinux.org.uk> wrote:
> > > > >
> > > > > On Fri, Apr 10, 2020 at 04:59:44PM +0200, Matteo Croce wrote:
> > > > > > On Fri, Apr 10, 2020 at 4:50 PM Russell King - ARM Linux admin
> > > > > > <linux@armlinux.org.uk> wrote:
> > > > > > >
> > > > > > > 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
> > > > >
> > > > > 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
> > >
> >
> > 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?
>

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,
-- 
Matteo Croce
per aspera ad upstream

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

[Matteo Croce]

On Fri, Apr 10, 2020 at 6:30 PM Matteo Croce <mcroce@redhat.com> wrote:
>
> On Fri, Apr 10, 2020 at 6:23 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Fri, Apr 10, 2020 at 06:07:46PM +0200, Matteo Croce wrote:
> > > On Fri, Apr 10, 2020 at 6:04 PM Russell King - ARM Linux admin
> > > <linux@armlinux.org.uk> wrote:
> > > >
> > > > On Fri, Apr 10, 2020 at 05:18:41PM +0200, Matteo Croce wrote:
> > > > > On Fri, Apr 10, 2020 at 5:16 PM Russell King - ARM Linux admin
> > > > > <linux@armlinux.org.uk> wrote:
> > > > > >
> > > > > > On Fri, Apr 10, 2020 at 04:59:44PM +0200, Matteo Croce wrote:
> > > > > > > On Fri, Apr 10, 2020 at 4:50 PM Russell King - ARM Linux admin
> > > > > > > <linux@armlinux.org.uk> wrote:
> > > > > > > >
> > > > > > > > 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
> > > > > >
> > > > > > 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
> > > >
> > >
> > > 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?
> >
>
> 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,
> --
> 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.

-- 
Matteo Croce
per aspera ad upstream

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

[Russell King - ARM Linux admin]

On Fri, Apr 10, 2020 at 06:30:48PM +0200, Matteo Croce wrote:
> On Fri, Apr 10, 2020 at 6:23 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Fri, Apr 10, 2020 at 06:07:46PM +0200, Matteo Croce wrote:
> > > On Fri, Apr 10, 2020 at 6:04 PM Russell King - ARM Linux admin
> > > <linux@armlinux.org.uk> wrote:
> > > >
> > > > On Fri, Apr 10, 2020 at 05:18:41PM +0200, Matteo Croce wrote:
> > > > > On Fri, Apr 10, 2020 at 5:16 PM Russell King - ARM Linux admin
> > > > > <linux@armlinux.org.uk> wrote:
> > > > > >
> > > > > > On Fri, Apr 10, 2020 at 04:59:44PM +0200, Matteo Croce wrote:
> > > > > > > On Fri, Apr 10, 2020 at 4:50 PM Russell King - ARM Linux admin
> > > > > > > <linux@armlinux.org.uk> wrote:
> > > > > > > >
> > > > > > > > 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
> > > > > >
> > > > > > 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
> > > >
> > >
> > > 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?
> >
> 
> 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.

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.

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

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

[Russell King - ARM Linux admin]

On Fri, Apr 10, 2020 at 03:48:34PM +0200, Matteo Croce wrote:
> On Fri, Apr 10, 2020 at 3:24 PM Russell King <rmk+kernel@armlinux.org.uk> wrote:
> >
> > 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 <rmk+kernel@armlinux.org.uk>
> 
> 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.

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