linux-kernel - Re: [PATCH] firmware: cs_dsp: Store control length as 32-bit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <176408508374.37186.15698361451262080935.b4-ty@kernel.org>
Date: Tue, 25 Nov 2025 15:38:03 +0000
From: Mark Brown <broonie@...nel.org>
To: Richard Fitzgerald <rf@...nsource.cirrus.com>
Cc: linux-sound@...r.kernel.org, linux-kernel@...r.kernel.org, 
 patches@...nsource.cirrus.com
Subject: Re: [PATCH] firmware: cs_dsp: Store control length as 32-bit

On Mon, 24 Nov 2025 17:15:35 +0000, Richard Fitzgerald wrote:
> The architectures supported by this driver have a maximum of 32-bits
> of address, so we don't need more than 32-bits to store the length of
> control data. Change the length in struct cs_dsp_coeff_ctl to an
> unsigned int instead of a size_t. Also make a corresponding trivial
> change to wm_adsp.c to prevent a compiler warning.
> 
> Tested on x86_64 builds this saves at least 4 bytes per control
> (another 4 bytes might be saved if the compiler was inserting padding
> to align the size_t).
> 
> [...]

Applied to

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

Thanks!

[1/1] firmware: cs_dsp: Store control length as 32-bit
      commit: 7584edf15892e29190b2145294cc1680aa142586

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