[PATCH net-next v3 00/18] net: phy: marvell10g updates

[PATCH net-next v3 00/18] net: phy: marvell10g updates

[Marek Behún]

Here are some updates for marvell10g PHY driver.

I am still working on some more changes for this driver, but I would
like to have at least something reviewed / applied.

Changes since v2:
- code refactored to use an additional structure mv3310_chip describing
  mv3310 specific properties / operations for PHYs supported by this
  driver
- added separate phy_driver structures for 88X3340 and 88E2111
- removed 88E2180 specific code (dual-port and quad-port SXGMII modes
  are ignored for now)

Changes since v1:
- added various MACTYPEs support also for 88E21XX
- differentiate between specific models with same PHY_ID
- better check for compatible interface
- print exact model

Marek Behún (18):
  net: phy: marvell10g: rename register
  net: phy: marvell10g: fix typo
  net: phy: marvell10g: allow 5gbase-r and usxgmii
  net: phy: marvell10g: indicate 88X33x0 only port control registers
  net: phy: marvell10g: add all MACTYPE definitions for 88X33x0
  net: phy: marvell10g: add MACTYPE definitions for 88E21xx
  net: phy: marvell10g: support all rate matching modes
  include: add library helpers for variadic macro expansion
  include: bitmap: add macro for bitmap initialization
  net: phy: marvell10g: check for correct supported interface mode
  net: phy: marvell10g: store temperature read method in chip strucutre
  net: phy: marvell10g: support other MACTYPEs
  net: phy: marvell10g: add separate structure for 88X3340
  net: phy: marvell10g: fix driver name for mv88e2110
  net: phy: add constants for 2.5G and 5G speed in PCS speed register
  net: phy: marvell10g: differentiate 88E2110 vs 88E2111
  net: phy: marvell10g: change module description
  MAINTAINERS: add myself as maintainer of marvell10g driver

 MAINTAINERS                    |   1 +
 drivers/net/phy/marvell10g.c   | 369 +++++++++++++++++++++++++++------
 include/linux/bitmap.h         |  24 +++
 include/linux/marvell_phy.h    |   6 +-
 include/linux/variadic-macro.h | 221 ++++++++++++++++++++
 include/uapi/linux/mdio.h      |   2 +
 6 files changed, 562 insertions(+), 61 deletions(-)
 create mode 100644 include/linux/variadic-macro.h

-- 
2.26.2

[PATCH net-next v3 01/18] net: phy: marvell10g: rename register

[Marek Behún]

The MV_V2_PORT_MAC_TYPE_* is part of the CTRL register. Rename to
MV_V2_PORT_CTRL_MACTYPE_*.

Signed-off-by: Marek Behún <kabel@kernel.org>
---
 drivers/net/phy/marvell10g.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 74b64e52ffa2..9b514124af0d 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -80,8 +80,8 @@ enum {
 	MV_V2_PORT_CTRL		= 0xf001,
 	MV_V2_PORT_CTRL_SWRST	= BIT(15),
 	MV_V2_PORT_CTRL_PWRDOWN = BIT(11),
-	MV_V2_PORT_MAC_TYPE_MASK = 0x7,
-	MV_V2_PORT_MAC_TYPE_RATE_MATCH = 0x6,
+	MV_V2_PORT_CTRL_MACTYPE_MASK = 0x7,
+	MV_V2_PORT_CTRL_MACTYPE_RATE_MATCH = 0x6,
 	/* Temperature control/read registers (88X3310 only) */
 	MV_V2_TEMP_CTRL		= 0xf08a,
 	MV_V2_TEMP_CTRL_MASK	= 0xc000,
@@ -477,8 +477,8 @@ static int mv3310_config_init(struct phy_device *phydev)
 	val = phy_read_mmd(phydev, MDIO_MMD_VEND2, MV_V2_PORT_CTRL);
 	if (val < 0)
 		return val;
-	priv->rate_match = ((val & MV_V2_PORT_MAC_TYPE_MASK) ==
-			MV_V2_PORT_MAC_TYPE_RATE_MATCH);
+	priv->rate_match = ((val & MV_V2_PORT_CTRL_MACTYPE_MASK) ==
+			MV_V2_PORT_CTRL_MACTYPE_RATE_MATCH);
 
 	/* Enable EDPD mode - saving 600mW */
 	return mv3310_set_edpd(phydev, ETHTOOL_PHY_EDPD_DFLT_TX_MSECS);
-- 
2.26.2

Re: [PATCH net-next v3 01/18] net: phy: marvell10g: rename register

[Andrew Lunn]

On Wed, Apr 07, 2021 at 12:10:50AM +0200, Marek Behún wrote:
> The MV_V2_PORT_MAC_TYPE_* is part of the CTRL register. Rename to
> MV_V2_PORT_CTRL_MACTYPE_*.
> 
> Signed-off-by: Marek Behún <kabel@kernel.org>

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

    Andrew

[PATCH net-next v3 02/18] net: phy: marvell10g: fix typo

[Marek Behún]

This space should be a tab instead.

Signed-off-by: Marek Behún <kabel@kernel.org>
---
 drivers/net/phy/marvell10g.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 9b514124af0d..f2f0da9717be 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -79,7 +79,7 @@ enum {
 	/* Vendor2 MMD registers */
 	MV_V2_PORT_CTRL		= 0xf001,
 	MV_V2_PORT_CTRL_SWRST	= BIT(15),
-	MV_V2_PORT_CTRL_PWRDOWN = BIT(11),
+	MV_V2_PORT_CTRL_PWRDOWN	= BIT(11),
 	MV_V2_PORT_CTRL_MACTYPE_MASK = 0x7,
 	MV_V2_PORT_CTRL_MACTYPE_RATE_MATCH = 0x6,
 	/* Temperature control/read registers (88X3310 only) */
-- 
2.26.2

Re: [PATCH net-next v3 02/18] net: phy: marvell10g: fix typo

[Andrew Lunn]

On Wed, Apr 07, 2021 at 12:10:51AM +0200, Marek Behún wrote:
> This space should be a tab instead.
> 
> Signed-off-by: Marek Behún <kabel@kernel.org>

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

    Andrew

[PATCH net-next v3 03/18] net: phy: marvell10g: allow 5gbase-r and usxgmii

[Marek Behún]

These modes are also supported by these PHYs.

Signed-off-by: Marek Behún <kabel@kernel.org>
---
 drivers/net/phy/marvell10g.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index f2f0da9717be..881a0717846e 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -462,9 +462,11 @@ static int mv3310_config_init(struct phy_device *phydev)
 	/* Check that the PHY interface type is compatible */
 	if (phydev->interface != PHY_INTERFACE_MODE_SGMII &&
 	    phydev->interface != PHY_INTERFACE_MODE_2500BASEX &&
+	    phydev->interface != PHY_INTERFACE_MODE_5GBASER &&
 	    phydev->interface != PHY_INTERFACE_MODE_XAUI &&
 	    phydev->interface != PHY_INTERFACE_MODE_RXAUI &&
-	    phydev->interface != PHY_INTERFACE_MODE_10GBASER)
+	    phydev->interface != PHY_INTERFACE_MODE_10GBASER &&
+	    phydev->interface != PHY_INTERFACE_MODE_USXGMII)
 		return -ENODEV;
 
 	phydev->mdix_ctrl = ETH_TP_MDI_AUTO;
@@ -599,6 +601,7 @@ static void mv3310_update_interface(struct phy_device *phydev)
 
 	if ((phydev->interface == PHY_INTERFACE_MODE_SGMII ||
 	     phydev->interface == PHY_INTERFACE_MODE_2500BASEX ||
+	     phydev->interface == PHY_INTERFACE_MODE_5GBASER ||
 	     phydev->interface == PHY_INTERFACE_MODE_10GBASER) &&
 	    phydev->link) {
 		/* The PHY automatically switches its serdes interface (and
@@ -611,6 +614,9 @@ static void mv3310_update_interface(struct phy_device *phydev)
 		case SPEED_10000:
 			phydev->interface = PHY_INTERFACE_MODE_10GBASER;
 			break;
+		case SPEED_5000:
+			phydev->interface = PHY_INTERFACE_MODE_5GBASER;
+			break;
 		case SPEED_2500:
 			phydev->interface = PHY_INTERFACE_MODE_2500BASEX;
 			break;
-- 
2.26.2

Re: [PATCH net-next v3 03/18] net: phy: marvell10g: allow 5gbase-r and usxgmii

[Andrew Lunn]

On Wed, Apr 07, 2021 at 12:10:52AM +0200, Marek Behún wrote:
> These modes are also supported by these PHYs.
> 
> Signed-off-by: Marek Behún <kabel@kernel.org>

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

    Andrew

[PATCH net-next v3 04/18] net: phy: marvell10g: indicate 88X33x0 only port control registers

[Marek Behún]

Rename port control registers to indicate that they are valid only for
88X33x0, not for 88E21x0.

Signed-off-by: Marek Behún <kabel@kernel.org>
---
 drivers/net/phy/marvell10g.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 881a0717846e..7552a658a513 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -78,10 +78,10 @@ enum {
 
 	/* Vendor2 MMD registers */
 	MV_V2_PORT_CTRL		= 0xf001,
-	MV_V2_PORT_CTRL_SWRST	= BIT(15),
-	MV_V2_PORT_CTRL_PWRDOWN	= BIT(11),
-	MV_V2_PORT_CTRL_MACTYPE_MASK = 0x7,
-	MV_V2_PORT_CTRL_MACTYPE_RATE_MATCH = 0x6,
+	MV_V2_PORT_CTRL_PWRDOWN			= BIT(11),
+	MV_V2_33X0_PORT_CTRL_SWRST		= BIT(15),
+	MV_V2_33X0_PORT_CTRL_MACTYPE_MASK	= 0x7,
+	MV_V2_33X0_PORT_CTRL_MACTYPE_RATE_MATCH	= 0x6,
 	/* Temperature control/read registers (88X3310 only) */
 	MV_V2_TEMP_CTRL		= 0xf08a,
 	MV_V2_TEMP_CTRL_MASK	= 0xc000,
@@ -268,7 +268,7 @@ static int mv3310_power_up(struct phy_device *phydev)
 		return ret;
 
 	return phy_set_bits_mmd(phydev, MDIO_MMD_VEND2, MV_V2_PORT_CTRL,
-				MV_V2_PORT_CTRL_SWRST);
+				MV_V2_33X0_PORT_CTRL_SWRST);
 }
 
 static int mv3310_reset(struct phy_device *phydev, u32 unit)
@@ -479,8 +479,8 @@ static int mv3310_config_init(struct phy_device *phydev)
 	val = phy_read_mmd(phydev, MDIO_MMD_VEND2, MV_V2_PORT_CTRL);
 	if (val < 0)
 		return val;
-	priv->rate_match = ((val & MV_V2_PORT_CTRL_MACTYPE_MASK) ==
-			MV_V2_PORT_CTRL_MACTYPE_RATE_MATCH);
+	priv->rate_match = ((val & MV_V2_33X0_PORT_CTRL_MACTYPE_MASK) ==
+			MV_V2_33X0_PORT_CTRL_MACTYPE_RATE_MATCH);
 
 	/* Enable EDPD mode - saving 600mW */
 	return mv3310_set_edpd(phydev, ETHTOOL_PHY_EDPD_DFLT_TX_MSECS);
-- 
2.26.2

Re: [PATCH net-next v3 04/18] net: phy: marvell10g: indicate 88X33x0 only port control registers

[Andrew Lunn]

> @@ -479,8 +479,8 @@ static int mv3310_config_init(struct phy_device *phydev)
>  	val = phy_read_mmd(phydev, MDIO_MMD_VEND2, MV_V2_PORT_CTRL);
>  	if (val < 0)
>  		return val;
> -	priv->rate_match = ((val & MV_V2_PORT_CTRL_MACTYPE_MASK) ==
> -			MV_V2_PORT_CTRL_MACTYPE_RATE_MATCH);
> +	priv->rate_match = ((val & MV_V2_33X0_PORT_CTRL_MACTYPE_MASK) ==
> +			MV_V2_33X0_PORT_CTRL_MACTYPE_RATE_MATCH);
>  
>  	/* Enable EDPD mode - saving 600mW */
>  	return mv3310_set_edpd(phydev, ETHTOOL_PHY_EDPD_DFLT_TX_MSECS);
> -- 

So it appears that mv3310_config_init() should not be used with the
mv88x2110. Did i miss somewhere where mv3310_drivers was changed so it
actually does not use it?

	 Andrew

Re: [PATCH net-next v3 04/18] net: phy: marvell10g: indicate 88X33x0 only port control registers

[Marek Behún]

On Wed, 7 Apr 2021 02:10:24 +0200
Andrew Lunn <andrew@lunn.ch> wrote:

> > @@ -479,8 +479,8 @@ static int mv3310_config_init(struct phy_device *phydev)
> >  	val = phy_read_mmd(phydev, MDIO_MMD_VEND2, MV_V2_PORT_CTRL);
> >  	if (val < 0)
> >  		return val;
> > -	priv->rate_match = ((val & MV_V2_PORT_CTRL_MACTYPE_MASK) ==
> > -			MV_V2_PORT_CTRL_MACTYPE_RATE_MATCH);
> > +	priv->rate_match = ((val & MV_V2_33X0_PORT_CTRL_MACTYPE_MASK) ==
> > +			MV_V2_33X0_PORT_CTRL_MACTYPE_RATE_MATCH);
> >  
> >  	/* Enable EDPD mode - saving 600mW */
> >  	return mv3310_set_edpd(phydev, ETHTOOL_PHY_EDPD_DFLT_TX_MSECS);
> > --   
> 
> So it appears that mv3310_config_init() should not be used with the
> mv88x2110. Did i miss somewhere where mv3310_drivers was changed so it
> actually does not use it?
> 
> 	 Andrew

This patch series makes it later so that mv3310_config_init() correctly
initializes even 2210 (this is done in patch 07/18). The function then
calls chip->get_mactype() and chip->init_interface() methods, which are
different for 3310 than for 2110.

I am thinking about whether all the functions which are same for all
the chips should be renamed from
  mv3310_*
to
  mv10g_*

This would rename
  mv3310_config_init
to
  mv10g_config_init
which would be more correct.

What do you think?

Marek

[PATCH net-next v3 05/18] net: phy: marvell10g: add all MACTYPE definitions for 88X33x0

[Marek Behún]

Add all MACTYPE definitions for 88X3310, 88X3310P, 88X3340 and 88X3340P.

In order to have consistent naming, rename
MV_V2_33X0_PORT_CTRL_MACTYPE_RATE_MATCH to
MV_V2_33X0_PORT_CTRL_MACTYPE_10GBASER_RATE_MATCH.

Signed-off-by: Marek Behún <kabel@kernel.org>
---
 drivers/net/phy/marvell10g.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 7552a658a513..7d9a45437b69 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -78,10 +78,18 @@ enum {
 
 	/* Vendor2 MMD registers */
 	MV_V2_PORT_CTRL		= 0xf001,
-	MV_V2_PORT_CTRL_PWRDOWN			= BIT(11),
-	MV_V2_33X0_PORT_CTRL_SWRST		= BIT(15),
-	MV_V2_33X0_PORT_CTRL_MACTYPE_MASK	= 0x7,
-	MV_V2_33X0_PORT_CTRL_MACTYPE_RATE_MATCH	= 0x6,
+	MV_V2_PORT_CTRL_PWRDOWN					= BIT(11),
+	MV_V2_33X0_PORT_CTRL_SWRST				= BIT(15),
+	MV_V2_33X0_PORT_CTRL_MACTYPE_MASK			= 0x7,
+	MV_V2_33X0_PORT_CTRL_MACTYPE_RXAUI			= 0x0,
+	MV_V2_3310_PORT_CTRL_MACTYPE_XAUI_RATE_MATCH		= 0x1,
+	MV_V2_3340_PORT_CTRL_MACTYPE_RXAUI_NO_SGMII_AN		= 0x1,
+	MV_V2_33X0_PORT_CTRL_MACTYPE_RXAUI_RATE_MATCH		= 0x2,
+	MV_V2_3310_PORT_CTRL_MACTYPE_XAUI			= 0x3,
+	MV_V2_33X0_PORT_CTRL_MACTYPE_10GBASER			= 0x4,
+	MV_V2_33X0_PORT_CTRL_MACTYPE_10GBASER_NO_SGMII_AN	= 0x5,
+	MV_V2_33X0_PORT_CTRL_MACTYPE_10GBASER_RATE_MATCH	= 0x6,
+	MV_V2_33X0_PORT_CTRL_MACTYPE_USXGMII			= 0x7,
 	/* Temperature control/read registers (88X3310 only) */
 	MV_V2_TEMP_CTRL		= 0xf08a,
 	MV_V2_TEMP_CTRL_MASK	= 0xc000,
@@ -480,7 +488,7 @@ static int mv3310_config_init(struct phy_device *phydev)
 	if (val < 0)
 		return val;
 	priv->rate_match = ((val & MV_V2_33X0_PORT_CTRL_MACTYPE_MASK) ==
-			MV_V2_33X0_PORT_CTRL_MACTYPE_RATE_MATCH);
+			MV_V2_33X0_PORT_CTRL_MACTYPE_10GBASER_RATE_MATCH);
 
 	/* Enable EDPD mode - saving 600mW */
 	return mv3310_set_edpd(phydev, ETHTOOL_PHY_EDPD_DFLT_TX_MSECS);
-- 
2.26.2

Re: [PATCH net-next v3 05/18] net: phy: marvell10g: add all MACTYPE definitions for 88X33x0

[Andrew Lunn]

On Wed, Apr 07, 2021 at 12:10:54AM +0200, Marek Behún wrote:
> Add all MACTYPE definitions for 88X3310, 88X3310P, 88X3340 and 88X3340P.
> 
> In order to have consistent naming, rename
> MV_V2_33X0_PORT_CTRL_MACTYPE_RATE_MATCH to
> MV_V2_33X0_PORT_CTRL_MACTYPE_10GBASER_RATE_MATCH.
> 
> Signed-off-by: Marek Behún <kabel@kernel.org>

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

    Andrew

[PATCH net-next v3 06/18] net: phy: marvell10g: add MACTYPE definitions for 88E21xx

[Marek Behún]

Add all MACTYPE definitions for 88E2110, 88E2180, 88E2111 and 88E2181.

Signed-off-by: Marek Behún <kabel@kernel.org>
---
 drivers/net/phy/marvell10g.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 7d9a45437b69..556c9b43860e 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -35,6 +35,15 @@
 enum {
 	MV_PMA_FW_VER0		= 0xc011,
 	MV_PMA_FW_VER1		= 0xc012,
+	MV_PMA_21X0_PORT_CTRL	= 0xc04a,
+	MV_PMA_21X0_PORT_CTRL_SWRST				= BIT(15),
+	MV_PMA_21X0_PORT_CTRL_MACTYPE_MASK			= 0x7,
+	MV_PMA_21X0_PORT_CTRL_MACTYPE_USXGMII			= 0x0,
+	MV_PMA_2180_PORT_CTRL_MACTYPE_DXGMII			= 0x1,
+	MV_PMA_2180_PORT_CTRL_MACTYPE_QXGMII			= 0x2,
+	MV_PMA_21X0_PORT_CTRL_MACTYPE_5GBASER			= 0x4,
+	MV_PMA_21X0_PORT_CTRL_MACTYPE_5GBASER_NO_SGMII_AN	= 0x5,
+	MV_PMA_21X0_PORT_CTRL_MACTYPE_10GBASER_RATE_MATCH	= 0x6,
 	MV_PMA_BOOT		= 0xc050,
 	MV_PMA_BOOT_FATAL	= BIT(0),
 
-- 
2.26.2

Re: [PATCH net-next v3 06/18] net: phy: marvell10g: add MACTYPE definitions for 88E21xx

[Andrew Lunn]

On Wed, Apr 07, 2021 at 12:10:55AM +0200, Marek Behún wrote:
> Add all MACTYPE definitions for 88E2110, 88E2180, 88E2111 and 88E2181.
> 
> Signed-off-by: Marek Behún <kabel@kernel.org>

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

    Andrew

[PATCH net-next v3 07/18] net: phy: marvell10g: support all rate matching modes

[Marek Behún]

Add support for all rate matching modes for 88X3310 (currently only
10gbase-r is supported, but xaui and rxaui can also be used).

Add support for rate matching for 88E2110 (on 88E2110 the MACTYPE
register is at a different place).

Signed-off-by: Marek Behún <kabel@kernel.org>
---
 drivers/net/phy/marvell10g.c | 104 +++++++++++++++++++++++++++++++----
 1 file changed, 93 insertions(+), 11 deletions(-)

diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 556c9b43860e..fc298e53f165 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -108,14 +108,26 @@ enum {
 	MV_V2_TEMP_UNKNOWN	= 0x9600, /* unknown function */
 };
 
+struct mv3310_chip {
+	int (*get_mactype)(struct phy_device *phydev);
+	int (*init_interface)(struct phy_device *phydev, int mactype);
+};
+
 struct mv3310_priv {
 	u32 firmware_ver;
 	bool rate_match;
+	phy_interface_t const_interface;
 
 	struct device *hwmon_dev;
 	char *hwmon_name;
 };
 
+static inline const struct mv3310_chip *
+to_mv3310_chip(struct phy_device *phydev)
+{
+	return phydev->drv->driver_data;
+}
+
 #ifdef CONFIG_HWMON
 static umode_t mv3310_hwmon_is_visible(const void *data,
 				       enum hwmon_sensor_types type,
@@ -470,11 +482,67 @@ static bool mv3310_has_pma_ngbaset_quirk(struct phy_device *phydev)
 		MV_PHY_ALASKA_NBT_QUIRK_MASK) == MV_PHY_ALASKA_NBT_QUIRK_REV;
 }
 
-static int mv3310_config_init(struct phy_device *phydev)
+static int mv2110_get_mactype(struct phy_device *phydev)
+{
+	int mactype;
+
+	mactype = phy_read_mmd(phydev, MDIO_MMD_PMAPMD, MV_PMA_21X0_PORT_CTRL);
+	if (mactype < 0)
+		return mactype;
+
+	return mactype & MV_PMA_21X0_PORT_CTRL_MACTYPE_MASK;
+}
+
+static int mv3310_get_mactype(struct phy_device *phydev)
+{
+	int mactype;
+
+	mactype = phy_read_mmd(phydev, MDIO_MMD_VEND2, MV_V2_PORT_CTRL);
+	if (mactype < 0)
+		return mactype;
+
+	return mactype & MV_V2_33X0_PORT_CTRL_MACTYPE_MASK;
+}
+
+static int mv2110_init_interface(struct phy_device *phydev, int mactype)
 {
 	struct mv3310_priv *priv = dev_get_drvdata(&phydev->mdio.dev);
-	int err;
-	int val;
+
+	priv->rate_match = false;
+
+	if (mactype == MV_PMA_21X0_PORT_CTRL_MACTYPE_10GBASER_RATE_MATCH) {
+		priv->rate_match = true;
+		priv->const_interface = PHY_INTERFACE_MODE_10GBASER;
+	}
+
+	return 0;
+}
+
+static int mv3310_init_interface(struct phy_device *phydev, int mactype)
+{
+	struct mv3310_priv *priv = dev_get_drvdata(&phydev->mdio.dev);
+
+	priv->rate_match = false;
+
+	if (mactype == MV_V2_33X0_PORT_CTRL_MACTYPE_10GBASER_RATE_MATCH ||
+	    mactype == MV_V2_33X0_PORT_CTRL_MACTYPE_RXAUI_RATE_MATCH ||
+	    mactype == MV_V2_3310_PORT_CTRL_MACTYPE_XAUI_RATE_MATCH)
+		priv->rate_match = true;
+
+	if (mactype == MV_V2_33X0_PORT_CTRL_MACTYPE_10GBASER_RATE_MATCH)
+		priv->const_interface = PHY_INTERFACE_MODE_10GBASER;
+	else if (mactype == MV_V2_33X0_PORT_CTRL_MACTYPE_RXAUI_RATE_MATCH)
+		priv->const_interface = PHY_INTERFACE_MODE_RXAUI;
+	else if (mactype == MV_V2_3310_PORT_CTRL_MACTYPE_XAUI_RATE_MATCH)
+		priv->const_interface = PHY_INTERFACE_MODE_XAUI;
+
+	return 0;
+}
+
+static int mv3310_config_init(struct phy_device *phydev)
+{
+	const struct mv3310_chip *chip = to_mv3310_chip(phydev);
+	int err, mactype;
 
 	/* Check that the PHY interface type is compatible */
 	if (phydev->interface != PHY_INTERFACE_MODE_SGMII &&
@@ -493,11 +561,13 @@ static int mv3310_config_init(struct phy_device *phydev)
 	if (err)
 		return err;
 
-	val = phy_read_mmd(phydev, MDIO_MMD_VEND2, MV_V2_PORT_CTRL);
-	if (val < 0)
-		return val;
-	priv->rate_match = ((val & MV_V2_33X0_PORT_CTRL_MACTYPE_MASK) ==
-			MV_V2_33X0_PORT_CTRL_MACTYPE_10GBASER_RATE_MATCH);
+	mactype = chip->get_mactype(phydev);
+	if (mactype < 0)
+		return mactype;
+
+	err = chip->init_interface(phydev, mactype);
+	if (err)
+		return err;
 
 	/* Enable EDPD mode - saving 600mW */
 	return mv3310_set_edpd(phydev, ETHTOOL_PHY_EDPD_DFLT_TX_MSECS);
@@ -607,12 +677,12 @@ static void mv3310_update_interface(struct phy_device *phydev)
 {
 	struct mv3310_priv *priv = dev_get_drvdata(&phydev->mdio.dev);
 
-	/* In "XFI with Rate Matching" mode the PHY interface is fixed at
-	 * 10Gb. The PHY adapts the rate to actual wire speed with help of
+	/* In all of the "* with Rate Matching" modes the PHY interface is fixed
+	 * at 10Gb. The PHY adapts the rate to actual wire speed with help of
 	 * internal 16KB buffer.
 	 */
 	if (priv->rate_match) {
-		phydev->interface = PHY_INTERFACE_MODE_10GBASER;
+		phydev->interface = priv->const_interface;
 		return;
 	}
 
@@ -788,11 +858,22 @@ static int mv3310_set_tunable(struct phy_device *phydev,
 	}
 }
 
+static const struct mv3310_chip mv3310_type = {
+	.get_mactype = mv3310_get_mactype,
+	.init_interface = mv3310_init_interface,
+};
+
+static const struct mv3310_chip mv2110_type = {
+	.get_mactype = mv2110_get_mactype,
+	.init_interface = mv2110_init_interface,
+};
+
 static struct phy_driver mv3310_drivers[] = {
 	{
 		.phy_id		= MARVELL_PHY_ID_88X3310,
 		.phy_id_mask	= MARVELL_PHY_ID_MASK,
 		.name		= "mv88x3310",
+		.driver_data	= &mv3310_type,
 		.get_features	= mv3310_get_features,
 		.config_init	= mv3310_config_init,
 		.probe		= mv3310_probe,
@@ -810,6 +891,7 @@ static struct phy_driver mv3310_drivers[] = {
 		.phy_id		= MARVELL_PHY_ID_88E2110,
 		.phy_id_mask	= MARVELL_PHY_ID_MASK,
 		.name		= "mv88x2110",
+		.driver_data	= &mv2110_type,
 		.probe		= mv3310_probe,
 		.suspend	= mv3310_suspend,
 		.resume		= mv3310_resume,
-- 
2.26.2

Re: [PATCH net-next v3 07/18] net: phy: marvell10g: support all rate matching modes

[Andrew Lunn]

> +static inline const struct mv3310_chip *
> +to_mv3310_chip(struct phy_device *phydev)
> +{
> +	return phydev->drv->driver_data;
> +}

No inline functions in C code please. Let the compiler decide.

   Andrew

Re: [PATCH net-next v3 07/18] net: phy: marvell10g: support all rate matching modes

[Marek Behún]

On Wed, 7 Apr 2021 01:30:28 +0200
Andrew Lunn <andrew@lunn.ch> wrote:

> > +static inline const struct mv3310_chip *
> > +to_mv3310_chip(struct phy_device *phydev)
> > +{
> > +	return phydev->drv->driver_data;
> > +}  
> 
> No inline functions in C code please. Let the compiler decide.
> 
>    Andrew

Fixed in my repo. Will send changed for v4.

Marek

Re: [PATCH net-next v3 07/18] net: phy: marvell10g: support all rate matching modes

[Andrew Lunn]

On Wed, Apr 07, 2021 at 12:10:56AM +0200, Marek Behún wrote:
> Add support for all rate matching modes for 88X3310 (currently only
> 10gbase-r is supported, but xaui and rxaui can also be used).
> 
> Add support for rate matching for 88E2110 (on 88E2110 the MACTYPE
> register is at a different place).

What is not clear to me is how rate matching mode gets enabled. What
sets the mactype to one of these modes?

It probably just needs an explanation here in the commit message.

   Andrew

Re: [PATCH net-next v3 07/18] net: phy: marvell10g: support all rate matching modes

[Marek Behún]

On Wed, 7 Apr 2021 01:33:33 +0200
Andrew Lunn <andrew@lunn.ch> wrote:

> On Wed, Apr 07, 2021 at 12:10:56AM +0200, Marek Behún wrote:
> > Add support for all rate matching modes for 88X3310 (currently only
> > 10gbase-r is supported, but xaui and rxaui can also be used).
> > 
> > Add support for rate matching for 88E2110 (on 88E2110 the MACTYPE
> > register is at a different place).  
> 
> What is not clear to me is how rate matching mode gets enabled. What
> sets the mactype to one of these modes?
> 
> It probably just needs an explanation here in the commit message.
> 
>    Andrew

Currently MACTYPE is set via strapping pins. I will add this to the
commit message for v4.

Both Russell King and myself are working on patches to support
selecting correct/better MACTYPE from information about which interface
modes are supported by the MAC and by the board. But first I want to
get this merged.

Marek

[PATCH net-next v3 08/18] include: add library helpers for variadic macro expansion

[Marek Behún]

Add a library with useful helpers to expand variadic macros.

We have the macro DECLARE_BITMAP(name, bits), but no way of compile-time
initialization of such bitmaps. Since C does not support consteval
functions, this can only be done via macros.

This macro library can be (among other things) used to implement a sane
way for compile-time bitmap initialization, something like
  static DECLARE_BITMAP(bm, 100) = INITIALIZE_BITMAP(100, 7, 9, 66, 98);

Signed-off-by: Marek Behún <kabel@kernel.org>
---
 include/linux/variadic-macro.h | 221 +++++++++++++++++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 include/linux/variadic-macro.h

diff --git a/include/linux/variadic-macro.h b/include/linux/variadic-macro.h
new file mode 100644
index 000000000000..5b21a66884e4
--- /dev/null
+++ b/include/linux/variadic-macro.h
@@ -0,0 +1,221 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Helpers for expanding variadic macros in useful ways
+ *
+ * 2021 by Marek Behún <kabel@kernel.org>
+ */
+
+#ifndef __VARIADIC_MACRO_H__
+#define __VARIADIC_MACRO_H__
+
+/*
+ * Helpers for variadic macros with up to 32 arguments.
+ * Pretty simple to extend.
+ */
+
+#define _VM_GET_NTH_ARG(_1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, \
+	_13, _14, _15, _16, _17, _18, _19, _20, _21, _22, _23, _24, _25, _26, \
+	_27, _28, _29, _30, _31, _32, N, ...) N
+
+#define _VM_HELP_0(_f, _d, ...)
+#define _VM_HELP_1(_f, _d, x, ...) _f(x, _d)
+#define _VM_HELP_2(_f, _d, x, ...) _f(x, _d) _VM_HELP_1(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_3(_f, _d, x, ...) _f(x, _d) _VM_HELP_2(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_4(_f, _d, x, ...) _f(x, _d) _VM_HELP_3(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_5(_f, _d, x, ...) _f(x, _d) _VM_HELP_4(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_6(_f, _d, x, ...) _f(x, _d) _VM_HELP_5(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_7(_f, _d, x, ...) _f(x, _d) _VM_HELP_6(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_8(_f, _d, x, ...) _f(x, _d) _VM_HELP_7(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_9(_f, _d, x, ...) _f(x, _d) _VM_HELP_8(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_10(_f, _d, x, ...) _f(x, _d) _VM_HELP_9(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_11(_f, _d, x, ...) _f(x, _d) _VM_HELP_10(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_12(_f, _d, x, ...) _f(x, _d) _VM_HELP_11(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_13(_f, _d, x, ...) _f(x, _d) _VM_HELP_12(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_14(_f, _d, x, ...) _f(x, _d) _VM_HELP_13(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_15(_f, _d, x, ...) _f(x, _d) _VM_HELP_14(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_16(_f, _d, x, ...) _f(x, _d) _VM_HELP_15(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_17(_f, _d, x, ...) _f(x, _d) _VM_HELP_16(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_18(_f, _d, x, ...) _f(x, _d) _VM_HELP_17(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_19(_f, _d, x, ...) _f(x, _d) _VM_HELP_18(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_20(_f, _d, x, ...) _f(x, _d) _VM_HELP_19(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_21(_f, _d, x, ...) _f(x, _d) _VM_HELP_20(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_22(_f, _d, x, ...) _f(x, _d) _VM_HELP_21(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_23(_f, _d, x, ...) _f(x, _d) _VM_HELP_22(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_24(_f, _d, x, ...) _f(x, _d) _VM_HELP_23(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_25(_f, _d, x, ...) _f(x, _d) _VM_HELP_24(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_26(_f, _d, x, ...) _f(x, _d) _VM_HELP_25(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_27(_f, _d, x, ...) _f(x, _d) _VM_HELP_26(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_28(_f, _d, x, ...) _f(x, _d) _VM_HELP_27(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_29(_f, _d, x, ...) _f(x, _d) _VM_HELP_28(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_30(_f, _d, x, ...) _f(x, _d) _VM_HELP_29(_f, _d, ##__VA_ARGS__)
+#define _VM_HELP_31(_f, _d, x, ...) _f(x, _d) _VM_HELP_30(_f, _d, ##__VA_ARGS__)
+
+/*
+ * EXPAND_FOR_EACH(_functor, _data, args...) - expand a call to functor for
+ *					       each argument
+ * @_functor:	name of the functor to expand a call to
+ * @_data:	private data to apply to the functor
+ * @args...:	for each of these arguments a call to functor will be expanded
+ *
+ * This macro will expand to a call to _functor(arg, _data) for all arguments
+ * after the _data argument, i.e.
+ *   EXPAND_FOR_EACH(f, d, 1, 2, 3)
+ * will expand to
+ *   f(1, d) f(2, d) f(3, d)
+ *
+ * ATTENTION: the functor cannot call EXPAND_FOR_EACH again.
+ * For recursive calls to EXPAND_FOR_EACH to be allowed, use EXPAND_FOR_EACH_R
+ * together with EXPAND_EVAL.
+ * Or you can call EXPAND_FOR_EACH in the functor for EXPAND_FOR_EACH_PASS_ARGS.
+ *
+ * Example:
+ *
+ * ::
+ *
+ *   #define __BIT_OR(x, dummy) | BIT(x)
+ *   #define BIT_OR(...) (0 EXPAND_FOR_EACH(__BIT_OR, dummy, ##__VA_ARGS__))
+ *
+ *   int x = BIT_OR(1, 7, 9, 13);
+ *   assert(x == (BIT(1) | BIT(7) | BIT(9) | BIT(13)));
+ */
+#define EXPAND_FOR_EACH(_functor, _data, ...)				 \
+	_VM_GET_NTH_ARG("", ##__VA_ARGS__, _VM_HELP_31, _VM_HELP_30,	 \
+	_VM_HELP_29, _VM_HELP_28, _VM_HELP_27, _VM_HELP_26, _VM_HELP_25, \
+	_VM_HELP_24, _VM_HELP_23, _VM_HELP_22, _VM_HELP_21, _VM_HELP_20, \
+	_VM_HELP_19, _VM_HELP_18, _VM_HELP_17, _VM_HELP_16, _VM_HELP_15, \
+	_VM_HELP_14, _VM_HELP_13, _VM_HELP_12, _VM_HELP_11, _VM_HELP_10, \
+	_VM_HELP_9, _VM_HELP_8, _VM_HELP_7, _VM_HELP_6, _VM_HELP_5,	 \
+	_VM_HELP_4, _VM_HELP_3, _VM_HELP_2, _VM_HELP_1,			 \
+	_VM_HELP_0)(_functor, _data, ##__VA_ARGS__)
+
+/*
+ * Black magic to prevent macros from creating disabling contexts
+ */
+#define _VM_EMPTY(...)
+#define _VM_DEFER(...) __VA_ARGS__ _VM_EMPTY()
+
+#define EXPAND_EVAL(...) _VM_EVAL1(_VM_EVAL1(_VM_EVAL1(__VA_ARGS__)))
+#define _VM_EVAL1(...) _VM_EVAL2(_VM_EVAL2(_VM_EVAL2(__VA_ARGS__)))
+#define _VM_EVAL2(...) _VM_EVAL3(_VM_EVAL3(_VM_EVAL3(__VA_ARGS__)))
+#define _VM_EVAL3(...) __VA_ARGS__
+
+#define _VM_APPLY(x, _functor, _data, ...) _functor(x, _data, ##__VA_ARGS__)
+#define _VM_APPLY_INDIRECT() _VM_APPLY
+#define _VM_APPLY_HELPER(x, __args) \
+	_VM_DEFER(_VM_APPLY_INDIRECT)()(x, _VM_DEFER __args)
+
+#define _VM_EXPAND_FOR_EACH_INDIRECT() EXPAND_FOR_EACH
+
+/*
+ * EXPAND_FOR_EACH_R(_functor, _data, args...) - expand a call to functor for
+ *						 each argument, recursive calls
+ *						 allowed
+ * @_functor:	name of the functor to expand a call to
+ * @_data:	private data to apply to the functor
+ * @args...:	for each of these arguments a call to functor will be expanded
+ *
+ * Does the same as EXPAND_FOR_EACH(_functor, _data, args...), but _functor is
+ * allowed to call EXPAND_FOR_EACH_R again.
+ *
+ * ATTENTION: in order for this to work, the outermost call to this macro must
+ * be wrapped inside the EXPAND_EVAL macro.
+ *
+ * Example:
+ *
+ * ::
+ *
+ *   #define EXP_3(y, x) x ## y
+ *   #define EXP_2(x, ...) EXPAND_FOR_EACH_R(EXP_3, x, ##__VA_ARGS__)
+ *   #define EXP_1(x, dummy) EXP_2(x, 1, 2, 3)
+ *   #define EXP(...) EXPAND_EVAL(EXPAND_FOR_EACH_R(EXP_1, dummy, ##__VA_ARGS__))
+ *
+ *   EXP(a, b, c)
+ *   // expands to: a1 a2 a3 b1 b2 b3 c1 c2 c3
+ */
+#define EXPAND_FOR_EACH_R _VM_DEFER(_VM_EXPAND_FOR_EACH_INDIRECT)()
+
+#define _VM_EXPAND_FOR_EACH_PASS_ARGS(_functor, _data, ...) \
+	_VM_DEFER(_VM_EXPAND_FOR_EACH_INDIRECT)()(_VM_APPLY_HELPER, \
+	(_functor, _data, ##__VA_ARGS__), ##__VA_ARGS__)
+
+/*
+ * EXPAND_FOR_EACH_PASS_ARGS(_functor, _data, args...) -
+ *   expand a call to functor for each argument, pass all arguments to each call
+ * @_functor:	name of the functor to expand a call to
+ * @_data:	private data to apply to the functor
+ * @args...:	for each of these arguments a call to functor will be expanded
+ *
+ * For each argument after the _data argument, a call to
+ * _functor(arg, _data, args...) will be expanded.
+ * This is similar to EXPAND_FOR_EACH, but each expanded call will also be
+ * passed all the original arguments, i.e.
+ *   EXPAND_FOR_EACH_PASS_ARGS(f, d, 1, 2, 3)
+ * will expand to
+ *   f(1, d, 1, 2, 3) f(2, d, 1, 2, 3) f(3, d, 1, 2, 3)
+ *
+ * This is useful when one needs to call EXPAND_FOR_EACH in the functor again,
+ * to expand all the arguments in some way for each argument.
+ *
+ * ATTENTION: the functor cannot call EXPAND_FOR_EACH_PASS_ARGS again.
+ * For recursive calls to EXPAND_FOR_EACH_PASS_ARGS to be allowed, use
+ * EXPAND_FOR_EACH_PASS_ARGS_R together with EXPAND_EVAL.
+ *
+ * Example (a mechanism to compile time bitmap initialization):
+ *
+ * ::
+ *
+ *   #define __BIT_OR(x, dummy) | BIT(x)
+ *   #define BIT_OR(...) (0 EXPAND_FOR_EACH(__BIT_OR, dummy, ##__VA_ARGS__))
+ *   #define BM_MEMB(bit) ((bit) / BITS_PER_LONG)
+ *   #define BM_OR(bit, member) \
+ *     | (BM_MEMB(bit) == member ? BIT((bit) % BITS_PER_LONG) : 0)
+ *   #define INIT_BITMAP_MEMBER(bit, dummy, ...) \
+ *     [BM_MEMB(bit)] = (0 EXPAND_FOR_EACH(BM_OR, BM_MEMB(bit), ##__VA_ARGS__)),
+ *   #define INIT_BITMAP(...) \
+ *     { \
+ *       EXPAND_FOR_EACH_PASS_ARGS(INIT_BITMAP_MEMBER, dummy, ##__VA_ARGS__) \
+ *     }
+ *
+ *   static const DECLARE_BITMAP(bm, 90) =
+ *     INIT_BITMAP(1, 2, 15, 32, 36, 80);
+ */
+#define EXPAND_FOR_EACH_PASS_ARGS(_functor, _data, ...) \
+	EXPAND_EVAL(_VM_EXPAND_FOR_EACH_PASS_ARGS(_functor, \
+						  _data, ##__VA_ARGS__))
+
+#define _VM_EXPAND_FOR_EACH_PASS_ARGS_INDIRECT() _VM_EXPAND_FOR_EACH_PASS_ARGS
+
+/*
+ * EXPAND_FOR_EACH_PASS_ARGS_R(_functor, _data, args...) -
+ *   expand a call to functor for each argument, pass all arguments to each
+ *   call, recursive calls allowed
+ * @_functor:	name of the functor to expand a call to
+ * @_data:	private data to apply to the functor
+ * @args...:	for each of these arguments a call to functor will be expanded
+ *
+ * Does the same as EXPAND_FOR_EACH_PASS_ARGS(_functor, _data, args...), but
+ * _functor is allowed to call EXPAND_FOR_EACH_PASS_ARGS_R again.
+ *
+ * ATTENTION: in order for this to work, the outermost call to this macro must
+ * be wrapped inside the EXPAND_EVAL macro.
+ *
+ * Example:
+ *
+ * ::
+ *
+ *   #define EXP_4(xy, z) z ## xy
+ *   #define EXP_3(y, x, ...) EXPAND_FOR_EACH(EXP_4, x ## y, ##__VA_ARGS__)
+ *   #define EXP_2(x, ...) EXPAND_FOR_EACH_PASS_ARGS_R(EXP_3, x, ##__VA_ARGS__)
+ *   #define EXP_1(x, dummy, ...) EXP_2(x, __VA_ARGS__)
+ *   #define EXP(...) \
+ *     EXPAND_EVAL(EXPAND_FOR_EACH_PASS_ARGS_R(EXP_1, dummy, ##__VA_ARGS__))
+ *
+ *   EXP(a, b, c)
+ *   // expands to: aaa aab aac aba abb abc aca acb acc
+ *   //             baa bab bac bba bbb bbc bca bcb bcc
+ *   //             caa cab cac cba cbb cbc cca ccb ccc
+ */
+#define EXPAND_FOR_EACH_PASS_ARGS_R \
+	_VM_DEFER(_VM_EXPAND_FOR_EACH_PASS_ARGS_INDIRECT)()
+
+#endif /* __VARIADIC_MACRO_H__ */
-- 
2.26.2

[PATCH net-next v3 09/18] include: bitmap: add macro for bitmap initialization

[Marek Behún]

Use the new variadic-macro.h library to implement macro
INITIALIZE_BITMAP(nbits, ...), which can be used for compile time bitmap
initialization in the form
  static DECLARE_BITMAP(bm, 100) = INITIALIZE_BITMAP(100, 7, 9, 66, 98);

The macro uses the BUILD_BUG_ON_ZERO mechanism to ensure a compile-time
error if an argument is out of range.

Signed-off-by: Marek Behún <kabel@kernel.org>
---
 include/linux/bitmap.h | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 70a932470b2d..a9e74d3420bf 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -8,6 +8,7 @@
 #include <linux/bitops.h>
 #include <linux/string.h>
 #include <linux/kernel.h>
+#include <linux/variadic-macro.h>
 
 /*
  * bitmaps provide bit arrays that consume one or more unsigned
@@ -114,6 +115,29 @@
  * contain all bit positions from 0 to 'bits' - 1.
  */
 
+/**
+ * DOC: initialize bitmap
+ * The INITIALIZE_BITMAP(bits, args...) macro expands to a designated
+ * initializer for bitmap of length 'bits', setting each bit specified
+ * in 'args...'.
+ */
+#define _BIT_MEMBER(bit) ((bit) / BITS_PER_LONG)
+#define _VERIFY_BIT(bit, nbits)						\
+	BUILD_BUG_ON_ZERO((bit) < 0 || (bit) >= (nbits))
+#define _INIT_BITMAP_MEMBER_VALUE(bit, member_bit)			\
+	| (_BIT_MEMBER(bit) == _BIT_MEMBER(member_bit)			\
+		? BIT((bit) % BITS_PER_LONG)				\
+		: 0)
+#define _INIT_BITMAP_MEMBER(bit, nbits, ...)				\
+	[_VERIFY_BIT((bit), (nbits)) + _BIT_MEMBER(bit)] =		\
+		(0 EXPAND_FOR_EACH(_INIT_BITMAP_MEMBER_VALUE,		\
+				   (bit), ##__VA_ARGS__)),
+#define INITIALIZE_BITMAP(nbits, ...)					\
+	{								\
+		EXPAND_FOR_EACH_PASS_ARGS(_INIT_BITMAP_MEMBER, (nbits),	\
+					  ##__VA_ARGS__)		\
+	}
+
 /*
  * Allocation and deallocation of bitmap.
  * Provided in lib/bitmap.c to avoid circular dependency.
-- 
2.26.2

Re: [PATCH net-next v3 09/18] include: bitmap: add macro for bitmap initialization

[Andrew Lunn]

On Wed, Apr 07, 2021 at 12:10:58AM +0200, Marek Behún wrote:
> Use the new variadic-macro.h library to implement macro
> INITIALIZE_BITMAP(nbits, ...), which can be used for compile time bitmap
> initialization in the form
>   static DECLARE_BITMAP(bm, 100) = INITIALIZE_BITMAP(100, 7, 9, 66, 98);
> 
> The macro uses the BUILD_BUG_ON_ZERO mechanism to ensure a compile-time
> error if an argument is out of range.
> 
> Signed-off-by: Marek Behún <kabel@kernel.org>
> ---
>  include/linux/bitmap.h | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
> index 70a932470b2d..a9e74d3420bf 100644
> --- a/include/linux/bitmap.h
> +++ b/include/linux/bitmap.h
> @@ -8,6 +8,7 @@
>  #include <linux/bitops.h>
>  #include <linux/string.h>
>  #include <linux/kernel.h>
> +#include <linux/variadic-macro.h>
>  
>  /*
>   * bitmaps provide bit arrays that consume one or more unsigned
> @@ -114,6 +115,29 @@
>   * contain all bit positions from 0 to 'bits' - 1.
>   */
>  
> +/**
> + * DOC: initialize bitmap
> + * The INITIALIZE_BITMAP(bits, args...) macro expands to a designated
> + * initializer for bitmap of length 'bits', setting each bit specified
> + * in 'args...'.
> + */

Doesn't the /** mean this is kernel doc? The rest does not seem to
follow kdoc. Does this compile cleanly with W=1?

       Andrew

Re: [PATCH net-next v3 09/18] include: bitmap: add macro for bitmap initialization

[Marek Behún]

On Wed, 7 Apr 2021 01:38:30 +0200
Andrew Lunn <andrew@lunn.ch> wrote:

> On Wed, Apr 07, 2021 at 12:10:58AM +0200, Marek Behún wrote:
> > Use the new variadic-macro.h library to implement macro
> > INITIALIZE_BITMAP(nbits, ...), which can be used for compile time bitmap
> > initialization in the form
> >   static DECLARE_BITMAP(bm, 100) = INITIALIZE_BITMAP(100, 7, 9, 66, 98);
> > 
> > The macro uses the BUILD_BUG_ON_ZERO mechanism to ensure a compile-time
> > error if an argument is out of range.
> > 
> > Signed-off-by: Marek Behún <kabel@kernel.org>
> > ---
> >  include/linux/bitmap.h | 24 ++++++++++++++++++++++++
> >  1 file changed, 24 insertions(+)
> > 
> > diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
> > index 70a932470b2d..a9e74d3420bf 100644
> > --- a/include/linux/bitmap.h
> > +++ b/include/linux/bitmap.h
> > @@ -8,6 +8,7 @@
> >  #include <linux/bitops.h>
> >  #include <linux/string.h>
> >  #include <linux/kernel.h>
> > +#include <linux/variadic-macro.h>
> >  
> >  /*
> >   * bitmaps provide bit arrays that consume one or more unsigned
> > @@ -114,6 +115,29 @@
> >   * contain all bit positions from 0 to 'bits' - 1.
> >   */
> >  
> > +/**
> > + * DOC: initialize bitmap
> > + * The INITIALIZE_BITMAP(bits, args...) macro expands to a designated
> > + * initializer for bitmap of length 'bits', setting each bit specified
> > + * in 'args...'.
> > + */  
> 
> Doesn't the /** mean this is kernel doc? The rest does not seem to
> follow kdoc. Does this compile cleanly with W=1?
> 
>        Andrew

Hmm. I just used the same style as was above in the same file, for
/**
 * DOC: declare bitmap
 ...

Anyway W=1 does not complain.

But it does complain about the implementation for INITIALIZE_BITMAP. It
seems that we have to use -Wno-override-init.
This seems to be a new option for gcc. For clang,
scripts/Makefile.extrawarn already uses -Wno-initializer-overrides, but
we have to add -Wno-override-init for gcc.

Marek

[PATCH net-next v3 10/18] net: phy: marvell10g: check for correct supported interface mode

[Marek Behún]

The 88E2110 does not support xaui nor rxaui modes. Check for correct
interface mode for different chips.

Signed-off-by: Marek Behún <kabel@kernel.org>
---
 drivers/net/phy/marvell10g.c | 25 ++++++++++++++++++-------
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index fc298e53f165..e3ced38f40c9 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -109,6 +109,7 @@ enum {
 };
 
 struct mv3310_chip {
+	DECLARE_BITMAP(supported_interfaces, PHY_INTERFACE_MODE_MAX);
 	int (*get_mactype)(struct phy_device *phydev);
 	int (*init_interface)(struct phy_device *phydev, int mactype);
 };
@@ -545,13 +546,7 @@ static int mv3310_config_init(struct phy_device *phydev)
 	int err, mactype;
 
 	/* Check that the PHY interface type is compatible */
-	if (phydev->interface != PHY_INTERFACE_MODE_SGMII &&
-	    phydev->interface != PHY_INTERFACE_MODE_2500BASEX &&
-	    phydev->interface != PHY_INTERFACE_MODE_5GBASER &&
-	    phydev->interface != PHY_INTERFACE_MODE_XAUI &&
-	    phydev->interface != PHY_INTERFACE_MODE_RXAUI &&
-	    phydev->interface != PHY_INTERFACE_MODE_10GBASER &&
-	    phydev->interface != PHY_INTERFACE_MODE_USXGMII)
+	if (!test_bit(phydev->interface, chip->supported_interfaces))
 		return -ENODEV;
 
 	phydev->mdix_ctrl = ETH_TP_MDI_AUTO;
@@ -859,11 +854,27 @@ static int mv3310_set_tunable(struct phy_device *phydev,
 }
 
 static const struct mv3310_chip mv3310_type = {
+	.supported_interfaces =
+		INITIALIZE_BITMAP(PHY_INTERFACE_MODE_MAX,
+				  PHY_INTERFACE_MODE_SGMII,
+				  PHY_INTERFACE_MODE_2500BASEX,
+				  PHY_INTERFACE_MODE_5GBASER,
+				  PHY_INTERFACE_MODE_XAUI,
+				  PHY_INTERFACE_MODE_RXAUI,
+				  PHY_INTERFACE_MODE_10GBASER,
+				  PHY_INTERFACE_MODE_USXGMII),
 	.get_mactype = mv3310_get_mactype,
 	.init_interface = mv3310_init_interface,
 };
 
 static const struct mv3310_chip mv2110_type = {
+	.supported_interfaces =
+		INITIALIZE_BITMAP(PHY_INTERFACE_MODE_MAX,
+				  PHY_INTERFACE_MODE_SGMII,
+				  PHY_INTERFACE_MODE_2500BASEX,
+				  PHY_INTERFACE_MODE_5GBASER,
+				  PHY_INTERFACE_MODE_10GBASER,
+				  PHY_INTERFACE_MODE_USXGMII),
 	.get_mactype = mv2110_get_mactype,
 	.init_interface = mv2110_init_interface,
 };
-- 
2.26.2

Re: [PATCH net-next v3 10/18] net: phy: marvell10g: check for correct supported interface mode

[Andrew Lunn]

On Wed, Apr 07, 2021 at 12:10:59AM +0200, Marek Behún wrote:
> The 88E2110 does not support xaui nor rxaui modes. Check for correct
> interface mode for different chips.
> 
> Signed-off-by: Marek Behún <kabel@kernel.org>

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

    Andrew

[PATCH net-next v3 11/18] net: phy: marvell10g: store temperature read method in chip strucutre

[Marek Behún]

Now that we have a chip structure, we can store the temperature reading
method in this structure (OOP style).

Signed-off-by: Marek Behún <kabel@kernel.org>
---
 drivers/net/phy/marvell10g.c | 23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index e3ced38f40c9..a7c7c87201fa 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -112,6 +112,10 @@ struct mv3310_chip {
 	DECLARE_BITMAP(supported_interfaces, PHY_INTERFACE_MODE_MAX);
 	int (*get_mactype)(struct phy_device *phydev);
 	int (*init_interface)(struct phy_device *phydev, int mactype);
+
+#ifdef CONFIG_HWMON
+	int (*hwmon_read_temp_reg)(struct phy_device *phydev);
+#endif
 };
 
 struct mv3310_priv {
@@ -151,18 +155,11 @@ static int mv2110_hwmon_read_temp_reg(struct phy_device *phydev)
 	return phy_read_mmd(phydev, MDIO_MMD_PCS, MV_PCS_TEMP);
 }
 
-static int mv10g_hwmon_read_temp_reg(struct phy_device *phydev)
-{
-	if (phydev->drv->phy_id == MARVELL_PHY_ID_88X3310)
-		return mv3310_hwmon_read_temp_reg(phydev);
-	else /* MARVELL_PHY_ID_88E2110 */
-		return mv2110_hwmon_read_temp_reg(phydev);
-}
-
 static int mv3310_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
 			     u32 attr, int channel, long *value)
 {
 	struct phy_device *phydev = dev_get_drvdata(dev);
+	const struct mv3310_chip *chip = to_mv3310_chip(phydev);
 	int temp;
 
 	if (type == hwmon_chip && attr == hwmon_chip_update_interval) {
@@ -171,7 +168,7 @@ static int mv3310_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
 	}
 
 	if (type == hwmon_temp && attr == hwmon_temp_input) {
-		temp = mv10g_hwmon_read_temp_reg(phydev);
+		temp = chip->hwmon_read_temp_reg(phydev);
 		if (temp < 0)
 			return temp;
 
@@ -865,6 +862,10 @@ static const struct mv3310_chip mv3310_type = {
 				  PHY_INTERFACE_MODE_USXGMII),
 	.get_mactype = mv3310_get_mactype,
 	.init_interface = mv3310_init_interface,
+
+#ifdef CONFIG_HWMON
+	.hwmon_read_temp_reg = mv3310_hwmon_read_temp_reg,
+#endif
 };
 
 static const struct mv3310_chip mv2110_type = {
@@ -877,6 +878,10 @@ static const struct mv3310_chip mv2110_type = {
 				  PHY_INTERFACE_MODE_USXGMII),
 	.get_mactype = mv2110_get_mactype,
 	.init_interface = mv2110_init_interface,
+
+#ifdef CONFIG_HWMON
+	.hwmon_read_temp_reg = mv2110_hwmon_read_temp_reg,
+#endif
 };
 
 static struct phy_driver mv3310_drivers[] = {
-- 
2.26.2

Re: [PATCH net-next v3 11/18] net: phy: marvell10g: store temperature read method in chip strucutre

[Andrew Lunn]

On Wed, Apr 07, 2021 at 12:11:00AM +0200, Marek Behún wrote:
> Now that we have a chip structure, we can store the temperature reading
> method in this structure (OOP style).
> 
> Signed-off-by: Marek Behún <kabel@kernel.org>

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

    Andrew

[PATCH net-next v3 12/18] net: phy: marvell10g: support other MACTYPEs

[Marek Behún]

Currently the only "changing" MACTYPE we support is when the PHY changes
between
  10gbase-r / 5gbase-r / 2500base-x / sgmii

Add support for
  usxgmii
  xaui / 5gbase-r / 2500base-x / sgmii
  rxaui / 5gbase-r / 2500base-x / sgmii
and also
  5gbase-r / 2500base-x / sgmii
for 88E2110.

Signed-off-by: Marek Behún <kabel@kernel.org>
---
 drivers/net/phy/marvell10g.c | 90 +++++++++++++++++++++---------------
 1 file changed, 54 insertions(+), 36 deletions(-)

diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index a7c7c87201fa..2fd823318de8 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -508,10 +508,18 @@ static int mv2110_init_interface(struct phy_device *phydev, int mactype)
 
 	priv->rate_match = false;
 
-	if (mactype == MV_PMA_21X0_PORT_CTRL_MACTYPE_10GBASER_RATE_MATCH) {
+	if (mactype == MV_PMA_21X0_PORT_CTRL_MACTYPE_10GBASER_RATE_MATCH)
 		priv->rate_match = true;
+
+	if (mactype == MV_PMA_21X0_PORT_CTRL_MACTYPE_USXGMII)
+		priv->const_interface = PHY_INTERFACE_MODE_USXGMII;
+	else if (mactype == MV_PMA_21X0_PORT_CTRL_MACTYPE_10GBASER_RATE_MATCH)
 		priv->const_interface = PHY_INTERFACE_MODE_10GBASER;
-	}
+	else if (mactype == MV_PMA_21X0_PORT_CTRL_MACTYPE_5GBASER ||
+		 mactype == MV_PMA_21X0_PORT_CTRL_MACTYPE_5GBASER_NO_SGMII_AN)
+		priv->const_interface = PHY_INTERFACE_MODE_NA;
+	else
+		return -EINVAL;
 
 	return 0;
 }
@@ -527,12 +535,20 @@ static int mv3310_init_interface(struct phy_device *phydev, int mactype)
 	    mactype == MV_V2_3310_PORT_CTRL_MACTYPE_XAUI_RATE_MATCH)
 		priv->rate_match = true;
 
-	if (mactype == MV_V2_33X0_PORT_CTRL_MACTYPE_10GBASER_RATE_MATCH)
+	if (mactype == MV_V2_33X0_PORT_CTRL_MACTYPE_USXGMII)
+		priv->const_interface = PHY_INTERFACE_MODE_USXGMII;
+	else if (mactype == MV_V2_33X0_PORT_CTRL_MACTYPE_10GBASER_RATE_MATCH ||
+		 mactype == MV_V2_33X0_PORT_CTRL_MACTYPE_10GBASER_NO_SGMII_AN ||
+		 mactype == MV_V2_33X0_PORT_CTRL_MACTYPE_10GBASER)
 		priv->const_interface = PHY_INTERFACE_MODE_10GBASER;
-	else if (mactype == MV_V2_33X0_PORT_CTRL_MACTYPE_RXAUI_RATE_MATCH)
+	else if (mactype == MV_V2_33X0_PORT_CTRL_MACTYPE_RXAUI_RATE_MATCH ||
+		 mactype == MV_V2_33X0_PORT_CTRL_MACTYPE_RXAUI)
 		priv->const_interface = PHY_INTERFACE_MODE_RXAUI;
-	else if (mactype == MV_V2_3310_PORT_CTRL_MACTYPE_XAUI_RATE_MATCH)
+	else if (mactype == MV_V2_3310_PORT_CTRL_MACTYPE_XAUI_RATE_MATCH ||
+		 mactype == MV_V2_3310_PORT_CTRL_MACTYPE_XAUI)
 		priv->const_interface = PHY_INTERFACE_MODE_XAUI;
+	else
+		return -EINVAL;
 
 	return 0;
 }
@@ -558,8 +574,10 @@ static int mv3310_config_init(struct phy_device *phydev)
 		return mactype;
 
 	err = chip->init_interface(phydev, mactype);
-	if (err)
+	if (err) {
+		phydev_err(phydev, "MACTYPE configuration invalid\n");
 		return err;
+	}
 
 	/* Enable EDPD mode - saving 600mW */
 	return mv3310_set_edpd(phydev, ETHTOOL_PHY_EDPD_DFLT_TX_MSECS);
@@ -669,44 +687,44 @@ static void mv3310_update_interface(struct phy_device *phydev)
 {
 	struct mv3310_priv *priv = dev_get_drvdata(&phydev->mdio.dev);
 
+	if (!phydev->link)
+		return;
+
 	/* In all of the "* with Rate Matching" modes the PHY interface is fixed
 	 * at 10Gb. The PHY adapts the rate to actual wire speed with help of
 	 * internal 16KB buffer.
+	 *
+	 * In USXGMII mode the PHY interface mode is also fixed.
 	 */
-	if (priv->rate_match) {
+	if (priv->rate_match ||
+	    priv->const_interface == PHY_INTERFACE_MODE_USXGMII) {
 		phydev->interface = priv->const_interface;
 		return;
 	}
 
-	if ((phydev->interface == PHY_INTERFACE_MODE_SGMII ||
-	     phydev->interface == PHY_INTERFACE_MODE_2500BASEX ||
-	     phydev->interface == PHY_INTERFACE_MODE_5GBASER ||
-	     phydev->interface == PHY_INTERFACE_MODE_10GBASER) &&
-	    phydev->link) {
-		/* The PHY automatically switches its serdes interface (and
-		 * active PHYXS instance) between Cisco SGMII, 10GBase-R and
-		 * 2500BaseX modes according to the speed.  Florian suggests
-		 * setting phydev->interface to communicate this to the MAC.
-		 * Only do this if we are already in one of the above modes.
-		 */
-		switch (phydev->speed) {
-		case SPEED_10000:
-			phydev->interface = PHY_INTERFACE_MODE_10GBASER;
-			break;
-		case SPEED_5000:
-			phydev->interface = PHY_INTERFACE_MODE_5GBASER;
-			break;
-		case SPEED_2500:
-			phydev->interface = PHY_INTERFACE_MODE_2500BASEX;
-			break;
-		case SPEED_1000:
-		case SPEED_100:
-		case SPEED_10:
-			phydev->interface = PHY_INTERFACE_MODE_SGMII;
-			break;
-		default:
-			break;
-		}
+	/* The PHY automatically switches its serdes interface (and active PHYXS
+	 * instance) between Cisco SGMII, 2500BaseX, 5GBase-R and 10GBase-R /
+	 * xaui / rxaui modes according to the speed.
+	 * Florian suggests setting phydev->interface to communicate this to the
+	 * MAC. Only do this if we are already in one of the above modes.
+	 */
+	switch (phydev->speed) {
+	case SPEED_10000:
+		phydev->interface = priv->const_interface;
+		break;
+	case SPEED_5000:
+		phydev->interface = PHY_INTERFACE_MODE_5GBASER;
+		break;
+	case SPEED_2500:
+		phydev->interface = PHY_INTERFACE_MODE_2500BASEX;
+		break;
+	case SPEED_1000:
+	case SPEED_100:
+	case SPEED_10:
+		phydev->interface = PHY_INTERFACE_MODE_SGMII;
+		break;
+	default:
+		break;
 	}
 }
 
-- 
2.26.2

[PATCH net-next v3 13/18] net: phy: marvell10g: add separate structure for 88X3340

[Marek Behún]

The 88X3340 contains 4 cores similar to 88X3310, but there is a
difference: it does not support xaui host mode. Instead the
corresponding MACTYPE means
  rxaui / 5gbase-r / 2500base-x / sgmii without AN

Signed-off-by: Marek Behún <kabel@kernel.org>
---
 drivers/net/phy/marvell10g.c | 55 ++++++++++++++++++++++++++++++++++--
 include/linux/marvell_phy.h  |  6 +++-
 2 files changed, 58 insertions(+), 3 deletions(-)

diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 2fd823318de8..74a91853ef46 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -553,6 +553,21 @@ static int mv3310_init_interface(struct phy_device *phydev, int mactype)
 	return 0;
 }
 
+static int mv3340_init_interface(struct phy_device *phydev, int mactype)
+{
+	struct mv3310_priv *priv = dev_get_drvdata(&phydev->mdio.dev);
+	int err = 0;
+
+	priv->rate_match = false;
+
+	if (mactype == MV_V2_3340_PORT_CTRL_MACTYPE_RXAUI_NO_SGMII_AN)
+		priv->const_interface = PHY_INTERFACE_MODE_RXAUI;
+	else
+		err = mv3310_init_interface(phydev, mactype);
+
+	return err;
+}
+
 static int mv3310_config_init(struct phy_device *phydev)
 {
 	const struct mv3310_chip *chip = to_mv3310_chip(phydev);
@@ -886,6 +901,23 @@ static const struct mv3310_chip mv3310_type = {
 #endif
 };
 
+static const struct mv3310_chip mv3340_type = {
+	.supported_interfaces =
+		INITIALIZE_BITMAP(PHY_INTERFACE_MODE_MAX,
+				  PHY_INTERFACE_MODE_SGMII,
+				  PHY_INTERFACE_MODE_2500BASEX,
+				  PHY_INTERFACE_MODE_5GBASER,
+				  PHY_INTERFACE_MODE_RXAUI,
+				  PHY_INTERFACE_MODE_10GBASER,
+				  PHY_INTERFACE_MODE_USXGMII),
+	.get_mactype = mv3310_get_mactype,
+	.init_interface = mv3340_init_interface,
+
+#ifdef CONFIG_HWMON
+	.hwmon_read_temp_reg = mv3310_hwmon_read_temp_reg,
+#endif
+};
+
 static const struct mv3310_chip mv2110_type = {
 	.supported_interfaces =
 		INITIALIZE_BITMAP(PHY_INTERFACE_MODE_MAX,
@@ -905,7 +937,7 @@ static const struct mv3310_chip mv2110_type = {
 static struct phy_driver mv3310_drivers[] = {
 	{
 		.phy_id		= MARVELL_PHY_ID_88X3310,
-		.phy_id_mask	= MARVELL_PHY_ID_MASK,
+		.phy_id_mask	= MARVELL_PHY_ID_88X33X0_MASK,
 		.name		= "mv88x3310",
 		.driver_data	= &mv3310_type,
 		.get_features	= mv3310_get_features,
@@ -921,6 +953,24 @@ static struct phy_driver mv3310_drivers[] = {
 		.remove		= mv3310_remove,
 		.set_loopback	= genphy_c45_loopback,
 	},
+	{
+		.phy_id		= MARVELL_PHY_ID_88X3340,
+		.phy_id_mask	= MARVELL_PHY_ID_88X33X0_MASK,
+		.name		= "mv88x3340",
+		.driver_data	= &mv3340_type,
+		.get_features	= mv3310_get_features,
+		.config_init	= mv3310_config_init,
+		.probe		= mv3310_probe,
+		.suspend	= mv3310_suspend,
+		.resume		= mv3310_resume,
+		.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,
+		.remove		= mv3310_remove,
+		.set_loopback	= genphy_c45_loopback,
+	},
 	{
 		.phy_id		= MARVELL_PHY_ID_88E2110,
 		.phy_id_mask	= MARVELL_PHY_ID_MASK,
@@ -943,7 +993,8 @@ static struct phy_driver mv3310_drivers[] = {
 module_phy_driver(mv3310_drivers);
 
 static struct mdio_device_id __maybe_unused mv3310_tbl[] = {
-	{ MARVELL_PHY_ID_88X3310, MARVELL_PHY_ID_MASK },
+	{ MARVELL_PHY_ID_88X3310, MARVELL_PHY_ID_88X33X0_MASK },
+	{ MARVELL_PHY_ID_88X3340, MARVELL_PHY_ID_88X33X0_MASK },
 	{ MARVELL_PHY_ID_88E2110, MARVELL_PHY_ID_MASK },
 	{ },
 };
diff --git a/include/linux/marvell_phy.h b/include/linux/marvell_phy.h
index 274abd5fbac3..6b11a5411082 100644
--- a/include/linux/marvell_phy.h
+++ b/include/linux/marvell_phy.h
@@ -22,10 +22,14 @@
 #define MARVELL_PHY_ID_88E1545		0x01410ea0
 #define MARVELL_PHY_ID_88E1548P		0x01410ec0
 #define MARVELL_PHY_ID_88E3016		0x01410e60
-#define MARVELL_PHY_ID_88X3310		0x002b09a0
 #define MARVELL_PHY_ID_88E2110		0x002b09b0
 #define MARVELL_PHY_ID_88X2222		0x01410f10
 
+/* PHY IDs and mask for Alaska 10G PHYs */
+#define MARVELL_PHY_ID_88X33X0_MASK	0xfffffff8
+#define MARVELL_PHY_ID_88X3310		0x002b09a0
+#define MARVELL_PHY_ID_88X3340		0x002b09a8
+
 /* Marvel 88E1111 in Finisar SFP module with modified PHY ID */
 #define MARVELL_PHY_ID_88E1111_FINISAR	0x01ff0cc0
 
-- 
2.26.2

Re: [PATCH net-next v3 13/18] net: phy: marvell10g: add separate structure for 88X3340

[Andrew Lunn]

On Wed, Apr 07, 2021 at 12:11:02AM +0200, Marek Behún wrote:
> The 88X3340 contains 4 cores similar to 88X3310, but there is a
> difference: it does not support xaui host mode. Instead the
> corresponding MACTYPE means
>   rxaui / 5gbase-r / 2500base-x / sgmii without AN
> 
> Signed-off-by: Marek Behún <kabel@kernel.org>

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

    Andrew

[PATCH net-next v3 14/18] net: phy: marvell10g: fix driver name for mv88e2110

[Marek Behún]

The driver name "mv88x2110" should be instead "mv88e2110".

Signed-off-by: Marek Behún <kabel@kernel.org>
---
 drivers/net/phy/marvell10g.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 74a91853ef46..51b7a5083bdf 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -974,7 +974,7 @@ static struct phy_driver mv3310_drivers[] = {
 	{
 		.phy_id		= MARVELL_PHY_ID_88E2110,
 		.phy_id_mask	= MARVELL_PHY_ID_MASK,
-		.name		= "mv88x2110",
+		.name		= "mv88e2110",
 		.driver_data	= &mv2110_type,
 		.probe		= mv3310_probe,
 		.suspend	= mv3310_suspend,
-- 
2.26.2

Re: [PATCH net-next v3 14/18] net: phy: marvell10g: fix driver name for mv88e2110

[Andrew Lunn]

On Wed, Apr 07, 2021 at 12:11:03AM +0200, Marek Behún wrote:
> The driver name "mv88x2110" should be instead "mv88e2110".
> 
> Signed-off-by: Marek Behún <kabel@kernel.org>

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

    Andrew

[PATCH net-next v3 15/18] net: phy: add constants for 2.5G and 5G speed in PCS speed register

[Marek Behún]

Add constants for 2.5G and 5G speed in PCS speed register into mdio.h.

Signed-off-by: Marek Behún <kabel@kernel.org>
---
 include/uapi/linux/mdio.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/linux/mdio.h b/include/uapi/linux/mdio.h
index 3f302e2523b2..bdf77dffa5a4 100644
--- a/include/uapi/linux/mdio.h
+++ b/include/uapi/linux/mdio.h
@@ -120,6 +120,8 @@
 #define MDIO_PMA_SPEED_100		0x0020	/* 100M capable */
 #define MDIO_PMA_SPEED_10		0x0040	/* 10M capable */
 #define MDIO_PCS_SPEED_10P2B		0x0002	/* 10PASS-TS/2BASE-TL capable */
+#define MDIO_PCS_SPEED_2_5G		0x0040	/* 2.5G capable */
+#define MDIO_PCS_SPEED_5G		0x0080	/* 5G capable */
 
 /* Device present registers. */
 #define MDIO_DEVS_PRESENT(devad)	(1 << (devad))
-- 
2.26.2

Re: [PATCH net-next v3 15/18] net: phy: add constants for 2.5G and 5G speed in PCS speed register

[Andrew Lunn]

On Wed, Apr 07, 2021 at 12:11:04AM +0200, Marek Behún wrote:
> Add constants for 2.5G and 5G speed in PCS speed register into mdio.h.
> 
> Signed-off-by: Marek Behún <kabel@kernel.org>

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

    Andrew

[PATCH net-next v3 16/18] net: phy: marvell10g: differentiate 88E2110 vs 88E2111

[Marek Behún]

88E2111 is a variant of 88E2110 which does not support 5 gigabit speeds.

Differentiate these variants via the match_phy_device() method, since
they have the same PHY ID.

Signed-off-by: Marek Behún <kabel@kernel.org>
---
 drivers/net/phy/marvell10g.c | 59 ++++++++++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)

diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 51b7a5083bdf..6269b9041180 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -934,6 +934,46 @@ static const struct mv3310_chip mv2110_type = {
 #endif
 };
 
+static const struct mv3310_chip mv2111_type = {
+	.supported_interfaces =
+		INITIALIZE_BITMAP(PHY_INTERFACE_MODE_MAX,
+				  PHY_INTERFACE_MODE_SGMII,
+				  PHY_INTERFACE_MODE_2500BASEX,
+				  PHY_INTERFACE_MODE_10GBASER,
+				  PHY_INTERFACE_MODE_USXGMII),
+	.get_mactype = mv2110_get_mactype,
+	.init_interface = mv2110_init_interface,
+
+#ifdef CONFIG_HWMON
+	.hwmon_read_temp_reg = mv2110_hwmon_read_temp_reg,
+#endif
+};
+
+static int mv211x_match_phy_device(struct phy_device *phydev, bool has_5g)
+{
+	int val;
+
+	if ((phydev->c45_ids.device_ids[MDIO_MMD_PMAPMD] &
+	     MARVELL_PHY_ID_MASK) != MARVELL_PHY_ID_88E2110)
+		return 0;
+
+	val = phy_read_mmd(phydev, MDIO_MMD_PCS, MDIO_SPEED);
+	if (val < 0)
+		return val;
+
+	return !!(val & MDIO_PCS_SPEED_5G) == has_5g;
+}
+
+static int mv2110_match_phy_device(struct phy_device *phydev)
+{
+	return mv211x_match_phy_device(phydev, true);
+}
+
+static int mv2111_match_phy_device(struct phy_device *phydev)
+{
+	return mv211x_match_phy_device(phydev, false);
+}
+
 static struct phy_driver mv3310_drivers[] = {
 	{
 		.phy_id		= MARVELL_PHY_ID_88X3310,
@@ -974,6 +1014,7 @@ static struct phy_driver mv3310_drivers[] = {
 	{
 		.phy_id		= MARVELL_PHY_ID_88E2110,
 		.phy_id_mask	= MARVELL_PHY_ID_MASK,
+		.match_phy_device = mv2110_match_phy_device,
 		.name		= "mv88e2110",
 		.driver_data	= &mv2110_type,
 		.probe		= mv3310_probe,
@@ -988,6 +1029,24 @@ static struct phy_driver mv3310_drivers[] = {
 		.remove		= mv3310_remove,
 		.set_loopback	= genphy_c45_loopback,
 	},
+	{
+		.phy_id		= MARVELL_PHY_ID_88E2110,
+		.phy_id_mask	= MARVELL_PHY_ID_MASK,
+		.match_phy_device = mv2111_match_phy_device,
+		.name		= "mv88e2111",
+		.driver_data	= &mv2111_type,
+		.probe		= mv3310_probe,
+		.suspend	= mv3310_suspend,
+		.resume		= mv3310_resume,
+		.config_init	= mv3310_config_init,
+		.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,
+		.remove		= mv3310_remove,
+		.set_loopback	= genphy_c45_loopback,
+	},
 };
 
 module_phy_driver(mv3310_drivers);
-- 
2.26.2

Re: [PATCH net-next v3 16/18] net: phy: marvell10g: differentiate 88E2110 vs 88E2111

[Andrew Lunn]

On Wed, Apr 07, 2021 at 12:11:05AM +0200, Marek Behún wrote:
> 88E2111 is a variant of 88E2110 which does not support 5 gigabit speeds.
> 
> Differentiate these variants via the match_phy_device() method, since
> they have the same PHY ID.
> 
> Signed-off-by: Marek Behún <kabel@kernel.org>

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

    Andrew

[PATCH net-next v3 17/18] net: phy: marvell10g: change module description

[Marek Behún]

This module supports not not only Alaska X, but also Alaska M.

Change module description appropriately.

Signed-off-by: Marek Behún <kabel@kernel.org>
---
 drivers/net/phy/marvell10g.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 6269b9041180..8c3ec67c83cc 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -1058,5 +1058,5 @@ static struct mdio_device_id __maybe_unused mv3310_tbl[] = {
 	{ },
 };
 MODULE_DEVICE_TABLE(mdio, mv3310_tbl);
-MODULE_DESCRIPTION("Marvell Alaska X 10Gigabit Ethernet PHY driver (MV88X3310)");
+MODULE_DESCRIPTION("Marvell Alaska X/M multi-gigabit Ethernet PHY driver");
 MODULE_LICENSE("GPL");
-- 
2.26.2

Re: [PATCH net-next v3 17/18] net: phy: marvell10g: change module description

[Andrew Lunn]

On Wed, Apr 07, 2021 at 12:11:06AM +0200, Marek Behún wrote:
> This module supports not not only Alaska X, but also Alaska M.
> 
> Change module description appropriately.
> 
> Signed-off-by: Marek Behún <kabel@kernel.org>

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

    Andrew

[PATCH net-next v3 18/18] MAINTAINERS: add myself as maintainer of marvell10g driver

[Marek Behún]

Add myself as maintainer of the marvell10g ethernet PHY driver, in
addition to Russell King.

Signed-off-by: Marek Behún <kabel@kernel.org>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 217c7470bfa9..3ea9539821b5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10695,6 +10695,7 @@ F:	include/linux/mv643xx.h
 
 MARVELL MV88X3310 PHY DRIVER
 M:	Russell King <linux@armlinux.org.uk>
+M:	Marek Behun <marek.behun@nic.cz>
 L:	netdev@vger.kernel.org
 S:	Maintained
 F:	drivers/net/phy/marvell10g.c
-- 
2.26.2