[PATCH net-next v9 0/4] net: phy: realtek: pair order and polarity

[PATCH net-next v9 0/4] net: phy: realtek: pair order and polarity

[Damien Dejean]

The RTL8224 PHY gives the manufacturer some flexbility with the pair
order and polarity to ease the wiring on the PCB. Then the correct pair
order and pair polarity must be provided to the PHY to function
properly. This series adds the support to configure the pair order and
the pair polarity to the Realtek PHY driver.

Signed-off-by: Damien Dejean <dam.dejean@gmail.com>
---
Changes in v9:
 - drivers/net/phy/realtek/realtek_main.c: support CONFIG_OF=n correctly when
   calling of_property_read_u32 in patches 2/4 and 4/4.
Changes in v8:
 - drivers/net/phy/realtek/realtek_main.c: introduce the common helper
   in patch 2/4 instead of 4/4.
Changes in v7:
 - drivers/net/phy/realtek/realtek_main.c: factor out a common helper
   for package bit modifications.

Damien Dejean (4):
  dt-bindings: net: ethernet-phy: add property enet-phy-pair-order
  net: phy: realtek: add RTL8224 pair order support
  dt-bindings: net: ethernet-phy: add property enet-phy-pair-polarity
  net: phy: realtek: add RTL8224 polarity support

 .../devicetree/bindings/net/ethernet-phy.yaml | 14 +++
 drivers/net/phy/realtek/Kconfig               |  1 +
 drivers/net/phy/realtek/realtek_main.c        | 96 +++++++++++++++++++
 3 files changed, 111 insertions(+)

-- 
2.47.3

[PATCH net-next v9 1/4] dt-bindings: net: ethernet-phy: add property enet-phy-pair-order

[Damien Dejean]

Add property enet-phy-pair-order to the device tree bindings to define
the pair order of the PHY. To simplify PCB design some manufacturers
allow to wire the pairs in a reverse order, and change the order in
software.

The property can be set to 0 to force the normal pair order (ABCD), or 1
to force the reverse pair order (DCBA).

Signed-off-by: Damien Dejean <dam.dejean@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
 Documentation/devicetree/bindings/net/ethernet-phy.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
index 58634fee9fc4..4a27547f7d7a 100644
--- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
@@ -126,6 +126,12 @@ properties:
       e.g. wrong bootstrap configuration caused by issues in PCB
       layout design.
 
+  enet-phy-pair-order:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    enum: [0, 1]
+    description:
+      For normal (0) or reverse (1) order of the pairs (ABCD -> DCBA).
+
   eee-broken-100tx:
     $ref: /schemas/types.yaml#/definitions/flag
     description:
-- 
2.47.3

[PATCH net-next v9 2/4] net: phy: realtek: add RTL8224 pair order support

[Damien Dejean]

The RTL8224 has a register to configure a pair swap (from ABCD order to
DCBA) providing PCB designers more flexbility when wiring the chip. The
swap parameter has to be set correctly for each of the 4 ports before
the chip can detect a link.

After a reset, this register is (unfortunately) left in a random state,
thus it has to be initialized. On most of the devices the bootloader
does it once for all and we can rely on the value set, on some other it
is not and the kernel has to do it.

The MDI pair swap can be set in the device tree using the property
enet-phy-pair-order. The property is set to 0 to keep the default order
(ABCD), or 1 to reverse the pairs (DCBA).

Signed-off-by: Damien Dejean <dam.dejean@gmail.com>
---
 drivers/net/phy/realtek/Kconfig        |  1 +
 drivers/net/phy/realtek/realtek_main.c | 64 ++++++++++++++++++++++++++
 2 files changed, 65 insertions(+)

diff --git a/drivers/net/phy/realtek/Kconfig b/drivers/net/phy/realtek/Kconfig
index b05c2a1e9024..a741b34d193e 100644
--- a/drivers/net/phy/realtek/Kconfig
+++ b/drivers/net/phy/realtek/Kconfig
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config REALTEK_PHY
 	tristate "Realtek PHYs"
+	select PHY_PACKAGE
 	help
 	  Currently supports RTL821x/RTL822x and fast ethernet PHYs
 
diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
index 530b4e26d16e..63134e300c33 100644
--- a/drivers/net/phy/realtek/realtek_main.c
+++ b/drivers/net/phy/realtek/realtek_main.c
@@ -171,6 +171,8 @@
 
 #define RTL8224_SRAM_RTCT_LEN(pair)		(0x8028 + (pair) * 4)
 
+#define RTL8224_VND1_MDI_PAIR_SWAP		0xa90
+
 #define RTL8366RB_POWER_SAVE			0x15
 #define RTL8366RB_POWER_SAVE_ON			BIT(12)
 
@@ -1820,6 +1822,66 @@ static int rtl8224_cable_test_get_status(struct phy_device *phydev, bool *finish
 	return rtl8224_cable_test_report(phydev, finished);
 }
 
+static int rtl8224_package_modify_mmd(struct phy_device *phydev, int devad,
+				      u32 regnum, u16 mask, u16 set)
+{
+	int val, ret;
+
+	phy_lock_mdio_bus(phydev);
+
+	val = __phy_package_read_mmd(phydev, 0, devad, regnum);
+	if (val < 0) {
+		ret = val;
+		goto exit;
+	}
+
+	val &= ~mask;
+	val |= set;
+
+	ret = __phy_package_write_mmd(phydev, 0, devad, regnum, val);
+
+exit:
+	phy_unlock_mdio_bus(phydev);
+	return ret;
+}
+
+static int rtl8224_mdi_config_order(struct phy_device *phydev)
+{
+	struct device_node *np = phydev->mdio.dev.of_node;
+	u8 port_offset = phydev->mdio.addr & 3;
+	u32 order = 0;
+	int ret;
+
+	ret = of_property_read_u32(np, "enet-phy-pair-order", &order);
+
+	/* Do nothing in case the property is not present */
+	if (ret == -EINVAL || ret == -ENOSYS)
+		return 0;
+
+	if (ret)
+		return ret;
+
+	if (order & ~1)
+		return -EINVAL;
+
+	return rtl8224_package_modify_mmd(phydev, MDIO_MMD_VEND1,
+					  RTL8224_VND1_MDI_PAIR_SWAP,
+					  BIT(port_offset),
+					  order ? BIT(port_offset) : 0);
+}
+
+static int rtl8224_config_init(struct phy_device *phydev)
+{
+	return rtl8224_mdi_config_order(phydev);
+}
+
+static int rtl8224_probe(struct phy_device *phydev)
+{
+	/* Chip exposes 4 ports, join all of them in the same package */
+	return devm_phy_package_join(&phydev->mdio.dev, phydev,
+				     phydev->mdio.addr & ~3, 0);
+}
+
 static bool rtlgen_supports_2_5gbps(struct phy_device *phydev)
 {
 	int val;
@@ -2395,6 +2457,8 @@ static struct phy_driver realtek_drvs[] = {
 		PHY_ID_MATCH_EXACT(0x001ccad0),
 		.name		= "RTL8224 2.5Gbps PHY",
 		.flags		= PHY_POLL_CABLE_TEST,
+		.probe		= rtl8224_probe,
+		.config_init	= rtl8224_config_init,
 		.get_features	= rtl822x_c45_get_features,
 		.config_aneg	= rtl822x_c45_config_aneg,
 		.read_status	= rtl822x_c45_read_status,
-- 
2.47.3

[PATCH net-next v9 3/4] dt-bindings: net: ethernet-phy: add property enet-phy-pair-polarity

[Damien Dejean]

Add the property enet-phy-pair-polarity to describe the polarity of the
PHY pairs. To ease PCB designs some manufacturers allow to wire the
pairs with a reverse polarity and provide a way to configure it.

The property 'enet-phy-pair-polarity' sets the polarity of each pair.
Bit 0 to 3 configure the polarity or pairs A to D, if set to 1 the
polarity is reversed for this pair.

Signed-off-by: Damien Dejean <dam.dejean@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
 Documentation/devicetree/bindings/net/ethernet-phy.yaml | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
index 4a27547f7d7a..21a1a63506f0 100644
--- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
@@ -132,6 +132,14 @@ properties:
     description:
       For normal (0) or reverse (1) order of the pairs (ABCD -> DCBA).
 
+  enet-phy-pair-polarity:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maximum: 0xf
+    description:
+      A bitmap to describe pair polarity swap. Bit 0 to swap polarity of pair A,
+      bit 1 to swap polarity of pair B, bit 2 to swap polarity of pair C and bit
+      3 to swap polarity of pair D.
+
   eee-broken-100tx:
     $ref: /schemas/types.yaml#/definitions/flag
     description:
-- 
2.47.3

[PATCH net-next v9 4/4] net: phy: realtek: add RTL8224 polarity support

[Damien Dejean]

The RTL8224 has a register to configure the polarity of every pair of
each port. It provides device designers more flexbility when wiring the
chip.

Unfortunately, the register is left in an unknown state after a reset.
Thus on devices where the bootloader don't initialize it, the driver has
to do it to detect and use a link.

The MDI polarity swap can be set in the device tree using the property
enet-phy-pair-polarity. The u32 value is a bitfield where bit[0..3]
control the polarity of pairs A..D.

Signed-off-by: Damien Dejean <dam.dejean@gmail.com>
---
 drivers/net/phy/realtek/realtek_main.c | 34 +++++++++++++++++++++++++-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
index 63134e300c33..023e47ad605b 100644
--- a/drivers/net/phy/realtek/realtek_main.c
+++ b/drivers/net/phy/realtek/realtek_main.c
@@ -172,6 +172,7 @@
 #define RTL8224_SRAM_RTCT_LEN(pair)		(0x8028 + (pair) * 4)
 
 #define RTL8224_VND1_MDI_PAIR_SWAP		0xa90
+#define RTL8224_VND1_MDI_POLARITY_SWAP		0xa94
 
 #define RTL8366RB_POWER_SAVE			0x15
 #define RTL8366RB_POWER_SAVE_ON			BIT(12)
@@ -1870,9 +1871,40 @@ static int rtl8224_mdi_config_order(struct phy_device *phydev)
 					  order ? BIT(port_offset) : 0);
 }
 
+static int rtl8224_mdi_config_polarity(struct phy_device *phydev)
+{
+	struct device_node *np = phydev->mdio.dev.of_node;
+	u8 offset = (phydev->mdio.addr & 3) * 4;
+	u32 polarity = 0;
+	int ret;
+
+	ret = of_property_read_u32(np, "enet-phy-pair-polarity", &polarity);
+
+	/* Do nothing if the property is not present */
+	if (ret == -EINVAL || ret == -ENOSYS)
+		return 0;
+
+	if (ret)
+		return ret;
+
+	if (polarity & ~0xf)
+		return -EINVAL;
+
+	return rtl8224_package_modify_mmd(phydev, MDIO_MMD_VEND1,
+					  RTL8224_VND1_MDI_POLARITY_SWAP,
+					  0xf << offset,
+					  polarity << offset);
+}
+
 static int rtl8224_config_init(struct phy_device *phydev)
 {
-	return rtl8224_mdi_config_order(phydev);
+	int ret;
+
+	ret = rtl8224_mdi_config_order(phydev);
+	if (ret)
+		return ret;
+
+	return rtl8224_mdi_config_polarity(phydev);
 }
 
 static int rtl8224_probe(struct phy_device *phydev)
-- 
2.47.3

Re: [PATCH net-next v9 2/4] net: phy: realtek: add RTL8224 pair order support

[Simon Horman]

On Wed, Mar 18, 2026 at 10:54:59PM +0100, Damien Dejean wrote:

...

> diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c

...

> +static int rtl8224_mdi_config_order(struct phy_device *phydev)
> +{
> +	struct device_node *np = phydev->mdio.dev.of_node;
> +	u8 port_offset = phydev->mdio.addr & 3;
> +	u32 order = 0;
> +	int ret;
> +
> +	ret = of_property_read_u32(np, "enet-phy-pair-order", &order);
> +
> +	/* Do nothing in case the property is not present */
> +	if (ret == -EINVAL || ret == -ENOSYS)
> +		return 0;

Checkpatch warns that ENOSYS only means 'invalid syscall nr'.

Looking over the implementation of of_property_read_u32() it seems to me
that -EINVAL is sufficient to detect that a property is not present. Which
may be appropriate here.

Likewise in patch 4/4.

Using a quick grep of the tree, I do notice the same pattern as above is
also present (only?) in aquantia_main.c.  So depending on the outcome of this
discussion it might be appropriate to update that too.

> +
> +	if (ret)
> +		return ret;
> +
> +	if (order & ~1)
> +		return -EINVAL;
> +
> +	return rtl8224_package_modify_mmd(phydev, MDIO_MMD_VEND1,
> +					  RTL8224_VND1_MDI_PAIR_SWAP,
> +					  BIT(port_offset),
> +					  order ? BIT(port_offset) : 0);
> +}
> +
> +static int rtl8224_config_init(struct phy_device *phydev)
> +{
> +	return rtl8224_mdi_config_order(phydev);
> +}

...

> @@ -2395,6 +2457,8 @@ static struct phy_driver realtek_drvs[] = {
>  		PHY_ID_MATCH_EXACT(0x001ccad0),
>  		.name		= "RTL8224 2.5Gbps PHY",
>  		.flags		= PHY_POLL_CABLE_TEST,
> +		.probe		= rtl8224_probe,
> +		.config_init	= rtl8224_config_init,
>  		.get_features	= rtl822x_c45_get_features,
>  		.config_aneg	= rtl822x_c45_config_aneg,
>  		.read_status	= rtl822x_c45_read_status,
> -- 
> 2.47.3
> 

Re: [PATCH net-next v9 2/4] net: phy: realtek: add RTL8224 pair order support

[Damien Dejean]

> Le 20 mars 2026 à 09:21, Simon Horman <horms@kernel.org> a écrit :
> 
> Checkpatch warns that ENOSYS only means 'invalid syscall nr'.
> 
> Looking over the implementation of of_property_read_u32() it seems to me
> that -EINVAL is sufficient to detect that a property is not present. Which
> may be appropriate here.

I added the check on -ENOSYS because in v8 Jakub commented [1] on the fact
that if the kernel is built with CONFIG_OF=n, of_property_read_u32() will
return ENOSYS. If ENOSYS is not handled there, then the call will return an
error while it shouldn’t.

Damien

[1] https://lkml.org/lkml/2026/3/17/2464

> 
> Likewise in patch 4/4.
> 
> Using a quick grep of the tree, I do notice the same pattern as above is
> also present (only?) in aquantia_main.c.  So depending on the outcome of this
> discussion it might be appropriate to update that too.
> 
>> +
>> + if (ret)
>> + return ret;
>> +
>> + if (order & ~1)
>> + return -EINVAL;
>> +
>> + return rtl8224_package_modify_mmd(phydev, MDIO_MMD_VEND1,
>> +  RTL8224_VND1_MDI_PAIR_SWAP,
>> +  BIT(port_offset),
>> +  order ? BIT(port_offset) : 0);
>> +}
>> +
>> +static int rtl8224_config_init(struct phy_device *phydev)
>> +{
>> + return rtl8224_mdi_config_order(phydev);
>> +}
> 
> ...
> 
>> @@ -2395,6 +2457,8 @@ static struct phy_driver realtek_drvs[] = {
>> PHY_ID_MATCH_EXACT(0x001ccad0),
>> .name = "RTL8224 2.5Gbps PHY",
>> .flags = PHY_POLL_CABLE_TEST,
>> + .probe = rtl8224_probe,
>> + .config_init = rtl8224_config_init,
>> .get_features = rtl822x_c45_get_features,
>> .config_aneg = rtl822x_c45_config_aneg,
>> .read_status = rtl822x_c45_read_status,
>> -- 
>> 2.47.3
>> 

Re: [PATCH net-next v9 0/4] net: phy: realtek: pair order and polarity

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Wed, 18 Mar 2026 22:54:57 +0100 you wrote:
> The RTL8224 PHY gives the manufacturer some flexbility with the pair
> order and polarity to ease the wiring on the PCB. Then the correct pair
> order and pair polarity must be provided to the PHY to function
> properly. This series adds the support to configure the pair order and
> the pair polarity to the Realtek PHY driver.
> 
> Signed-off-by: Damien Dejean <dam.dejean@gmail.com>
> 
> [...]

Here is the summary with links:
  - [net-next,v9,1/4] dt-bindings: net: ethernet-phy: add property enet-phy-pair-order
    https://git.kernel.org/netdev/net-next/c/c1887257a81b
  - [net-next,v9,2/4] net: phy: realtek: add RTL8224 pair order support
    https://git.kernel.org/netdev/net-next/c/330296ea9e15
  - [net-next,v9,3/4] dt-bindings: net: ethernet-phy: add property enet-phy-pair-polarity
    https://git.kernel.org/netdev/net-next/c/58ffb5910f32
  - [net-next,v9,4/4] net: phy: realtek: add RTL8224 polarity support
    https://git.kernel.org/netdev/net-next/c/beed9c0e9b53

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH net-next v9 2/4] net: phy: realtek: add RTL8224 pair order support

[Simon Horman]

On Fri, Mar 20, 2026 at 07:17:56PM +0100, Damien Dejean wrote:
> 
> > Le 20 mars 2026 à 09:21, Simon Horman <horms@kernel.org> a écrit :
> > 
> > Checkpatch warns that ENOSYS only means 'invalid syscall nr'.
> > 
> > Looking over the implementation of of_property_read_u32() it seems to me
> > that -EINVAL is sufficient to detect that a property is not present. Which
> > may be appropriate here.
> 
> I added the check on -ENOSYS because in v8 Jakub commented [1] on the fact
> that if the kernel is built with CONFIG_OF=n, of_property_read_u32() will
> return ENOSYS. If ENOSYS is not handled there, then the call will return an
> error while it shouldn’t.

Ahh, I see. I missed that in my analysis.
Sorry about that.

> 
> Damien
> 
> [1] https://lkml.org/lkml/2026/3/17/2464

...