Generic events for wake up from S1-S4

Generic events for wake up from S1-S4

[ori]

Hi linux-pm experts.

We are working on a sleep solution for Linux server and therefore are 
very interested in this subject.
I have found an email thread with the subject above from July 2009.
Could you tell if any advance was done on this front ? any thoughts 
about how to implement the user events for wake up reasons ?

I have tried to find any resource about this subject but there is hardly 
anything out there.

Thanks in advance for any kind of an answer.
Best regards,
Ori

-- 
Ori Finkelman
ComSleep Ltd.

Cell:  +972-52-3832189
Tel:   +972-3-5366641 ext. 102
Fax:   +972-3-5366643
Email: ori@comsleep.com

Re: Generic events for wake up from S1-S4

[Rafael J. Wysocki]

On Tuesday 23 February 2010, ori wrote:
> Hi linux-pm experts.
> 
> We are working on a sleep solution for Linux server and therefore are 
> very interested in this subject.
> I have found an email thread with the subject above from July 2009.
> Could you tell if any advance was done on this front ? any thoughts 
> about how to implement the user events for wake up reasons ?
> 
> I have tried to find any resource about this subject but there is hardly 
> anything out there.

I'm not really sure what you mean by "generic events".  Can you please elaborate?

Rafael

Generic events for wake up from S1-S4

[Luis R. Rodriguez]

I'm working on Wake-on-Wireless support for wireless right now [1].
Upon wake up I wanted to inform the kernel of the event which caused
the wake up but am not clear if there is a generic API for this. Mind
you, for WoW we'll need at least some AC power to the card so we'll
need to at least be in S3-Hot so we'll only need events for that for
now.

Do we have some generic infrastructure to gather reasons for wake up
from S1-S4 and pass this to userspace yet?

[1] http://wireless.kernel.org/en/users/Documentation/WoW

  Luis

Re: Generic events for wake up from S1-S4

[Pavel Machek]

On Tue 2009-07-14 15:11:45, Luis R. Rodriguez wrote:
> I'm working on Wake-on-Wireless support for wireless right now [1].
> Upon wake up I wanted to inform the kernel of the event which caused
> the wake up but am not clear if there is a generic API for this. Mind
> you, for WoW we'll need at least some AC power to the card so we'll
> need to at least be in S3-Hot so we'll only need events for that for
> now.
> 
> Do we have some generic infrastructure to gather reasons for wake up
> from S1-S4 and pass this to userspace yet?

I do not think generic api exists...

How does it work? I thought that wifi stack is in software -> you need
main cpu to run for wifi to work?

...and what are the applications? I understand that WoL is useful for
remote administration of connected desktops.
								Pavel

> [1] http://wireless.kernel.org/en/users/Documentation/WoW


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Generic events for wake up from S1-S4

[Luis R. Rodriguez]

On Tue, Jul 14, 2009 at 4:53 PM, Pavel Machek<pavel@ucw.cz> wrote:
> On Tue 2009-07-14 15:11:45, Luis R. Rodriguez wrote:
>> I'm working on Wake-on-Wireless support for wireless right now [1].
>> Upon wake up I wanted to inform the kernel of the event which caused
>> the wake up but am not clear if there is a generic API for this. Mind
>> you, for WoW we'll need at least some AC power to the card so we'll
>> need to at least be in S3-Hot so we'll only need events for that for
>> now.
>>
>> Do we have some generic infrastructure to gather reasons for wake up
>> from S1-S4 and pass this to userspace yet?
>
> I do not think generic api exists...
>
> How does it work?

I tried to brain dump as much as I could on the WoW wiki page [1]. In
essence we send keep alive messages (null data frames) and since we're
in PS mode the AP buffers the frames for us. At least for Atheros
ath9k devices we don't have any option but to not process any frames
sent to us from the AP except for WoW hardware processing. For WoW we
have a few triggers, with user patterns we can customize a wakeup upon
ARP requests, for example, but right now I've only enabled and tested
Magic Packet.

> I thought that wifi stack is in software -> you need
> main cpu to run for wifi to work?

Yes, but we are not processing 802.11 frames for data processing and
sending them up to any higher layer, we're just doing raw hardware
pattern matching and event triggering. This of course also means
devices which do not a CPU or a CPU but no special WoW firmware that
you won't be able to use WPA for group key stuff for example for which
I do believe we do need the box's CPU. Which reminds me, maybe we
should not allow WoW for that case for now.

> ...and what are the applications?

Same as with Ethernet, only difference this is 802.11. Also not all
Ethernet drivers support WoL.

> I understand that WoL is useful for
> remote administration of connected desktops.

Sure, I for instance want to be able to use WoL and WoW to power up my
machines at home when I walk in and my Android associates to my AP.
Some devices may be connected through Ethernet some not.

>> [1] http://wireless.kernel.org/en/users/Documentation/WoW

  Luis

Re: Generic events for wake up from S1-S4

[Luis R. Rodriguez]

On Wed, Jul 15, 2009 at 8:51 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Tue, Jul 14, 2009 at 4:53 PM, Pavel Machek<pavel@ucw.cz> wrote:

>> I thought that wifi stack is in software -> you need
>> main cpu to run for wifi to work?
>
> Yes, but we are not processing 802.11 frames for data processing and
> sending them up to any higher layer, we're just doing raw hardware
> pattern matching and event triggering. This of course also means
> devices which do not a CPU or a CPU but no special WoW firmware that
> you won't be able to use WPA for group key stuff for example for which
> I do believe we do need the box's CPU. Which reminds me, maybe we
> should not allow WoW for that case for now.

I should clarify a little more here. It is true you need the main CPU
for wifi to "work", but you don't need it to have the wireless
device's radio turned on, or other logical components of the hardware
sending a PCI PME, for example. All you need for that is some juice.
"Work" in the usual sense would mean to process your raw 802.11
frames, and send them up the stack. That's the part we leave off to
the CPU/driver.

  Luis

Re: Generic events for wake up from S1-S4

[Luis R. Rodriguez]

On Wed, Jul 15, 2009 at 8:51 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Tue, Jul 14, 2009 at 4:53 PM, Pavel Machek<pavel@ucw.cz> wrote:
>> On Tue 2009-07-14 15:11:45, Luis R. Rodriguez wrote:
>>> I'm working on Wake-on-Wireless support for wireless right now [1].
>>> Upon wake up I wanted to inform the kernel of the event which caused
>>> the wake up but am not clear if there is a generic API for this. Mind
>>> you, for WoW we'll need at least some AC power to the card so we'll
>>> need to at least be in S3-Hot so we'll only need events for that for
>>> now.
>>>
>>> Do we have some generic infrastructure to gather reasons for wake up
>>> from S1-S4 and pass this to userspace yet?
>>
>> I do not think generic api exists...

Going back to this topic -- any suggestions? Will a generic netlink
family be OK? Or perhaps easier a udev event for some suitable
existing parent ?

  Luis

Re: Generic events for wake up from S1-S4

[Pavel Machek]

On Wed 2009-07-15 11:00:07, Luis R. Rodriguez wrote:
> On Wed, Jul 15, 2009 at 8:51 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> > On Tue, Jul 14, 2009 at 4:53 PM, Pavel Machek<pavel@ucw.cz> wrote:
> >> On Tue 2009-07-14 15:11:45, Luis R. Rodriguez wrote:
> >>> I'm working on Wake-on-Wireless support for wireless right now [1].
> >>> Upon wake up I wanted to inform the kernel of the event which caused
> >>> the wake up but am not clear if there is a generic API for this. Mind
> >>> you, for WoW we'll need at least some AC power to the card so we'll
> >>> need to at least be in S3-Hot so we'll only need events for that for
> >>> now.
> >>>
> >>> Do we have some generic infrastructure to gather reasons for wake up
> >>> from S1-S4 and pass this to userspace yet?
> >>
> >> I do not think generic api exists...
> 
> Going back to this topic -- any suggestions? Will a generic netlink
> family be OK? Or perhaps easier a udev event for some suitable
> existing parent ?

Is "who woke me" information even relevant? Yes, it may be interesting
enough for printk, but... What will userspace do with that information?

Imagine WoW packet comes, 5msec later WoL packet comes, 5msec later
user opens the lid. You report WoW as wakeup reason, but it is
inherently "racy".

What about simply reporting "wake event happened on this device" and
doing that for all the devices?


									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Generic events for wake up from S1-S4

[Luis R. Rodriguez]

On Sat, Jul 18, 2009 at 3:37 AM, Pavel Machek<pavel@ucw.cz> wrote:
> On Wed 2009-07-15 11:00:07, Luis R. Rodriguez wrote:
>> On Wed, Jul 15, 2009 at 8:51 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>> > On Tue, Jul 14, 2009 at 4:53 PM, Pavel Machek<pavel@ucw.cz> wrote:
>> >> On Tue 2009-07-14 15:11:45, Luis R. Rodriguez wrote:
>> >>> I'm working on Wake-on-Wireless support for wireless right now [1].
>> >>> Upon wake up I wanted to inform the kernel of the event which caused
>> >>> the wake up but am not clear if there is a generic API for this. Mind
>> >>> you, for WoW we'll need at least some AC power to the card so we'll
>> >>> need to at least be in S3-Hot so we'll only need events for that for
>> >>> now.
>> >>>
>> >>> Do we have some generic infrastructure to gather reasons for wake up
>> >>> from S1-S4 and pass this to userspace yet?
>> >>
>> >> I do not think generic api exists...
>>
>> Going back to this topic -- any suggestions? Will a generic netlink
>> family be OK? Or perhaps easier a udev event for some suitable
>> existing parent ?
>
> Is "who woke me" information even relevant? Yes, it may be interesting
> enough for printk, but... What will userspace do with that information?

Splashy event notification thingies?

I was just trying to avoid verbose debug info for WoW upon wakeup and
figured it be nice to report back through a generic interface.

> Imagine WoW packet comes, 5msec later WoL packet comes, 5msec later
> user opens the lid. You report WoW as wakeup reason, but it is
> inherently "racy".

Hm yeah, but I doubt someone will do that, generally we'd get one wake
up event. Can't we just report the first one and ignore the rest?

> What about simply reporting "wake event happened on this device" and
> doing that for all the devices?

That's fine too. Just think it would be nice to be more specific if possible.

  Luis

Re: Generic events for wake up from S1-S4

[Henrique de Moraes Holschuh]

On Sat, 18 Jul 2009, Luis R. Rodriguez wrote:
> Hm yeah, but I doubt someone will do that, generally we'd get one wake
> up event. Can't we just report the first one and ignore the rest?

Well, I'd say keeping it simple is best, here.  What if you ignore the more
interesting wakeup events by chance (and it is really up to userspace to
know what it considers interesting...)?  IMHO, just issue as many
notifications as needed, let userspace filter it if it wants.

But if you guys are talking about something really generic, shouldn't it
also provide the important "why" along with the "who"?

Even for the most common cases, the "why" is useful: userspace may well want
to run special routines when it wakes up because of WoL and WoW (instead of
a key press, lid open or mouse movement...).

When you factor in wakeups caused by platform alarms, well, the "why"
becomes even more interesting.

> > What about simply reporting "wake event happened on this device" and
> > doing that for all the devices?
> 
> That's fine too. Just think it would be nice to be more specific if possible.

A generic way for a device (of any sort, not just network devices!) to
report that they just issued a system wakeup message, as well as the reason
it did that seems like a good way to do it to me.

-- 
  "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

[Luis R. Rodriguez]

On Sat, Jul 18, 2009 at 4:56 PM, Henrique de Moraes
Holschuh<hmh@hmh.eng.br> wrote:
> On Sat, 18 Jul 2009, Luis R. Rodriguez wrote:
>> Hm yeah, but I doubt someone will do that, generally we'd get one wake
>> up event. Can't we just report the first one and ignore the rest?
>
> Well, I'd say keeping it simple is best, here.  What if you ignore the more
> interesting wakeup events by chance (and it is really up to userspace to
> know what it considers interesting...)?  IMHO, just issue as many
> notifications as needed, let userspace filter it if it wants.
>
> But if you guys are talking about something really generic, shouldn't it
> also provide the important "why" along with the "who"?
>
> Even for the most common cases, the "why" is useful: userspace may well want
> to run special routines when it wakes up because of WoL and WoW (instead of
> a key press, lid open or mouse movement...).
>
> When you factor in wakeups caused by platform alarms, well, the "why"
> becomes even more interesting.

We'd need a generic interface for keeping track of all possible
wake-up-triggers. Should be easy with udev events.

>> > What about simply reporting "wake event happened on this device" and
>> > doing that for all the devices?
>>
>> That's fine too. Just think it would be nice to be more specific if possible.
>
> A generic way for a device (of any sort, not just network devices!) to
> report that they just issued a system wakeup message, as well as the reason
> it did that seems like a good way to do it to me.

This should be easy to do via udev events.

How about an generic platform registered, and udev events issues for
wake-up-triggers, and also for wake-up-events, and leave all the
sorting out to userspace? All we'd need in-kernel would be the trigger
registration and event trigger notifications.

  Luis

Re: Generic events for wake up from S1-S4

[Henrique de Moraes Holschuh]

On Mon, 20 Jul 2009, Luis R. Rodriguez wrote:
> >> > What about simply reporting "wake event happened on this device" and
> >> > doing that for all the devices?
> >>
> >> That's fine too. Just think it would be nice to be more specific if possible.
> >
> > A generic way for a device (of any sort, not just network devices!) to
> > report that they just issued a system wakeup message, as well as the reason
> > it did that seems like a good way to do it to me.
> 
> This should be easy to do via udev events.
> 
> How about an generic platform registered, and udev events issues for
> wake-up-triggers, and also for wake-up-events, and leave all the
> sorting out to userspace? All we'd need in-kernel would be the trigger
> registration and event trigger notifications.

I am fine with it.  Please CC me if you write some code for that ;-)

-- 
  "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

[Pavel Machek]

On Sat 2009-07-18 20:56:10, Henrique de Moraes Holschuh wrote:
> On Sat, 18 Jul 2009, Luis R. Rodriguez wrote:
> > Hm yeah, but I doubt someone will do that, generally we'd get one wake
> > up event. Can't we just report the first one and ignore the rest?
> 
> Well, I'd say keeping it simple is best, here.  What if you ignore the more
> interesting wakeup events by chance (and it is really up to userspace to
> know what it considers interesting...)?  IMHO, just issue as many
> notifications as needed, let userspace filter it if it wants.
> 
> But if you guys are talking about something really generic, shouldn't it
> also provide the important "why" along with the "who"?
> 
> Even for the most common cases, the "why" is useful: userspace may well want
> to run special routines when it wakes up because of WoL and WoW (instead of
> a key press, lid open or mouse movement...).

What special routines?

Note that the "why" is unreliable by design. Network driver will
ignore WoL during run-time, right?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Generic events for wake up from S1-S4

[Henrique de Moraes Holschuh]

On Thu, 23 Jul 2009, Pavel Machek wrote:
> On Sat 2009-07-18 20:56:10, Henrique de Moraes Holschuh wrote:
> > On Sat, 18 Jul 2009, Luis R. Rodriguez wrote:
> > > Hm yeah, but I doubt someone will do that, generally we'd get one wake
> > > up event. Can't we just report the first one and ignore the rest?
> > 
> > Well, I'd say keeping it simple is best, here.  What if you ignore the more
> > interesting wakeup events by chance (and it is really up to userspace to
> > know what it considers interesting...)?  IMHO, just issue as many
> > notifications as needed, let userspace filter it if it wants.
> > 
> > But if you guys are talking about something really generic, shouldn't it
> > also provide the important "why" along with the "who"?
> > 
> > Even for the most common cases, the "why" is useful: userspace may well want
> > to run special routines when it wakes up because of WoL and WoW (instead of
> > a key press, lid open or mouse movement...).
> 
> What special routines?

Starting a remote maintenance shell is a common usage scenario on corporate
environments.

Besides, it is a generic wakeup notification we're talking about, isn't it?
I have some that have nothing to do with WoW or WoL:

1. Thermal alarm
2. Battery alarm
3. Hotunplug request (bay/dock): umount stuff, cleanly undock, then go back
to sleep (optional)

I already support them in thinkpad-acpi, but all I can do is issue a printk
and set some crap values in sysfs for userspace to query right now (I didn't
want to create yet another non-generic event interface).

> 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"...

If the WoW/WoL device doesn't know why it woke up the system, it uses the
generic reason for network devices (I don't even know if a network device
has more than one reason for wakeup).  If a different device wakes the
system, it might know why and provide that reason.  And if it doesn't know
it woke up the system, it sends no notification at all.

-- 
  "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

[Pavel Machek]

On Thu 2009-07-23 15:57:20, Henrique de Moraes Holschuh wrote:
> On Thu, 23 Jul 2009, Pavel Machek wrote:
> > On Sat 2009-07-18 20:56:10, Henrique de Moraes Holschuh wrote:
> > > On Sat, 18 Jul 2009, Luis R. Rodriguez wrote:
> > > > Hm yeah, but I doubt someone will do that, generally we'd get one wake
> > > > up event. Can't we just report the first one and ignore the rest?
> > > 
> > > Well, I'd say keeping it simple is best, here.  What if you ignore the more
> > > interesting wakeup events by chance (and it is really up to userspace to
> > > know what it considers interesting...)?  IMHO, just issue as many
> > > notifications as needed, let userspace filter it if it wants.
> > > 
> > > But if you guys are talking about something really generic, shouldn't it
> > > also provide the important "why" along with the "who"?
> > > 
> > > Even for the most common cases, the "why" is useful: userspace may well want
> > > to run special routines when it wakes up because of WoL and WoW (instead of
> > > a key press, lid open or mouse movement...).
> > 
> > What special routines?
> 
> Starting a remote maintenance shell is a common usage scenario on corporate
> environments.

But... You want to start maintenance shell not on wakeup from WoL, but
on receiving the magic packet. If you hit the keyboard before to wake
up the machine, and the magic packet still comes, you still want the
remote maintenance shell.

> Besides, it is a generic wakeup notification we're talking about, isn't it?
> I have some that have nothing to do with WoW or WoL:
> 
> 1. Thermal alarm
> 2. Battery alarm
> 3. Hotunplug request (bay/dock): umount stuff, cleanly undock, then go back
> to sleep (optional)

Well, battery&thermal alarms would certainly be useful. (And yes, I
believe it is a bug in ACPI that we don't printk on battery critical).

> > 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.

> If the WoW/WoL device doesn't know why it woke up the system, it uses the
> generic reason for network devices (I don't even know if a network device
> has more than one reason for wakeup).  If a different device wakes the
> system, it might know why and provide that reason.  And if it doesn't know
> it woke up the system, it sends no notification at all.

See above.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Generic events for wake up from S1-S4

[Henrique de Moraes Holschuh]

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.

-- 
  "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

[Pavel Machek]

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.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Generic events for wake up from S1-S4

[Henrique de Moraes Holschuh]

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.

-- 
  "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

[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

[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

[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

[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

[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.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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

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

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

Re: Generic events for wake up from S1-S4

[Valdis.Kletnieks]

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

On Thu, 23 Jul 2009 21:51:14 +0200, Pavel Machek said:

> 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.

That's actually a sane thing to do - for instance, one of the main uses
of "wake on LAN" in many environments is to wake up a box to do software
upgrades.  And if we're already up-and-running, and we "know" (from site
policy) that a W-o-L packet is only sent because IT is pushing updates,
it may make a lot of sense to catch a "wake packet" event, and go ahead
and start the software updater *anyhow* (with suitable notification/confirm
dialog to the poor guy still working on that presentation at 2AM, of course :)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]