linux-kernel - Re: [PATCH v2 1/2] leds: ktd20xx: Add the KTD20xx family of the RGB LEDs driver from Kinetic

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] [day] [month] [year] [list]

Message-ID: <350ab383a3a40439c73a2769b9034ec6@dev.tdt.de>
Date:   Mon, 20 Dec 2021 09:01:49 +0100
From:   Florian Eckert <fe@....tdt.de>
To:     Pavel Machek <pavel@....cz>
Cc:     robh+dt@...nel.org, linux-kernel@...r.kernel.org,
        linux-leds@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 1/2] leds: ktd20xx: Add the KTD20xx family of the RGB
 LEDs driver from Kinetic

Hello Pavel,

thanks for your reply.

>> Variant 1:
>> The device has the ability to group LED outputs into two banks so that
>> the two LED banks can be controlled with the same color. This could 
>> not
>> be done via the LEDs 'sysfs' entry because of the limitation on the 
>> color
>> register count. The color of the two banks can be configured via 
>> device
>> 'sysfs' entry for all LEDs at once [current_color0|current_color1].
>> Which color the LED is to be used can be set via the 'sysfs' of the
>> individual LEDs via the 'multi_intensity' file. Valid values for the
>> colors (RGB) are 0 | 1. The value 0 selects the color register 0 and 
>> the
>> value 1 selects the color register 1.
>> 
>> Variant 2:
>> The device can also set the LED color independently. Since the chip 
>> only
>> has two color registers, but we want to control the 12 LEDs
>> independently via the 'led-class-multicolour' sysfs entry,
>> the full RGB color depth cannot be used. Due to this limitation, only 
>> 7
>> colors and the color black (off) can be set. To use this mode the 
>> color
>> registers must be preset via the device tree or the device 'sysfs'. 
>> The
>> color registers 0 must be preset with 0x00 (Red=0x00 Green=0x00 
>> Blue=0x00).
>> The color register1 should be preset all with the same value. This 
>> value
>> depends on which light intensity is to be used in the setup.
> 
> Summary: some crazy hardware.

I agree with you completely.
But there was no other hardware to choose it was already on the board.

> 
>> +static ssize_t current_color0_store(struct device *dev,
>> +		struct device_attribute *a,
>> +		const char *buf, size_t size)
>> +{
> 
> And now we have custom interface. Undocumented.

I just wanted to implement all possibilities features for the chip and
not commit to one. It may be that someone else can use the hardware for
something else. If that is the problem, then I can document that.

> That is not acceptable, sorry.
> Find a way to squeeze it into current RGB framework, perhaps with
> reduced feature set.

Ok I'll try and focus on variant 2.

> AFAICT you could either pretend it is 2-LED driver with full 8bit RGB
> on each, or you could pretend it is 12-LED driver with 1bit
> RGB. Select one and implement that.

On my board the LED driver is used for 12 LEDs and 1bit RGB colour 
depth.
So I could select 7 colors and (off).
For my understanding, does this mean that I remove variant 1 from the
source and send a v3 patchset? Or do I have to take anything else into
account when I use variant 2 now?

 From my point of view, the driver should fit if I remove variant 1?

Best regards

Florian