[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 6 Jun 2017 22:13:42 +0200
From: Pavel Machek <pavel@....cz>
To: Jacek Anaszewski <jacek.anaszewski@...il.com>
Cc: fenglinw@...eaurora.org, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org, Richard Purdie <rpurdie@...ys.net>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
linux-leds@...r.kernel.org, devicetree@...r.kernel.org,
subbaram@...cinc.com, aghayal@....qualcomm.com, wruan@...cinc.com,
kgunda@....qualcomm.com
Subject: Re: [PATCH V2 1/2] leds: leds-qti-rgb: Add LED driver for QTI
TRI_LED module
Hi!
> >> Generally I came to a conclusion that it will be best to register
> >> additional LED RGB class device in an addition to three LED class
> >> devices representing each color. In order to avoid hard to solve
> >> locking problems I propose to allow for simultaneous access to LED
> >> class devices and LED RGB class device gathering them.
> >>
> >> All in all, currently we also don't give an exclusive access to
> >> a particular LED class device, which always can lead to overwriting
> >> current brightness by another process. These issues must be arbitrated
> >> by user space.
> >>
> >> I propose that LED RGB class device exposed following files:
> >>
> >> - red_brightness
> >> - green_brightness
> >> - blue_brightness
> >> - latch_color
> >
> > Actually, I'd just do single file, "rgb_brightness" with 3
> > values. Overhead of writing 3 values is pretty much 0.
>
> You've always been strongly in favor of one-value-per-file
> sysfs rule of thumb, but I'm OK with this approach as well :-)
Being values of same type (etc), this is actually permitted. And it is
better than hack with latch_color :-).
Good.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists