linux-kernel - Re: [RESEND PATCH v17 00/17] Multi Color LED Framework

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 Feb 2020 23:17:21 +0100
From:   Jacek Anaszewski <jacek.anaszewski@...il.com>
To:     Pavel Machek <pavel@....cz>, Dan Murphy <dmurphy@...com>
Cc:     linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RESEND PATCH v17 00/17] Multi Color LED Framework

On 2/25/20 11:19 AM, Pavel Machek wrote:
> Hi!
> 
>>>   leds: lp5521: Add multicolor framework multicolor brightness support
>>>   leds: lp55xx: Fix checkpatch file permissions issues
>>>   leds: lp5523: Fix checkpatch issues in the code
>>>   dt: bindings: Update lp55xx binding to recommended LED naming
>>
>> I have no open comments on this patchset except for a DT change requested by
>> Shawn Gao but this change should wait till after this patchset is merged.
>>
>> Is there something holding this up?
> 
> Yes... my time; sorry about that.
> 
> The fact that it changes API makes it important to get it right, and
> hard/impossible to fix it once it is merged... and I don't think this
> is the right interface (sorry).
> 
> In particular, I don't think having directory per channel is a good
> idea. It makes atomic updates impossible (minor), 

It is possible via brightness file, although it will need first writing
intensity files, which only will cache colors, and actual write to hw
occurs on write to brightness file. This has been discussed dozen of
times throughout last year, and you even proposed the formula for
calculating per-color-subled brightness basing on global brightness and
intensity set for each color.

> but will also
> increase memory consuption (to a point where led-per-channel might
> be cheaper), and will make userspace do 3x ammount of syscalls in the
> common case.
> 
> And we can do better; sysfs files with arrays are okay. So I'd like to
> see

Let's first achieve broader consensus on this statement before we
move forward with such design. Sysfs maintainer seems to be the best
person to consult at first.

> channel_intensity (file containing array of u32's)
> 
> channel_names (usually containing "red green blue")

> (I'm not sure if max_intensity is good idea; i believe we could simply
> fix it to UINT32_MAX without bad effects).
> 
> And yes, I realize I should have spoken up sooner / more
> forcefully. Sorry again.

-- 
Best regards,
Jacek Anaszewski