On Wed, Jul 10, 2019 at 12:00:26PM +0530, Viresh Kumar wrote:
> On 05-07-19, 11:57, Niklas Cassel wrote:
> > + drv->opp_tables = kcalloc(num_possible_cpus(), sizeof(*drv->opp_tables),
> > + GFP_KERNEL);
> > + if (!drv->opp_tables) {
> > + ret = -ENOMEM;
> > + goto free_drv;
> > + }
> >
> > for_each_possible_cpu(cpu) {
> > cpu_dev = get_cpu_device(cpu);
> > @@ -166,19 +195,23 @@ static int qcom_cpufreq_probe(struct platform_device
> > *pdev)
> > goto free_opp;
> > }
> >
> > - opp_tables[cpu] = dev_pm_opp_set_supported_hw(cpu_dev,
> > - &versions, 1);
> > - if (IS_ERR(opp_tables[cpu])) {
> > - ret = PTR_ERR(opp_tables[cpu]);
> > - dev_err(cpu_dev, "Failed to set supported hardware\n");
> > - goto free_opp;
> > + if (drv->data->get_version) {
>
> Why depend on get_version here ? The OPP table is already allocated
> unconditionally.
Since the reading of the speedbin efuse is now optional,
it is now inside "if (drv->data->get_version)".
So if I don't also protect "dev_pm_opp_set_supported_hw()"
with "if (drv->data->get_version)" I get:
[ 3.135092] cpu cpu0: _opp_is_supported: failed to read opp-supported-hw
property at index 0: -22
[ 3.139364] cpu cpu0: _opp_is_supported: failed to read opp-supported-hw
property at index 0: -22
[ 3.148330] cpu cpu0: _opp_is_supported: failed to read opp-supported-hw
property at index 0: -22
Probably since drv->versions is initialized to 0,
and if there is no opp-supported-hw in device tree,
OPP framework prints failures.
So it feels safest to only call dev_pm_opp_set_supported_hw()
if we know that we are supposed to parse the speedbin efuse.
Kind regards,
Niklas
>
> > + drv->opp_tables[cpu] =
> > + dev_pm_opp_set_supported_hw(cpu_dev,
> > + &drv->versions, 1);
> > + if (IS_ERR(drv->opp_tables[cpu])) {
> > + ret = PTR_ERR(drv->opp_tables[cpu]);
> > + dev_err(cpu_dev,
> > + "Failed to set supported hardware\n");
> > + goto free_opp;
> > + }
> > }
> > }
>
> --
> viresh
