From: sashiko-bot@kernel.org
To: "Link Mauve" <linkmauve@linkmauve.fr>
Cc: linux-sunxi@lists.linux.dev, lee@kernel.org, imx@lists.linux.dev,
Frank.Li@kernel.org, neil.armstrong@linaro.org,
linux-rtc@vger.kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
linux-amlogic@lists.infradead.org, mfd@lists.linux.dev,
ojeda@kernel.org
Subject: Re: [PATCH 1/8] nvmem: core: make reg_write() take a const void *
Date: Wed, 15 Jul 2026 18:00:56 +0000 [thread overview]
Message-ID: <20260715180057.0EE0C1F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <20260715175229.24672-2-linkmauve@linkmauve.fr>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Modifying the `nvmem_reg_write_t` callback signature to use `const void *val` without updating the implementing drivers causes widespread build failures and runtime kCFI panics.
--
--- Patch [1]: [PATCH 1/8] nvmem: core: make reg_write() take a const void * ---
commit 465aa1ef7ad6475c286716a1fffc7cdb9b6f09dc
Author: Link Mauve <linkmauve@linkmauve.fr>
nvmem: core: make reg_write() take a const void *
This commit changes the nvmem_reg_write_t callback signature to expect
a const void * instead of a mutable void *.
> diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h
> index f3b13da78aac9..e62285836cbbe 100644
> --- a/include/linux/nvmem-provider.h
> +++ b/include/linux/nvmem-provider.h
> @@ -19,7 +19,7 @@ struct nvmem_device;
> typedef int (*nvmem_reg_read_t)(void *priv, unsigned int offset,
> void *val, size_t bytes);
> typedef int (*nvmem_reg_write_t)(void *priv, unsigned int offset,
> - void *val, size_t bytes);
> + const void *val, size_t bytes);
[Severity: High]
Does modifying this callback signature without updating the implementing
drivers cause widespread build failures and runtime kCFI panics?
For example, drivers/nvmem/bcm-ocotp.c:bcm_otpc_write() still expects
a mutable void *:
static int bcm_otpc_write(void *context, unsigned int offset, void *val,
size_t bytes)
When this is assigned to reg_write in bcm_otpc_nvmem_config, it causes an
incompatible pointer type mismatch. This leads to build errors with modern
compilers or -Werror, and will trigger kernel panics upon any nvmem write
operation on kernels with Control-Flow Integrity (kCFI) enabled.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260715175229.24672-1-linkmauve@linkmauve.fr?part=1
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Link Mauve" <linkmauve@linkmauve.fr>
Cc: linux-sunxi@lists.linux.dev, lee@kernel.org, imx@lists.linux.dev,
Frank.Li@kernel.org, neil.armstrong@linaro.org,
linux-rtc@vger.kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
linux-amlogic@lists.infradead.org, mfd@lists.linux.dev,
ojeda@kernel.org
Subject: Re: [PATCH 1/8] nvmem: core: make reg_write() take a const void *
Date: Wed, 15 Jul 2026 18:00:56 +0000 [thread overview]
Message-ID: <20260715180057.0EE0C1F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <20260715175229.24672-2-linkmauve@linkmauve.fr>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Modifying the `nvmem_reg_write_t` callback signature to use `const void *val` without updating the implementing drivers causes widespread build failures and runtime kCFI panics.
--
--- Patch [1]: [PATCH 1/8] nvmem: core: make reg_write() take a const void * ---
commit 465aa1ef7ad6475c286716a1fffc7cdb9b6f09dc
Author: Link Mauve <linkmauve@linkmauve.fr>
nvmem: core: make reg_write() take a const void *
This commit changes the nvmem_reg_write_t callback signature to expect
a const void * instead of a mutable void *.
> diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h
> index f3b13da78aac9..e62285836cbbe 100644
> --- a/include/linux/nvmem-provider.h
> +++ b/include/linux/nvmem-provider.h
> @@ -19,7 +19,7 @@ struct nvmem_device;
> typedef int (*nvmem_reg_read_t)(void *priv, unsigned int offset,
> void *val, size_t bytes);
> typedef int (*nvmem_reg_write_t)(void *priv, unsigned int offset,
> - void *val, size_t bytes);
> + const void *val, size_t bytes);
[Severity: High]
Does modifying this callback signature without updating the implementing
drivers cause widespread build failures and runtime kCFI panics?
For example, drivers/nvmem/bcm-ocotp.c:bcm_otpc_write() still expects
a mutable void *:
static int bcm_otpc_write(void *context, unsigned int offset, void *val,
size_t bytes)
When this is assigned to reg_write in bcm_otpc_nvmem_config, it causes an
incompatible pointer type mismatch. This leads to build errors with modern
compilers or -Werror, and will trigger kernel panics upon any nvmem write
operation on kernels with Control-Flow Integrity (kCFI) enabled.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260715175229.24672-1-linkmauve@linkmauve.fr?part=1
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2026-07-15 18:01 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 17:52 [PATCH 0/8] nvmem: make reg_write() take a const void * Link Mauve
2026-07-15 17:52 ` Link Mauve
2026-07-15 17:52 ` [PATCH 1/8] nvmem: core: " Link Mauve
2026-07-15 17:52 ` Link Mauve
2026-07-15 18:00 ` sashiko-bot [this message]
2026-07-15 18:00 ` sashiko-bot
2026-07-15 18:58 ` Andy Shevchenko
2026-07-15 18:58 ` Andy Shevchenko
2026-07-15 19:03 ` Link Mauve
2026-07-15 19:03 ` Link Mauve
2026-07-15 17:52 ` [PATCH 2/8] nvmem: make all reg_write callbacks take " Link Mauve
2026-07-15 17:52 ` Link Mauve
2026-07-15 18:08 ` sashiko-bot
2026-07-15 18:08 ` sashiko-bot
2026-07-15 17:52 ` [PATCH 3/8] rtc: " Link Mauve
2026-07-15 17:52 ` Link Mauve
2026-07-15 18:01 ` sashiko-bot
2026-07-15 18:01 ` sashiko-bot
2026-07-15 17:52 ` [PATCH 4/8] misc: " Link Mauve
2026-07-15 17:52 ` Link Mauve
2026-07-15 18:04 ` sashiko-bot
2026-07-15 18:04 ` sashiko-bot
2026-07-15 17:52 ` [PATCH 5/8] iio: pressure: bmp280: make reg_write callback " Link Mauve
2026-07-15 17:52 ` Link Mauve
2026-07-15 18:03 ` sashiko-bot
2026-07-15 18:03 ` sashiko-bot
2026-07-15 17:52 ` [PATCH 6/8] firmware: meson_sm: " Link Mauve
2026-07-15 17:52 ` Link Mauve
2026-07-15 18:06 ` sashiko-bot
2026-07-15 18:06 ` sashiko-bot
2026-07-15 17:52 ` [PATCH 7/8] mfd: twl-core: " Link Mauve
2026-07-15 17:52 ` Link Mauve
2026-07-15 18:08 ` sashiko-bot
2026-07-15 18:08 ` sashiko-bot
2026-07-15 17:52 ` [PATCH 8/8] media: ov2740: remove NULL reg_write callback Link Mauve
2026-07-15 17:52 ` Link Mauve
2026-07-15 18:07 ` sashiko-bot
2026-07-15 18:07 ` sashiko-bot
2026-07-15 19:02 ` [PATCH 0/8] nvmem: make reg_write() take a const void * Andy Shevchenko
2026-07-15 19:02 ` Andy Shevchenko
2026-07-15 19:09 ` Link Mauve
2026-07-15 19:09 ` Link Mauve
2026-07-15 20:09 ` Yury Norov
2026-07-15 20:09 ` Yury Norov
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=20260715180057.0EE0C1F00A3E@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=imx@lists.linux.dev \
--cc=lee@kernel.org \
--cc=linkmauve@linkmauve.fr \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-rtc@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=mfd@lists.linux.dev \
--cc=neil.armstrong@linaro.org \
--cc=ojeda@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.