[PATCH net-next v4] net: phy: realtek: Add support for JLSemi JL2101 and JL2121 PHYs

[PATCH net-next v4] net: phy: realtek: Add support for JLSemi JL2101 and JL2121 PHYs

[Pufan Jin]

JLSemi (JingLue Semiconductor) JL2101 and JL2121 Gigabit Ethernet PHYs
are register-compatible second-source alternatives to the Realtek
RTL8211F. They share the same paged register layout (page select at
register 0x1f), RGMII TX/RX internal delay registers (page 0xd08
regs 11/15), specific status register (0x1a), and LED control registers
(page 0xd04 reg 0x10).

In the IEEE 802.3 PHY ID allocation, JL2101 (0x937c4032) and JL2121
(0x937c4030) share the same Model number 0x03 (bits [9:4] of register 3),
differing only in revision number bits [3:0] (0x2 vs 0x0). Both chips
share identical operational characteristics. Consolidate them under a
single PHY_ID_MATCH_MODEL(0x937c4030) entry covering all revisions of
this model.

Unlike RTL8211F where PHYSR (0x1a) can be read directly on page 0,
JL21xx requires reading PHYSR from page 0xa43 via phy_read_paged().
Reading 0x1a on page 0 yields 0x0000, which causes rtlgen_decode_physr()
to erroneously downshift to 10Mbps half duplex. Introduce
jlsemi_read_status() to read PHYSR from page 0xa43.

Extend the Realtek PHY driver to bind JLSemi JL21xx by its Model ID to
the RTL8211F-compatible driver operations, using the generic rtl821x
probe and suspend/resume routines to avoid touching unverified WoL
registers. Add the ID to the MDIO module device table.

Signed-off-by: Pufan Jin <cyan2254650260@gmail.com>
---
Changes in v4:
- Consolidate JL2101 and JL2121 into a single PHY_ID_MATCH_MODEL entry
  since both share Model 0x03 in IEEE 802.3 PHY ID allocation. (Andrew Lunn)
- Drop unverified WoL callbacks (.set_wol, .get_wol) and switch .probe to
  rtl821x_probe and .suspend/.resume to rtl821x_* to avoid touching unverified
  WoL registers (page 0xd8a). Tested on hardware: page 0xd8a/0xd8c read back
  as 0x0000 on JL2121. (Andrew Lunn)
- Retain hardware LED callbacks (.led_hw_*) after thorough validation on
  hardware (ALINX AX7Z020B): Mode B page 0xd04 reg 0x10 bitfields verified
  via single/dual LED blinking tests and netdev trigger hardware offload.

Changes in v3:
- Drop standalone driver drivers/net/phy/jlsemi.c and extend the Realtek
  PHY driver directly as suggested by Andrew Lunn.
- Add jlsemi_read_status() to read PHYSR (0x1a) from page 0xa43, avoiding
  erroneous downshift to 10Mbps half duplex (verified on physical ALINX AX7Z020B).

Changes in v2:
- Drop redundant phy_interface_is_rgmii() check in jlsemi_config_init() (Andrew Lunn)
- Check device_can_wakeup() and configure wakeup capability and wake IRQ in probe()
  when 'wakeup-source' is present (Andrew Lunn)
- Drop redundant .features = PHY_GBIT_FEATURES (Andrew Lunn)
- Use PHY_ID_MATCH_VENDOR() for generic driver and mdio table (Andrew Lunn)
 drivers/net/phy/realtek/realtek_main.c | 38 ++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
index 4927ee838..355135143 100644
--- a/drivers/net/phy/realtek/realtek_main.c
+++ b/drivers/net/phy/realtek/realtek_main.c
@@ -270,6 +270,9 @@
 #define RTL_8261CE_CG				0x001cc899
 #define RTL_8261D_VM				0x001cc89a
 
+#define JLSEMI_JL21XX_PHYID			0x937c4030
+#define JLSEMI_STATUS_PAGE			0xa43
+
 #define RTL8261C_CE_MODEL		0x00
 #define RTL8261D_MODEL			0x81
 #define RTL8261X_INT_AUTONEG_ERROR	BIT(0)
@@ -1755,6 +1758,23 @@ static int rtlgen_read_status(struct phy_device *phydev)
 	return 0;
 }
 
+static int jlsemi_read_status(struct phy_device *phydev)
+{
+	int ret, val;
+
+	ret = genphy_read_status(phydev);
+	if (ret < 0 || !phydev->link)
+		return ret;
+
+	val = phy_read_paged(phydev, JLSEMI_STATUS_PAGE, RTL_PHYSR);
+	if (val < 0)
+		return val;
+
+	rtlgen_decode_physr(phydev, val);
+
+	return 0;
+}
+
 static int rtlgen_read_vend2(struct phy_device *phydev, int regnum)
 {
 	return __mdiobus_c45_read(phydev->mdio.bus, 0, MDIO_MMD_VEND2, regnum);
@@ -3283,6 +3303,23 @@ static struct phy_driver realtek_drvs[] = {
 		.led_hw_control_get = rtl8211f_led_hw_control_get,
 		.led_hw_control_set = rtl8211f_led_hw_control_set,
 		.disable_autonomous_eee = rtl8211f_disable_autonomous_eee,
+	}, {
+		PHY_ID_MATCH_MODEL(JLSEMI_JL21XX_PHYID),
+		.name		= "JLSemi JL2101/JL2121 Gigabit Ethernet",
+		.probe		= rtl821x_probe,
+		.config_init	= &rtl8211f_config_init,
+		.read_status	= jlsemi_read_status,
+		.config_intr	= &rtl8211f_config_intr,
+		.handle_interrupt = rtl8211f_handle_interrupt,
+		.suspend	= rtl821x_suspend,
+		.resume		= rtl821x_resume,
+		.read_page	= rtl821x_read_page,
+		.write_page	= rtl821x_write_page,
+		.flags		= PHY_ALWAYS_CALL_SUSPEND,
+		.led_hw_is_supported = rtl8211x_led_hw_is_supported,
+		.led_hw_control_get = rtl8211f_led_hw_control_get,
+		.led_hw_control_set = rtl8211f_led_hw_control_set,
+		.disable_autonomous_eee = rtl8211f_disable_autonomous_eee,
 	}, {
 		.name		= "Generic FE-GE Realtek PHY",
 		.match_phy_device = rtlgen_match_phy_device,
@@ -3527,6 +3564,7 @@ module_phy_driver(realtek_drvs);
 
 static const struct mdio_device_id __maybe_unused realtek_tbl[] = {
 	{ PHY_ID_MATCH_VENDOR(0x001cc800) },
+	{ PHY_ID_MATCH_MODEL(JLSEMI_JL21XX_PHYID) },
 	{ }
 };
 
-- 
2.56.0

Re: [PATCH net-next v4] net: phy: realtek: Add support for JLSemi JL2101 and JL2121 PHYs

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 3 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 2

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The JLSemi entry in realtek_drvs[] uses two incompatible
  register-access models.
- [Low] REALTEK_PHY's Kconfig help (drivers/net/phy/realtek/Kconfig line
  6: 'Currently supports RTL821x/RTL822x and fast ethernet PHYs') was…
- [Low] The concern says realtek,rtl82xx.yaml forbids LEDs for JL21xx
  (allOf: leds: false unless compatible contains ethernet-phy-…

--

net: phy: realtek: Add support for JLSemi JL2101 and JL2121 PHYs

This adds a realtek_drvs[] entry that matches the JLSemi JL21xx model ID
(0x937c4030) and reuses the RTL8211F callbacks. It also adds
jlsemi_read_status(), which reads PHYSR from page 0xa43, and adds the ID
to the MDIO module device table.

> diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
> index 4927ee838de21..355135143fb98 100644
> --- a/drivers/net/phy/realtek/realtek_main.c
> +++ b/drivers/net/phy/realtek/realtek_main.c

[ ... ]

> @@ -1755,6 +1758,23 @@ static int rtlgen_read_status(struct phy_device *phydev)
>  	return 0;
>  }
>  
> +static int jlsemi_read_status(struct phy_device *phydev)
> +{
> +	int ret, val;
> +
> +	ret = genphy_read_status(phydev);
> +	if (ret < 0 || !phydev->link)
> +		return ret;
> +
> +	val = phy_read_paged(phydev, JLSEMI_STATUS_PAGE, RTL_PHYSR);

[Severity: Medium]
The commit message says that on JL21xx, reading 0x1a on page 0 returns
0x0000. That is why PHYSR is read here through page 0xa43, and it means
0x1a depends on the page select on this chip.

Commit 650e55f224a5 ("net: phy: realtek: simplify bogus paged operations")
changed every 0x18-0x1f access in this driver into a plain phy_read() or
phy_modify(). It did so because only 0x10-0x17 depend on the page select
register. The RTL8211F callbacks bound to the new entry still follow that
model for registers next to 0x1a.

rtl8211f_ack_interrupt() and rtl8211f_handle_interrupt() read INSR (0x1d)
unpaged:

    irq_status = phy_read(phydev, RTL8211F_INSR);

rtl8211f_disable_autonomous_eee() modifies PHYCR2 (0x19) unpaged:

    return phy_modify(phydev, RTL8211F_PHYCR2,
                      RTL8211F_PHYCR2_PHY_EEE_ENABLE, 0);

rtl8211f_config_aldps() modifies PHYCR1 (0x18) unpaged:

    return phy_modify(phydev, RTL8211F_PHYCR1, mask, mask);

rtl8211f_config_clk_out(), rtl8211f_config_clkout_ssc() and
rtl8211f_config_sysclk_ssc() also access PHYCR2 with phy_modify() or
phy_set_bits().

Suppose JL21xx pages 0x18, 0x19 and 0x1d the same way it pages 0x1a.
Would these accesses then hit the default page instead of the real
registers?

For interrupts, rtl8211f_config_intr() enables INER with a paged write,
which does reach the hardware:

    err = phy_write_paged(phydev, 0xa42, RTL821x_INER, val);

rtl8211f_handle_interrupt() then checks the unpaged 0x1d read:

    if (irq_status & RTL8211F_INER_LINK_STATUS) {
    ...
    if (irq_status & RTL8211F_INER_PME) {
    ...
    return IRQ_NONE;

Could this return IRQ_NONE without ever clearing the latched INSR? On a
level-triggered INTB line, that could cause an interrupt storm. The IRQ
would then get disabled and link changes would be lost.

For EEE, phylink_bringup_phy()->phy_support_eee() calls
disable_autonomous_eee whenever the MAC supports EEE. It sets
autonomous_eee_disabled as soon as the MDIO write succeeds. Could phylib
then believe autonomous EEE is off while the PHY still has it on? The
same write is repeated after each soft reset in phy_init_hw().

The ALDPS and CLKOUT-disable paths would also report success without
reaching PHYCR1 or PHYCR2. The clk_out path soft-resets the PHY as well.

Now suppose 0x18-0x1f are not paged on JL21xx. Then
phy_read_paged(phydev, 0xa43, RTL_PHYSR) is the same as an unpaged read.
In that case, how does jlsemi_read_status() avoid the 10/Half downshift
it was added to fix?

The changelog says PHYSR, the RGMII delays and the LEDs were tested on
hardware. v4 drops WoL as unverified but keeps the interrupt, EEE, ALDPS
and CLKOUT paths. Were those also checked on JL21xx?

> +	if (val < 0)
> +		return val;
> +
> +	rtlgen_decode_physr(phydev, val);
> +
> +	return 0;
> +}

[ ... ]

> @@ -3283,6 +3303,23 @@ static struct phy_driver realtek_drvs[] = {
>  		.led_hw_control_get = rtl8211f_led_hw_control_get,
>  		.led_hw_control_set = rtl8211f_led_hw_control_set,
>  		.disable_autonomous_eee = rtl8211f_disable_autonomous_eee,
>  	}, {
> +		PHY_ID_MATCH_MODEL(JLSEMI_JL21XX_PHYID),
> +		.name		= "JLSemi JL2101/JL2121 Gigabit Ethernet",
> +		.probe		= rtl821x_probe,

[Severity: Low]
This isn't a bug, but rtl821x_probe() now parses vendor DT properties for
this PHY, for example:

    priv->enable_aldps = of_property_read_bool(dev->of_node,
                                               "realtek,aldps-enable");

Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml has no select:
section, and its compatible enum only lists ethernet-phy-id001c.cXXX
entries. So a JL21xx node (no compatible, or ethernet-phy-id937c.4030) is
never validated against that schema. Its leds: false rule therefore does
not affect JL21xx either.

The realtek,* properties only do anything if a DT author sets them.
Should the binding say that they also apply to JL21xx?

[ ... ]

> @@ -3527,6 +3564,7 @@ module_phy_driver(realtek_drvs);
>  
>  static const struct mdio_device_id __maybe_unused realtek_tbl[] = {
>  	{ PHY_ID_MATCH_VENDOR(0x001cc800) },
> +	{ PHY_ID_MATCH_MODEL(JLSEMI_JL21XX_PHYID) },

[Severity: Low]
This isn't a bug, but the module now binds and autoloads a non-Realtek
OUI. The REALTEK_PHY help text in drivers/net/phy/realtek/Kconfig still
says:

    Currently supports RTL821x/RTL822x and fast ethernet PHYs

MODULE_DESCRIPTION() is also still "Realtek PHY driver". Could the help
text mention JLSemi JL2101/JL2121, so that people building for that
hardware know to enable CONFIG_REALTEK_PHY?

>  	{ }
>  };

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261105173350.159060-1-cyan2254650260%40gmail.com

[PATCH net-next v4] net: phy: realtek: Add support for JLSemi JL2101 and JL2121 PHYs

[Pufan Jin]

JLSemi (JingLue Semiconductor) JL2101 and JL2121 Gigabit Ethernet PHYs
are register-compatible second-source alternatives to the Realtek
RTL8211F. They share the same paged register layout (page select at
register 0x1f), RGMII TX/RX internal delay registers (page 0xd08
regs 11/15), and specific status register (0x1a). Wake-on-LAN (WoL)
events (page 0xd8a regs 16/17 and page 0xd8c reg 16) and LED control
registers (page 0xd04 reg 0x10) match RTL8211F.

In the IEEE 802.3 PHY ID allocation, JL2101 (0x937c4032) and JL2121
(0x937c4030) share the same Model number 0x03 (bits [9:4] of register 3),
differing only in revision number bits [3:0] (0x2 vs 0x0). Both chips
share identical operational characteristics. Consolidate them under a
single PHY_ID_MATCH_MODEL(0x937c4030) entry covering all revisions of
this model.

Unlike RTL8211F where PHYSR (0x1a) can be read directly on page 0,
JL21xx requires reading PHYSR from page 0xa43 via phy_read_paged().
Reading 0x1a on page 0 yields 0x0000, which causes rtlgen_decode_physr()
to erroneously downshift to 10Mbps half duplex. Introduce
jlsemi_read_status() to read PHYSR from page 0xa43.

Extend the Realtek PHY driver to bind JLSemi JL21xx by its Model ID to
the RTL8211F-compatible driver operations, and add the ID to the MDIO
module device table.

Signed-off-by: Pufan Jin <cyan2254650260@gmail.com>
---
Changes in v4:
- Consolidate JL2101 (0x937c4032) and JL2121 (0x937c4030) into a single
  PHY_ID_MATCH_MODEL(0x937c4030) entry as both share Model number 0x03
  and differ only in revision number (Andrew Lunn).

Changes in v3:
- Drop standalone driver drivers/net/phy/jlsemi.c and extend the Realtek
  PHY driver directly as suggested by Andrew Lunn.
- Add jlsemi_read_status() to read PHYSR (0x1a) via phy_read_paged()
  from page 0xa43, avoiding false downshift to 10Mbps half duplex (verified
  on physical ALINX AX7Z020B board).

Changes in v2:
- Drop redundant phy_interface_is_rgmii() check in jlsemi_config_init()
  (Andrew Lunn)
- Change speed check in jlsemi_read_status() to '>= SPEED_1000' since
  JL21xx only supports up to 1000M and 100BASE-TX does not use Master/Slave
  clock resolution (Andrew Lunn)
- Check device_can_wakeup() and configure wakeup capability and wake IRQ
  in probe() when 'wakeup-source' is present (Andrew Lunn)
- Drop redundant .features = PHY_GBIT_FEATURES (Andrew Lunn)
- Use PHY_ID_MATCH_VENDOR() for generic driver and mdio table (Andrew Lunn)
 drivers/net/phy/realtek/realtek_main.c | 40 ++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
index 177b62a7b..13039d9f8 100644
--- a/drivers/net/phy/realtek/realtek_main.c
+++ b/drivers/net/phy/realtek/realtek_main.c
@@ -259,6 +259,9 @@
 #define RTL_8261C				0x001cc890
 #define RTL_8261C_CG				0x001cc898
 
+#define JLSEMI_JL21XX_PHYID			0x937c4030
+#define JLSEMI_STATUS_PAGE			0xa43
+
 #define RTL8261C_CE_MODEL		0x00
 #define RTL8261D_MODEL			0x81
 #define RTL8261X_INT_AUTONEG_ERROR	BIT(0)
@@ -1731,6 +1734,23 @@ static int rtlgen_read_status(struct phy_device *phydev)
 	return 0;
 }
 
+static int jlsemi_read_status(struct phy_device *phydev)
+{
+	int ret, val;
+
+	ret = genphy_read_status(phydev);
+	if (ret < 0 || !phydev->link)
+		return ret;
+
+	val = phy_read_paged(phydev, JLSEMI_STATUS_PAGE, RTL_PHYSR);
+	if (val < 0)
+		return val;
+
+	rtlgen_decode_physr(phydev, val);
+
+	return 0;
+}
+
 static int rtlgen_read_vend2(struct phy_device *phydev, int regnum)
 {
 	return __mdiobus_c45_read(phydev->mdio.bus, 0, MDIO_MMD_VEND2, regnum);
@@ -3192,6 +3212,25 @@ static struct phy_driver realtek_drvs[] = {
 		.led_hw_control_get = rtl8211f_led_hw_control_get,
 		.led_hw_control_set = rtl8211f_led_hw_control_set,
 		.disable_autonomous_eee = rtl8211f_disable_autonomous_eee,
+	}, {
+		PHY_ID_MATCH_MODEL(JLSEMI_JL21XX_PHYID),
+		.name		= "JLSemi JL2101/JL2121 Gigabit Ethernet",
+		.probe		= rtl8211f_probe,
+		.config_init	= &rtl8211f_config_init,
+		.read_status	= jlsemi_read_status,
+		.config_intr	= &rtl8211f_config_intr,
+		.handle_interrupt = rtl8211f_handle_interrupt,
+		.set_wol	= rtl8211f_set_wol,
+		.get_wol	= rtl8211f_get_wol,
+		.suspend	= rtl8211f_suspend,
+		.resume		= rtl8211f_resume,
+		.read_page	= rtl821x_read_page,
+		.write_page	= rtl821x_write_page,
+		.flags		= PHY_ALWAYS_CALL_SUSPEND,
+		.led_hw_is_supported = rtl8211x_led_hw_is_supported,
+		.led_hw_control_get = rtl8211f_led_hw_control_get,
+		.led_hw_control_set = rtl8211f_led_hw_control_set,
+		.disable_autonomous_eee = rtl8211f_disable_autonomous_eee,
 	}, {
 		.name		= "Generic FE-GE Realtek PHY",
 		.match_phy_device = rtlgen_match_phy_device,
@@ -3420,6 +3459,7 @@ module_phy_driver(realtek_drvs);
 
 static const struct mdio_device_id __maybe_unused realtek_tbl[] = {
 	{ PHY_ID_MATCH_VENDOR(0x001cc800) },
+	{ PHY_ID_MATCH_MODEL(JLSEMI_JL21XX_PHYID) },
 	{ }
 };
 
-- 
2.56.0

Re: [PATCH net-next v4] net: phy: realtek: Add support for JLSemi JL2101 and JL2121 PHYs

[Andrew Lunn]

> +		PHY_ID_MATCH_MODEL(JLSEMI_JL21XX_PHYID),

Thanks for this change.

https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html

Since the merge window is open at the moment, patches will not be
accepted until it closes.

> +		.set_wol	= rtl8211f_set_wol,
> +		.get_wol	= rtl8211f_get_wol,

> +		.suspend	= rtl8211f_suspend,
> +		.resume		= rtl8211f_resume,

> +		.led_hw_is_supported = rtl8211x_led_hw_is_supported,
> +		.led_hw_control_get = rtl8211f_led_hw_control_get,
> +		.led_hw_control_set = rtl8211f_led_hw_control_set,

Have you tested these features? You have seen one register is
different. There might be others.

   Andrew

Re: [PATCH net-next v4] net: phy: realtek: Add support for JLSemi JL2101 and JL2121 PHYs

[Pufan Jin]

On 2026/10/22 01:30, Andrew Lunn wrote:

>> +		PHY_ID_MATCH_MODEL(JLSEMI_JL21XX_PHYID),
> Thanks for this change.
>
> https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
>
> Since the merge window is open at the moment, patches will not be
> accepted until it closes.
>
>> +		.set_wol	= rtl8211f_set_wol,
>> +		.get_wol	= rtl8211f_get_wol,
>> +		.suspend	= rtl8211f_suspend,
>> +		.resume		= rtl8211f_resume,
>> +		.led_hw_is_supported = rtl8211x_led_hw_is_supported,
>> +		.led_hw_control_get = rtl8211f_led_hw_control_get,
>> +		.led_hw_control_set = rtl8211f_led_hw_control_set,
> Have you tested these features? You have seen one register is
> different. There might be others.
>
>     Andrew

Hi Andrew,

Thanks for the clarification regarding the merge window. I will hold off
submitting v4 until net-next reopens once the merge window closes.

Regarding your question about testing:
 > Have you tested these features? You have seen one register is
 > different. There might be others.

1. WoL:
On my ALINX AX7Z020B board, the INT/PME pin is not wired to the SoC
as a system wakeup source, so I cannot test end-to-end Wake-on-LAN
from system suspend.
Furthermore, I probed the RTL8211F WoL registers (page 0xd8a and 0xd8c)
directly on the hardware: writes do not stick and all registers read back
as 0x0000. This confirms that the JL2121 does not share the RTL8211F WoL
register map.
Therefore, for v4 I have dropped .set_wol and .get_wol, and switched
.probe to rtl821x_probe and .suspend/.resume to rtl821x_*
(matching RTL8211F-VD) so the driver does not touch page 0xd8a.

2. Hardware LED control:
I have already tested the LED hardware control on the physical
AX7Z020B board. The RJ45 jack has green and yellow LEDs, and page 0xd04
reg 0x10 is indeed the active LED control register:
- Boot default is 0xe251 (Mode B with 1000M+Act on LED2, 100M+Act on
   LED1, 10M+Act on LED0).
- Declaring leds child nodes in the board DTS successfully registered the
   LEDs under /sys/class/leds/, and the netdev trigger confirmed
   hardware offload ('offloaded: 1').
- Setting register 0x8000 (clearing all LED rules in Mode B) turns off
   both green and yellow LEDs completely.
- Setting 0xa000 (LED2 link 1000 only) turns on the green LED while yellow
   remains off.
- Bitfield manipulation verified that the green and yellow LEDs can be
   independently toggled (e.g., single-LED blink and synchronous dual-LED
   blink cycles).

Therefore, the hardware LED registers and Mode B bitfields are identical
to the RTL8211F. I will retain the verified .led_hw_* callbacks in v4.

Thanks again for the review,
Pufan