Big thanks to Kory, Oleksij and Krzysztof for all the helpful feedback
on v2 — really appreciate the time you put into reviewing this.
I learned a lot!
This series adds poll-based event detection and LED trigger support
to the PSE core subsystem.
Patches 1-2 introduce the poll path independently of LED support,
so it can be tested in isolation on boards with and without IRQ
configured.
Patch 3 adds LED triggers that hook into the shared event handling
path introduced by patch 2.
Note: pse_handle_events() and the existing pse_isr() pass notifs_mask
as a single unsigned long, which limits the bitmask to BITS_PER_LONG
PI lines. This is a pre-existing constraint in the IRQ path and is
sufficient for all current PSE controllers (max 48 ports vs 64-bit
unsigned long), but may need to be converted to DECLARE_BITMAP() if
future hardware exceeds this limit.
Changes since v2:
- Based on net-next/main, added net-next subject prefix
- Added --base tree information
- Added CC for devicetree list and DT maintainers
- Collected Reviewed-by from Kory Maincent on patch 1/3
- Fixed build error when CONFIG_LEDS_TRIGGERS is disabled:
moved LED registration before list_add(), removing the
pcdev->pi_led_trigs = NULL assignment on conditionally
compiled struct member (reported by kernel test robot)
- Fixed use-after-free on device unbind: poll work is now
cancelled via devm_add_action_or_reset() to ensure correct
devres teardown ordering (poll_work cancelled before
poll_notifs is freed)
- Used system_freezable_wq for poll worker to prevent hardware
access during system suspend
- Added PoDL power status and admin state checks to LED triggers
so they work for both C33 and PoDL controller types
- Used dev_name(dev) for LED trigger names to ensure uniqueness
across multiple PSE controllers (of_node->name can be generic)
- Added initial LED state query at registration so already-active
ports are reflected immediately
- Added pse_led_update() calls in regulator enable/disable paths
so ethtool admin state changes are reflected in LEDs
- Moved LED trigger registration before list_add() to prevent
race where IRQ/poll could invoke pse_led_update() on partially
initialized triggers
Changes since v1:
- Split single patch into 3 separate patches
- Extracted pse_handle_events() and devm_pse_poll_helper() as a
standalone poll path (patches 1-2), testable without LED code
- Added DT binding for poll-interval-ms as a separate patch
- Renamed led-poll-interval-ms to poll-interval-ms for generic use
- Fire LED triggers from the notification path rather than a
separate poll loop
Tested on Realtek RTL9303 with HS104 PoE chip, poll path only
(without IRQ configured). Verified PD connect/disconnect notifications
and LED trigger state changes.
Link: https://lore.kernel.org/all/20260323201225.1836561-1-github@szelinsky.de/
Link: https://lore.kernel.org/all/20260314235916.2391678-1-github@szelinsky.de/
Carlo Szelinsky (3):
dt-bindings: net: pse-pd: add poll-interval-ms property
net: pse-pd: add devm_pse_poll_helper()
net: pse-pd: add LED trigger support via notification path
.../bindings/net/pse-pd/pse-controller.yaml | 8 +
drivers/net/pse-pd/pse_core.c | 298 ++++++++++++++++--
include/linux/pse-pd/pse.h | 34 ++
3 files changed, 309 insertions(+), 31 deletions(-)
base-commit: ced629dc8e5c51ff2b5d847adeeb1035cd655d58
--
2.43.0