kernel.git/include/uapi/sound/asound.h, branch linux-6.2.y

ALSA: Remove some left-over license text in include/uapi/sound/

2022-09-27T06:42:50Z

There is already a SPDX-License-Identifier tag, so the corresponding license text can be removed. Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/203c1db92c470925f31e361f6e7d180812501f2e.1664112023.git.christophe.jaillet@wanadoo.fr Signed-off-by: Takashi Iwai

treewide: uapi: Replace zero-length arrays with flexible-array members

2022-06-28T19:26:05Z

There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. This code was transformed with the help of Coccinelle: (linux-5.19-rc2$ spatch --jobs $(getconf _NPROCESSORS_ONLN) --sp-file script.cocci --include-headers --dir . > output.patch) @@ identifier S, member, array; type T1, T2; @@ struct S { ... T1 member; T2 array[ - 0 ]; }; -fstrict-flex-arrays=3 is coming and we need to land these changes to prevent issues like these in the short future: ../fs/minix/dir.c:337:3: warning: 'strcpy' will always overflow; destination buffer has size 0, but the source string has length 2 (including NUL byte) [-Wfortify-source] strcpy(de3->name, "."); ^ Since these are all [0] to [] changes, the risk to UAPI is nearly zero. If this breaks anything, we can use a union with a new member name. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/78 Build-tested-by: kernel test robot Link: https://lore.kernel.org/lkml/62b675ec.wKX6AOZ6cbE71vtF%25lkp@intel.com/ Acked-by: Dan Williams # For ndctl.h Signed-off-by: Gustavo A. R. Silva

Merge tag 'asoc-fix-v5.17-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

2022-02-01T15:52:54Z

ASoC: Fixes for v5.17 Quite a few fixes here, including an unusually large set in the core spurred on by various testing efforts as well as the usual small driver fixes. There are quite a few fixes for out of bounds writes in both the core and the various Qualcomm drivers, plus a couple of fixes for locking in the DPCM code.

ASoC: hdmi-codec: Fix OOB memory accesses

2022-01-28T15:59:19Z

Correct size of iec_status array by changing it to the size of status array of the struct snd_aes_iec958. This fixes out-of-bounds slab read accesses made by memcpy() of the hdmi-codec driver. This problem is reported by KASAN. Cc: stable@vger.kernel.org Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20220112195039.1329-1-digetx@gmail.com Signed-off-by: Mark Brown

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

2022-01-05T14:39:24Z

ASoC: Updates for v5.17 Not much going on framework release this time, but a big update for drivers especially the Intel and SOF ones. - Refinements and cleanups around the delay() APIs. - Wider use of dev_err_probe(). - Continuing cleanups and improvements to the SOF code. - Support for pin switches in simple-card derived cards. - Support for AMD Renoir ACP, Asahi Kasei Microdevices AKM4375, Intel systems using NAU8825 and MAX98390, Mediatek MT8915, nVidia Tegra20 S/PDIF, Qualcomm systems using ALC5682I-VS and Texas Instruments TLV320ADC3xxx.

ALSA: uapi: use C90 comment style instead of C99 style

2021-12-13T08:19:00Z

UAPI headers are built with compiler option for C90, thus double-slashes comment introduced in C99 is not preferable. Fixes: fb6723daf890 ("ALSA: pcm: comment about relation between msbits hw parameter and [S|U]32 formats") Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20211213081257.36097-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai

ALSA: pcm: comment about relation between msbits hw parameter and [S|U]32 formats

2021-12-13T07:18:43Z

Regarding to handling [U|S][32|24] PCM formats, many userspace application developers and driver developers have confusion, since they require them to understand justification or padding. It easily loses consistency and soundness to operate with many type of devices. In this commit, I attempt to solve the situation by adding comment about relation between [S|U]32 formats and 'msbits' hardware parameter. The formats are used for 'left-justified' sample format, and the available bit count in most significant bit is delivered to userspace in msbits hardware parameter (struct snd_pcm_hw_params.msbits), which is decided by msbits constraint added by pcm drivers (snd_pcm_hw_constraint_msbits()). In driver side, the msbits constraint includes two elements; the physical width of format and the available width of the format in most significant bit. The former is used to match SAMPLE_BITS of format. (For my convenience, I ignore wildcard in the usage of the constraint.) As a result of interaction between ALSA pcm core and ALSA pcm application, when the format in which SAMPLE_BITS equals to physical width of the msbits constaint, the msbits parameter is set by referring to the available width of the constraint. When the msbits parameter is not changed in the above process, ALSA pcm core set it alternatively with SAMPLE_BIT of chosen format. In userspace application side, the msbits is only available after calling ioctl(2) with SNDRV_PCM_IOCTL_HW_PARAMS request. Even if the hardware parameter structure includes somewhat value of SAMPLE_BITS interval parameter as width of format, all of the width is not always available since msbits can be less than the width. I note that [S|U]24 formats are used for 'right-justified' 24 bit sample formats within 32 bit frame. The first byte in most significant bit should be invalidated. Although the msbits exposed to userspace should be zero as invalid value, actually it is 32 from physical width of format. [ corrected typos -- tiwai ] Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20210529033353.21641-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai

ALSA: pcm: introduce INFO_NO_REWINDS flag

2021-11-24T12:57:18Z

When the hardware can only deal with a monotonically increasing appl_ptr, this flag can be set. In case the application requests a rewind, be it with a snd_pcm_rewind() or with a direct change of a mmap'ed pointer followed by a SNDRV_PCM_IOCTL_SYNC_PTR, this patch checks if a rewind occurred and returns an error. Credits to Takashi Iwai for identifying the path with SYNC_PTR and suggesting the pointer checks. Suggested-by: Takashi Iwai Reviewed-by: Takashi Iwai Reviewed-by: Ranjani Sridharan Reviewed-by: Kai Vehmanen Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20211119230852.206310-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ALSA: uapi: Fix a C++ style comment in asound.h

2021-10-18T12:58:28Z

UAPI header should have no C++ style comment but only in the traditional C style comment, but there is still one place we used it mistakenly. This patch corrects it. Fixes: 542283566679 ("ALSA: ctl: remove unused macro for timestamping of elem_value") Reviewed-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20211018114035.18433-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: rawmidi: introduce SNDRV_RAWMIDI_IOCTL_USER_PVERSION

2021-09-23T07:26:40Z

The new framing mode causes the user space regression, because the alsa-lib code does not initialize the reserved space in the params structure when the device is opened. This change adds SNDRV_RAWMIDI_IOCTL_USER_PVERSION like we do for the PCM interface for the protocol acknowledgment. Cc: David Henningsson Cc: Fixes: 08fdced60ca0 ("ALSA: rawmidi: Add framing mode") BugLink: https://github.com/alsa-project/alsa-lib/issues/178 Signed-off-by: Jaroslav Kysela Link: https://lore.kernel.org/r/20210920171850.154186-1-perex@perex.cz Signed-off-by: Takashi Iwai