Re: Generic events for wake up from S1-S4

[Luis R. Rodriguez]

On Fri, Jul 24, 2009 at 6:39 AM, Henrique de Moraes
Holschuh<hmh@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/