lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 30 Mar 2020 15:29:33 -0700
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Thara Gopinath <thara.gopinath@...aro.org>
Cc:     rui.zhang@...el.com, ulf.hansson@...aro.org,
        daniel.lezcano@...aro.org, agross@...nel.org, robh@...nel.org,
        amit.kucheria@...durent.com, mark.rutland@....com,
        rjw@...ysocki.net, linux-pm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [Patch v5 4/6] soc: qcom: Extend RPMh power controller driver to
 register warming devices.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ