Linux-LEDs Archive on lore.kernel.org
 help / color / Atom feed
From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Pavel Machek <pavel@ucw.cz>, 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: Wed, 26 Feb 2020 21:45:54 +0100
Message-ID: <20f6bdd5-e899-aead-8c35-1c3a3d09145f@gmail.com> (raw)
In-Reply-To: <20200226125903.GA2800@duo.ucw.cz>

Hi Greg,

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.

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")

In order to have this clarified once and for all, could you please
provide us with guidance on whether the fragment from
Documentation/filesystems/sysfs.txt is still in force and we
can benefit from it for LED multicolor framework, or not and then
it should be removed from the doc then?

Best regards,
Jacek Anaszewski

On 2/26/20 1:59 PM, Pavel Machek wrote:
> Hi!
> 
>>> The fact that it changes API makes it important to get it right, and
>>> hard/impossible to fix it once it is merged... and I don't think this
>>> is the right interface (sorry).
>>>
>>> In particular, I don't think having directory per channel is a good
>>> idea. It makes atomic updates impossible (minor), 
>>
>> It is possible via brightness file, although it will need first writing
>> intensity files, which only will cache colors, and actual write to hw
>> occurs on write to brightness file. This has been discussed dozen of
>> times throughout last year, and you even proposed the formula for
>> calculating per-color-subled brightness basing on global brightness and
>> intensity set for each color.
> 
> You are right, it is possible to make updates atomic with right kind
> of latching (which is quite confusing).
> 
>>> but will also
>>> increase memory consuption (to a point where led-per-channel might
>>> be cheaper), and will make userspace do 3x ammount of syscalls in the
>>> common case.
>>>
>>> And we can do better; sysfs files with arrays are okay. So I'd like to
>>> see
>>
>> Let's first achieve broader consensus on this statement before we
>> move forward with such design. Sysfs maintainer seems to be the best
>> person to consult at first.
> 
> This is actually documented:
> 
> Documentation/filesystems/sysfs.txt
> 
> <quote>
> Attributes should be ASCII text files, preferably with only one value
> per file. It is noted that it may not be efficient to contain only one
> value per file, so it is socially acceptable to express an array of
> values of the same type.
> 
> Mixing types, expressing multiple lines of data, and doing fancy
> formatting of data is heavily frowned upon. Doing these things may get
> you publicly humiliated and your code rewritten without notice.
> </quote>
> 
> Best regards,
> 									Pavel
> 



  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 [this message]
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
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=20f6bdd5-e899-aead-8c35-1c3a3d09145f@gmail.com \
    --to=jacek.anaszewski@gmail.com \
    --cc=dmurphy@ti.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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