netdev - Re: [PATCH v5 1/8] leds: add support for hardware driven LEDs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 12 Nov 2021 17:04:20 -0800
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Ansuel Smith <ansuelsmth@...il.com>, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Jonathan Corbet <corbet@....net>, Pavel Machek <pavel@....cz>,
        John Crispin <john@...ozen.org>, netdev@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-leds@...r.kernel.org,
        Marek Behún <kabel@...nel.org>
Subject: Re: [PATCH v5 1/8] leds: add support for hardware driven LEDs

On 11/12/21 7:35 AM, Ansuel Smith wrote:
> diff --git a/Documentation/leds/leds-class.rst b/Documentation/leds/leds-class.rst
> index cd155ead8703..e5d266919a19 100644
> --- a/Documentation/leds/leds-class.rst
> +++ b/Documentation/leds/leds-class.rst
> @@ -169,6 +169,38 @@ Setting the brightness to zero with brightness_set() callback function
>   should completely turn off the LED and cancel the previously programmed
>   hardware blinking function, if any.
>   
> +Hardware driven LEDs
> +===================================
> +
> +Some LEDs can be driven by hardware (for example an LED connected to
> +an ethernet PHY or an ethernet switch can be configured to blink on activity on
> +the network, which in software is done by the netdev trigger).
> +
> +To do such offloading, LED driver must support this and a supported trigger must
> +be used.
> +
> +LED driver should declare the correct control mode supported and should set
> +the LED_SOFTWARE_CONTROLLED or LED_HARDWARE_CONTROLLED bit in the flags
> +parameter.
> +The trigger will check these bits and fail to activate if the control mode
> +is not supported. By default if a LED driver doesn't declare a control mode,

                                 if an LED driver

> +bit LED_SOFTWARE_CONTROLLED is assumed and set.
> +
> +The LED must implement 3 main APIs:
> +- hw_control_status(): This asks the LED driver if hardware mode is enabled
> +    or not.
> +- hw_control_start(): This will simply enable the hardware mode for the LED
> +    and the LED driver should reset any active blink_mode.
> +- hw_control_stop(): This will simply disable the hardware mode for the LED.
> +    It's advised to the driver to put the LED in the old state but this is not
> +    enforced and putting the LED off is also accepted.
> +
> +If LED_HARDWARE_CONTROLLED bit is the only control mode set (LED_SOFTWARE_CONTROLLED
> +not set) set hw_control_status/start/stop is optional as the LED supports only

             ^^^ is that an extra "set"?  I can't quite read this sentence.

And it would be better with a comma added, like so:

   not set),


> +hardware mode and any software only trigger will reject activation.

                          software-only

> +
> +On init an LED driver that support a hardware mode should reset every blink mode

                               supports

> +set by default.


-- 
~Randy