[lkml]   [2020]   [Feb]   [28]   [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/28/20 1:42 AM, Greg KH wrote:
> On Thu, Feb 27, 2020 at 10:22:43PM +0100, Jacek Anaszewski wrote:
>> On 2/27/20 2:07 PM, Dan Murphy wrote:
>>> <snip>
>>> 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.
>> I believe that some of mechanisms that were devised for the most
>> recent implementation proposal of LED mc class will need
>> to be reused for the array approach. E.g. available_colors bitmask
>> will make the parsing resistant to duplicates.
>> Of course LED multicolor DT node design should be applicable as well
>> to the array approach.
>>>> Writing 3 or 4 or 5 numbers all at once in a single sysfs file to
>>>> represent a single output should be fine.
>>>> thanks,
>> Thank you for making this clear.
>> Effectively, the way to go as I see it now is just moving from
>> colors directory to channel_intensity and channel_names files.
> Wait, we already have an interface for this and you want to create a
> competing one? Why? What's wrong with what you have now?
> Do you have a pointer to the Documentation/ABI/ entries that you have
> now that you feel do not work well?

Here is the proposal we have been working on for some time.


ABI Documentation and support code:


> thanks,
> greg k-h

 \ /
  Last update: 2020-02-28 13:36    [W:0.076 / U:2.936 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site