Messages in this thread | | | Date | Thu, 27 Jul 2023 18:56:34 +0530 | Subject | Re: [PATCH v5 2/2] nvmem: sec-qfprom: Add Qualcomm secure QFPROM support | From | Mukesh Ojha <> |
| |
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@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
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
| |