linux.git/drivers/net/phy/realtek, branch v6.18 Linux kernel source tree net: phy: realtek: fix rtl8221b-vm-cg name 2025-10-17T23:34:37+00:00 Aleksander Jan Bajkowski olek2@wp.pl 2025-10-16T19:22:52+00:00 ffff5c8fc2af2218a3332b3d5b97654599d50cde When splitting the RTL8221B-VM-CG into C22 and C45 variants, the name was accidentally changed to RTL8221B-VN-CG. This patch brings back the previous part number. Fixes: ad5ce743a6b0 ("net: phy: realtek: Add driver instances for rtl8221b via Clause 45") Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20251016192325.2306757-1-olek2@wp.pl Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
When splitting the RTL8221B-VM-CG into C22 and C45 variants, the name was
accidentally changed to RTL8221B-VN-CG. This patch brings back the previous
part number.

Fixes: ad5ce743a6b0 ("net: phy: realtek: Add driver instances for rtl8221b via Clause 45")
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20251016192325.2306757-1-olek2@wp.pl
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: phy: realtek: Avoid PHYCR2 access if PHYCR2 not present 2025-10-14T00:46:01+00:00 Marek Vasut marek.vasut@mailbox.org 2025-10-11T11:02:49+00:00 2c67301584f2671e320236df6bbe75ae09feb4d0 The driver is currently checking for PHYCR2 register presence in rtl8211f_config_init(), but it does so after accessing PHYCR2 to disable EEE. This was introduced in commit bfc17c165835 ("net: phy: realtek: disable PHY-mode EEE"). Move the PHYCR2 presence test before the EEE disablement and simplify the code. Fixes: bfc17c165835 ("net: phy: realtek: disable PHY-mode EEE") Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/20251011110309.12664-1-marek.vasut@mailbox.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
The driver is currently checking for PHYCR2 register presence in
rtl8211f_config_init(), but it does so after accessing PHYCR2 to
disable EEE. This was introduced in commit bfc17c165835 ("net:
phy: realtek: disable PHY-mode EEE"). Move the PHYCR2 presence
test before the EEE disablement and simplify the code.

Fixes: bfc17c165835 ("net: phy: realtek: disable PHY-mode EEE")
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/20251011110309.12664-1-marek.vasut@mailbox.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: phy: realtek: support for TRIGGER_NETDEV_LINK on RTL8211E and RTL8211F 2025-08-28T00:13:32+00:00 Aleksander Jan Bajkowski olek2@wp.pl 2025-08-25T21:09:49+00:00 f63f21e82ecafd288b100ea161247820bf1e92c4 This patch adds support for the TRIGGER_NETDEV_LINK trigger. It activates the LED when a link is established, regardless of the speed. Tested on Orange Pi PC2 with RTL8211E PHY. Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250825211059.143231-1-olek2@wp.pl Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
This patch adds support for the TRIGGER_NETDEV_LINK trigger. It activates
the LED when a link is established, regardless of the speed.

Tested on Orange Pi PC2 with RTL8211E PHY.

Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20250825211059.143231-1-olek2@wp.pl
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: phy: realtek: enable serdes option mode for RTL8226-CG 2025-08-20T01:09:52+00:00 Markus Stockhausen markus.stockhausen@gmx.de 2025-08-15T08:20:09+00:00 3a752e67800106a5c42d802d67e06c60aa71d07b The RTL8226-CG can make use of the serdes option mode feature to dynamically switch between SGMII and 2500base-X. From what is known the setup sequence is much simpler with no magic values. Convert the exiting config_init() into a helper that configures the PHY depending on generation 1 or 2. Call the helper from two separated new config_init() functions. Finally convert the phy_driver specs of the RTL8226-CG to make use of the new configuration and switch over to the extended read_status() function to dynamically change the interface according to the serdes mode. Remark! The logic could be simpler if the serdes mode could be set before all other generation 2 magic values. Due to missing RTL8221B test hardware the mmd command order was kept. Tested on Zyxel XGS1210-12. Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20250815082009.3678865-1-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
The RTL8226-CG can make use of the serdes option mode feature to
dynamically switch between SGMII and 2500base-X. From what is
known the setup sequence is much simpler with no magic values.

Convert the exiting config_init() into a helper that configures
the PHY depending on generation 1 or 2. Call the helper from two
separated new config_init() functions.

Finally convert the phy_driver specs of the RTL8226-CG to make
use of the new configuration and switch over to the extended
read_status() function to dynamically change the interface
according to the serdes mode.

Remark! The logic could be simpler if the serdes mode could be
set before all other generation 2 magic values. Due to missing
RTL8221B test hardware the mmd command order was kept.

Tested on Zyxel XGS1210-12.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://patch.msgid.link/20250815082009.3678865-1-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: phy: realtek: fix RTL8211F wake-on-lan support 2025-08-19T00:13:24+00:00 Russell King (Oracle) rmk+kernel@armlinux.org.uk 2025-08-13T10:04:45+00:00 b826bf795564ddef6402cf2cb522ae035bd117ae Implement Wake-on-Lan for RTL8211F correctly. The existing implementation has multiple issues: 1. It assumes that Wake-on-Lan can always be used, whether or not the interrupt is wired, and whether or not the interrupt is capable of waking the system. This breaks the ability for MAC drivers to detect whether the PHY WoL is functional. 2. switching the interrupt pin in the .set_wol() method to PMEB mode immediately silences link-state interrupts, which breaks phylib when interrupts are being used rather than polling mode. 3. the code claiming to "reset WOL status" was doing nothing of the sort. Bit 15 in page 0xd8a register 17 controls WoL reset, and needs to be pulsed low to reset the WoL state. This bit was always written as '1', resulting in no reset. 4. not resetting WoL state results in the PMEB pin remaining asserted, which in turn leads to an interrupt storm. Only resetting the WoL state in .set_wol() is not sufficient. 5. PMEB mode does not allow software detection of the wake-up event as there is no status bit to indicate we received the WoL packet. 6. across reboots of at least the Jetson Xavier NX system, the WoL configuration is preserved. Fix all of these issues by essentially rewriting the support. We: 1. clear the WoL event enable register at probe time. 2. detect whether we can support wake-up by having a valid interrupt, and the "wakeup-source" property in DT. If we can, then we mark the MDIO device as wakeup capable, and associate the interrupt with the wakeup source. 3. arrange for the get_wol() and set_wol() implementations to handle the case where the MDIO device has not been marked as wakeup capable (thereby returning no WoL support, and refusing to enable WoL support.) 4. avoid switching to PMEB mode, instead using INTB mode with the interrupt enable, reconfiguring the interrupt enables at suspend time, and restoring their original state at resume time (we track the state of the interrupt enable register in .config_intr() register.) 5. move WoL reset from .set_wol() to the suspend function to ensure that WoL state is cleared prior to suspend. This is necessary after the PME interrupt has been enabled as a second WoL packet will not re-raise a previously cleared PME interrupt. 6. when a PME interrupt (for wakeup) is asserted, pass this to the PM wakeup so it knows which device woke the system. This fixes WoL support in the Realtek RTL8211F driver when used on the nVidia Jetson Xavier NX platform, and needs to be applied before stmmac patches which allow these platforms to forward the ethtool WoL commands to the Realtek PHY. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1um8Ld-008jxD-Mc@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
Implement Wake-on-Lan for RTL8211F correctly. The existing
implementation has multiple issues:

1. It assumes that Wake-on-Lan can always be used, whether or not the
   interrupt is wired, and whether or not the interrupt is capable of
   waking the system. This breaks the ability for MAC drivers to detect
   whether the PHY WoL is functional.
2. switching the interrupt pin in the .set_wol() method to PMEB mode
   immediately silences link-state interrupts, which breaks phylib
   when interrupts are being used rather than polling mode.
3. the code claiming to "reset WOL status" was doing nothing of the
   sort. Bit 15 in page 0xd8a register 17 controls WoL reset, and
   needs to be pulsed low to reset the WoL state. This bit was always
   written as '1', resulting in no reset.
4. not resetting WoL state results in the PMEB pin remaining asserted,
   which in turn leads to an interrupt storm. Only resetting the WoL
   state in .set_wol() is not sufficient.
5. PMEB mode does not allow software detection of the wake-up event as
   there is no status bit to indicate we received the WoL packet.
6. across reboots of at least the Jetson Xavier NX system, the WoL
   configuration is preserved.

Fix all of these issues by essentially rewriting the support. We:
1. clear the WoL event enable register at probe time.
2. detect whether we can support wake-up by having a valid interrupt,
   and the "wakeup-source" property in DT. If we can, then we mark
   the MDIO device as wakeup capable, and associate the interrupt
   with the wakeup source.
3. arrange for the get_wol() and set_wol() implementations to handle
   the case where the MDIO device has not been marked as wakeup
   capable (thereby returning no WoL support, and refusing to enable
   WoL support.)
4. avoid switching to PMEB mode, instead using INTB mode with the
   interrupt enable, reconfiguring the interrupt enables at suspend
   time, and restoring their original state at resume time (we track
   the state of the interrupt enable register in .config_intr()
   register.)
5. move WoL reset from .set_wol() to the suspend function to ensure
   that WoL state is cleared prior to suspend. This is necessary
   after the PME interrupt has been enabled as a second WoL packet
   will not re-raise a previously cleared PME interrupt.
6. when a PME interrupt (for wakeup) is asserted, pass this to the
   PM wakeup so it knows which device woke the system.

This fixes WoL support in the Realtek RTL8211F driver when used on the
nVidia Jetson Xavier NX platform, and needs to be applied before stmmac
patches which allow these platforms to forward the ethtool WoL commands
to the Realtek PHY.

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/E1um8Ld-008jxD-Mc@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: phy: realtek: convert RTL8226-CG to c45 only 2025-08-15T00:32:54+00:00 Markus Stockhausen markus.stockhausen@gmx.de 2025-08-13T05:44:07+00:00 34167f1a024d2c5abae0b0325a6d0b8257160f86 Short: Convert the RTL8226-CG to c45 so it can be used in its Realtek based ecosystems. Long: The RTL8226-CG can be mainly found on devices of the Realtek Otto switch platform. Devices like the Zyxel XGS1210-12 are based on it. These implement a hardware based phy polling in the background to update SoC status registers. The hardware provides 4 smi busses where phys are attached to. For each bus one can decide if it is polled in c45 or c22 mode. See https://svanheule.net/realtek/longan/register/smi_glb_ctrl With this setting the register access will be limited by the hardware. This is very complex (including caching and special c45-over-c22 handling). But basically it boils down to "enable protocol x and SoC will disable register access via protocol y". Mainline already gained support for the rtl9300 mdio driver in commit 24e31e474769 ("net: mdio: Add RTL9300 MDIO driver"). It covers the basic features, but a lot effort is still needed to understand hardware properly. So it runs a simple setup by selecting the proper bus mode during startup. /* Put the interfaces into C45 mode if required */ glb_ctrl_mask = GENMASK(19, 16); for (i = 0; i < MAX_SMI_BUSSES; i++) if (priv->smi_bus_is_c45[i]) glb_ctrl_val |= GLB_CTRL_INTF_SEL(i); ... err = regmap_update_bits(regmap, SMI_GLB_CTRL, glb_ctrl_mask, glb_ctrl_val); To avoid complex coding later on, it limits access by only providing either c22 or c45: bus->name = "Realtek Switch MDIO Bus"; if (priv->smi_bus_is_c45[mdio_bus]) { bus->read_c45 = rtl9300_mdio_read_c45; bus->write_c45 = rtl9300_mdio_write_c45; } else { bus->read = rtl9300_mdio_read_c22; bus->write = rtl9300_mdio_write_c22; } Because of these limitations the existing RTL8226 phy driver is not working at all on Realtek switches. Convert the driver to c45-only. Luckily the RTL8226 seems to support proper MDIO_PMA_EXTABLE flags. So standard function genphy_c45_pma_read_abilities() can call genphy_c45_pma_read_ext_abilities() and 10/100/1000 is populated right. Thus conversion is straight forward. Outputs before - REMARK: For this a "hacked" bus was used that toggles the mode for each c22/c45 access. But that is slow and produces unstable data in the SoC status registers). Settings for lan9: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full 2500baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full 2500baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: Unknown! Duplex: Unknown! (255) Port: Twisted Pair PHYAD: 24 Transceiver: external Auto-negotiation: on MDI-X: Unknown Supports Wake-on: d Wake-on: d Link detected: no Outputs with this commit: Settings for lan9: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full 2500baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full 2500baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: Unknown! Duplex: Unknown! (255) Port: Twisted Pair PHYAD: 24 Transceiver: external Auto-negotiation: on MDI-X: Unknown Supports Wake-on: d Wake-on: d Link detected: no Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20250813054407.1108285-1-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
Short: Convert the RTL8226-CG to c45 so it can be used in its
Realtek based ecosystems.

Long: The RTL8226-CG can be mainly found on devices of the
Realtek Otto switch platform. Devices like the Zyxel XGS1210-12
are based on it. These implement a hardware based phy polling
in the background to update SoC status registers.

The hardware provides 4 smi busses where phys are attached to.
For each bus one can decide if it is polled in c45 or c22 mode.
See https://svanheule.net/realtek/longan/register/smi_glb_ctrl
With this setting the register access will be limited by the
hardware. This is very complex (including caching and special
c45-over-c22 handling). But basically it boils down to "enable
protocol x and SoC will disable register access via protocol y".

Mainline already gained support for the rtl9300 mdio driver
in commit 24e31e474769 ("net: mdio: Add RTL9300 MDIO driver").

It covers the basic features, but a lot effort is still needed
to understand hardware properly. So it runs a simple setup by
selecting the proper bus mode during startup.

	/* Put the interfaces into C45 mode if required */
	glb_ctrl_mask = GENMASK(19, 16);
	for (i = 0; i < MAX_SMI_BUSSES; i++)
		if (priv->smi_bus_is_c45[i])
			glb_ctrl_val |= GLB_CTRL_INTF_SEL(i);
	...
	err = regmap_update_bits(regmap, SMI_GLB_CTRL,
				 glb_ctrl_mask, glb_ctrl_val);

To avoid complex coding later on, it limits access by only
providing either c22 or c45:

	bus->name = "Realtek Switch MDIO Bus";
	if (priv->smi_bus_is_c45[mdio_bus]) {
		bus->read_c45 = rtl9300_mdio_read_c45;
		bus->write_c45 =  rtl9300_mdio_write_c45;
	} else {
		bus->read = rtl9300_mdio_read_c22;
		bus->write = rtl9300_mdio_write_c22;
	}

Because of these limitations the existing RTL8226 phy driver
is not working at all on Realtek switches. Convert the driver
to c45-only.

Luckily the RTL8226 seems to support proper MDIO_PMA_EXTABLE
flags. So standard function genphy_c45_pma_read_abilities() can
call genphy_c45_pma_read_ext_abilities() and 10/100/1000 is
populated right. Thus conversion is straight forward.

Outputs before - REMARK: For this a "hacked" bus was used that
toggles the mode for each c22/c45 access. But that is slow and
produces unstable data in the SoC status registers).

Settings for lan9:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
                                2500baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
                                2500baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: Unknown!
        Duplex: Unknown! (255)
        Port: Twisted Pair
        PHYAD: 24
        Transceiver: external
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: d
        Wake-on: d
        Link detected: no

Outputs with this commit:

Settings for lan9:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
                                2500baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
                                2500baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: Unknown!
        Duplex: Unknown! (255)
        Port: Twisted Pair
        PHYAD: 24
        Transceiver: external
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: d
        Wake-on: d
        Link detected: no

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://patch.msgid.link/20250813054407.1108285-1-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: phy: realtek: add error handling to rtl8211f_get_wol 2025-06-25T23:54:31+00:00 Daniel Braunwarth daniel.braunwarth@kuka.com 2025-06-24T14:17:33+00:00 a9b24b3583ae1da7dbda031f141264f2da260219 We should check if the WOL settings was successfully read from the PHY. In case this fails we cannot just use the error code and proceed. Signed-off-by: Daniel Braunwarth <daniel.braunwarth@kuka.com> Reported-by: Jon Hunter <jonathanh@nvidia.com> Closes: https://lore.kernel.org/baaa083b-9a69-460f-ab35-2a7cb3246ffd@nvidia.com Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250624-realtek_fixes-v1-1-02a0b7c369bc@kuka.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
We should check if the WOL settings was successfully read from the PHY.

In case this fails we cannot just use the error code and proceed.

Signed-off-by: Daniel Braunwarth <daniel.braunwarth@kuka.com>
Reported-by: Jon Hunter <jonathanh@nvidia.com>
Closes: https://lore.kernel.org/baaa083b-9a69-460f-ab35-2a7cb3246ffd@nvidia.com
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20250624-realtek_fixes-v1-1-02a0b7c369bc@kuka.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: phy: pass PHY driver to .match_phy_device OP 2025-05-21T22:56:09+00:00 Christian Marangi ansuelsmth@gmail.com 2025-05-17T20:13:45+00:00 31afd6bc55cc0093c3e5b0a368319e423d4de8ea Pass PHY driver pointer to .match_phy_device OP in addition to phydev. Having access to the PHY driver struct might be useful to check the PHY ID of the driver is being matched for in case the PHY ID scanned in the phydev is not consistent. A scenario for this is a PHY that change PHY ID after a firmware is loaded, in such case, the PHY ID stored in PHY device struct is not valid anymore and PHY will manually scan the ID in the match_phy_device function. Having the PHY driver info is also useful for those PHY driver that implement multiple simple .match_phy_device OP to match specific MMD PHY ID. With this extra info if the parsing logic is the same, the matching function can be generalized by using the phy_id in the PHY driver instead of hardcoding. Rust wrapper callback is updated to align to the new match_phy_device arguments. Suggested-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Benno Lossin <lossin@kernel.org> # for Rust Reviewed-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Link: https://patch.msgid.link/20250517201353.5137-2-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
Pass PHY driver pointer to .match_phy_device OP in addition to phydev.
Having access to the PHY driver struct might be useful to check the
PHY ID of the driver is being matched for in case the PHY ID scanned in
the phydev is not consistent.

A scenario for this is a PHY that change PHY ID after a firmware is
loaded, in such case, the PHY ID stored in PHY device struct is not
valid anymore and PHY will manually scan the ID in the match_phy_device
function.

Having the PHY driver info is also useful for those PHY driver that
implement multiple simple .match_phy_device OP to match specific MMD PHY
ID. With this extra info if the parsing logic is the same, the matching
function can be generalized by using the phy_id in the PHY driver
instead of hardcoding.

Rust wrapper callback is updated to align to the new match_phy_device
arguments.

Suggested-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Benno Lossin <lossin@kernel.org> # for Rust
Reviewed-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://patch.msgid.link/20250517201353.5137-2-ansuelsmth@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: phy: realtek: add RTL8127-internal PHY 2025-05-21T01:09:34+00:00 ChunHao Lin hau@realtek.com 2025-05-16T05:56:22+00:00 83d9623161283f5f6883ee3fdb88ef2177b8a5f1 RTL8127-internal PHY is RTL8261C which is a integrated 10Gbps PHY with ID 0x001cc890. It follows the code path of RTL8125/RTL8126 internal NBase-T PHY. Signed-off-by: ChunHao Lin <hau@realtek.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250516055622.3772-1-hau@realtek.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
RTL8127-internal PHY is RTL8261C which is a integrated 10Gbps PHY with ID
0x001cc890. It follows the code path of RTL8125/RTL8126 internal NBase-T
PHY.

Signed-off-by: ChunHao Lin <hau@realtek.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20250516055622.3772-1-hau@realtek.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: phy: realtek: Add support for PHY LEDs on RTL8211E 2025-05-06T11:31:27+00:00 Michael Klein michael@fossekall.de 2025-05-04T17:29:16+00:00 708686132ba02659267c0cebcc414348ece389a5 Like the RTL8211F, the RTL8211E PHY supports up to three LEDs. Add netdev trigger support for them, too. Signed-off-by: Michael Klein <michael@fossekall.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250504172916.243185-7-michael@fossekall.de Signed-off-by: Paolo Abeni <pabeni@redhat.com> 
Like the RTL8211F, the RTL8211E PHY supports up to three LEDs.
Add netdev trigger support for them, too.

Signed-off-by: Michael Klein <michael@fossekall.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20250504172916.243185-7-michael@fossekall.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>