November 2022 - Alsa-devel - mailman.alsa-project.org

[PATCH v2] ASoC: soc-pcm: Add NULL check in BE reparenting
by Srinivasa Rao Mandadapu 23 Nov '22

23 Nov '22

Add NULL check in dpcm_be_reparent API, to handle kernel NULL pointer dereference error. The issue occurred in fuzzing test. Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam(a)quicinc.com> --- Changes Since V1: -- Update commit title. sound/soc/soc-pcm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 493f003..a7810c7 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -1247,6 +1247,8 @@ static void dpcm_be_reparent(struct snd_soc_pcm_runtime *fe, return; be_substream = snd_soc_dpcm_get_substream(be, stream); + if (!be_substream) + return; for_each_dpcm_fe(be, stream, dpcm) { if (dpcm->fe == fe) -- 2.7.4

3 2

starting from kernel 5.10.x latency test fails systematically on multiple platforms
by GitHub issues - edited 23 Nov '22

23 Nov '22

alsa-project/alsa-lib issue #285 was edited from bondagit: If I try the latency test application ([test/latency.c](https://github.com/alsa-project/alsa-lib/blob/master/test/l…) using a **Linux Kernel 5.9.x** with alsa-lib v1.2.4 on the following audio card: _PCH [HDA Intel PCH], device 1: ALC269VC Analog [ALC269VC Analog]_ (for example) I get the following result: ``` sudo ./latency -C hw:1 -P hw:1 -f S16_LE -r 48000 -c 2 -s 10 -m 128 -M 128 Scheduler set to Round Robin with priority 99... Playback device is hw:1 Capture device is hw:1 Parameters are 48000Hz, S16_LE, 2 channels, non-blocking mode Poll mode: no Loop limit is 480000 frames, minimum latency = 128, maximum latency = 128 Hardware PCM card 1 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Hardware PCM card 1 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Trying latency 128 frames, 2666.667us, 2.666667ms (375.0000Hz) Success Playback: *** frames = 480128 *** state : RUNNING trigger_time: 1907393.672215 tstamp : 0.000000 delay : 80 avail : 48 avail_max : 64 Capture: *** frames = 480000 *** state : RUNNING trigger_time: 1907393.672215 tstamp : 0.000000 delay : 0 avail : 0 avail_max : 16 Maximum read: 16 frames Maximum read latency: 333.333us, 0.333333ms (3000.0000Hz) Hardware sync Playback time = 1907393.672215, Record time = 1907393.672215, diff = 0 ``` The tests succeeded and final state is **RUNNING** If I try the same tests on the same audio device and distribution but with a **Linux Kernel >= 5.10.x** it fails systematically and I get: ``` sudo ./lantency -C hw:1 -P hw:1 -f S16_LE -r 48000 -c 2 -s 10 -m 128 -M 128 Scheduler set to Round Robin with priority 99... Playback device is hw:0 Capture device is hw:0 Parameters are 48000Hz, S16_LE, 2 channels, non-blocking mode Poll mode: no Loop limit is 480000 frames, minimum latency = 128, maximum latency = 128 Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Trying latency 128 frames, 2666.667us, 2.666667ms (375.0000Hz) Failure Playback: *** frames = 90720 *** state : XRUN trigger_time: 967.658489 tstamp : 0.000000 delay : 0 avail : 216 avail_max : 216 Capture: *** frames = 90592 *** state : XRUN trigger_time: 967.658489 tstamp : 0.000000 delay : 0 avail : 88 avail_max : 88 Maximum read: 16 frames Maximum read latency: 333.333us, 0.333333ms (3000.0000Hz) Hardware sync ``` I get an **XRUN** during the test execution. I can reproduce the same error on multiple boards for multiple audio cards and on different Linux distribution just changing the Linux kernel version. The problem was originally reported at: [AES67 Linux daemon: Latency test fails with Linux kernel starting from 5.10.0x](https://github.com/bondagit/aes67-linux-daemon/issues/79) I am interested in testing with low latency (-m 128 -M 128). My guess is that something changed in the Linux audio core and the latency application has to be adapted. Any idea ? Issue URL : https://github.com/alsa-project/alsa-lib/issues/285 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

starting from kernel 5.10.x latency test fails systematically on multiple platforms
by GitHub issues - edited 23 Nov '22

23 Nov '22

alsa-project/alsa-lib issue #285 was edited from bondagit: If I try the latency test application ([test/latency.c](https://github.com/alsa-project/alsa-lib/blob/master/test/l…) using a **Linux Kernel 5.9.x** with alsa-lib v1.2.4 on the following audio card: _PCH [HDA Intel PCH], device 1: ALC269VC Analog [ALC269VC Analog]_ (for example) I get the following result: ``` sudo ./latency -C hw:1 -P hw:1 -f S16_LE -r 48000 -c 2 -s 10 -m 128 -M 128 Scheduler set to Round Robin with priority 99... Playback device is hw:1 Capture device is hw:1 Parameters are 48000Hz, S16_LE, 2 channels, non-blocking mode Poll mode: no Loop limit is 480000 frames, minimum latency = 128, maximum latency = 128 Hardware PCM card 1 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Hardware PCM card 1 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Trying latency 128 frames, 2666.667us, 2.666667ms (375.0000Hz) Success Playback: *** frames = 480128 *** state : RUNNING trigger_time: 1907393.672215 tstamp : 0.000000 delay : 80 avail : 48 avail_max : 64 Capture: *** frames = 480000 *** state : RUNNING trigger_time: 1907393.672215 tstamp : 0.000000 delay : 0 avail : 0 avail_max : 16 Maximum read: 16 frames Maximum read latency: 333.333us, 0.333333ms (3000.0000Hz) Hardware sync Playback time = 1907393.672215, Record time = 1907393.672215, diff = 0 ``` The tests succeeded and final state is **RUNNING** If I try the same tests on the same audio device and distribution but with a **Linux Kernel >= 5.10.x** it fails systematically and I get: ``` sudo ./lantency -C hw:1 -P hw:1 -f S16_LE -r 48000 -c 2 -s 10 -m 128 -M 128 Scheduler set to Round Robin with priority 99... Playback device is hw:0 Capture device is hw:0 Parameters are 48000Hz, S16_LE, 2 channels, non-blocking mode Poll mode: no Loop limit is 480000 frames, minimum latency = 128, maximum latency = 128 Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Trying latency 128 frames, 2666.667us, 2.666667ms (375.0000Hz) Failure Playback: *** frames = 90720 *** state : XRUN trigger_time: 967.658489 tstamp : 0.000000 delay : 0 avail : 216 avail_max : 216 Capture: *** frames = 90592 *** state : XRUN trigger_time: 967.658489 tstamp : 0.000000 delay : 0 avail : 88 avail_max : 88 Maximum read: 16 frames Maximum read latency: 333.333us, 0.333333ms (3000.0000Hz) Hardware sync ``` I get an **XRUN** during the test execution. I can reproduce the same error on multiple boards for multiple audio cards and on different Linux distribution just changing the Linux kernel version. The problem was originally reported at: [AES67 Linux daemon: Latency test fails with Linux kernel starting from 5.10.0x](https://github.com/bondagit/aes67-linux-daemon/issues/79) I am interested in testing a with low latency (-m 128 -M 128). My guess is that something changed in the Linux audio core and the latency application has to be adapted. Any idea ? Issue URL : https://github.com/alsa-project/alsa-lib/issues/285 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

starting from kernel 5.10.x latency test fails systematically on multiple platforms
by GitHub issues - opened 23 Nov '22

23 Nov '22

alsa-project/alsa-lib issue #285 was opened from bondagit: If I try the latency test application ([test/latency.c](https://github.com/alsa-project/alsa-lib/blob/master/test/l…) using a **Linux Kernel 5.9.x** with alsa-lib v1.2.4 on the following audio card: _PCH [HDA Intel PCH], device 1: ALC269VC Analog [ALC269VC Analog]_ (for example) I get the following result: ``` sudo ./latency -C hw:1 -P hw:1 -f S16_LE -r 48000 -c 2 -s 10 -m 128 -M 128 Scheduler set to Round Robin with priority 99... Playback device is hw:1 Capture device is hw:1 Parameters are 48000Hz, S16_LE, 2 channels, non-blocking mode Poll mode: no Loop limit is 480000 frames, minimum latency = 128, maximum latency = 128 Hardware PCM card 1 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Hardware PCM card 1 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Trying latency 128 frames, 2666.667us, 2.666667ms (375.0000Hz) Success Playback: *** frames = 480128 *** state : RUNNING trigger_time: 1907393.672215 tstamp : 0.000000 delay : 80 avail : 48 avail_max : 64 Capture: *** frames = 480000 *** state : RUNNING trigger_time: 1907393.672215 tstamp : 0.000000 delay : 0 avail : 0 avail_max : 16 Maximum read: 16 frames Maximum read latency: 333.333us, 0.333333ms (3000.0000Hz) Hardware sync Playback time = 1907393.672215, Record time = 1907393.672215, diff = 0 ``` The tests succeeded and final state is **RUNNING** If I try the same tests on the same audio device and distribution but with a **Linux Kernel >= 5.10.x** it fails systematically and I get: ``` sudo ./lantency -C hw:1 -P hw:1 -f S16_LE -r 48000 -c 2 -s 10 -m 128 -M 128 Scheduler set to Round Robin with priority 99... Playback device is hw:0 Capture device is hw:0 Parameters are 48000Hz, S16_LE, 2 channels, non-blocking mode Poll mode: no Loop limit is 480000 frames, minimum latency = 128, maximum latency = 128 Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Trying latency 128 frames, 2666.667us, 2.666667ms (375.0000Hz) Failure Playback: *** frames = 90720 *** state : XRUN trigger_time: 967.658489 tstamp : 0.000000 delay : 0 avail : 216 avail_max : 216 Capture: *** frames = 90592 *** state : XRUN trigger_time: 967.658489 tstamp : 0.000000 delay : 0 avail : 88 avail_max : 88 Maximum read: 16 frames Maximum read latency: 333.333us, 0.333333ms (3000.0000Hz) Hardware sync ``` I get an **XRUN** during the test execution. I can reproduce the same error on multiple boards for multiple audio cards and on different Linux distribution just changing the Linux kernel version. The problem was originally reported at: [AES67 Linux daemon: Latency test fails with Linux kernel starting from 5.10.0x](https://github.com/bondagit/aes67-linux-daemon/issues/79) My guess is that something changed in the Linux audio core and the latency application has to be adapted. Any idea ? Issue URL : https://github.com/alsa-project/alsa-lib/issues/285 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[RESEND PATCH] ALSA: rawmidi: fix infoleak in snd_rawmidi_ioctl_status_compat64
by Xiaolong Huang 23 Nov '22

23 Nov '22

The compat_status is declared off of the stack, so it needs to be zeroed out before copied back to userspace to prevent any unintentional data leakage. Fixes: d9e5582c4bb2 ("ALSA: Avoid using timespec for struct snd_rawmidi_status") Signed-off-by: Xiaolong Huang <butterflyhuangxx(a)gmail.com> --- Reason for resend: 1. add Fixes line. --- sound/core/rawmidi_compat.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/core/rawmidi_compat.c b/sound/core/rawmidi_compat.c index 68a93443583c..6afa68165b17 100644 --- a/sound/core/rawmidi_compat.c +++ b/sound/core/rawmidi_compat.c @@ -80,6 +80,7 @@ static int snd_rawmidi_ioctl_status_compat64(struct snd_rawmidi_file *rfile, if (err < 0) return err; + memset(&compat_status, 0, sizeof(compat_status)); compat_status = (struct compat_snd_rawmidi_status64) { .stream = status.stream, .tstamp_sec = status.tstamp_sec, base-commit: eb7081409f94a9a8608593d0fb63a1aa3d6f95d8 -- 2.25.1

3 3

[PATCH -next v2] ALSA: seq: fix undefined behavior in bit shift for SNDRV_SEQ_FILTER_USE_EVENT
by Baisong Zhong 23 Nov '22

23 Nov '22

Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in sound/core/seq/seq_clientmgr.c:509:22 left shift of 1 by 31 places cannot be represented in type 'int' ... Call Trace: <TASK> dump_stack_lvl+0x8d/0xcf ubsan_epilogue+0xa/0x44 __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 snd_seq_deliver_single_event.constprop.21+0x191/0x2f0 snd_seq_deliver_event+0x1a2/0x350 snd_seq_kernel_client_dispatch+0x8b/0xb0 snd_seq_client_notify_subscription+0x72/0xa0 snd_seq_ioctl_subscribe_port+0x128/0x160 snd_seq_kernel_client_ctl+0xce/0xf0 snd_seq_oss_create_client+0x109/0x15b alsa_seq_oss_init+0x11c/0x1aa do_one_initcall+0x80/0x440 kernel_init_freeable+0x370/0x3c3 kernel_init+0x1b/0x190 ret_from_fork+0x1f/0x30 </TASK> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Baisong Zhong <zhongbaisong(a)huawei.com> --- v2: update all SNDRV_SEQ_FILTER_* to 1U to keep consistent --- include/uapi/sound/asequencer.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/uapi/sound/asequencer.h b/include/uapi/sound/asequencer.h index 6d4a2c60808d..00d2703e8fca 100644 --- a/include/uapi/sound/asequencer.h +++ b/include/uapi/sound/asequencer.h @@ -328,10 +328,10 @@ typedef int __bitwise snd_seq_client_type_t; #define KERNEL_CLIENT ((__force snd_seq_client_type_t) 2) /* event filter flags */ -#define SNDRV_SEQ_FILTER_BROADCAST (1<<0) /* accept broadcast messages */ -#define SNDRV_SEQ_FILTER_MULTICAST (1<<1) /* accept multicast messages */ -#define SNDRV_SEQ_FILTER_BOUNCE (1<<2) /* accept bounce event in error */ -#define SNDRV_SEQ_FILTER_USE_EVENT (1<<31) /* use event filter */ +#define SNDRV_SEQ_FILTER_BROADCAST (1U<<0) /* accept broadcast messages */ +#define SNDRV_SEQ_FILTER_MULTICAST (1U<<1) /* accept multicast messages */ +#define SNDRV_SEQ_FILTER_BOUNCE (1U<<2) /* accept bounce event in error */ +#define SNDRV_SEQ_FILTER_USE_EVENT (1U<<31) /* use event filter */ struct snd_seq_client_info { int client; /* client number to inquire */ -- 2.25.1

2 1

[PATCH -next v2] ALSA: pcm: fix undefined behavior in bit shift for SNDRV_PCM_RATE_KNOT
by Baisong Zhong 23 Nov '22

23 Nov '22

Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in sound/core/pcm_native.c:2676:21 left shift of 1 by 31 places cannot be represented in type 'int' ... Call Trace: <TASK> dump_stack_lvl+0x8d/0xcf ubsan_epilogue+0xa/0x44 __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 snd_pcm_open_substream+0x9f0/0xa90 snd_pcm_oss_open.part.26+0x313/0x670 snd_pcm_oss_open+0x30/0x40 soundcore_open+0x18b/0x2e0 chrdev_open+0xe2/0x270 do_dentry_open+0x2f7/0x620 path_openat+0xd66/0xe70 do_filp_open+0xe3/0x170 do_sys_openat2+0x357/0x4a0 do_sys_open+0x87/0xd0 do_syscall_64+0x34/0x80 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Baisong Zhong <zhongbaisong(a)huawei.com> --- v2: update all SNDRV_PCM_RATE_* to 1U to keep consistent -- include/sound/pcm.h | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/include/sound/pcm.h b/include/sound/pcm.h index 7b1a022910e8..27040b472a4f 100644 --- a/include/sound/pcm.h +++ b/include/sound/pcm.h @@ -106,24 +106,24 @@ struct snd_pcm_ops { #define SNDRV_PCM_POS_XRUN ((snd_pcm_uframes_t)-1) /* If you change this don't forget to change rates[] table in pcm_native.c */ -#define SNDRV_PCM_RATE_5512 (1<<0) /* 5512Hz */ -#define SNDRV_PCM_RATE_8000 (1<<1) /* 8000Hz */ -#define SNDRV_PCM_RATE_11025 (1<<2) /* 11025Hz */ -#define SNDRV_PCM_RATE_16000 (1<<3) /* 16000Hz */ -#define SNDRV_PCM_RATE_22050 (1<<4) /* 22050Hz */ -#define SNDRV_PCM_RATE_32000 (1<<5) /* 32000Hz */ -#define SNDRV_PCM_RATE_44100 (1<<6) /* 44100Hz */ -#define SNDRV_PCM_RATE_48000 (1<<7) /* 48000Hz */ -#define SNDRV_PCM_RATE_64000 (1<<8) /* 64000Hz */ -#define SNDRV_PCM_RATE_88200 (1<<9) /* 88200Hz */ -#define SNDRV_PCM_RATE_96000 (1<<10) /* 96000Hz */ -#define SNDRV_PCM_RATE_176400 (1<<11) /* 176400Hz */ -#define SNDRV_PCM_RATE_192000 (1<<12) /* 192000Hz */ -#define SNDRV_PCM_RATE_352800 (1<<13) /* 352800Hz */ -#define SNDRV_PCM_RATE_384000 (1<<14) /* 384000Hz */ - -#define SNDRV_PCM_RATE_CONTINUOUS (1<<30) /* continuous range */ -#define SNDRV_PCM_RATE_KNOT (1<<31) /* supports more non-continuos rates */ +#define SNDRV_PCM_RATE_5512 (1U<<0) /* 5512Hz */ +#define SNDRV_PCM_RATE_8000 (1U<<1) /* 8000Hz */ +#define SNDRV_PCM_RATE_11025 (1U<<2) /* 11025Hz */ +#define SNDRV_PCM_RATE_16000 (1U<<3) /* 16000Hz */ +#define SNDRV_PCM_RATE_22050 (1U<<4) /* 22050Hz */ +#define SNDRV_PCM_RATE_32000 (1U<<5) /* 32000Hz */ +#define SNDRV_PCM_RATE_44100 (1U<<6) /* 44100Hz */ +#define SNDRV_PCM_RATE_48000 (1U<<7) /* 48000Hz */ +#define SNDRV_PCM_RATE_64000 (1U<<8) /* 64000Hz */ +#define SNDRV_PCM_RATE_88200 (1U<<9) /* 88200Hz */ +#define SNDRV_PCM_RATE_96000 (1U<<10) /* 96000Hz */ +#define SNDRV_PCM_RATE_176400 (1U<<11) /* 176400Hz */ +#define SNDRV_PCM_RATE_192000 (1U<<12) /* 192000Hz */ +#define SNDRV_PCM_RATE_352800 (1U<<13) /* 352800Hz */ +#define SNDRV_PCM_RATE_384000 (1U<<14) /* 384000Hz */ + +#define SNDRV_PCM_RATE_CONTINUOUS (1U<<30) /* continuous range */ +#define SNDRV_PCM_RATE_KNOT (1U<<31) /* supports more non-continuos rates */ #define SNDRV_PCM_RATE_8000_44100 (SNDRV_PCM_RATE_8000|SNDRV_PCM_RATE_11025|\ SNDRV_PCM_RATE_16000|SNDRV_PCM_RATE_22050|\ -- 2.25.1

2 1

[PATCH] dt-bindings: Move fixed string node names under 'properties'
by Rob Herring 23 Nov '22

23 Nov '22

Fixed string node names should be under 'properties' rather than 'patternProperties'. Additionally, without beginning and end of line anchors, any prefix or suffix is allowed on the specified node name. These cases don't appear to want a prefix or suffix, so move them under 'properties'. In some cases, the diff turns out to look like we're moving some patterns rather than the fixed string properties. Signed-off-by: Rob Herring <robh(a)kernel.org> --- .../arm/tegra/nvidia,tegra20-pmc.yaml | 54 ++++++++-------- .../bindings/regulator/ti,tps65219.yaml | 14 ++-- .../bindings/sound/tlv320adcx140.yaml | 64 +++++++++---------- 3 files changed, 66 insertions(+), 66 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml index 7fd8d47b1be4..4a00593b9f7f 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml @@ -123,6 +123,33 @@ properties: some PLLs, clocks and then brings up CPU0 for resuming the system. + core-supply: + description: + Phandle to voltage regulator connected to the SoC Core power rail. + + core-domain: + type: object + description: | + The vast majority of hardware blocks of Tegra SoC belong to a + Core power domain, which has a dedicated voltage rail that powers + the blocks. + + properties: + operating-points-v2: + description: + Should contain level, voltages and opp-supported-hw property. + The supported-hw is a bitfield indicating SoC speedo or process + ID mask. + + "#power-domain-cells": + const: 0 + + required: + - operating-points-v2 + - "#power-domain-cells" + + additionalProperties: false + i2c-thermtrip: type: object description: @@ -300,33 +327,6 @@ patternProperties: additionalProperties: false - core-domain: - type: object - description: | - The vast majority of hardware blocks of Tegra SoC belong to a - Core power domain, which has a dedicated voltage rail that powers - the blocks. - - properties: - operating-points-v2: - description: - Should contain level, voltages and opp-supported-hw property. - The supported-hw is a bitfield indicating SoC speedo or process - ID mask. - - "#power-domain-cells": - const: 0 - - required: - - operating-points-v2 - - "#power-domain-cells" - - additionalProperties: false - - core-supply: - description: - Phandle to voltage regulator connected to the SoC Core power rail. - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/regulator/ti,tps65219.yaml b/Documentation/devicetree/bindings/regulator/ti,tps65219.yaml index 78be79930fda..78e64521d401 100644 --- a/Documentation/devicetree/bindings/regulator/ti,tps65219.yaml +++ b/Documentation/devicetree/bindings/regulator/ti,tps65219.yaml @@ -51,13 +51,6 @@ properties: where the board has a button wired to the pin and triggers an interrupt on pressing it. -patternProperties: - "^buck[1-3]-supply$": - description: Input supply phandle of one regulator. - - "^ldo[1-4]-supply$": - description: Input supply phandle of one regulator. - regulators: type: object description: | @@ -82,6 +75,13 @@ patternProperties: additionalProperties: false +patternProperties: + "^buck[1-3]-supply$": + description: Input supply phandle of one regulator. + + "^ldo[1-4]-supply$": + description: Input supply phandle of one regulator. + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml index ee698614862e..6b8214071115 100644 --- a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml +++ b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml @@ -109,38 +109,6 @@ properties: maximum: 7 default: [0, 0, 0, 0] - ti,asi-tx-drive: - type: boolean - description: | - When set the device will set the Tx ASI output to a Hi-Z state for unused - data cycles. Default is to drive the output low on unused ASI cycles. - -patternProperties: - '^ti,gpo-config-[1-4]$': - $ref: /schemas/types.yaml#/definitions/uint32-array - description: | - Defines the configuration and output driver for the general purpose - output pins (GPO). These values are pairs, the first value is for the - configuration type and the second value is for the output drive type. - The array is defined as <GPO_CFG GPO_DRV> - - GPO output configuration can be one of the following: - - 0 - (default) disabled - 1 - GPOX is configured as a general-purpose output (GPO) - 2 - GPOX is configured as a device interrupt output (IRQ) - 3 - GPOX is configured as a secondary ASI output (SDOUT2) - 4 - GPOX is configured as a PDM clock output (PDMCLK) - - GPO output drive configuration for the GPO pins can be one of the following: - - 0d - (default) Hi-Z output - 1d - Drive active low and active high - 2d - Drive active low and weak high - 3d - Drive active low and Hi-Z - 4d - Drive weak low and active high - 5d - Drive Hi-Z and active high - ti,gpio-config: description: | Defines the configuration and output drive for the General Purpose @@ -183,6 +151,38 @@ patternProperties: maximum: 15 default: [2, 2] + ti,asi-tx-drive: + type: boolean + description: | + When set the device will set the Tx ASI output to a Hi-Z state for unused + data cycles. Default is to drive the output low on unused ASI cycles. + +patternProperties: + '^ti,gpo-config-[1-4]$': + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + Defines the configuration and output driver for the general purpose + output pins (GPO). These values are pairs, the first value is for the + configuration type and the second value is for the output drive type. + The array is defined as <GPO_CFG GPO_DRV> + + GPO output configuration can be one of the following: + + 0 - (default) disabled + 1 - GPOX is configured as a general-purpose output (GPO) + 2 - GPOX is configured as a device interrupt output (IRQ) + 3 - GPOX is configured as a secondary ASI output (SDOUT2) + 4 - GPOX is configured as a PDM clock output (PDMCLK) + + GPO output drive configuration for the GPO pins can be one of the following: + + 0d - (default) Hi-Z output + 1d - Drive active low and active high + 2d - Drive active low and weak high + 3d - Drive active low and Hi-Z + 4d - Drive weak low and active high + 5d - Drive Hi-Z and active high + required: - compatible - reg -- 2.35.1

3 3

[PATCH] ALSA: rawmidi: fix infoleak in snd_rawmidi_ioctl_status_compat64
by Xiaolong Huang 22 Nov '22

22 Nov '22

The compat_status is declared off of the stack, so it needs to be zeroed out before copied back to userspace to prevent any unintentional data leakage. Signed-off-by: Xiaolong Huang <butterflyhuangxx(a)gmail.com> --- sound/core/rawmidi_compat.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/core/rawmidi_compat.c b/sound/core/rawmidi_compat.c index 68a93443583c..6afa68165b17 100644 --- a/sound/core/rawmidi_compat.c +++ b/sound/core/rawmidi_compat.c @@ -80,6 +80,7 @@ static int snd_rawmidi_ioctl_status_compat64(struct snd_rawmidi_file *rfile, if (err < 0) return err; + memset(&compat_status, 0, sizeof(compat_status)); compat_status = (struct compat_snd_rawmidi_status64) { .stream = status.stream, .tstamp_sec = status.tstamp_sec, base-commit: eb7081409f94a9a8608593d0fb63a1aa3d6f95d8 -- 2.25.1

1 0

[PATCH 0/3] ASoC: Intel: add Dell SKU 0C11 support
by Bard Liao 22 Nov '22

22 Nov '22

Add Dell SKU 0C11 support with rt1318 codec. Gongjun Song (3): ASoC: intel: sof_sdw: add rt1318 codec support. ASoC: Intel: sof_sdw: Add support for SKU 0C11 product ASoC: Intel: soc-acpi: add SKU 0C11 SoundWire configuration sound/soc/intel/boards/Kconfig | 1 + sound/soc/intel/boards/Makefile | 4 +- sound/soc/intel/boards/sof_sdw.c | 17 +++ sound/soc/intel/boards/sof_sdw_common.h | 7 + sound/soc/intel/boards/sof_sdw_rt1318.c | 120 ++++++++++++++++++ .../intel/common/soc-acpi-intel-rpl-match.c | 48 +++++++ 6 files changed, 195 insertions(+), 2 deletions(-) create mode 100644 sound/soc/intel/boards/sof_sdw_rt1318.c -- 2.25.1

2 4