nvmem: Support efuse/OTP devices

[pdgendt]

Problem Description

The NVMEM subsystem currently only has support for EEPROM devices. In an effort to add support for efuse/One-Time-Programming (OTP) devices it has become clear that there are multiple solutions to tackle this.

This RFC gathers information from the different proposals.

Proposed Change (Summary)

There's a need to be able to describe NVMEM cells in the device tree, that are located in efuse/OTP devices, for example:

efuse: efuse {
	compatible = "vendor,efuse";

	nvmem-layout {
		compatible = "fixed-layout";
		#address-cells = <1>;
		#size-cells = <1>;

		cell0: cell@0 {
			reg = <0x0 0x1>;
			#nvmem-cell-cells = <0>;
			read-only;
		};
	};
};

And NVMEM consumers should be able to read from and optionally write to those devices.

Proposed Change (Detailed)

These are some of the current proposals that were brought up in different PR/comments (order does not indicate any preference):

• ntroduce a generic nvmem driver API [PoC] Add nvmem device driver model #98369
• Introduce a fuse driver API drivers: fuse: add fuse driver subsystem with STM32 Ethernet MAC adress loading #98149
• Use the syscon API drivers: syscon: Preparation for NVMEM usage #98140
• Introduce an nvmem provider API main...teslabs:zephyr:sf32lb-hwinfo
• Rework NVMEM subsystem to become a driver [PoC] Rework NVMEM subsystem to become a driver #98285

Dependencies

Moving forward it should be possible for other subsystems to turn into NVMEM consumers and leverage the NVMEM providers for accessing efuse/OTP data.

Concerns and Unresolved Questions

Listing concerns raised from various places:

• A new API vs re-using an existing one (eeprom, syscon, ...) https://github.com/zephyrproject-rtos/zephyr/pull/98149/files#r2455488653
• Programming efuse/OTP data is critical and can't be undone, writing is not as trivial like with EEPROM drivers: fuse: add fuse driver subsystem with STM32 Ethernet MAC adress loading #98149 (comment)
• The driver should have clear purpose drivers: syscon: Preparation for NVMEM usage #98140 (review)

Alternatives Considered

No response

[maass-hamburg]

as I already started in #98149 (comment) we should be really careful and super restrictive when it comes to "writing" otps and fuses. If we are going to implement writing, it should be disabled by default and nothing in-tree should change the default, select it, imply it and only depend on it and probably add a build warning, like we have with CONFIG_TIMER_RANDOM_GENERATOR and CONFIG_TEST_CSPRNG_GENERATOR.

[henrikbrixandersen]

as I already started in #98149 (comment) we should be really careful and super restrictive when it comes to "writing" otps and fuses. If we are going to implement writing, it should be disabled by default and nothing in-tree should change the default, select it, imply it and only depend on it and probably add a build warning, like we have with CONFIG_TIMER_RANDOM_GENERATOR and CONFIG_TEST_CSPRNG_GENERATOR.

I agree. Perhaps this alone could warrant having a dedicated driver subsystem for "fuses"?

[pdgendt]

as I already started in #98149 (comment) we should be really careful and super restrictive when it comes to "writing" otps and fuses. If we are going to implement writing, it should be disabled by default and nothing in-tree should change the default, select it, imply it and only depend on it and probably add a build warning, like we have with CONFIG_TIMER_RANDOM_GENERATOR and CONFIG_TEST_CSPRNG_GENERATOR.

I agree. Perhaps this alone could warrant having a dedicated driver subsystem for "fuses"?

We all agree, I think. That's why the read-only property exists for NVMEM cells. That way the data needs to be provisioned outside the scope of the NVMEM subsystem.
But it should be possible to provision it in some form, which can be decided as part of the outcome in this RFC.

[GseoC]

Should the provisioning feature be flagged by the hardening tool?

[maass-hamburg]

But it should be possible to provision it in some form, which can be decided as part of the outcome in this RFC.

Yes if its simple enough, yes. If you "just" have fuses, where you can always blow the fuses out, that haven't been, sure. But there are also f.e. crypto chips, that would only let you set the otp, when you are authenticated and also only during provisioning , thats something I wouldn't like to expose via the api and would just say, that from the apis viewpoint, that that one can only be read.

[pdgendt]

Should the provisioning feature be flagged by the hardening tool?

Not sure what you mean, but I think it's outside of the scope of this RFC?

[GseoC]

Should the provisioning feature be flagged by the hardening tool?

Not sure what you mean, but I think it's outside of the scope of this RFC?

I mean OTP provisioning by an application may be considered unsafe. Therefore, when hardening the configuration, if this feature is enabled, then it may trigger some kind of warning. But yes, it's probably out of scope there.

[ZhaoxiangJin]

Hello @GseoC, could you please help to review this PR? I can't seem to @ you in this PR. Thanks.