From: "Christian A. Ehrhardt" <christian.ehrhardt@codasip.com>

ab8500_filter_controls[i].private_value is initialized using

	.private_value = (unsigned long)&(struct filter_control)
		{.count = xcount, .min = xmin, .max = xmax}

thus it's a pointer to a struct filter_control casted to unsigned long.

So to get back that pointer .private_data must be cast back, not its
address.

Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver")
Signed-off-by: Christian A. Ehrhardt <christian.ehrhardt@codasip.com>
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
Hello,

note this is untested on actual hardware and was found by Christian using
clang-tidy and code inspection. I'm a bit irritated how/if that driver was used
since it was introduced into v3.6-rc1 in 2012. Maybe this is a hint that the
driver is unused?

Best regards
Uwe

 sound/soc/codecs/ab8500-codec.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/soc/codecs/ab8500-codec.c b/sound/soc/codecs/ab8500-codec.c
index fdda1b747bf7..8ab2e60f80b4 100644
--- a/sound/soc/codecs/ab8500-codec.c
+++ b/sound/soc/codecs/ab8500-codec.c
@@ -2496,13 +2496,13 @@ static int ab8500_codec_probe(struct snd_soc_component *component)
 		return status;
 	}
 	fc = (struct filter_control *)
-		&ab8500_filter_controls[AB8500_FILTER_ANC_FIR].private_value;
+		ab8500_filter_controls[AB8500_FILTER_ANC_FIR].private_value;
 	drvdata->anc_fir_values = (long *)fc->value;
 	fc = (struct filter_control *)
-		&ab8500_filter_controls[AB8500_FILTER_ANC_IIR].private_value;
+		ab8500_filter_controls[AB8500_FILTER_ANC_IIR].private_value;
 	drvdata->anc_iir_values = (long *)fc->value;
 	fc = (struct filter_control *)
-		&ab8500_filter_controls[AB8500_FILTER_SID_FIR].private_value;
+		ab8500_filter_controls[AB8500_FILTER_SID_FIR].private_value;
 	drvdata->sid_fir_values = (long *)fc->value;
 
 	snd_soc_dapm_disable_pin(dapm, "ANC Configure Input");

base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
-- 
2.47.3

On Tue, 28 Apr 2026 21:22:49 +0200, Uwe Kleine-König (The Capable Hub) wrote:
> ASoC: codecs: ab8500: Fix casting of private data

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.1

Thanks!

[1/1] ASoC: codecs: ab8500: Fix casting of private data
      https://git.kernel.org/broonie/sound/c/a201aef1a88b

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

Hello Mark,

On Wed, Apr 29, 2026 at 09:47:43AM +0900, Mark Brown wrote:
> On Tue, 28 Apr 2026 21:22:49 +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > ASoC: codecs: ab8500: Fix casting of private data
> 
> Applied to
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.1
> 
> Thanks!
> 
> [1/1] ASoC: codecs: ab8500: Fix casting of private data
>       https://git.kernel.org/broonie/sound/c/a201aef1a88b

Thanks for applying. Sashiko found[1] that I should have written
"private_value" instead of "private_data" in the commit log. I think it's
still understandable as is, but if you want to fixup that would please
the pedant in me.

Best regards
Uwe

[1] https://sashiko.dev/#/patchset/20260428192255.2294705-2-u.kleine-koenig%40baylibre.com

On Wed, Apr 29, 2026 at 07:21:48AM +0200, Uwe Kleine-König (The Capable Hub) wrote:

> Thanks for applying. Sashiko found[1] that I should have written
> "private_value" instead of "private_data" in the commit log. I think it's
> still understandable as is, but if you want to fixup that would please
> the pedant in me.

Sorry, there's already other stuff on top of it (and I generally try to
avoid changing existing commits).

On Tue, Apr 28, 2026 at 09:22:49PM +0200, Uwe Kleine-König (The Capable Hub) wrote:

> note this is untested on actual hardware and was found by Christian using
> clang-tidy and code inspection. I'm a bit irritated how/if that driver was used
> since it was introduced into v3.6-rc1 in 2012. Maybe this is a hint that the
> driver is unused?

A filter control is relatively obscure, it sseens entirely likely that
people just never used this feature of the driver.  IIRC it was on some
relatively widely available reference board.