linux-kernel - RE: [PATCH] leds: led-core: Get rid of enum led

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:   Fri, 11 Dec 2020 14:08:43 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Marek Behun' <marek.behun@....cz>,
        Abanoub Sameh <abanoubsameh8@...il.com>
CC:     "pavel@....cz" <pavel@....cz>,
        "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Abanoub Sameh <abanoubsameh@...tonmail.com>,
        kernel test robot <lkp@...el.com>
Subject: RE: [PATCH] leds: led-core: Get rid of enum led_brightness

From: Marek Behun
> Sent: 11 December 2020 12:56
> 
> On Fri, 11 Dec 2020 03:48:40 +0200
> Abanoub Sameh <abanoubsameh8@...il.com> wrote:
> 
> > This gets rid of enum led_brightness in the main led files,
> > because it is deprecated, and an int can be used instead,
> > or maybe even a uint8_t since it only goes up to 255.
> > Next we can also patch the other files to get rid of it completely.
> 
> 1. unsigned int should be used IMO
>   - using int may force all implementers to check for negative value
>     and return -EINVAL, which is stupid
>   - some LED controllers may offer more than 8bit brightness value, so
>     no uint8_t

More than 8 bits would be good.
While not really relevant for actual 'brightness' it allows
for 'strange' things be encoded in the brightness field.

For instance we have some hardware that has RGB leds on it.
They are a single device so it really needs a colour property.
But it is more complex than that, between the driver and LED
there is an FPGA - so it can modulate the LED output in many ways.
As well as using PWM to change the brightness and (eg) 1/2HZ flashing
it is possible to alternate between red and green to get a reasonable
orange (works better than driving both at the same time!).

There is also the option of making the led follow some internal
signal rather then be directly driven by the driver.

While extra parameters could be added, they are only really usable
by code that knows they are present.
So encoding in the 'brightness' sort of makes sense.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)