On Thursday, July 17, 2014 10:39:16 AM Alan Stern wrote: > On Wed, 16 Jul 2014, Dmitry Torokhov wrote: > > We are not planning on implementing the policy in kernel, that's > > indeed task for userspace; but unless we bring in the heavy hammer of > > forcibly unbinding drivers, we do not currently have universal > > mechanism of quiescing devices. > > We sort of do: the ->freeze() callback. But it wasn't intended for > this kind of use; drivers may very well expect that userspace will > already be frozen when the callback runs. Besides, ->freeze() is > supposed to quiesce devices without powering them down, whereas you > want to do both. Right. > > What you're asking for is different from anything the PM subsystem has > done before. Right. > Given this fact, I don't see any alternatives to adding a > new API or repurposing an existing API. Either one would be somewhat > painful. > > For example, we could arrange to invoke ->suspend(). However, since > the circumstances would be unusual (userspace is still running, > ->prepare() was not called beforehand, ->suspend_irq() won't be called > afterward), subsystems and drivers may very well react inappropriately. I do not think anybody expects that drivers would not have to be modified to support this functionality; I expect drivers would have to declare themselves "queiscable" and therefore would assert that they will act according to whatever rules we set up. I only want to make sure that this new state is added to existing list of PM states rather than creating completely new facility, so that driver authors have a chance to understand PM state transitions that involve their driver. Thanks, Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
