On Thu, 2009-08-06 at 00:10 +0800, Valdis.Kletnieks@xxxxxx wrote: > On Wed, 05 Aug 2009 09:04:52 +0800, Zhang Rui said: > > On Wed, 2009-08-05 at 01:36 +0800, Greg KH wrote: > > > On Tue, Aug 04, 2009 at 01:24:24PM -0400, Valdis.Kletnieks@xxxxxx wrote: > > > > On Tue, 04 Aug 2009 08:10:42 PDT, Greg KH said: > > > > > On Tue, Aug 04, 2009 at 03:21:29PM +0200, Pavel Machek wrote: > > > > > > On Mon 2009-08-03 17:10:57, Zhang Rui wrote: > > > > > > > > > > > cat /sys/class/als/als0/mappings > > > > > > > ???Illuminance Adjustment > > > > > > > 0 70 > > > > > > > 10 73 > > > > > > > 80 85 > > > > > > > 300 100 > > > > > > > 1000 150 > > > > > > > > > > > > There's one value per file for sysfs... You should definitely have th > e > > > > > > header. > > > > > > > > > > No, no "header", just don't do this, it's not allowed. Again, > > > > > one-value-per-sysfs-file is the rule, please do not violate it. > > > > > > > > What's the intended sysfs solution here, then? Make 'mappings' a directory, > > > > and populate it with files called 0, 10, 80, 300, 1000, each with one number > > > > in them? > > > > > > That's one acceptable solution. Or how about files in this directory > > > called "mapping_0", "mapping_10", and so on, containing the adjustment > > > value? > > > > > great. that's what I'm going to do. > > refreshed patch will be sent out later. :) > > Hmm. whether to call the files mapping_0, mapping_10 etc or mapping/0, mapping/10 > etc probably depends on how nailed-down the 0,10,80,300,100 is - are those > numbers carved in stone, no, these values can even change at run time. > or are we better off defining the API as "directory > mapping, and files for whatever values the hardware happens to cough up?" > hmm, I'd prefer mappings0/{illuminance, adjustment}, mappings1/{illuminance, adjustment}... in this case, all the illuminance/adjustment files can share the same kobj_attribute. thanks, rui -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html