linux-kernel - Re: led: hw-trigger, global brightness and multi-colored leds

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]

Message-ID: <4b8da1c0-60a6-e19c-379d-9649036c9ba4@gmail.com>
Date:   Thu, 3 May 2018 23:14:17 +0200
From:   Jacek Anaszewski <jacek.anaszewski@...il.com>
To:     Uwe Kleine-König <uwe@...ine-koenig.org>,
        Pavel Machek <pavel@....cz>
Cc:     linux-kernel@...r.kernel.org,
        Tomas Hlavacek <tomas.hlavacek@....cz>
Subject: Re: led: hw-trigger, global brightness and multi-colored leds

Hi Uwe and Pavel,

On 05/03/2018 08:49 PM, Uwe Kleine-König wrote:
> Hello Pavel,
> 
> On 05/02/2018 11:21 PM, Pavel Machek wrote:
>>> on the Turris Omnia[1] the LEDs are controllable via an i2c device. Each
>>> LED can be either in "manual mode" or in a mode I'd call "native mode"
>>> which is the default. In this native mode the LED being on or off
>>> depends on an input line that is controlled by another hardware. So a
>>> LED signals for example activity on the WAN ethernet port without any
>>> software intervention, but can be used as a normal LED, too, when in
>>> "manual mode" where it can be switched on and off by a register
>>> write.
>>
>> "Native mode" is quite common. We have it for example on Nokia N900
>> here (charger has hw option to automatically control the LED).
> 
> git grep -i n900 -- drivers/leds doesn't yield any output. Do I miss
> anything?
> 
>> I believe reasonable solution would be to have "hardware" trigger, and
>> have it selected by default. When active, LED would be controlled by
>> hardware.

The question is whether there is a way for a driver to tell whether
the device is in the manual or in the native mode. If yes,
then we could just return -EBUSY on any attempt of brightness setting
when in the native mode.

Also, if it is possible to detect brightness changes originating
from hardware, then we have an optional brightness_hw_changed sysfs
file supporting POLLPRI events
(compare drivers/platform/x86/thinkpad_acpi.c).

If we can't tell whether the LED is in native or manual mode,
but it is possible to read the current brightness from a register, then
implementing brightness_get op will allow to detect it indirectly (to
some extent since we cannot guarantee that brightness is not changed
by another process).

In each case I'd rather not use trigger mechanism here, which is
defined as __kernel__ based source of LED events.

> There is no prior art for that available as source code, right?
> 
>>> Another feature of the LED device is that there is a global brightness
>>> register that influences all LED's brightness (if on) independent of the
>>> operating mode.
>>
>> We can't describe that easily.
> 
> Given that I can give an RGB value (i.e. 3x 8 bit) for the LED, I can
> change brightness per LED. Have to play around a bit.
> 
>>> Further the color of each LED can be set to an RGB triplet.
>>
>> We normally handle RGB LED as three independend LEDs, like
>> notify::red, notify::green, notify::blue. Again, example is Nokia N900
>> or Motorola Droid 4.
> 
> I cannot find source code for LEDs on the Droid 4 either.
> 
> An ugly property here is that the hardware trigger only operates on all
> three colors at once. Hmm, will think a bit about the way to go.
> 
> Best regards and thanks for your input,
> Uwe
> 

-- 
Best regards,
Jacek Anaszewski