lkml.org 
[lkml]   [2023]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v5 2/2] nvmem: sec-qfprom: Add Qualcomm secure QFPROM support
From
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@quicinc.com>
> ---
> 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

> + .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

\
 
 \ /
  Last update: 2023-07-27 08:40    [W:0.145 / U:0.428 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site