Re: [PATCH v5 2/2] nvmem: sec-qfprom: Add Qualcomm secure QFPROM support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 7/27/2023 12:09 PM, Mukesh Ojha wrote:
Hi,

Some questions, may not need to be addressed if the reason is
known

On 7/24/2023 2:08 PM, Komal Bajaj wrote:
For some of the Qualcomm SoC's, it is possible that
some of the fuse regions or entire qfprom region is
protected from non-secure access. In such situations,
Linux will have to use secure calls to read the region.
With that motivation, add secure qfprom driver.

Signed-off-by: Komal Bajaj <quic_kbajaj@xxxxxxxxxxx>
---
  drivers/nvmem/Kconfig      |  13 +++++
  drivers/nvmem/Makefile     |   2 +
  drivers/nvmem/sec-qfprom.c | 101 +++++++++++++++++++++++++++++++++++++
  3 files changed, 116 insertions(+)
  create mode 100644 drivers/nvmem/sec-qfprom.c

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index b291b27048c7..764fc5feb26c 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -216,6 +216,19 @@ config NVMEM_QCOM_QFPROM
        This driver can also be built as a module. If so, the module
        will be called nvmem_qfprom.

+config NVMEM_QCOM_SEC_QFPROM
+        tristate "QCOM SECURE QFPROM Support"
+        depends on ARCH_QCOM || COMPILE_TEST
+        depends on HAS_IOMEM
+        depends on OF
+        select QCOM_SCM
+        help
+          Say y here to enable secure QFPROM support. The secure QFPROM provides access +          functions for QFPROM data to rest of the drivers via nvmem interface.
+
+          This driver can also be built as a module. If so, the module will be called
+          nvmem_sec_qfprom.
+
  config NVMEM_RAVE_SP_EEPROM
      tristate "Rave SP EEPROM Support"
      depends on RAVE_SP_CORE
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index f82431ec8aef..e248d3daadf3 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -44,6 +44,8 @@ obj-$(CONFIG_NVMEM_NINTENDO_OTP)    += nvmem-nintendo-otp.o
  nvmem-nintendo-otp-y            := nintendo-otp.o
  obj-$(CONFIG_NVMEM_QCOM_QFPROM)        += nvmem_qfprom.o
  nvmem_qfprom-y                := qfprom.o
+obj-$(CONFIG_NVMEM_QCOM_SEC_QFPROM)    += nvmem_sec_qfprom.o
+nvmem_sec_qfprom-y            := sec-qfprom.o

Are we just doing this for just renaming the object ?

  obj-$(CONFIG_NVMEM_RAVE_SP_EEPROM)    += nvmem-rave-sp-eeprom.o
  nvmem-rave-sp-eeprom-y            := rave-sp-eeprom.o
  obj-$(CONFIG_NVMEM_RMEM)         += nvmem-rmem.o
diff --git a/drivers/nvmem/sec-qfprom.c b/drivers/nvmem/sec-qfprom.c
new file mode 100644
index 000000000000..bc68053b7d94
--- /dev/null
+++ b/drivers/nvmem/sec-qfprom.c
@@ -0,0 +1,101 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include <linux/firmware/qcom/qcom_scm.h>
+#include <linux/mod_devicetable.h>
+#include <linux/nvmem-provider.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+
+/**
+ * struct sec_qfprom - structure holding secure qfprom attributes
+ *
+ * @base: starting physical address for secure qfprom corrected address space.
+ * @dev: qfprom device structure.
+ */
+struct sec_qfprom {
+    phys_addr_t base;
+    struct device *dev;
+};
+
+static int sec_qfprom_reg_read(void *context, unsigned int reg, void *_val, size_t bytes)
+{
+    struct sec_qfprom *priv = context;
+    unsigned int i;
+    u8 *val = _val;
+    u32 read_val;
+    u8 *tmp;
+
+    for (i = 0; i < bytes; i++, reg++) {
+        if (i == 0 || reg % 4 == 0) {
+            if (qcom_scm_io_readl(priv->base + (reg & ~3), &read_val)) {
+                dev_err(priv->dev, "Couldn't access fuse register\n");
+                return -EINVAL;
+            }
+            tmp = (u8 *)&read_val;
+        }
+
+        val[i] = tmp[reg & 3];
+    }

Getting secure read from fuse region is fine here, since we have to read
4 byte from trustzone, but this restriction of reading is also there
for sm8{4|5}50 soc's where byte by byte reading is protected and granularity set to 4 byte (qfprom_reg_read() in drivers/nvmem/qfprom.c)
is will result in abort, in  that case this function need to export this
logic.

+
+    return 0;
+}
+
+static int sec_qfprom_probe(struct platform_device *pdev)
+{
+    struct nvmem_config econfig = {
+        .name = "sec-qfprom",
+        .stride = 1,
+        .word_size = 1,
+        .id = NVMEM_DEVID_AUTO,
+        .reg_read = sec_qfprom_reg_read,
+    };
+    struct device *dev = &pdev->dev;
+    struct nvmem_device *nvmem;
+    struct sec_qfprom *priv;
+    struct resource *res;
+    int ret;
+
+    priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+    if (!priv)
+        return -ENOMEM;
+
+    res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+    if (!res)
+        return -EINVAL;
+
+    priv->base = res->start;
+
+    econfig.size = resource_size(res);
+    econfig.dev = dev;
+    econfig.priv = priv;
+
+    priv->dev = dev;
+
+    ret = devm_pm_runtime_enable(dev);
+    if (ret)
+        return ret;
+
+    nvmem = devm_nvmem_register(dev, &econfig);
+
+    return PTR_ERR_OR_ZERO(nvmem);
+}
+
+static const struct of_device_id sec_qfprom_of_match[] = {
+    { .compatible = "qcom,sec-qfprom" },
+    {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, sec_qfprom_of_match);
+
+static struct platform_driver qfprom_driver = {
+    .probe = sec_qfprom_probe,

Why don't we have remove/remove_new callbacks?
Same comment apply for drivers/nvmem/qfprom.c

Ignore this comment; Something new learnt with devm_* api
implementation.

-Mukesh

+    .driver = {
+        .name = "qcom_sec_qfprom",
+        .of_match_table = sec_qfprom_of_match,
+    },
+};
+module_platform_driver(qfprom_driver);
+MODULE_DESCRIPTION("Qualcomm Secure QFPROM driver");
+MODULE_LICENSE("GPL");
--
2.40.1


-Mukesh



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux