Re: [PATCH] pinctrl: qcom: Enable device links to consumers

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Fri, May 24, 2019 at 1:16 AM Stephen Boyd <swboyd@xxxxxxxxxxxx> wrote:
> Quoting Linus Walleij (2019-05-23 12:26:20)
> > On Thu, May 23, 2019 at 7:52 PM Stephen Boyd <swboyd@xxxxxxxxxxxx> wrote:

> > AFAIK it does not, the device links however can do this so that
> > the probe order does not have to use deferral at all.
>
> I'm not too worried about using device links for probe ordering. I'm
> saying that this probe defer logic in drivers/base/dd.c already takes
> care of reordering the list so suspend/resume will be correct.
>
>                 /*
>                  * Force the device to the end of the dpm_list since
>                  * the PM code assumes that the order we add things to
>                  * the list is a good order for suspend but deferred
>                  * probe makes that very unsafe.
>                  */
>                 device_pm_move_to_tail(dev);
>
> Basically all providers will come before consumers and then suspend will
> run through the list in reverse and suspend consumers first before
> providers.

Okay! News2me. :) and very good and intuitive in a way.

> > But the
> > links can also be added later at runtime (like when pin control
> > states are requested by drivers) and that is what this patch
> > does.
>
> Ok, great! So if some consumer is only informing the provider of the
> driver dependency after probe succeeds then this will help by fixing the
> list order. This is what I'm looking for. It's unfortunate that devices
> aren't getting all resources in probe so this could be avoided.

Yeah :/

I'm still figuring out the details because device links are new
to me: not many callers in the kernel, but the regulators are
using it so it seems like the way to go. I will probably have to
add something similar for GPIO descriptors as for pin control
handles so the GPIO providers get a strict suspend/resume
order too.

> > >I can understand that runtime suspend may be important because
> > > order of suspend isn't fixed, but system suspend should be unaffected,
> > > right?
> >
> > AFAIK both runtime PM and system suspend use the device
> > links, this was implemented especially for system suspend/resume
> > and tested with the STMFX driver on STM32.
>
> Yes that's my understanding too.

I'm unsure if it's actually the reuse of runtime PM runtime
suspend/resume path for the main suspend/resume path that is
causing this behaviour. It's good if they both do it the same way.

The flag DL_FLAG_PM_RUNTIME should maybe be renamed
DL_FLAG_PM but Rafael and Ulf knows these semantics better.

Yours,
Linus Walleij