Re: [PATCH v2 0/2] nvmem: fix a const-unsoundness in reg_write

From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Link Mauve <linkmauve@linkmauve.fr>
Cc: "Srinivas Kandagatla" <srini@kernel.org>,
	"Andy Shevchenko" <andy@kernel.org>,
	"Sven Peter" <sven@kernel.org>, "Janne Grunau" <j@jannau.net>,
	"Neal Gompa" <neal@gompa.dev>, "Frank Li" <Frank.Li@nxp.com>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Pengutronix Kernel Team" <kernel@pengutronix.de>,
	"Fabio Estevam" <festevam@gmail.com>,
	"Vladimir Zapolskiy" <vz@mleia.com>,
	"André Draszik" <andre.draszik@linaro.org>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Jerome Brunet" <jbrunet@baylibre.com>,
	"Martin Blumenstingl" <martin.blumenstingl@googlemail.com>,
	"Orson Zhai" <orsonzhai@gmail.com>,
	"Baolin Wang" <baolin.wang@linux.alibaba.com>,
	"Chunyan Zhang" <zhang.lyra@gmail.com>,
	"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
	"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
	"Kalyani Akula" <kalyani.akula@amd.com>,
	"Michal Simek" <michal.simek@amd.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Tamir Duberstein" <tamird@kernel.org>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	"Onur Özkan" <work@onurozkan.dev>,
	asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, imx@lists.linux.dev,
	linux-amlogic@lists.infradead.org, linux-arm-msm@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v2 0/2] nvmem: fix a const-unsoundness in reg_write
Date: Thu, 16 Jul 2026 12:03:17 +0300	[thread overview]
Message-ID: <alieVR1cOtOySi4_@ashevche-desk.local> (raw)
In-Reply-To: <20260715195520.25410-1-linkmauve@linkmauve.fr>

On Wed, Jul 15, 2026 at 09:55: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.
> 
> 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.

You forgot to use --base. It's unclear against what should be this applied.
I tried Linux Next (next-20260715), and it fails.

Yes, it applies against v7.2-rc3, but it means that this won't be applied on
top of maintainer's tree (which has something already that you have to take
into consideration).

For the record, the first version of the series was no go as the first patch
there breaks the things, like

drivers/nvmem/qfprom.c:446:22: error: incompatible function pointer types assigning to 'nvmem_reg_write_t' (aka 'int (*)(void *, unsigned int, const void *, unsigned long)') from 'int (void *, unsigned int, void *, size_t)' (aka 'int (void *, unsigned int, void *, unsigned long)') [-Wincompatible-function-pointer-types]
  446 |                         econfig.reg_write = qfprom_reg_write;
      |                                           ^ ~~~~~~~~~~~~~~~~
1 error generated.

This version doesn't have this issue (at least with my smoke build tests
on x86_64).

Now, what catches me is that regmap_bulk_read() proto used for both cases in
drivers/nvmem/apple-spmi-nvmem.c without any changes. Which makes me think
that the approach can be done in a simpler way, id est converting users first
to use const specifiers in their callbacks first. But this trick is done with
using (void *) casting (?) which makes warning to disappear, which is
interesting case. So I think the Apple driver should actually use proper
protos and hence wrappers, otherwise it makes compiler blind, which is not
good. TL;DR: you should fix the Apple driver (and might more if any of them
use that dirty trick).

-- 
With Best Regards,
Andy Shevchenko

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic