[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