On Tue, 22 Sep 2015, Oliver Neukum wrote: > Indeed. We can handle output to suspended devices by waking them. > I don't see why this case is different. We are talking about input > only. > > > The runtime-PM "usage" value for these devices is a little tricky to > > calculate. It should be nonzero if there are any open files _and_ the > > device isn't "inhibited". I don't know the best way to represent that > > kind of condition in the runtime PM framework. > > Does that make sense in the generic framework at all? I still > think that drivers should cease IO for input in such cases. > That should involve a common callback, but no counter. I'm not sure I understand what you're saying. Are you suggesting that this "inhibit" mechanism should involve a new callback different from the existing runtime-PM callbacks? And when this new callback is invoked, drivers should cancel existing input requests (these devices are input-only) and go to low power? This would create a parallel runtime-PM mechanism which is independent of the existing one. Is that really a good idea? Alan Stern -- 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
