On Fri, Jan 05, 2007 at 12:33:20PM -0500, Len Brown wrote: [...] > With /proc/acpi/ going away, this raises the question of where sony_acpi should put stuff > that is under development -- as unlike brightness -- it will not have a generic home in sysfs. I was thinking the same and had 2 options in my mind: 1- debugfs (with proper documentation) 2- turn the SNC into a platform_device driver (as is msi-laptop) and eventually create .config options to enable experimental/debug features. > To do it right, some analysis of the DSDT which has these vendor methods in them > will be necessary. It is conceivable that these methods can be hooked to the generic > device power management support if the "real" devices in sysfs can be found. In my DSDT[1] some of the methods (the audio card power setter: AZPW) references a method in the real device (the same used in _PS0 and _PS3 for the device) so it's actually a duplicate and the real device already has the capability. I'd say all the others are playing with random IO registers or in the EC0 operation region. [1]: sz72b http://oioio.altervista.org/linux/DSDT.sz72b.dsl other DSDTs I have: http://oioio.altervista.org/linux/DSDT.ux50.dsl http://oioio.altervista.org/linux/DSDT.gr7k.dsl > A word of warning, which may be totally obvious here, is that the method names above > are completely arbitrary choices on the part of a BIOS engineer at Sony, and the > next BIOS engineer can make completely different choices for what names are used > or what the same names do. This is already partly happened, at least a known old method name has mutated. I'll send a first rush of patches as soon as I decide how to deal with the different method names. -- mattia :wq! - 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
