> As you know we want user configuration of enabled wakeup events (unlike > embedded platforms where this is hardcoded). It seems that the current > interface available for that is /sys/devices/../power/wakeup hook (when > !ACPI). > > However there are several wakeup capable devices in OLPC which do not > have drivers, thus no platform devices: > > - power button > - lid > > It seems that creating platform devices for these two just for the > purpose of a having an interface for enabling wakeup events is overkill. > > Given that, we probably want something similar to what was initially > described in http://wiki.laptop.org/go/Power_Management_Interface ? > > The downside of doing that is a non-unified interface: platform > devices via /sys/devices/../power/wakeup and otherwise > /sys/whatever/wakeup/source? Perhaps it is over kill, but is it really very expensive for handful of devices? I am curious as to others experiences here. In hacks for embedded in the past I've sprinkled some extra device/bus registrations around to provide a common way to enable wake ups and idle states. I don't know that it was the best way to do it, but it could be made to work. A dev structure is a handy thing to have around and provides symmetry. Having a sysfs entry provides for an easy way to set and test from user space. You can always export the function in the kernel also to get a secondary path to the function. All that seems nicer than adding ioctrls and the like per driver. Regards, Richard W. - 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
