[PATCH v3 1/3] dt-bindings: nvmem: lan9662-otpc: Add LAN969x series

[PATCH v3 1/3] dt-bindings: nvmem: lan9662-otpc: Add LAN969x series

[Robert Marko]

From: Robert Marko <robert.marko@sartura.hr>

Unlike LAN966x series which has 8K of OTP space, LAN969x series has 16K of
OTP space, so document the compatible.

Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
Changes in v3:
* Pick Acked-by from Conor

 .../devicetree/bindings/nvmem/microchip,lan9662-otpc.yaml        | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/nvmem/microchip,lan9662-otpc.yaml b/Documentation/devicetree/bindings/nvmem/microchip,lan9662-otpc.yaml
index f97c6beb4766..c03e96afe564 100644
--- a/Documentation/devicetree/bindings/nvmem/microchip,lan9662-otpc.yaml
+++ b/Documentation/devicetree/bindings/nvmem/microchip,lan9662-otpc.yaml
@@ -25,6 +25,7 @@ properties:
           - const: microchip,lan9662-otpc
       - enum:
           - microchip,lan9662-otpc
+          - microchip,lan9691-otpc
 
   reg:
     maxItems: 1
-- 
2.54.0

[PATCH v3 2/3] nvmem: lan9662-otp: add support for LAN969x

[Robert Marko]

From: Horatiu Vultur <horatiu.vultur@microchip.com>

Microchip LAN969x provides OTP with the same control logic, only the size
differs as LAN969x has 16KB of OTP instead of 8KB like on LAN966x.

Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
Changes in v3:
* Rebase onto current next-20260508

 drivers/nvmem/Kconfig        |  2 +-
 drivers/nvmem/lan9662-otpc.c | 12 +++++++++---
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 74ddbd0f79b0..78b648e14727 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -138,7 +138,7 @@ config NVMEM_JZ4780_EFUSE
 
 config NVMEM_LAN9662_OTPC
 	tristate "Microchip LAN9662 OTP controller support"
-	depends on SOC_LAN966 || COMPILE_TEST
+	depends on SOC_LAN966 || ARCH_LAN969X || COMPILE_TEST
 	depends on HAS_IOMEM
 	help
 	  This driver enables the OTP controller available on Microchip LAN9662
diff --git a/drivers/nvmem/lan9662-otpc.c b/drivers/nvmem/lan9662-otpc.c
index 56fc19f092a7..62d1d6381bf8 100644
--- a/drivers/nvmem/lan9662-otpc.c
+++ b/drivers/nvmem/lan9662-otpc.c
@@ -27,7 +27,6 @@
 #define OTP_OTP_STATUS_OTP_CPUMPEN		BIT(1)
 #define OTP_OTP_STATUS_OTP_BUSY			BIT(0)
 
-#define OTP_MEM_SIZE 8192
 #define OTP_SLEEP_US 10
 #define OTP_TIMEOUT_US 500000
 
@@ -176,7 +175,6 @@ static struct nvmem_config otp_config = {
 	.word_size = 1,
 	.reg_read = lan9662_otp_read,
 	.reg_write = lan9662_otp_write,
-	.size = OTP_MEM_SIZE,
 };
 
 static int lan9662_otp_probe(struct platform_device *pdev)
@@ -196,6 +194,7 @@ static int lan9662_otp_probe(struct platform_device *pdev)
 
 	otp_config.priv = otp;
 	otp_config.dev = dev;
+	otp_config.size = (uintptr_t) device_get_match_data(dev);
 
 	nvmem = devm_nvmem_register(dev, &otp_config);
 
@@ -203,7 +202,14 @@ static int lan9662_otp_probe(struct platform_device *pdev)
 }
 
 static const struct of_device_id lan9662_otp_match[] = {
-	{ .compatible = "microchip,lan9662-otpc", },
+	{
+		.compatible = "microchip,lan9662-otpc",
+		.data = (const void *) SZ_8K,
+	},
+	{
+		.compatible = "microchip,lan9691-otpc",
+		.data = (const void *) SZ_16K,
+	},
 	{ },
 };
 MODULE_DEVICE_TABLE(of, lan9662_otp_match);
-- 
2.54.0

Re: [PATCH v3 2/3] nvmem: lan9662-otp: add support for LAN969x

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The driver mutates a shared static global structure (`otp_config`) during its `probe()` function, creating a data race on concurrent probes.
--

commit 084765687704216b34f261a961d208c0c6497f50
Author: Horatiu Vultur <horatiu.vultur@microchip.com>

nvmem: lan9662-otp: add support for LAN969x

This commit adds support for the Microchip LAN969x to the lan9662-otp driver.
It relies on the existing control logic while allowing the OTP size to vary
based on device tree match data.

> diff --git a/drivers/nvmem/lan9662-otpc.c b/drivers/nvmem/lan9662-otpc.c
> index 56fc19f092a7f..62d1d6381bf88 100644
> --- a/drivers/nvmem/lan9662-otpc.c
> +++ b/drivers/nvmem/lan9662-otpc.c

[ ... ]

> @@ -196,6 +194,7 @@ static int lan9662_otp_probe(struct platform_device *pdev)
>  
>  	otp_config.priv = otp;
>  	otp_config.dev = dev;
> +	otp_config.size = (uintptr_t) device_get_match_data(dev);

Does modifying the static otp_config structure during probe create a data
race?

If multiple device instances are probed concurrently, threads could race to
update these fields. This could lead to one instance being registered with
another's private data before devm_nvmem_register() creates its internal
copy.

If that happens and the latter device is unbound, its devm-managed memory is
freed, which could result in a use-after-free when the first device attempts
to access the nvmem interface.

Would it be safer to allocate the nvmem_config structure locally on the
stack within the probe function instead of using a global static structure?

>  
>  	nvmem = devm_nvmem_register(dev, &otp_config);
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260515115954.701155-1-robimarko@gmail.com?part=2

[PATCH v3 3/3] arm64: dts: microchip: lan969x: add OTP node

[Robert Marko]

From: Robert Marko <robert.marko@sartura.hr>

Add the required OTP on LAN969x.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
 arch/arm64/boot/dts/microchip/lan9691.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/microchip/lan9691.dtsi b/arch/arm64/boot/dts/microchip/lan9691.dtsi
index 235e56bebbdb..ed997d87dd09 100644
--- a/arch/arm64/boot/dts/microchip/lan9691.dtsi
+++ b/arch/arm64/boot/dts/microchip/lan9691.dtsi
@@ -100,6 +100,11 @@ usb: usb@300000 {
 			status = "disabled";
 		};
 
+		otp: otp@e0021000 {
+			compatible = "microchip,lan9691-otpc";
+			reg = <0xe0021000 0x1000>;
+		};
+
 		flx0: flexcom@e0040000 {
 			compatible = "microchip,lan9691-flexcom", "atmel,sama5d2-flexcom";
 			reg = <0xe0040000 0x100>;
-- 
2.54.0