Re: Generic events for wake up from S1-S4

["Luis R. Rodriguez" <mcgrof@gmail.com>]

On Fri, Jul 24, 2009 at 6:39 AM, Henrique de Moraes
Holschuh<hmh@hmh.eng.br> wrote:
> On Fri, 24 Jul 2009, ykzhao wrote:
>> > > Well, we *already* deliver "lid opened" when the lid is opened, regardless
>> > > of it waking up the computer or not.  But we are missing a way to deliver
>> > > other classes of wakeup events.
>> > >
>> > > I know of at least these (incomplete list):
>> > >
>> > > 1. network-initiated wakeup
>> > >    a. wired
>> > >    b. wireless
>> > >    c. long-range wireless
>> > >
>> > > 2. platform health/condition alarms
>> > >    a. battery alarm (two levels, warning and emergency)
>> > >    b. thermal alarm (two levels, warning and emergency)
>> > >    (we need these as generic alarms, not just reason-for-wakeup)
>> > >
>> > > 3. device (or device tree) hotplug/hotunplug
>> > >    a. hotunplug request or notification
>> > >       (we deliver the request/notification, but we don't know we should
>> > >       go back to sleep, so all we are missing is the reason-for-wakeup
>> > >       event)
>> > >
>> > > 4. management
>> > >    a. wake-up/power on clock
>> > >    b. remote management command (IMPI, etc)
>> > >    c. intrusion alarm
>> > >    d. theft alarm
>> > >
>> > > None of those have a standard interface to notify userspace of the reason of
>> > > the wake up AFAIK.  Many of these want a generic event interface to be
>> > > delivered not just as reason-for-wakeup, but also as runtime events.
>> > >
>> > > And I guess we should also tell userspace what state we are waking up from
>> > > (S5 clean state, S5/S4 hibernation, S3), sometimes it matters.
>> >
>> > Agreed, and same for the above.
>> >
>> > So, what in your opinion would be the best way to expose this information?
>
> Frankly?  It needs to be an easy-to-extend ABI, and the only one that cames
> to mind right now are uevents.

That sounds like a great idea.

  Luis