[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 Nov 2021 18:24:05 -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: [RFC PATCH v4 1/8] leds: add support for hardware driven LEDs
On 11/10/21 5:34 PM, Ansuel Smith wrote:
> diff --git a/Documentation/leds/leds-class.rst b/Documentation/leds/leds-class.rst
> index cd155ead8703..0175954717a3 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 a LED connected to
an LED
> +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 bit and fail to activate if the control mode
bits
> +is not supported. By default if a LED driver doesn't declare a control mode,
> +bit LED_SOFTWARE_CONTROLLED is assumed and set by default.
drop the second: by default
> +
> +The LED must implement 3 main API:
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
> + enforcerd and putting the LED off is also accepted.
enforced
> +
> +If LED_HARDWARE_CONTROLLED bit is the only contro mode set (LED_SOFTWARE_CONTROLLED
control
> +not set) set hw_control_status/start/stop is optional as the LED supports only
> +hardware mode and any software only trigger will reject activation.
> +
> +On init a LED driver that support a hardware mode should reset every blink mode
an LED
> +set by default.
>
> Known Issues
> ============
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index ed800f5da7d8..bd2b19cc77ec 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -49,6 +49,17 @@ config LEDS_BRIGHTNESS_HW_CHANGED
>
> See Documentation/ABI/testing/sysfs-class-led for details.
>
> +config LEDS_HARDWARE_CONTROL
> + bool "LED Hardware Control support"
> + help
> + This option enabled Hardware control support used by leds that
enables LEDs
> + can be driven in hardware by using supported triggers.
> +
> + Hardware blink modes will be exposed by sysfs class in
> + /sys/class/leds based on the trigger currently active.
> +
> + If unsure, say Y.
--
~Randy
Powered by blists - more mailing lists