linux-kernel - Re: [PATCH net-next + leds v2 2/7] leds: add generic API for LEDs that can be controlled by hardware

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 9 Sep 2020 11:43:28 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Marek Behún <marek.behun@....cz>
Cc:     netdev@...r.kernel.org, linux-leds@...r.kernel.org,
        Pavel Machek <pavel@....cz>, Dan Murphy <dmurphy@...com>,
        Ondřej Jirman <megous@...ous.com>,
        Russell King <linux@...linux.org.uk>,
        Andrew Lunn <andrew@...n.ch>, linux-kernel@...r.kernel.org,
        Matthias Schiffer <matthias.schiffer@...tq-group.com>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net-next + leds v2 2/7] leds: add generic API for LEDs
 that can be controlled by hardware

On 9/9/20 11:31 AM, Marek Behún wrote:
> On Wed, 9 Sep 2020 11:20:00 -0700
> Randy Dunlap <rdunlap@...radead.org> wrote:
> 
>> Hi,
>>
>> On 9/9/20 9:25 AM, Marek Behún wrote:
>>> Many an ethernet PHY (and other chips) supports various HW control
>>> modes for LEDs connected directly to them.
>>>
>>> This patch adds a generic API for registering such LEDs when
>>> described in device tree. This API also exposes generic way to
>>> select between these hardware control modes.
>>>
>>> This API registers a new private LED trigger called dev-hw-mode.
>>> When this trigger is enabled for a LED, the various HW control
>>> modes which are supported by the device for given LED can be
>>> get/set via hw_mode sysfs file.
>>>
>>> Signed-off-by: Marek Behún <marek.behun@....cz>
>>> ---
>>>  .../sysfs-class-led-trigger-dev-hw-mode       |   8 +
>>>  drivers/leds/Kconfig                          |  10 +
>>>  drivers/leds/Makefile                         |   1 +
>>>  drivers/leds/leds-hw-controlled.c             | 227
>>> ++++++++++++++++++ include/linux/leds-hw-controlled.h            |
>>> 74 ++++++ 5 files changed, 320 insertions(+)
>>>  create mode 100644
>>> Documentation/ABI/testing/sysfs-class-led-trigger-dev-hw-mode
>>> create mode 100644 drivers/leds/leds-hw-controlled.c create mode
>>> 100644 include/linux/leds-hw-controlled.h 
>>
>>> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
>>> index 1c181df24eae4..5e47ab21aafb4 100644
>>> --- a/drivers/leds/Kconfig
>>> +++ b/drivers/leds/Kconfig
>>> @@ -49,6 +49,16 @@ config LEDS_BRIGHTNESS_HW_CHANGED
>>>  
>>>  	  See Documentation/ABI/testing/sysfs-class-led for
>>> details. 
>>> +config LEDS_HW_CONTROLLED
>>> +	bool "API for LEDs that can be controlled by hardware"
>>> +	depends on LEDS_CLASS  
>>
>> 	depends on OF || COMPILE_TEST
>> ?
>>
> 
> I specifically did not add OF dependency so that this can be also used
> on non-OF systems. A device driver may register such LED itself...
> That's why hw_controlled_led_brightness_set symbol is exported.
> 
> Do you think I shouldn't do it?

I have no problem with it as it is.

>>> +	select LEDS_TRIGGERS
>>> +	help
>>> +	  This option enables support for a generic API via which
>>> other drivers
>>> +	  can register LEDs that can be put into hardware
>>> controlled mode, eg.  

thanks.
-- 
~Randy