Re: [PATCH v4 5/7] cpufreq: qcom-hw: Implement CPRh aware OSM programming

[Bjorn Andersson]

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