[lkml]   [2020]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RESEND PATCH v17 00/17] Multi Color LED Framework

On 2/27/20 6:43 AM, Greg KH wrote:
> On Thu, Feb 27, 2020 at 11:58:08AM +0100, Pavel Machek wrote:
>> Hi, Jacek!
>> (and thanks for doing this).
>>> We have here long lasting discussion related to LED multicolor class
>>> sysfs interface design. We went through several iterations and worked
>>> out the solution with individual file per each color sub-LED in the
>>> color directory as shown below:
>>> /sys/class/leds/<led>/colors/<color>_intensity
>>> This is in line with one-value-per-file sysfs rule, that is being
>>> frequently highlighted, and we even had not so long ago a patch
>>> for led cpu trigger solving the problem caused by this rule not
>>> being adhered to.
>> Yep. One of the problems is that it is nice to change all the hardware
>> channels at once to produce color (it is often on i2c -- and slow), so
>> current proposals use "interesting" kind of latching.
>>> Now we have the voice below bringing to attention another caveat
>>> from sysfs documentation:
>>> "it is socially acceptable to express an array of values of the same
>>> type"
>>> and proposing the interface in the form of two files:
>>> channel_intensity (file containing array of u32's)
>>> channel_names (usually containing "red green blue")
>> And thus I want to have it in one file, so it is naturaly atomic. RGB
>> leds with 3 channels are common; I have not user yet, but there are
>> RGBW with 4 channels (and some more exotic stuff). I don't expect to
>> have more than 5 channels.

This is not an accurate statement.  Right now a user can have up to 8
channels to cover all the LEDs defined in the LED core

And if the led_colors array expands then this array can expand.

We have no control on how many entries the user will put in their DT so
again this number is completely arbitrary.


> Writing 3 or 4 or 5 numbers all at once in a single sysfs file to
> represent a single output should be fine.
> thanks,
> greg k-h

 \ /
  Last update: 2020-02-27 14:12    [W:0.099 / U:1.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site