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
