On Sun, Dec 29, 2013 at 3:21 AM, Pavel Machek <pavel@xxxxxx> wrote: > Hi! > >> > Idea would be "sequence of brigtnesses" (one file) and "delay between >> > changes" (second file). >> >> Ick. >> >> > Reason to do it in kernel is that some machines actually have >> > "coprocessor" on i2c that can do it while main CPU is suspended. (For >> > more reasons, see beggining of thread). >> >> Ick ick. >> >> > Binary attribute with array of bytes should be acceptable, rights? >> >> Not at all. >> >> > (IOW write(..., buf, size) ) >> > >> > Ascii array of decimal integers -- no so, right? >> > >> > (IOW printf("%d %d ..", buf[0], buf[1]) ) >> >> Use an ioctl with a structure to get things correct as a character >> device. As odds are, you aren't going to be able to create a "generic" >> format for all of this for all types of devices that support such a >> "co-processor". > > Well, we already do have hw-specific driver in the tree, > drivers/leds/leds-lp55xx-common.c . But the interface is > "interesting" and I believe we should have generic interface and it > should use existing trigger framework -- array of brightnesses does > not seem too complicated. > > Do you have suggestion how to pass the brightnesses over sysfs? > What about send those binary stuff as firmware through kernel firmware interface and LED trigger sysfs is just for parameters setup and enable/disable controlling. Thanks, -Bryan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html