From: Sascha Hauer <s.hauer@pengutronix.de>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH v1 2/7] nvmem: rmem: add write and protect support
Date: Mon, 2 Jun 2025 11:33:53 +0200 [thread overview]
Message-ID: <aD1wAcoFucaHQ-OY@pengutronix.de> (raw)
In-Reply-To: <20250530114106.1009454-3-o.rempel@pengutronix.de>
On Fri, May 30, 2025 at 01:41:01PM +0200, Oleksij Rempel wrote:
> Add reg_write and reg_protect operations to the rmem NVMEM driver.
> This makes rmem devices writable (they were previously read-only via the
> NVMEM interface due to lacking reg_write) and allows specific regions
> to be marked read-only.
>
> The primary motivation is to improve testing of NVMEM consumer code that
> handles write protection, by enabling rmem to emulate such hardware,
> particularly in sandbox environments.
This is some quite complex code with lots of possibilities to introduce
bugs. nvmem devices are rather small and your motivation is debugging,
so I suggest to invest 1/8 of the nvmem device in memory and use a
bitmap instead of lists of ranges.
> +/**
> + * rmem_ranges_overlap - Check if two memory ranges overlap.
> + * @offset1: Starting offset of the first range.
> + * @len1: Length of the first range.
> + * @offset2: Starting offset of the second range.
> + * @len2: Length of the second range.
> + *
> + * Compares two memory ranges, defined by their starting offsets and
> + * lengths, to determine if they have any common region. Ranges with
> + * zero length are considered non-overlapping.
> + *
> + * The ranges are treated as inclusive, i.e., a range starting at @offset
> + * with length @len covers all bytes from @offset to @offset + @len - 1.
> + *
> + * Return: True if the ranges overlap, false otherwise.
> + */
> +static bool rmem_ranges_overlap(unsigned int offset1, size_t len1,
> + unsigned int offset2, size_t len2)
> +{
We already have region_overlap_size() for this.
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:36 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 [this message]
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=aD1wAcoFucaHQ-OY@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.