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]
Message-Id: <20220416025637.83484-5-y.oudjana@protonmail.com>
Date:   Sat, 16 Apr 2022 06:56:32 +0400
From:   Yassine Oudjana <yassine.oudjana@...il.com>
To:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Ilia Lin <ilia.lin@...nel.org>,
        Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
        "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Loic Poulain <loic.poulain@...aro.org>,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
        linux-pm@...r.kernel.org,
        Yassine Oudjana <y.oudjana@...tonmail.com>
Subject: [PATCH RESEND v2 4/9] cpufreq: qcom_cpufreq_nvmem: Simplify reading kryo speedbin

MSM8996 and MSM8996 Pro have different OPPs with different dependencies on
CPR and CBF levels. Sharing the same OPP tables will make implementing CPR
and CBF scaling quite difficult, as it will become necessary to use
opp-supported-hw not only to choose CPU OPPs, but to also choose their
required CPR and CBF OPPs which are different on the same CPU OPP between
MSM8996 and MSM8996 Pro. The best solution would be to make a new device
tree for MSM8996 Pro which would override the OPP tables from the existing
MSM8996 device tree.

In preparation for adding a separate device tree for MSM8996 Pro, skip
reading msm-id from smem and just read the speedbin efuse.

Signed-off-by: Yassine Oudjana <y.oudjana@...tonmail.com>
---
 drivers/cpufreq/Kconfig.arm          |  1 -
 drivers/cpufreq/qcom-cpufreq-nvmem.c | 75 +++-------------------------
 2 files changed, 6 insertions(+), 70 deletions(-)

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 954749afb5fe..7d9798bc5753 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -154,7 +154,6 @@ config ARM_QCOM_CPUFREQ_NVMEM
 	tristate "Qualcomm nvmem based CPUFreq"
 	depends on ARCH_QCOM
 	depends on QCOM_QFPROM
-	depends on QCOM_SMEM
 	select PM_OPP
 	help
 	  This adds the CPUFreq driver for Qualcomm Kryo SoC based boards.
diff --git a/drivers/cpufreq/qcom-cpufreq-nvmem.c b/drivers/cpufreq/qcom-cpufreq-nvmem.c
index 6dfa86971a75..a2b895a930cb 100644
--- a/drivers/cpufreq/qcom-cpufreq-nvmem.c
+++ b/drivers/cpufreq/qcom-cpufreq-nvmem.c
@@ -9,8 +9,8 @@
  * based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
  * defines the voltage and frequency value based on the msm-id in SMEM
  * and speedbin blown in the efuse combination.
- * The qcom-cpufreq-nvmem driver reads the msm-id and efuse value from the SoC
- * to provide the OPP framework with required information.
+ * The qcom-cpufreq-nvmem driver reads efuse value from the SoC to provide the
+ * OPP framework with required information.
  * This is used to determine the voltage and frequency value for each OPP of
  * operating-points-v2 table when it is parsed by the OPP framework.
  */
@@ -27,22 +27,6 @@
 #include <linux/pm_domain.h>
 #include <linux/pm_opp.h>
 #include <linux/slab.h>
-#include <linux/soc/qcom/smem.h>
-
-#define MSM_ID_SMEM	137
-
-enum _msm_id {
-	MSM8996V3 = 0xF6ul,
-	APQ8096V3 = 0x123ul,
-	MSM8996SG = 0x131ul,
-	APQ8096SG = 0x138ul,
-};
-
-enum _msm8996_version {
-	MSM8996_V3,
-	MSM8996_SG,
-	NUM_OF_MSM8996_VERSIONS,
-};
 
 struct qcom_cpufreq_drv;
 
@@ -142,35 +126,6 @@ static void get_krait_bin_format_b(struct device *cpu_dev,
 	dev_dbg(cpu_dev, "PVS version: %d\n", *pvs_ver);
 }
 
-static enum _msm8996_version qcom_cpufreq_get_msm_id(void)
-{
-	size_t len;
-	u32 *msm_id;
-	enum _msm8996_version version;
-
-	msm_id = qcom_smem_get(QCOM_SMEM_HOST_ANY, MSM_ID_SMEM, &len);
-	if (IS_ERR(msm_id))
-		return NUM_OF_MSM8996_VERSIONS;
-
-	/* The first 4 bytes are format, next to them is the actual msm-id */
-	msm_id++;
-
-	switch ((enum _msm_id)*msm_id) {
-	case MSM8996V3:
-	case APQ8096V3:
-		version = MSM8996_V3;
-		break;
-	case MSM8996SG:
-	case APQ8096SG:
-		version = MSM8996_SG;
-		break;
-	default:
-		version = NUM_OF_MSM8996_VERSIONS;
-	}
-
-	return version;
-}
-
 static int qcom_cpufreq_kryo_name_version(struct device *cpu_dev,
 					  struct nvmem_cell *speedbin_nvmem,
 					  char **pvs_name,
@@ -178,30 +133,13 @@ static int qcom_cpufreq_kryo_name_version(struct device *cpu_dev,
 {
 	size_t len;
 	u8 *speedbin;
-	enum _msm8996_version msm8996_version;
 	*pvs_name = NULL;
 
-	msm8996_version = qcom_cpufreq_get_msm_id();
-	if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
-		dev_err(cpu_dev, "Not Snapdragon 820/821!");
-		return -ENODEV;
-	}
-
 	speedbin = nvmem_cell_read(speedbin_nvmem, &len);
 	if (IS_ERR(speedbin))
 		return PTR_ERR(speedbin);
 
-	switch (msm8996_version) {
-	case MSM8996_V3:
-		drv->versions = 1 << (unsigned int)(*speedbin);
-		break;
-	case MSM8996_SG:
-		drv->versions = 1 << ((unsigned int)(*speedbin) + 4);
-		break;
-	default:
-		BUG();
-		break;
-	}
+	drv->versions = 1 << (unsigned int)(*speedbin);
 
 	kfree(speedbin);
 	return 0;
@@ -464,10 +402,9 @@ static const struct of_device_id qcom_cpufreq_match_list[] __initconst = {
 MODULE_DEVICE_TABLE(of, qcom_cpufreq_match_list);
 
 /*
- * Since the driver depends on smem and nvmem drivers, which may
- * return EPROBE_DEFER, all the real activity is done in the probe,
- * which may be defered as well. The init here is only registering
- * the driver and the platform device.
+ * Since the driver depends on the nvmem driver, which may return EPROBE_DEFER,
+ * all the real activity is done in the probe, which may be defered as well.
+ * The init here is only registering the driver and the platform device.
  */
 static int __init qcom_cpufreq_init(void)
 {
-- 
2.35.1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ