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

[RFC PATCH v1 0/9] uaccess: Convert small fixed size copy_{to/from}_user() to scoped user access
by Christophe Leroy (CS GROUP) 29 Apr '26

29 Apr '26

A lot of copy_from_user() and copy_to_user() perform copies of small fixed size pieces of data between kernel and userspace, and don't care about partial copies. copy_from_user() and copy_to_user() are big functions optimised for copying large amount of data, with cache management, etc ... This is often overkill for small copies that could just be inlined instead. What makes things a bit more tricky is that those copy functions are designed to handle partial copies in case of page fault. But among the 6000 callers of those functions, only 2% really care about the quantity of no-copied data that those functions return. All other ones fails as soon as the returned value is not 0, returning -EACCESS. So first step in this series is to introduce variants called copy_from_user_partial() and copy_to_user_partial() which will be called by the 2% users that care about the partial copy, then the original copy_from_user() and copy_to_user() are changed to return -EFAULT when the copy fails. Then the second step is to implement copy of small fixed-size data with scoped user access instead of calling the arch specific heavy user copy functions. Patch 5, can be split in different patches for each archicture or subsystem, but let's get a first feedback and agree on the principle. Christophe Leroy (CS GROUP) (9): uaccess: Split check_zeroed_user() out of usercopy.c uaccess: Convert INLINE_COPY_{TO/FROM}_USER to kconfig and reduce ifdefery x86/umip: Be stricter in fixup_umip_exception() uaccess: Introduce copy_{to/from}_user_partial() uaccess: Switch to copy_{to/from}_user_partial() when relevant uaccess: Change copy_{to/from}_user to return -EFAULT x86: Add unsafe_copy_from_user() arm64: Add unsafe_copy_from_user() uaccess: Convert small fixed size copy_{to/from}_user() to scoped user access arch/alpha/Kconfig | 1 + arch/alpha/kernel/osf_sys.c | 4 +- arch/alpha/kernel/termios.c | 2 +- arch/arc/include/asm/uaccess.h | 3 - arch/arc/kernel/disasm.c | 2 +- arch/arm/include/asm/uaccess.h | 2 - arch/arm64/include/asm/gcs.h | 2 +- arch/arm64/include/asm/uaccess.h | 30 +++-- arch/arm64/kernel/signal32.c | 2 +- arch/csky/Kconfig | 1 + arch/hexagon/include/asm/uaccess.h | 3 - arch/loongarch/include/asm/uaccess.h | 3 - arch/m68k/include/asm/uaccess.h | 3 - arch/microblaze/include/asm/uaccess.h | 2 - arch/mips/include/asm/uaccess.h | 3 - arch/mips/kernel/rtlx.c | 8 +- arch/mips/kernel/vpe.c | 2 +- arch/nios2/include/asm/uaccess.h | 2 - arch/openrisc/include/asm/uaccess.h | 2 - arch/parisc/include/asm/uaccess.h | 3 - arch/powerpc/Kconfig | 1 + arch/powerpc/kvm/book3s_64_mmu_hv.c | 4 +- arch/powerpc/kvm/book3s_64_mmu_radix.c | 4 +- arch/powerpc/kvm/book3s_hv.c | 2 +- arch/riscv/Kconfig | 1 + arch/riscv/kernel/signal.c | 2 +- arch/s390/include/asm/idals.h | 8 +- arch/s390/include/asm/uaccess.h | 3 - arch/sh/include/asm/uaccess.h | 2 - arch/sparc/include/asm/uaccess_32.h | 3 - arch/sparc/include/asm/uaccess_64.h | 2 - arch/sparc/kernel/termios.c | 2 +- arch/um/include/asm/uaccess.h | 3 - arch/um/kernel/process.c | 2 +- arch/x86/Kconfig | 1 + arch/x86/include/asm/uaccess.h | 29 ++++- arch/x86/kernel/umip.c | 2 +- arch/x86/lib/insn-eval.c | 2 +- arch/x86/um/signal.c | 2 +- arch/xtensa/include/asm/uaccess.h | 2 - drivers/android/binder_alloc.c | 2 +- drivers/comedi/comedi_fops.c | 4 +- drivers/dma/idxd/cdev.c | 2 +- drivers/firmware/efi/test/efi_test.c | 2 +- drivers/fsi/fsi-scom.c | 2 +- .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 2 +- drivers/gpu/drm/i915/gt/intel_sseu.c | 4 +- drivers/gpu/drm/i915/i915_gem.c | 4 +- drivers/hwtracing/intel_th/msu.c | 2 +- drivers/misc/ibmvmc.c | 2 +- drivers/misc/vmw_vmci/vmci_host.c | 2 +- drivers/most/most_cdev.c | 2 +- drivers/net/ieee802154/ca8210.c | 4 +- drivers/net/wireless/ath/wil6210/debugfs.c | 2 +- .../intel/iwlwifi/pcie/gen1_2/trans.c | 2 +- drivers/net/wireless/ti/wlcore/debugfs.c | 2 +- drivers/ps3/ps3-lpm.c | 2 +- drivers/s390/crypto/zcrypt_api.h | 4 +- drivers/spi/spidev.c | 2 +- .../staging/media/atomisp/pci/atomisp_cmd.c | 8 +- drivers/tty/tty_ioctl.c | 14 +-- drivers/tty/vt/vc_screen.c | 4 +- drivers/usb/gadget/function/f_hid.c | 4 +- drivers/usb/gadget/function/f_printer.c | 2 +- drivers/vfio/vfio_iommu_type1.c | 4 +- drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +- fs/namespace.c | 2 +- fs/ocfs2/dlmfs/dlmfs.c | 2 +- fs/proc/base.c | 4 +- include/asm-generic/uaccess.h | 2 - include/linux/bpfptr.h | 2 +- include/linux/sockptr.h | 4 +- include/linux/uaccess.h | 107 ++++++++++++++---- ipc/msg.c | 8 +- ipc/sem.c | 8 +- ipc/shm.c | 18 +-- kernel/regset.c | 2 +- kernel/sys.c | 4 +- lib/Kconfig | 3 + lib/Makefile | 4 +- lib/kfifo.c | 8 +- lib/{usercopy.c => usercheck.c} | 22 ---- lib/usercopy.c | 66 ----------- mm/kasan/kasan_test_c.c | 4 +- mm/memory.c | 2 +- net/x25/af_x25.c | 2 +- rust/helpers/uaccess.c | 6 +- sound/pci/emu10k1/emufx.c | 4 +- sound/pci/rme9652/hdsp.c | 6 +- sound/soc/intel/avs/probes.c | 6 +- sound/soc/sof/compress.c | 12 +- sound/soc/sof/sof-client-probes.c | 6 +- 92 files changed, 269 insertions(+), 288 deletions(-) copy lib/{usercopy.c => usercheck.c} (73%) -- 2.49.0

11 29

i.MX8MP SOF: I2S TX data line selection issue
by Andrej Picej 21 Apr '26

21 Apr '26

Hi all, I am working on NXP i.MX8M Plus with Sound Open Firmware and I am trying to configure playback over a different I2S data line. Currently, playback works and I can observe bit clock, frame sync, and data on TX_DATA00. However, our external audio codec is connected to TX_DATA02, so we want to configure a third transmit channel (i.e., use TX_DATA02). In IMX SAI driver I modified the chan_idx to the appropriate offset for the third transmit channel, but this leads to an issue: pcm_write returns an Input/output error and no data is observed on TX_DATA02. For reference, our current topology includes the following DAI configuration: > dnl DAI_CONFIG(type, idx, link_id, name, sai_config) > > DAI_CONFIG(SAI, SAI_INDEX, 0, DAI_BE_NAME, > ifelse( > CODEC, `tas2563', ` > SAI_CONFIG(I2S, > SAI_CLOCK(mclk, 12288000, codec_mclk_in), > SAI_CLOCK(bclk, 3072000, codec_consumer), > SAI_CLOCK(fsync, RATE, codec_consumer), > SAI_TDM(2, 32, 1, 0), > SAI_CONFIG_DATA(SAI, SAI_INDEX, 0)))', > ) My questions: Is changing chan_idx sufficient to select TX_DATA02 on i.MX8MP? Are there other settings (DMA settings, topology, DAI configuration, driver, or DTS) that must be adjusted when enabling transmit channels? Any advice, examples or pointers would be greatly appreciated. Best regards, Andrej

2 7

[PATCH AUTOSEL 6.18] ASoC: SOF: topology: reject invalid vendor array size in token parser
by Sasha Levin 20 Apr '26

20 Apr '26

From: Cássio Gabriel <cassiogabrielcontato(a)gmail.com> [ Upstream commit 215e5fe75881a7e2425df04aeeed47a903d5cd5d ] sof_parse_token_sets() accepts array->size values that can be invalid for a vendor tuple array header. In particular, a zero size does not advance the parser state and can lead to non-progress parsing on malformed topology data. Validate array->size against the minimum header size and reject values smaller than sizeof(*array) before parsing. This preserves behavior for valid topologies and hardens malformed-input handling. Signed-off-by: Cássio Gabriel <cassiogabrielcontato(a)gmail.com> Acked-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Link: https://patch.msgid.link/20260319-sof-topology-array-size-fix-v1-1-f9191b16… 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: Error: Failed to generate final synthesis sound/soc/sof/topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c index b6d5c8024f8cf..4c8dba285408a 100644 --- a/sound/soc/sof/topology.c +++ b/sound/soc/sof/topology.c @@ -736,7 +736,7 @@ static int sof_parse_token_sets(struct snd_soc_component *scomp, asize = le32_to_cpu(array->size); /* validate asize */ - if (asize < 0) { /* FIXME: A zero-size array makes no sense */ + if (asize < sizeof(*array)) { dev_err(scomp->dev, "error: invalid array size 0x%x\n", asize); return -EINVAL; -- 2.53.0

1 0

Topology file needed for Dell XPS 14 DA14260 (Panther Lake) — sof-ptl-cs42l43-l0-cs35l56-l23.tplg
by John Meyer 08 Apr '26

08 Apr '26

Hello, I've submitted kernel patches to linux-sound(a)vger.kernel.org enabling audio on the Dell XPS 14 DA14260 (Panther Lake). The machine uses the following SoundWire topology: Link 0: CS42L45 (mfr 0x01FA, part 0x4245) — SDCA headset codec Link 2: CS35L57 × 2 (mfr 0x01FA, part 0x3557) — speaker amps Link 3: CS35L57 × 2 (mfr 0x01FA, part 0x3557) — speaker amps The machine driver patch (ASoC: intel: ptl) specifies the topology file as: sof-ptl-cs42l43-l0-cs35l56-l23.tplg This file does not yet exist in sof-bin. As a workaround I am currently symlinking to the LNL topology: sof-lnl-cs42l43-l0-cs35l56-l23.tplg -> sof-ptl-cs42l43-l0-cs35l56-l23.tplg This works on the hardware but is not suitable for distribution. A proper PTL topology file at the above filename would be needed for end users to get audio working without manual intervention. Happy to test any topology file on the hardware if that would help. Thanks, John Meyer

2 1