On Mon 19 Apr 15:59 CDT 2021, AngeloGioacchino Del Regno wrote:
> Il 19/04/21 20:52, Bjorn Andersson ha scritto:
> > On Tue 19 Jan 11:45 CST 2021, AngeloGioacchino Del Regno wrote:
[..]
> > > +static int qcom_cpufreq_hw_acd_init(struct device *cpu_dev,
> > > + struct cpufreq_policy *policy,
> > > + int index)
> > > +{
[..]
> > > + acd_resname = kasprintf(GFP_KERNEL, "osm-acd%d", index);
> >
> > How about just sprintf() into a 10 byte array on the stack?
> >
>
> My motto, apart the clearly possible chance to get 1000 clusters in the
> future (lol), is to free the (very little) memory as soon as I'm done with
> it.
>
> Was I too much paranoid there again? :)))
>
Feel free to waste a couple of extra bytes in that array then ;)
[..]
> > > static int qcom_cpufreq_hw_driver_probe(struct platform_device *pdev)
[..]
> > > + /*
> > > + * If the power domain device is not registered yet, then
> > > + * defer probing this driver until that is available.
> > > + */
> > > + pd_dev = of_find_device_by_node(pd_node);
> > > + if (!pd_dev || !pd_dev->dev.driver ||
> > > + !device_is_bound(&pd_dev->dev))
> > > + return -EPROBE_DEFER;
> >
> > I wonder if there's a more appropriate way to probe defer on resources
> > described in the CPU nodes...
> >
>
> I was wondering the same. I had nightmares about this one.
> If there's any better way... please, let me know!
>
Let's see if Viresh has any good suggestions, otherwise let's stick with
this for now.
>
> P.S.: There is a v5 of this (and CPR3) set(s) that I had sent immediately
> after this v4, back in January, addressing the big abuse of the OPP API that
> is present in the v4 (this) version of the driver.
>
May I ask for you to incorporate the changes I pointed out here and post
a v6 instead of me re-reviewing v5? I'll make sure to prioritize the
next round.
Thanks,
Bjorn
