Hi! > >>>>+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? No, it would not. It is required so that we don't end up with broken parsers. > Apart from it, we have also flash_faults attribute, that currently > provides a space separated list of flash faults that have occurred. > If we are to stick tightly to the one-value-per-file rule, then how > we should approach flash_faults case? Should the separate file be > dynamically created for each reported fault? I think you can get away with flash_faults attribute (since the strings are hardcoded). Dynamically created files would be extremely ugly interface, but you could also have files such as "overvoltage_fault" containing either 0 or 1 ... 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
