Linux-LEDs Archive on lore.kernel.org
 help / color / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Dan Murphy <dmurphy@ti.com>, Pavel Machek <pavel@denx.de>,
	linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RESEND PATCH v17 00/17] Multi Color LED Framework
Date: Fri, 28 Feb 2020 08:42:35 +0100
Message-ID: <20200228074235.GA2900429@kroah.com> (raw)
In-Reply-To: <96a31ff6-5ecf-05a7-d61f-2804f2488d1b@gmail.com>

On Thu, Feb 27, 2020 at 10:22:43PM +0100, Jacek Anaszewski wrote:
> On 2/27/20 2:07 PM, 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.
> 
> 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?

thanks,

greg k-h

  reply index

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-27 15:00 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
2020-02-27 13:29                 ` Dan Murphy
2020-02-27 21:22                 ` Jacek Anaszewski
2020-02-28  7:42                   ` Greg KH [this message]
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=20200228074235.GA2900429@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=dmurphy@ti.com \
    --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

Linux-LEDs Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-leds/0 linux-leds/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-leds linux-leds/ https://lore.kernel.org/linux-leds \
		linux-leds@vger.kernel.org
	public-inbox-index linux-leds

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-leds


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git