From: David Laight <David.Laight@ACULAB.COM>
To: 'Marek Behun' <marek.behun@nic.cz>,
Abanoub Sameh <abanoubsameh8@gmail.com>
Cc: "pavel@ucw.cz" <pavel@ucw.cz>,
"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Abanoub Sameh <abanoubsameh@protonmail.com>,
kernel test robot <lkp@intel.com>
Subject: RE: [PATCH] leds: led-core: Get rid of enum led_brightness
Date: Fri, 11 Dec 2020 14:08:43 +0000 [thread overview]
Message-ID: <2ae41868b2604a489927b5903529afb4@AcuMS.aculab.com> (raw)
In-Reply-To: <20201211135628.1fe1af79@nic.cz>
From: Marek Behun
> Sent: 11 December 2020 12:56
>
> On Fri, 11 Dec 2020 03:48:40 +0200
> Abanoub Sameh <abanoubsameh8@gmail.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)
next prev parent reply other threads:[~2020-12-12 1:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-11 1:48 Abanoub Sameh
2020-12-11 12:56 ` Marek Behun
2020-12-11 14:08 ` David Laight [this message]
2020-12-11 18:31 ` Marek Behun
2020-12-17 22:59 ` Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2020-12-11 20:42 Abanoub Sameh
2021-02-19 10:36 ` Pavel Machek
2020-12-10 13:49 Abanoub Sameh
2020-12-10 20:03 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2ae41868b2604a489927b5903529afb4@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=abanoubsameh8@gmail.com \
--cc=abanoubsameh@protonmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=lkp@intel.com \
--cc=marek.behun@nic.cz \
--cc=pavel@ucw.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®