From: Pavel Machek <pavel@denx.de>
To: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>, Dan Murphy <dmurphy@ti.com>,
linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RESEND PATCH v17 00/17] Multi Color LED Framework
Date: Thu, 27 Feb 2020 11:58:08 +0100 [thread overview]
Message-ID: <20200227105808.GA27003@duo.ucw.cz> (raw)
In-Reply-To: <20f6bdd5-e899-aead-8c35-1c3a3d09145f@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]
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.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2020-02-27 10:58 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 [this message]
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
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=20200227105808.GA27003@duo.ucw.cz \
--to=pavel@denx.de \
--cc=dmurphy@ti.com \
--cc=gregkh@linuxfoundation.org \
--cc=jacek.anaszewski@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
/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).