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 ? Alan -- 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/
