[PATCH v1 5/7] nvmem: regmap: Implement protect operation using regmap_seal

[Sascha Hauer]

On Fri, May 30, 2025 at 01:41:04PM +0200, Oleksij Rempel wrote:
> Implement the NVMEM 'protect' operation for devices registered via
> regmap. This adds a new static function, nvmem_regmap_protect, which
> acts as an adapter between the NVMEM core's reg_protect callback
> and the recently added regmap_seal() API.
> 
> The nvmem_regmap_protect function:
>   - Translates the NVMEM 'prot' parameter (0 for unprotect, 1 for
>     protect) into the corresponding REGMAP_SEAL_CLEAR |
>     REGMAP_SEAL_WRITE_PROTECT or REGMAP_SEAL_WRITE_PROTECT |
>     REGMAP_SEAL_PERMANENT flags for the regmap_seal() call.
>   - Enforces that the NVMEM operation's offset and size are aligned
>     to the regmap's value byte size (obtained via
>     regmap_get_val_bytes()).
>   - Iterates over the specified byte range, calling regmap_seal() for
>     each underlying hardware word.
> 
> By assigning nvmem_regmap_protect to config.reg_protect within
> nvmem_regmap_register_with_pp, NVMEM devices that are backed by a
> regmap can now expose hardware-level protection capabilities. This
> is essential for drivers like the STM32 BSEC (in a subsequent patch)
> to enable features such as OTP (One-Time Programmable) memory locking
> through the standard NVMEM 'protect' cdev operation, provided their
> underlying regmap_bus implements the necessary reg_seal method.
> 
> Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
> ---
>  drivers/nvmem/regmap.c | 65 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 65 insertions(+)
> 
> diff --git a/drivers/nvmem/regmap.c b/drivers/nvmem/regmap.c
> index 24712fbb0f33..681cdf313e71 100644
> --- a/drivers/nvmem/regmap.c
> +++ b/drivers/nvmem/regmap.c
> @@ -63,6 +63,70 @@ static int nvmem_regmap_read(void *ctx, unsigned offset, void *buf, size_t bytes
>  	return 0;
>  }
>  
> +static int nvmem_regmap_protect(void *ctx, unsigned int offset, size_t bytes,
> +				int prot)
> +{
> +	unsigned int seal_flags = 0;
> +	struct regmap *map = ctx;
> +	size_t reg_val_bytes;
> +	unsigned int i;
> +	int ret = 0;
> +
> +	reg_val_bytes = regmap_get_val_bytes(map);
> +	if (reg_val_bytes == 0) {
> +		dev_err(regmap_get_device(map), "Invalid regmap value byte size (0)\n");
> +		return -EINVAL;
> +	}
> +
> +	/* NVMEM protect operations should typically be on aligned boundaries
> +	 * matching the hardware's lockable unit (which is regmap's val_bytes
> +	 * here).
> +	 */
> +	if ((offset % reg_val_bytes) != 0 || (bytes % reg_val_bytes) != 0) {
> +		dev_warn(regmap_get_device(map),
> +			 "NVMEM protect op for regmap: offset (0x%x) or size (0x%zx) not aligned to register size (%zu bytes).\n",
> +			 offset, bytes, reg_val_bytes);
> +		return -EINVAL;
> +	}
> +
> +	switch (prot) {
> +	case NVMEM_PROTECT_ENABLE_WRITE:
> +		/* NVMEM protect mode 0 = Unlock/Make-writable
> +		 * Attempt to clear write protection.
> +		 * The underlying bus->reg_seal must support clearing.
> +		 * For BSEC OTPs, this will (and should) fail with -EOPNOTSUPP
> +		 * or -EPERM.
> +		 */
> +		seal_flags = REGMAP_SEAL_CLEAR | REGMAP_SEAL_WRITE_PROTECT;
> +		break;
> +	case NVMEM_PROTECT_DISABLE_WRITE:
> +		/* NVMEM protect mode 1 = Lock/Write-protect */
> +		/* For OTPs like BSEC, permanent is implied */
> +		seal_flags = REGMAP_SEAL_WRITE_PROTECT | REGMAP_SEAL_PERMANENT;
> +		break;
> +	default:
> +		dev_warn(regmap_get_device(map), "Unsupported NVMEM protect mode: %d\n",
> +			 prot);
> +		return -EOPNOTSUPP;
> +	}
> +
> +	for (i = 0; i < bytes; i += reg_val_bytes) {
> +		unsigned int current_reg_offset = offset + i;
> +
> +		ret = regmap_seal(map, current_reg_offset, seal_flags);
> +		if (ret) {
> +			dev_err(regmap_get_device(map), "regmap_seal failed for offset 0x%x: %pe\n",
> +				current_reg_offset, ERR_PTR(ret));
> +			/* No error handling for partial failures, we messed up
> +			 * the HW state and can't recover.
> +			 */
> +			return ret;
> +		}
> +	}

The i.MX OCOTP offers write protection for fuses as well. AFAIR
there are single fuses for protecting a whole range of fuses, so to
support this we would have to pass the full range down to the driver
instead of separating the range into registers here.

I never looked at the i.MX OCOTP locking capabilities very closely, so
it could be that even passing a range is not good enough to make this
implementable for the OCOTP. We might want to have a look into this
before deciding if we want to implement protect for the drivers based on
single registers.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |