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.

Thanks to the guidance of Andy Shevchenko, this now introduces a new
callback and deprecates the existing one, with the goal of renaming the
new one into the old one once no user remains in the kernel.

Changes since v4:
- Link to v4:
  https://lore.kernel.org/rust-for-linux/20260726131724.15299-1-linkmauve@linkmauve.fr/T/
- Rebase on top of linux-next 20260803, the previous series didn’t apply
  any more due to changes in core.c.
- Also convert the at24, at25, eeprom_93xx46 and m24lr drivers to the
  new reg_write_const callback, these were missed because they got moved
  to the nvmem directory in linux-next between v3 and v4.

Changes since v3:
- Link to v3:
  https://lore.kernel.org/rust-for-linux/20260716142415.28718-1-linkmauve@linkmauve.fr/T/
- Drop Apple SPMI patch, which had already been independently included
  in linux-next as 7089170e1df160f5f8fb395bc5aa2e2697b4e896.
- Reword the cover letter’s subject.
- Reorder the meson firmware patch before the other ones, so that every
  commit is always working correctly.

Changes since v2:
- Link to v2:
  https://lore.kernel.org/rust-for-linux/aljAqBNVXV1aVJqx@luna/T/
- Rebase on top of linux-next/master.
- Fix logic error which made all devices read-only.
- Remove a blanket cast of function pointers to void * in
  apple-spmi-nvmem (patch 3).
- Also fix constness of write buffer in firmware: meson, which is used
  exclusively by meson-efuse (patch 4).
- Re-review all changes to make sure the passed types are more correct
  than they were before.
- Actually test with COMPILE_TEST, which I forgot to enable before…

Changes since v1:
- Link to v1:
  https://lore.kernel.org/rust-for-linux/20260715175229.24672-1-linkmauve@linkmauve.fr/
- Removed all changes to other subsystems than nvmem.
- Added a new reg_write_const callback instead of changing the exisitng
  reg_write.
- Deprecated the existing reg_write callback, it will get removed once
  all users in the kernel will be done migrating to the new one.

Link Mauve (3):
  firmware: meson: pass a const buffer to meson_sm_call_write()
  nvmem: core: deprecate reg_write callback with reg_write_const
  nvmem: make all reg_write callbacks take const void *

 drivers/firmware/meson/meson_sm.c       |  2 +-
 drivers/nvmem/apple-spmi-nvmem.c        |  4 ++--
 drivers/nvmem/at24.c                    |  6 +++---
 drivers/nvmem/at25.c                    |  4 ++--
 drivers/nvmem/bcm-ocotp.c               |  8 +++----
 drivers/nvmem/core.c                    | 28 ++++++++++++++-----------
 drivers/nvmem/eeprom_93xx46.c           |  6 +++---
 drivers/nvmem/imx-ocotp-scu.c           |  6 +++---
 drivers/nvmem/imx-ocotp.c               |  6 +++---
 drivers/nvmem/internals.h               |  1 +
 drivers/nvmem/lan9662-otpc.c            |  6 +++---
 drivers/nvmem/lpc18xx_eeprom.c          |  6 +++---
 drivers/nvmem/m24lr.c                   |  4 ++--
 drivers/nvmem/max77759-nvmem.c          |  4 ++--
 drivers/nvmem/meson-efuse.c             |  8 +++----
 drivers/nvmem/qcom-spmi-sdam.c          |  6 +++---
 drivers/nvmem/qfprom.c                  |  6 +++---
 drivers/nvmem/rave-sp-eeprom.c          |  6 +++---
 drivers/nvmem/snvs_lpgpr.c              |  4 ++--
 drivers/nvmem/sprd-efuse.c              |  6 +++---
 drivers/nvmem/stm32-bsec-optee-ta.c     |  2 +-
 drivers/nvmem/stm32-bsec-optee-ta.h     |  4 ++--
 drivers/nvmem/stm32-romem.c             | 10 ++++-----
 drivers/nvmem/zynqmp_nvmem.c            |  6 +++---
 include/linux/firmware/meson/meson_sm.h |  2 +-
 include/linux/nvmem-provider.h          |  6 +++++-
 26 files changed, 83 insertions(+), 74 deletions(-)


base-commit: 9a4cdc958dd79fc6c3b20b51a10debec6ca09fec
-- 
2.55.0

On Tue, Aug 04, 2026 at 03:59:34PM +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.
> 
> Thanks to the guidance of Andy Shevchenko, this now introduces a new
> callback and deprecates the existing one, with the goal of renaming the
> new one into the old one once no user remains in the kernel.

FWIW, if the approach taken is okay by maintainers,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

I think this is right direction to go. We should use all possible ways to
protect the data from corruption.

-- 
With Best Regards,
Andy Shevchenko

Hi,

On Mon, Aug 17, 2026 at 09:54:43PM +0300, Andy Shevchenko wrote:
> On Tue, Aug 04, 2026 at 03:59:34PM +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.
> > 
> > Thanks to the guidance of Andy Shevchenko, this now introduces a new
> > callback and deprecates the existing one, with the goal of renaming the
> > new one into the old one once no user remains in the kernel.
> 
> FWIW, if the approach taken is okay by maintainers,
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

Thanks for the review!

> 
> I think this is right direction to go. We should use all possible ways to
> protect the data from corruption.

Sorry for not pinging again before the end of the 7.3 merge window, I
was on vacations, but this only delayed that work by one cycle.

Is there anything I could do to make it happen for 7.4, or should I just
wait until a maintainer picks up that series?  I just tested and
everything still builds file on top of linux-next as of next-20260911.

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

-- 
Link Mauve