linux-kernel - Re: [PATCH v2 2/3] leds: upboard: Add LED support

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:   Wed, 24 Oct 2018 22:07:30 +0200
From:   Jacek Anaszewski <jacek.anaszewski@...il.com>
To:     Pavel Machek <pavel@....cz>
Cc:     Dan O'Donovan <dan@...tex.com>, linux-kernel@...r.kernel.org,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Lee Jones <lee.jones@...aro.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-gpio@...r.kernel.org, linux-leds@...r.kernel.org,
        Carlos Iglesias <carlos.iglesias@...tex.com>,
        Javier Arteaga <javier@...tex.com>
Subject: Re: [PATCH v2 2/3] leds: upboard: Add LED support

On 10/23/2018 09:30 PM, Pavel Machek wrote:
> On Tue 2018-10-23 21:09:54, Jacek Anaszewski wrote:
>> On 10/23/2018 08:54 PM, Pavel Machek wrote:
>>> Hi!
>>>
>>>>> +	led->field = devm_regmap_field_alloc(dev, regmap, conf);
>>>>> +	if (IS_ERR(led->field))
>>>>> +		return PTR_ERR(led->field);
>>>>> +
>>>>> +	led->cdev.max_brightness = 1;
>>>>
>>>> s/1/LED_ON/
>>>
>>> Actually, I prefer constant 1 here, as it makes it immediately obvious
>>> this supports just 0/1.
>>>
>>> Yes, LED_ON is also 1, but I had to grep the header files for
>>> that... (I thought it was 255).
>>
>> If we have the enum for that, let's use it.
>> Here's the commit message of the patch adding LED_ON - it should
>> be somehow familiar to you - see the ack.
> 
> Well .. brightness = LED_ON; is good usage. max_brightness = LED_ON is
> IMO less readable than max_brightness = 1.
> 
> Looking at situation again... Having LED_ON and LED_FULL, with some
> leds having max brightness of 1023, so LED_FULL is not really full
> brightness any more... Maybe it is time to get rid of the enum, and
> make it plain int. It does not really enumarate anything, and it does
> not help readability, either.

I agree that it introduces confusion.

Yet, there are many out of LED subsystem files to update:

find -name "*.c" -o -name "*.h" | xargs grep  "enum led_brightness" |
awk -F: '{print $1}' | sort -u | grep -v "leds" | wc -l

returns 87.

>> commit 4e552c8cb5bc9137e67e035bab8df6dddbca7384
>> Author: Andi Shyti <andi.shyti@...sung.com>
>> Date:   Thu Jan 5 11:34:12 2017 +0900
>>
>>     leds: add LED_ON brightness as boolean value
>>
>>     Some devices do not handle the led brightness or simply don't
>>     care about it. Conceptually said devices want to just switch on
>>     or off the led. It is useless in this case to have a 255 range
>>     of brightness, while just having an LED_ON and LED_OFF improves
>>     the boolean meaning of the led status.
>>
>>     Signed-off-by: Andi Shyti <andi.shyti@...sung.com>
>>     Acked-by: Pavel Machek <pavel@....cz>
>>     Signed-off-by: Jacek Anaszewski <jacek.anaszewski@...il.com>
>>
>>
> 

-- 
Best regards,
Jacek Anaszewski