Re: [PATCH] net: pse-pd: add LED trigger support
From: Kory Maincent <kory.maincent@bootlin.com>
Date: 2026-03-16 14:44:40
Also in:
lkml
Hello Carlo, On Sun, 15 Mar 2026 17:58:05 +0100 Oleksij Rempel [off-list ref] 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:quoted
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