From: sashiko-bot@kernel.org
To: "Link Mauve" <linkmauve@linkmauve.fr>
Cc: Frank.Li@kernel.org, ojeda@kernel.org, imx@lists.linux.dev,
linux-rtc@vger.kernel.org, linux-sunxi@lists.linux.dev,
lee@kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
linux-amlogic@lists.infradead.org, mfd@lists.linux.dev,
neil.armstrong@linaro.org
Subject: Re: [PATCH 2/8] nvmem: make all reg_write callbacks take const void *
Date: Wed, 15 Jul 2026 18:08:48 +0000 [thread overview]
Message-ID: <20260715180848.BD6951F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260715175229.24672-3-linkmauve@linkmauve.fr>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] Syntax error in `qfprom_reg_write` signature causing compilation failure
- [Low] Incomplete API migration causing widespread incompatible-pointer-types build errors across other subsystems
--
--- Patch [2]: [PATCH 2/8] nvmem: make all reg_write callbacks take const void * ---
commit 7e2f42ea4c9950738972bc60aeca19f14bd93ce4
Author: Link Mauve <linkmauve@linkmauve.fr>
nvmem: make all reg_write callbacks take const void *
This patch updates the reg_write callbacks in the nvmem subsystem to take a
const void pointer instead of a mutable void pointer for the value buffer.
> nvmem: make all reg_write callbacks take const void *
>
> The previous commit switched from a pointer to mutable data to a pointer
> to immutable data, so let’s fix all users of this API.
[Severity: Low]
Are there users of this API outside of the drivers/nvmem/ directory that were
missed during this migration?
For example, when building drivers like drivers/rtc/rtc-cmos.c or
drivers/misc/eeprom/at24.c, will assigning their unupdated callbacks to
nvmem_config.reg_write trigger incompatible-pointer-types build errors?
> diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c
> index a872c640b8c5a..bacdcb5610bae 100644
> --- a/drivers/nvmem/qfprom.c
> +++ b/drivers/nvmem/qfprom.c
[ ... ]
> @@ -253,13 +253,13 @@ static int qfprom_enable_fuse_blowing(const struct qfprom_priv *priv,
> *
> * Return: 0 or -err.
> */
> -static int qfprom_reg_write(void *context, unsigned int reg, void *_val,
> +static int qfprom_reg_write(void *context, unsigned int reg, void void *_val,
> size_t bytes)
> {
[Severity: Low]
Does this cause a compilation failure?
The double void void declaration appears to be a syntax error that will break
the build when the Qualcomm QFPROM driver is enabled.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260715175229.24672-1-linkmauve@linkmauve.fr?part=2
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Link Mauve" <linkmauve@linkmauve.fr>
Cc: Frank.Li@kernel.org, ojeda@kernel.org, imx@lists.linux.dev,
linux-rtc@vger.kernel.org, linux-sunxi@lists.linux.dev,
lee@kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
linux-amlogic@lists.infradead.org, mfd@lists.linux.dev,
neil.armstrong@linaro.org
Subject: Re: [PATCH 2/8] nvmem: make all reg_write callbacks take const void *
Date: Wed, 15 Jul 2026 18:08:48 +0000 [thread overview]
Message-ID: <20260715180848.BD6951F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260715175229.24672-3-linkmauve@linkmauve.fr>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] Syntax error in `qfprom_reg_write` signature causing compilation failure
- [Low] Incomplete API migration causing widespread incompatible-pointer-types build errors across other subsystems
--
--- Patch [2]: [PATCH 2/8] nvmem: make all reg_write callbacks take const void * ---
commit 7e2f42ea4c9950738972bc60aeca19f14bd93ce4
Author: Link Mauve <linkmauve@linkmauve.fr>
nvmem: make all reg_write callbacks take const void *
This patch updates the reg_write callbacks in the nvmem subsystem to take a
const void pointer instead of a mutable void pointer for the value buffer.
> nvmem: make all reg_write callbacks take const void *
>
> The previous commit switched from a pointer to mutable data to a pointer
> to immutable data, so let’s fix all users of this API.
[Severity: Low]
Are there users of this API outside of the drivers/nvmem/ directory that were
missed during this migration?
For example, when building drivers like drivers/rtc/rtc-cmos.c or
drivers/misc/eeprom/at24.c, will assigning their unupdated callbacks to
nvmem_config.reg_write trigger incompatible-pointer-types build errors?
> diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c
> index a872c640b8c5a..bacdcb5610bae 100644
> --- a/drivers/nvmem/qfprom.c
> +++ b/drivers/nvmem/qfprom.c
[ ... ]
> @@ -253,13 +253,13 @@ static int qfprom_enable_fuse_blowing(const struct qfprom_priv *priv,
> *
> * Return: 0 or -err.
> */
> -static int qfprom_reg_write(void *context, unsigned int reg, void *_val,
> +static int qfprom_reg_write(void *context, unsigned int reg, void void *_val,
> size_t bytes)
> {
[Severity: Low]
Does this cause a compilation failure?
The double void void declaration appears to be a syntax error that will break
the build when the Qualcomm QFPROM driver is enabled.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260715175229.24672-1-linkmauve@linkmauve.fr?part=2
_______________________________________________
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:08 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
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 [this message]
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=20260715180848.BD6951F00A3A@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.