[PATCH v3 05/13] realtek: add switch port LED driver
Alex G.
mr.nuke.me at gmail.com
Mon Oct 31 06:52:35 PDT 2022
On 10/30/22 13:30, Sander Vanheule wrote:
> RTL83xx switch SoCs can control up to 3 LEDs per (non-CPU) switch port,
> typically to display the port link status. This driver allows to address
> these LEDs and provides direct control from userspace, blink offloading,
> and switch port status offloading. On Maple (RTL838x, RTL833x) 3×28 LEDs
> are supported. On Cypress (RTL839x, RTL835x) 3×52 LEDs are supported.
>
> The driver expects a list of devicetree nodes, one per physical LED, or
> LED component in the case of multi-color LEDs. The 'reg' property of
> these nodes has three cells:
> 1. Switch's internal port number (0-27 for Maple, 0-51 for Cypress)
> 2. Port LED index (0-2)
> 3. Port type index (0 for RJ45/primary, 1 for SFP/secondary)
>
> The driver refers to the RJ45 and SFP LEDs as "primary" and "secondary",
> since SFP LED values are always output from the peripheral after RJ45
> LED values. Note that on Maple it is not possible to control these
> secondary LEDs from userspace. Nevertheless, if a combo port has one LED
> per physical medium, both need to be specified in the devicetree.
>
> Since offloading of the generic netdev trigger does not exist (yet),
> this driver provides a private trigger which achieves the same and is
> named "realtek-switchport". Each LED will have a file named
> "rtl_hw_trigger" in /sys/class/leds/$LED, where the requested trigger
> mode can be written to. It should be noted that port status offloading
> is always enabled simultaneously for the primary and secondary LED.
>
> When the custom trigger is activated, the LED will be added to a group
> of LEDs with the same trigger conditions. If it is not possible to add
> the LED to a group, e.g. when the number of control groups is exhausted,
> the user must first choose an already existing trigger condition, or use
> direct LED control.
>
> If an unsupported mode is requested, or the trigger cannot be activated,
> this will be reported to the user via a kernel message and write
> failure.
>
> Some common modes (i.e. values for "rtl_hw_trigger") are:
> - 1G/100M/10M Link present, blink on activity: 1f
> - 100M/10M link, blink on activity: f
> - 1G link present: 10
> - blink on link activity: 3
>
> To document a port LED trigger as specified on the device's front panel,
> the user can specify a u32 "realtek,led-port-trigger" property in the
> DTS, using the helper macros from the dt-bindings header.
>
> /* Port 8, LED index 1, primary LED: Link/Act 1G LED */
> led at 8.1.0 {
> reg = <8 1 0>;
> color = <LED_COLOR_ID_GREEN>;
> function = LED_FUNCTION_LAN
> linux,default-trigger = "realtek-switchport";
> realtek,led-port-trigger = <(RTL_LED_ACT | RTL_LED_LINK_1000)>;
Should be "realtek,port-led-trigger" to match source code.
> };
>
> Signed-off-by: Sander Vanheule <sander at svanheule.net>
Tested-by: Alexandru Gagniuc <mr.nuke.me at gmail.com>
with the devicetree changes at:
https://github.com/mrnuke/openwrt/commits/svanheule-port-drv
Alex
More information about the openwrt-devel
mailing list