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

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 19 Apr 2021 18:22:53 -0500
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...ainline.org>
Cc:     viresh.kumar@...aro.org, agross@...nel.org, rjw@...ysocki.net,
        devicetree@...r.kernel.org, robh+dt@...nel.org,
        amit.kucheria@...aro.org, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org, phone-devel@...r.kernel.org,
        konrad.dybcio@...ainline.org, marijn.suijten@...ainline.org,
        martin.botka@...ainline.org, jeffrey.l.hugo@...il.com
Subject: Re: [PATCH v4 5/7] cpufreq: qcom-hw: Implement CPRh aware OSM
 programming

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