Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <9fd66ca4-36f2-e6c2-fdb3-76e00e1e954b@quicinc.com>
Date:   Thu, 27 Jul 2023 18:56:34 +0530
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Subject: Re: [PATCH v5 2/2] nvmem: sec-qfprom: Add Qualcomm secure QFPROM
 support
Content-Language: en-US
From:   Mukesh Ojha <quic_mojha@quicinc.com>
To:     Komal Bajaj <quic_kbajaj@quicinc.com>, <agross@kernel.org>,
        <andersson@kernel.org>, <konrad.dybcio@linaro.org>,
        <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>,
        <conor+dt@kernel.org>, <srinivas.kandagatla@linaro.org>
CC:     <linux-arm-msm@vger.kernel.org>, <devicetree@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>
References: <20230724083849.8277-1-quic_kbajaj@quicinc.com>
 <20230724083849.8277-3-quic_kbajaj@quicinc.com>
 <9f417fea-38cf-942b-514e-99b47f27c544@quicinc.com>
In-Reply-To: <9f417fea-38cf-942b-514e-99b47f27c544@quicinc.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


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