kernel/linux.git/drivers/firmware/cirrus, branch linux-7.1.y

ASoC: amd: Move to GPIO descriptors

2026-03-16T01:11:23+00:00

Linus Walleij says: After a quick look and test-compile I can determine that all of these drivers include for no reason whatsoever, so fixing it is low hanging fruit. Link: https://patch.msgid.link/20260314-asoc-amd-v1-0-31afed06e022@kernel.org

firmware: cs_dsp: Simplify suppressing log messages during KUnit testing

2026-03-10T14:53:05+00:00

Rework the way that kernel log messages are rate-limited or suppressed while running the cs_dsp KUnit tests. Under normal conditions cs_dsp doesn't produce an unreasonable number of log messages, and state changes are relatively infrequent. But the KUnit tests run through a very large number of test cases, especially error cases, and this produces an unusually large amount of log output from cs_dsp. The original fix for this in commit 10db9f6899dd ("firmware: cs_dsp: rate-limit log messages in KUnit builds") was effective but not pretty. It involved different definitions of the log macros for KUnit and not-KUnit builds, and exported variables for the KUnit tests to disable log messages. I would have preferred to turn the log macros into real functions that can contain a KUNIT_STATIC_STUB_REDIRECT(), but the dev_xxx() macros don't have a version that take va_args, so they can't be wrapped by a function. This patch enables the use of a KUNIT_STATIC_STUB_REDIRECT() instead of exported variables, and avoids the need for different definitions of the debug macros in KUnit and not-KUnit builds. - A new function cs_dsp_can_emit_message() returns true if the messages can be emitted to the kernel log. In a normal not-KUnit build this function collapses to simply returning true. In KUnit builds it will rate-limit output, and this uses a single static rate limiter so it limits the overall rate across all cs_dsp log messages. The KUnit test can redirect it to change the suppression behavior. - The cs_dsp debug message macros are changed to only call the dev_xxx() if cs_dsp_can_emit_message() returns true. These are still macros so there is no problem wrapping the dev_xxx(). For a normal not-KUnit build cs_dsp_can_emit_message() always returns true so these macros simplify down to being identical to calling dev_xxx() directly. - The KUnit tests that cause a lot of cs_dsp messages now redirect cs_dsp_can_emit_message() to a local function. This returns false to suppress cs_dsp messages, unless DEBUG is defined for that test. I have checked that for a x86_64 production (non-KUnit) build the disassembled cs_dsp.o is identical to what was generated from the original code. So the complier is correctly simplifying the cs_dsp_can_emit_message() and macros down to only the call to dev_xxx(). Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260310130343.1791951-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown

firmware: cs_dsp: Fix fragmentation regression in firmware download

2026-03-09T00:16:52+00:00

Use vmalloc() instead of kmalloc(..., GFP_DMA) to alloc the temporary buffer for firmware download blobs. This avoids the problem that a heavily fragmented system cannot allocate enough physically-contiguous memory for a large blob. The redundant alloc buffer mechanism was removed in commit 900baa6e7bb0 ("firmware: cs_dsp: Remove redundant download buffer allocator"). While doing that I was overly focused on the possibility of the underlying bus requiring DMA-safe memory. So I used GFP_DMA kmalloc()s. I failed to notice that the code I was removing used vmalloc(). This creates a regression. Way back in 2014 the problem of fragmentation with kmalloc()s was fixed by commit cdcd7f728753 ("ASoC: wm_adsp: Use vmalloc to allocate firmware download buffer"). Although we don't need physically-contiguous memory, we don't know if the bus needs some particular alignment of the buffers. Since the change in 2014, the firmware download has always used whatever alignment vmalloc() returns. To avoid introducing a new problem, the temporary buffer is still used, to keep the same alignment of pointers passed to regmap_raw_write(). Signed-off-by: Richard Fitzgerald Fixes: 900baa6e7bb0 ("firmware: cs_dsp: Remove redundant download buffer allocator") Link: https://patch.msgid.link/20260304141250.1578597-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown

Support wm_adsp hibernation for runtime suspend

2026-03-02T13:35:21+00:00

Merge series from Stefan Binding : When the CS35L41 and CS35L45 drivers suspend, they are put into hibernation, and the regmap goes into cache_only, but the firmware is still running, and wm_adsp is not stopped. If userspace attempts to read a firmware control, it will perform a regmap_raw_read() and this will produce an error in the kernel log. To prevent these spurious errors, add an apis into cs_dsp and wm_adsp to allow wm_adsp to hibernate. In this hibernation mode, reads or writes to the dsp controls would be rejected with -EPERM rather than -EBUSY, and no error will be printed to the kernel log.

firmware: cs_dsp: Add API to hibernate the DSP

2026-03-01T23:48:37+00:00

For some parts, the DSP is kept running when in low power mode (hibernation), leaving the firmware ALSA controls enabled, but the registers are inaccessible. Attempts to access volatile firmware controls whilst in this state would produce errors in the kernel log due to a regmap_raw_read() into DSP registers whilst the regmap is in cache_only. To remove this error log, add a hibernating flag to indicate that the controls are inaccessible, so we no longer try to read or write to the registers whilst the regmap is in cache_only. This would still produce an error when trying to read or write to these controls, but this would be a different error (-EPERM instead of -EBUSY), and would not produce a spurious error log in the kernel. Upon wake from hibernation, the control caches are re-synced to the hardware, if the DSP is running. Signed-off-by: Stefan Binding Link: https://patch.msgid.link/20260224161821.93365-2-sbinding@opensource.cirrus.com Reviewed-by: Richard Fitzgerald Signed-off-by: Mark Brown

firmware: cs_dsp: Mark KUnit test suites KUNIT_SPEED_SLOW

2026-02-25T18:33:17+00:00

Most of the test suites perform a large number of test cases, so mark the suites as KUNIT_SPEED_SLOW for anyone who finds that useful. The callback test suites haven't been marked because they don't perform many test cases, and the tests are quick. Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260225125644.1248826-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

Merge tag 'asoc-v6.20' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

2026-02-09T16:39:11+00:00

ASoC: Updates for v7.0 This release is almost all abut driers, there's very little core work here, although some of that driver work is in more generic areas like SDCA and SOF: - Generic SDCA support for reporting jack events. - Continuing platform support, cleanup and feature improements for the AMD, Intel, Qualcomm and SOF code. - Platform description improvements for the Cirrus drivers. - Support for NXP i.MX952, Realtek RT1320 and RT5575, and Sophogo CV1800B. We also pulled in one small SPI API update and some more substantial regmap work (cache description improvements) for use in drivers.

firmware: cs_dsp: rate-limit log messages in KUnit builds

2026-02-02T12:09:28+00:00

Use the dev_*_ratelimit() macros if the cs_dsp KUnit tests are enabled in the build, and allow the KUnit tests to disable message output. Some of the KUnit tests cause a very large number of log messages from cs_dsp, because the tests perform many different test cases. This could cause some lines to be dropped from the kernel log. Dropped lines can prevent the KUnit wrappers from parsing the ktap output in the dmesg log. The KUnit builds of cs_dsp export three bools that the KUnit tests can use to entirely disable log output of err, warn and info messages. Some tests have been updated to use this, replacing the previous fudge of a usleep() in the exit handler of each test. We don't necessarily want to disable all log messages if they aren't expected to be excessive, so the rate-limiting allows leaving some logging enabled. The rate-limited macros are not used in normal builds because it is not appropriate to rate-limit every message. That could cause important messages to be dropped, and there wouldn't be such a high rate of messages in normal operation. Signed-off-by: Richard Fitzgerald Reported-by: Mark Brown Closes: https://lore.kernel.org/linux-sound/af393f08-facb-4c44-a054-1f61254803ec@opensource.cirrus.com/T/#t Fixes: cd8c058499b6 ("firmware: cs_dsp: Add KUnit testing of bin error cases") Link: https://patch.msgid.link/20260130171256.863152-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown