[PATCH 0/3] nvmem: Add Raspberry Pi OTP nvmem driver

[PATCH 0/3] nvmem: Add Raspberry Pi OTP nvmem driver

[Gregor Herburger]

Hi,

This series adds support for the Raspberry Pis OTP registers. The
Raspberry Pi has one or more OTP regions. These registers are accessible
through the firmware. Add a driver for it and add the corresponding
devicetree scheme.

I also added the devicetree nodes for the Raspberry Pi as I tested the
series on it.

---
Gregor Herburger (3):
      dt-bindings: nvmem: Add a binding for the RPi Firmware OTP register
      nvmem: Add the Raspberry Pi OTP driver
      arm64: dts: broadcom: bcm2712: Add the otp nodes to firmware

 .../arm/bcm/raspberrypi,bcm2835-firmware.yaml      |  18 +++
 .../boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi    |   8 ++
 drivers/nvmem/Kconfig                              |  12 ++
 drivers/nvmem/Makefile                             |   1 +
 drivers/nvmem/raspberrypi-otp.c                    | 159 +++++++++++++++++++++
 include/soc/bcm2835/raspberrypi-firmware.h         |   2 +
 6 files changed, 200 insertions(+)
---
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
change-id: 20260408-rpi-otp-driver-75fce1dcff7d

Best regards,
--  
Gregor Herburger <gregor.herburger@linutronix.de>

[PATCH 1/3] dt-bindings: nvmem: Add a binding for the RPi Firmware OTP register

[Gregor Herburger]

The firmware running on the Raspberry Pi VideoCore can be used to access
OTP registers. There are two OTP regions (private and customer). Add a
binding for these.

Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
 .../bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index 983ea80eaec9..975c8927d75b 100644
--- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -137,6 +137,20 @@ required:
   - compatible
   - mboxes
 
+patternProperties:
+  "^otp-(customer|private)$":
+    type: object
+    additionalProperties: false
+
+    properties:
+      compatible:
+        enum:
+          - raspberrypi,firmware-otp-customer
+          - raspberrypi,firmware-otp-private
+
+    required:
+      - compatible
+
 additionalProperties: false
 
 examples:
@@ -156,6 +170,10 @@ examples:
             #gpio-cells = <2>;
         };
 
+        otp: otp-private {
+            compatible = "raspberrypi,firmware-otp-private";
+        };
+
         reset: reset {
             compatible = "raspberrypi,firmware-reset";
             #reset-cells = <1>;

-- 
2.47.3

Re: [PATCH 1/3] dt-bindings: nvmem: Add a binding for the RPi Firmware OTP register

[Krzysztof Kozlowski]

On Wed, Apr 08, 2026 at 10:00:15AM +0200, Gregor Herburger wrote:
> The firmware running on the Raspberry Pi VideoCore can be used to access
> OTP registers. There are two OTP regions (private and customer). Add a
> binding for these.

A nit, subject: drop second/last, redundant "a binding for the". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18

> 
> Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
> ---
>  .../bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> index 983ea80eaec9..975c8927d75b 100644
> --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> @@ -137,6 +137,20 @@ required:
>    - compatible
>    - mboxes
>  
> +patternProperties:
> +  "^otp-(customer|private)$":

Not a pattern but just "otp".

> +    type: object
> +    additionalProperties: false
> +
> +    properties:
> +      compatible:
> +        enum:
> +          - raspberrypi,firmware-otp-customer
> +          - raspberrypi,firmware-otp-private

I don't understand why having OTP regions is not deducible from
top-level compatible. I also do not get why do you need per OTP
compatible.

There are no resources here, so standard review would be "no" and you
need strong justification in terms of DT.

Best regards,
Krzysztof

[PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver

[Gregor Herburger]

Raspberry Pis have OTP registers which can be accessed through the
videocore firmware. Add a nvmem driver to support these OTP registers.

Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
 drivers/nvmem/Kconfig                      |  12 +++
 drivers/nvmem/Makefile                     |   1 +
 drivers/nvmem/raspberrypi-otp.c            | 159 +++++++++++++++++++++++++++++
 include/soc/bcm2835/raspberrypi-firmware.h |   2 +
 4 files changed, 174 insertions(+)

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 74ddbd0f79b0..892d05fe67be 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -483,4 +483,16 @@ config NVMEM_QORIQ_EFUSE
 	  This driver can also be built as a module. If so, the module
 	  will be called nvmem_qoriq_efuse.
 
+config NVMEM_RASPBERRYPI_OTP
+	tristate "Raspberry Pi OTP support"
+	# Make sure not 'y' when RASPBERRYPI_FIRMWARE is 'm'. This can only
+	# happen when COMPILE_TEST=y, hence the added !RASPBERRYPI_FIRMWARE.
+	depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && !RASPBERRYPI_FIRMWARE)
+	help
+	  This driver provides access to the Raspberry Pi OTP memory via the
+	  nvmem subsystem. The driver supports the customer otp as well as the
+	  device specific private key OTP.
+
+	  This driver can also be built as a module. If so, the module
+	  will be called raspberrypi-otp.
 endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 7252b8ec88d4..8ca2095e068f 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -95,3 +95,4 @@ obj-$(CONFIG_NVMEM_ZYNQMP)		+= nvmem_zynqmp_nvmem.o
 nvmem_zynqmp_nvmem-y			:= zynqmp_nvmem.o
 obj-$(CONFIG_NVMEM_QORIQ_EFUSE)		+= nvmem-qoriq-efuse.o
 nvmem-qoriq-efuse-y			:= qoriq-efuse.o
+obj-$(CONFIG_NVMEM_RASPBERRYPI_OTP)	+= raspberrypi-otp.o
diff --git a/drivers/nvmem/raspberrypi-otp.c b/drivers/nvmem/raspberrypi-otp.c
new file mode 100644
index 000000000000..13ee3784b137
--- /dev/null
+++ b/drivers/nvmem/raspberrypi-otp.c
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <linux/module.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <soc/bcm2835/raspberrypi-firmware.h>
+
+struct rpi_otp_priv {
+	struct rpi_firmware *fw;
+	struct device *dev;
+	u32 read_tag;
+	u32 write_tag;
+};
+
+struct rpi_otp_driver_data {
+	const char *name;
+	u32 read_tag;
+	u32 write_tag;
+};
+
+struct rpi_otp_header {
+	u32 start;
+	u32 count;
+	u32 data[];
+};
+
+static int rpi_otp_read(void *context, unsigned int offset, void *buf, size_t bytes)
+{
+	struct rpi_otp_priv *priv = context;
+	struct rpi_otp_header *fwbuf;
+	int ret;
+
+	fwbuf = kmalloc(sizeof(struct rpi_otp_header) + bytes, GFP_KERNEL);
+	if (!fwbuf)
+		return -ENOMEM;
+
+	fwbuf->start = offset / 4;
+	fwbuf->count = bytes / 4;
+
+	ret = rpi_firmware_property(priv->fw, priv->read_tag, fwbuf,
+				    sizeof(struct rpi_otp_header) + bytes);
+	if (ret)
+		goto out;
+
+	memcpy(buf, fwbuf->data, bytes);
+
+out:
+	kfree(fwbuf);
+	return ret;
+}
+
+static int rpi_otp_write(void *context, unsigned int offset, void *val, size_t bytes)
+{
+	struct rpi_otp_priv *priv = context;
+	struct rpi_otp_header *fwbuf;
+	int ret;
+
+	fwbuf = kmalloc(sizeof(struct rpi_otp_header) + bytes, GFP_KERNEL);
+	if (!fwbuf)
+		return -ENOMEM;
+
+	fwbuf->start = offset / 4;
+	fwbuf->count = bytes / 4;
+	memcpy(fwbuf->data, val, bytes);
+
+	ret = rpi_firmware_property(priv->fw, priv->write_tag, fwbuf,
+				    sizeof(struct rpi_otp_header) + bytes);
+
+	kfree(fwbuf);
+	return ret;
+}
+
+static const struct rpi_otp_driver_data rpi_otp_customer = {
+	.name = "rpi-otp-customer",
+	.read_tag = RPI_FIRMWARE_GET_CUSTOMER_OTP,
+	.write_tag = RPI_FIRMWARE_SET_CUSTOMER_OTP,
+};
+
+static const struct rpi_otp_driver_data rpi_otp_private = {
+	.name = "rpi-otp-private",
+	.read_tag = RPI_FIRMWARE_GET_PRIVATE_OTP,
+	.write_tag = RPI_FIRMWARE_SET_PRIVATE_OTP,
+};
+
+static int rpi_otp_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct nvmem_device *nvmem;
+	struct rpi_otp_priv *priv;
+	struct device_node *np;
+	const struct rpi_otp_driver_data *data;
+	struct nvmem_config config = {
+		.read_only = false,
+		.word_size = 4,
+		.stride = 4,
+		.reg_read = rpi_otp_read,
+		.reg_write = rpi_otp_write,
+		.size = 32,
+	};
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	data = device_get_match_data(dev);
+	if (!data)
+		return -ENODEV;
+
+	np = of_get_parent(dev->of_node);
+	if (!np) {
+		dev_err(dev, "Missing firmware node\n");
+		return -ENOENT;
+	}
+
+	priv->fw = devm_rpi_firmware_get(&pdev->dev, np);
+	of_node_put(np);
+	if (!priv->fw)
+		return -EPROBE_DEFER;
+
+	priv->dev = dev;
+	priv->read_tag = data->read_tag;
+	priv->write_tag = data->write_tag;
+	config.dev = dev;
+	config.priv = priv;
+	config.name = data->name;
+
+	nvmem = devm_nvmem_register(dev, &config);
+	if (IS_ERR(nvmem))
+		return dev_err_probe(dev, PTR_ERR(nvmem), "error registering nvmem config\n");
+
+	return 0;
+}
+
+static const struct of_device_id rpi_otp_of_match[] = {
+	{
+		.compatible = "raspberrypi,firmware-otp-customer",
+		.data = &rpi_otp_customer
+	},
+	{
+		.compatible = "raspberrypi,firmware-otp-private",
+		.data = &rpi_otp_private,
+	},
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, rpi_otp_of_match);
+
+static struct platform_driver raspberry_otp_driver = {
+	.probe	= rpi_otp_probe,
+	.driver = {
+		.name	= "rpi-otp",
+		.of_match_table = rpi_otp_of_match,
+	},
+};
+module_platform_driver(raspberry_otp_driver);
+
+MODULE_AUTHOR("Gregor Herburger <gregor.herburger@linutronix.de>");
+MODULE_DESCRIPTION("Raspberry OTP driver");
+MODULE_LICENSE("GPL");
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index e1f87fbfe554..6e94ccf34f47 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -92,6 +92,8 @@ enum rpi_firmware_property_tag {
 	RPI_FIRMWARE_SET_POE_HAT_VAL =                        0x00030050,
 	RPI_FIRMWARE_NOTIFY_XHCI_RESET =                      0x00030058,
 	RPI_FIRMWARE_NOTIFY_DISPLAY_DONE =                    0x00030066,
+	RPI_FIRMWARE_GET_PRIVATE_OTP =                        0x00030081,
+	RPI_FIRMWARE_SET_PRIVATE_OTP =                        0x00038081,
 
 	/* Dispmanx TAGS */
 	RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE =                   0x00040001,

-- 
2.47.3

Re: [PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver

[Stefan Wahren]

Hi Gregor,

[drop Emma's old address]

Am 08.04.26 um 10:00 schrieb Gregor Herburger:
> Raspberry Pis have OTP registers which can be accessed through the
> videocore firmware. Add a nvmem driver to support these OTP registers.
>
> Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
> ---
>   drivers/nvmem/Kconfig                      |  12 +++
>   drivers/nvmem/Makefile                     |   1 +
>   drivers/nvmem/raspberrypi-otp.c            | 159 +++++++++++++++++++++++++++++
>   include/soc/bcm2835/raspberrypi-firmware.h |   2 +
>   4 files changed, 174 insertions(+)
>
> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> index 74ddbd0f79b0..892d05fe67be 100644
> --- a/drivers/nvmem/Kconfig
> +++ b/drivers/nvmem/Kconfig
> @@ -483,4 +483,16 @@ config NVMEM_QORIQ_EFUSE
>   	  This driver can also be built as a module. If so, the module
>   	  will be called nvmem_qoriq_efuse.
>   
> +config NVMEM_RASPBERRYPI_OTP
> +	tristate "Raspberry Pi OTP support"
> +	# Make sure not 'y' when RASPBERRYPI_FIRMWARE is 'm'. This can only
> +	# happen when COMPILE_TEST=y, hence the added !RASPBERRYPI_FIRMWARE.
I don't think these comments are necessary, because this applies to 
other firmware drivers, too.
> +	depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && !RASPBERRYPI_FIRMWARE)
> +	help
> +	  This driver provides access to the Raspberry Pi OTP memory via the
> +	  nvmem subsystem. The driver supports the customer otp as well as the
> +	  device specific private key OTP.
> +
> +	  This driver can also be built as a module. If so, the module
> +	  will be called raspberrypi-otp.
>   endif
> diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
> index 7252b8ec88d4..8ca2095e068f 100644
> --- a/drivers/nvmem/Makefile
> +++ b/drivers/nvmem/Makefile
> @@ -95,3 +95,4 @@ obj-$(CONFIG_NVMEM_ZYNQMP)		+= nvmem_zynqmp_nvmem.o
>   nvmem_zynqmp_nvmem-y			:= zynqmp_nvmem.o
>   obj-$(CONFIG_NVMEM_QORIQ_EFUSE)		+= nvmem-qoriq-efuse.o
>   nvmem-qoriq-efuse-y			:= qoriq-efuse.o
> +obj-$(CONFIG_NVMEM_RASPBERRYPI_OTP)	+= raspberrypi-otp.o
> diff --git a/drivers/nvmem/raspberrypi-otp.c b/drivers/nvmem/raspberrypi-otp.c
> new file mode 100644
> index 000000000000..13ee3784b137
> --- /dev/null
> +++ b/drivers/nvmem/raspberrypi-otp.c
> @@ -0,0 +1,159 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <linux/module.h>
> +#include <linux/nvmem-provider.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <soc/bcm2835/raspberrypi-firmware.h>
> +
> +struct rpi_otp_priv {
> +	struct rpi_firmware *fw;
> +	struct device *dev;
> +	u32 read_tag;
> +	u32 write_tag;
> +};
> +
> +struct rpi_otp_driver_data {
> +	const char *name;
> +	u32 read_tag;
> +	u32 write_tag;
> +};
> +
> +struct rpi_otp_header {
> +	u32 start;
> +	u32 count;
> +	u32 data[];
> +};
> +
> +static int rpi_otp_read(void *context, unsigned int offset, void *buf, size_t bytes)
> +{
> +	struct rpi_otp_priv *priv = context;
> +	struct rpi_otp_header *fwbuf;
> +	int ret;
> +
> +	fwbuf = kmalloc(sizeof(struct rpi_otp_header) + bytes, GFP_KERNEL);
> +	if (!fwbuf)
> +		return -ENOMEM;
> +
> +	fwbuf->start = offset / 4;
> +	fwbuf->count = bytes / 4;
> +
> +	ret = rpi_firmware_property(priv->fw, priv->read_tag, fwbuf,
> +				    sizeof(struct rpi_otp_header) + bytes);
> +	if (ret)
> +		goto out;
> +
> +	memcpy(buf, fwbuf->data, bytes);
> +
> +out:
> +	kfree(fwbuf);
> +	return ret;
> +}
> +
> +static int rpi_otp_write(void *context, unsigned int offset, void *val, size_t bytes)
> +{
> +	struct rpi_otp_priv *priv = context;
> +	struct rpi_otp_header *fwbuf;
> +	int ret;
> +
> +	fwbuf = kmalloc(sizeof(struct rpi_otp_header) + bytes, GFP_KERNEL);
> +	if (!fwbuf)
> +		return -ENOMEM;
> +
> +	fwbuf->start = offset / 4;
> +	fwbuf->count = bytes / 4;
> +	memcpy(fwbuf->data, val, bytes);
> +
> +	ret = rpi_firmware_property(priv->fw, priv->write_tag, fwbuf,
> +				    sizeof(struct rpi_otp_header) + bytes);
> +
> +	kfree(fwbuf);
> +	return ret;
> +}
> +
> +static const struct rpi_otp_driver_data rpi_otp_customer = {
> +	.name = "rpi-otp-customer",
> +	.read_tag = RPI_FIRMWARE_GET_CUSTOMER_OTP,
> +	.write_tag = RPI_FIRMWARE_SET_CUSTOMER_OTP,
> +};
> +
> +static const struct rpi_otp_driver_data rpi_otp_private = {
> +	.name = "rpi-otp-private",
> +	.read_tag = RPI_FIRMWARE_GET_PRIVATE_OTP,
> +	.write_tag = RPI_FIRMWARE_SET_PRIVATE_OTP,
> +};
> +
> +static int rpi_otp_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct nvmem_device *nvmem;
> +	struct rpi_otp_priv *priv;
> +	struct device_node *np;
> +	const struct rpi_otp_driver_data *data;
> +	struct nvmem_config config = {
> +		.read_only = false,
> +		.word_size = 4,
> +		.stride = 4,
> +		.reg_read = rpi_otp_read,
> +		.reg_write = rpi_otp_write,
> +		.size = 32,
> +	};
> +
> +	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> +	if (!priv)
> +		return -ENOMEM;
> +
> +	data = device_get_match_data(dev);
> +	if (!data)
> +		return -ENODEV;
> +
> +	np = of_get_parent(dev->of_node);
> +	if (!np) {
> +		dev_err(dev, "Missing firmware node\n");
> +		return -ENOENT;
> +	}
> +
> +	priv->fw = devm_rpi_firmware_get(&pdev->dev, np);
> +	of_node_put(np);
> +	if (!priv->fw)
> +		return -EPROBE_DEFER;
> +
> +	priv->dev = dev;
> +	priv->read_tag = data->read_tag;
> +	priv->write_tag = data->write_tag;
> +	config.dev = dev;
> +	config.priv = priv;
> +	config.name = data->name;
> +
> +	nvmem = devm_nvmem_register(dev, &config);
> +	if (IS_ERR(nvmem))
> +		return dev_err_probe(dev, PTR_ERR(nvmem), "error registering nvmem config\n");
> +
> +	return 0;
> +}
Is there any reason, why we cannot register this driver in 
rpi_firmware_probe() like hwmon and clk driver?

I like to avoid the complete dt-binding from patch 1.
> +
> +static const struct of_device_id rpi_otp_of_match[] = {
> +	{
> +		.compatible = "raspberrypi,firmware-otp-customer",
> +		.data = &rpi_otp_customer
> +	},
> +	{
> +		.compatible = "raspberrypi,firmware-otp-private",
> +		.data = &rpi_otp_private,
> +	},
> +	{ /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, rpi_otp_of_match);
> +
> +static struct platform_driver raspberry_otp_driver = {
> +	.probe	= rpi_otp_probe,
> +	.driver = {
> +		.name	= "rpi-otp",
> +		.of_match_table = rpi_otp_of_match,
> +	},
> +};
> +module_platform_driver(raspberry_otp_driver);
> +
> +MODULE_AUTHOR("Gregor Herburger <gregor.herburger@linutronix.de>");
> +MODULE_DESCRIPTION("Raspberry OTP driver");
Raspberry Pi OTP driver ?

Regards
> +MODULE_LICENSE("GPL");
> diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
> index e1f87fbfe554..6e94ccf34f47 100644
> --- a/include/soc/bcm2835/raspberrypi-firmware.h
> +++ b/include/soc/bcm2835/raspberrypi-firmware.h
> @@ -92,6 +92,8 @@ enum rpi_firmware_property_tag {
>   	RPI_FIRMWARE_SET_POE_HAT_VAL =                        0x00030050,
>   	RPI_FIRMWARE_NOTIFY_XHCI_RESET =                      0x00030058,
>   	RPI_FIRMWARE_NOTIFY_DISPLAY_DONE =                    0x00030066,
> +	RPI_FIRMWARE_GET_PRIVATE_OTP =                        0x00030081,
> +	RPI_FIRMWARE_SET_PRIVATE_OTP =                        0x00038081,
>   
>   	/* Dispmanx TAGS */
>   	RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE =                   0x00040001,
>

Re: [PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver

[Gregor Herburger]

Hi Stefan,

thanks for the review.

> > +config NVMEM_RASPBERRYPI_OTP
> > +	tristate "Raspberry Pi OTP support"
> > +	# Make sure not 'y' when RASPBERRYPI_FIRMWARE is 'm'. This can only
> > +	# happen when COMPILE_TEST=y, hence the added !RASPBERRYPI_FIRMWARE.
> I don't think these comments are necessary, because this applies to other
> firmware drivers, too.

I have seen this in all the other drivers that depend on RASPBERRYPI_FIRMWARE
so I added it here as well. I can remove it.
> > +	depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && !RASPBERRYPI_FIRMWARE)
> > +	help
> > +	  This driver provides access to the Raspberry Pi OTP memory via the
> > +	  nvmem subsystem. The driver supports the customer otp as well as the
> > +	  device specific private key OTP.
> > +
> > +	  This driver can also be built as a module. If so, the module
> > +	  will be called raspberrypi-otp.
> >   endif
> > diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
> > index 7252b8ec88d4..8ca2095e068f 100644

> Is there any reason, why we cannot register this driver in
> rpi_firmware_probe() like hwmon and clk driver?
> 
> I like to avoid the complete dt-binding from patch 1.

The private OTP registers are not available on all Raspberries. Afaik
only on 4 and 5. So I think these registers must be described through
the device tree. Therefore the bindings are needed.

> > +module_platform_driver(raspberry_otp_driver);
> > +
> > +MODULE_AUTHOR("Gregor Herburger <gregor.herburger@linutronix.de>");
> > +MODULE_DESCRIPTION("Raspberry OTP driver");
> Raspberry Pi OTP driver ?

Yes. I will update in the next version.

Re: [PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver

[Stefan Wahren]

Am 08.04.26 um 21:47 schrieb Gregor Herburger:
> Hi Stefan,
>
> thanks for the review.
>> Is there any reason, why we cannot register this driver in
>> rpi_firmware_probe() like hwmon and clk driver?
>>
>> I like to avoid the complete dt-binding from patch 1.
> The private OTP registers are not available on all Raspberries. Afaik
> only on 4 and 5. So I think these registers must be described through
> the device tree. Therefore the bindings are needed.
This binding doesn't represent some kind of hardware, it's just some 
firmware interface. A proper DT binding would describe the MMIO address 
range for OTP access.
If you need some distinction between the Raspberry Pi generations there 
are firmware tags to do this.

Regards

Re: [PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver

[Gregor Herburger]

On Wed, Apr 08, 2026 at 10:03:47PM +0200, Stefan Wahren wrote:
> Am 08.04.26 um 21:47 schrieb Gregor Herburger:
> > Hi Stefan,
> > 
> > thanks for the review.
> > > Is there any reason, why we cannot register this driver in
> > > rpi_firmware_probe() like hwmon and clk driver?
> > > 
> > > I like to avoid the complete dt-binding from patch 1.
> > The private OTP registers are not available on all Raspberries. Afaik
> > only on 4 and 5. So I think these registers must be described through
> > the device tree. Therefore the bindings are needed.
> This binding doesn't represent some kind of hardware, it's just some
> firmware interface. A proper DT binding would describe the MMIO address
> range for OTP access.

I think it does represent real hardware. Although it is hidden through the
firmware. Not all hardware must be MMIO addresses. 

The only driver that does not have a DT node is the hwmon driver. All
other drivers (clock, gpio, touchscreeen, reset, pwm) do have a DT
binding. Looking at the comment in rpi_register_clk_driver this
seems to be some legacy behaviour for older DTs for the clock driver. 

> If you need some distinction between the Raspberry Pi generations there are
> firmware tags to do this.

So what is your suggestion? What tags do you mean?

I don't understand why you want to avoid the dt-binding. What is the
problem with dt-bindings?
What is the benefit of registering the driver in rpi_firmware_probe?

Imho describing this in the DT is the more natural way to do this. E.g.
if in the future there is a raspberry pi with a 64Byte otp it could easily
be supported by adding a devicetree property and add it to the driver.

Regards
Gregor

Re: [PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver

[Stefan Wahren]

Am 09.04.26 um 10:05 schrieb Gregor Herburger:
> On Wed, Apr 08, 2026 at 10:03:47PM +0200, Stefan Wahren wrote:
>> Am 08.04.26 um 21:47 schrieb Gregor Herburger:
>>> Hi Stefan,
>>>
>>> thanks for the review.
>>>> Is there any reason, why we cannot register this driver in
>>>> rpi_firmware_probe() like hwmon and clk driver?
>>>>
>>>> I like to avoid the complete dt-binding from patch 1.
>>> The private OTP registers are not available on all Raspberries. Afaik
>>> only on 4 and 5. So I think these registers must be described through
>>> the device tree. Therefore the bindings are needed.
>> This binding doesn't represent some kind of hardware, it's just some
>> firmware interface. A proper DT binding would describe the MMIO address
>> range for OTP access.
> I think it does represent real hardware. Although it is hidden through the
> firmware. Not all hardware must be MMIO addresses.
>
> The only driver that does not have a DT node is the hwmon driver. All
> other drivers (clock, gpio, touchscreeen, reset, pwm) do have a DT
> binding. Looking at the comment in rpi_register_clk_driver this
> seems to be some legacy behaviour for older DTs for the clock driver.
There is a long history of different approaches how to implement the 
VideoCore firmware interface for the Raspberry Pi and not all of them 
are good from today's perspective.

One big problem with DT binding is that the kernel must be compatible 
with all mainline DTS versions. This sounds trivial, but it's not. Since 
we cannot assume that kernel & DTB are updated at the same time. So we 
need to keep these bad solutions from the past.
>> If you need some distinction between the Raspberry Pi generations there are
>> firmware tags to do this.
> So what is your suggestion? What tags do you mean?
Your driver already use firmware tags to access the OTPs via firmware. 
You can ask the Raspberry Pi guys, how to do the distinction in a 
efficient/maintainable way.

My suggestion would be to look at 
https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface#get-board-model

and

https://github.com/u-boot/u-boot/blob/master/board/raspberrypi/rpi/rpi.c#L95

The compatible "raspberrypi,bcm2712-firmware" approach is more straight 
forward, but requires a newer DTB. See above.

Best regards

Re: [PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver

[Krzysztof Kozlowski]

On Wed, Apr 08, 2026 at 10:00:16AM +0200, Gregor Herburger wrote:
> Raspberry Pis have OTP registers which can be accessed through the
> videocore firmware. Add a nvmem driver to support these OTP registers.
> 
> Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
> ---
>  drivers/nvmem/Kconfig                      |  12 +++
>  drivers/nvmem/Makefile                     |   1 +
>  drivers/nvmem/raspberrypi-otp.c            | 159 +++++++++++++++++++++++++++++
>  include/soc/bcm2835/raspberrypi-firmware.h |   2 +
>  4 files changed, 174 insertions(+)
> 
> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> index 74ddbd0f79b0..892d05fe67be 100644
> --- a/drivers/nvmem/Kconfig
> +++ b/drivers/nvmem/Kconfig
> @@ -483,4 +483,16 @@ config NVMEM_QORIQ_EFUSE
>  	  This driver can also be built as a module. If so, the module
>  	  will be called nvmem_qoriq_efuse.
>  
> +config NVMEM_RASPBERRYPI_OTP
> +	tristate "Raspberry Pi OTP support"
> +	# Make sure not 'y' when RASPBERRYPI_FIRMWARE is 'm'. This can only
> +	# happen when COMPILE_TEST=y, hence the added !RASPBERRYPI_FIRMWARE.

Drop comment and use standard rules for multiple modules.

https://lwn.net/Articles/944368/

Best regards,
Krzysztof

[PATCH 3/3] arm64: dts: broadcom: bcm2712: Add the otp nodes to firmware

[Gregor Herburger]

The Raspberry Pi 5 has two OTP registers (private and customer), add these
to the devicetree.

Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
 arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
index b7a6bc34ae1a..676081198213 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
@@ -60,6 +60,14 @@ reset: reset {
 				#reset-cells = <1>;
 			};
 
+			otp_customer: otp-customer {
+				compatible = "raspberrypi,firmware-otp-customer";
+			};
+
+			otp_private: otp-private {
+				compatible = "raspberrypi,firmware-otp-private";
+			};
+
 			power: power {
 				compatible = "raspberrypi,bcm2835-power";
 				firmware = <&firmware>;

-- 
2.47.3

Re: [PATCH 3/3] arm64: dts: broadcom: bcm2712: Add the otp nodes to firmware

[Krzysztof Kozlowski]

On Wed, Apr 08, 2026 at 10:00:17AM +0200, Gregor Herburger wrote:
> The Raspberry Pi 5 has two OTP registers (private and customer), add these
> to the devicetree.

So this sentence confirms my question on bindings - your device
raspberrypi,bcm2835-firmware has these, thus you do not need these child
nodes at all. Neither compatibles.

Drop entire DTS and binding patches.

See also writing-bindings and DTS101 why we do not allow this.

Best regards,
Krzysztof

Re: [PATCH 3/3] arm64: dts: broadcom: bcm2712: Add the otp nodes to firmware

[Gregor Herburger]

Hi Krzysztof,

thanks for reviewing.

On Thu, Apr 09, 2026 at 10:15:12AM +0200, Krzysztof Kozlowski wrote:
> On Wed, Apr 08, 2026 at 10:00:17AM +0200, Gregor Herburger wrote:
> > The Raspberry Pi 5 has two OTP registers (private and customer), add these
> > to the devicetree.
> 
> So this sentence confirms my question on bindings - your device
> raspberrypi,bcm2835-firmware has these, thus you do not need these child
> nodes at all. Neither compatibles.

I dont't think so. In my understanding the bcm2835-firmware does not
provide the otp registers but only provides the interface to the
registers. Though I don't know the details how this is done but [1] says
that only BCM2712 has 512bits and the others (like bcm2711) have
256bits. So both devicetrees have the raspberrypi,bcm2835-firmware node
but only the bcm2712 has the raspberrypi,firmware-otp-private node while the 
raspberrypi,firmware-otp-customer is available in all raspberrys.

> Drop entire DTS and binding patches.

If I drop the binding patch how to distinguish the variants? Should I
add a SoC specific compatible? e.g. `raspberrypi,bcm2712-firmware` and
use it in the firmware/raspberrypi driver to add the second otp region?

Also what I don't understand why we have all the bindings for
'raspberrypi,firmware-clocks', 'raspberrypi,firmware-gpio',
'raspberrypi,firmware-reset', 'raspberrypi,firmware-poe-pwm' and
'raspberrypi,firmware-ts'. What is the difference between these devices
and the otp registers. They are all accessed through the firmware.

[1] https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#device-specific-private-key

Best regards
Gregor

Re: [PATCH 3/3] arm64: dts: broadcom: bcm2712: Add the otp nodes to firmware

[Krzysztof Kozlowski]

On 09/04/2026 14:02, Gregor Herburger wrote:
> Hi Krzysztof,
> 
> thanks for reviewing.
> 
> On Thu, Apr 09, 2026 at 10:15:12AM +0200, Krzysztof Kozlowski wrote:
>> On Wed, Apr 08, 2026 at 10:00:17AM +0200, Gregor Herburger wrote:
>>> The Raspberry Pi 5 has two OTP registers (private and customer), add these
>>> to the devicetree.
>>
>> So this sentence confirms my question on bindings - your device
>> raspberrypi,bcm2835-firmware has these, thus you do not need these child
>> nodes at all. Neither compatibles.
> 
> I dont't think so. In my understanding the bcm2835-firmware does not
> provide the otp registers but only provides the interface to the
> registers. Though I don't know the details how this is done but [1] says
> that only BCM2712 has 512bits and the others (like bcm2711) have

Still the same. s/otp/interface/ so your device provides interface.

> 256bits. So both devicetrees have the raspberrypi,bcm2835-firmware node
> but only the bcm2712 has the raspberrypi,firmware-otp-private node while the 

Why does bcm2712 use bcm2835 compatible?

Nodes and properties are not a solution. See DTS101 question - "...
because my new device, which is compatible with an older one, does not
support ..." and answer: No.



> raspberrypi,firmware-otp-customer is available in all raspberrys.
> 
>> Drop entire DTS and binding patches.
> 
> If I drop the binding patch how to distinguish the variants? Should I
> add a SoC specific compatible? e.g. `raspberrypi,bcm2712-firmware` and
> use it in the firmware/raspberrypi driver to add the second otp region?

So you have different devices/variants? What is the "variant" here?

Writing-bindings asks you to have per device compatible. Why standard
rules do not apply here? (see also DTS101)

> 
> Also what I don't understand why we have all the bindings for

Neither do I.

> 'raspberrypi,firmware-clocks', 'raspberrypi,firmware-gpio',
> 'raspberrypi,firmware-reset', 'raspberrypi,firmware-poe-pwm' and
> 'raspberrypi,firmware-ts'. What is the difference between these devices
> and the otp registers. They are all accessed through the firmware.


Best regards,
Krzysztof

Re: [PATCH 3/3] arm64: dts: broadcom: bcm2712: Add the otp nodes to firmware

[Gregor Herburger]

On Thu, Apr 09, 2026 at 02:15:32PM +0200, Krzysztof Kozlowski wrote:
> On 09/04/2026 14:02, Gregor Herburger wrote:
> > Hi Krzysztof,
> > 
> > thanks for reviewing.
> > 
> > On Thu, Apr 09, 2026 at 10:15:12AM +0200, Krzysztof Kozlowski wrote:
> >> On Wed, Apr 08, 2026 at 10:00:17AM +0200, Gregor Herburger wrote:
> >>> The Raspberry Pi 5 has two OTP registers (private and customer), add these
> >>> to the devicetree.
> >>
> >> So this sentence confirms my question on bindings - your device
> >> raspberrypi,bcm2835-firmware has these, thus you do not need these child
> >> nodes at all. Neither compatibles.
> > 
> > I dont't think so. In my understanding the bcm2835-firmware does not
> > provide the otp registers but only provides the interface to the
> > registers. Though I don't know the details how this is done but [1] says
> > that only BCM2712 has 512bits and the others (like bcm2711) have
> 
> Still the same. s/otp/interface/ so your device provides interface.
> 
Ok understood.

> > 256bits. So both devicetrees have the raspberrypi,bcm2835-firmware node
> > but only the bcm2712 has the raspberrypi,firmware-otp-private node while the 
> 
> Why does bcm2712 use bcm2835 compatible?

I have no idea. But it is like this.
> 
> Nodes and properties are not a solution. See DTS101 question - "...
> because my new device, which is compatible with an older one, does not
> support ..." and answer: No.
> 
> 
> 
> > raspberrypi,firmware-otp-customer is available in all raspberrys.
> > 
> >> Drop entire DTS and binding patches.
> > 
> > If I drop the binding patch how to distinguish the variants? Should I
> > add a SoC specific compatible? e.g. `raspberrypi,bcm2712-firmware` and
> > use it in the firmware/raspberrypi driver to add the second otp region?
> 
> So you have different devices/variants? What is the "variant" here?

Seems so. I suppose there is at least a bcm2712 variant and a non-bcm2712
variant (which is currently confusingly named 'raspberrypi,bcm2835-firmware').
> 
> Writing-bindings asks you to have per device compatible. Why standard
> rules do not apply here? (see also DTS101)

I am not arguing that the rules do not apply here. I want to find out
what is the correct way to do it. 

Should there then be a 'raspberrypi,bcm2712-firmware' compatible with
'raspberrypi,bcm2835-firmware' fallback?

> 
> > 
> > Also what I don't understand why we have all the bindings for
> 
> Neither do I.
Ok good. That is what confused me.

Best regards,
Gregor

Re: [PATCH 3/3] arm64: dts: broadcom: bcm2712: Add the otp nodes to firmware

[Krzysztof Kozlowski]

On 09/04/2026 15:03, Gregor Herburger wrote:
>>>
>>> If I drop the binding patch how to distinguish the variants? Should I
>>> add a SoC specific compatible? e.g. `raspberrypi,bcm2712-firmware` and
>>> use it in the firmware/raspberrypi driver to add the second otp region?
>>
>> So you have different devices/variants? What is the "variant" here?
> 
> Seems so. I suppose there is at least a bcm2712 variant and a non-bcm2712
> variant (which is currently confusingly named 'raspberrypi,bcm2835-firmware').
>>
>> Writing-bindings asks you to have per device compatible. Why standard
>> rules do not apply here? (see also DTS101)
> 
> I am not arguing that the rules do not apply here. I want to find out
> what is the correct way to do it. 
> 
> Should there then be a 'raspberrypi,bcm2712-firmware' compatible with
> 'raspberrypi,bcm2835-firmware' fallback?

Yes, most likely. Let's wait a bit - maybe someone from Raspberry or
Broadcom will clarify things here.

Best regards,
Krzysztof