linux-kernel - Re: [PATCH 2/5] nvmem: add Samsung Exynos OTP support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <93d5636b-a515-4976-b68c-9606924eab8f@kernel.org>
Date: Tue, 4 Nov 2025 08:19:08 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Tudor Ambarus <tudor.ambarus@...aro.org>,
 Srinivas Kandagatla <srini@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Alim Akhtar <alim.akhtar@...sung.com>,
 Peter Griffin <peter.griffin@...aro.org>,
 André Draszik <andre.draszik@...aro.org>
Cc: semen.protsenko@...aro.org, willmcvicker@...gle.com,
 kernel-team@...roid.com, linux-kernel@...r.kernel.org,
 linux-samsung-soc@...r.kernel.org, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 2/5] nvmem: add Samsung Exynos OTP support

On 31/10/2025 13:45, Tudor Ambarus wrote:
> Add support for the Samsung Exynos OTP controller. On the Google GS101
> SoC, this controller provides 32 Kbit of OTP memory space that can be
> read/program/lock using a specific sequence of register accesses.
> 
> The OTP controller register space is of interest as well because it
> contains dedicated registers for the Product ID and the Chip ID (apart
> other things like TMU or ASV info). Register the OTP controller
> register space as a nvmem device so that other drivers can access its
> contents using nvmem cells.
> 
> Support for the OTP memory space can follow and be modeled as a
> dedicated nvmem device.
> 
> Signed-off-by: Tudor Ambarus <tudor.ambarus@...aro.org>
> ---
>  drivers/nvmem/Kconfig      | 10 +++++
>  drivers/nvmem/Makefile     |  2 +
>  drivers/nvmem/exynos-otp.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 110 insertions(+)
> 
> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> index e0d88d3199c11a3b71cc274b2114e9554ac486fc..f973e009737f2fbdc8511e50f1aa9e6003286065 100644
> --- a/drivers/nvmem/Kconfig
> +++ b/drivers/nvmem/Kconfig
> @@ -84,6 +84,16 @@ config NVMEM_BRCM_NVRAM
>  	  This driver provides support for Broadcom's NVRAM that can be accessed
>  	  using I/O mapping.
>  
> +config NVMEM_EXYNOS_OTP
> +	tristate "Samsung Exynos OTP support"
> +	depends on ARCH_EXYNOS || COMPILE_TEST
> +	help
> +	  This driver provides support for the OTP controller found on some
> +	  Samsung Exynos SoCs.
> +
> +	  This driver can also be built as a module. If so, the module
> +	  will be called exynos-otp.
> +
>  config NVMEM_IMX_IIM
>  	tristate "i.MX IC Identification Module support"
>  	depends on ARCH_MXC || COMPILE_TEST
> diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
> index 70a4464dcb1e25cf9116280a32f4a0f4f9941a75..920a536fc359a5a7d8f3aabba6a712e85c277ee7 100644
> --- a/drivers/nvmem/Makefile
> +++ b/drivers/nvmem/Makefile
> @@ -20,6 +20,8 @@ obj-$(CONFIG_NVMEM_BCM_OCOTP)		+= nvmem-bcm-ocotp.o
>  nvmem-bcm-ocotp-y			:= bcm-ocotp.o
>  obj-$(CONFIG_NVMEM_BRCM_NVRAM)		+= nvmem_brcm_nvram.o
>  nvmem_brcm_nvram-y			:= brcm_nvram.o
> +obj-$(CONFIG_NVMEM_EXYNOS_OTP)		+= nvmem-exynos-otp.o
> +nvmem-exynos-otp-y			:= exynos-otp.o
>  obj-$(CONFIG_NVMEM_IMX_IIM)		+= nvmem-imx-iim.o
>  nvmem-imx-iim-y				:= imx-iim.o
>  obj-$(CONFIG_NVMEM_IMX_OCOTP)		+= nvmem-imx-ocotp.o
> diff --git a/drivers/nvmem/exynos-otp.c b/drivers/nvmem/exynos-otp.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..3bff9421e6f2b80a8f20533b490a289687d117e8
> --- /dev/null
> +++ b/drivers/nvmem/exynos-otp.c
> @@ -0,0 +1,98 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright 2025 Linaro Ltd.
> + *
> + * Samsung Exynos OTP driver.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/ioport.h>
> +#include <linux/module.h>
> +#include <linux/nvmem-provider.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/mod_devicetable.h>
> +
> +struct exynos_otp {
> +	struct clk *pclk;
> +	struct regmap *regmap;
> +};
> +
> +static int exynos_otp_read(void *context, unsigned int offset, void *val,
> +			   size_t bytes)
> +{
> +	struct exynos_otp *eotp = context;
> +
> +	return regmap_bulk_read(eotp->regmap, offset, val, bytes / 4);


So you are just reading MMIO and pretending this is NVMEM?

Is it possible to actually do the other actions from your commit msg
"read/program/lock"? If not, then you just created NVMEM abstraction
over existing chipid completely duplicating the driver (with more
translation layers).

Best regards,
Krzysztof