fcp_ioctl_init() allocates its response buffer with kmalloc() and copies
the whole buffer back to userspace:
buf_size = init.step0_resp_size + init.step2_resp_size;
void *resp __free(kfree) =
kmalloc(buf_size, GFP_KERNEL);
...
if (copy_to_user(arg->resp, resp, buf_size))
return -EFAULT;
Nothing clears the buffer, and the only writer of its leading
step0_resp_size bytes is the step-0 control transfer:
err = snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0),
FCP_USB_REQ_STEP0,
USB_RECIP_INTERFACE | USB_TYPE_CLASS | USB_DIR_IN,
0, private->bInterfaceNumber,
step0_resp, private->step0_resp_size);
if (err < 0)
return err;
usb_fill_control_urb() does not set URB_SHORT_NOT_OK, so a short or
zero-length data stage completes with status 0 and snd_usb_ctl_msg()
returns a small actual_length. The only check is err < 0, so a short
transfer is accepted as success.
snd_usb_ctl_msg() copies the full size back unconditionally:
buf = kmemdup(data, size, GFP_KERNEL);
...
memcpy(data, buf, size);
Bytes the device never wrote are therefore restored into resp unchanged
and copied to userspace. step0_resp_size and step2_resp_size are each
validated only to 1..255, so the caller also picks the slab cache, from
kmalloc-8 up to kmalloc-512.
On 7.2.0-rc5 (arm64), device answering step 0 with a zero-length data
stage, s0 = s2 = 255:
# init_on_alloc off, no spray
step0 window [0,255): nonzero=94/255
000: 00 80 60 06 00 00 ff ff 18 00 00 00 57 01 ea 01
010: 08 78 22 13 00 00 ff ff a8 c4 5f 80 00 80 ff ff
# same kernel, kmalloc-512 pre-seeded with an 8-byte tag
step0 window [0,255): nonzero=219/255 tagbytes=232
# identical run, init_on_alloc=1
step0 window [0,255): nonzero=0/255 tagbytes=0
# all three runs
step2 window [255,510): device words matched=62/62
a8 c4 5f 80 00 80 ff ff is the little-endian kernel text address
ffff8000805fc4a8. The step-2 window is unaffected, so the disclosure is
exactly the step-0 region.
Zero the buffer, and require the step-0 transfer to deliver the full
step0_resp_size bytes so a short data stage is reported as an error.
Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
Fixes: 46757a3e7d ("ALSA: FCP: Add Focusrite Control Protocol driver")
Reported-by: Federico Kirschbaum <federico.kirschbaum@xbow.com>
Reported-by: Baul Lee <baul.lee@xbow.com>
Cc: stable@vger.kernel.org
Signed-off-by: Baul Lee <baul.lee@xbow.com>
Link: https://patch.msgid.link/20260805013804.38839-1-baul.lee@xbow.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
bcd2000_free_usb_related_resources() frees both URBs and leaves the
pointers behind:
usb_kill_urb(bcd2k->midi_out_urb);
usb_kill_urb(bcd2k->midi_in_urb);
usb_free_urb(bcd2k->midi_out_urb);
usb_free_urb(bcd2k->midi_in_urb);
The rawmidi device outlives that call. A substream that is still open
when the device is unplugged reaches bcd2000_midi_send() from the
trigger path on close. That function writes to the freed URB and then
hands it to the USB core:
bcd2k->midi_out_urb->transfer_buffer_length = BUFSIZE;
...
ret = usb_submit_urb(bcd2k->midi_out_urb, GFP_ATOMIC);
usb_kill_urb() does not stop a later submission either, so a submit that
races the disconnect can requeue the URB after it has been reaped.
midi_in_urb is exposed the same way: bcd2000_input_complete() resubmits
it from the completion handler.
KASAN on 7.2.0-rc5 (arm64):
BUG: KASAN: slab-use-after-free in bcd2000_midi_send [snd_bcd2000]
Write of size 4 at addr ffff00001827d388 by task bpoc/168
__asan_store4
bcd2000_midi_send [snd_bcd2000]
bcd2000_midi_output_trigger [snd_bcd2000]
snd_rawmidi_kernel_write1
close_substream.part.0
Freed by task 168:
usb_free_urb
bcd2000_disconnect [snd_bcd2000]
BUG: KASAN: slab-use-after-free in usb_submit_urb
Read of size 8 at addr ffff00001827d3b8 by task bpoc/168
Clear both pointers after freeing and test them on the paths that can
still run. Poison the URBs before freeing them: usb_poison_urb() waits
for a running completion handler and rejects any later submission, so
after it returns the input path is quiesced and only the rawmidi trigger
path can still reach bcd2000_midi_send(). No unpoison is needed; the
URBs are freed on the next line.
Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
Fixes: b47a22290d ("ALSA: MIDI driver for Behringer BCD2000 USB device")
Reported-by: Federico Kirschbaum <federico.kirschbaum@xbow.com>
Reported-by: Baul Lee <baul.lee@xbow.com>
Cc: stable@vger.kernel.org
Signed-off-by: Baul Lee <baul.lee@xbow.com>
Link: https://patch.msgid.link/20260805013428.38204-1-baul.lee@xbow.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
usb6fire_comm_receiver_handler() forwards a MIDI event using a length
byte the device supplies, with no bound and no check that the transfer
delivered that many bytes:
if (!urb->status) {
if (rt->receiver_buffer[0] == 0x10) /* midi in event */
if (midi_rt)
midi_rt->in_received(midi_rt,
rt->receiver_buffer + 2,
rt->receiver_buffer[1]);
}
receiver_buffer is a 64-byte kzalloc() buffer (COMM_RECEIVER_BUFSIZE), so
only 62 bytes follow the two-byte header. receiver_buffer[1] is a u8 the
device chooses, so a device that answers with 0x10 and a length of 0xFF
makes snd_rawmidi_receive() read 255 bytes starting two bytes into a
64-byte object. The bytes past the buffer are handed to userspace
through the rawmidi read path.
urb->actual_length is not consulted either, so a short transfer leaves
both the type byte and the length byte at their previous values and the
handler acts on stale data.
The receiver URB is submitted from usb6fire_comm_init() at probe, so the
read happens on plug with no user action; forwarding to userspace also
needs a MIDI input substream open, since usb6fire_midi_in_received()
only calls snd_rawmidi_receive() when rt->in is set.
KASAN on 7.2.0-rc5 (arm64), single packet from an emulated device:
BUG: KASAN: slab-out-of-bounds in snd_rawmidi_receive
Read of size 255 at addr ffff000009f64682 by task bash/183
__asan_memcpy
snd_rawmidi_receive
usb6fire_midi_in_received [snd_usb_6fire]
usb6fire_comm_receiver_handler [snd_usb_6fire]
Allocated by task 11:
usb6fire_comm_init [snd_usb_6fire]
usb6fire_chip_probe [snd_usb_6fire]
The buggy address is located 2 bytes inside of
allocated 64-byte region [ffff000009f64680, ffff000009f646c0)
Reject the event when the length exceeds the bytes that follow the
header, and require the transfer to have delivered the header plus that
many bytes. The receiver URB is submitted with a 64-byte
transfer_buffer_length, so a genuine device cannot deliver an event
longer than those 62 bytes and nothing valid is dropped.
Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
Fixes: c6d43ba816 ("ALSA: usb/6fire - Driver for TerraTec DMX 6Fire USB")
Reported-by: Federico Kirschbaum <federico.kirschbaum@xbow.com>
Reported-by: Baul Lee <baul.lee@xbow.com>
Cc: stable@vger.kernel.org
Signed-off-by: Baul Lee <baul.lee@xbow.com>
Link: https://patch.msgid.link/20260805013423.38175-1-baul.lee@xbow.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The fixed-size components field in SNDRV_CTL_IOCTL_CARD_INFO can be too
small on systems with many audio devices.
Keep the existing struct snd_ctl_card_info ABI intact and add a new
ioctl SNDRV_CTL_IOCTL_CARD_BYTES that carries a variable-length payload
selected by a type discriminator. The first defined type
SND_CTL_CARD_BTYPE_COMPONENTS returns the full components string. The
ioctl is designed to be reused for other variable-length card payloads
in the future.
The user-space caller may set data_allocated == 0 (or data == NULL) to
query the required length; otherwise the kernel copies the payload into
the user buffer and writes back the actual length in data_len.
When the legacy components field in struct snd_ctl_card_info is
truncated, '>' is written just before the NUL terminator to signal to
user-space that the full string is available via the new ioctl.
card->components is now dynamically allocated and grown in 32 byte
increments via krealloc(), capped at 512 bytes.
Link: https://github.com/alsa-project/alsa-lib/pull/494
Suggested-by: Jaroslav Kysela <perex@perex.cz>
Suggested-by: Takashi Iwai <tiwai@suse.com>
Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260720103505.1860399-2-mstrozek@opensource.cirrus.com
Lenovo Yoga Pro 7 15ASH11 and Legion 7 15ASH11 use the same audio
subsystem implementation and support only analog microphone.
Limit Amp-In Vals to 0x00 and 0x01 for the internal microphone to reduce
recording noise. Values 0x02 and 0x03 introduce significant noise on
them.
Fixes: 17065203e1 ("ALSA: hda/realtek:ALC269 fixup for Yoga Pro 7 15ASH11 mic mute LED")
Signed-off-by: Jackie Dong <xy-jackie@139.com>
Link: https://patch.msgid.link/20260804123637.21001-1-xy-jackie@139.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A temporary refcount management of a struct device can be done
gracefully with __clean(put_device) for avoiding potential leaks.
No functional change but just a code cleanup.
Cc: Shenghao Ding <shenghao-ding@ti.com>
Cc: Kevin Lu <kevin-lu@ti.com>
Cc: Baojun Xu <baojun.xu@ti.com>
Cc: Sen Wang <sen@ti.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260803140100.919071-2-tiwai@suse.de
A temporary refcount management of a struct device can be done
gracefully with __clean(put_device) for avoiding potential leaks.
No functional change but just a code cleanup.
Cc: Marco Giunta <marco_giunta@outlook.it>
Reviewed-by: Marco Giunta <marco_giunta@outlook.it>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260803140100.919071-1-tiwai@suse.de
The stream descriptor status register reports FIFO and descriptor
errors, but these are currently cleared silently along with the rest
of the interrupt status. Log them, rate-limited, so DMA problems are
visible instead of only manifesting as audible glitches.
Observed on some AMD GPU HDMI audio controllers under specific low power
circumstances.
Signed-off-by: Arun Raghavan <arunr@valvesoftware.com>
Cc: Arun Raghavan <arun@arunraghavan.net>
Link: https://patch.msgid.link/20260803-master-v1-1-9bcedb736978@valvesoftware.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALC285_FIXUP_ASUS_GA605K_I2C_SPEAKER2_TO_DAC1 and
ALC285_FIXUP_SPEAKER2_TO_DAC1 are exactly the same. Remove the former to
avoid redundancy.
Signed-off-by: Eric Naim <dnaim@cachyos.org>
Link: https://patch.msgid.link/20260803091102.107570-10-dnaim@cachyos.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALC294_FIXUP_ASUS_ALLY_SPEAKER is exactly the same as
ALC285_FIXUP_SPEAKER2_TO_DAC1. Remove the former to avoid redundancy.
Signed-off-by: Eric Naim <dnaim@cachyos.org>
Link: https://patch.msgid.link/20260803091102.107570-9-dnaim@cachyos.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Now that ALC285_FIXUP_YOGA_SPEAKER2_TO_DAC1 exists,
ALC285_FIXUP_SPEAKER2_TO_DAC1 can be unchained from
ALC269_FIXUP_THINKPAD_ACPI.
Signed-off-by: Eric Naim <dnaim@cachyos.org>
Link: https://patch.msgid.link/20260803091102.107570-8-dnaim@cachyos.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In preparation for unchaining ALC269_FIXUP_THINKPAD_ACPI from
ALC285_FIXUP_SPEAKER2_TO_DAC1, add
ALC285_FIXUP_YOGA_SPEAKER2_TO_DAC1 as a duplicate of
ALC285_FIXUP_SPEAKER2_TO_DAC1.
Signed-off-by: Eric Naim <dnaim@cachyos.org>
Link: https://patch.msgid.link/20260803091102.107570-7-dnaim@cachyos.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Now that ALC269_FIXUP_LIMIT_INT_MIC_BOOST is no longer chained to
ALC269_FIXUP_THINKPAD_ACPI, ALC269_FIXUP_STARLABS_LIMIT_INT_MIC_BOOST and
ALC269_FIXUP_LIMIT_INT_MIC_BOOST are both identical. Remove the former
and replace it with the latter to avoid redundancy.
Signed-off-by: Eric Naim <dnaim@cachyos.org>
Link: https://patch.msgid.link/20260803091102.107570-6-dnaim@cachyos.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Now that ALC269_FIXUP_LIMIT_INT_MIC_BOOST is no longer chained to
ALC269_FIXUP_THINKPAD_ACPI, ALC233_FIXUP_INTEL_NUC8_BOOST and
ALC269_FIXUP_LIMIT_INT_MIC_BOOST are both identical. Remove the former
and replace it with the latter to avoid redundancy.
Signed-off-by: Eric Naim <dnaim@cachyos.org>
Link: https://patch.msgid.link/20260803091102.107570-5-dnaim@cachyos.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
After creating ALC269_FIXUP_THINKPAD_LIMIT_INT_MIC_BOOST,
ALC269_FIXUP_LIMIT_INT_MIC_BOOST no longer needs to be chained to
ALC269_FIXUP_THINKPAD_ACPI and can be a generic quirk usable by all
devices.
Signed-off-by: Eric Naim <dnaim@cachyos.org>
Link: https://patch.msgid.link/20260803091102.107570-4-dnaim@cachyos.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add ALC269_FIXUP_THINKPAD_LIMIT_INT_MIC_BOOST, identical to
ALC269_FIXUP_LIMIT_INT_MIC_BOOST.
This prepares for removing the chain from
ALC269_FIXUP_LIMIT_INT_MIC_BOOST.
Signed-off-by: Eric Naim <dnaim@cachyos.org>
Link: https://patch.msgid.link/20260803091102.107570-3-dnaim@cachyos.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALC294_FIXUP_CS35L41_I2C_2 is exactly the same as
ALC287_FIXUP_CS35L41_I2C_2, so remove the former and move existing
devices that previously used ALC294_FIXUP_CS35L41_I2C_2 to
ALC287_FIXUP_CS35L41_I2C_2.
Signed-off-by: Eric Naim <dnaim@cachyos.org>
Link: https://patch.msgid.link/20260803091102.107570-2-dnaim@cachyos.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The UAC mixer of the Logitech PRO X 2 LIGHTSPEED has broken mixer
GET_CUR behavior but otherwise works fine.
Add a quirk table entry matching VID/PID=0x046d/0x0af7 and apply the
MIXER_GET_CUR_BROKEN quirk flag to make the mixer usable again.
Quirky device sample (after applying the quirk flag):
usb 3-2.1: New USB device found, idVendor=046d, idProduct=0af7, bcdDevice= 1.00
usb 3-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-2.1: Product: PRO X 2 LIGHTSPEED
usb 3-2.1: Manufacturer: Logitech
usb 3-2.1: SerialNumber: 0000000000000000
usb 3-2.1: 2:0: broken mixer GET_CUR (-18944/0/256 => -2662)
usb 3-2.1: 6:0: broken mixer GET_CUR (-18944/0/256 => 0)
Fixes: 86aa1ea1f1 ("ALSA: usb-audio: Do not expose sticky mixers")
Suggested-by: Brian van den Berg <faxuser@proton.me>
Reported-by: Brian van den Berg <faxuser@proton.me>
Link: https://lore.kernel.org/all/370007e6-b73b-4bfc-8410-a860781c7ad7@proton.me/
Signed-off-by: Rong Zhang <i@rong.moe>
Link: https://patch.msgid.link/20260731-uac-lg-pro-x-2-ls-v1-1-268eaefe66ab@rong.moe
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The firmware of the Minisforum AI X1 Pro leaves the headphone jack detector
reset bit asserted on its ALC245 codec. As a result, pin sense on NID 0x21
always reports the jack as absent.
Clear only the Reset HP JD bit during codec initialization. Preserve the
remaining coefficient bits. This makes pin sense and the generic HDA
auto-mute logic work normally. Apply the fixup at INIT to also reapply the
setting after codec reinitialization and resume.
Tested on a Minisforum AI X1 Pro with codec 0x10ec0245 and subsystem
0x1f4cb020 using Ubuntu 26.04 kernel 7.0.0-28-generic.
Signed-off-by: Jeremie Pardou <jrmi@jeremiez.net>
Link: https://patch.msgid.link/20260802194832.49393-1-jrmi@jeremiez.net
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The LG gram 16 (16Z90TR, SSID 1854:0554) drives its internal speakers
through Samsung-style smart amplifiers on an ALC298. Nothing initialises
them, so the internal speakers are silent after a cold boot, while
headphones, HDMI and the microphones work.
A warm reset leaves the amps initialised, which masks the problem:
rebooting gives working speakers, a cold boot does not, with a
bit-identical kernel log in both cases. Dumping the codec's processing
coefficients in the two states shows the difference confined to COEF
0x22/0x23/0x25/0x26. COEF 0x22, the amp select register written by
alc298_samsung_v2_init_amps(), reads 0x39 when the speakers work and
0x00 after a cold boot. 0x39 is the second entry of
alc298_samsung_v2_amp_desc_tbl[], so two amps are in use.
Verified with hda_model=alc298-samsung-amp-v2-2-amps, which selects the
same fixup: the internal speakers work from a cold boot and COEF 0x22
reads 0x39.
Signed-off-by: Aaron Fan <aaronfan404@gmail.com>
Link: https://patch.msgid.link/20260802055818.7389-1-aaronfan404@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The ASUS VivoBook M515DA/X515DAP (subsystem ID 1043:1e3e)
requires the ALC256_FIXUP_ASUS_MIC_NO_PRESENCE fixup to
enable the internal microphone.
Without this quirk, the internal microphone captures only
silence under Linux, while it works correctly under Windows.
The fix has been verified on real hardware.
Tested on an ASUS VivoBook M515DA/X515DAP running Linux Mint
22.3 with Ubuntu HWE kernel 7.0.0-28.
Signed-off-by: Mauricio Orozco <maudob@live.com>
Link: https://patch.msgid.link/20260730033506.8958-1-mauoro3@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
tas2781_read_acpi() gets a reference to the matching ACPI device and then
looks up its first physical device node. After taking a reference to the
physical device, it immediately drops the ACPI device reference.
However, every later failure jumps to an error path that drops the ACPI
device reference a second time. This unbalances the reference count and
may prematurely release the ACPI device.
In addition, acpi_get_first_physical_node() may return NULL. Without a
check, the driver passes the NULL physical device to the property helper
calls and may dereference it.
Return -ENODEV when no physical device is associated with the ACPI node,
and remove the duplicate acpi_dev_put() from the common error path.
Fixes: bb5f86ea50 ("ALSA: hda/tas2781: Add tas2781 hda SPI driver")
Cc: stable@vger.kernel.org
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Link: https://patch.msgid.link/97EA8F29DA0D9AF7+20260731033554.949564-1-raoxu@uniontech.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In loopback_hrtimer_stop(), calling hrtimer_cancel() while holding
cable->lock triggers an AB-BA spinlock deadlock if the hrtimer softirq
is executing concurrently on another CPU:
1) CPU A runs loopback_trigger(STOP), acquires spin_lock(&cable->lock),
and calls hrtimer_cancel(). Since hrtimer_cancel() is synchronous,
it spins waiting for the executing callback to complete before
returning.
2) CPU B executes loopback_hrtimer_function(), which immediately tries
to acquire spin_lock(&cable->lock).
This mutual dependency leads to a CPU hard lockup and NMI watchdog
panic when multiple streams start and stop concurrently with small
period sizes.
Replace hrtimer_cancel() in loopback_hrtimer_stop() with the non-blocking
hrtimer_try_to_cancel(), matching the behavior of jiffies timers
(timer_delete vs timer_delete_sync). If try_to_cancel returns -1
because the handler is running, CPU A releases cable->lock cleanly.
When the running handler subsequently acquires cable->lock, it observes
that the stream is no longer in running state (cleared by trigger STOP)
and terminates without re-arming the timer. Synchronous hrtimer_cancel()
remains preserved in loopback_hrtimer_stop_sync() where cable->lock is
not held.
Fixes: bf08a5f698 ("ALSA: aloop: Add 'hrtimer' option to timer_source")
Signed-off-by: Yu-Hsuan Hsu <yuhsuan@chromium.org>
Link: https://patch.msgid.link/20260731074255.1513402-1-yuhsuan@chromium.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Simplify the code to manage the firmware loading with auto-cleanup.
By the use of __free(firmware), we can replace the manual mutex locks
with guard() gracefully, too.
Only the code refactoring, no functional changes.
Cc: patches@opensource.cirrus.com
Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260729083735.120219-7-tiwai@suse.de
Simplify the code to manage the firmware loading with auto-cleanup
with __free(firmware). A NULL clear is added at
cs35l41_request_firmware_file() for avoiding the double-free.
Note that the driver still keeps a few manual firmware releases
because it retries with different firmware files when one of firmware
pairs fails.
Only the code refactoring, no functional changes.
Cc: patches@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260729083735.120219-6-tiwai@suse.de
Clean up the code for managing the firmware loading in the 6fire
driver with __free(firmware) and __free(kfree), so that the loaded
firmware and the name string are cleaned up automatically.
Only the code refactoring, no functional changes.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260729083735.120219-2-tiwai@suse.de
As strlcat() shall be deprecated in future, provide an alternative
just for a simple purpose -- append a suffix string to the given
string buffer -- and use it at appropriate places. The code isn't
really efficient, but we don't ask for speed here, so let it be.
Link: https://lore.kernel.org/amolHJpiluNmBsDU@dev
Reviewed-by: Ian Bridges <icb@fastmail.org>
Tested-by: Ian Bridges <icb@fastmail.org>
Link: https://patch.msgid.link/20260730161518.641254-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Now no one calls snd_hda_get_pin_label() with the index pointer, so
let's drop the index handling from this helper function as a code
cleanup. This results in reduction of unneeded code.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260730084513.327992-3-tiwai@suse.de
get_jack_mode_name() tries to identify the (potential) index number of
the control element to be created, but this index number isn't
actually used, since the index is set automatically at instantiating
the controls.
Drop the unneeded index retrieval and calculation as a cleanup.
Along with the change, find_kctl_name() is no longer used, hence drop
this function as well.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260730084513.327992-2-tiwai@suse.de
On the ThinkBook 14 G8+ IPH (SSID 17aa:393e, ALC287) the F1 speaker mute
LED never lights up, while the F4 mic mute LED works.
Both LEDs are platform LEDs registered by lenovo-wmi-hotkey-utilities and
default to the audio-mute / audio-micmute triggers, so the speaker LED only
follows a control carrying SNDRV_CTL_ELEM_ACCESS_SPK_LED. No control on
this machine has that flag set, so snd_ctl_led never attaches anything and
/sys/class/sound/ctl-led/speaker/card0/list stays empty. The mic LED is
unaffected because MIC_LED is set from the SOF topology on the DMIC
control, which does not go through the codec fixups at all.
The pin configuration of this machine matches the ThinkPad pin quirk that
selects ALC285_FIXUP_THINKPAD_HEADSET_JACK - pin_config_match() masks out
the sequence/association nibbles, so 0x14=0x90170120 still matches the
0x90170110 in the table. That fixup chains into ALC269_FIXUP_THINKPAD_ACPI,
but hda_fixup_thinkpad_acpi() returns early because is_thinkpad() is false:
a ThinkBook exposes neither LEN0068/LEN0268 nor IBM0068. Therefore
snd_hda_gen_add_mute_led_cdev() is never called and spec->vmaster_mute_led
stays 0.
The vendor fallback SND_PCI_QUIRK_VENDOR(0x17aa, "Lenovo XPAD",
ALC269_FIXUP_LENOVO_XPAD_ACPI) would have handled this correctly - the
machine does expose LHK2019 and VPC2004, so is_ideapad() is true - but it
never runs: the pin quirk has already set codec->fixup_id, and
snd_hda_pick_fixup() returns immediately in that case.
Add an SSID quirk selecting a fixup that keeps everything the machine
currently gets (headset jack handling plus the X1 Gen7 DAC routing) and
additionally runs the ideapad ACPI setup. It chains into
ALC287_FIXUP_LENOVO_YOGA_PRO7, which already combines
alc285_fixup_thinkpad_x1_gen7 with ALC269_FIXUP_LENOVO_XPAD_ACPI, so the
resulting chain differs from the current one only by the added ideapad step
and cannot regress the analog output or the headset jack.
Tested on 7.1.5 on the affected machine: the speaker LED group is now
populated at probe time without any userspace help, and the F1 LED
follows the mute state. Compared against a boot with the previous fixup
selection, the mixer control list (names and numids) and the registered
jack input devices are identical.
Note that the underlying mismatch is not specific to this SSID. Any Lenovo
non-ThinkPad whose pins collide with a ThinkPad pin quirk loses its mute
LED the same way. Letting hda_fixup_thinkpad_acpi() fall back to the
ideapad check would cover the whole class at once, but that touches a
helper shared with every ThinkPad, so this patch only fixes the machine
that was actually tested.
Signed-off-by: Padhia Luo <lcj20010426@gmail.com>
Link: https://patch.msgid.link/20260730071453.19636-1-lcj20010426@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a relatively large set of updates, the biggest batch of things
is Charles' fixes for the SDCA code which have been through a number of
iterations on the list and deal with a bunch of issues that have been
seen as we get more real world usage of SDCA. We also have the usual
device specific fix and quirk traffic that we tend to see, there's a
small pile of fixes for the tas2562 driver since I saw some bugs while
reviewing fixes sent by Haidar Lee but it's nothing too remarkable.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmprOjEACgkQJNaLcl1U
h9AJeAgAhXykup5iskMuGCmHG3DxDZpHQOxcmvy6x4Afrn39yBVWD1CSkhSWRxHn
IT2GDOMQeHtZE0inMjQ66BX4EUsHg9jZTrvDPEjbscGrLNJdOsrfz1L+e1CTecyG
BgdDsfZFXrjDA/pSa3GtwvbH3YalGZLlmW4lk5PPWGwf7SjkqGj+Xea7kVu1uZrf
nnTC9Sso8siSE+dWapST+yRw6KYwhJndf33ruhjX1OkBfsEM/iDn/gpgJ550G/Xl
ffN12LIB8bDeEuW6svKvQ7OdGUIQds1OfhGngDaNKmMSEqUWGZP0VfxT1s6N8TTQ
5SWz3zAwXUpxkzUYXGQWgUOpkC3CUw==
=u8gI
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v7.2-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v7.2
This is a relatively large set of updates, the biggest batch of things
is Charles' fixes for the SDCA code which have been through a number of
iterations on the list and deal with a bunch of issues that have been
seen as we get more real world usage of SDCA. We also have the usual
device specific fix and quirk traffic that we tend to see, there's a
small pile of fixes for the tas2562 driver since I saw some bugs while
reviewing fixes sent by Haidar Lee but it's nothing too remarkable.
In alc269_probe(), codec->bus->pci is dereferenced without a NULL check
for the ALC236 vendor ID case. Add the missing check, consistent with
the existing pattern used elsewhere in the same function.
Signed-off-by: Bob Song <songxiebing@kylinos.cn>
Link: https://patch.msgid.link/20260730015302.253008-2-songxiebing@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
alc_read_coef_idx() and alc_read_coefex_idx() can return -1 on error
via snd_hda_codec_read(). Several codec initialization and shutdown
functions save these return values and later write them back to
hardware registers without checking for errors, potentially corrupting
COEF register state on a read failure.
Add error checks in:
- alc282_init() and alc282_shutup(): check coef78 before write-back
- alc285_hp_init(): check coef38/coef0d/coef36 before update, check
val before write-back, and break polling loop on error
- alc294_hp_init(): break polling loop on read error
Signed-off-by: Bob Song <songxiebing@kylinos.cn>
Link: https://patch.msgid.link/20260730015302.253008-1-songxiebing@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
