Re: [PATCH v4 2/2] PM: runtime: Add Example Driver Patterns section

[Rafael J. Wysocki (Intel)]

On Fri, Oct 16, 2026 at 8:05 PM Rafael J. Wysocki (Intel)
<rafael@xxxxxxxxxx> wrote:
>
> On Fri, Oct 16, 2026 at 7:42 PM Rafael J. Wysocki (Intel)
> <rafael@xxxxxxxxxx> wrote:
> > On Thu, Oct 15, 2026 at 10:55 PM Brian Norris <briannorris@xxxxxxxxxxxx> wrote:
> > > On Thu, Oct 15, 2026 at 10:11:04PM +0200, Rafael J. Wysocki (Intel) wrote:
> > > > On Wed, Oct 14, 2026 at 10:15 PM Brian Norris <briannorris@xxxxxxxxxxxx> wrote:
> > > > > On Wed, Oct 14, 2026 at 09:07:54PM +0200, Rafael J. Wysocki (Intel) wrote:
> > > > > > On Thu, Oct 1, 2026 at 5:51 PM Brian Norris <briannorris@xxxxxxxxxxxx> wrote:
> > > > > > >
>
> [cut]
>
> > >
> > > I kinda think the point of most of this power domain architecture is
> > > that a typical driver just doesn't have to worry about it at all (in
> > > probe(), and if you use runtime PM properly), so I'd prefer not
> > > mentioning it in the Basic example. But sure.
> >
> > Well, your basic example needs to be put in a certain context because
> > it may not be generally applicable everywhere.
> >
> > I think that you should make it clear what the driver's expectations
> > regarding the physical state of the device at the probe time are and
> > the general rule is that it is better to leave the device in the same
> > state in which it is expected to be found next time.
>
> To be somewhat more precise, if the driver expects to find the device
> completely off and the runtime PM callbacks are set up to make it
> operational, runtime PM can be used to power it up in probe:
>
> /* Assume the runtime PM status to be "suspended". */
> pm_runtime_enable(dev);
> pm_runtime_get_sync(dev);
>
> but then in remove or on probe errors the "power off" state needs to
> be restored manually:
>
> pm_runtime_disable(dev);
> /* Allow the parent and suppliers (if any) to suspend. */
> pm_runtime_set_suspended(dev);
> device_specific_power_off(dev);
>
> However, if the driver expects to find the device operational (for
> example, because it assumes the ACPI PM domain to be there), it may
> just update the runtime PM status before enabling runtime PM:
>
> /* Assume the runtime PM status to be "suspended". */
> pm_runtime_set_active(dev);

And I forgot to add

pm_runtime_get_noresume(dev);

here (to prevent runtime suspend from being triggered by toggling the
"control" sysfs attribute from "on" to "auto" at this point).

> pm_runtime_enable(dev);
>
> but then in remove or on probe errors it may just leave the device in
> its current physical state (whatever it is) and assume somebody else
> to take care of turning it off subsequently:
>
> pm_runtime_disable(dev);
> /* Allow the parent and suppliers (if any) to suspend. */
> pm_runtime_set_suspended(dev);
>
> These are two distinct cases that are rather hard to cover in one
> simple example.