[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <43e72e890907240825l2181297ejb4e1b55ff5e811ef@mail.gmail.com>
Date: Fri, 24 Jul 2009 08:25:49 -0700
From: "Luis R. Rodriguez" <mcgrof@...il.com>
To: Henrique de Moraes Holschuh <hmh@....eng.br>
Cc: ykzhao <yakui.zhao@...el.com>, "Rafael J. Wysocki" <rjw@...k.pl>,
Pavel Machek <pavel@....cz>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Johannes Berg <johannes@...solutions.net>,
"John W. Linville" <linville@...driver.com>,
Jouni Malinen <j@...fi>,
linux-wireless <linux-wireless@...r.kernel.org>,
Stephen Chen <Stephen.Chen@...eros.com>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
pm list <linux-pm@...ts.linux-foundation.org>
Subject: Re: Generic events for wake up from S1-S4
On Fri, Jul 24, 2009 at 6:39 AM, Henrique de Moraes
Holschuh<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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists