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]

Message-ID: <20200225101940.GB16252@amd>
Date:   Tue, 25 Feb 2020 11:19:40 +0100
From:   Pavel Machek <pavel@....cz>
To:     Dan Murphy <dmurphy@...com>
Cc:     jacek.anaszewski@...il.com, linux-leds@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RESEND PATCH v17 00/17] Multi Color LED Framework

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), 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

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,

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)