[PATCH net-next v2 0/2] net: dsa: realtek: EEE support for RTL8365MB-VC

[PATCH net-next v2 0/2] net: dsa: realtek: EEE support for RTL8365MB-VC

[Oleksij Rempel]

On these switches EEE is enabled by default, but so far it is neither
visible nor controllable from user space. This series wires EEE up to
phylib/phylink on the RTL8365MB-VC integrated-PHY ports so it can be
observed and controlled per port via ethtool

Oleksij Rempel (2):
  net: phy: realtek: use C45 for RTL8365MB-VC internal PHY MMD access
  net: dsa: realtek: rtl8365mb: add EEE support

 drivers/net/dsa/realtek/realtek.h        |   4 +
 drivers/net/dsa/realtek/rtl8365mb_main.c | 123 +++++++++++++++++++++++
 drivers/net/dsa/realtek/rtl83xx.c        |  20 ++++
 drivers/net/phy/realtek/realtek_main.c   |   2 +
 4 files changed, 149 insertions(+)

--
2.47.3

[PATCH net-next v2 1/2] net: phy: realtek: use C45 for RTL8365MB-VC internal PHY MMD access

[Oleksij Rempel]

The RTL8365MB-VC PHYs are integrated into the switch and have no MMD
registers of their own. What phylib accesses as MMD registers (EEE)
actually lives in the switch's OCP registers; the realtek DSA driver maps
those MMD requests onto OCP and exposes them over C45.

For a C22 PHY, phy_read_mmd()/phy_write_mmd() would use C22 indirect-MMD,
which this hardware does not implement. Point .read_mmd/.write_mmd at
genphy_{read,write}_mmd_c45() so phylib's MMD accesses go over C45 to the
DSA driver's mapping instead.

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
Anticipated reviewer questions:

Q: .read_mmd/.write_mmd now use the C45 helpers, but the DSA user MDIO bus
   only gains .read_c45/.write_c45 in the next patch -- is this bisect-broken?
A: No. Until then an MMD access returns -EOPNOTSUPP, but the only one that runs
   is the EEE-ability read in phy_probe(), which phylib ignores; probe, link and
   traffic are unaffected. ethtool --show-eee reports EEE unsupported here -- the
   same as before this series, since these ports gain EEE only in the next patch
   -- so it is not a regression. Verified on an RTL8365MB-VC.
---
 drivers/net/phy/realtek/realtek_main.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
index 177b62a7b2d1..ad8017e91b4f 100644
--- a/drivers/net/phy/realtek/realtek_main.c
+++ b/drivers/net/phy/realtek/realtek_main.c
@@ -3388,6 +3388,8 @@ static struct phy_driver realtek_drvs[] = {
 	}, {
 		PHY_ID_MATCH_EXACT(0x001cc942),
 		.name		= "RTL8365MB-VC Gigabit Ethernet",
+		.read_mmd	= genphy_read_mmd_c45,
+		.write_mmd	= genphy_write_mmd_c45,
 		/* Interrupt handling analogous to RTL8366RB */
 		.config_intr	= genphy_no_config_intr,
 		.handle_interrupt = genphy_handle_interrupt_no_ack,
-- 
2.47.3

Re: [PATCH net-next v2 1/2] net: phy: realtek: use C45 for RTL8365MB-VC internal PHY MMD access

[Luiz Angelo Daros de Luca]

> The RTL8365MB-VC PHYs are integrated into the switch and have no MMD
> registers of their own. What phylib accesses as MMD registers (EEE)
> actually lives in the switch's OCP registers; the realtek DSA driver maps
> those MMD requests onto OCP and exposes them over C45.
>
> For a C22 PHY, phy_read_mmd()/phy_write_mmd() would use C22 indirect-MMD,
> which this hardware does not implement. Point .read_mmd/.write_mmd at
> genphy_{read,write}_mmd_c45() so phylib's MMD accesses go over C45 to the
> DSA driver's mapping instead.
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> ---
> Anticipated reviewer questions:
>
> Q: .read_mmd/.write_mmd now use the C45 helpers, but the DSA user MDIO bus
>    only gains .read_c45/.write_c45 in the next patch -- is this bisect-broken?
> A: No. Until then an MMD access returns -EOPNOTSUPP, but the only one that runs
>    is the EEE-ability read in phy_probe(), which phylib ignores; probe, link and
>    traffic are unaffected. ethtool --show-eee reports EEE unsupported here -- the
>    same as before this series, since these ports gain EEE only in the next patch
>    -- so it is not a regression. Verified on an RTL8365MB-VC.

I was going to do exactly that test but you saved me some time. Thanks.

Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>

Re: [PATCH net-next v2 1/2] net: phy: realtek: use C45 for RTL8365MB-VC internal PHY MMD access

[Linus Walleij]

On Thu, Sep 3, 2026 at 11:22 AM Oleksij Rempel <o.rempel@pengutronix.de> wrote:

> The RTL8365MB-VC PHYs are integrated into the switch and have no MMD
> registers of their own. What phylib accesses as MMD registers (EEE)
> actually lives in the switch's OCP registers; the realtek DSA driver maps
> those MMD requests onto OCP and exposes them over C45.
>
> For a C22 PHY, phy_read_mmd()/phy_write_mmd() would use C22 indirect-MMD,
> which this hardware does not implement. Point .read_mmd/.write_mmd at
> genphy_{read,write}_mmd_c45() so phylib's MMD accesses go over C45 to the
> DSA driver's mapping instead.
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>

Reviewed-by: Linus Walleij <linusw@kernel.org>

Yours,
Linus Walleij

[PATCH net-next v2 2/2] net: dsa: realtek: rtl8365mb: add EEE support

[Oleksij Rempel]

Add EEE support on the integrated-PHY ports, controllable per port via
ethtool.

The integrated PHYs have no MMD registers; their EEE registers live in the
switch's OCP space. phylib accesses EEE as MMD registers, so add
phy_{read,write}_c45 realtek_ops that map those MMD accesses onto their OCP
addresses, wired as the user MII bus C45 handlers when the chip provides
them (rtl8366rb etc. unaffected).

The hardware manages LPI on its own, so advertise EEE to phylink with
no-op mac_{en,dis}able_tx_lpi callbacks. The LPI timer is a single global
per-speed register, so .set_mac_eee rejects the per-port TX LPI knobs
rather than silently ignoring them.

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
Changes since v1:
- .set_mac_eee: return -EOPNOTSUPP instead of -EINVAL for the rejected
  TX LPI cases -- the hardware cannot support them, it is not an invalid
  configuration (Andrew Lunn).
---
 drivers/net/dsa/realtek/realtek.h        |   4 +
 drivers/net/dsa/realtek/rtl8365mb_main.c | 123 +++++++++++++++++++++++
 drivers/net/dsa/realtek/rtl83xx.c        |  20 ++++
 3 files changed, 147 insertions(+)

diff --git a/drivers/net/dsa/realtek/realtek.h b/drivers/net/dsa/realtek/realtek.h
index 75a127545e5d..1c0ca6daf545 100644
--- a/drivers/net/dsa/realtek/realtek.h
+++ b/drivers/net/dsa/realtek/realtek.h
@@ -156,6 +156,10 @@ struct realtek_ops {
 	int	(*phy_read)(struct realtek_priv *priv, int phy, int regnum);
 	int	(*phy_write)(struct realtek_priv *priv, int phy, int regnum,
 			     u16 val);
+	int	(*phy_read_c45)(struct realtek_priv *priv, int phy, int devad,
+				int regnum);
+	int	(*phy_write_c45)(struct realtek_priv *priv, int phy, int devad,
+				 int regnum, u16 val);
 };
 
 struct realtek_variant {
diff --git a/drivers/net/dsa/realtek/rtl8365mb_main.c b/drivers/net/dsa/realtek/rtl8365mb_main.c
index 4c305756116c..998f6b2ad140 100644
--- a/drivers/net/dsa/realtek/rtl8365mb_main.c
+++ b/drivers/net/dsa/realtek/rtl8365mb_main.c
@@ -101,6 +101,7 @@
 #include <linux/regmap.h>
 #include <linux/if_bridge.h>
 #include <linux/if_vlan.h>
+#include <linux/mdio.h>
 #include <linux/phylink.h>
 
 #include "realtek.h"
@@ -202,6 +203,10 @@
 /* The PHY OCP addresses of PHY registers 0~31 start here */
 #define RTL8365MB_PHY_OCP_ADDR_PHYREG_BASE		0xA400
 
+#define RTL8365MB_PHY_OCP_ADDR_EEE_ABLE			0xA5C4
+#define RTL8365MB_PHY_OCP_ADDR_EEE_ADV			0xA5D0
+#define RTL8365MB_PHY_OCP_ADDR_EEE_LPABLE		0xA5D2
+
 /* External interface port mode values - used in DIGITAL_INTERFACE_SELECT */
 #define RTL8365MB_EXT_PORT_MODE_DISABLE		0
 #define RTL8365MB_EXT_PORT_MODE_RGMII		1
@@ -1040,6 +1045,66 @@ static int rtl8365mb_phy_write(struct realtek_priv *priv, int phy, int regnum,
 	return 0;
 }
 
+static int rtl8365mb_phy_read_c45(struct realtek_priv *priv, int phy, int devad,
+				  int regnum)
+{
+	u32 ocp_addr;
+	u16 val;
+	int ret;
+
+	if (phy > RTL8365MB_PHYADDRMAX)
+		return -EINVAL;
+
+	if (devad == MDIO_MMD_PCS && regnum == MDIO_PCS_EEE_ABLE)
+		ocp_addr = RTL8365MB_PHY_OCP_ADDR_EEE_ABLE;
+	else if (devad == MDIO_MMD_AN && regnum == MDIO_AN_EEE_ADV)
+		ocp_addr = RTL8365MB_PHY_OCP_ADDR_EEE_ADV;
+	else if (devad == MDIO_MMD_AN && regnum == MDIO_AN_EEE_LPABLE)
+		ocp_addr = RTL8365MB_PHY_OCP_ADDR_EEE_LPABLE;
+	else
+		/* Only the EEE registers are mapped; others read as 0, as the
+		 * hardware does, so the generic MMD code is not tripped up by
+		 * an error.
+		 */
+		return 0;
+
+	ret = rtl8365mb_phy_ocp_read(priv, phy, ocp_addr, &val);
+	if (ret) {
+		dev_err(priv->dev,
+			"failed to read PHY%d OCP %04x, ret %d\n", phy, ocp_addr,
+			ret);
+		return ret;
+	}
+
+	return val;
+}
+
+static int rtl8365mb_phy_write_c45(struct realtek_priv *priv, int phy,
+				   int devad, int regnum, u16 val)
+{
+	int ret;
+
+	if (phy > RTL8365MB_PHYADDRMAX)
+		return -EINVAL;
+
+	/* Only the EEE advertisement register is writable; writes to other
+	 * registers are ignored, as the hardware does.
+	 */
+	if (devad != MDIO_MMD_AN || regnum != MDIO_AN_EEE_ADV)
+		return 0;
+
+	ret = rtl8365mb_phy_ocp_write(priv, phy, RTL8365MB_PHY_OCP_ADDR_EEE_ADV,
+				      val);
+	if (ret) {
+		dev_err(priv->dev,
+			"failed to write PHY%d OCP %04x, ret %d\n", phy,
+			RTL8365MB_PHY_OCP_ADDR_EEE_ADV, ret);
+		return ret;
+	}
+
+	return 0;
+}
+
 static const struct rtl8365mb_extint *
 rtl8365mb_get_port_extint(struct realtek_priv *priv, int port)
 {
@@ -1639,6 +1704,14 @@ static void rtl8365mb_phylink_get_caps(struct dsa_switch *ds, int port,
 		 */
 		__set_bit(PHY_INTERFACE_MODE_GMII,
 			  config->supported_interfaces);
+
+		/* Integrated PHYs support EEE at 100M/1G; the hardware manages
+		 * LPI on its own, so just advertise LPI awareness to phylink.
+		 */
+		memcpy(config->lpi_interfaces, config->supported_interfaces,
+		       sizeof(config->lpi_interfaces));
+		config->lpi_capabilities = MAC_100FD | MAC_1000FD;
+		config->eee_enabled_default = true;
 		return;
 	}
 
@@ -3275,18 +3348,66 @@ static int rtl8365mb_detect(struct realtek_priv *priv)
 	return 0;
 }
 
+static int rtl8365mb_phylink_mac_enable_tx_lpi(struct phylink_config *config,
+					       u32 timer, bool tx_clock_stop)
+{
+	/* The hardware manages LPI itself; there is no MAC-level LPI control.
+	 * This callback only signals LPI awareness to phylink.
+	 */
+	return 0;
+}
+
+static void rtl8365mb_phylink_mac_disable_tx_lpi(struct phylink_config *config)
+{
+}
+
 static const struct phylink_mac_ops rtl8365mb_phylink_mac_ops = {
 	.mac_select_pcs = rtl8365mb_phylink_mac_select_pcs,
 	.mac_config = rtl8365mb_phylink_mac_config,
 	.mac_link_down = rtl8365mb_phylink_mac_link_down,
 	.mac_link_up = rtl8365mb_phylink_mac_link_up,
+	.mac_enable_tx_lpi = rtl8365mb_phylink_mac_enable_tx_lpi,
+	.mac_disable_tx_lpi = rtl8365mb_phylink_mac_disable_tx_lpi,
 };
 
+static bool rtl8365mb_support_eee(struct dsa_switch *ds, int port)
+{
+	/* Only integrated-PHY ports support EEE, not the external RGMII ports. */
+	return !rtl8365mb_get_port_extint(ds->priv, port);
+}
+
+static int rtl8365mb_set_mac_eee(struct dsa_switch *ds, int port,
+				 struct ethtool_keee *e)
+{
+	struct realtek_priv *priv = ds->priv;
+
+	/* The only LPI timing control (tx_lpi_timer) is a single global
+	 * per-speed register shared by all ports, so it cannot be set from this
+	 * per-port callback; leave it at its reset default. Per-port EEE is
+	 * driven through the PHY advertisement. Reject the per-port TX LPI knobs
+	 * rather than silently ignoring them.
+	 */
+	if (!e->tx_lpi_enabled) {
+		dev_err(priv->dev, "disabling EEE TX LPI is not supported\n");
+		return -EOPNOTSUPP;
+	}
+
+	if (e->tx_lpi_timer) {
+		dev_err(priv->dev,
+			"setting the EEE TX LPI timer is not supported\n");
+		return -EOPNOTSUPP;
+	}
+
+	return 0;
+}
+
 static const struct dsa_switch_ops rtl8365mb_switch_ops = {
 	.get_tag_protocol = rtl8365mb_get_tag_protocol,
 	.change_tag_protocol = rtl8365mb_change_tag_protocol,
 	.setup = rtl8365mb_setup,
 	.teardown = rtl8365mb_teardown,
+	.support_eee = rtl8365mb_support_eee,
+	.set_mac_eee = rtl8365mb_set_mac_eee,
 	.phylink_get_caps = rtl8365mb_phylink_get_caps,
 	.port_bridge_join = rtl83xx_port_bridge_join,
 	.port_bridge_leave = rtl83xx_port_bridge_leave,
@@ -3332,6 +3453,8 @@ static const struct realtek_ops rtl8365mb_ops = {
 	.l2_flush = rtl8365mb_l2_flush,
 	.phy_read = rtl8365mb_phy_read,
 	.phy_write = rtl8365mb_phy_write,
+	.phy_read_c45 = rtl8365mb_phy_read_c45,
+	.phy_write_c45 = rtl8365mb_phy_write_c45,
 };
 
 static const char *const rtl8365mb_supplies[] = {
diff --git a/drivers/net/dsa/realtek/rtl83xx.c b/drivers/net/dsa/realtek/rtl83xx.c
index 8121ec12fd8b..ad42c05d0a88 100644
--- a/drivers/net/dsa/realtek/rtl83xx.c
+++ b/drivers/net/dsa/realtek/rtl83xx.c
@@ -62,6 +62,22 @@ static int rtl83xx_user_mdio_write(struct mii_bus *bus, int addr, int regnum,
 	return priv->ops->phy_write(priv, addr, regnum, val);
 }
 
+static int rtl83xx_user_mdio_read_c45(struct mii_bus *bus, int addr, int devad,
+				      int regnum)
+{
+	struct realtek_priv *priv = bus->priv;
+
+	return priv->ops->phy_read_c45(priv, addr, devad, regnum);
+}
+
+static int rtl83xx_user_mdio_write_c45(struct mii_bus *bus, int addr, int devad,
+				       int regnum, u16 val)
+{
+	struct realtek_priv *priv = bus->priv;
+
+	return priv->ops->phy_write_c45(priv, addr, devad, regnum, val);
+}
+
 /**
  * rtl83xx_setup_user_mdio() - register the user mii bus driver
  * @ds: DSA switch associated with this user_mii_bus
@@ -95,6 +111,10 @@ int rtl83xx_setup_user_mdio(struct dsa_switch *ds)
 	bus->name = "Realtek user MII";
 	bus->read = rtl83xx_user_mdio_read;
 	bus->write = rtl83xx_user_mdio_write;
+	if (priv->ops->phy_read_c45)
+		bus->read_c45 = rtl83xx_user_mdio_read_c45;
+	if (priv->ops->phy_write_c45)
+		bus->write_c45 = rtl83xx_user_mdio_write_c45;
 	snprintf(bus->id, MII_BUS_ID_SIZE, "%s:user_mii", dev_name(priv->dev));
 	bus->parent = priv->dev;
 
-- 
2.47.3

Re: [PATCH net-next v2 2/2] net: dsa: realtek: rtl8365mb: add EEE support

[Andrew Lunn]

On Thu, Sep 03, 2026 at 11:22:11AM +0200, Oleksij Rempel wrote:
> Add EEE support on the integrated-PHY ports, controllable per port via
> ethtool.
> 
> The integrated PHYs have no MMD registers; their EEE registers live in the
> switch's OCP space. phylib accesses EEE as MMD registers, so add
> phy_{read,write}_c45 realtek_ops that map those MMD accesses onto their OCP
> addresses, wired as the user MII bus C45 handlers when the chip provides
> them (rtl8366rb etc. unaffected).
> 
> The hardware manages LPI on its own, so advertise EEE to phylink with
> no-op mac_{en,dis}able_tx_lpi callbacks. The LPI timer is a single global
> per-speed register, so .set_mac_eee rejects the per-port TX LPI knobs
> rather than silently ignoring them.
> 
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>

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

    Andrew

Re: [PATCH net-next v2 2/2] net: dsa: realtek: rtl8365mb: add EEE support

[Luiz Angelo Daros de Luca]

---
     Luiz Angelo Daros de Luca
            luizluca@gmail.com

Em qui., 3 de set. de 2026 às 09:24, Andrew Lunn <andrew@lunn.ch> escreveu:
>
> On Thu, Sep 03, 2026 at 11:22:11AM +0200, Oleksij Rempel wrote:
> > Add EEE support on the integrated-PHY ports, controllable per port via
> > ethtool.
> >
> > The integrated PHYs have no MMD registers; their EEE registers live in the
> > switch's OCP space. phylib accesses EEE as MMD registers, so add
> > phy_{read,write}_c45 realtek_ops that map those MMD accesses onto their OCP
> > addresses, wired as the user MII bus C45 handlers when the chip provides
> > them (rtl8366rb etc. unaffected).
> >
> > The hardware manages LPI on its own, so advertise EEE to phylink with
> > no-op mac_{en,dis}able_tx_lpi callbacks. The LPI timer is a single global
> > per-speed register, so .set_mac_eee rejects the per-port TX LPI knobs
> > rather than silently ignoring them.
> >
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>

It looks great. Thanks.

Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>

Re: [PATCH net-next v2 2/2] net: dsa: realtek: rtl8365mb: add EEE support

[Linus Walleij]

On Thu, Sep 3, 2026 at 11:22 AM Oleksij Rempel <o.rempel@pengutronix.de> wrote:

> Add EEE support on the integrated-PHY ports, controllable per port via
> ethtool.
>
> The integrated PHYs have no MMD registers; their EEE registers live in the
> switch's OCP space. phylib accesses EEE as MMD registers, so add
> phy_{read,write}_c45 realtek_ops that map those MMD accesses onto their OCP
> addresses, wired as the user MII bus C45 handlers when the chip provides
> them (rtl8366rb etc. unaffected).
>
> The hardware manages LPI on its own, so advertise EEE to phylink with
> no-op mac_{en,dis}able_tx_lpi callbacks. The LPI timer is a single global
> per-speed register, so .set_mac_eee rejects the per-port TX LPI knobs
> rather than silently ignoring them.
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>

Excellent work on this Oleksij!
Reviewed-by: Linus Walleij <linusw@kernel.org>

Yours,
Linus Walleij

Re: [PATCH net-next v2 2/2] net: dsa: realtek: rtl8365mb: add EEE support

[Jakub Kicinski]

On Thu,  3 Sep 2026 11:22:11 +0200 Oleksij Rempel wrote:
> Add EEE support on the integrated-PHY ports, controllable per port via
> ethtool.

Looks like clang is doing more aggressive inlining here because build
fails with:

../drivers/net/dsa/realtek/rtl8365mb_main.c:894:9: error: call to '__compiletime_assert_1481' declared with 'error' attribute: FIELD_PREP: value too large for the field
  894 |         val |= FIELD_PREP(RTL8365MB_INDIRECT_ACCESS_ADDRESS_OCPADR_5_1_MASK,
      |                ^
../include/linux/bitfield.h:138:3: note: expanded from macro 'FIELD_PREP'
  138 |                 __FIELD_PREP(_mask, _val, "FIELD_PREP: ");              \
      |                 ^
../include/linux/bitfield.h:91:3: note: expanded from macro '__FIELD_PREP'
   91 |                 __BF_FIELD_CHECK_MASK(mask, val, pfx);                  \
      |                 ^
../include/linux/bitfield.h:70:3: note: expanded from macro '__BF_FIELD_CHECK_MASK'
   70 |                 BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?           \
      |                 ^
note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
./../include/linux/compiler_types.h:690:2: note: expanded from macro '_compiletime_assert'
  690 |         __compiletime_assert(condition, msg, prefix, suffix)
      |         ^
./../include/linux/compiler_types.h:683:4: note: expanded from macro '__compiletime_assert'
  683 |                         prefix ## suffix();                             \
      |                         ^
<scratch space>:18:1: note: expanded from here
   18 | __compiletime_assert_1481
      | ^

Looks legit at a glance. Maybe the addrs you're defining should be
relative to RTL8365MB_PHY_OCP_ADDR_PHYREG_BASE ?