On Mon, 21 Sep 2015, Dmitry Torokhov wrote:

quoted

What happens if the "inhibit" control is turned on and the driver puts 
the device into runtime suspend, but then an I/O request arrives?

	If the I/O request originated from userspace, it means the
	user is violating the terms of the "inhibit" control.  Should
	the request simply fail?

What user? User that inhibited it or user that tried to use the device?

Normally they would be the same.  But even if they aren't, someone has 
violated the kernel interface: The first user told the kernel a 
particular device wasn't going to be used, and then the second user 
tried to use it.

Of course, this issue doesn't arise for devices that merely report 
external events.

quoted

	What if the I/O request originated from somewhere in the
	kernel, not from the user?

I think we should treat in-kernel users as all other users.

quoted

	Or maybe the driver would want to carry out the request,
	overriding the "inhibit" control temporarily.  Does it simply
	turn off the control, meaning that the device won't go back
	into runtime suspend until userspace turns the control on
	again?

	Or if the driver doesn't turn off the "inhibit" control, then
	how does it know when it can safely put the device back into
	runtime suspend?

Qustions like these make me think that this mechanism is best suited 
for a kind of device that doesn't handle I/O requests.  In other words, 
something that just reports events as they occur -- which is another 
way of describing an input device!

Or maybe IIO device. Or hwmon. Or something else. I think if we allow
drivers (or subsystems) to opt in into this mechanism it will solve much
of worries about disks and similar devices that indeed not very suitable
for such mechanism.

Should the mechanism really be per-device?  Or would it be more useful 
to have a single "inhibit" setting that affected all the relevant 
devices at once?

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.

Alan Stern