Re: [Patch v5 4/6] soc: qcom: Extend RPMh power controller driver to register warming devices.

[Bjorn Andersson <bjorn.andersson@linaro.org>]

On Mon 30 Mar 07:53 PDT 2020, Thara Gopinath wrote:
> On 3/27/20 6:53 PM, Bjorn Andersson wrote:
> > On Thu 19 Mar 18:41 PDT 2020, Thara Gopinath wrote:
[..]
> > > +static int __init rpmhpd_init_warming_device(void)
> > > +{
> > > +	size_t num_pds;
> > > +	struct rpmhpd **rpmhpds;
> > > +	int i;
> > > +
> > > +	if (!global_desc)
> > > +		return -EINVAL;
> > > +
> > > +	rpmhpds = global_desc->rpmhpds;
> > > +	num_pds = global_desc->num_pds;
> > > +
> > > +	if (!of_find_property(rpmhpds[0]->dev->of_node, "#cooling-cells", NULL))
> > > +		return 0;
> > > +
> > > +	for (i = 0; i < num_pds; i++)
> > > +		if (rpmhpds[i]->is_warming_dev)
> > > +			of_pd_warming_register(rpmhpds[i]->dev, i);
> > > +
> > > +	return 0;
> > > +}
> > > +late_initcall(rpmhpd_init_warming_device);
> > 
> > ...why can't this be done in rpmhpd_probe()?
> > 
> > In particular with the recent patches from John Stultz to allow rpmhpd
> > to be built as a module I don't think there's any guarantees that
> > rpmh_probe() will have succeeded before rpmhpd_init_warming_device()
> > executes.
> 
> It is to take care of boot order.

Understood.

> So this has to happen after the thermal framework is initialized. Thermal
> framework is initialized with core_initcall. Can I move the rpmhpd init as a
> postcore_initcall ? Then I can get rid of this separate function and keep it
> as part of probe.
> 

So I presume the problem is that if this is called from probe, you might
of_pd_warming_register(), which ends up in
__thermal_cooling_device_register() before thermal_init() has been
invoked? 

Which is bad because e.g. thermal_class is not yet initialized.


I don't want to rely on the order of initcalls for things to work, so
could we make this more robust by having
thermal_of_cooling_device_register() return -EPROBE_DEFER is
thermal_init() isn't done?

Regards,
Bjorn