Re: Generic events for wake up from S1-S4

Re: Generic events for wake up from S1-S4

[Rafael J. Wysocki]

On Thursday 23 July 2009, Henrique de Moraes Holschuh wrote:
> On Thu, 23 Jul 2009, Pavel Machek wrote:
> > On Thu 2009-07-23 16:45:22, Henrique de Moraes Holschuh wrote:
> > > On Thu, 23 Jul 2009, Pavel Machek wrote:
> > > > > > Note that the "why" is unreliable by design. Network driver will
> > > > > > ignore WoL during run-time, right?
> > > > > 
> > > > > "Why" is unrealible?  I don't follow your reasoning.  It should be as
> > > > > reliable as "who"...
> > > > 
> > > > See above. The wakeup events race with each other.
> > > 
> > > We deliver them all.  It is that simple.  The rest is up to userspace.
> > 
> > Ok, but then we should not be talking about wake up events,
> > but... events.
> > 
> > Like "lid opened", "wake packet came", ... . And deliver them even
> > when they happen during run-time. That's okay with me.
> 
> 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?

Rafael

Re: Generic events for wake up from S1-S4

[ykzhao]

On Fri, 2009-07-24 at 05:27 +0800, Rafael J. Wysocki wrote:
> On Thursday 23 July 2009, Henrique de Moraes Holschuh wrote:
> > On Thu, 23 Jul 2009, Pavel Machek wrote:
> > > On Thu 2009-07-23 16:45:22, Henrique de Moraes Holschuh wrote:
> > > > On Thu, 23 Jul 2009, Pavel Machek wrote:
> > > > > > > Note that the "why" is unreliable by design. Network driver will
> > > > > > > ignore WoL during run-time, right?
> > > > > > 
> > > > > > "Why" is unrealible?  I don't follow your reasoning.  It should be as
> > > > > > reliable as "who"...
> > > > > 
> > > > > See above. The wakeup events race with each other.
> > > > 
> > > > We deliver them all.  It is that simple.  The rest is up to userspace.
> > > 
> > > Ok, but then we should not be talking about wake up events,
> > > but... events.
> > > 
> > > Like "lid opened", "wake packet came", ... . And deliver them even
> > > when they happen during run-time. That's okay with me.
> > 
> > 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?
Maybe we should firstly define what event should be delivered to user
space when it is resumed from S1--S4.

And another issue who is in charge of sending the event? By the specific
device or ACPI notification?

Thanks.
> 
> Rafael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Generic events for wake up from S1-S4

[Henrique de Moraes Holschuh]

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.

> Maybe we should firstly define what event should be delivered to user
> space when it is resumed from S1--S4.

Why not a change uevent (although we could always come up with a new uevent
type for this, and that might be a good idea)?

> And another issue who is in charge of sending the event? By the specific
> device or ACPI notification?

ACPI notifications are hard to extend, I think.  Please correct me if I am
wrong.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Generic events for wake up from S1-S4

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 305 bytes --]

On Fri, 2009-07-24 at 10:39 -0300, Henrique de Moraes Holschuh wrote:

> ACPI notifications are hard to extend, I think.  Please correct me if I am
> wrong.

ACPI is the wrong place anyway, since it's fundamentally platform
dependent. Unlike the rest of suspend and wake functionality.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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@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-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html