August 2026 - Sound-open-firmware - mailman.alsa-project.org

[PATCH 00/42] of: reserved_mem: Introduce devres helpers and convert drivers
by Mukesh Ojha 30 Sep '26

30 Sep '26

Drivers using of_reserved_mem_device_init() and its variants must manually call of_reserved_mem_device_release() in their remove and error-unwind paths. This is repetitive boilerplate that is easy to get wrong, and several drivers have open-coded the teardown inconsistently or skipped it entirely, leading to dangling reserved memory references. This series introduces devres-managed wrappers — devm_of_reserved_mem_device_init(), devm_of_reserved_mem_device_init_by_idx(), and devm_of_reserved_mem_device_init_by_name() — that tie the reserved memory region lifetime to the device, releasing it automatically on unbind. The remaining 40 patches convert drivers across the drm, media, ASoC, remoteproc, firmware, mmc, memory and misc subsystems to use these helpers, yielding a net reduction of ~90 lines of boilerplate. This series depends on https://lore.kernel.org/lkml/20260703164457.4040457-1-mukesh.ojha@oss.qualc… Konrad Dybcio (1): of: reserved_mem: Introduce devres-managed initialization functions Mukesh Ojha (41): of: reserved_mem: Add devm_of_reserved_mem_device_init_by_name() firmware: qcom: scm: Use devm_of_reserved_mem_device_init() remoteproc: da8xx: Use devm_of_reserved_mem_device_init() remoteproc: keystone: Use devm_of_reserved_mem_device_init() media: synopsys: hdmirx: Use devm_of_reserved_mem_device_init() remoteproc: omap: Use devm_of_reserved_mem_device_init() drm: logicvc: Use devm_of_reserved_mem_device_init() drm: hdlcd: Use devm_of_reserved_mem_device_init() drm: pl111: Use devm_of_reserved_mem_device_init() remoteproc: mtk_scp: Use devm_of_reserved_mem_device_init() media: aspeed: Use devm_of_reserved_mem_device_init() media: nuvoton: npcm-video: Use devm_of_reserved_mem_device_init() memory: tegra210-emc: Use devm_of_reserved_mem_device_init_by_name() drm: komeda: Use devm_of_reserved_mem_device_init() drm: malidp: Use devm_of_reserved_mem_device_init() drm: ingenic: Use devm_of_reserved_mem_device_init() drm: kmb: Use devm_of_reserved_mem_device_init() drm: sun4i: Use devm_of_reserved_mem_device_init() drm: xlnx: zynqmp_dpsub: Use devm_of_reserved_mem_device_init() media: arm: mali-c55: Use devm_of_reserved_mem_device_init() media: mediatek: vpu: Use devm_of_reserved_mem_device_init() mmc: sdhci-of-bst: Use devm_of_reserved_mem_device_init_by_idx() remoteproc: ti_k3: Use devm_of_reserved_mem_device_init() ASoC: mediatek: mt8192: Use devm_of_reserved_mem_device_init() ASoC: mediatek: mt8196: Use devm_of_reserved_mem_device_init() ASoC: mediatek: mt8183: Use devm_of_reserved_mem_device_init() ASoC: mediatek: mt8189: Use devm_of_reserved_mem_device_init() ASoC: SOF: imx: Use devm_of_reserved_mem_device_init_by_name() staging: media: cedrus: Use devm_of_reserved_mem_device_init() ASoC: cix-ipbloq: Use devm_of_reserved_mem_device_init() drm: aspeed: Use devm_of_reserved_mem_device_init() drm: arcpgu: Use devm_of_reserved_mem_device_init() ASoC: mediatek: mt8173: Use devm_of_reserved_mem_device_init() ASoC: mediatek: mt8186: Use devm_of_reserved_mem_device_init() ASoC: mediatek: mt8188: Use devm_of_reserved_mem_device_init() ASoC: mediatek: mt8195: Use devm_of_reserved_mem_device_init() ASoC: SOF: mediatek: mt8186: Use devm_of_reserved_mem_device_init() ASoC: SOF: mediatek: mt8195: Use devm_of_reserved_mem_device_init() misc: fastrpc: Use devm_of_reserved_mem_device_init() ASoC: fsl: imx-rpmsg: Use devm_of_reserved_mem_device_init_by_idx() ASoC: sprd: Use devm_of_reserved_mem_device_init() drivers/firmware/qcom/qcom_scm.c | 22 +++------ .../gpu/drm/arm/display/komeda/komeda_dev.c | 4 +- drivers/gpu/drm/arm/hdlcd_drv.c | 6 +-- drivers/gpu/drm/arm/malidp_drv.c | 4 +- drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 2 +- drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 13 +----- drivers/gpu/drm/kmb/kmb_drv.c | 12 +---- drivers/gpu/drm/logicvc/logicvc_drm.c | 21 ++++----- drivers/gpu/drm/pl111/pl111_drv.c | 4 +- drivers/gpu/drm/sun4i/sun4i_drv.c | 4 +- drivers/gpu/drm/tiny/arcpgu.c | 2 +- drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 4 +- .../platform/arm/mali-c55/mali-c55-core.c | 12 ++--- drivers/media/platform/aspeed/aspeed-video.c | 12 ++--- drivers/media/platform/mediatek/vpu/mtk_vpu.c | 3 +- drivers/media/platform/nuvoton/npcm-video.c | 9 +--- .../platform/synopsys/hdmirx/snps_hdmirx.c | 16 +------ drivers/memory/tegra/tegra210-emc-core.c | 21 ++++----- drivers/misc/fastrpc.c | 2 +- drivers/mmc/host/sdhci-of-bst.c | 7 +-- drivers/of/of_reserved_mem.c | 41 +++++++++++++++++ drivers/remoteproc/da8xx_remoteproc.c | 10 +--- drivers/remoteproc/keystone_remoteproc.c | 16 +------ drivers/remoteproc/mtk_scp.c | 3 +- drivers/remoteproc/omap_remoteproc.c | 13 +----- drivers/remoteproc/ti_k3_common.c | 13 +----- drivers/remoteproc/ti_k3_common.h | 1 - .../staging/media/sunxi/cedrus/cedrus_hw.c | 6 +-- include/linux/of_reserved_mem.h | 46 +++++++++++++++++++ sound/hda/controllers/cix-ipbloq.c | 2 +- sound/soc/fsl/imx-rpmsg.c | 2 +- sound/soc/mediatek/mt8173/mt8173-afe-pcm.c | 2 +- sound/soc/mediatek/mt8183/mt8183-afe-pcm.c | 13 +----- sound/soc/mediatek/mt8186/mt8186-afe-pcm.c | 2 +- sound/soc/mediatek/mt8188/mt8188-afe-pcm.c | 2 +- sound/soc/mediatek/mt8189/mt8189-afe-pcm.c | 16 +------ sound/soc/mediatek/mt8192/mt8192-afe-pcm.c | 11 +---- sound/soc/mediatek/mt8195/mt8195-afe-pcm.c | 2 +- sound/soc/mediatek/mt8196/mt8196-afe-pcm.c | 14 +----- sound/soc/sof/imx/imx-common.c | 9 ++-- sound/soc/sof/mediatek/mt8186/mt8186.c | 2 +- sound/soc/sof/mediatek/mt8195/mt8195.c | 2 +- sound/soc/sprd/sprd-pcm-dma.c | 3 +- 43 files changed, 162 insertions(+), 249 deletions(-) -- 2.53.0

14 56

[PATCH 0/2] ASoC: fix SoundWire enumeration on Surface Pro 11
by Amaan Lalani 31 Aug '26

31 Aug '26

Some Surface Pro 11 systems expose duplicate SoundWire ACPI _ADR entries for the same physical peripheral, differing only in SDCA class ID. Firmware may also describe SoundWire peripherals which remain unattached. Together, these can result in incorrect amplifier name prefixes and entries being created for peripherals which are not physically present, preventing the sound card from registering correctly. The first patch reuses the amplifier name prefix when an _ADR entry differs from an earlier entry only by SDCA class ID. The second patch skips SoundWire peripherals explicitly reported as SDW_SLAVE_UNATTACHED when counting and parsing endpoints. Tested on a Microsoft Surface Pro 11 with Intel hardware by building and booting the patched kernel and verifying that the sound card registers and speaker playback works. Amaan Lalani (2): ASoC: SOF: Intel: reuse name prefix for duplicate SoundWire devices ASoC: sdw_utils: skip unattached SoundWire peripherals sound/soc/sdw_utils/soc_sdw_utils.c | 35 +++++++++++++++++++++++++++++ sound/soc/sof/intel/hda.c | 14 ++++++++++++ 2 files changed, 49 insertions(+) base-commit: 1b78070aaef63512688aebfbc82365ef9d6660f1 -- 2.55.0

2 5

[PATCH AUTOSEL 6.18] ASoC/soundwire: Intel: reset the PCMSyCM registers in hda_sdw_bpt_close
by Sasha Levin 31 Aug '26

31 Aug '26

From: Bard Liao <yung-chuan.liao(a)linux.intel.com> [ Upstream commit 992eb0dfbc4f594d60ae57974efa835bfac34d1e ] Resetting the PCMSyCM registers is required for Intel SoundWire stream. The same procedure is done in sdw_hda_dai_hw_params() for the normal SoundWire stream, too. Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood(a)intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.dev> Acked-by: Vinod Koul <vkoul(a)kernel.org> Link: https://patch.msgid.link/20260730012518.2180906-1-yung-chuan.liao@linux.int… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: # Stable Backport Analysis: Reset PCMSyCM Registers in `hda_sdw_bpt_close` **Local tree:** `v6.18.44` (6.18.y stable) **Commit under review:** `992eb0dfbc4f5` — *ASoC/soundwire: Intel: reset the PCMSyCM registers in hda_sdw_bpt_close* **Status in this tree:** Not present (on `master` only) --- ## PHASE 1: COMMIT MESSAGE FORENSICS ### Step 1.1: Subject Line **Record:** `[ASoC/soundwire: Intel]` `[reset]` — Reset PCMSyCM registers during BPT stream close to match the open/setup path. ### Step 1.2: Tags **Record:** - **Signed-off-by:** Bard Liao, Mark Brown (ignore pipeline-added SOBs) - **Reviewed-by:** Péter Ujfalusi, Liam Girdwood, Pierre-Louis Bossart - **Acked-by:** Vinod Koul (SoundWire maintainer) - **Link:** https://patch.msgid.link/20260730012518.2180906-1-yung- chuan.liao(a)linux.intel.com - **No** Fixes:, Reported-by:, Tested-by:, Cc: stable(a)vger.kernel.org - Notable: Three Intel audio maintainers reviewed; SoundWire maintainer Acked. ### Step 1.3: Body Analysis **Record:** - **Bug:** `hda_sdw_bpt_close()` deprepared DMA buffers but did not reset PCMSyCM hardware registers programmed during `hda_sdw_bpt_open()`. - **Symptom:** Not explicitly stated (no crash trace or user report), but stale PCMSyCM state can interfere with subsequent SoundWire audio streams on the same link. - **Root cause:** Asymmetric open/close — open programs PCMSyCM via `hdac_bus_eml_sdw_map_stream_ch()`, close omitted the inverse reset. - **Reference pattern:** Commit message cites `sdw_hda_dai_hw_params()`; the actual reset pattern lives in `sdw_hda_dai_hw_free()` (commit message typo, not a code issue). ### Step 1.4: Hidden Bug Fix? **Record:** Yes. Despite the neutral "reset" wording, this is a real hardware cleanup bug — missing register teardown on a production code path, not cosmetic cleanup. --- ## PHASE 2: DIFF ANALYSIS ### Step 2.1: Inventory **Record:** | File | Change | |------|--------| | `sound/soc/sof/intel/hda-sdw-bpt.c` | +24 lines (core fix) | | `drivers/soundwire/intel_ace2x.c` | +3 lines (pass `link_id`) | | `include/sound/hda-sdw-bpt.h` | +2 lines (API signature) | **Functions modified:** `hda_sdw_bpt_close()`, `hda_sdw_bpt_open()` (error path), `intel_ace2x_bpt_open_stream()`, `intel_ace2x_bpt_close_stream()` **Scope:** Single-subsystem, surgical fix across 3 files. ### Step 2.2: Code Flow Change **Record:** - **Hunk 1 (`hda_sdw_bpt_close`):** Before: only DMA deprepare. After: reset PDI0 (playback) and PDI1 (capture) PCMSyCM registers via `hdac_bus_eml_sdw_map_stream_ch(..., 0, 0, stream)`, then deprepare DMA regardless of reset errors. - **Hunk 2 (API):** Adds `int link_id` parameter to `hda_sdw_bpt_close()` to identify the SoundWire sublink. - **Hunk 3 (callers):** `intel_ace2x.c` passes `sdw->instance`; `hda_sdw_bpt_open()` error path passes existing `link_id`. ### Step 2.3: Bug Mechanism **Record:** **Category (g) — logic/correctness / hardware state cleanup.** `hda_sdw_bpt_open()` programs PCMSyCM for PDI0 and PDI1. Without reset on close, hardware retains stale channel/stream mappings. The normal SoundWire path already resets in `sdw_hda_dai_hw_free()`: ```631:638:sound/soc/sof/intel/hda-dai.c /* in the case of SoundWire we need to reset the PCMSyCM registers */ ret = hdac_bus_eml_sdw_map_stream_ch(sof_to_bus(sdev), link_id, cpu_dai->id, 0, 0, substream->stream); ``` The fix applies the same reset pattern to the BPT path. ### Step 2.4: Fix Quality **Record:** Obviously correct — mirrors established `sdw_hda_dai_hw_free()` behavior. Minimal, symmetric with `_open()`. Pierre-Louis Bossart confirmed: *"LGTM, this patch makes the _close() sequence and api mimic the _open() one."* Low regression risk; continues DMA cleanup even if register reset fails. --- ## PHASE 3: GIT HISTORY INVESTIGATION ### Step 3.1: Blame **Record:** `hda_sdw_bpt_close()` introduced in `5d5cb86fb46ea` (2025-02-27, "add helpers for SoundWire BPT DMA") without PCMSyCM reset. Present since **v6.15**, including this tree at v6.18.44. ### Step 3.2: Fixes: Tag **Record:** N/A — no Fixes: tag. ### Step 3.3: Related File History **Record:** Recent related commits in this tree: - `67d0475e78b39` — release bpt_stream when close - `8b184c34806e5` — set persistent_buffer false - `5d5cb86fb46ea` — initial BPT helpers Standalone single-patch series (v1 only). No prerequisite commits required. ### Step 3.4: Author Context **Record:** Bard Liao is a regular Intel SoundWire/SOF contributor. Related commits in this subsystem include BPT CHAIN_DMA support and stream lifecycle fixes. ### Step 3.5: Dependencies **Record:** No dependencies. Uses `hdac_bus_eml_sdw_map_stream_ch()` (present since 2023, `ccc2f0c1b6b61`) and `sdw->instance` (already used in `hda_sdw_bpt_open()` at line 167 of `intel_ace2x.c`). Applies standalone. --- ## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH ### Step 4.1: Original Discussion **Record:** - **URL:** https://patch.msgid.link/20260730012518.2180906-1-yung- chuan.liao(a)linux.intel.com - **Series:** v1 only (no revisions) - **Key feedback:** Vinod Koul Acked; Pierre-Louis Bossart Reviewed with LGTM - **No** stable nomination, NAKs, or explicit failure reports in thread ### Step 4.2: Reviewers **Record:** CC'd: linux-sound, broonie, tiwai, vkoul, pierre- louis.bossart, peter.ujfalusi — appropriate subsystem maintainers and Intel audio team. ### Step 4.3: Bug Reports **Record:** No Reported-by:, syzbot, or bugzilla links. Impact inferred from code analysis and established PCMSyCM reset requirement. ### Step 4.4: Related Patches **Record:** Related stable-nominated PCMSyCM fix: `6e38a7e098d32` ("Handle prepare without close for non-HDA DAI's") included `Cc: stable(a)vger.kernel.org # 6.10.x 6.11.x` for SDW PCMSyCM reset on prepare-after-drain. Same subsystem, same register family. ### Step 4.5: Stable List History **Record:** No stable-list discussion found for this specific patch. Not a negative signal. --- ## PHASE 5: CODE SEMANTIC ANALYSIS ### Step 5.1: Key Functions **Record:** `hda_sdw_bpt_close()`, `intel_ace2x_bpt_close_stream()`, `intel_ace2x_bpt_open_stream()`, `hdac_bus_eml_sdw_map_stream_ch()` ### Step 5.2: Callers **Record:** - `intel_ace2x_bpt_close_stream()` — called from BPT error paths and after `intel_ace2x_bpt_wait()` completes - `hda_sdw_bpt_close()` — called from `intel_ace2x_bpt_open_stream()` error path and `hda_sdw_bpt_open()` error path - BPT entry: `sdw_bpt_send_async()` / `sdw_bpt_wait()` in `bus.c` → Intel `hw_ops` → `intel_ace2x_bpt_*` - Used for SoundWire register access (BRA/BPT), codec driver operations, and debugfs BPT interface ### Step 5.3: Callees **Record:** `hdac_bus_eml_sdw_map_stream_ch()` programs/resets PCMSyCM shim registers; `hda_sdw_bpt_dma_deprepare()` tears down DMA. ### Step 5.4: Reachability **Record:** Triggered during SoundWire BPT transfers on Intel ACE2.x platforms with `CONFIG_SND_SOF_SOF_HDA_SDW_BPT` (auto-selected for Intel LNL+ with SoundWire). Reachable from kernel driver/codec operations and debugfs — not a dead path. ### Step 5.5: Similar Patterns **Record:** `sdw_hda_dai_hw_free()` uses identical reset (`channel_mask=0, stream_id=0`). Open side in `hda_sdw_bpt_open()` already programs PCMSyCM at lines 277–292. Fix completes the symmetry. --- ## PHASE 6: CROSS-REFERENCING AGAINST LOCAL TREE ### Step 6.1: Buggy Code Exists? **Record:** **Yes.** `hda_sdw_bpt_close()` in v6.18.44 only deprepares DMA (lines 425–438 of `hda-sdw-bpt.c`). Bug present since v6.15 (`5d5cb86fb46ea`), well before 6.18 branched. ### Step 6.2: Backport Complications **Record:** `.c` files apply cleanly (`git apply --check` passes). Header file fails automated apply because master added `hda_sdw_bpt_get_buf_size_alignment()` after `hda_sdw_bpt_close()` — that function is **not** in v6.18.44. The signature change itself is trivial and needs only dropping that extra context line. **Minor manual adjustment**, not a rework. ### Step 6.3: Related Fixes Already Present? **Record:** No equivalent PCMSyCM reset in BPT close path. Other BPT fixes present (`67d0475e78b39`, `8b184c34806e5`) address different issues. --- ## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT ### Step 7.1: Subsystem Criticality **Record:** **sound/ASoC/SOF/Intel SoundWire** — IMPORTANT. Affects audio on modern Intel laptops (Meteor Lake, Lunar Lake, Panther Lake) with SoundWire codecs. ### Step 7.2: Subsystem Activity **Record:** Actively developed — BPT support added in 6.15, multiple follow-up fixes through 6.18.y. --- ## PHASE 8: IMPACT AND RISK ASSESSMENT ### Step 8.1: Who Is Affected **Record:** Users of Intel SOF + SoundWire platforms with BPT enabled (`CONFIG_SND_SOF_SOF_HDA_SDW_BPT`). Growing population of modern Intel laptops. ### Step 8.2: Trigger Conditions **Record:** Any BPT transfer on a SoundWire link (register access, codec configuration, debugfs BPT operations) followed by normal audio use on the same link. Not timing-dependent; deterministic stale hardware state. ### Step 8.3: Failure Mode Severity **Record:** Stale PCMSyCM mappings can cause subsequent audio stream setup/playback failures on the affected link. **Severity: MEDIUM-HIGH** for affected hardware — functional audio breakage, not kernel crash/oops/corruption. ### Step 8.4: Risk-Benefit **Record:** - **Benefit:** Prevents audio malfunction after BPT operations; completes missing hardware cleanup - **Risk:** Very low — ~30 lines, mirrors proven pattern, well-reviewed - **Ratio:** Clear benefit outweighs minimal risk --- ## PHASE 9: FINAL SYNTHESIS ### Step 9.1: Evidence Summary **FOR backport:** - Real bug: missing PCMSyCM register reset on BPT close - Bug present in v6.18.44 since BPT introduction (v6.15) - Mirrors `sdw_hda_dai_hw_free()` — same reset already deemed stable- worthy in related commit - Small, surgical, obviously correct - Reviewed by 3 maintainers + Acked by SoundWire maintainer - Can break audio on production Intel SoundWire hardware **AGAINST backport:** - No explicit user crash report or syzbot finding - Commit message doesn't describe concrete failure symptoms - Header needs trivial manual adjustment for 6.18.y apply **Unresolved:** No documented user-facing failure report; impact inferred from code analysis and hardware register semantics. ### Step 9.2: Stable Rules Checklist | Criterion | Result | |-----------|--------| | 1. Obviously correct and tested? | **PASS** — mirrors existing pattern; maintainer-reviewed | | 2. Fixes real bug? | **PASS** — missing hardware register cleanup | | 3. Important issue? | **PASS** — audio failure on affected Intel hardware | | 4. Small and contained? | **PASS** — ~30 lines, 3 files | | 5. No new features/APIs? | **PASS** — extends existing close with required cleanup; signature change is internal | | 6. Can apply to local tree? | **PASS** — clean apply on .c files; trivial header tweak | ### Step 9.3: Exception Categories **Record:** N/A — standard bug fix, not device ID/quirk/DT/build/doc exception. ### Step 9.4: Decision Rationale This commit fixes a genuine omission in the SoundWire BPT teardown path. Since BPT was introduced in v6.15, `hda_sdw_bpt_open()` has programmed PCMSyCM registers while `hda_sdw_bpt_close()` left them programmed — unlike the normal SoundWire audio path, which explicitly resets them in `sdw_hda_dai_hw_free()`. On Intel SOF + SoundWire laptops, BPT operations (register access, codec configuration) are followed by normal audio use; stale PCMSyCM state can cause audio failures on that link. The fix is small, mirrors an established and previously stable-nominated pattern, and is endorsed by the SoundWire maintainer and Intel audio team. The missing user report is outweighed by the clear hardware semantics and code asymmetry. --- ## Verification - **[Phase 1]** `git show 992eb0dfbc4f5`: parsed full commit message and all tags - **[Phase 1]** Read `sdw_hda_dai_hw_free()` at lines 631–638 of `hda- dai.c`: confirmed PCMSyCM reset pattern; commit message references wrong function name (`hw_params` vs `hw_free`) - **[Phase 2]** Diff analysis: 3 files, ~30 net lines; core fix adds two `hdac_bus_eml_sdw_map_stream_ch()` calls with `(0, 0)` reset - **[Phase 3]** `git describe HEAD`: v6.18.44; `make kernelversion`: 6.18.44 - **[Phase 3]** `git blame` on `hda_sdw_bpt_close()`: introduced `5d5cb86fb46ea` (2025-02-27) - **[Phase 3]** `git merge-base --is-ancestor 5d5cb86fb46ea v6.18.44`: BPT code present in this tree - **[Phase 3]** `git merge-base --is-ancestor 992eb0dfbc4f5 HEAD`: commit NOT in current tree - **[Phase 3]** `git tag --contains 5d5cb86fb46ea`: first in v6.15 - **[Phase 3]** `git log --oneline -20` on affected files: no duplicate fix found - **[Phase 4]** `b4 dig -c 992eb0dfbc4f5`: found thread at patch.msgid.link URL - **[Phase 4]** `b4 dig -c 992eb0dfbc4f5 -w`: Vinod Koul, broonie, vkoul, pierre-louis.bossart CC'd - **[Phase 4]** `b4 dig -c 992eb0dfbc4f5 -a`: single v1 patch, no revisions - **[Phase 4]** `/tmp/bpt_thread.mbox`: Vinod Koul Acked; Pierre-Louis Bossart LGTM; no stable nomination or NAKs - **[Phase 4]** WebFetch of patch URL: blocked by bot protection; used mbox instead - **[Phase 5]** `grep hdac_bus_eml_sdw_map_stream_ch`: present in `hda- mlink.c`, used in `hda-dai.c` and `hda-sdw-bpt.c` - **[Phase 5]** `grep bpt_` call chain: `bus.c` → `intel_ace2x.c` → `hda_sdw_bpt_close()` - **[Phase 5]** `grep sdw->instance` in `intel_ace2x.c`: already used in `hda_sdw_bpt_open()` at line 167 - **[Phase 6]** Read current `hda_sdw_bpt_close()` at lines 425–438: confirms buggy code (no PCMSyCM reset) - **[Phase 6]** `git show 992eb0dfbc4f5 -- sound/soc/sof/intel/hda-sdw- bpt.c drivers/soundwire/intel_ace2x.c | git apply --check`: **passes** - **[Phase 6]** `git show 992eb0dfbc4f5 -- include/sound/hda-sdw-bpt.h | git apply --check`: **fails** — master has `hda_sdw_bpt_get_buf_size_alignment()` not in v6.18.44; trivial manual fix - **[Phase 6]** `git diff v6.18.44 master -- include/sound/hda-sdw- bpt.h`: confirmed divergence - **[Phase 7]** `grep CONFIG_SND_SOF_SOF_HDA_SDW_BPT` in Kconfig: present, auto-selected for Intel LNL+ - **[Phase 8]** Failure mode assessed from PCMSyCM register semantics and parallel `sdw_hda_dai_hw_free()` behavior **YES**Those background git searches finished successfully and match what the analysis already used: - **BPT introduction:** SoundWire BPT support landed with `5d5cb86fb46ea` ("add helpers for SoundWire BPT DMA"), first appearing in **v6.15** and present in your **v6.18.44** tree. - **PCMSyCM history:** The register helper dates to `ccc2f0c1b6b61` (2023); the normal SoundWire reset path is in `sdw_hda_dai_hw_free()`, and a related stable-nominated fix is `6e38a7e098d32`. That confirms the bug has been in the BPT close path since BPT was added, and the backport recommendation remains **YES**. drivers/soundwire/intel_ace2x.c | 4 +++- include/sound/hda-sdw-bpt.h | 5 +++-- sound/soc/sof/intel/hda-sdw-bpt.c | 31 ++++++++++++++++++++++++++++--- 3 files changed, 34 insertions(+), 6 deletions(-) diff --git a/drivers/soundwire/intel_ace2x.c b/drivers/soundwire/intel_ace2x.c index f0e0a79b30b0e..c1ea420bc11ff 100644 --- a/drivers/soundwire/intel_ace2x.c +++ b/drivers/soundwire/intel_ace2x.c @@ -192,6 +192,7 @@ static int intel_ace2x_bpt_open_stream(struct sdw_intel *sdw, struct sdw_slave * __func__, str_read_write(command), ret); ret1 = hda_sdw_bpt_close(cdns->dev->parent, /* PCI device */ + sdw->instance, sdw->bpt_ctx.bpt_tx_stream, &sdw->bpt_ctx.dmab_tx_bdl, sdw->bpt_ctx.bpt_rx_stream, &sdw->bpt_ctx.dmab_rx_bdl); if (ret1 < 0) @@ -226,7 +227,8 @@ static void intel_ace2x_bpt_close_stream(struct sdw_intel *sdw, struct sdw_slave struct sdw_cdns *cdns = &sdw->cdns; int ret; - ret = hda_sdw_bpt_close(cdns->dev->parent /* PCI device */, sdw->bpt_ctx.bpt_tx_stream, + ret = hda_sdw_bpt_close(cdns->dev->parent /* PCI device */, sdw->instance, + sdw->bpt_ctx.bpt_tx_stream, &sdw->bpt_ctx.dmab_tx_bdl, sdw->bpt_ctx.bpt_rx_stream, &sdw->bpt_ctx.dmab_rx_bdl); if (ret < 0) diff --git a/include/sound/hda-sdw-bpt.h b/include/sound/hda-sdw-bpt.h index f649549b75d52..330cda50f100c 100644 --- a/include/sound/hda-sdw-bpt.h +++ b/include/sound/hda-sdw-bpt.h @@ -27,7 +27,7 @@ int hda_sdw_bpt_send_async(struct device *dev, struct hdac_ext_stream *bpt_tx_st int hda_sdw_bpt_wait(struct device *dev, struct hdac_ext_stream *bpt_tx_stream, struct hdac_ext_stream *bpt_rx_stream); -int hda_sdw_bpt_close(struct device *dev, struct hdac_ext_stream *bpt_tx_stream, +int hda_sdw_bpt_close(struct device *dev, int link_id, struct hdac_ext_stream *bpt_tx_stream, struct snd_dma_buffer *dmab_tx_bdl, struct hdac_ext_stream *bpt_rx_stream, struct snd_dma_buffer *dmab_rx_bdl); #else @@ -56,7 +56,8 @@ static inline int hda_sdw_bpt_wait(struct device *dev, struct hdac_ext_stream *b return -EOPNOTSUPP; } -static inline int hda_sdw_bpt_close(struct device *dev, struct hdac_ext_stream *bpt_tx_stream, +static inline int hda_sdw_bpt_close(struct device *dev, int link_id, + struct hdac_ext_stream *bpt_tx_stream, struct snd_dma_buffer *dmab_tx_bdl, struct hdac_ext_stream *bpt_rx_stream, struct snd_dma_buffer *dmab_rx_bdl) diff --git a/sound/soc/sof/intel/hda-sdw-bpt.c b/sound/soc/sof/intel/hda-sdw-bpt.c index ff5abccf0d88b..4e5c99413c750 100644 --- a/sound/soc/sof/intel/hda-sdw-bpt.c +++ b/sound/soc/sof/intel/hda-sdw-bpt.c @@ -297,7 +297,8 @@ int hda_sdw_bpt_open(struct device *dev, int link_id, struct hdac_ext_stream **b __func__, ret); close: - ret1 = hda_sdw_bpt_close(dev, *bpt_tx_stream, dmab_tx_bdl, *bpt_rx_stream, dmab_rx_bdl); + ret1 = hda_sdw_bpt_close(dev, link_id, *bpt_tx_stream, dmab_tx_bdl, + *bpt_rx_stream, dmab_rx_bdl); if (ret1 < 0) dev_err(dev, "%s: hda_sdw_bpt_close failed: %d\n", __func__, ret1); @@ -422,14 +423,38 @@ int hda_sdw_bpt_wait(struct device *dev, struct hdac_ext_stream *bpt_tx_stream, } EXPORT_SYMBOL_NS(hda_sdw_bpt_wait, "SND_SOC_SOF_INTEL_HDA_SDW_BPT"); -int hda_sdw_bpt_close(struct device *dev, struct hdac_ext_stream *bpt_tx_stream, +int hda_sdw_bpt_close(struct device *dev, int link_id, struct hdac_ext_stream *bpt_tx_stream, struct snd_dma_buffer *dmab_tx_bdl, struct hdac_ext_stream *bpt_rx_stream, struct snd_dma_buffer *dmab_rx_bdl) { + struct snd_sof_dev *sdev = dev_get_drvdata(dev); int ret; int ret1; - ret = hda_sdw_bpt_dma_deprepare(dev, bpt_rx_stream, dmab_rx_bdl); + /* + * In the case of SoundWire we need to reset the PCMSyCM registers. + * Need to continue depreparing the DMA buffers even if this fails. + */ + ret = hdac_bus_eml_sdw_map_stream_ch(sof_to_bus(sdev), link_id, + 0, /* PDI0 */ + 0, 0, SNDRV_PCM_STREAM_PLAYBACK); + if (ret < 0) + dev_err(dev, "%s: hdac_bus_eml_sdw_map_stream_ch failed %d for PDI0\n", + __func__, ret); + + ret1 = hdac_bus_eml_sdw_map_stream_ch(sof_to_bus(sdev), link_id, + 1, /* PDI1 */ + 0, 0, SNDRV_PCM_STREAM_CAPTURE); + if (ret1 < 0) { + dev_err(dev, "%s: hdac_bus_eml_sdw_map_stream_ch failed %d for PDI1\n", + __func__, ret1); + if (!ret) + ret = ret1; + } + + ret1 = hda_sdw_bpt_dma_deprepare(dev, bpt_rx_stream, dmab_rx_bdl); + if (!ret) + ret = ret1; ret1 = hda_sdw_bpt_dma_deprepare(dev, bpt_tx_stream, dmab_tx_bdl); if (!ret) -- 2.53.0

1 0

[PATCH AUTOSEL 6.18] ASoC: SOF: validate probe info element counts
by Sasha Levin 31 Aug '26

31 Aug '26

From: Yousef Alhouseen <alhouseenyousef(a)gmail.com> [ Upstream commit 95edf2dbb492f3ea2420111e9c0044c7dec9113c ] Probe information replies contain a firmware-provided element count. IPC3 uses that count to copy an array, then returns the unchecked count to its caller. A short reply can therefore make the caller walk beyond the copied array. IPC4 similarly uses the count both to allocate the destination array and to walk the reply. On 32-bit systems the allocation size can wrap, while on all systems an excessive count reads beyond the reply payload. Validate each count against the actual reply size before copying or allocating the array, and use kcalloc() for the IPC4 allocation. Signed-off-by: Yousef Alhouseen <alhouseenyousef(a)gmail.com> Link: https://patch.msgid.link/20260628000329.18606-1-alhouseenyousef@gmail.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## Phase 1: Commit Message Forensics ### Step 1.1: Subject Line **Record:** `[ASoC: SOF]` `[validate]` — Validate firmware-provided probe info element counts before use in IPC3/IPC4 probe handlers. ### Step 1.2: Tags **Record:** - **Signed-off-by:** Yousef Alhouseen `<alhouseenyousef(a)gmail.com>` (author) - **Link:** `https://patch.msgid.link/20260628000329.18606-1- alhouseenyousef(a)gmail.com` - **Signed-off-by:** Mark Brown `<broonie(a)kernel.org>` (ASoC maintainer) - No `Fixes:`, `Reported-by:`, `Cc: stable(a)vger.kernel.org`, `Tested- by:`, or `Reviewed-by:` tags - Notable: maintainer sign-off; no fuzzer/user bug report in message ### Step 1.3: Body Analysis **Record:** - **Bug:** Probe info IPC replies include a firmware-provided `num_elems`. IPC3 uses it for `kmemdup()` and returns it to callers; IPC4 uses it for allocation and iteration. Neither path validates the count against the actual reply size. - **Symptoms:** Short/malformed replies can cause out-of-bounds reads during copy/iteration; on 32-bit IPC4 paths, `num_elems * sizeof(desc)` can wrap in `kzalloc()`. - **Root cause:** Missing bounds check on untrusted firmware IPC payload fields. - **Version info:** None stated in the commit message. ### Step 1.4: Hidden Bug Fix? **Record:** Yes. Although the subject says "validate" rather than "fix", this is a memory-safety bug fix: unchecked firmware metadata can cause OOB access and allocation-size wrap. --- ## Phase 2: Diff Analysis ### Step 2.1: Inventory **Record:** - `sound/soc/sof/sof-client-probes-ipc3.c`: +19 / -4 lines - `sound/soc/sof/sof-client-probes-ipc4.c`: +11 / -1 lines - **Functions modified:** `ipc3_probes_info()`, `ipc4_probes_points_info()` - **Scope:** Small, two-file, subsystem-local surgical fix ### Step 2.2: Code Flow Changes **IPC3 (`ipc3_probes_info`):** - **Before:** After IPC success, used `reply->num_elems` directly to compute `bytes *= num_elems`, `kmemdup()`, and `*num_params`. - **After:** Reads `payload_size = reply->rhdr.hdr.size`, rejects undersized payloads, computes `elem_size`, validates `num_elems <= payload_size / elem_size`, then copies/returns count. **IPC4 (`ipc4_probes_points_info`):** - **Before:** Used `info->num_elems` directly for `kzalloc(*num_desc * sizeof(**desc))` and loop bound. - **After:** Validates `info->num_elems` against `msg.data_size`, switches to `kcalloc()`, rejects invalid counts. ### Step 2.3: Bug Mechanism **Record:** **Memory safety / bounds validation bug** - **IPC3:** Unchecked `num_elems` can make `bytes = elem_size * num_elems` exceed actual reply payload; `kmemdup()` reads past valid IPC data. If multiplication wraps, a small allocation can be paired with a large returned count, and callers iterate past the allocation. - **IPC4:** Unchecked `num_elems` allows loop reads past `msg.data_ptr` bounds; `kzalloc(n * size)` can wrap on 32-bit systems. ### Step 2.4: Fix Quality **Record:** Fix is obviously correct and minimal. It mirrors the existing SOF pattern in `debug.c` (`struct_size(reply, elems, reply->num_elems) != reply->rhdr.hdr.size`). Regression risk is very low: only rejects malformed firmware replies. --- ## Phase 3: Git History Investigation ### Step 3.1: Blame **Record:** Buggy lines in both files trace to commit `5d324e5159d9e` in this shallow checkout. The vulnerable logic is present in the current tree at `sof-client-probes-ipc3.c:131-144` and `sof-client-probes- ipc4.c:251-264`. ### Step 3.2: Fixes Tag **Record:** N/A — no `Fixes:` tag in the commit message. ### Step 3.3: Related File History **Record:** Repository is shallow (`git rev-parse --is-shallow- repository` → `true`), limiting history depth. The probe client files exist in this 6.18.44 tree. No duplicate fix found (`grep "invalid probe info element count"` → no matches). ### Step 3.4: Author History **Record:** No prior SOF commits from Yousef Alhouseen found in this tree. Mark Brown is ASoC maintainer (sign-off). ### Step 3.5: Dependencies **Record:** Standalone fix. Uses only existing headers (`offsetof`, `kcalloc`). No series dependency indicated. The commit is not yet present in this checkout. --- ## Phase 4: Mailing List and External Research ### Step 4.1: Original Discussion **Record:** UNVERIFIED — `b4 dig` could not match the commit (not in local repo). WebFetch to patch.msgid.link and lore.kernel.org returned bot-protection pages (403/JS challenge). Could not read review thread. ### Step 4.2: Reviewers **Record:** UNVERIFIED — `b4 dig -w` unavailable for this commit. ### Step 4.3: Bug Report **Record:** No `Reported-by:` or syzbot link. Issue identified by code inspection of firmware IPC parsing. ### Step 4.4: Related Patches **Record:** UNVERIFIED — could not retrieve series revisions from lore. ### Step 4.5: Stable List History **Record:** UNVERIFIED — lore stable search inaccessible. --- ## Phase 5: Code Semantic Analysis ### Step 5.1: Key Functions **Record:** `ipc3_probes_info()`, `ipc3_probes_points_info()` (wrapper), `ipc4_probes_points_info()` ### Step 5.2: Callers **Record:** - `sof_probes_compr_shutdown()` in `sof-client-probes.c:78` — compressed-stream shutdown path - `sof_probes_dfs_points_read()` in `sof-client-probes.c:227` — debugfs read path (root-accessible) Both invoke `ipc->points_info()` from the IPC ops table. ### Step 5.3: Callees **Record:** `sof_client_ipc_tx_message()`, `sof_client_ipc_set_get_data()`, `kmemdup()`, `kzalloc()`/`kcalloc()`, `sof_client_get_ipc_max_payload_size()` ### Step 5.4: Reachability **Record:** - Trigger requires `CONFIG_SND_SOC_SOF_DEBUG_PROBES`, auto-selected on Intel HDA (`SND_SOC_SOF_HDA_PROBES`) and AMD ACP (`SND_SOC_SOF_ACP_PROBES`) SOF platforms. - Malformed `num_elems` must come from SOF firmware IPC replies during probe point enumeration. - Not a direct unprivileged syscall path, but reachable during normal audio probe shutdown and root debugfs use when probes are active. - Precedent: `sound/soc/sof/debug.c:227-231` already validates similar IPC `num_elems` against `rhdr.hdr.size`. ### Step 5.5: Similar Patterns **Record:** `debug.c` already validates IPC element counts; probes code was missing equivalent checks. `ipc3-control.c` uses overflow checks for control data sizes. --- ## Phase 6: Cross-Reference Against Local Tree ### Step 6.1: Buggy Code Present? **Record:** **Yes.** Local tree is **v6.18.44** (`6.18.44`). Vulnerable code is present; fix is **not** applied. Confirmed by reading current sources and absent error string `invalid probe info element count`. ### Step 6.2: Backport Complications **Record:** Expected **clean apply** — current file contents match the patch base context exactly. ### Step 6.3: Related Fixes Already Present? **Record:** No equivalent validation found in probe IPC files. `debug.c` has similar validation for a different IPC path only. --- ## Phase 7: Subsystem and Maintainer Context ### Step 7.1: Subsystem **Record:** `sound/soc/sof` — ASoC / SOF audio driver. **Criticality: IMPORTANT** (not core kernel, but widely used on Intel/AMD laptop/desktop SOF platforms). ### Step 7.2: Activity **Record:** SOF client probe support is active in this tree (`sof- client-probes*.c` present, Makefile builds with `CONFIG_SND_SOC_SOF_DEBUG_PROBES`). --- ## Phase 8: Impact and Risk Assessment ### Step 8.1: Who Is Affected **Record:** Users on SOF platforms with probes enabled (Intel HDA SOF, AMD ACP). Config-specific, not universal. ### Step 8.2: Trigger Conditions **Record:** SOF firmware returns probe info with `num_elems` inconsistent with reply size. Requires probes feature active and a probe-info IPC exchange. Most likely with buggy firmware; defense-in- depth against compromised firmware is also relevant. Root can trigger via debugfs when extractor is running. ### Step 8.3: Failure Mode Severity **Record:** - **IPC3:** OOB read in `kmemdup()`; potential `size_t` multiply wrap leading to small allocation + large iteration count - **IPC4:** OOB read in `info->points[i]` loop; `kzalloc()` size wrap on 32-bit - **Severity: HIGH** (kernel memory safety; possible oops/KASAN fault) ### Step 8.4: Risk-Benefit **Record:** - **Benefit:** Prevents kernel memory corruption/crash on malformed firmware IPC in an existing code path - **Risk:** Very low — only rejects invalid replies; follows established SOF validation pattern - **Ratio:** Strong benefit, minimal risk --- ## Phase 9: Final Synthesis ### Step 9.1: Evidence Summary **FOR backport:** - Real memory-safety bug (OOB read, allocation-size wrap) - Small, surgical, obviously correct fix - Buggy code exists in this 6.18.44 tree; fix not yet present - Matches existing validation in `debug.c` - Maintainer-reviewed (Mark Brown) - Callers iterate using returned count after undersized allocation/copy **AGAINST backport:** - Config-limited (`CONFIG_SND_SOC_SOF_DEBUG_PROBES`) - Trigger requires malformed SOF firmware IPC, not direct userspace input - No syzbot/user report in commit message - Mailing list review details unavailable **Unresolved:** - Full lore review thread and any explicit stable nominations (web access blocked) ### Step 9.2: Stable Rules Checklist 1. Obviously correct and tested? **PASS** — logic is straightforward; maintainer sign-off; pattern proven elsewhere in SOF 2. Fixes a real bug affecting users? **PASS** — malformed firmware IPC can crash/affect SOF probe users 3. Important issue? **PASS** — HIGH severity memory safety 4. Small and contained? **PASS** — ~30 lines, 2 files 5. No new features or APIs? **PASS** — validation only 6. Can apply to local tree? **PASS** — code exists; patch context matches ### Step 9.3: Exception Categories **Record:** None (not device ID, quirk, DT, build, or docs). Standard bug-fix exception applies. ### Step 9.4: Decision Rationale For **this** tree (6.18.44), the vulnerable probe IPC parsing code is present and lacks bounds checking on firmware-provided element counts. The fix is minimal, follows an established SOF pattern, and closes a real kernel memory-safety hole that can be triggered when SOF probes are in use and firmware returns inconsistent IPC data. While the feature is config-specific and firmware-mediated, stable trees routinely take such IPC validation fixes because the failure mode is kernel OOB access, not a benign error return. --- ## Verification - [Phase 1] Parsed subject, tags, body from provided commit message - [Phase 1] Confirmed no `Fixes:`, `Reported-by:`, or syzbot references - [Phase 2] Read diff hunks for `ipc3_probes_info()` and `ipc4_probes_points_info()` - [Phase 2] Classified bug as unchecked firmware `num_elems` → OOB / overflow - [Phase 3] `git describe HEAD` → `v6.18.44-1-g2736c32da98b9`; Makefile → 6.18.44 - [Phase 3] `git blame` on vulnerable lines → `5d324e5159d9e` - [Phase 3] `git rev-parse --is-shallow-repository` → `true` - [Phase 3] `grep "invalid probe info element count"` → no matches (fix absent) - [Phase 4] `b4 dig -c HEAD` on wrong commit; target commit not in repo - [Phase 4] WebFetch patch.msgid.link and lore search → blocked by bot protection - [Phase 4] curl lore raw → 403 Forbidden - [Phase 5] `grep` callers → `sof-client-probes.c:78`, `sof-client- probes.c:227` - [Phase 5] Read `debug.c:227-231` — existing `num_elems` vs `hdr.size` validation - [Phase 5] Read Kconfig — `SND_SOC_SOF_DEBUG_PROBES` auto-selected by HDA/ACP probe options - [Phase 6] Read current `sof-client-probes-ipc3.c:102-148` — vulnerable code confirmed - [Phase 6] Read current `sof-client-probes-ipc4.c:207-267` — vulnerable code confirmed - [Phase 6] Verified patch context matches current tree contents - [Phase 7] Read `sound/soc/sof/Makefile` — probes built under `CONFIG_SND_SOC_SOF_DEBUG_PROBES` - [Phase 8] Traced failure modes: OOB read, size wrap, caller over- iteration - **UNVERIFIED:** Lore review thread, stable-list discussion, explicit reviewer stable nomination **YES** sound/soc/sof/sof-client-probes-ipc3.c | 23 +++++++++++++++++++---- sound/soc/sof/sof-client-probes-ipc4.c | 11 ++++++++++- 2 files changed, 29 insertions(+), 5 deletions(-) diff --git a/sound/soc/sof/sof-client-probes-ipc3.c b/sound/soc/sof/sof-client-probes-ipc3.c index a78ec0954a618..a3e382d6161f1 100644 --- a/sound/soc/sof/sof-client-probes-ipc3.c +++ b/sound/soc/sof/sof-client-probes-ipc3.c @@ -107,7 +107,7 @@ static int ipc3_probes_info(struct sof_client_dev *cdev, unsigned int cmd, struct device *dev = &cdev->auxdev.dev; struct sof_ipc_probe_info_params msg = {{{0}}}; struct sof_ipc_probe_info_params *reply; - size_t bytes; + size_t bytes, elem_size, payload_size; int ret; *params = NULL; @@ -128,14 +128,29 @@ static int ipc3_probes_info(struct sof_client_dev *cdev, unsigned int cmd, if (ret < 0 || reply->rhdr.error < 0) goto exit; + payload_size = reply->rhdr.hdr.size; + if (payload_size < offsetof(struct sof_ipc_probe_info_params, dma)) { + ret = -EINVAL; + goto exit; + } + if (!reply->num_elems) goto exit; if (cmd == SOF_IPC_PROBE_DMA_INFO) - bytes = sizeof(reply->dma[0]); + elem_size = sizeof(reply->dma[0]); else - bytes = sizeof(reply->desc[0]); - bytes *= reply->num_elems; + elem_size = sizeof(reply->desc[0]); + + payload_size -= offsetof(struct sof_ipc_probe_info_params, dma); + if (reply->num_elems > payload_size / elem_size) { + dev_err(dev, "%s: invalid probe info element count %u\n", + __func__, reply->num_elems); + ret = -EINVAL; + goto exit; + } + + bytes = reply->num_elems * elem_size; *params = kmemdup(&reply->dma[0], bytes, GFP_KERNEL); if (!*params) { ret = -ENOMEM; diff --git a/sound/soc/sof/sof-client-probes-ipc4.c b/sound/soc/sof/sof-client-probes-ipc4.c index 758a56d271d77..2c2ab85979b83 100644 --- a/sound/soc/sof/sof-client-probes-ipc4.c +++ b/sound/soc/sof/sof-client-probes-ipc4.c @@ -248,10 +248,19 @@ static int ipc4_probes_points_info(struct sof_client_dev *cdev, return ret; } info = msg.data_ptr; + if (msg.data_size < sizeof(*info) || + info->num_elems > (msg.data_size - sizeof(*info)) / + sizeof(info->points[0])) { + dev_err(dev, "%s: invalid probe info element count %u\n", + __func__, info->num_elems); + kfree(msg.data_ptr); + return -EINVAL; + } + *num_desc = info->num_elems; dev_dbg(dev, "%s: got %zu probe points", __func__, *num_desc); - *desc = kzalloc(*num_desc * sizeof(**desc), GFP_KERNEL); + *desc = kcalloc(*num_desc, sizeof(**desc), GFP_KERNEL); if (!*desc) { kfree(msg.data_ptr); return -ENOMEM; -- 2.53.0

1 0

[PATCH 0/3] ASoC: fix audio on the Microsoft Surface Pro 11 (Intel)
by Sergey Lebedev 30 Aug '26

30 Aug '26

The Microsoft Surface Pro 11 for Business (Intel, Lunar Lake) has no working audio under Linux: the speakers are silent, while everything reports success. These three patches fix it, and the machine then works with the stock sof-soundwire UCM profile and the shipped topologies - no board quirk, no new match entry, no local configuration of any kind. All three failures come from one firmware defect. The board carries a single physical RT1320 amplifier on SoundWire link 0, and describes it twice: SWRA _ADR 0x000030025D132000 SDCA class 0 SWRB _ADR 0x000030025D132001 SDCA class 1 Identical apart from the class id: same link, same manufacturer, part and version, same unique id 0. The part reports class 1, so only SWRB ever enumerates. SWRA stays UNATTACHED on every boot, on every firmware version we have tested, including the November 2025 bundle. Both entries nonetheless reach the machine-select and card-probe paths, and the phantom breaks each in a different way. 1/3 rt1320: the amplifier's preset never runs, because the driver waits for FUNCTION_NEEDS_INITIALIZATION and this part never sets it. rt712-sdca and rt722-sdca already handle this by also running the preset on the first hardware init; rt1320 is the odd one out. One line. 2/3 sdw_utils: DAI links get built for the phantom, and later fail to prepare with -61, taking the whole link down rather than degrading it. 3/3 SOF/Intel hda: the phantom consumes an amplifier index, so the real part is named "rt1320-2". The stock UCM profile addresses the first amplifier and therefore enables switches on a device that is not there. Only 1/3 is codec-specific. The other two are general: any firmware that describes a peripheral twice, or describes one that never enumerates, hits them. One thing worth raising, since a reviewer will reasonably ask. Before 2/3 existed we also hit a DAI link name collision: create_sdw_dailink() builds names from link id and function type alone, so the phantom's SmartMic endpoint produced a second "SDW0-Capture-SmartMic" and the card failed to register at all with -EEXIST. With 2/3 applied the phantom's endpoints never reach the naming code, so that collision is no longer reachable on this machine and we cannot demonstrate it. The naming scheme is still not unique in general - a board with two genuinely distinct codecs of the same function type on one link would hit it - but we have no such board, so it is deliberately not part of this series. Happy to send it separately if you would like it. Testing. Developed and tested on a Surface Pro 11 for Business (Intel Core Ultra 7 268V), booting 7.1.0-rc7 built from thesofproject/linux topic/sof-dev at 7e9e0409c with these three patches and nothing else. Verified on that kernel: - card registers as sof-soundwire, 4 playback + 1 capture devices - no -EEXIST, no -61 link startup errors - amplifier named rt1320-1, controls "rt1320-1 OT23 L/R Switch" - rt1320_vc_preset runs, reporting RT1320_KR0_INT_READY=0x1f - amp function status reads 0x41 (NEWLY_ATTACHED | FUNCTION_HAS_BEEN_RESET) on every boot, confirming bit 5 is never set on this part - speakers audible, internal microphone captures signal - stock alsa-ucm-conf 1.2.15.3 and firmware-sof-signed 2025.12.2, with no local UCM, PipeWire or WirePlumber configuration checkpatch --strict is clean on all three. Sergey Lebedev (3): ASoC: rt1320: run the initialisation preset on the first hardware init ASoC: sdw_utils: skip endpoints of a peripheral that is not on the bus ASoC: SOF: Intel: hda: duplicate _ADR entries share one amp index sound/soc/codecs/rt1320-sdw.c | 2 +- sound/soc/sdw_utils/soc_sdw_utils.c | 46 +++++++++++++++++++++++++++++ sound/soc/sof/intel/hda.c | 16 ++++++++++ 3 files changed, 63 insertions(+), 1 deletion(-) base-commit: 7e9e0409cd57924c4099090879154300c07b8643 -- 2.50.1 (Apple Git-155)

3 9

[PATCH v2] ASoC: SOF: validate topology volume range before allocation
by Pengpeng Hou 14 Aug '26

14 Aug '26

SOF treats the topology mixer min and max values as non-negative indices into its volume table. It stores them in signed fields, allocates max + 1 entries through an int argument, and later indexes the table with the stored range. An inverted range is invalid, while a maximum at or above INT_MAX cannot be represented safely after the increment or in the signed fields. Validate the complete range before storing it or allocating the table. Fixes: 311ce4fe7637 ("ASoC: SOF: Add support for loading topologies") Assisted-by: Codex:gpt-5 Signed-off-by: Pengpeng Hou <pengpeng(a)iscas.ac.cn> --- Changes since v1: https://lore.kernel.org/all/20260722041532.14085-1-pengpeng@iscas.ac.cn/ - validate SOF's non-negative table-index range before signed storage - require max + 1 to remain representable by the allocator's int argument - rebase on current SOF topology sources The SOF table-index consumers and allocator conversion were reviewed statically; no SOF topology or hardware test was performed. sound/soc/sof/topology.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c index 42a2d90bb705..31dd7a66a9cf 100644 --- a/sound/soc/sof/topology.c +++ b/sound/soc/sof/topology.c @@ -846,6 +846,7 @@ static int sof_control_load_volume(struct snd_soc_component *scomp, struct snd_soc_tplg_mixer_control *mc = container_of(hdr, struct snd_soc_tplg_mixer_control, hdr); int tlv[SOF_TLV_ITEMS]; + u32 min, max; unsigned int mask; int ret; @@ -853,6 +854,11 @@ static int sof_control_load_volume(struct snd_soc_component *scomp, if (le32_to_cpu(mc->num_channels) > SND_SOC_TPLG_MAX_CHAN) return -EINVAL; + min = le32_to_cpu(mc->min); + max = le32_to_cpu(mc->max); + if (min > max || max >= INT_MAX) + return -EINVAL; + /* * If control has more than 2 channels we need to override the info. This is because even if * ASoC layer has defined topology's max channel count to SND_SOC_TPLG_MAX_CHAN = 8, the @@ -863,12 +869,12 @@ static int sof_control_load_volume(struct snd_soc_component *scomp, kc->info = snd_sof_volume_info; scontrol->comp_id = sdev->next_comp_id; - scontrol->min_volume_step = le32_to_cpu(mc->min); - scontrol->max_volume_step = le32_to_cpu(mc->max); + scontrol->min_volume_step = min; + scontrol->max_volume_step = max; scontrol->num_channels = le32_to_cpu(mc->num_channels); - scontrol->max = le32_to_cpu(mc->max); - if (le32_to_cpu(mc->max) == 1) + scontrol->max = max; + if (max == 1) goto skip; /* extract tlv data */ @@ -878,7 +884,7 @@ static int sof_control_load_volume(struct snd_soc_component *scomp, } /* set up volume table */ - ret = set_up_volume_table(scontrol, tlv, le32_to_cpu(mc->max) + 1); + ret = set_up_volume_table(scontrol, tlv, max + 1); if (ret < 0) { dev_err(scomp->dev, "error: setting up volume table\n"); return ret; @@ -911,7 +917,7 @@ static int sof_control_load_volume(struct snd_soc_component *scomp, return 0; err: - if (le32_to_cpu(mc->max) > 1) + if (max > 1) kfree(scontrol->volume_table); return ret; -- 2.50.1 (Apple Git-155)

1 0