linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Murphy <dmurphy@ti.com>
To: Greg KH <gregkh@linuxfoundation.org>, Pavel Machek <pavel@denx.de>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	<linux-leds@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<dmurphy@ti.com>
Subject: Re: [RESEND PATCH v17 00/17] Multi Color LED Framework
Date: Thu, 27 Feb 2020 07:07:17 -0600	[thread overview]
Message-ID: <4c273c06-5024-b2d4-c656-b165015090be@ti.com> (raw)
In-Reply-To: <20200227124329.GA994747@kroah.com>

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

> 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

  reply	other threads:[~2020-02-27 13:12 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-27 15:00 [RESEND PATCH v17 00/17] Multi Color LED Framework Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 01/17] dt-bindings: leds: Add multicolor ID to the color ID list Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 02/17] " Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 03/17] leds: multicolor: Introduce a multicolor class definition Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 04/17] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 05/17] leds: lp50xx: Add the LP50XX family of the RGB LED driver Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 06/17] dt: bindings: lp55xx: Be consistent in the document with LED acronym Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 07/17] dt: bindings: lp55xx: Update binding for Multicolor Framework Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 08/17] ARM: dts: n900: Add reg property to the LP5523 channel node Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 09/17] ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 " Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 10/17] ARM: dts: ste-href: Add reg property to the LP5521 channel nodes Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 11/17] leds: lp55xx: Convert LED class registration to devm_* Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 12/17] leds: lp55xx: Add multicolor framework support to lp55xx Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 13/17] leds: lp5523: Update the lp5523 code to add multicolor brightness function Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 14/17] leds: lp5521: Add multicolor framework multicolor brightness support Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 15/17] leds: lp55xx: Fix checkpatch file permissions issues Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 16/17] leds: lp5523: Fix checkpatch issues in the code Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 17/17] dt: bindings: Update lp55xx binding to recommended LED naming Dan Murphy
2020-02-12 13:09 ` [RESEND PATCH v17 00/17] Multi Color LED Framework Dan Murphy
2020-02-25 10:19   ` Pavel Machek
2020-02-25 22:17     ` Jacek Anaszewski
2020-02-25 22:44       ` Dan Murphy
2020-02-26 12:59       ` Pavel Machek
2020-02-26 20:45         ` Jacek Anaszewski
2020-02-26 22:10           ` Dan Murphy
2020-02-27 10:58           ` Pavel Machek
2020-02-27 12:43             ` Greg KH
2020-02-27 13:07               ` Dan Murphy [this message]
2020-02-27 13:29                 ` Dan Murphy
2020-02-27 21:22                 ` Jacek Anaszewski
2020-02-28  7:42                   ` Greg KH
2020-02-28  9:34                     ` Pavel Machek
2020-02-28 12:30                     ` Dan Murphy
2020-02-28  9:39                   ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4c273c06-5024-b2d4-c656-b165015090be@ti.com \
    --to=dmurphy@ti.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).