[PATCH v3] misc: Add RZG2L OTP support

[Marek Vasut]

On 4/27/26 11:15 AM, Mathieu Othacehe wrote:

Hello Mathieu,

>> If you do want to expose the fuses via SMC , then the fuse region has to be
>> secure only , so only TFA can access it . TFA can then decide which exact fuse
>> the user can or can not read or program, on a single fuse granularity.
>>
>> By default, non-secure user should be able to read some select fuses (IDs),
>> program no fuses. User should have the ability to expose some select fuses as
>> programmable, for manufacturing purposes.
>>
>> Mathieu, which fuses exactly do you plan to program ?
> 
> I plan to program all fuses (enable secureboot, ROT hash, user
> encryption keys) using U-Boot directly or U-Boot + TF-A during
> manufacturing.
> 
> I then see two possibilities:
> 
> 1. During manufacturing, use a specific TF-A that allows fusing from the
> non-secure world (with SYS_SLVACCCTL7 register). Fuse directly
> everything from U-Boot, using the patch under review. Then, flash the
> regular, default TF-A that does not allow fusing from the non-secure
> world.
> 
> 2. During manufacturing, use a specific TF-A that allows, via SMC,
> fusing everything from the non-secure world. Write a new U-Boot driver
> that performs fusing through SMC. Use it to fuse everything from U-Boot
> during manufacturing. Then, flash the regular, default TF-A that only
> allows specific ID fuse read via SMC.
> 
> Both options require a specific TF-A during manufacturing. The only real
> difference to me is that with option 2, we can allow ID fuse read from
> U-Boot via SMC during regular use.

This difference is in fact a bit more important.

I agree that in both cases, it would be necessary to have a TFA capable 
of programming the fuses, with one or the other mechanisms.

It is possible to expose the fuse block as read-only to U-Boot/Linux in 
either case, but this may be undesired. It may be undesired to expose 
all fuses to U-Boot/Linux, instead, it may be desired to expose only a 
subset of fuses to U-Boot/Linux and prevent U-Boot/Linux from even 
reading other fuses.

This is what I see as a benefit of option 2 -- it is possible to limit 
which fuses can be accessed from U-Boot/Linux with single fuse 
granularity. This is not possible with option 1.

But please look at prior art if/when implementing option 2 and learn 
from their mistakes, Linux drivers/nvmem/imx-ocotp-scu.c is for MX8Q SCU 
which is old and odd so ideally avoid that as an example, 
drivers/nvmem/stm32-romem.c is I think limited to programming only full 
32bit words (?) and does not handle single-fuse granularity. It would 
also be good to design the SMC ABI in a way that maps easily to Linux 
NVMEM API and in a way that is generic, so others could reuse it (if 
possible) and reuse the (generic SMC fuse ABI) driver.