On Nov 24 2008, at 18:08, Alan Stern was caught saying: > > Yep. i8042, lid, power button, battery state change, WOL. I think > > I can do something similar to what ACPI is doing by trapping the > > device registration. > > ACPI may not be such a good model after all. It's very table-driven, > with its own little interpreter (or not so little!), whereas most > platforms have a pretty good idea beforehand of what devices can exist, > and they are described as static data. Right? Correct. Most embedded platforms are fairly static and don't need the complexity of ACPI. > So the platform code could initialize the "can_wakeup" setting when it > first detects and registers the device. And you could add a > "set_wakeup" function pointer to struct platform_device, which the > bus-level suspend and resume routines would invoke to enable or disable > remote wakeup, as appropriate. In the static structures these function > pointers would point to routines that set or clear the appropriate bits > in your Embedded Controller. > > I think this is the right way to go... This sounds good. I think I can get away with doing this w/o having to touch shared drivers such as i8042. ~Deepak -- Deepak Saxena http://www.greenbasement.info _____ __o Kernel Hacker, One Laptop Per Child (o> ------ -\<, Give One Laptop, Get One Laptop //\ ----- ( )/ ( ) http://www.amazon.com/xo V_/_ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
