rpmpd(and maybe qcom-cpufreq-nvmem?) are broken on sdm632 about linux HOT 12 CLOSED

While investigating the issue I found a code path that could lead to a null pointer dereference or similar in _add_opp_table_indexed. Maybe that's why we are having that kernel oops.

struct opp_table *_add_opp_table_indexed(struct device *dev, int index,
					 bool getclk)
{

...

	if (opp_table) {
		if (!_add_opp_dev(dev, opp_table)) {
			dev_pm_opp_put_opp_table(opp_table);
			opp_table = ERR_PTR(-ENOMEM);               <----
		}
	        mutex_lock(&opp_table_lock);
	} else {
		opp_table = _allocate_opp_table(dev, index);

		mutex_lock(&opp_table_lock);
		if (!IS_ERR(opp_table))
			list_add(&opp_table->node, &opp_tables);
	}

	opp_tables_busy = false;

unlock:
	mutex_unlock(&opp_table_lock);

	return _update_opp_table_clk(dev, opp_table, getclk);     <---- (this functions tries to access a struct field of opp_table without checking if the pointer is invalid)
}

from linux.

Nevermind, i didn't see the IS_ERR() in _update_opp_table_clk

from linux.

Now i got something

/mnt/linux # cat trace.txt | CROSS_COMPILE=aarch64-alpine-linux-musl- ./scripts/decode_stacktrace.sh .output/vmlinux ./
[    1.618458] Call trace:
[    1.618461] _of_add_table_indexed (/mnt/linux/.output/../drivers/opp/of.c:373 /mnt/linux/.output/../drivers/opp/of.c:1053 /mnt/linux/.output/../drivers/opp/of.c:1148)
[    1.618472] dev_pm_opp_of_add_table_indexed (/mnt/linux/.output/../drivers/opp/of.c:1235) 
[    1.618481] of_genpd_add_provider_onecell (/mnt/linux/.output/../drivers/base/power/domain.c:2380) 

Here's the issue:

Here's the code (put_np is at the end of the function):

from linux.

Lol I found what the error was...

Compatible has to be operating-points-v2. No wonder it was reading a null opp table...

I just tested it and its working...

from linux.

Can you test changing the compatible and see if that's it?

from linux.

According to docs, standalone operating-points-v2-kryo-cpu compatible is a legit use case (and also used on msm8996 & qcs404, but operating-points-v2-qcom-cpu isn't documented anywhere. Removing the latter doesn't change anything though.

Are you sure that the cpufreq driver probes correctly when you set compatible to operating-points-v2?

from linux.

Okay right, it's failing with -ENOENT. But at least now it doesn't crash...
[ 1.296503] qcom-cpufreq-nvmem: probe of qcom-cpufreq-nvmem failed with error -2

Maybe something's missing in the DT?

from linux.

Yes, also commenting the nvmem-cells = <&cpu_speed_bin>; in dt makes probe fail and boot succeed.

I guess the bug lies in either b052d04 (which looks quite hacky tbh and looks like it might cause stuff like this) or 664d2ef and presumably doing things that shouldn't be done.

from linux.

Temporarily worked around with b265c06, I believe

from linux.

Fixed in 6.0.10 branch, the compatible for the spmi regulator that cpr uses was wrong so it didn't probe

from linux.

Can you test it in both sdm625 and 632?

from linux.

Is this still relevant?

from linux.