Hi Pavel and Greg, On Fri, Feb 20, 2015 at 09:57:38PM +0100, Pavel Machek wrote: > 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.anaszewski@xxxxxxxxxxx> > > > >>>>Acked-by: Kyungmin Park <kyungmin.park@xxxxxxxxxxx> > > > >>>>Cc: Bryan Wu <cooloney@xxxxxxxxx> > > > >>>>Cc: Richard Purdie <rpurdie@xxxxxxxxx> > > > >>> > > > >>>NAK-ed-by: Pavel Machek > > > >>> > > > >>>>+What: /sys/class/leds/<led>/available_sync_leds > > > >>>>+Date: February 2015 > > > >>>>+KernelVersion: 3.20 > > > >>>>+Contact: Jacek Anaszewski <j.anaszewski@xxxxxxxxxxx> > > > >>>>+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. It'd be nice if these names would match the V4L2 sub-device names. We don't have any rules for them other than they must be unique, and there's the established practice that an I2C address follows the component name. We're about to discuss the matter on Monday on #v4l (11:00 Finnish time), but I don't think we can generally guarantee any of the names won't have spaces. Separate files, then? > > > 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. We'd first run out of V4L2 bitmask control bits --- there are 32 of them. I'm frankly not really worried about that either. -- Kind regards, Sakari Ailus e-mail: sakari.ailus@xxxxxx XMPP: sailus@xxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
