On Mon 19 Apr 15:59 CDT 2021, AngeloGioacchino Del Regno wrote:

Il 19/04/21 20:52, Bjorn Andersson ha scritto:

quoted

On Tue 19 Jan 11:45 CST 2021, AngeloGioacchino Del Regno wrote:

[..]

quoted

quoted

+static int qcom_cpufreq_hw_acd_init(struct device *cpu_dev,
+				    struct cpufreq_policy *policy,
+				    int index)
+{

[..]

quoted

quoted

+	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 ;)

[..]

quoted

quoted

  static int qcom_cpufreq_hw_driver_probe(struct platform_device *pdev)

[..]

quoted

quoted

+		/*
+		 * 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