[PATCH] net: pse-pd: add LED trigger support

[PATCH] net: pse-pd: add LED trigger support

[Carlo Szelinsky]

Add LED trigger registration and polling into the PSE core subsystem.
Per-PI "delivering" and "enabled" triggers are registered for each PSE
controller, with a configurable poll interval via the DT property
"led-poll-interval-ms".

Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
---
 drivers/net/pse-pd/pse_core.c | 123 ++++++++++++++++++++++++++++++++++
 include/linux/pse-pd/pse.h    |  23 +++++++
 2 files changed, 146 insertions(+)

diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
index 3beaaaeec9e1..589a9b403916 100644
--- a/drivers/net/pse-pd/pse_core.c
+++ b/drivers/net/pse-pd/pse_core.c
@@ -15,6 +15,7 @@
 #include <linux/regulator/machine.h>
 #include <linux/rtnetlink.h>
 #include <net/net_trackers.h>
+#include <linux/leds.h>
 
 #define PSE_PW_D_LIMIT INT_MAX
 
@@ -1030,6 +1031,122 @@ static void pse_send_ntf_worker(struct work_struct *work)
 	}
 }
 
+#if IS_ENABLED(CONFIG_LEDS_TRIGGERS)
+static void pse_led_poll_work(struct work_struct *work)
+{
+	struct pse_controller_dev *pcdev =
+		container_of(work, struct pse_controller_dev,
+			     led_poll_work.work);
+	int i;
+
+	mutex_lock(&pcdev->lock);
+	for (i = 0; i < pcdev->nr_lines; i++) {
+		struct pse_pi_led_triggers *trigs = &pcdev->pi_led_trigs[i];
+		struct pse_pw_status pw_status = {};
+		struct pse_admin_state admin_state = {};
+		bool delivering, enabled;
+
+		if (!pcdev->pi[i].rdev)
+			continue;
+
+		if (pcdev->ops->pi_get_pw_status(pcdev, i, &pw_status))
+			continue;
+		if (pcdev->ops->pi_get_admin_state(pcdev, i, &admin_state))
+			continue;
+
+		delivering = pw_status.c33_pw_status ==
+			ETHTOOL_C33_PSE_PW_D_STATUS_DELIVERING;
+		enabled = admin_state.c33_admin_state ==
+			ETHTOOL_C33_PSE_ADMIN_STATE_ENABLED;
+
+		if (trigs->last_delivering != delivering) {
+			trigs->last_delivering = delivering;
+			led_trigger_event(&trigs->delivering,
+					  delivering ? LED_FULL : LED_OFF);
+		}
+
+		if (trigs->last_enabled != enabled) {
+			trigs->last_enabled = enabled;
+			led_trigger_event(&trigs->enabled,
+					  enabled ? LED_FULL : LED_OFF);
+		}
+	}
+	mutex_unlock(&pcdev->lock);
+
+	schedule_delayed_work(&pcdev->led_poll_work,
+			      msecs_to_jiffies(pcdev->led_poll_interval_ms));
+}
+
+static int pse_led_triggers_register(struct pse_controller_dev *pcdev)
+{
+	struct device *dev = pcdev->dev;
+	const char *node_name;
+	int i, ret;
+
+	node_name = dev->of_node ? dev->of_node->name : dev_name(dev);
+
+	of_property_read_u32(dev->of_node, "led-poll-interval-ms",
+			     &pcdev->led_poll_interval_ms);
+	if (!pcdev->led_poll_interval_ms)
+		pcdev->led_poll_interval_ms = 500;
+
+	pcdev->pi_led_trigs = devm_kcalloc(dev, pcdev->nr_lines,
+					   sizeof(*pcdev->pi_led_trigs),
+					   GFP_KERNEL);
+	if (!pcdev->pi_led_trigs)
+		return -ENOMEM;
+
+	INIT_DELAYED_WORK(&pcdev->led_poll_work, pse_led_poll_work);
+
+	for (i = 0; i < pcdev->nr_lines; i++) {
+		struct pse_pi_led_triggers *trigs = &pcdev->pi_led_trigs[i];
+
+		if (!pcdev->pi[i].rdev)
+			continue;
+
+		trigs->delivering.name = devm_kasprintf(dev, GFP_KERNEL,
+							"%s:port%d:delivering",
+							node_name, i);
+		if (!trigs->delivering.name)
+			return -ENOMEM;
+
+		ret = devm_led_trigger_register(dev, &trigs->delivering);
+		if (ret)
+			return ret;
+
+		trigs->enabled.name = devm_kasprintf(dev, GFP_KERNEL,
+						     "%s:port%d:enabled",
+						     node_name, i);
+		if (!trigs->enabled.name)
+			return -ENOMEM;
+
+		ret = devm_led_trigger_register(dev, &trigs->enabled);
+		if (ret)
+			return ret;
+	}
+
+	schedule_delayed_work(&pcdev->led_poll_work,
+			      msecs_to_jiffies(pcdev->led_poll_interval_ms));
+
+	return 0;
+}
+
+static void pse_led_triggers_cancel(struct pse_controller_dev *pcdev)
+{
+	if (pcdev->pi_led_trigs)
+		cancel_delayed_work_sync(&pcdev->led_poll_work);
+}
+#else
+static int pse_led_triggers_register(struct pse_controller_dev *pcdev)
+{
+	return 0;
+}
+
+static void pse_led_triggers_cancel(struct pse_controller_dev *pcdev)
+{
+}
+#endif /* CONFIG_LEDS_TRIGGERS */
+
 /**
  * pse_controller_register - register a PSE controller device
  * @pcdev: a pointer to the initialized PSE controller device
@@ -1104,6 +1221,11 @@ int pse_controller_register(struct pse_controller_dev *pcdev)
 	list_add(&pcdev->list, &pse_controller_list);
 	mutex_unlock(&pse_list_mutex);
 
+	ret = pse_led_triggers_register(pcdev);
+	if (ret)
+		dev_warn(pcdev->dev, "Failed to register LED triggers: %d\n",
+			 ret);
+
 	return 0;
 }
 EXPORT_SYMBOL_GPL(pse_controller_register);
@@ -1114,6 +1236,7 @@ EXPORT_SYMBOL_GPL(pse_controller_register);
  */
 void pse_controller_unregister(struct pse_controller_dev *pcdev)
 {
+	pse_led_triggers_cancel(pcdev);
 	pse_flush_pw_ds(pcdev);
 	pse_release_pis(pcdev);
 	if (pcdev->irq)
diff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h
index 4e5696cfade7..9e5d0123223e 100644
--- a/include/linux/pse-pd/pse.h
+++ b/include/linux/pse-pd/pse.h
@@ -11,6 +11,7 @@
 #include <uapi/linux/ethtool.h>
 #include <uapi/linux/ethtool_netlink_generated.h>
 #include <linux/regulator/driver.h>
+#include <linux/leds.h>
 
 /* Maximum current in uA according to IEEE 802.3-2022 Table 145-1 */
 #define MAX_PI_CURRENT 1920000
@@ -266,6 +267,23 @@ struct pse_pi {
 	int pw_allocated_mW;
 };
 
+#if IS_ENABLED(CONFIG_LEDS_TRIGGERS)
+/**
+ * struct pse_pi_led_triggers - LED trigger state for a PSE PI
+ *
+ * @delivering: LED trigger for power delivering state
+ * @enabled: LED trigger for admin enabled state
+ * @last_delivering: cached delivering state for change detection
+ * @last_enabled: cached enabled state for change detection
+ */
+struct pse_pi_led_triggers {
+	struct led_trigger delivering;
+	struct led_trigger enabled;
+	bool last_delivering;
+	bool last_enabled;
+};
+#endif
+
 /**
  * struct pse_ntf - PSE notification element
  *
@@ -317,6 +335,11 @@ struct pse_controller_dev {
 	struct work_struct ntf_work;
 	DECLARE_KFIFO_PTR(ntf_fifo, struct pse_ntf);
 	spinlock_t ntf_fifo_lock; /* Protect @ntf_fifo writer */
+#if IS_ENABLED(CONFIG_LEDS_TRIGGERS)
+	struct pse_pi_led_triggers *pi_led_trigs;
+	struct delayed_work led_poll_work;
+	unsigned int led_poll_interval_ms;
+#endif
 };
 
 /**
-- 
2.43.0

Re: [PATCH] net: pse-pd: add LED trigger support

[Oleksij Rempel]

Hi Carlo,

On Sun, Mar 15, 2026 at 12:59:16AM +0100, Carlo Szelinsky wrote:
> Add LED trigger registration and polling into the PSE core subsystem.
> Per-PI "delivering" and "enabled" triggers are registered for each PSE
> controller, with a configurable poll interval via the DT property
> "led-poll-interval-ms".

Nice work. However, this needs an architectural shift.

Since the hardware lacks interrupts, we need a core polling mechanism.
However, the PSE core already has an event notification framework. The
new polling should integrate with it instead of being LED-specific.

Please consider this approach:

- Add a generic polling loop in the PSE core. It should simulate the IRQ
  handler pse_isr() by detecting state changes and pushing standard
  events into the existing ntf_fifo to be processed by
  pse_send_ntf_worker()

- Do not poll inside the LED code. The core state tracker should trigger
  LED events as a reaction to state changes.

- Please add a define for the default polling interval. Include a
  comment explaining why this specific value is chosen.

@Köry, How should we decide when to enable polling?  Should we check if
no IRQ is registered? Or add a flag if the controller lacks IRQ support?

@Carlo, What controller are you using?

Best Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH] net: pse-pd: add LED trigger support

[Carlo Szelinsky]

Hi Oleksij,

Thanks for your kind and quick feedback. I appreciate the time you invested on the weekend :-)

I will look into your suggestion and try to work on it... 

Regarding your question: It is a simple POE chip (hs104) that is integrated in different cheap realtek managed switches.
It communicates only via i2c with the host and does not have any other GPIP/IRQ functionality. The problem is that the LEDs are controlled via a different (MFD) chip that communicates via i2c as well. We wanted to uncouple this as much as possible to keep things clean.

More information you find here:
https://github.com/openwrt/openwrt/pull/22245 [hs104 driver]
https://forum.openwrt.org/t/support-poe-on-hasivo-devices-s1100wp-8gt-se/244817 [discussion]
https://github.com/openwrt/openwrt/pull/21578 [MFD LED controller]

Side note: We are working hard on supporting PSE-PD for openwrt (backports to 6.12, luci, netifd support) and we plan to port other old drivers.

Do you think this simple driver for the hs104 (openwrt github PR) could get merged to mainline kernel?

best,
Carlo

Re: [PATCH] net: pse-pd: add LED trigger support

[Oleksij Rempel]

Hi Carlo,

On Sun, Mar 15, 2026 at 10:12:22PM +0100, Carlo Szelinsky wrote:
> Hi Oleksij,
> 
> Thanks for your kind and quick feedback. I appreciate the time you
> invested on the weekend :-)
> 
> I will look into your suggestion and try to work on it... 
> 
> Regarding your question: It is a simple POE chip (hs104) that is
> integrated in different cheap realtek managed switches.
> It communicates only via i2c with the host and does not have any other
> GPIP/IRQ functionality. The problem is that the LEDs are controlled
> via a different (MFD) chip that communicates via i2c as well. We
> wanted to uncouple this as much as possible to keep things clean.
> 
> More information you find here:
> https://github.com/openwrt/openwrt/pull/22245 [hs104 driver]

I would add regmap_range , otherwise regmap damp will try to access not
existing registers.

> https://forum.openwrt.org/t/support-poe-on-hasivo-devices-s1100wp-8gt-se/244817 [discussion]
> https://github.com/openwrt/openwrt/pull/21578 [MFD LED controller]

I guess, here we will have some discussion on the devicetree binding :)

> Side note: We are working hard on supporting PSE-PD for openwrt
> (backports to 6.12, luci, netifd support) and we plan to port other
> old drivers.

Very nice!

> Do you think this simple driver for the hs104 (openwrt github PR)
> could get merged to mainline kernel?

Sure!

Best Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH] net: pse-pd: add LED trigger support

[Kory Maincent]

Hello Carlo,

On Sun, 15 Mar 2026 17:58:05 +0100
Oleksij Rempel <o.rempel@pengutronix.de> wrote:

> Hi Carlo,

Nice to see you trying upstreaming the PSE LED work.
 
> On Sun, Mar 15, 2026 at 12:59:16AM +0100, Carlo Szelinsky wrote:
> > Add LED trigger registration and polling into the PSE core subsystem.
> > Per-PI "delivering" and "enabled" triggers are registered for each PSE
> > controller, with a configurable poll interval via the DT property
> > "led-poll-interval-ms".  
> 
> Nice work. However, this needs an architectural shift.
> 
> Since the hardware lacks interrupts, we need a core polling mechanism.
> However, the PSE core already has an event notification framework. The
> new polling should integrate with it instead of being LED-specific.
> 
> Please consider this approach:
> 
> - Add a generic polling loop in the PSE core. It should simulate the IRQ
>   handler pse_isr() by detecting state changes and pushing standard
>   events into the existing ntf_fifo to be processed by
>   pse_send_ntf_worker()

Careful with pse_isr() there is a tricky case between software and hardware
managed power control. And the irq support was mainly designed to support the
software managed power control case.

Adding a generic polling loop should be indeed similar to what happen in the
interrupt process. This mean we need a polling_handler to report the events
from the driver similarly to the irq one:
https://elixir.bootlin.com/linux/v6.19.6/source/drivers/net/pse-pd/tps23881.c#L1348
And either modify the devm_pse_irq_helper() supporting the case when the irq is
null or adding a new devm_pse_poll_helper() helper. So either the core decide
to use polling instead of irq either this choice comes from the driver.

We have two cases, interrupt not supported by the controller or interrupt
supported but not wired and the polling case should comply with both.

Note: You may also need to modify pse_pw_d_is_sw_pw_control() accordingly.

> - Do not poll inside the LED code. The core state tracker should trigger
>   LED events as a reaction to state changes.

+1

> - Please add a define for the default polling interval. Include a
>   comment explaining why this specific value is chosen.

+1

> @Köry, How should we decide when to enable polling?  Should we check if
> no IRQ is registered? Or add a flag if the controller lacks IRQ support?

Replied above.

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

Re: [PATCH] net: pse-pd: add LED trigger support

[Andrew Lunn]

On Sun, Mar 15, 2026 at 12:59:16AM +0100, Carlo Szelinsky wrote:
> Add LED trigger registration and polling into the PSE core subsystem.
> Per-PI "delivering" and "enabled" triggers are registered for each PSE
> controller, with a configurable poll interval via the DT property
> "led-poll-interval-ms".
> 
> Signed-off-by: Carlo Szelinsky <github@szelinsky.de>

Please also Cc: LED mailing list. Ideally you want an acked-by from
the LED Maintainer.

    Andrew

---
pw-bot: cr

Re: [PATCH] net: pse-pd: add LED trigger support

[Carlo Szelinsky]

Hey Kory, Hey Oleksij,

Thanks again for taking the time to give detailed feedback. I am not really experienced with working on the kernel, so I took some time to process and get a clear picture. I will try to implement and test it asap... My action points would be the following:
                                                                                                                              
1. Replace the LED specific polling with some generic devm_pse_poll_helper() that is based on the existing pse_isr() logic but in a timer instead of an IRQ - pushing events through ntf_fifo / pse_send_ntf_worker() like other IRQ-based controllers already do.
2. Fire LED triggers from the notification path, not from a separate poll loop: LEDs react to state changes e.g. they don't drive their own polling.
3. Fix pse_pw_d_is_sw_pw_control() - it currently requires pcdev->irq to be set in the PSE_BUDGET_EVAL_STRAT_DISABLED path, so poll-only controllers like hs104 would never enter software power control. Needs to also check for an active poll worker.
4. Add #define for the default poll interval (e.g. 500ms) with a comment explainin why.

Did I understand you correctly to not waste any time?

Unclear is for me still:
* Poll helper design: new devm_pse_poll_helper() vs extending devm_pse_irq_helper() with IRQ=0 fallback? I suggest a separate devm_pse_poll_helper() - it keeps the IRQ and poll paths clean and symmetric, and avoids overloading devm_pse_irq_helper() with conditional logic.
* Who decides to poll? The driver explicitly calls the poll helper, or the core auto-detects missing IRQ? I suggest the driver decides explicitly - the driver knows its hardware best, and an explicit call is easier to review and reason about than auto-detection magic.
* DT property: rename led-poll-interval-ms to poll-interval-ms since polling is now generic? I suggest yes - the polling is no longer LED-specific, so the property name should reflect that.
* Kory mentioned two distinct cases: (a) controller has no IRQ support at all (like the hs104), (b) controller supports IRQ but it's not wired on the board. Should both cases be handled by the same poll helper, or does (b) need different treatment? I suggest the same devm_pse_poll_helper() handles both - from the core's perspective the situation is identical: no IRQ available, need to poll. The driver just calls the poll helper instead of the IRQ helper in either case.

Have a nice weekend,
cheers.

Re: [PATCH] net: pse-pd: add LED trigger support

[Kory Maincent]

Hello Carlo,

On Sat, 21 Mar 2026 18:55:46 +0100
Carlo Szelinsky <github@szelinsky.de> wrote:

> Hey Kory, Hey Oleksij,
> 
> Thanks again for taking the time to give detailed feedback. I am not really
> experienced with working on the kernel, so I took some time to process and
> get a clear picture. I will try to implement and test it asap... My action
> points would be the following: 1. Replace the LED specific polling with some
> generic devm_pse_poll_helper() that is based on the existing pse_isr() logic
> but in a timer instead of an IRQ - pushing events through ntf_fifo /
> pse_send_ntf_worker() like other IRQ-based controllers already do. 

Please add a patch to introduce the poll path before any LED support.
I will test this new path with my boards with and without the IRQ configured. 

> 2. Fire
> LED triggers from the notification path, not from a separate poll loop: LEDs
> react to state changes e.g. they don't drive their own polling. 3. Fix
> pse_pw_d_is_sw_pw_control() - it currently requires pcdev->irq to be set in
> the PSE_BUDGET_EVAL_STRAT_DISABLED path, so poll-only controllers like hs104
> would never enter software power control. Needs to also check for an active
> poll worker. 4. Add #define for the default poll interval (e.g. 500ms) with a
> comment explainin why.
> 
> Did I understand you correctly to not waste any time?

Yes that's it.

> Unclear is for me still:
> * Poll helper design: new devm_pse_poll_helper() vs extending
> devm_pse_irq_helper() with IRQ=0 fallback? I suggest a separate
> devm_pse_poll_helper() - it keeps the IRQ and poll paths clean and symmetric,
> and avoids overloading devm_pse_irq_helper() with conditional logic.
> * Who decides to poll? The driver explicitly calls the poll helper, or the
> core auto-detects missing IRQ? I suggest the driver decides explicitly - the
> driver knows its hardware best, and an explicit call is easier to review and
> reason about than auto-detection magic.
> * DT property: rename led-poll-interval-ms to poll-interval-ms since polling
> is now generic? I suggest yes - the polling is no longer LED-specific, so the
> property name should reflect that.
> * Kory mentioned two distinct cases: (a) controller has no IRQ support at all
> (like the hs104), (b) controller supports IRQ but it's not wired on the
> board. Should both cases be handled by the same poll helper, or does (b) need
> different treatment? I suggest the same devm_pse_poll_helper() handles both -
> from the core's perspective the situation is identical: no IRQ available,
> need to poll. The driver just calls the poll helper instead of the IRQ helper
> in either case.

I agreed with all your points.
Thank you!

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

Re: [PATCH] net: pse-pd: add LED trigger support

[Carlo Szelinsky]

Thank you for the support Kory, Oleksij and Andrew.