linux-kernel - Re: [PATCH v11 04/16] leds: multicolor: Introduce a multicolor class definition

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: <d6b68a79-235a-0a9b-bbf3-519571646eff@ti.com>
Date:   Wed, 9 Oct 2019 15:44:20 -0500
From:   Dan Murphy <dmurphy@...com>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
CC:     Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Pavel Machek <pavel@....cz>,
        Linux LED Subsystem <linux-leds@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v11 04/16] leds: multicolor: Introduce a multicolor class
 definition

Bjorn

On 10/9/19 3:11 PM, Bjorn Andersson wrote:
> On Tue, Oct 8, 2019 at 1:49 PM Dan Murphy <dmurphy@...com> wrote:
>> Introduce a multicolor class that groups colored LEDs
>> within a LED node.
>>
>> The multi color class groups monochrome LEDs and allows controlling two
>> aspects of the final combined color: hue and lightness. The former is
>> controlled via <color>_intensity files and the latter is controlled
>> via brightness file.
>>
> Thanks for making progress on this, it's been the one outstanding
> question mark for the long overdue respin of the Qualcomm LPG driver.

> But while it works for the LPG, in that it has outputs named "RGB" I
> have boards with "generic" LED drivers that are connected to RGB LEDs.
> So per your proposed solution we would need to add the additional

You don't have to add the MC class to those drivers.  This is an 
optional framework but if you wanted to use the framework for specific 
devices then yes you would need to add that support. This is why I did 
the LP55xx patches to demonstrate the feasibility since the LP50xx has 
the MC class intelligence already.

The LP55xx driver can register to the LED class and/or the MC LED class 
pending on the DT organization.

I don't plan on going through all of TI's RGB drivers and retrofitting 
them to the MC class.  I do have to update the GPIO LED driver to use 
the class but that work is still pending.

I may also update the Motorola PCAP driver as well since I have a Droid4 
to test.

> mc_class handling to every single LED driver that might be used to
> sink current into an RGB LED.
>
> I also don't see anything preventing hardware designers from feeding
> single RGB LEDs from multiple different LED controllers, something the
> current proposal would prohibit.

What do you mean by a single RGB LED? Are you referring to a RGB module?

http://wiki.sunfounder.cc/index.php?title=RGB_LED_Module

There is no prevention for HW designers to put a driver on each LED 
output but I am not sure why they would incur

the additional BOM cost seems quite silly unless you have an unlimited 
budget ;)

If they did design the system that way then the SW would need to revert 
back to the standard LED class as it is done today.

Dan