[PATCH v2 0/5] nvmem: add Samsung Exynos OTP support

[PATCH v2 0/5] nvmem: add Samsung Exynos OTP support

[Tudor Ambarus]

Dependency
==========
Typical dependency of the DT patch depending on the bindings patch,
thus the bindings patch could go via the Samsung SoC tree with
Srinivas's ack.

Description
===========
Add initial support for the Samsung Exynos OTP controller. Read the
product and chip IDs from the OTP controller registers space and
register the SoC info to the SoC interface.

The driver can be extended to empower the controller become nvmem
provider. This is not in the scope of this patch because it seems the
OTP memory space is not yet used by any consumer, even downstream.

Testing
=======
root@google-gs:~# cat /sys/devices/soc0/family
Samsung Exynos
root@google-gs:~# cat /sys/devices/soc0/machine
Oriole
root@google-gs:~# cat /sys/devices/soc0/revision
11
root@google-gs:~# cat /sys/devices/soc0/soc_id
GS101

Cheers,
ta

Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
Changes in v2:
- bindings:
  - drop dependency on nvmem-deprecated-cells.yaml
  - drop clock-names, otp label, child nodes
  - add interrupts prop, make it required and add it in the example
- driver:
  - no longer a nvmem provider, register just to the soc interface
  - update comment about the module name in Kconfig
- dts: add interrupts, drop child nodes, drop otp label
- Link to v1: https://lore.kernel.org/r/20251031-gs101-otp-v1-0-2a54f6c4e7b6@linaro.org

---
Tudor Ambarus (5):
      dt-bindings: nvmem: add google,gs101-otp
      nvmem: add Samsung Exynos OTP support
      arm64: dts: exynos: gs101: add OTP node
      arm64: defconfig: enable Samsung Exynos OTP controller
      MAINTAINERS: add entry for the Samsung Exynos OTP controller driver

 .../bindings/nvmem/google,gs101-otp.yaml           |  56 ++++++++
 MAINTAINERS                                        |   8 ++
 arch/arm64/boot/dts/exynos/google/gs101.dtsi       |   7 +
 arch/arm64/configs/defconfig                       |   1 +
 drivers/nvmem/Kconfig                              |  10 ++
 drivers/nvmem/Makefile                             |   2 +
 drivers/nvmem/exynos-otp.c                         | 160 +++++++++++++++++++++
 7 files changed, 244 insertions(+)
---
base-commit: 4b67e4c65c1e0740ac12bd0d790eb5a9d0091aaa
change-id: 20251031-gs101-otp-2f38e8b4b793

Best regards,
-- 
Tudor Ambarus <tudor.ambarus@linaro.org>

[PATCH v2 1/5] dt-bindings: nvmem: add google,gs101-otp

[Tudor Ambarus]

Add binding for the OTP controller found on Google GS101.

Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
 .../bindings/nvmem/google,gs101-otp.yaml           | 56 ++++++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/Documentation/devicetree/bindings/nvmem/google,gs101-otp.yaml b/Documentation/devicetree/bindings/nvmem/google,gs101-otp.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..ea87216761dbab9a7a5cecd87a553a6a2a1783f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/google,gs101-otp.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/google,gs101-otp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Google GS101 OTP Controller
+
+maintainers:
+  - Tudor Ambarus <tudor.ambarus@linaro.org>
+
+description: |
+  OTP controller drives a NVMEM memory where system or user specific data
+  can be stored. The OTP controller register space if of interest as well
+  because it contains dedicated registers where it stores the Product ID
+  and the Chip ID (apart other things like TMU or ASV info).
+
+allOf:
+  - $ref: nvmem.yaml#
+
+properties:
+  compatible:
+    items:
+      - const: google,gs101-otp
+
+  clocks:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  reg:
+    maxItems: 1
+
+  power-domains:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - interrupts
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/google,gs101.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+    efuse@10000000 {
+        compatible = "google,gs101-otp";
+        reg = <0x10000000 0xf084>;
+        clocks = <&cmu_misc CLK_GOUT_MISC_OTP_CON_TOP_PCLK>;
+        interrupts = <GIC_SPI 752 IRQ_TYPE_LEVEL_HIGH>;
+    };

-- 
2.51.2.1041.gc1ab5b90ca-goog

[PATCH v2 2/5] nvmem: add Samsung Exynos OTP support

[Tudor Ambarus]

Add initial support for the Samsung Exynos OTP controller. Read the
product and chip IDs from the OTP controller registers space and
register the SoC info to the SoC interface.

The driver can be extended to empower the controller become nvmem
provider. This is not in the scope of this patch because it seems the
OTP memory space is not yet used by any consumer, even downstream.

Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
 drivers/nvmem/Kconfig      |  10 +++
 drivers/nvmem/Makefile     |   2 +
 drivers/nvmem/exynos-otp.c | 160 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 172 insertions(+)

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index e0d88d3199c11a3b71cc274b2114e9554ac486fc..aa8c14d4624b820a3685cdf14f2f32521a82db4a 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 nvmem-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..5acdc6ef1f8e07ffb6d465b160659732f4ef5a22
--- /dev/null
+++ b/drivers/nvmem/exynos-otp.c
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2025 Linaro Ltd.
+ *
+ * Samsung Exynos OTP driver.
+ */
+
+#include <linux/array_size.h>
+#include <linux/clk.h>
+#include <linux/device.h>
+#include <linux/device/devres.h>
+#include <linux/err.h>
+#include <linux/ioport.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/sys_soc.h>
+
+#define EXYNOS_OTP_PRODUCT_ID			0
+#define EXYNOS_OTP_PRODUCT_ID_MASK		GENMASK(31, 12)
+#define EXYNOS_OTP_PRODUCT_ID_MAIN_REV		GENMASK(3, 0)
+
+#define EXYNOS_OTP_CHIPID(i)			(0x4 + (i) * 4)
+#define EXYNOS_OTP_CHIPID3_SUB_REV		GENMASK(19, 16)
+
+#define EXYNOS_OTP_PRODUCT_ID_MAIN_REV_SHIFT	4
+
+struct exynos_otp {
+	struct clk *pclk;
+	struct device *dev;
+	struct regmap *regmap;
+};
+
+static const struct exynos_otp_soc_id {
+	const char *name;
+	u32 id;
+} eotp_soc_ids[] = {
+	{ "GS101", 0x9845 },
+};
+
+static const char *exynos_otp_xlate_soc_name(u32 id)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(eotp_soc_ids); i++)
+		if (id == eotp_soc_ids[i].id)
+			return eotp_soc_ids[i].name;
+	return NULL;
+}
+
+static void exynos_otp_unregister_soc(void *data)
+{
+	soc_device_unregister(data);
+}
+
+static int exynos_otp_soc_device_register(struct exynos_otp *eotp)
+{
+	struct soc_device_attribute *soc_dev_attr;
+	struct regmap *regmap = eotp->regmap;
+	struct device *dev = eotp->dev;
+	struct soc_device *soc_dev;
+	u32 val, main_rev, sub_rev;
+	u32 product_id, revision;
+	int ret;
+
+	soc_dev_attr = devm_kzalloc(dev, sizeof(*soc_dev_attr), GFP_KERNEL);
+	if (!soc_dev_attr)
+		return -ENOMEM;
+
+	ret = regmap_read(regmap, EXYNOS_OTP_PRODUCT_ID, &val);
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to read product id\n");
+
+	product_id = FIELD_GET(EXYNOS_OTP_PRODUCT_ID_MASK, val);
+	main_rev = FIELD_GET(EXYNOS_OTP_PRODUCT_ID_MAIN_REV, val);
+
+	ret = regmap_read(regmap, EXYNOS_OTP_CHIPID(3), &val);
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to read chip id\n");
+
+	sub_rev = FIELD_GET(EXYNOS_OTP_CHIPID3_SUB_REV, val);
+	revision = main_rev << EXYNOS_OTP_PRODUCT_ID_MAIN_REV_SHIFT | sub_rev;
+
+	soc_dev_attr->family = "Samsung Exynos";
+	soc_dev_attr->soc_id = exynos_otp_xlate_soc_name(product_id);
+	if (!soc_dev_attr->soc_id)
+		return dev_err_probe(dev, -ENODEV, "failed to translate chip id to name\n");
+
+	soc_dev_attr->revision = devm_kasprintf(dev, GFP_KERNEL, "%x",
+						revision);
+	if (!soc_dev_attr->revision)
+		return -ENOMEM;
+
+	soc_dev = soc_device_register(soc_dev_attr);
+	if (IS_ERR(soc_dev))
+		return dev_err_probe(dev, PTR_ERR(soc_dev),
+				     "failed to register to the SoC interface\n");
+
+	ret = devm_add_action_or_reset(dev, exynos_otp_unregister_soc, soc_dev);
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to add devm action\n");
+
+	return 0;
+}
+
+static int exynos_otp_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct exynos_otp *eotp;
+	struct resource *res;
+	void __iomem *base;
+
+	eotp = devm_kzalloc(dev, sizeof(*eotp), GFP_KERNEL);
+	if (!eotp)
+		return -ENOMEM;
+
+	base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+
+	const struct regmap_config reg_config = {
+		.reg_bits = 32,
+		.reg_stride = 4,
+		.val_bits = 32,
+		.use_relaxed_mmio = true,
+		.max_register = (resource_size(res) - reg_config.reg_stride),
+	};
+
+	eotp->regmap = devm_regmap_init_mmio(dev, base, &reg_config);
+	if (IS_ERR(eotp->regmap))
+		return PTR_ERR(eotp->regmap);
+
+	eotp->pclk = devm_clk_get_enabled(dev, NULL);
+	if (IS_ERR(eotp->pclk))
+		return dev_err_probe(dev, PTR_ERR(eotp->pclk), "failed to get clock\n");
+
+	eotp->dev = dev;
+
+	return exynos_otp_soc_device_register(eotp);
+}
+
+static const struct of_device_id exynos_otp_dt_ids[] = {
+	{ .compatible = "google,gs101-otp" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, exynos_otp_dt_ids);
+
+static struct platform_driver exynos_otp_driver = {
+	.probe	= exynos_otp_probe,
+	.driver = {
+		.name	= "exynos-otp",
+		.of_match_table = exynos_otp_dt_ids,
+	},
+};
+module_platform_driver(exynos_otp_driver);
+
+MODULE_AUTHOR("Tudor Ambarus <tudor.ambarus@linaro.org>");
+MODULE_DESCRIPTION("Samsung Exynos OTP driver");
+MODULE_LICENSE("GPL");

-- 
2.51.2.1041.gc1ab5b90ca-goog

[PATCH v2 3/5] arm64: dts: exynos: gs101: add OTP node

[Tudor Ambarus]

Add the OTP controller node.

Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
 arch/arm64/boot/dts/exynos/google/gs101.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
index d06d1d05f36408137a8acd98e43d48ea7d4f4292..4be983d4e291b3afe3530fbea0163f70c1a74671 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -571,6 +571,13 @@ soc: soc@0 {
 		#size-cells = <1>;
 		ranges = <0x0 0x0 0x0 0x40000000>;
 
+		efuse@10000000 {
+			compatible = "google,gs101-otp";
+			reg = <0x10000000 0xf084>;
+			clocks = <&cmu_misc CLK_GOUT_MISC_OTP_CON_TOP_PCLK>;
+			interrupts = <GIC_SPI 752 IRQ_TYPE_LEVEL_HIGH 0>;
+		};
+
 		cmu_misc: clock-controller@10010000 {
 			compatible = "google,gs101-cmu-misc";
 			reg = <0x10010000 0x10000>;

-- 
2.51.2.1041.gc1ab5b90ca-goog

[PATCH v2 4/5] arm64: defconfig: enable Samsung Exynos OTP controller

[Tudor Ambarus]

Enable the exynos-otp nvmem driver. The driver reads the product and
chip IDs from the OTP register space and register the SoC info to the
SoC interface.

The driver can be extended to empower the controller become nvmem
provider. The fuse block stores various system information (TMU, ASV,
etc.) which can be accessed by client drivers.

Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 646097e94efe7f1a18fb59d5b6dfc6268be91383..6433e3c0f88b892ce6f2ee190f866a6ab4889771 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1682,6 +1682,7 @@ CONFIG_ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU=m
 CONFIG_NVIDIA_CORESIGHT_PMU_ARCH_SYSTEM_PMU=m
 CONFIG_MESON_DDR_PMU=m
 CONFIG_NVMEM_LAYOUT_SL28_VPD=m
+CONFIG_NVMEM_EXYNOS_OTP=m
 CONFIG_NVMEM_IMX_OCOTP=y
 CONFIG_NVMEM_IMX_OCOTP_ELE=m
 CONFIG_NVMEM_IMX_OCOTP_SCU=y

-- 
2.51.2.1041.gc1ab5b90ca-goog

[PATCH v2 5/5] MAINTAINERS: add entry for the Samsung Exynos OTP controller driver

[Tudor Ambarus]

Add an entry for the Samsung Exynos OTP controller driver.

Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
 MAINTAINERS | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ab00eca640e02d40dd80949986d6cd6216ee6194..813a098475ab7d5371c811020ea022f63d1acb35 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22775,6 +22775,14 @@ F:	Documentation/devicetree/bindings/mailbox/google,gs101-mbox.yaml
 F:	drivers/mailbox/exynos-mailbox.c
 F:	include/linux/mailbox/exynos-message.h
 
+SAMSUNG EXYNOS OTP DRIVER
+M:	Tudor Ambarus <tudor.ambarus@linaro.org>
+L:	linux-kernel@vger.kernel.org
+L:	linux-samsung-soc@vger.kernel.org
+S:	Supported
+F:	Documentation/devicetree/bindings/nvmem/google,gs101-otp.yaml
+F:	drivers/nvmem/exynos-otp.c
+
 SAMSUNG EXYNOS PSEUDO RANDOM NUMBER GENERATOR (RNG) DRIVER
 M:	Krzysztof Kozlowski <krzk@kernel.org>
 L:	linux-crypto@vger.kernel.org

-- 
2.51.2.1041.gc1ab5b90ca-goog

Re: [PATCH v2 1/5] dt-bindings: nvmem: add google,gs101-otp

[Krzysztof Kozlowski]

On Wed, Nov 12, 2025 at 08:29:05AM +0000, Tudor Ambarus wrote:
> Add binding for the OTP controller found on Google GS101.
> 
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
>  .../bindings/nvmem/google,gs101-otp.yaml           | 56 ++++++++++++++++++++++
>  1 file changed, 56 insertions(+)

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof

Re: [PATCH v2 2/5] nvmem: add Samsung Exynos OTP support

[Krzysztof Kozlowski]

On Wed, Nov 12, 2025 at 08:29:06AM +0000, Tudor Ambarus wrote:
> Add initial support for the Samsung Exynos OTP controller. Read the
> product and chip IDs from the OTP controller registers space and
> register the SoC info to the SoC interface.
> 
> The driver can be extended to empower the controller become nvmem
> provider. This is not in the scope of this patch because it seems the
> OTP memory space is not yet used by any consumer, even downstream.

Quick look tells me you just duplicated existing Samsung ChipID driver.
Even actual product ID registers and masks are the same, with one
difference - you read CHIPID3... which is the same as in newer Exynos,
e.g. Exynos8895.

What is exactly the point of having this as separate driver? I think
this can easily be just customized chipid driver - with different
implementation of exynos_chipid_get_chipid_info().

Best regards,
Krzysztof

Re: [PATCH v2 1/5] dt-bindings: nvmem: add google,gs101-otp

[André Draszik]

On Wed, 2025-11-12 at 08:29 +0000, Tudor Ambarus wrote:
> Add binding for the OTP controller found on Google GS101.
> 
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
>  .../bindings/nvmem/google,gs101-otp.yaml           | 56 ++++++++++++++++++++++
>  1 file changed, 56 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/nvmem/google,gs101-otp.yaml b/Documentation/devicetree/bindings/nvmem/google,gs101-
> otp.yaml
> new file mode 100644
> index 0000000000000000000000000000000000000000..ea87216761dbab9a7a5cecd87a553a6a2a1783f7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/google,gs101-otp.yaml
> @@ -0,0 +1,56 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/nvmem/google,gs101-otp.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Google GS101 OTP Controller
> +
> +maintainers:
> +  - Tudor Ambarus <tudor.ambarus@linaro.org>
> +
> +description: |
> +  OTP controller drives a NVMEM memory where system or user specific data
> +  can be stored. The OTP controller register space if of interest as well

If there's another version:

-> if of interest
-> is of interest

In any case:

Reviewed-by: André Draszik <andre.draszik@linaro.org>

Cheers,
Andre

Re: [PATCH v2 2/5] nvmem: add Samsung Exynos OTP support

[Tudor Ambarus]

On 11/13/25 10:30 AM, Krzysztof Kozlowski wrote:
> On Wed, Nov 12, 2025 at 08:29:06AM +0000, Tudor Ambarus wrote:
>> Add initial support for the Samsung Exynos OTP controller. Read the
>> product and chip IDs from the OTP controller registers space and
>> register the SoC info to the SoC interface.
>>
>> The driver can be extended to empower the controller become nvmem
>> provider. This is not in the scope of this patch because it seems the
>> OTP memory space is not yet used by any consumer, even downstream.
> 
> Quick look tells me you just duplicated existing Samsung ChipID driver.
> Even actual product ID registers and masks are the same, with one
> difference - you read CHIPID3... which is the same as in newer Exynos,
> e.g. Exynos8895.

Yes, that's correct. It's very similar with the Samsung ChipID driver.

> 
> What is exactly the point of having this as separate driver? I think

The difference is that for gs101 the chipid info is part of the OTP
registers. GS101 OTP has a clock, an interrupt line, a register space 
(that contains product and chip ID, TMU data, ASV, etc) and a 32Kbit
memory space that can be read/program/locked with specific commands.

The ChipID driver handles older exynos platforms that have a dedicated
chipid device that references a SFR register space to get the product
and chip ID. On GS101 (but also for e850 and autov9 I assume) the
"ChipID block" is just an abstraction, it's not a physical device. The
ChipID info is from OTP. When the power-on sequence progresses, the OTP
chipid values are loaded to the OTP registers. We need the OTP clock to
be on in order to read them. So GS101 has an OTP device that also happens
to have chip ID info.

For now I just got the chipid info and registered it to the SoC interface
(which is very similar to that the exynos-chipid driver does), but this
driver can be extended to export both its memory space and register space
as nvmem devices, if any consumer needs them. Downstream GS101 drivers
seem to use just the chip id info and a dvfs version from the OTP
registers. DVFS version is not going to be used upstream as we're defining
the OPPs in DT. So I was not interested in extending the driver with nvmem
provider support, because it seems we don't need it for GS101.

Do the above justify the point of having a dedicated driver?

> this can easily be just customized chipid driver - with different
> implementation of exynos_chipid_get_chipid_info().

If the answer is no to my question above, how shall I model the device
that binds to the existing exynos-chipid driver?

Thanks!
ta

Re: [PATCH v2 2/5] nvmem: add Samsung Exynos OTP support

[Krzysztof Kozlowski]

On 13/11/2025 10:28, Tudor Ambarus wrote:
> 
> 
> On 11/13/25 10:30 AM, Krzysztof Kozlowski wrote:
>> On Wed, Nov 12, 2025 at 08:29:06AM +0000, Tudor Ambarus wrote:
>>> Add initial support for the Samsung Exynos OTP controller. Read the
>>> product and chip IDs from the OTP controller registers space and
>>> register the SoC info to the SoC interface.
>>>
>>> The driver can be extended to empower the controller become nvmem
>>> provider. This is not in the scope of this patch because it seems the
>>> OTP memory space is not yet used by any consumer, even downstream.
>>
>> Quick look tells me you just duplicated existing Samsung ChipID driver.
>> Even actual product ID registers and masks are the same, with one
>> difference - you read CHIPID3... which is the same as in newer Exynos,
>> e.g. Exynos8895.
> 
> Yes, that's correct. It's very similar with the Samsung ChipID driver.
> 
>>
>> What is exactly the point of having this as separate driver? I think
> 
> The difference is that for gs101 the chipid info is part of the OTP
> registers. GS101 OTP has a clock, an interrupt line, a register space 
> (that contains product and chip ID, TMU data, ASV, etc) and a 32Kbit
> memory space that can be read/program/locked with specific commands.
> 
> The ChipID driver handles older exynos platforms that have a dedicated
> chipid device that references a SFR register space to get the product
> and chip ID. On GS101 (but also for e850 and autov9 I assume) the
> "ChipID block" is just an abstraction, it's not a physical device. The
> ChipID info is from OTP. When the power-on sequence progresses, the OTP
> chipid values are loaded to the OTP registers. We need the OTP clock to
> be on in order to read them. So GS101 has an OTP device that also happens
> to have chip ID info.
> 
> For now I just got the chipid info and registered it to the SoC interface
> (which is very similar to that the exynos-chipid driver does), but this
> driver can be extended to export both its memory space and register space


There is no code for that now and possibility of extension is not a
reason to duplicate yet.

> as nvmem devices, if any consumer needs them. Downstream GS101 drivers
> seem to use just the chip id info and a dvfs version from the OTP
> registers. DVFS version is not going to be used upstream as we're defining
> the OPPs in DT. So I was not interested in extending the driver with nvmem
> provider support, because it seems we don't need it for GS101.
> 
> Do the above justify the point of having a dedicated driver?
Only partially, I asked about driver. I did not spot previously the
clock, so we have two differences - CHIPID3 register and clock - right?
I wonder why Exynos8895 and others, which are already supported, do not
use CHIPID3, but nevertheless these two differences can be easily
integrated into existing driver.
 >
>> this can easily be just customized chipid driver - with different
>> implementation of exynos_chipid_get_chipid_info().
> 
> If the answer is no to my question above, how shall I model the device
> that binds to the existing exynos-chipid driver?
Just extend the existing driver.

Best regards,
Krzysztof

Re: [PATCH v2 2/5] nvmem: add Samsung Exynos OTP support

[Tudor Ambarus]

On 11/13/25 11:35 AM, Krzysztof Kozlowski wrote:
> On 13/11/2025 10:28, Tudor Ambarus wrote:
>>
>>
>> On 11/13/25 10:30 AM, Krzysztof Kozlowski wrote:
>>> On Wed, Nov 12, 2025 at 08:29:06AM +0000, Tudor Ambarus wrote:
>>>> Add initial support for the Samsung Exynos OTP controller. Read the
>>>> product and chip IDs from the OTP controller registers space and
>>>> register the SoC info to the SoC interface.
>>>>
>>>> The driver can be extended to empower the controller become nvmem
>>>> provider. This is not in the scope of this patch because it seems the
>>>> OTP memory space is not yet used by any consumer, even downstream.
>>>
>>> Quick look tells me you just duplicated existing Samsung ChipID driver.
>>> Even actual product ID registers and masks are the same, with one
>>> difference - you read CHIPID3... which is the same as in newer Exynos,
>>> e.g. Exynos8895.
>>
>> Yes, that's correct. It's very similar with the Samsung ChipID driver.
>>
>>>
>>> What is exactly the point of having this as separate driver? I think
>>
>> The difference is that for gs101 the chipid info is part of the OTP
>> registers. GS101 OTP has a clock, an interrupt line, a register space 
>> (that contains product and chip ID, TMU data, ASV, etc) and a 32Kbit
>> memory space that can be read/program/locked with specific commands.
>>
>> The ChipID driver handles older exynos platforms that have a dedicated
>> chipid device that references a SFR register space to get the product
>> and chip ID. On GS101 (but also for e850 and autov9 I assume) the
>> "ChipID block" is just an abstraction, it's not a physical device. The
>> ChipID info is from OTP. When the power-on sequence progresses, the OTP
>> chipid values are loaded to the OTP registers. We need the OTP clock to
>> be on in order to read them. So GS101 has an OTP device that also happens
>> to have chip ID info.
>>
>> For now I just got the chipid info and registered it to the SoC interface
>> (which is very similar to that the exynos-chipid driver does), but this
>> driver can be extended to export both its memory space and register space
> 
> 
> There is no code for that now and possibility of extension is not a
> reason to duplicate yet.
> 
>> as nvmem devices, if any consumer needs them. Downstream GS101 drivers
>> seem to use just the chip id info and a dvfs version from the OTP
>> registers. DVFS version is not going to be used upstream as we're defining
>> the OPPs in DT. So I was not interested in extending the driver with nvmem
>> provider support, because it seems we don't need it for GS101.
>>
>> Do the above justify the point of having a dedicated driver?
> Only partially, I asked about driver. I did not spot previously the
> clock, so we have two differences - CHIPID3 register and clock - right?

clock and interrupts, but I don't use the interrupts because I just need
to read the OTP registers to get the chip id info.

> I wonder why Exynos8895 and others, which are already supported, do not
> use CHIPID3, but nevertheless these two differences can be easily
> integrated into existing driver.

they can be integrated, but I want to make sure we're making the best
decision.

>>> this can easily be just customized chipid driver - with different
>>> implementation of exynos_chipid_get_chipid_info().
>>
>> If the answer is no to my question above, how shall I model the device
>> that binds to the existing exynos-chipid driver?
> Just extend the existing driver.
> 
So you mean I shall have something like that in DT:

+		chipid@10000000 {
+			compatible = "google,gs101-chipid";
+			reg = <0x10000000 0xf084>;
+			clocks = <&cmu_misc CLK_GOUT_MISC_OTP_CON_TOP_PCLK>;
+			interrupts = <GIC_SPI 752 IRQ_TYPE_LEVEL_HIGH 0>;
+		};

Maybe remove the interrupts because I don't need them for reading OTP regs.

What happens in the maybe unlikely case we do want to add support for OTP
for GS101? How will we describe that in DT?

Thanks!
ta

Re: [PATCH v2 2/5] nvmem: add Samsung Exynos OTP support

[Tudor Ambarus]

On 11/13/25 11:51 AM, Tudor Ambarus wrote:
> 
> 
> On 11/13/25 11:35 AM, Krzysztof Kozlowski wrote:
>> On 13/11/2025 10:28, Tudor Ambarus wrote:
>>>
>>>
>>> On 11/13/25 10:30 AM, Krzysztof Kozlowski wrote:
>>>> On Wed, Nov 12, 2025 at 08:29:06AM +0000, Tudor Ambarus wrote:
>>>>> Add initial support for the Samsung Exynos OTP controller. Read the
>>>>> product and chip IDs from the OTP controller registers space and
>>>>> register the SoC info to the SoC interface.
>>>>>
>>>>> The driver can be extended to empower the controller become nvmem
>>>>> provider. This is not in the scope of this patch because it seems the
>>>>> OTP memory space is not yet used by any consumer, even downstream.
>>>>
>>>> Quick look tells me you just duplicated existing Samsung ChipID driver.
>>>> Even actual product ID registers and masks are the same, with one
>>>> difference - you read CHIPID3... which is the same as in newer Exynos,
>>>> e.g. Exynos8895.
>>>
>>> Yes, that's correct. It's very similar with the Samsung ChipID driver.
>>>
>>>>
>>>> What is exactly the point of having this as separate driver? I think
>>>
>>> The difference is that for gs101 the chipid info is part of the OTP
>>> registers. GS101 OTP has a clock, an interrupt line, a register space 
>>> (that contains product and chip ID, TMU data, ASV, etc) and a 32Kbit
>>> memory space that can be read/program/locked with specific commands.
>>>
>>> The ChipID driver handles older exynos platforms that have a dedicated
>>> chipid device that references a SFR register space to get the product
>>> and chip ID. On GS101 (but also for e850 and autov9 I assume) the
>>> "ChipID block" is just an abstraction, it's not a physical device. The
>>> ChipID info is from OTP. When the power-on sequence progresses, the OTP
>>> chipid values are loaded to the OTP registers. We need the OTP clock to
>>> be on in order to read them. So GS101 has an OTP device that also happens
>>> to have chip ID info.
>>>
>>> For now I just got the chipid info and registered it to the SoC interface
>>> (which is very similar to that the exynos-chipid driver does), but this
>>> driver can be extended to export both its memory space and register space
>>
>>
>> There is no code for that now and possibility of extension is not a
>> reason to duplicate yet.
>>
>>> as nvmem devices, if any consumer needs them. Downstream GS101 drivers
>>> seem to use just the chip id info and a dvfs version from the OTP
>>> registers. DVFS version is not going to be used upstream as we're defining
>>> the OPPs in DT. So I was not interested in extending the driver with nvmem
>>> provider support, because it seems we don't need it for GS101.
>>>
>>> Do the above justify the point of having a dedicated driver?
>> Only partially, I asked about driver. I did not spot previously the
>> clock, so we have two differences - CHIPID3 register and clock - right?
> 
> clock and interrupts, but I don't use the interrupts because I just need
> to read the OTP registers to get the chip id info.
> 
>> I wonder why Exynos8895 and others, which are already supported, do not
>> use CHIPID3, but nevertheless these two differences can be easily
>> integrated into existing driver.
> 
> they can be integrated, but I want to make sure we're making the best
> decision.
> 
>>>> this can easily be just customized chipid driver - with different
>>>> implementation of exynos_chipid_get_chipid_info().
>>>
>>> If the answer is no to my question above, how shall I model the device
>>> that binds to the existing exynos-chipid driver?
>> Just extend the existing driver.
>>
> So you mean I shall have something like that in DT:
> 
> +		chipid@10000000 {
> +			compatible = "google,gs101-chipid";
> +			reg = <0x10000000 0xf084>;
> +			clocks = <&cmu_misc CLK_GOUT_MISC_OTP_CON_TOP_PCLK>;
> +			interrupts = <GIC_SPI 752 IRQ_TYPE_LEVEL_HIGH 0>;
> +		};
> 
> Maybe remove the interrupts because I don't need them for reading OTP regs.
> 
> What happens in the maybe unlikely case we do want to add support for OTP
> for GS101? How will we describe that in DT?
> 

Ah, I guess you meant to keep the node as I described it in patch 3/5,
an efuse node with a google,gs101-otp compatible, that will bind to the
existing exynos-chipid driver. Then if/when we add OTP support, move
everything to a new OTP driver. That can work, yes. Unless I add some
OTP support now, to justify the new driver. Both shall be okay, right?

Thanks,
ta

Re: [PATCH v2 2/5] nvmem: add Samsung Exynos OTP support

[Krzysztof Kozlowski]

On 13/11/2025 10:51, Tudor Ambarus wrote:
> 
> 
> On 11/13/25 11:35 AM, Krzysztof Kozlowski wrote:
>> On 13/11/2025 10:28, Tudor Ambarus wrote:
>>>
>>>
>>> On 11/13/25 10:30 AM, Krzysztof Kozlowski wrote:
>>>> On Wed, Nov 12, 2025 at 08:29:06AM +0000, Tudor Ambarus wrote:
>>>>> Add initial support for the Samsung Exynos OTP controller. Read the
>>>>> product and chip IDs from the OTP controller registers space and
>>>>> register the SoC info to the SoC interface.
>>>>>
>>>>> The driver can be extended to empower the controller become nvmem
>>>>> provider. This is not in the scope of this patch because it seems the
>>>>> OTP memory space is not yet used by any consumer, even downstream.
>>>>
>>>> Quick look tells me you just duplicated existing Samsung ChipID driver.
>>>> Even actual product ID registers and masks are the same, with one
>>>> difference - you read CHIPID3... which is the same as in newer Exynos,
>>>> e.g. Exynos8895.
>>>
>>> Yes, that's correct. It's very similar with the Samsung ChipID driver.
>>>
>>>>
>>>> What is exactly the point of having this as separate driver? I think
>>>
>>> The difference is that for gs101 the chipid info is part of the OTP
>>> registers. GS101 OTP has a clock, an interrupt line, a register space 
>>> (that contains product and chip ID, TMU data, ASV, etc) and a 32Kbit
>>> memory space that can be read/program/locked with specific commands.
>>>
>>> The ChipID driver handles older exynos platforms that have a dedicated
>>> chipid device that references a SFR register space to get the product
>>> and chip ID. On GS101 (but also for e850 and autov9 I assume) the
>>> "ChipID block" is just an abstraction, it's not a physical device. The
>>> ChipID info is from OTP. When the power-on sequence progresses, the OTP
>>> chipid values are loaded to the OTP registers. We need the OTP clock to
>>> be on in order to read them. So GS101 has an OTP device that also happens
>>> to have chip ID info.
>>>
>>> For now I just got the chipid info and registered it to the SoC interface
>>> (which is very similar to that the exynos-chipid driver does), but this
>>> driver can be extended to export both its memory space and register space
>>
>>
>> There is no code for that now and possibility of extension is not a
>> reason to duplicate yet.
>>
>>> as nvmem devices, if any consumer needs them. Downstream GS101 drivers
>>> seem to use just the chip id info and a dvfs version from the OTP
>>> registers. DVFS version is not going to be used upstream as we're defining
>>> the OPPs in DT. So I was not interested in extending the driver with nvmem
>>> provider support, because it seems we don't need it for GS101.
>>>
>>> Do the above justify the point of having a dedicated driver?
>> Only partially, I asked about driver. I did not spot previously the
>> clock, so we have two differences - CHIPID3 register and clock - right?
> 
> clock and interrupts, but I don't use the interrupts because I just need
> to read the OTP registers to get the chip id info.
> 
>> I wonder why Exynos8895 and others, which are already supported, do not
>> use CHIPID3, but nevertheless these two differences can be easily
>> integrated into existing driver.
> 
> they can be integrated, but I want to make sure we're making the best
> decision.
> 
>>>> this can easily be just customized chipid driver - with different
>>>> implementation of exynos_chipid_get_chipid_info().
>>>
>>> If the answer is no to my question above, how shall I model the device
>>> that binds to the existing exynos-chipid driver?
>> Just extend the existing driver.
>>
> So you mean I shall have something like that in DT:
> 
> +		chipid@10000000 {
> +			compatible = "google,gs101-chipid";

No. I said about driver. Why are you mixing these?

In previous v1 I said that bindings are wrong, because you created two
bindings for the same device. This was fixed and bindings look okay.
That's done.

We speak here ONLY about the driver.

> +			reg = <0x10000000 0xf084>;
> +			clocks = <&cmu_misc CLK_GOUT_MISC_OTP_CON_TOP_PCLK>;
> +			interrupts = <GIC_SPI 752 IRQ_TYPE_LEVEL_HIGH 0>;
> +		};
> 
> Maybe remove the interrupts because I don't need them for reading OTP regs.

No, they must stay because hardware description must be complete.

> 
> What happens in the maybe unlikely case we do want to add support for OTP
> for GS101? How will we describe that in DT?

You add nvmem-cells to that node. You can add them even now to the
binding to make hardware description complete, but because we do not see
any use of that and nvmem-cells are mostly for other consumers of the
node, it does not matter that much. Maybe mention that in commit msg,
that you skip nvmem-cells because this OTP is not used at all as NVMEM
anywhere in downstream, upstream and you do not see such possibility.

Best regards,
Krzysztof

Re: [PATCH v2 2/5] nvmem: add Samsung Exynos OTP support

[Krzysztof Kozlowski]

On 13/11/2025 11:26, Tudor Ambarus wrote:
>>
>>>>> this can easily be just customized chipid driver - with different
>>>>> implementation of exynos_chipid_get_chipid_info().
>>>>
>>>> If the answer is no to my question above, how shall I model the device
>>>> that binds to the existing exynos-chipid driver?
>>> Just extend the existing driver.
>>>
>> So you mean I shall have something like that in DT:
>>
>> +		chipid@10000000 {
>> +			compatible = "google,gs101-chipid";
>> +			reg = <0x10000000 0xf084>;
>> +			clocks = <&cmu_misc CLK_GOUT_MISC_OTP_CON_TOP_PCLK>;
>> +			interrupts = <GIC_SPI 752 IRQ_TYPE_LEVEL_HIGH 0>;
>> +		};
>>
>> Maybe remove the interrupts because I don't need them for reading OTP regs.
>>
>> What happens in the maybe unlikely case we do want to add support for OTP
>> for GS101? How will we describe that in DT?
>>
> 
> Ah, I guess you meant to keep the node as I described it in patch 3/5,
> an efuse node with a google,gs101-otp compatible, that will bind to the
> existing exynos-chipid driver. Then if/when we add OTP support, move
> everything to a new OTP driver. That can work, yes. Unless I add some
> OTP support now, to justify the new driver. Both shall be okay, right?

Yes.

Best regards,
Krzysztof

Re: [PATCH v2 2/5] nvmem: add Samsung Exynos OTP support

[Tudor Ambarus]

On 11/13/25 12:44 PM, Krzysztof Kozlowski wrote:
> On 13/11/2025 11:26, Tudor Ambarus wrote:
>>>
>>>>>> this can easily be just customized chipid driver - with different
>>>>>> implementation of exynos_chipid_get_chipid_info().
>>>>>
>>>>> If the answer is no to my question above, how shall I model the device
>>>>> that binds to the existing exynos-chipid driver?
>>>> Just extend the existing driver.
>>>>
>>> So you mean I shall have something like that in DT:
>>>
>>> +		chipid@10000000 {
>>> +			compatible = "google,gs101-chipid";
>>> +			reg = <0x10000000 0xf084>;
>>> +			clocks = <&cmu_misc CLK_GOUT_MISC_OTP_CON_TOP_PCLK>;
>>> +			interrupts = <GIC_SPI 752 IRQ_TYPE_LEVEL_HIGH 0>;
>>> +		};
>>>
>>> Maybe remove the interrupts because I don't need them for reading OTP regs.
>>>
>>> What happens in the maybe unlikely case we do want to add support for OTP
>>> for GS101? How will we describe that in DT?
>>>
>>
>> Ah, I guess you meant to keep the node as I described it in patch 3/5,
>> an efuse node with a google,gs101-otp compatible, that will bind to the
>> existing exynos-chipid driver. Then if/when we add OTP support, move
>> everything to a new OTP driver. That can work, yes. Unless I add some
>> OTP support now, to justify the new driver. Both shall be okay, right?
> 
> Yes.
> 

I'm going to extend the existing chipid driver. I looked downstream again,
and couldn't see any other consumer of OTP, even for newer SoCs than gs101.

Thanks!
ta