All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH v1 1/7] nvmem: Add 'protect' operation to core framework
Date: Mon, 2 Jun 2025 11:04:47 +0200	[thread overview]
Message-ID: <aD1pL51ZmNTdodUV@pengutronix.de> (raw)
In-Reply-To: <20250530114106.1009454-2-o.rempel@pengutronix.de>

On Fri, May 30, 2025 at 01:41:00PM +0200, Oleksij Rempel wrote:
> Introduce a generic "protect" operation to the NVMEM framework.
> This allows NVMEM providers to expose hardware-specific protection or
> locking mechanisms through the character device interface. Existing
> read/write operations do not cover this type of state-altering
> protection.
> 
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
>  drivers/nvmem/core.c           | 48 ++++++++++++++++++++++++++++++++++
>  drivers/nvmem/partition.c      |  7 +++++
>  include/linux/nvmem-provider.h |  5 ++++
>  3 files changed, 60 insertions(+)
> 
> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> index 38dfb2cf2d1f..ac54a56f3c9f 100644
> --- a/drivers/nvmem/core.c
> +++ b/drivers/nvmem/core.c
> @@ -30,6 +30,8 @@ struct nvmem_device {
>  					     const void *val, size_t val_size);
>  	int			(*reg_read)(void *ctx, unsigned int reg,
>  					    void *val, size_t val_size);
> +	int			(*reg_protect)(void *ctx, unsigned int reg,
> +					       size_t bytes, int prot);
>  };
>  
>  struct nvmem_cell {
> @@ -93,9 +95,54 @@ static ssize_t nvmem_cdev_write(struct cdev *cdev, const void *buf, size_t count
>  	return retlen;
>  }
>  
> +static int nvmem_cdev_protect(struct cdev *cdev, size_t count, loff_t offset,
> +			      int prot)
> +{
> +	struct nvmem_device *nvmem;
> +	int nvmem_prot;
> +
> +	if (cdev->master)
> +		nvmem = container_of(cdev->master, struct nvmem_device, cdev);
> +	else
> +		nvmem = container_of(cdev, struct nvmem_device, cdev);

Please rebase on https://lore.kernel.org/20250602-cdev-part-fixes-v1-0-814d9aa195ed@pengutronix.de

This quirk is buggy.

> +
> +	dev_dbg(cdev->dev, "protect ofs: 0x%08llx count: 0x%08zx prot: %d\n",
> +		offset, count, prot);
> +
> +	if (!nvmem->reg_protect) {
> +		dev_warn(cdev->dev, "NVMEM device %s does not support protect operation\n",
> +			 nvmem->name);
> +		return -EOPNOTSUPP;
> +	}
> +
> +	if (!count)
> +		return 0;
> +
> +	if (offset >= nvmem->size || count > nvmem->size - offset) {

Can be simplified to:

	if (offset + count > nvmem->size)


> +		dev_err(cdev->dev, "protect range out of bounds (ofs: 0x%08llx, count 0x%08zx, size 0x%08zx)\n",
> +			offset, count, nvmem->size);
> +		return -EINVAL;
> +	}
> +
> +	switch (prot) {
> +	case 0:
> +		nvmem_prot = NVMEM_PROTECT_ENABLE_WRITE;
> +		break;
> +	case 1:
> +		nvmem_prot = NVMEM_PROTECT_DISABLE_WRITE;
> +		break;
> +	default:
> +		dev_err(cdev->dev, "unsuported protection type %d\n", prot);
> +		return -EINVAL;
> +	}

I would appreciate introducing defines for the prot parameter treewide
(or converting it to boolean), but introducing it for nvmem only doesn't
improve the current state.

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 |



  reply	other threads:[~2025-06-02  9:05 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 [this message]
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
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=aD1pL51ZmNTdodUV@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.