On Mon, Jul 19, 2021 at 9:18 AM Geert Uytterhoeven [off-list ref] wrote:

On Thu, 15 Jul 2021, Amy Parker wrote:

quoted

This commit changes how led_brightness, declared in header file
include/linux/leds.h, works throughout the kernel, and updates other
files in accordance.

The TODO located at drivers/leds/TODO requests:

* Get rid of led_brightness

It is really an integer, as maximum is configurable. Get rid of it, or
make it into typedef or something.

This patch changes the declaration of led_brightness from an enum to a
typedef. In order to hold the currently existing enum values, macro
definitions are provided. Files which use led_brightness are updated to
conform to the new types.

Signed-off-by: Amy Parker <redacted>

Thanks for your patch!

quoted

207 files changed, 437 insertions(+), 438 deletions(-)

This touches a lot of files, so we better get it right.

quoted

--- a/include/linux/leds.h
+++ b/include/linux/leds.h

@@ -26,12 +26,11 @@ struct device_node;
 */

/* This is obsolete/useless. We now support variable maximum brightness. */
-enum led_brightness {
-     LED_OFF         = 0,
-     LED_ON          = 1,
-     LED_HALF        = 127,
-     LED_FULL        = 255,
-};
+typedef u8 led_brightness;

In general, typedefs are frowned upon in the kernel, but there can be a
good reason to use one.
What if the maximum brightness is larger than 255?
Using "unsigned int" sounds better to me, but let's wait for Pavel...

And as Dan just pointed out, "signed int" would be even better, as it
would allow a function to return an error code.

quoted

+#define LED_OFF 0
+#define LED_ON 1
+#define LED_HALF 127
+#define LED_FULL 255

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds