[PATCH 2/5] cpuidle: psci: Fix error path via converting to a platform driver

[Ulf Hansson]

On Fri, 26 Jun 2020 at 16:42, Sudeep Holla <sudeep.holla at arm.com> wrote:
>
> On Mon, Jun 15, 2020 at 05:20:51PM +0200, Ulf Hansson wrote:
> > The current error paths for the cpuidle-psci driver, may leak memory or
> > possibly leave CPU devices attached to their PM domains. These are quite
> > harmless issues, but still deserves to be taken care of.
> >
> > Although, rather than fixing them by keeping track of allocations that
> > needs to be freed, which tends to become a bit messy, let's convert into a
> > platform driver. In this way, it gets easier to fix the memory leaks as we
> > can rely on the devm_* functions.
> >
> > Moreover, converting to a platform driver also enables support for deferred
> > probe, which subsequent changes takes benefit from.
> >
>
> Though I don't have strong opinion, I don't like platform device for cpuidle.
> But that's not main issue. I am more worried about the need for whole
> deferred probe for cpuidle. Is this due to OSI and Qcom dependencies ?
> Ideally, the firmware is already to accept suspend calls soon after they
> are powered on in psci f/w.

I agree that a platform device for cpuidle isn't very nice, but that's
the best I could figure out to use. If you have a better idea, please
tell me.

>From the PSCI FW point of view you are right. Everything is ready.

So, yes, as you stated, this boils down to the initialization of the
PSCI PM domains, registered in cpuidle-psci-domain.c, which I am
converting to platform driver in patch4. That change means that
cpuidle-psci-domain driver are about to support deferred probe (and
more importantly the ->sync_state() callback), which means that when
psci_dt_attach_cpu() is called, it may return -EPROBE_DEFER - hence we
should cope with it.

I hope this further clarifies the reason behind $subject patch!?

Thanks for reviewing!

Kind regards
Uffe