[5/8] iio: pressure: bmp280: make reg_write callback take const void *

Message ID 20260715175229.24672-6-linkmauve@linkmauve.fr (mailing list archive)
State New
Headers
Series nvmem: make reg_write() take a const void * |

Commit Message

Link Mauve July 15, 2026, 5:52 p.m. UTC
The previous commit switched from a pointer to mutable data to a pointer
to immutable data, so let’s fix all users of the nvmem_config API.

Signed-off-by: Link Mauve <linkmauve@linkmauve.fr>
---
 drivers/iio/pressure/bmp280-core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
  

Comments

sashiko-bot@kernel.org July 15, 2026, 6:03 p.m. UTC | #1
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Low] Syntax error due to 'void void *_val' parameter in qfprom_reg_write.

Pre-existing issues:
- [Critical] m48t59_nvram_read and m48t59_nvram_write completely ignore the requested offset.
--

--- Patch [5]: [PATCH 5/8] iio: pressure: bmp280: make reg_write callback take const void * ---
commit bd8404c8c6d692d9a700578455111f78fd0eaf2a
Author: Link Mauve <linkmauve@linkmauve.fr>

iio: pressure: bmp280: make reg_write callback 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 the nvmem_config API.

> 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 syntax error in qfprom_reg_write() prevent the qfprom driver from
compiling?

It looks like "void void *_val" was introduced during a find-and-replace
to make the callback take a const void pointer.

>  	struct qfprom_priv *priv = context;
>  	struct qfprom_touched_values old;
>  	int words = bytes / 4;
> -	u32 *value = _val;
> +	const u32 *value = _val;
>  	u32 blow_status;

[ ... ]

> diff --git a/drivers/rtc/rtc-m48t59.c b/drivers/rtc/rtc-m48t59.c
> index 4e608bc8bbd36..ad407faecf1f8 100644
> --- a/drivers/rtc/rtc-m48t59.c
> +++ b/drivers/rtc/rtc-m48t59.c
> @@ -325,7 +325,7 @@ static int m48t59_nvram_write(void *priv, unsigned int offset, void *val,
>  	struct m48t59_private *m48t59 = platform_get_drvdata(pdev);
>  	ssize_t cnt = 0;
>  	unsigned long flags;
> -	u8 *buf = val;
> +	const u8 *buf = val;
>  
>  	spin_lock_irqsave(&m48t59->lock, flags);
>  

[Severity: Critical]
This is a pre-existing issue, but does the loop in m48t59_nvram_write()
completely ignore the requested offset?

It appears that cnt starts at 0 and is used as the hardware address instead
of adding the requested offset:

drivers/rtc/rtc-m48t59.c:m48t59_nvram_write() {
    ...
	for (; cnt < size; cnt++)
		M48T59_WRITE(*buf++, cnt);
    ...
}

Any subsystem or user-space application performing an NVMEM write at an
offset greater than 0 will silently overwrite data at the very beginning
of the NVRAM.

The same issue seems to be present in m48t59_nvram_read(), which could
lead to incorrect data disclosure:

drivers/rtc/rtc-m48t59.c:m48t59_nvram_read() {
    ...
	for (; cnt < size; cnt++)
		*buf++ = M48T59_READ(cnt);
    ...
}
  

Patch

diff --git a/drivers/iio/pressure/bmp280-core.c b/drivers/iio/pressure/bmp280-core.c
index 990340a9b10c..0a39c5f39378 100644
--- a/drivers/iio/pressure/bmp280-core.c
+++ b/drivers/iio/pressure/bmp280-core.c
@@ -2261,11 +2261,11 @@  static int bmp580_nvmem_read(void *priv, unsigned int offset, void *val,
 	return ret;
 }
 
-static int bmp580_nvmem_write_impl(void *priv, unsigned int offset, void *val,
+static int bmp580_nvmem_write_impl(void *priv, unsigned int offset, const void *val,
 				   size_t bytes)
 {
 	struct bmp280_data *data = priv;
-	u16 *buf = val;
+	const u16 *buf = val;
 	int ret, addr;
 
 	guard(mutex)(&data->lock);
@@ -2322,7 +2322,7 @@  static int bmp580_nvmem_write_impl(void *priv, unsigned int offset, void *val,
 	return ret;
 }
 
-static int bmp580_nvmem_write(void *priv, unsigned int offset, void *val,
+static int bmp580_nvmem_write(void *priv, unsigned int offset, const void *val,
 			      size_t bytes)
 {
 	struct bmp280_data *data = priv;