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? > > 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. Just thought of something. Not all the devices we can wakeup on are platform devices. The WLAN specifically is an on-board USB device with a sideband wakeup signal connected to the EC. So instead I'll make the set_wakeup() ptr a member of struct device and call it in device_suspend(). ~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
