> This _is_ a USB concept, although it certainly might apply elsewhere too > (keyboards and mice, for instance, or input devices in general). The idea > is that while the device is suspended, if some important event happens > (like a key is pressed or the mouse is moved) the device sends a request > to tell the system that the device needs to be resumed. In USB the > hardware doesn't permit devices to resume all by themselves; they have to > ask the host to do it for them. PCI is the same way. Well, ignore the request then. > The difference between a resume request and a wakeup request lies mostly > in the host, not so much in the device. A resume request is what happens > when the system is awake and the device is in a low-power mode, asking to > be returned to full power. A wakeup request is what happens when the > system is suspended and the device wants to wake it up. A device might > not even be aware of the difference between the two types of request. Ok. > Either request could take the form of PME#. (In fact Linux currently > doesn't support using PME# for resume requests; that needs to be changed.) > > A resume request could also be a regular IRQ. There are other > possibilities as well (like setting a flag in a device register that the > driver polls regularly), but these are the major ones. Polling should be stopped in system suspend anyway, remember, your HCI will be sleeping and so no URBs can transit... > Not so. If the driver's suspend method was called, it might be for a > selective suspend, not a system suspend. A driver can't afford to ignore > IRQs while the device is suspended; otherwise there would be no way to do > a selective resume on demand. Didn't we discuss already the fact that this mix of selective & system suspend was totally unacceptable and should be split in different calls ? We _MUST_ provide different selectors to suspend() if we ever want to really support selective suspend (the current stuff or writing a random number to /sys/*/power/state is crap). In which case, a device which is whatever "selective" (I call it local) suspend state would still get a suspend() request for a system transition and so can keep track of it. > Furthermore, it could be that a device can't issue wakeup requests unless > it has IRQs enabled. So what happens, for instance, if Wake-on-LAN is > turned on and an Ethernet interface has been suspended in preparation for > STR, but before the STR completes (and while interrupts are still enabled) > a packet arrives? Well, if the driver properly follows the semantics of suspend(), it won't be able to get that interrupt since the DMA engine on the chip will be stopped, and possibly the local irq mask too. On sungem, I can't "see" any packet once I'm suspended, the whole thing is down at the DMA/host side. For WOL, I only keep the MAC part of the chip enabled and setup some bits in the chip that do a system resume (via PME# I suppose, though I'm not 100% sure, it just works) regardless of my driver beeing able to receive a packet. > It doesn't make sense for the driver to resume the > Ethernet interface when the whole system is about to go to sleep. On the > other hand, since the request has already been delivered, if the driver > ignores it then it will be lost forever. Again, in most of the cases I've seen, the request isn't something that goes up to the driver... But it seems USB is different in this case. Anyway, I suppose that if you press a key on your USB keyboard just after it got suspended and before the machine is actually suspended, then it won't be seen as a waekup request for the machine... There is simply _nothing_ you can do about that and trying to do something would render the stuff even more complicated. Besides, once you had your suspend request, you can't talk to your USB device anymore anyway. Ben.
