On Wednesday 24 November 2004 07:46, Alan Stern wrote: > 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. The only systems I happen to have that claim to support PME# are ACPI based ... I'd expect non-ACPI systems with PCI+PME to support Linux at some point, but PM will need some work! > > > 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. Yes. > 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? Not from what I see. Drivers in subsystems that don't support selective suspend shouldn't be trying to use such mechanisms. For the moment we're in better shape with selective suspend in USB than with ACPI... - Dave > Alan Stern > >
