On Thu, 2014-10-30 at 23:25 +0000, One Thousand Gnomes wrote: > O> The kernel receives an interrupt, likely on a different device. Again, > > I'm talking about "legacy" devices, for which suspend is actually a > > state. If the device is only in low-power mode, you'd probably get the > > event on the input device, which is accessible from user-space. > > I don't believe so - the firmware ate it. > > > Knowing why the Wi-Fi card woke up is also important when there isn't a > > full "suspend" state. As was mentioned, it's useful for power debugging, > > but it's also useful because that tells things outside the network card > > driver what happened. > > Wifi devices that are smart generally have a fair bit of info they > provide themselves on this. In particular if you are using a deep idle > type behaviour they may well wake every minute or so just to poke a > packet out to keep any NAT mapping alive. > > > As I mentioned in more recent emails on this thread, maybe we don't want > > to know what woke the system up, but knowing that a wake-up event > > occurred on this device, at this time, would allow us to make the > > software act accordingly. The fact that we don't know that means that we > > cannot take appropriate action. > > What woke the system up may also not be a singular item. Suppose the > alarm goes off as the user opens the lid and the wireless gets a wakeup > packet in the same window ?
Then each one of those devices would have their own wakeup reason set, with a timestamp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
