[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53a0af43-abaf-5936-9e23-3c7e71c3e10a@ti.com>
Date: Thu, 27 Feb 2020 07:29:22 -0600
From: Dan Murphy <dmurphy@...com>
To: Pavel Machek <pavel@...x.de>, <dmurphy@...com>
CC: Jacek Anaszewski <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
Removing GKH
On 2/27/20 7:07 AM, Dan Murphy wrote:
> Pavel
>
> 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.
>
> Dan
>
The more I think about my above statement it is actually worse to do the
arrays. What checks will we have to implement that the DT won't define
an array like this
[red green blue white red green white IR blue yellow]
This array is unbounded at this point. The sysfs framework will not
allow creating files under the directory with the same name so we can
bound this to 1 LED color to a file and there will be no duplicates.
Sure we can NACK DT's that do create unbounded color arrays but that
means we would have to review every DT file that would add a LED node.
What is expected and what is exposed as capability are two different things.
We don't expect developers to have more then 5 channels but if given the
capabilities of doing it eventually it will be done and the framework
will break.
Dan
Powered by blists - more mailing lists