lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 6 Jan 2014 01:37:14 +0100 From: Pavel Machek <pavel@....cz> To: Bryan Wu <cooloney@...il.com> Cc: Greg KH <greg@...ah.com>, Geert Uytterhoeven <geert@...ux-m68k.org>, Joe Xue <lgxue@...mail.com>, "rpurdie@...ys.net" <rpurdie@...ys.net>, "rob@...dley.net" <rob@...dley.net>, "milo.kim@...com" <milo.kim@...com>, "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org> Subject: Re: how to represent sequence of brightnesses in /sys (was Re: [PATCH] Add the LED burst trigger) Hi! > >> > 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. That might be a bit too heavy. LED patterns do change quite often. lp5523 driver uses this to push binary data through /sys. (It is code for lp5523 processor in this case). Something like that would still be better than firmware loader... cd /sys/class/i2c-adapter/i2c-2/2-0032 echo load > engine1_mode echo cd /sys/class/i2c-adapter/i2c-2/2-0032 echo 9d804000427f0d7f7f007f0042000000 > engine1_load echo run > engine1_mode 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 linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists