[PATCH 0/3] leds: add Realtek RTL9300 port LEDs under software control

[PATCH 0/3] leds: add Realtek RTL9300 port LEDs under software control

[Ross Cawston]

The RTL9300 switch drives up to four LEDs per port over its LED
interface, serial or scanned, each normally showing a hardware function
chosen by the LED set of the port. Some boards wire LEDs to it that have
no hardware function and that the vendor firmware switches in software,
such as the PoE status LEDs of the MokerLink POE-10G07110GSM.

This series adds a binding for such LEDs as a child of the switch, like
its I2C and MDIO controllers, and a driver that takes them under
software control and exposes them as LED class devices. With the PSE
core's LED triggers, the PoE LEDs then follow the power delivery of
their ports. The registers come from the vendor SDK's register table.
Tested on the MokerLink POE-10G07110GSM.

Ross Cawston (3):
  dt-bindings: leds: add Realtek RTL9301 port LEDs
  dt-bindings: net: realtek,rtl9301-switch: add port LED controller
  leds: add Realtek RTL9300 port LED driver

 .../leds/realtek,rtl9301-port-leds.yaml       |  84 ++++++++
 .../bindings/net/realtek,rtl9301-switch.yaml  |   3 +
 MAINTAINERS                                   |   7 +
 drivers/leds/Kconfig                          |  13 ++
 drivers/leds/Makefile                         |   1 +
 drivers/leds/leds-rtl9300-port.c              | 201 ++++++++++++++++++
 6 files changed, 309 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/realtek,rtl9301-port-leds.yaml
 create mode 100644 drivers/leds/leds-rtl9300-port.c

-- 
2.55.0.windows.5

[PATCH 1/3] dt-bindings: leds: add Realtek RTL9301 port LEDs

[Ross Cawston]

Add a binding for RTL9300 switch port LEDs under software control. The
node is a child of the switch and gives the offset of the software LED
control registers; each LED child names its switch port and its place
among the port's LEDs.

Signed-off-by: Ross Cawston <ross@r-sc.ca>
---
 .../leds/realtek,rtl9301-port-leds.yaml       | 84 +++++++++++++++++++
 1 file changed, 84 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/realtek,rtl9301-port-leds.yaml

diff --git a/Documentation/devicetree/bindings/leds/realtek,rtl9301-port-leds.yaml b/Documentation/devicetree/bindings/leds/realtek,rtl9301-port-leds.yaml
new file mode 100644
index 00000000000..8d6b3552526
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/realtek,rtl9301-port-leds.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/realtek,rtl9301-port-leds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek RTL9300 switch port LEDs under software control
+
+maintainers:
+  - Ross Cawston <ross@r-sc.ca>
+
+description: |
+  The RTL9300 switch drives up to four LEDs per port over its LED interface,
+  serial or scanned, each normally showing a hardware function chosen by the
+  LED set of the port. The LEDs listed here are taken over by software instead
+  and switched on and off as LED class devices, for port LEDs that have no
+  hardware function such as the PoE status LED of a PoE switch. The node is a
+  child of the switch, whose registers it uses.
+
+properties:
+  compatible:
+    const: realtek,rtl9301-port-leds
+
+  reg:
+    description: The software LED control registers, from SW_LED_LOAD to the
+      end of LED_PORT_SW_CTRL, as an offset into the switch registers.
+    maxItems: 1
+
+  "#address-cells":
+    const: 2
+
+  "#size-cells":
+    const: 0
+
+patternProperties:
+  "^led@[0-9a-f]+,[0-3]$":
+    $ref: /schemas/leds/common.yaml#
+    unevaluatedProperties: false
+
+    properties:
+      reg:
+        items:
+          - items:
+              - description: Switch port
+                maximum: 27
+              - description: LED of the port, numbered as in the port's
+                  LED set
+                maximum: 3
+
+    required:
+      - reg
+
+required:
+  - compatible
+  - reg
+  - "#address-cells"
+  - "#size-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/leds/common.h>
+
+    led-controller@cc48 {
+        compatible = "realtek,rtl9301-port-leds";
+        reg = <0xcc48 0x84>;
+        #address-cells = <2>;
+        #size-cells = <0>;
+
+        led@0,2 {
+            reg = <0 2>;
+            color = <LED_COLOR_ID_GREEN>;
+            function = "poe";
+            function-enumerator = <1>;
+        };
+
+        led@8,2 {
+            reg = <8 2>;
+            color = <LED_COLOR_ID_GREEN>;
+            function = "poe";
+            function-enumerator = <2>;
+        };
+    };
-- 
2.55.0.windows.5

[PATCH 2/3] dt-bindings: net: realtek,rtl9301-switch: add port LED controller

[Ross Cawston]

The switch drives the port LEDs, and some boards wire LEDs to it that
have no hardware function and are switched in software, such as PoE
status LEDs. Allow the software LED control block, described by
realtek,rtl9301-port-leds, as a child of the switch like its I2C and
MDIO controllers.

Signed-off-by: Ross Cawston <ross@r-sc.ca>
---
 .../devicetree/bindings/net/realtek,rtl9301-switch.yaml        | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/realtek,rtl9301-switch.yaml b/Documentation/devicetree/bindings/net/realtek,rtl9301-switch.yaml
index 80eabc17066..9529327ee0c 100644
--- a/Documentation/devicetree/bindings/net/realtek,rtl9301-switch.yaml
+++ b/Documentation/devicetree/bindings/net/realtek,rtl9301-switch.yaml
@@ -57,6 +57,9 @@ patternProperties:
   'mdio-controller@[0-9a-f]+$':
     $ref: realtek,rtl9301-mdio.yaml#
 
+  'led-controller@[0-9a-f]+$':
+    $ref: /schemas/leds/realtek,rtl9301-port-leds.yaml#
+
 required:
   - compatible
   - reg
-- 
2.55.0.windows.5

[PATCH 3/3] leds: add Realtek RTL9300 port LED driver

[Ross Cawston]

The RTL9300 switch drives up to four LEDs per port over its LED
interface, serial or scanned. Each normally shows a hardware function
picked by the LED set of the port, but software can take it over: one
enable bit per LED, a 3-bit mode per LED (off, on or one of six blink
rates), kept separately for copper and fibre media, and a load strobe
after which the LED controller applies the modes.

Add a driver for LEDs that boards wire to the switch without a hardware
function, such as PoE status LEDs. It takes the LEDs listed in the
device tree under software control, sets both media alike, exposes them
as LED class devices and hands them back to their hardware function
when it is removed. The register offsets come from the reg of its node,
within the switch's syscon register block.

Signed-off-by: Ross Cawston <ross@r-sc.ca>
---
 MAINTAINERS                      |   7 ++
 drivers/leds/Kconfig             |  13 ++
 drivers/leds/Makefile            |   1 +
 drivers/leds/leds-rtl9300-port.c | 201 +++++++++++++++++++++++++++++++
 4 files changed, 222 insertions(+)
 create mode 100644 drivers/leds/leds-rtl9300-port.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a1eb0937238..1e099a4cf05 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23013,6 +23013,13 @@ S:	Maintained
 F:	Documentation/devicetree/bindings/net/dsa/realtek.yaml
 F:	drivers/net/dsa/realtek/*
 
+REALTEK RTL9300 PORT LED DRIVER
+M:	Ross Cawston <ross@r-sc.ca>
+L:	linux-leds@vger.kernel.org
+S:	Maintained
+F:	Documentation/devicetree/bindings/leds/realtek,rtl9301-port-leds.yaml
+F:	drivers/leds/leds-rtl9300-port.c
+
 REALTEK SPI-NAND
 M:	Chris Packham <chris.packham@alliedtelesis.co.nz>
 S:	Maintained
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 7ec2c8d7854..d9b2afca2a6 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -676,6 +676,19 @@ config LEDS_REGULATOR
 	help
 	  This option enables support for regulator driven LEDs.
 
+config LEDS_RTL9300_PORT
+	tristate "LED support for Realtek RTL9300 switch port LEDs"
+	depends on LEDS_CLASS
+	depends on MACH_REALTEK_RTL || COMPILE_TEST
+	select MFD_SYSCON
+	help
+	  This option enables software control of the port LEDs of the
+	  Realtek RTL9300 switch, for port LEDs that have no hardware
+	  function, such as the PoE status LEDs of PoE switches.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called leds-rtl9300-port.
+
 config LEDS_BD2606MVV
 	tristate "LED driver for BD2606MVV"
 	depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 4d4b089156e..e1295303738 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -87,6 +87,7 @@ obj-$(CONFIG_LEDS_POWERNV)		+= leds-powernv.o
 obj-$(CONFIG_LEDS_PWM)			+= leds-pwm.o
 obj-$(CONFIG_LEDS_QNAP_MCU)		+= leds-qnap-mcu.o
 obj-$(CONFIG_LEDS_REGULATOR)		+= leds-regulator.o
+obj-$(CONFIG_LEDS_RTL9300_PORT)		+= leds-rtl9300-port.o
 obj-$(CONFIG_LEDS_SC27XX_BLTC)		+= leds-sc27xx-bltc.o
 obj-$(CONFIG_LEDS_ST1202)		+= leds-st1202.o
 obj-$(CONFIG_LEDS_SUN50I_A100)		+= leds-sun50i-a100.o
diff --git a/drivers/leds/leds-rtl9300-port.c b/drivers/leds/leds-rtl9300-port.c
new file mode 100644
index 00000000000..623932a2a41
--- /dev/null
+++ b/drivers/leds/leds-rtl9300-port.c
@@ -0,0 +1,201 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Realtek RTL9300 switch port LEDs under software control
+ *
+ * The RTL9300 drives up to four LEDs per switch port over its LED interface,
+ * serial or scanned. Each one normally shows a hardware function (link,
+ * speed, activity) chosen by the LED set of the port, but software can take
+ * it over and switch it on or off instead. Boards use that for port LEDs
+ * that have no hardware function, such as the PoE status LED of a PoE
+ * switch.
+ *
+ * Software control has a mode per LED, kept separately for copper and fibre
+ * media, and the LED controller picks the new modes up when it is told to
+ * load them. Both media are set alike here. The registers are part of the
+ * switch register block; the node's reg gives their offset in it.
+ *
+ * Copyright (C) 2026 Ross Cawston <ross@r-sc.ca>
+ */
+
+#include <linux/bits.h>
+#include <linux/leds.h>
+#include <linux/mfd/syscon.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/regmap.h>
+
+/* Offsets from reg, which is SW_LED_LOAD (0xcc48 on the RTL9301) */
+#define RTL9300_LED_SW_LOAD			0x00
+#define   RTL9300_LED_SW_LOAD_START		BIT(0)
+#define RTL9300_LED_PORT_SW_EN_CTRL(port)	(0x04 + ((port) / 8) * 4)
+#define   RTL9300_LED_PORT_SW_EN(port, led)	BIT(((port) % 8) * 4 + (led))
+#define RTL9300_LED_PORT_SW_CTRL(port)		(0x14 + (port) * 4)
+/* 3-bit mode per LED: 0 off, 7 on, copper LEDs from bit 0, fibre from 12 */
+#define   RTL9300_LED_SW_MODE(led)		((GENMASK(2, 0) | GENMASK(14, 12)) << (3 * (led)))
+
+#define RTL9300_LED_PORTS			28
+#define RTL9300_LED_PER_PORT			4
+
+struct rtl9300_port_leds {
+	struct regmap *map;
+	u32 base;
+};
+
+struct rtl9300_port_led {
+	struct led_classdev cdev;
+	struct rtl9300_port_leds *ctrl;
+	u32 port;
+	u32 led;
+};
+
+static int rtl9300_port_led_load(struct rtl9300_port_leds *ctrl)
+{
+	return regmap_write(ctrl->map, ctrl->base + RTL9300_LED_SW_LOAD,
+			    RTL9300_LED_SW_LOAD_START);
+}
+
+static int rtl9300_port_led_set(struct led_classdev *cdev,
+				enum led_brightness brightness)
+{
+	struct rtl9300_port_led *pled = container_of(cdev, struct rtl9300_port_led, cdev);
+	struct rtl9300_port_leds *ctrl = pled->ctrl;
+	u32 mask = RTL9300_LED_SW_MODE(pled->led);
+	int ret;
+
+	ret = regmap_update_bits(ctrl->map, ctrl->base + RTL9300_LED_PORT_SW_CTRL(pled->port),
+				 mask, brightness ? mask : 0);
+	if (ret)
+		return ret;
+
+	return rtl9300_port_led_load(ctrl);
+}
+
+/* Hand the LED back to its hardware function */
+static void rtl9300_port_led_release(void *data)
+{
+	struct rtl9300_port_led *pled = data;
+	struct rtl9300_port_leds *ctrl = pled->ctrl;
+
+	regmap_clear_bits(ctrl->map, ctrl->base + RTL9300_LED_PORT_SW_EN_CTRL(pled->port),
+			  RTL9300_LED_PORT_SW_EN(pled->port, pled->led));
+	rtl9300_port_led_load(ctrl);
+}
+
+static int rtl9300_port_led_add(struct device *dev, struct rtl9300_port_leds *ctrl,
+				struct fwnode_handle *fwnode)
+{
+	struct led_init_data init_data = { .fwnode = fwnode };
+	struct rtl9300_port_led *pled;
+	enum led_brightness brightness;
+	u32 reg[2], sw_en, val;
+	int ret;
+
+	ret = fwnode_property_read_u32_array(fwnode, "reg", reg, ARRAY_SIZE(reg));
+	if (ret)
+		return dev_err_probe(dev, ret, "%pfw: bad reg\n", fwnode);
+	if (reg[0] >= RTL9300_LED_PORTS || reg[1] >= RTL9300_LED_PER_PORT)
+		return dev_err_probe(dev, -EINVAL, "%pfw: no LED %u of port %u\n",
+				     fwnode, reg[1], reg[0]);
+
+	pled = devm_kzalloc(dev, sizeof(*pled), GFP_KERNEL);
+	if (!pled)
+		return -ENOMEM;
+
+	pled->ctrl = ctrl;
+	pled->port = reg[0];
+	pled->led = reg[1];
+	sw_en = ctrl->base + RTL9300_LED_PORT_SW_EN_CTRL(pled->port);
+
+	switch (led_init_default_state_get(fwnode)) {
+	case LEDS_DEFSTATE_ON:
+		brightness = LED_ON;
+		break;
+	case LEDS_DEFSTATE_KEEP:
+		ret = regmap_read(ctrl->map, sw_en, &val);
+		if (ret)
+			return ret;
+		brightness = LED_OFF;
+		if (val & RTL9300_LED_PORT_SW_EN(pled->port, pled->led)) {
+			ret = regmap_read(ctrl->map,
+					  ctrl->base + RTL9300_LED_PORT_SW_CTRL(pled->port),
+					  &val);
+			if (ret)
+				return ret;
+			if (val & RTL9300_LED_SW_MODE(pled->led))
+				brightness = LED_ON;
+		}
+		break;
+	default:
+		brightness = LED_OFF;
+		break;
+	}
+
+	ret = rtl9300_port_led_set(&pled->cdev, brightness);
+	if (ret)
+		return ret;
+
+	ret = regmap_set_bits(ctrl->map, sw_en, RTL9300_LED_PORT_SW_EN(pled->port, pled->led));
+	if (ret)
+		return ret;
+
+	ret = devm_add_action_or_reset(dev, rtl9300_port_led_release, pled);
+	if (ret)
+		return ret;
+
+	ret = rtl9300_port_led_load(ctrl);
+	if (ret)
+		return ret;
+
+	pled->cdev.brightness = brightness;
+	pled->cdev.max_brightness = LED_ON;
+	pled->cdev.brightness_set_blocking = rtl9300_port_led_set;
+
+	return devm_led_classdev_register_ext(dev, &pled->cdev, &init_data);
+}
+
+static int rtl9300_port_leds_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct rtl9300_port_leds *ctrl;
+	int ret;
+
+	ctrl = devm_kzalloc(dev, sizeof(*ctrl), GFP_KERNEL);
+	if (!ctrl)
+		return -ENOMEM;
+
+	ctrl->map = syscon_node_to_regmap(dev_of_node(dev->parent));
+	if (IS_ERR(ctrl->map))
+		return dev_err_probe(dev, PTR_ERR(ctrl->map), "no switch regmap\n");
+
+	ret = device_property_read_u32(dev, "reg", &ctrl->base);
+	if (ret)
+		return dev_err_probe(dev, ret, "no reg\n");
+
+	device_for_each_child_node_scoped(dev, child) {
+		ret = rtl9300_port_led_add(dev, ctrl, child);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static const struct of_device_id rtl9300_port_leds_of_match[] = {
+	{ .compatible = "realtek,rtl9301-port-leds" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, rtl9300_port_leds_of_match);
+
+static struct platform_driver rtl9300_port_leds_driver = {
+	.probe = rtl9300_port_leds_probe,
+	.driver = {
+		.name = "leds-rtl9300-port",
+		.of_match_table = rtl9300_port_leds_of_match,
+	},
+};
+module_platform_driver(rtl9300_port_leds_driver);
+
+MODULE_DESCRIPTION("Realtek RTL9300 switch port LEDs under software control");
+MODULE_LICENSE("GPL");
-- 
2.55.0.windows.5

Re: [PATCH 3/3] leds: add Realtek RTL9300 port LED driver

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 396 bytes --]

Hello Ross,

On Sun, Oct 18, 2026 at 12:43:38PM -0700, Ross Cawston wrote:
> +#include <linux/mod_devicetable.h>
> [...]
> +#include <linux/platform_device.h>

Please don't include <linux/mod_devicetable.h> which pulls in a big
bunch of dependencies on subsystems not used in your driver.
<linux/platform_device.h> already provides of_device_id so you can just
drop the former.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 0/3] leds: add Realtek RTL9300 port LEDs under software control

[Andrew Lunn]

On Sun, Oct 18, 2026 at 12:43:35PM -0700, Ross Cawston wrote:
> The RTL9300 switch drives up to four LEDs per port over its LED
> interface, serial or scanned, each normally showing a hardware function
> chosen by the LED set of the port. Some boards wire LEDs to it that have
> no hardware function and that the vendor firmware switches in software,
> such as the PoE status LEDs of the MokerLink POE-10G07110GSM.
> 
> This series adds a binding for such LEDs as a child of the switch, like
> its I2C and MDIO controllers, and a driver that takes them under
> software control and exposes them as LED class devices.

This is an odd architecture when compared to other switch drivers with
LEDs.

Port LEDs should be within the port node of the switch in DT. Ideally
you want all LEDs for a port to start the with basics, on/off control.
That gives the minimum, enough that you can make them software blink
on traffic, show link speed, poe, shift lock, morse code panic dumps.

If the LED has more capabilities, you can then advertise this, and the
led triggers will offload blinking to the hardware. But this is an
extension, not a requirement.

So please don't make these LEDs special.

	Andrew

Re: [PATCH 0/3] leds: add Realtek RTL9300 port LEDs under software control

[Ross Cawston]

On Sun, Oct 18, 2026 at 10:36 PM UTC, Andrew Lunn wrote:
> Port LEDs should be within the port node of the switch in DT. Ideally
> you want all LEDs for a port to start the with basics, on/off control.
[...]
> So please don't make these LEDs special.

That makes sense. The catch is that RTL9300 has no switch driver
upstream yet, so there is no port node with a driver behind it to put
them in: mainline only has drivers for the switch's I2C and MDIO
controllers.

Unless you see a place they could go in the meantime, I'll withdraw
this series until there is one.

Chris, do you know of anyone working on an RTL9300 switch driver? If
so, I'd be glad to help with the port LEDs there.

Ross

Re: [PATCH 0/3] leds: add Realtek RTL9300 port LEDs under software control

[Andrew Lunn]

On Sun, Oct 18, 2026 at 04:20:14PM -0700, Ross Cawston wrote:
> On Sun, Oct 18, 2026 at 10:36 PM UTC, Andrew Lunn wrote:
> > Port LEDs should be within the port node of the switch in DT. Ideally
> > you want all LEDs for a port to start the with basics, on/off control.
> [...]
> > So please don't make these LEDs special.
> 
> That makes sense. The catch is that RTL9300 has no switch driver
> upstream yet, so there is no port node with a driver behind it to put
> them in: mainline only has drivers for the switch's I2C and MDIO
> controllers.

Markus Stockhausen <markus.stockhausen@gmx.de> did a lot of work on
the MDIO driver, based on what is in OpenWRT. Maybe he plans to work
on the switch driver?

   Andrew

Re: [PATCH 0/3] leds: add Realtek RTL9300 port LEDs under software control

[Ross Cawston]

On Mon, Oct 19, 2026 at 12:02 AM UTC, Andrew Lunn wrote:
> Markus Stockhausen <markus.stockhausen@gmx.de> did a lot of work on
> the MDIO driver, based on what is in OpenWRT. Maybe he plans to work
> on the switch driver?

Thanks, adding Markus.

Markus, are you planning to take the RTL930x switch driver upstream? If
so, I'd be glad to help with the port LEDs there, in the port nodes as
Andrew describes earlier in this thread, and to test on an RTL9303
board:

https://lore.kernel.org/all/20261018194339.132-1-ross@r-sc.ca/T/

In OpenWrt, openwrt/openwrt#25341 adds software control of the RTL930x
LEDs to the switch driver; I tested it with this board's PoE LEDs.

Ross

AW: [PATCH 0/3] leds: add Realtek RTL9300 port LEDs under software control

[Markus Stockhausen]

Hi you two,

> Von: Ross Cawston <ross@r-sc.ca> 
> Gesendet: Montag, 19. Oktober 2026 07:43
> An: andrew@lunn.ch
> Betreff: Re: [PATCH 0/3] leds: add Realtek RTL9300 port LEDs under
software control
> ...
>
> Thanks, adding Markus.
>
> Markus, are you planning to take the RTL930x switch driver upstream? 

While this is the overall goal some day it is currently beyond the time 
available. I'm only two months into the nearly abandoned Otto DSA 
driver and just keep things rolling. As of today the operation mode is 
more like:

Some commited contributors are throwing AI at the hardware to fix and 
enhance the DSA driver. Coding, testing and PR submission is runnung 
full-auto-mode. So a lot gets documented during this process. With my 
limited time and knowledge I'm doing my best to review and organize
this to some extend.  If possible I ask for refactoring or add simple 
refactoring PRs on my own.

Markus