I'd say no.
Anyway, even though it is very tempting to declare inhibit a "deeper" state of
runtime suspend maybe you are right and inhibit should really be separate from
PM and drivers would have to sort out all the possible state permutations.
Considering input devices:
input_open(): check if device is inhibited, if so do nothing. Otherwise try
waking up itself and parent (via pm_runtime_get_sync() on itself), this will
power up the device. Do additional configuration if needed.
input_close(): check if device is inhibited, if not do pm_runtime_put (_sync?
to make sure we power off properly and not leave device up and running? or
should we power down manually not waiting for runtime PM)?
inhibit(): check if device is opened, if opened do pm_runtime_put_sync().
uninhibit(): if device is opened do pm_runtime_get_sync(), let runtime PM
bring up the device. Do additional config if needed -> very similar to
input_open(), different condition.
runtime_suspend(): power down the device. If not inhibited enable as wakeup
source.
runtime_resume(): power up the device if device is opened and not inhibited.
system_suspend(): check if device is opened, not inhibited and not in
runtimesuspend already; power down.
system_resume(): power up the device if it is opened and not inhibited. I
guess it's OK to wake up device that shoudl be runtime-PM-idle since it will
go to back sleep shortly.
Ugh.. This is complicated...