linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick DELAUNAY <patrick.delaunay@foss.st.com>
To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Alexandre TORGUE <alexandre.torgue@foss.st.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Etienne CARRIERE <etienne.carriere@linaro.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-stm32@st-md-mailman.stormreply.com>,
	Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Subject: Re: [PATCH 3/3] nvmem: stm32: add OP-TEE support for STM32MP13x
Date: Wed, 2 Nov 2022 11:59:28 +0100	[thread overview]
Message-ID: <a4ae3648-2943-55e0-243f-71a3c5f71ad8@foss.st.com> (raw)
In-Reply-To: <99a8d093-13f3-9ff8-6d87-d4aecaec1566@linaro.org>

Hi,

On 11/1/22 08:26, Srinivas Kandagatla wrote:
>
>
> On 28/10/2022 15:52, Patrick Delaunay wrote:
>> For boot with OP-TEE on STM32MP13, the communication with the secure
>> world no more use STMicroelectronics SMC but communication with the
>> BSEC TA, for data access (read/write) or lock operation:
>> - all the request are sent to OP-TEE trusted application,
>> - for upper OTP with ECC protection and with word programming only
>>    each OTP are permanently locked when programmed to avoid ECC error
>>    on the second write operation
>>
>> Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
>> ---
>
> For some reason I pushed this patch without a full review, This is now 
> reverted from nvmem-next.


Ok


>
> Why not add TEE client based new driver instead of ifdefing around 
> this driver? Also I see there is not much common across both drivers 
> anyway.


I hesitate between the 2 solutions. I choose this update to handle the 
STM32MP15 support with OP-TEE.

For backward compatibility reason the same driver STM32 ROMEM associated 
to compatible "st,stm32mp15-bsec" should be kept.

- the lower OTP can directly accessible by Linux (the IP is not secured) 
=> boot with SPL

- the upper OTP and the write operation are requested by 
STMicroelectronics SMCs

    => boot with TF-A SPMIN and old OP-TEE (before migration to STM32 
BSEC PTA)


But in the future OP-TEE the access to OTP should be also done with 
STM32 BSEC PTA...


I can manage this compatibility by detection in STM32 romem driver if 
the booth access are managed in the same driver.

This patch can be added in the serie to understood the detection mechanism.


>
>
>>
>>   drivers/nvmem/stm32-romem.c | 450 +++++++++++++++++++++++++++++++++++-
>>   1 file changed, 446 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/nvmem/stm32-romem.c b/drivers/nvmem/stm32-romem.c
>> index 6de565639d5f..dfdedbcca9b9 100644
>> --- a/drivers/nvmem/stm32-romem.c
>> +++ b/drivers/nvmem/stm32-romem.c
>> @@ -11,6 +11,7 @@
>>   #include <linux/module.h>
>>   #include <linux/nvmem-provider.h>
>>   #include <linux/of_device.h>
>> +#include <linux/tee_drv.h>
>>     /* BSEC secure service access from non-secure */
>>   #define STM32_SMC_BSEC            0x82001003
>> @@ -25,14 +26,22 @@
>>   struct stm32_romem_cfg {
>>       int size;
>>       u8 lower;
>> +    bool ta;
>>   };
>>     struct stm32_romem_priv {
>>       void __iomem *base;
>>       struct nvmem_config cfg;
>>       u8 lower;
>> +    struct device *ta;
>>   };
>>   +struct device *stm32_bsec_pta_find(struct device *dev);
>> +static int stm32_bsec_pta_read(void *context, unsigned int offset, 
>> void *buf,
>> +                   size_t bytes);
>> +static int stm32_bsec_pta_write(void *context, unsigned int offset, 
>> void *buf,
>> +                size_t bytes);
>> +
>>   static int stm32_romem_read(void *context, unsigned int offset, 
>> void *buf,
>>                   size_t bytes)
>>   {
>> @@ -173,15 +182,25 @@ static int stm32_romem_probe(struct 
>> platform_device *pdev)
>>       } else {
>>           priv->cfg.size = cfg->size;
>>           priv->lower = cfg->lower;
>> -        priv->cfg.reg_read = stm32_bsec_read;
>> -        priv->cfg.reg_write = stm32_bsec_write;
>> +        if (cfg->ta) {
>> +            priv->ta = stm32_bsec_pta_find(dev);
>> +            /* wait for OP-TEE client driver to be up and ready */
>> +            if (!priv->ta)
>> +                return -EPROBE_DEFER;
>> +
>> +            priv->cfg.reg_read = stm32_bsec_pta_read;
>> +            priv->cfg.reg_write = stm32_bsec_pta_write;
>> +        } else {
>> +            priv->cfg.reg_read = stm32_bsec_read;
>> +            priv->cfg.reg_write = stm32_bsec_write;
>> +        }
>>       }
>>         return PTR_ERR_OR_ZERO(devm_nvmem_register(dev, &priv->cfg));
>>   }
>>     /*
>> - * STM32MP15 BSEC OTP regions: 4096 OTP bits (with 3072 effective bits)
>> + * STM32MP15/13 BSEC OTP regions: 4096 OTP bits (with 3072 effective 
>> bits)
>>    * => 96 x 32-bits data words
>>    * - Lower: 1K bits, 2:1 redundancy, incremental bit programming
>>    *   => 32 (x 32-bits) lower shadow registers = words 0 to 31
>> @@ -191,6 +210,13 @@ static int stm32_romem_probe(struct 
>> platform_device *pdev)
>>   static const struct stm32_romem_cfg stm32mp15_bsec_cfg = {
>>       .size = 384,
>>       .lower = 32,
>> +    .ta = false,
>> +};
>> +
>> +static const struct stm32_romem_cfg stm32mp13_bsec_cfg = {
>> +    .size = 384,
>> +    .lower = 32,
>> +    .ta = true,
>>   };
>>     static const struct of_device_id stm32_romem_of_match[] = {
>> @@ -198,6 +224,8 @@ static const struct of_device_id 
>> stm32_romem_of_match[] = {
>>           .compatible = "st,stm32mp15-bsec",
>>           .data = (void *)&stm32mp15_bsec_cfg,
>>       }, {
>> +        .compatible = "st,stm32mp13-bsec",
>> +        .data = (void *)&stm32mp13_bsec_cfg,
>
> missing sentinel, which caused a regression in next.


Ok, sorry for my error in the rebase conflict.


Patrick


>
>
> --srini
>>       },
>>   };
>>   MODULE_DEVICE_TABLE(of, stm32_romem_of_match);
>> @@ -209,7 +237,421 @@ static struct platform_driver 
>> stm32_romem_driver = {
>>           .of_match_table = of_match_ptr(stm32_romem_of_match),
>>       },
>>   };
>> -module_platform_driver(stm32_romem_driver);
>> +
>> +#if IS_ENABLED(CONFIG_OPTEE)
>>
....


>> +
>> +module_init(stm32_romem_init);
>> +module_exit(stm32_romem_exit);
>>     MODULE_AUTHOR("Fabrice Gasnier <fabrice.gasnier@st.com>");
>>   MODULE_DESCRIPTION("STMicroelectronics STM32 RO-MEM");

  reply	other threads:[~2022-11-02 10:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-28 14:52 [PATCH 0/3] nvmem: stm32: add OP-TEE support for STM32MP13x Patrick Delaunay
2022-10-28 14:52 ` [PATCH 1/3] dt-bindings: nvmem: add new stm32mp13 compatible for stm32-romem Patrick Delaunay
2022-10-28 15:39   ` Fabrice Gasnier
2022-10-28 14:52 ` [PATCH 2/3] ARM: dts: stm32mp13: fix compatible for BSEC Patrick Delaunay
2022-10-28 14:52 ` [PATCH 3/3] nvmem: stm32: add OP-TEE support for STM32MP13x Patrick Delaunay
2022-11-01  7:26   ` Srinivas Kandagatla
2022-11-02 10:59     ` Patrick DELAUNAY [this message]
2022-11-08 10:03       ` Srinivas Kandagatla
2022-11-09 17:35         ` Patrick DELAUNAY
2022-11-09 18:02           ` Srinivas Kandagatla
2022-11-03 13:18   ` [Linux-stm32] " Fabrice Gasnier
2022-11-07 10:18     ` Patrick DELAUNAY
2022-10-31 17:42 ` [PATCH 0/3] " Srinivas Kandagatla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a4ae3648-2943-55e0-243f-71a3c5f71ad8@foss.st.com \
    --to=patrick.delaunay@foss.st.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=etienne.carriere@linaro.org \
    --cc=fabrice.gasnier@foss.st.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=srinivas.kandagatla@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).