From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Subject: Re: how to represent sequence of brightnesses in /sys (was Re: [PATCH] Add the LED burst trigger) Date: Sat, 28 Dec 2013 17:43:24 -0800 Message-ID: <20131229014324.GB18455@kroah.com> References: <20131227095705.GC17143@amd.pavel.ucw.cz> <20131228101622.GA13564@amd.pavel.ucw.cz> <20131228192935.GA28119@amd.pavel.ucw.cz> <20131228212523.GA8733@amd.pavel.ucw.cz> <20131228215042.GA7048@kroah.com> <20131228235045.GA8786@amd.pavel.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20131228235045.GA8786@amd.pavel.ucw.cz> Sender: linux-kernel-owner@vger.kernel.org To: Pavel Machek Cc: Geert Uytterhoeven , Joe Xue , "cooloney@gmail.com" , "rpurdie@rpsys.net" , "rob@landley.net" , "milo.kim@ti.com" , "linux-leds@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-doc@vger.kernel.org" List-Id: linux-leds@vger.kernel.org On Sun, Dec 29, 2013 at 12:50:46AM +0100, Pavel Machek wrote: > On Sat 2013-12-28 13:50:42, Greg KH wrote: > > On Sat, Dec 28, 2013 at 10:25:23PM +0100, Pavel Machek wrote: > > > Hi! > > > > > > > >> Sysfs is meant to be human-readable/writable, so please use plain ASCII > > > > >> numbers in strings instead. > > > > > > > > > > Actually, sysfs is meant to be one value per file, and it is > > > > > > > > Ideally, yes. > > > > > > > > > understood that data that are "natively blob" are just passed as > > > > > blob. (I believe this qualifies). > > > > > > > > But it doesn't buy us much here, does it? It will make e.g. shell scripts > > > > needlessly complicated. > > > > > > echo -ne '\012' is not that bad, and parsing array of integers from > > > kernel will be an ugly piece of code. > > > > Ick, no. What are you trying to do here? Have the kernel intrepret a > > sequence of bytes to flash an LED? I thought we have frameworks in > > userspace already to handle this type of thing. Please don't invent new > > ways of doing stuff... > > 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". greg k-h