[0/8] nvmem: make reg_write() take a const void *

This callback used to take a mutable void * for no reason, which causes
the compiler to be unaware that the val buffer should never be modified
by the callback.

This was found while drafting the nvmem-provider Rust abstraction.

I’ve split this series based on the subsystem each patch affects, but I
think it should go through the nvmem tree in one go after gathering the
acks from the other subsystem maintainers.

I’ve been told previously to not include too many maintainers in Cc, but
I don’t know which ones to remove from the get_maintainers.pl output, so
I’ve still included everyone, sorry about that.

Thanks,

Link Mauve (8):
  nvmem: core: make reg_write() take a const void *
  nvmem: make all reg_write callbacks take const void *
  rtc: make all reg_write callbacks take const void *
  misc: make all reg_write callbacks take const void *
  iio: pressure: bmp280: make reg_write callback take const void *
  firmware: meson_sm: make reg_write callback take const void *
  mfd: twl-core: make reg_write callback take const void *
  media: ov2740: remove NULL reg_write callback

 drivers/firmware/meson/meson_sm.c                 | 2 +-
 drivers/iio/pressure/bmp280-core.c                | 6 +++---
 drivers/media/i2c/ov2740.c                        | 1 -
 drivers/mfd/twl-core.c                            | 2 +-
 drivers/misc/ds1682.c                             | 2 +-
 drivers/misc/eeprom/at24.c                        | 4 ++--
 drivers/misc/eeprom/at25.c                        | 2 +-
 drivers/misc/eeprom/eeprom_93xx46.c               | 4 ++--
 drivers/misc/eeprom/m24lr.c                       | 2 +-
 drivers/misc/keba/cp500.c                         | 2 +-
 drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_otpe2p.c | 8 ++++----
 drivers/nvmem/bcm-ocotp.c                         | 4 ++--
 drivers/nvmem/core.c                              | 2 +-
 drivers/nvmem/imx-ocotp-scu.c                     | 4 ++--
 drivers/nvmem/imx-ocotp.c                         | 4 ++--
 drivers/nvmem/lan9662-otpc.c                      | 4 ++--
 drivers/nvmem/lpc18xx_eeprom.c                    | 4 ++--
 drivers/nvmem/max77759-nvmem.c                    | 2 +-
 drivers/nvmem/meson-efuse.c                       | 4 ++--
 drivers/nvmem/qcom-spmi-sdam.c                    | 2 +-
 drivers/nvmem/qfprom.c                            | 4 ++--
 drivers/nvmem/rave-sp-eeprom.c                    | 4 ++--
 drivers/nvmem/snvs_lpgpr.c                        | 2 +-
 drivers/nvmem/sprd-efuse.c                        | 4 ++--
 drivers/nvmem/stm32-bsec-optee-ta.c               | 2 +-
 drivers/nvmem/stm32-bsec-optee-ta.h               | 4 ++--
 drivers/nvmem/stm32-romem.c                       | 6 +++---
 drivers/nvmem/zynqmp_nvmem.c                      | 4 ++--
 drivers/rtc/rtc-abx80x.c                          | 4 ++--
 drivers/rtc/rtc-cmos.c                            | 2 +-
 drivers/rtc/rtc-ds1305.c                          | 4 ++--
 drivers/rtc/rtc-ds1307.c                          | 2 +-
 drivers/rtc/rtc-ds1343.c                          | 2 +-
 drivers/rtc/rtc-ds1511.c                          | 2 +-
 drivers/rtc/rtc-ds1553.c                          | 4 ++--
 drivers/rtc/rtc-ds1685.c                          | 4 ++--
 drivers/rtc/rtc-ds1742.c                          | 4 ++--
 drivers/rtc/rtc-ds3232.c                          | 2 +-
 drivers/rtc/rtc-isl12026.c                        | 4 ++--
 drivers/rtc/rtc-isl1208.c                         | 2 +-
 drivers/rtc/rtc-m48t59.c                          | 4 ++--
 drivers/rtc/rtc-m48t86.c                          | 2 +-
 drivers/rtc/rtc-max31335.c                        | 2 +-
 drivers/rtc/rtc-meson.c                           | 2 +-
 drivers/rtc/rtc-omap.c                            | 4 ++--
 drivers/rtc/rtc-pcf2127.c                         | 2 +-
 drivers/rtc/rtc-pcf85063.c                        | 2 +-
 drivers/rtc/rtc-pcf85363.c                        | 4 ++--
 drivers/rtc/rtc-rp5c01.c                          | 4 ++--
 drivers/rtc/rtc-rv3028.c                          | 6 +++---
 drivers/rtc/rtc-rv3029c2.c                        | 2 +-
 drivers/rtc/rtc-rv3032.c                          | 4 ++--
 drivers/rtc/rtc-rv8803.c                          | 4 ++--
 drivers/rtc/rtc-rx8581.c                          | 4 ++--
 drivers/rtc/rtc-s35390a.c                         | 4 ++--
 drivers/rtc/rtc-stk17ta8.c                        | 4 ++--
 drivers/rtc/rtc-sun6i.c                           | 4 ++--
 drivers/rtc/rtc-ti-k3.c                           | 2 +-
 drivers/rtc/rtc-twl.c                             | 2 +-
 include/linux/firmware/meson/meson_sm.h           | 2 +-
 include/linux/mfd/twl.h                           | 4 ++--
 include/linux/nvmem-provider.h                    | 2 +-
 62 files changed, 100 insertions(+), 101 deletions(-)
  

On Wed, Jul 15, 2026 at 07:52:16PM +0200, Link Mauve wrote:
> This callback used to take a mutable void * for no reason, which causes
> the compiler to be unaware that the val buffer should never be modified
> by the callback.
> 
> This was found while drafting the nvmem-provider Rust abstraction.
> 
> I’ve split this series based on the subsystem each patch affects, but I
> think it should go through the nvmem tree in one go after gathering the
> acks from the other subsystem maintainers.

It's an option. The other option (and often we go this way) is to introduce
a new name, convert users, convert the name back.

See, for example, how GPIO subsystem changed a proto of .set() callback.

> I’ve been told previously to not include too many maintainers in Cc, but
> I don’t know which ones to remove from the get_maintainers.pl output, so
> I’ve still included everyone, sorry about that.

With this, rather standard, way you will fulfill the above requirement
automatically. Also you won't need treewide change to bother everybody
with this. And also increase the chances to go in (maybe in a few releases
span).
  

On Wed, Jul 15, 2026 at 10:02:13PM +0300, Andy Shevchenko wrote:
> On Wed, Jul 15, 2026 at 07:52:16PM +0200, Link Mauve wrote:
> > This callback used to take a mutable void * for no reason, which causes
> > the compiler to be unaware that the val buffer should never be modified
> > by the callback.
> > 
> > This was found while drafting the nvmem-provider Rust abstraction.
> > 
> > I’ve split this series based on the subsystem each patch affects, but I
> > think it should go through the nvmem tree in one go after gathering the
> > acks from the other subsystem maintainers.
> 
> It's an option. The other option (and often we go this way) is to introduce
> a new name, convert users, convert the name back.

Thanks for the hint, I’ll go for this route for v2 then.

> 
> See, for example, how GPIO subsystem changed a proto of .set() callback.

I will, thanks.

> 
> > I’ve been told previously to not include too many maintainers in Cc, but
> > I don’t know which ones to remove from the get_maintainers.pl output, so
> > I’ve still included everyone, sorry about that.
> 
> With this, rather standard, way you will fulfill the above requirement
> automatically. Also you won't need treewide change to bother everybody
> with this. And also increase the chances to go in (maybe in a few releases
> span).

I originally thought given how few users of this API there are in the
kernel, it would be simpler to fix them all in one go, but that might be
a better option then.

> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
>
  

On Wed, Jul 15, 2026 at 10:02:13PM +0300, Andy Shevchenko wrote:
> On Wed, Jul 15, 2026 at 07:52:16PM +0200, Link Mauve wrote:
> > This callback used to take a mutable void * for no reason, which causes
> > the compiler to be unaware that the val buffer should never be modified
> > by the callback.
> > 
> > This was found while drafting the nvmem-provider Rust abstraction.
> > 
> > I’ve split this series based on the subsystem each patch affects, but I
> > think it should go through the nvmem tree in one go after gathering the
> > acks from the other subsystem maintainers.
> 
> It's an option. The other option (and often we go this way) is to introduce
> a new name, convert users, convert the name back.
> 
> See, for example, how GPIO subsystem changed a proto of .set() callback.

I agree with Andy. This should be a well-narrowed bisectable series,
so please follow his suggestion with renaming.

> > I’ve been told previously to not include too many maintainers in Cc, but
> > I don’t know which ones to remove from the get_maintainers.pl output, so
> > I’ve still included everyone, sorry about that.
> 
> With this, rather standard, way you will fulfill the above requirement
> automatically. Also you won't need treewide change to bother everybody
> with this. And also increase the chances to go in (maybe in a few releases
> span).

If I feel the recepient list is too long, I have a couple home-brewed scripts
for it:

  $ cat add_maintainers.sh
  #!/bin/bash
  
  line=`scripts/get_maintainer.pl -n -f --separator , --no-rolestats $1`
  
  sed -i "/^Subject:/i To: $line" $1
  sed -i "s/>,/>,\n\t/g" $1

and

  $ cat addm.sh
  #!/bin/bash

  for f in 00*; do
  	echo $f
  	./add_maintainers.sh $f
  done

So, my approach is:

1. Run the ./addm.sh
2. Pick maintainers from each patch, and put them in the cover letter.
3. Trim cover letter To list, if needed.

The disadvantage of this approach is that people may receive a part of
the series, so for example can't apply it cleanly for testing. But now
that everyone has b4, fetching everything is as simple as
        
        b4 mbox <message-id>

Thanks,
Yury