linux-kernel - [regression 4.20-rc1, bisected] cpufreq fails to register on db820c

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

Message-ID: <20181106012928.GA32044@centauri.lan>
Date:   Tue, 6 Nov 2018 02:29:28 +0100
From:   Niklas Cassel <niklas.cassel@...aro.org>
To:     bgolaszewski@...libre.com
Cc:     srinivas.kandagatla@...aro.org, viresh.kumar@...aro.org,
        linux-kernel@...r.kernel.org
Subject: [regression 4.20-rc1, bisected] cpufreq fails to register on db820c

Hello Bartosz,

I've run into a regression on v4.20-rc1, where cpufreq on dragonboard 820c
fails to register.

I've bisected the issue to:
e888d445ac33 ("nvmem: resolve cells from DT at registration time")

If I revert that patch, cpufreq starts working on dragonboard 820c again.


Before your patch:
[    5.052985] qcom_cpufreq_kryo_probe:110 speedbin_nvmem: ffff8000d4d51e00
[    5.053133] qcom_cpufreq_kryo_probe:120 speedbin: ffff8000d4d51d00
[    5.058895] qcom_cpufreq_kryo_probe:121 *speedbin: 0


After your patch:
[    4.791664] qcom_cpufreq_kryo_probe:110 speedbin_nvmem: ffff8000d472ed00
[    4.791815] qcom_cpufreq_kryo_probe:120 speedbin: ffff8000d451b300
[    4.797575] qcom_cpufreq_kryo_probe:121 *speedbin: 12


The prints are debug prints that I've added locally:

--- a/drivers/cpufreq/qcom-cpufreq-kryo.c
+++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
@@ -107,6 +107,7 @@ static int qcom_cpufreq_kryo_probe(struct platform_device *pdev)
        }
 
        speedbin_nvmem = of_nvmem_cell_get(np, NULL);
+       pr_err("%s:%d speedbin_nvmem: %lx\n", __func__, __LINE__, speedbin_nvmem);
        of_node_put(np);
        if (IS_ERR(speedbin_nvmem)) {
                if (PTR_ERR(speedbin_nvmem) != -EPROBE_DEFER)
@@ -116,6 +117,8 @@ static int qcom_cpufreq_kryo_probe(struct platform_device *pdev)
        }
 
        speedbin = nvmem_cell_read(speedbin_nvmem, &len);
+       pr_err("%s:%d speedbin: %lx\n", __func__, __LINE__, speedbin);
+       pr_err("%s:%d *speedbin: %u\n", __func__, __LINE__, (unsigned int)(*speedbin));
        nvmem_cell_put(speedbin_nvmem);
        if (IS_ERR(speedbin))
                return PTR_ERR(speedbin);


So it appears that the read from nvmem_cell_read()
gets another value after your commit.

This value is then given to dev_pm_opp_set_supported_hw(),
however, since this new value (12) from nvmem_cell_read()
doesn't have any matching opp-supported-hw in device tree,
cpufreq fails to register.

This error only happens when we read this new incorrect value
(12 instead of 0).
Any idea why nvmem_cell_read() returns a new value for the
same efuse?


Kind regards,
Niklas