linux-kernel - Re: [PATCH] LEDs: allow led-drivers to use a wider than 0...255 range of brightness values

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:	Tue, 25 Nov 2008 16:02:41 -0200
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Guennadi Liakhovetski <lg@...x.de>
Cc:	rpurdie@...ys.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] LEDs: allow led-drivers to use a wider than 0...255
	range of brightness values

On Tue, 25 Nov 2008, Guennadi Liakhovetski wrote:
> This patch allows drivers to override the default maximum brightness value of
> 255. We take care to preserve backwards-compatibility, so that user-space
> ABI doesn't change for existing drivers. All existing drivers have been verified
> to use a zero-initialised memory for their struct led_classdev objects, so that
> they will get the default maximum value of 255. New user-space software 
> can use a new read-only sysfs file /sys/class/leds/*/max_brightness to 
> retrieve maximum supported brightness of a specific LED.

I am not speaking AGAINST this change, I actually like the idea, especially
if we can set max_brightness to 1 and support binary (on/off) leds in a much
easier way :p

However, you must be aware that it IS still an ABI and API change.  Generic
LED drivers and triggers expect the [0, 255] scale, and expect 0 and 255 to
have special meanings (LED_OFF and LED_FULL).

I'd suggest that you set the new max_brightness field PROPERLY for all LEDs
(i.e. set it to 255), and fix all of the LED trigger code to use
max_brightness when it wants LED_FULL.

In fact, LED_FULL probably will need to become a function (inlineable), so
that triggers can just call led_set_to_max_brightness(theled), or
whatever...

That would still leave us with non-updated userspace not doing the right
thing when faced with a led with a range different from [0, 255], but there is
probably not a big set of userland doing generic LED control (and specific
LEDs have no reason to change their range from the default [0, 255]).

Either that, or maybe you could use an alternative way, like adding a
fractional component to the scale (which has its own problems, but it
probably can be done cleanly).  In that case, it is best to also add an
attribute to disclose the granularity supported by the LED driver.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/