On Fri 2015-02-20 07:36:16, Greg KH wrote:
> On Fri, Feb 20, 2015 at 08:56:11AM +0100, Jacek Anaszewski wrote:
> > On 02/19/2015 10:40 PM, Greg KH wrote:
> > >On Thu, Feb 19, 2015 at 11:02:04AM +0200, Sakari Ailus wrote:
> > >>On Wed, Feb 18, 2015 at 11:47:47PM +0100, Pavel Machek wrote:
> > >>>
> > >>>On Wed 2015-02-18 17:20:22, Jacek Anaszewski wrote:
> > >>>>Add a documentation of LED Flash class specific sysfs attributes.
> > >>>>
> > >>>>Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
> > >>>>Acked-by: Kyungmin Park <kyungmin.p...@samsung.com>
> > >>>>Cc: Bryan Wu <coolo...@gmail.com>
> > >>>>Cc: Richard Purdie <rpur...@rpsys.net>
> > >>>
> > >>>NAK-ed-by: Pavel Machek
> > >>>
> > >>>>+What:          /sys/class/leds/<led>/available_sync_leds
> > >>>>+Date:          February 2015
> > >>>>+KernelVersion: 3.20
> > >>>>+Contact:       Jacek Anaszewski <j.anaszew...@samsung.com>
> > >>>>+Description:   read/write
> > >>>>+               Space separated list of LEDs available for flash strobe
> > >>>>+               synchronization, displayed in the format:
> > >>>>+
> > >>>>+               led1_id.led1_name led2_id.led2_name led3_id.led3_name 
> > >>>>etc.
> > >>>
> > >>>Multiple values per file, with all the problems we had in /proc. I
> > >>>assume led_id is an integer? What prevents space or dot in led name?
> > >>
> > >>Very good point. How about using a newline instead? That'd be a little bit
> > >>easier to parse, too.
> > >
> > >No, please make it one value per-file, which is what sysfs requires.
> > 
> > The purpose of this attribute is only to provide an information about
> > the range of valid identifiers that can be written to the
> > flash_sync_strobe attribute. Wouldn't splitting this to many attributes
> > be an unnecessary inflation of sysfs files?
> 
> Ok a list of allowed values to write is acceptable, as long as it is not
> hard to parse and always is space separated.

Well, this one is list of LED numbers and LED names.

> > Apart from it, we have also flash_faults attribute, that currently
> > provides a space separated list of flash faults that have occurred.
> 
> That's crazy, what's to keep it from growing and growing to be larger
> than is allowed to be read?

Umm. Actually, this one is less crazy, I'd say. List of faults is
fixed, and you can have them all-at-once, at most, which is way below
4K limit.
                                                                Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to