From: Sascha Hauer <s.hauer@pengutronix.de>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH v1 4/7] regmap: Add reg_seal operation for hardware protection
Date: Mon, 2 Jun 2025 11:47:10 +0200 [thread overview]
Message-ID: <aD1zHoTyc3epHgcI@pengutronix.de> (raw)
In-Reply-To: <20250530114106.1009454-5-o.rempel@pengutronix.de>
On Fri, May 30, 2025 at 01:41:03PM +0200, Oleksij Rempel wrote:
> Add a new 'reg_seal' operation to the regmap bus interface, along
> with a public API `regmap_seal()`. This is needed for drivers that
> must perform hardware-level "sealing" or permanent write-protection
> on registers/words, a capability not covered by standard regmap
> read/write ops.
>
> The initial use case is for the STM32 BSEC driver (coming in a
> follow-up patch) to lock One-Time Programmable (OTP) memory words.
> This gives explicit control to make OTP entries permanently read-only
> after programming.
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> drivers/base/regmap/internal.h | 2 ++
> drivers/base/regmap/regmap.c | 31 +++++++++++++++++++++++++++++++
> include/linux/regmap.h | 33 +++++++++++++++++++++++++++++++++
> 3 files changed, 66 insertions(+)
>
> diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
> index 6f6a34edc7a8..f2b95cc6361e 100644
> --- a/drivers/base/regmap/internal.h
> +++ b/drivers/base/regmap/internal.h
> @@ -39,6 +39,8 @@ struct regmap {
> unsigned int *val);
> int (*reg_write)(void *context, unsigned int reg,
> unsigned int val);
> + int (*reg_seal)(void *context, unsigned int reg,
> + unsigned int flags);
> };
>
> struct regmap_field {
> diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
> index 777636c0b319..dc65b9e965ce 100644
> --- a/drivers/base/regmap/regmap.c
> +++ b/drivers/base/regmap/regmap.c
> @@ -81,6 +81,17 @@ static int _regmap_bus_reg_write(void *context, unsigned int reg,
> return map->bus->reg_write(map->bus_context, reg, val);
> }
>
> +static int _regmap_bus_reg_seal(void *context, unsigned int reg,
> + unsigned int flags)
> +{
> + struct regmap *map = context;
> +
> + if (!map->bus->reg_seal)
> + return -EOPNOTSUPP;
> +
> + return map->bus->reg_seal(map->bus_context, reg, flags);
> +}
> +
> /*
> * regmap_init - initialize and register a regmap
> *
> @@ -124,6 +135,9 @@ struct regmap *regmap_init(struct device *dev,
> }
> }
>
> + if (!map->reg_seal)
> + map->reg_seal = _regmap_bus_reg_seal;
map was just xzalloced, so this check seems unnecessary.
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 |
next prev parent reply other threads:[~2025-06-02 9:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-30 11:40 [PATCH v1 0/7] NVMEM: Introduce write protection support Oleksij Rempel
2025-05-30 11:41 ` [PATCH v1 1/7] nvmem: Add 'protect' operation to core framework Oleksij Rempel
2025-06-02 9:04 ` Sascha Hauer
2025-05-30 11:41 ` [PATCH v1 2/7] nvmem: rmem: add write and protect support Oleksij Rempel
2025-06-02 9:33 ` Sascha Hauer
2025-05-30 11:41 ` [PATCH v1 3/7] commands: nvmem: Add support for creating dynamic rmem devices Oleksij Rempel
2025-06-02 9:41 ` Sascha Hauer
2025-05-30 11:41 ` [PATCH v1 4/7] regmap: Add reg_seal operation for hardware protection Oleksij Rempel
2025-06-02 9:47 ` Sascha Hauer [this message]
2025-05-30 11:41 ` [PATCH v1 5/7] nvmem: regmap: Implement protect operation using regmap_seal Oleksij Rempel
2025-06-02 9:57 ` Sascha Hauer
2025-06-05 4:40 ` Oleksij Rempel
2025-05-30 11:41 ` [PATCH v1 6/7] nvmem: bsec: Implement NVMEM protect via regmap_seal for OTP locking Oleksij Rempel
2025-05-30 11:41 ` [PATCH v1 7/7] nvmem: rmem: Use unique device name for NVMEM registration Oleksij Rempel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aD1zHoTyc3epHgcI@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=o.rempel@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.