On Tue, 23 Nov 2004, David Brownell wrote: > > Okay. Looking through the kernel source I couldn't find any place where > > PME# is turned off! That would cause problems for repeated suspends... > > Could be. On the other hand, I've yet to see a system wake > up from PME with ACPI either, so I don't have any reason to > believe the other PME infrastructure behaves yet either. It probably doesn't. But remember that the two are separate and independent: ACPI doesn't mean PCI or PME# is present, and PCI + PME# doesn't mean ACPI is present. > > How would you describe a host controller which was capable of sending PME# > > when the PCI bus interface is suspended, but is not capable of > > interrupting the host when the bus interface is in D0 and the root hub is > > suspended? Would you say that the root hub's can_wakeup should not be > > set? Or would you say that can_wakeup should be set and the HCD should > > rely on timer polling to detect events? > > The latter: it's a root hub that must use software polling, > except in system-wide sleep states. That's fully compatible > with how the system shuts down the timers almost as the very > last thing before entering an ACPI sleep state. Okay. It's safe to assume that any HC will support port event polling while it is suspended, right? So one way or another, we will always be able to receive resume requests from root hubs. That undercuts my major reason for wanting a can_resume flag. But the idea may still be useful for other sorts of devices. Does it make sense, in general, to separate out a device's capability for waking the system from a sleep state and its capability for requesting a resume while it is selectively suspended but the system is awake? Alan Stern
