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]

Date:   Fri, 25 May 2018 00:08:23 +0200
From:   Tomas Hlavacek <tomas.hlavacek@....cz>
To:     Uwe Kleine-König <uwe@...ine-koenig.org>
Cc:     Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org
Subject: Re: led: hw-trigger, global brightness and multi-colored leds

Hi!

On Wed, May 2, 2018 at 5:11 PM, Uwe Kleine-König <uwe@...ine-koenig.org> wrote:
> Hello,
>
> on the Turris Omnia[1] the LEDs are controllable via an i2c device.
...
> Now I wonder how to match these two features to the LED device model. Do
> you have an idea?

That is an interesting question - I was quite clueless about that two
years ago - when I wrote the driver for Omnia LEDs
(https://github.com/tmshlvck/omnia-linux/blob/omnia/drivers/leds/leds-omnia.c).
I didn't even made an attempt to send it to upstream because it
obviously does not fit to the LED device model.

The fundamental problems were:

1) Sending commands over I2C to the MCU that drives LEDs is quite
slow. Therefore the interface is optimized for doing incremental
changes and batch changes. (Btw. the protocol description is here
https://gitlab.labs.nic.cz/hw/omnia_hw_ctrl/blob/master/turris_omnia_i2c_desc.adoc
).

2) "native" or autonomous mode means that MCU that drives LEDs take
independently wired (on/off) input from switch, PHY or PCI cards
without any kernel interaction, but color settings and brightness for
each individual LED are still active, just the on/off/blink trigger is
autonomous.

3) There is a global brightness (autonomous PWM control for cathode of
all LEDs - the best method for LED dimming, running on few MHz).

4) Per-LED brightness works, however PWM is running on just few
hundreds of kHz and when all LEDs are dimmed and you watch carefully,
you can see intermittent flickering.

5) The abstraction in the protocol (mentioned in (1)) is actually
counting 3 LEDs (separate RGB) as one arbitrary-color LED. The reason
was to save bandwidth on I2C I guess, because color is expected to
change less frequently than brightness.

But I also have good news: The FW of the MCU is also OSS (see the repo
in the link (1)). There is a method for flashing the MCU over I2C from
Linux and there is JTAG connector for the MCU, in case un-bricking is
needed. Therefore the LED protocol can be changed to be more sensible
and/or it is even possible to emulate some existing HW LED driver chip
in Omnia MCU and reuse OSS driver for that chip.

Tomas