> > I'm not sure I agree with that. Perhaps the driver could use the extra > information... but the fact is that USB only defines a single "suspended" > state, and when a device is suspended the only feature you can enable or > disable is whether it sends resume/wakeup requests. Well... it depends. Again, there are reasons we want the full details down to the device, it's a matter of policy. For example, imagine a USB self powered storage device. In some cases, you may to explicitely send a stop unit to it, in some cases you may not (just picking a random example, but there may be more subtle ones in real life). Also, the queue freezing for block devices will be completely different depending on wether they accept more upstream request (thus self-waking up) or not. What you may need on USB I suppose is a way for a hub to "know" that all it's childs have entered an self-suspend mode (idle), and if that propagates up to the root hub, then suspend the bus. Bus then, devices need in a similar way, a mecanism to inform their parent hub they are waking up from that self-suspend mode (because an upstream request for example), thus triggering wakeup of the whole bus segment down to that devive. I don't know at this point how much of that can be dealt with at the core PM level or should stay USB specific tho. It's a bit of a complicated matter, especially when locking is involved... > > > Should SELECTIVE_SUSPEND be added as a PM message type? Then calls > > > > That's one possibility. Or we might just have a flag for that. > > It seems like a waste to force drivers to store information in every > device structure about whether the current suspend is selective or > system-wide. Particularly since system-wide suspends always affect every > device when they occur. They have to. For once, the auto-wakeup, for once, wether the parent can be woken up "upon request" by the child (as explained above) or not (system suspend)... We may have ways to abstract all of that at the PM core loevel tho ... > Why not instead have a globally-available flag or API for checking whether > selective resume requests should be honored? At the start of a > system-suspend this flag could be set to disallow resumes, and the flag > can be cleared when the system-resume begins. I hate anything global... Ben.
