On Thu, 21 Jun 2018, Roger Quadros wrote:
> >>> probe()
> >>> pm_runtime_forbid() 1
>
> Can you call pm_runtime_forbid() before pm_runtime_enable()?
> Wouldn't it fail with -EACCES as dev->power.disable_depth > 0?
Look, there has been a lot of confusion in this email thread. Let's
get some things straightened out before it goes much farther.
There are only a very few reasons for ever calling pm_runtime_forbid()
or pm_runtime_allow() at any time other than just before the device is
registered. In fact, I can only think of one reason at the moment:
If a device belongs to a class which is well known to have
excellent support for runtime PM, a driver might want to
call pm_runtime_allow().
But in general, a driver should not call these routines. The decision
about whether or not a device should be allowed to go into runtime
suspend is a policy matter and therefore should be decided by the
user, not by the kernel. Furthermore, these calls merely set a default
value; the default can be overridden by the user at any time and
therefore a driver cannot depend on these functions for anything.
Another point of confusion involves balancing pm_runtime_get_* and
pm_runtime_put_* calls. They should always end up in balance, and at
any moment there never should be more put's than get's except in one
very particular circumstance:
The bus system may guarantee to invoke probe callbacks after
performing an extra get, and to perform an extra put after
invoking remove callbacks (the PCI subsystem does this).
This can be useful when a lot of drivers don't support runtime
PM; the extra get insures that the PM core will never try to
suspend the device while such a driver is bound to it. A
driver that _does_ support runtime PM would do an extra
pm_runtime_put at the end of its probe routine and an extra
pm_runtime_get_sync in its remove routine; this will allow
runtime PM to work while keeping the counts non-negative.
That's the only situation I know of where it's reasonable to have more
puts than gets. The PCI subsystem does this, and to be perfectly
honest, I do not remember why local_pci_probe() recommends that drivers
call pm_runtime_put_noidle rather than pm_runtime_put. On the face of
it, this would allow the PM usage counter to go to 0 without triggering
an immediate runtime suspend.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
