[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250422043635.GA27670@nxa18884-linux>
Date: Tue, 22 Apr 2025 14:30:52 +0800
From: Peng Fan <peng.fan@....nxp.com>
To: Frieder Schrempf <frieder@...s.de>
Cc: Peng Fan <peng.fan@....com>, Pankaj Gupta <pankaj.gupta@....com>,
linux-arm-kernel@...ts.infradead.org,
Conor Dooley <conor+dt@...nel.org>, devicetree@...r.kernel.org,
imx@...ts.linux.dev, Krzysztof Kozlowski <krzk+dt@...nel.org>,
linux-kernel@...r.kernel.org, Rob Herring <robh@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Shawn Guo <shawnguo@...nel.org>,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
Frieder Schrempf <frieder.schrempf@...tron.de>,
Arnd Bergmann <arnd@...db.de>, Fabio Estevam <festevam@...il.com>,
Frank Li <Frank.Li@....com>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Rafał Miłecki <rafal@...ecki.pl>,
Shengjiu Wang <shengjiu.wang@....com>,
Shenwei Wang <shenwei.wang@....com>, Xu Yang <xu.yang_2@....com>,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>
Subject: Re: [RFC PATCH 0/5] Add NVMEM driver for i.MX93 OTP access through
ELE
Hi Frieder,
On Wed, Apr 16, 2025 at 04:26:19PM +0200, Frieder Schrempf wrote:
>From: Frieder Schrempf <frieder.schrempf@...tron.de>
>
>This depends on [1] for the support of the Edgelock Secure Enclave firmware
>driver.
>
>There are at least two ways to access the OTP fuses on i.MX93:
>
>(1) through the FSB (fuseblock) registers
>(2) through the ELE S400 API
>
>There currently is a NVMEM driver imx-ocotp-ele.c that (despite its name)
>implements (1). As the FSB only provides limited access to the OTP registers
>(read only) it's not sufficient for all use-cases.
>
>It seems like imx-ocotp-ele.c was intended to be extended later to implement
>(1) and (2) deciding on a per-fuse-register basis which of both access methods
>should be used.
>
>This has some downsides:
>
>* the driver gets convoluted and complex
>* the driver decides which OTP registers are accessed in which way and therefore
> mixes read-only and read/write access
>
>Therefore I implemented a simple driver that uses the ELE S400 API only, as the
>FSB access (1) doesn't provide any benefits except for that it doesn't depend
>on the ELE firmware being available. This is used by us downstream.
>
>For the upstream solution I would like to have some feedback on how to move
>on:
>
>1. switch imx-ocotp-ele.c to use ELE API exclusively
> -> this will create a hard dependency on the ELE firmware/driver being available
>2. extend imx-ocotp-ele.c to use FSB and ELE API
> -> make the driver use ELE API for all registers if ELE firmware/driver is available
>3. create separate drivers as done in this RFC
Need to confirm ELE APIs supports all fuses. If yes, switching to using ELE API
exclusively should be ok, no need to mix FSB and ELE API. And drop the current
FSB usage
Thanks,
Peng.
>
>Thanks!
>
>[1] https://patchwork.kernel.org/project/linux-arm-kernel/cover/20250409-imx-se-if-v16-0-5394e5f3417e@nxp.com/
>
>Frieder Schrempf (5):
> firmware: imx: ele: Add API functions for OCOTP fuse access
> nvmem: Add i.MX OCOTP fuse driver using ELE S400 API
> arm64: dts: imx93: Add node for EdgeLock Enclave (ELE) firmware driver
> arm64: dts: imx93: Add node for OCOTP S400 NVMEM driver
> arm64: dts: imx93-kontron: Add DMA memory region for ELE firmware
>
> .../dts/freescale/imx93-kontron-osm-s.dtsi | 16 ++
> arch/arm64/boot/dts/freescale/imx93.dtsi | 11 +
> drivers/firmware/imx/ele_base_msg.c | 122 +++++++++++
> drivers/firmware/imx/ele_base_msg.h | 8 +
> drivers/nvmem/Kconfig | 11 +
> drivers/nvmem/Makefile | 2 +
> drivers/nvmem/imx-ocotp-s400.c | 195 ++++++++++++++++++
> include/linux/firmware/imx/se_api.h | 3 +
> 8 files changed, 368 insertions(+)
> create mode 100644 drivers/nvmem/imx-ocotp-s400.c
>
>--
>2.49.0
Powered by blists - more mailing lists