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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Greg

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.

Series:

https://lore.kernel.org/patchwork/project/lkml/list/?series=427513

ABI Documentation and support code:

https://lore.kernel.org/patchwork/patch/1186194/

Dan

thanks,

greg k-h



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux