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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
