__snd_pcm_set_state() writes runtime->state under the PCM stream lock.
However, the OSS I/O functions snd_pcm_oss_write3(), snd_pcm_oss_read3(),
snd_pcm_oss_writev3() and snd_pcm_oss_readv3() read runtime->state
without holding the stream lock, only holding oss.params_lock (a
different mutex that does not synchronize with the stream lock).
Since __snd_pcm_set_state() is called from IRQ context (e.g.,
snd_pcm_period_elapsed -> snd_pcm_update_state -> __snd_pcm_xrun ->
snd_pcm_stop -> snd_pcm_post_stop) while the OSS read/write paths
run in process context, these are concurrent accesses that constitute
a data race.
Rather than using READ_ONCE()/WRITE_ONCE() barriers, introduce a
snd_pcm_get_state() helper that reads runtime->state under the stream
lock, matching the locking discipline used elsewhere in the PCM layer.
Also export snd_pcm_set_state() for completeness.
Use snd_pcm_get_state() in all four OSS I/O functions, caching the
result in a local variable where the same snapshot is used for
multiple comparisons to avoid taking the lock repeatedly.
Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
Link: https://patch.msgid.link/20260316085047.2876451-1-zzzccc427@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
convert_chmap_v3() translates UAC3 channel relationship values into
ALSA channel-map positions.
UAC3_CH_FRONT_WIDE_LEFT and UAC3_CH_FRONT_WIDE_RIGHT currently fall
back to SNDRV_CHMAP_UNKNOWN, although ALSA already provides matching
channel-map positions via SNDRV_CHMAP_FLW and SNDRV_CHMAP_FRW.
Map these two UAC3 positions to their ALSA equivalents and update the
comment to clarify that unsupported UAC3 channel relationships remain
reported as SNDRV_CHMAP_UNKNOWN.
No functional change for other channel relationships.
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Link: https://patch.msgid.link/20260311200010.103710-1-cassiogabrielcontato@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In i2sbus_resume(), skip devices with an empty codec list, which avoids
using an uninitialized 'sysclock_factor' in the 32-bit format path in
i2sbus_pcm_prepare().
In i2sbus_pcm_prepare(), replace two list_for_each_entry() loops with a
single list_first_entry() now that the codec list is guaranteed to be
non-empty by all callers.
Fixes: f3d9478b2c ("[ALSA] snd-aoa: add snd-aoa")
Cc: stable@vger.kernel.org
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Link: https://patch.msgid.link/20260310102921.210109-3-thorsten.blum@linux.dev
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch addresses a potential state inconsistency bug and optimizes
runtime performance:
1. Fix error handling in set_beep_amp():
Previously, beep_nid was assigned before adding kcontrols. If
kcontrol creation failed, the function returned error but left
beep_nid set, causing inconsistent driver state. Moved the
assignment to the end of the function.
2. Optimize senary_auto_turn_eapd():
Removed the redundant snd_hda_query_pin_caps() check inside the
loop. The target pins are sourced from spec->eapds, which is
strictly filtered during the initial parse phase. Checking
capabilities again during every mute/unmute hook is unnecessary
overhead.
Signed-off-by: wangdicheng <wangdicheng@kylinos.cn>
Link: https://patch.msgid.link/20260310023649.155858-1-wangdich9700@163.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Adapt the already implemented support for the Studio 1824c
audio interface to the predecessor Studio 1824.
Basically just a change adding the
different hardware ID in the relevant places.
Tested as much as possible.
All implemented functionality seemingly works.
Signed-off-by: Frederic Popp <frederic.l.popp@t-online.de>
Link: https://patch.msgid.link/20260308153334.50433-2-frederic.l.popp@t-online.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Remove snd_usb_get_string() and use the manufacturer and product strings
stored in struct usb_device directly to match quirk table entries. Their
NULLity can be checked to determine if the device has no these strings.
This simplifies the code a lot.
Meanwhile, allow quirk table entries to match "no string" explicitly, and
add appropriate comments to show the expected usages of
DEVICE_STRING_FLG() and VENDOR_STRING_FLG(). These changes are tiny and
doesn't form another separate patch, so that back-and-forth changes can
be avoided.
Suggested-by: Terry Junge <linuxsound@cosmicgizmosystems.com>
Link: https://lore.kernel.org/r/b59da54a-9c80-4212-a337-c5ea98da52d1@cosmicgizmosystems.com
Signed-off-by: Rong Zhang <i@rong.moe>
Link: https://patch.msgid.link/20260305174711.1106324-1-i@rong.moe
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The USB core already prepares the strings for manufacturer, product
and serial number, and we don't have to extract the string at each
time. Replace the manual usb_string() calls with the corresponding
pointers in struct usb_dev as a code cleanup.
Link: https://patch.msgid.link/20260305130426.975604-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Port the essential hardware initialization logic from the vendor driver
and introduce the standard HDA fixup framework to handle different
machine configurations.
Key changes:
1. Add hardware init verbs:
- Implement `senary_init_verb` to send the vendor-specific
initialization sequence required by the SN6186 chip.
- Override pin capabilities for Node 0x19 to ensure proper headset
microphone support.
2. Introduce fixup framework:
- Define a default pin configuration table (`senary_pincfg_default`)
to provide a fallback for devices with invalid BIOS configurations.
- Establish a quirk table structure for future machine-specific
fixes.
- Since the standard quirk matching relies on Subsystem IDs, we
manually apply the default fixup if `snd_hda_pick_fixup` does not
find a specific match.
This ensures the chip is correctly initialized during probe and resume,
and provides a scalable mechanism for supporting specific hardware
quirks.
Signed-off-by: wangdicheng <wangdicheng@kylinos.cn>
Link: https://patch.msgid.link/20260304070219.450083-1-wangdich9700@163.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
MV-SILICON is a SoC manufacturer producing multifunctional audio SoCs.
Many devices built on top of their SDK share a common quirk that the
Playback and Capture mixers use linear volume with val = 0/4096/1.
The SDK seems to always report "MV-SILICON" for manufacturer string.
Hence, match it so that we don't need to define quirk table entries
separately for each devices. The "val = 0/4096/1" pattern is also
checked against before applying the quirk, in order that the quirk won't
accidentally break unseen variants.
Quirky device samples:
usb 7-1: New USB device found, idVendor=1235, idProduct=0003, bcdDevice= 1.00
usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 7-1: Product: G1
usb 7-1: Manufacturer: MV-SILICON
usb 7-1: SerialNumber: 20190808
usb 7-1: New USB device found, idVendor=1235, idProduct=0003, bcdDevice= 1.00
usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 7-1: Product: mvsilicon B1 usb audio
usb 7-1: Manufacturer: MV-SILICON
usb 7-1: SerialNumber: 20190808
usb 5-1.4: New USB device found, idVendor=8888, idProduct=1719, bcdDevice= 1.00
usb 5-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 5-1.4: Product: HF310 USB Audio
usb 5-1.4: Manufacturer: MV-SILICON
usb 5-1.4: SerialNumber: 20190808
usb 7-1: New USB device found, idVendor=2717, idProduct=5086, bcdDevice= 1.00
usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 7-1: Product: Redmi 电脑音箱
usb 7-1: Manufacturer: MV-SILICON
usb 7-1: SerialNumber: 20190808
usb 2-1.2: New USB device found, idVendor=3142, idProduct=a601, bcdDevice= 1.00
usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-1.2: Product: fifine Microphone
usb 2-1.2: Manufacturer: MV-SILICON
usb 2-1.2: SerialNumber: 20190808
* https://forum.ubuntu-it.org/viewtopic.php?t=659345
Signed-off-by: Rong Zhang <i@rong.moe>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260303194805.266158-9-i@rong.moe
Hotone Audio Pulze Mini is a modeling amplifier with UAC interface. Its
Playback and Capture mixers use linear volume with val = 0/100/1.
Add a quirk table entry matching VID/PID=0x84ef/0x0082 and applying
linear volume quirk flags, so that it can work properly.
Quirky device sample:
usb 7-1: New USB device found, idVendor=84ef, idProduct=0082, bcdDevice= 1.03
usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 7-1: Product: Pulze Mini
usb 7-1: Manufacturer: Hotone Audio
usb 7-1: SerialNumber: 20240807
Signed-off-by: Rong Zhang <i@rong.moe>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260303194805.266158-8-i@rong.moe
Some quirky devices tune their volume by linearly tuning the voltage
level (linear volume). In other words, such devices has a linear TLV
mapping of DECLARE_TLV_DB_LINEAR(scale, TLV_DB_GAIN_MUTE, 0).
Add quirk flags MIXER_PLAYBACK_LINEAR_VOL and MIXER_CAPTURE_LINEAR_VOL
to represent this case respectively for playback and capture mixers.
No functional change intended.
Signed-off-by: Rong Zhang <i@rong.moe>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260303194805.266158-7-i@rong.moe
MV-SILICON is a SoC manufacturer producing multifunctional audio SoCs.
Many budget-oriented OEM devices are built on top of them. However, some
of them are just too budget-constrained that their manufacturers didn't
even have a USB VID and simply picked a random VID.
Some OEMs unfortunately picked the VID of Focusrite Novation (0x1235),
resulting in VID conflicts as we had defined a VENDOR_FLG() for the
latter.
Add a VENDOR_STRING_FLG() for MV-SILICON to stop the matching procedure
for these quirky devices, so that quirk flags for Focusrite Novation
won't be accidentally applied on them.
Quirky device samples:
usb 7-1: New USB device found, idVendor=1235, idProduct=0003, bcdDevice= 1.00
usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 7-1: Product: G1
usb 7-1: Manufacturer: MV-SILICON
usb 7-1: SerialNumber: 20190808
usb 7-1: New USB device found, idVendor=1235, idProduct=0003, bcdDevice= 1.00
usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 7-1: Product: mvsilicon B1 usb audio
usb 7-1: Manufacturer: MV-SILICON
usb 7-1: SerialNumber: 20190808
usb 1-1.2: New USB device found, idVendor=1235, idProduct=0002, bcdDevice= 1.00
usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=...
usb 1-1.2: Product: V8
usb 1-1.2: Manufacturer: MV-SILICON
usb 1-1.2: SerialNumber: ...
* https://github.com/linuxhw/Dmesg/blob/main/Desktop/Others/Intel/Intel%20X79/96ED1CC44499/LINUXMINT-19.3/5.0.0-32-GENERIC/X86_64/5BE1E4C74C#L1122
usb 2-1.6: New USB device found, idVendor=1235, idProduct=0002, bcdDevice= 1.00
usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=...
usb 2-1.6: Product: V9
usb 2-1.6: Manufacturer: MV-SILICON
usb 2-1.6: SerialNumber: ...
* https://github.com/linuxhw/Dmesg/blob/main/Desktop/Hewlett-Packard/ProLiant/ProLiant%20ML110%20G6/79B1D707316A/KUBUNTU-21.04/5.11.0-33-GENERIC/X86_64/A43F59C4AB#L1009
Signed-off-by: Rong Zhang <i@rong.moe>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260303194805.266158-6-i@rong.moe
Some quirky devices do not have a unique VID/PID. Matching them using
DEVICE_FLG() or VENDOR_FLG() may result in conflicts.
Add two new macros DEVICE_STRING_FLG() and VENDOR_STRING_FLG() to match
USB string descriptors (manufacturer and/or product) in addition to VID
and/or PID, so that we can deconflict these devices safely.
No functional change intended.
Signed-off-by: Rong Zhang <i@rong.moe>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260303194805.266158-5-i@rong.moe
Currently the volume range check is only meant to discover quirky
microphone on webcam devices and facing these issues:
- The check is only meaningful for dB volume, but it doesn't check if
the TLV callback is the corresponding one
- A common quirky pattern "val = 0/100/1" doesn't trigger any warning
- Some modern devices trigger the check, but they are legit
- The warning message doesn't apply to some quirky messages with linear
volume
- The term "range" in the warning message is confusing. At readers'
first glance it should be (max - min), but it turns out to be
((max - min) / res)
Solve these issues by improving the checking logic to:
- Ignore mixers with non-dB TLV
- Warn on unlikely small volume ranges (max - min < 256)
- Add some heuristics to determine if the volume range is unlikely big
- Rephrase the warning message to mention linear volume
- Rephrase the warning message in correct wording
Signed-off-by: Rong Zhang <i@rong.moe>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260303194805.266158-4-i@rong.moe
When a potentially insane volume range is found, the volume control
parameters will be printed in WARN level instead of DEBUG level.
Currently, it's done by emitting a open-coded usb_audio_warn() in the
corresponding check.
The following changes are about to add more checks against volumen
ranges. As the first step, extract the current check logic into a helper
function to improve readability.
No functional change intended.
Signed-off-by: Rong Zhang <i@rong.moe>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260303194805.266158-3-i@rong.moe
UAC uses 2 bytes to store volume values, so the maximum volume range is
0xFFFF (65535, val = -32768/32767/1).
The reverted commit bumpped the range of triggering the warning to >
65535, effectively making the range check a no-op. It didn't fix
anything but covered any potential problems and deviated from the
original intention of the range check.
This reverts commit 6b971191fc.
Fixes: 6b971191fc ("ALSA: usb: Increase volume range that triggers a warning")
Cc: stable@vger.kernel.org
Signed-off-by: Rong Zhang <i@rong.moe>
Acked-by: Arun Raghavan <arunr@valvesoftware.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260303194805.266158-2-i@rong.moe
The driver sets spec->gen.own_eapd_ctl to take manual control of the
EAPD (External Amplifier). However, senary_init does not turn on the
EAPD, while senary_shutdown turns it off.
Since the generic driver skips EAPD handling when own_eapd_ctl is set,
the EAPD remains off after initialization (e.g., after resume), leaving
the codec in a non-functional state.
Explicitly call senary_auto_turn_eapd in senary_init to ensure the EAPD
is enabled and the codec is functional.
Signed-off-by: wangdicheng <wangdicheng@kylinos.cn>
Link: https://patch.msgid.link/20260303081516.583438-1-wangdich9700@163.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Replace the hardcoded GPIO node ID (0x01) with codec->core.afg.
This follows the standard HDA driver practice and makes the driver
more robust against different hardware configurations.
Signed-off-by: wangdicheng <wangdicheng@kylinos.cn>
Link: https://patch.msgid.link/20260303054242.318062-1-wangdich9700@163.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
'struct codec_connection' are not modified in this driver.
Constifying these structures moves some data to a read-only section, so
increases overall security.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
10034 3392 12 13438 347e sound/aoa/fabrics/layout.o
After:
=====
text data bss dec hex filename
10370 3040 12 13422 346e sound/aoa/fabrics/layout.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://patch.msgid.link/4009c337cc1a1a57795562279270c03687973b3b.1772138640.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The put() operation is expected to return:
1) 0 on success if no changes were made
2) 1 on success if changes were made
3) error code otherwise
Currently 2) is usually ignored when writing control-operations. While
forcing compliance is not an option right now, make it easier for
developers to adhere to the expectations and notice problems by logging
them when CONFIG_SND_CTL_DEBUG is enabled.
Due to large size of struct snd_ctl_elem_value, 'value_buf' is provided
as a reusable buffer for kctl->put() verification. This prevents
exhausting the stack when verifying the operation.
>From user perspective, patch introduces a new trace/events category
'snd_ctl' containing a single 'snd_ctl_put' event type. Log sample:
amixer-1086 [003] ..... 8.035939: snd_ctl_put: success: expected=0, actual=0 for ctl numid=1, iface=MIXER, name='Master Playback Volume', index=0, device=0, subdevice=0, card=0
amixer-1087 [003] ..... 8.938721: snd_ctl_put: success: expected=1, actual=1 for ctl numid=1, iface=MIXER, name='Master Playback Volume', index=0, device=0, subdevice=0, card=0
amixer-1088 [003] ..... 9.631470: snd_ctl_put: success: expected=1, actual=1 for ctl numid=1, iface=MIXER, name='Master Playback Volume', index=0, device=0, subdevice=0, card=0
amixer-1089 [000] ..... 9.636786: snd_ctl_put: fail: expected=1, actual=0 for ctl numid=5, iface=MIXER, name='Loopback Mute', index=0, device=0, subdevice=0, card=0
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260224205619.584795-1-cezary.rojewski@intel.com
The use of snprintf() may cause a warning with W=1 due to the possibly
truncated string. As the truncation doesn't really matter (and won't
happen practically) in the case of dice driver, just shut it up by
replacing with scnprintf().
Link: https://patch.msgid.link/20260227155705.1557224-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On TAS2781, if the Speaker calibrated impedance is lower than default
value hard-coded inside the TAS2781, it will cuase vol lower than
normal. In order to fix this issue, the parameter of SineGainI need
updating.
Signed-off-by: Shenghao Ding <shenghao-ding@ti.com>
Tested-by: Matthew Schwartz <matthew.schwartz@linux.dev>
Link: https://patch.msgid.link/20260227144641.1243-1-shenghao-ding@ti.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Setting up the interface when suspended/resumeing fail on this card.
Adding a reset and delay quirk will eliminate this problem.
usb 1-1: New USB device found, idVendor=0624, idProduct=3d3f
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: AB13X USB Audio
usb 1-1: Manufacturer: Generic
usb 1-1: SerialNumber: 20210726905926
Signed-off-by: Lianqin Hu <hulianqin@vivo.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/TYUPR06MB621795D087BF2D594027C235D273A@TYUPR06MB6217.apcprd06.prod.outlook.com
HP/Speaker auto-detect (VNID_HP_ASEL) has been off by default for every
CA0132 device since the driver was added in 2012. vnode_lswitch is
always initialized to 0 in ca0132_init_chip(), and no quirk or other
code path enables it. As a result, headphone jack detection works only
after the user manually turns on "HP/Speaker Auto Detect" in alsamixer,
which is not obvious on laptops with combo jacks (e.g. Google Link,
Alienware).
Change the default to follow the headphone pin config: if the pin verb
has presence detect enabled (no AC_DEFCFG_MISC_NO_PRESENCE) and the
codec supports it (AC_PINCAP_PRES_DETECT), enable HP_ASEL by default.
This lets firmware (coreboot, UEFI, etc.) express whether the headphone
jack supports insertion detection. Devices with combo jacks can default
to auto-detect; devices with fixed/no jack leave it off.
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Link: https://patch.msgid.link/20260226163055.825167-1-matt.devillier@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The kernel-doc comments for sdca_irq_request() contained some typos
that lead to build warnings with W=1. Let's correct them.
Fixes: b126394d9e ("ASoC: SDCA: Generic interrupt support")
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260226154753.1083320-1-tiwai@suse.de
We don't process this driver code for kernel-doc, and the "/**" marker
leads to warnings with W=1 builds. Drop the superfluous markers, and
also fix the invalid mark up, too.
Link: https://patch.msgid.link/20260226155456.1092186-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
At fixing the memory leak of xfer buffer, we forgot to update the
corresponding comment, too. This resulted in a kernel-doc warning
with W=1. Let's correct it.
Fixes: 5c7ef50012 ("ALSA: qc_audio_offload: avoid leaking xfer_buf allocation")
Link: https://patch.msgid.link/20260226154414.1081568-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We don't process USB-audio driver code for kernel-doc, and the "/**"
marker leads to warnings with W=1 builds. Drop the superfluous
markers.
Link: https://patch.msgid.link/20260226154414.1081568-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Since commit af37511305 ("firmware: cs_dsp: Don't require client to
provide a struct cs_dsp_client_ops") the client doesn't have to provide
a struct cs_dsp_client_ops. So remove the dummy cs_dsp_client_ops.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260226124115.1811187-1-rf@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
One quirk and a fix for handling of exotic peripherals on cs42l43.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmmgOOkACgkQJNaLcl1U
h9BmNQf/U42WZyfPuTmtNH8YvPIm3UqE2kyzYhE37FvM3/JUrz34fiL0pB4SeUHE
FR2UQepV6k5jQtkLbzRuLAQnAeast5UB8QrYwc4iPvu7O90GzQeINBX3gN7Q4tuq
FDWdO+yANrWruz4WC5OVxoHhEkYTvwTIwySMlansrP6i8mxDazi6Nbf+adzI9rLM
f0CXUoT/Wn5+XX0L4lJe1E1Tiuzy/be6rKWvTvO91zQPINbYmKwDe3AJpaMq27Kb
k6tyVE+eIY9XFHLGD4R4ojr252wm/4JplxQeOSCU7SNQGDiTqSx+jHZRp7gEJ8qx
NY7QnD976usyenVCEBLbx0OdiDhtnw==
=2O9T
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v7.0-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v7.0
One quirk and a fix for handling of exotic peripherals on cs42l43.
In cs35l56_hda_posture_put() assign ucontrol->value.integer.value[0] to
a long instead of an unsigned long. ucontrol->value.integer.value[0] is
a long.
This fixes the sparse warning:
sound/hda/codecs/side-codecs/cs35l56_hda.c:256:20: warning: unsigned value
that used to be signed checked against zero?
sound/hda/codecs/side-codecs/cs35l56_hda.c:252:29: signed value source
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Fixes: 73cfbfa9ca ("ALSA: hda/cs35l56: Add driver for Cirrus Logic CS35L56 amplifier")
Link: https://patch.msgid.link/20260226111728.1700431-1-rf@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The entry of the validators table for UAC3 AC header descriptor is
defined with the wrong protocol version UAC_VERSION_2, while it should
have been UAC_VERSION_3. This results in the validator never matching
for actual UAC3 devices (protocol == UAC_VERSION_3), causing their
header descriptors to bypass validation entirely. A malicious USB
device presenting a truncated UAC3 header could exploit this to cause
out-of-bounds reads when the driver later accesses unvalidated
descriptor fields.
The bug was introduced in the same commit as the recently fixed UAC3
feature unit sub-type typo, and appears to be from the same copy-paste
error when the UAC3 section was created from the UAC2 section.
Fixes: 57f8770620 ("ALSA: usb-audio: More validations of descriptor units")
Cc: <stable@vger.kernel.org>
Signed-off-by: Jun Seo <jun.seo.93@proton.me>
Link: https://patch.msgid.link/20260226010820.36529-1-jun.seo.93@proton.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The default bdl_pos_adj of 32 for Nvidia HDA controllers is
insufficient on GA102 (and likely other recent Nvidia GPUs) after S3
suspend/resume. The controller's DMA timing degrades after resume,
causing premature IRQ detection in azx_position_ok() which results in
silent HDMI/DP audio output despite userspace reporting a valid
playback state and correct ELD data.
Increase bdl_pos_adj to 64 for AZX_DRIVER_NVIDIA, matching the value
already used by Intel Apollo Lake for the same class of timing issue.
Cc: stable@vger.kernel.org
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221069
Suggested-by: Charalampos Mitrodimas <charmitro@posteo.net>
Signed-off-by: Panagiotis Foliadis <pfoliadis@posteo.net>
Link: https://patch.msgid.link/20260225-nvidia-audio-fix-v1-1-b1383c37ec49@posteo.net
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Replace the remaining with inclusive terms; it's only this function
name we overlooked at the previous conversion.
Fixes: 53837b4ac2 ("ALSA: usb-audio: Replace slave/master terms")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260225085233.316306-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Although DIYINHK USB Audio 2.0 (ID 20b1:2009) shows the implicit
feedback source for the capture stream, this would cause several
problems for the playback. Namely, the device can get wMaxPackSize
1024 for 24/32 bit format with 6 channels, and when a high sample rate
like 352.8kHz or 384kHz is played, the packet size overflows the max
limit. Also, the device has another two playback altsets, and those
aren't properly handled with the implicit feedback.
Since the device has been working well even before introducing the
implicit feedback, we can assume that it works fine in the async mode.
This patch adds the explicit skip of the implicit fb detection to make
the playback running in the async mode.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260225085233.316306-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When the packet sizes are taken from the capture stream in the
implicit feedback mode, the sizes might be larger than the upper
boundary defined by the descriptor. As already done for other
transfer modes, we have to cap the sizes accordingly at sending,
otherwise this would lead to an error in USB core at submission of
URBs.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260225085233.316306-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We calculate the possible packet sizes beforehand for adaptive and
synchronous endpoints, but we didn't take care of the max frame size
for those pre-calculated values. When a device or a bus limits the
packet size, a high sample rate or a high number of channels may lead
to the packet sizes that are larger than the given limit, which
results in an error from the USB core at submitting URBs.
As a simple workaround, just add the sanity checks of pre-calculated
packet sizes to have the upper boundary of ep->maxframesize.
Fixes: f0bd62b640 ("ALSA: usb-audio: Improve frames size computation")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260225085233.316306-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The ASUS ExpertBook BM1503CDA (Ryzen 5 7535U, Barcelo-R) has an
internal DMIC connected through the AMD ACP (Audio CoProcessor)
but is missing from the DMI quirk table, so the acp6x machine
driver probe returns -ENODEV and no DMIC capture device is created.
Add the DMI entry so the internal microphone works out of the box.
Signed-off-by: Azamat Almazbek uulu <almazbek1608@gmail.com>
Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Link: https://patch.msgid.link/20260221114813.5610-1-almazbek1608@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
For some exotic peripherals the type detect can return a reserved value
of 0x4. This will currently return an error and not report anything to
user-space, update this to report the insert normally.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260223093616.3800350-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add QUIRK_FLAG_SKIP_CLOCK_SELECTOR for Focusrite devices.
During interface parsing, snd_usb_clock_find_source() reads the clock
selector value then writes it back unchanged. On Focusrite devices
this redundant write results in a ~300ms delay per altsetting, adding
~1.8s to probe time on a typical device with 6 altsettings.
Enabling SKIP_CLOCK_SELECTOR skips the redundant write-back.
Signed-off-by: Geoffrey D. Bennett <g@b4.vu>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/00e53ae0a508b41516b41833daa17823381a649c.1771594828.git.g@b4.vu
Add a quirk flag to skip the usb_set_interface(),
snd_usb_init_pitch(), and snd_usb_init_sample_rate() calls in
__snd_usb_parse_audio_interface(). These are redundant with
snd_usb_endpoint_prepare() at stream-open time.
Enable the quirk for Focusrite devices, as init_sample_rate(rate_max)
sets 192kHz during probing, which disables the internal mixer and Air
and Safe modes.
Fixes: 16f1f83844 ("Revert "ALSA: usb-audio: Drop superfluous interface setup at parsing"")
Signed-off-by: Geoffrey D. Bennett <g@b4.vu>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/65a7909b15f9feb76c2a6f4f8814c240ddc50737.1771594828.git.g@b4.vu
Remove QUIRK_FLAG_VALIDATE_RATES for Focusrite. With the previous
commit, focusrite_valid_sample_rate() produces correct rate tables
without USB probing.
QUIRK_FLAG_VALIDATE_RATES sends SET_CUR requests for each rate (~25ms
each) and leaves the device at 192kHz. This is a problem because that
rate: 1) disables the internal mixer, so outputs are silent until an
application opens the PCM and sets a lower rate, and 2) the Air and
Safe modes get disabled.
Fixes: 5963e52621 ("ALSA: usb-audio: Enable rate validation for Scarlett devices")
Signed-off-by: Geoffrey D. Bennett <g@b4.vu>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/09b9c012024c998c4ca14bd876ef0dce0d0b6101.1771594828.git.g@b4.vu
Replace the bLength == 10 max_rate check in
focusrite_valid_sample_rate() with filtering that also examines the
bmControls VAL_ALT_SETTINGS bit.
When VAL_ALT_SETTINGS is readable, the device uses strict
per-altsetting rate filtering (only the highest rate pair for that
altsetting is valid). When it is not readable, all rates up to
max_rate are valid.
For devices without the bLength == 10 Format Type descriptor extension
but with VAL_ALT_SETTINGS readable and multiple altsettings (only seen
in Scarlett 18i8 3rd Gen playback), fall back to the Focusrite
convention: alt 1 = 48kHz, alt 2 = 96kHz, alt 3 = 192kHz.
This produces correct rate tables for all tested Focusrite devices
(all Scarlett 2nd, 3rd, and 4th Gen, Clarett+, and Vocaster) using
only USB descriptors, allowing QUIRK_FLAG_VALIDATE_RATES to be removed
for Focusrite in the next commit.
Signed-off-by: Geoffrey D. Bennett <g@b4.vu>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/7e18c1f393a6ecb6fc75dd867a2c4dbe135e3e22.1771594828.git.g@b4.vu
Similar to other Samsung laptops, NT950QCT also requires the
ALC298_FIXUP_SAMSUNG_AMP quirk applied.
Cc: <stable@vger.kernel.org>
Signed-off-by: Juhyung Park <qkrwngud825@gmail.com>
Link: https://patch.msgid.link/20260222122609.281191-2-qkrwngud825@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
