| Age | Commit message (Collapse) | Author |
|---|
|
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
# Conflicts:
# include/sound/tas2781.h
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
# Conflicts:
# sound/hda/codecs/side-codecs/cs35l41_hda.c
|
|
|
|
The internal speaker amplifier on the ASUS ExpertCenter AIO E5402WHA
(ALC256, SSID 1043:3500) is enabled via GPIO2 and is active-low.
Driving GPIO2 high, as ALC256_FIXUP_ASUS_AIO_GPIO2 does on the ZN270IE,
keeps the speakers muted. Add a dedicated fixup that drives GPIO2 low
so the internal speakers work.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221938
Tested-by: Johan den Hollander <johan.den.hollander@finalist.nl>
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20261013071255.270131-1-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
cs35l41_hda_probe() takes an acpi_device through
cs35l41_hda_read_acpi() and stores it in cs35l41->dacpi. Only the
failures that happen later reach the err: label, which is where that
reference and cs35l41->acpi_subsystem_id are released, so the early
return taken when cs35l41_hda_read_acpi() fails leaves both behind.
Keep the ownership in the caller instead of dropping the reference
inside cs35l41_hda_read_acpi(). That removes the need to work out
whether a given failure path has already released it, and with it the
double put that cs35l41_hda_parse_acpi() would otherwise cause when it
fails after having released the device itself.
cs35l41_hda_parse_acpi() and the !physdev path no longer put the
reference, and the early failure enters the existing err: cleanup tail
through a new err_acpi label.
The label sits between the reset of the codec and the gpio cleanup, so
an early failure also releases the reset and chip-select descriptors
that cs35l41_hda_parse_acpi() may already have taken, while still
skipping cs35l41_safe_reset() on a codec that was never brought up.
cs35l41->dacpi comes from devm_kzalloc() and is only assigned once the
ACPI device has been found, so the put is a no-op when the lookup
itself failed.
Found by code review.
Fixes: 447106e92a0c ("ALSA: hda: cs35l41: Support mute notifications for CS35L41 HDA")
Cc: stable@vger.kernel.org
Signed-off-by: Ma Ke <make_ruc2021@163.com>
Link: https://patch.msgid.link/20261012084152.3740340-1-make_ruc2021@163.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The Acer Aspire Go 16 (AG16-71P) uses a Conexant SN6180 codec
(subsystem ID 0x1025:0x1937) with the microphone mute LED wired
to GPIO4. Add a quirk entry so the kernel drives the LED in sync
with the microphone mute state.
The fixup reuses the existing cxt_setup_mute_led() helper with
mask 0x10, matching the behavior verified on the hardware.
Signed-off-by: Gonçalo Miranda <me@goncalom.dev>
Link: https://patch.msgid.link/20261012110024.25310-1-me@goncalom.dev
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
* acpi-driver:
ACPI: bus: Drop acpi_get_first_physical_node()
efi/dev-path-parser: Switch to use acpi_bus_get_primary_device()
ALSA: hda: tas2781: Switch to use acpi_bus_get_primary_device()
ALSA: hda: cs35l41: Switch to use acpi_bus_get_primary_device()
iommu/arm-smmu-v3: Switch to use acpi_bus_get_primary_device()
ACPI: Add stub for acpi_find_child_device()
ACPI: bus: Provide !ACPI stub for acpi_device_uid()
ALSA: hda: aw88399: Switch to use acpi_bus_get_primary_device()
ASoC: loongson: Switch to use acpi_bus_get_primary_device()
ASoC: intel: boards: Switch to use acpi_bus_get_primary_device()
ASoC: amd: acp3x-es83xx: Switch to use acpi_bus_get_primary_device()
ASoC: amd: acp-es8336: Switch to use acpi_bus_get_primary_device()
thunderbolt: Switch to use acpi_bus_get_primary_device()
platform/x86: apple-gmux: Switch to use acpi_bus_get_primary_device()
platform/x86: x86-android-tablets: Use acpi_bus_get_primary_device()
platform/x86: serdev_helpers: Switch to use acpi_bus_get_primary_device()
platform/x86: yogabook: Switch to use acpi_bus_get_primary_device()
ACPI: amba: Switch to use acpi_bus_get_primary_device()
ACPI: bus: Use acpi/acpi_bus.h without CONFIG_ACPI
|
|
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
On some models like the Dell Inspiron 15 3520, jack
detection does not work. This patch switches to
delayed work to fix jack plug on Chrome OS for this model.
Assisted-by: LLM
Signed-off-by: Steven 'Steve' Kendall <skend@chromium.org>
Link: https://patch.msgid.link/20261007-fix-headphone-plug-cirrus-dell-v5-1-c28146b18d5c@chromium.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The HP ENVY Laptop 17-cr1xxx with subsystem ID 103c:8be8 uses an
ALC245 codec and two CS35L41 I2C speaker amplifiers. Its existing
quirk configures the amplifiers but does not enable the speaker
and microphone mute LED handlers.
Select ALC287_FIXUP_CS35L41_I2C_2_HP_MUTE_LEDS to retain the
amplifier setup and enable both mute indicators.
The equivalent change was tested on an HP ENVY 17-cr1xxx running
Kubuntu 26.04.1 with kernel 7.0.0-38-generic. Both keyboard mute
indicators were confirmed working.
Fixes: aa8e3ef4fe53 ("ALSA: hda/realtek: Add quirks for various HP ENVY models")
Assisted-by: LLM
Signed-off-by: Maksim Krasutski <krasutskimaksim@gmail.com>
Link: https://patch.msgid.link/20261010185335.30949-1-krasutskimaksim@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The AW88399 HDA side codec driver relies on the serial-multi-instantiate
driver to create I2C devices from the "AWDZ8399" ACPI HID entry.
Add imply SERIAL_MULTI_INSTANTIATE to help kernel configuration tools
suggest the correct dependency, matching the CS35L41 and CS35L56
HDA side codec entries.
Signed-off-by: Marco Giunta <marco_giunta@outlook.it>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/SN6PR19MB2303BF65050B51AE7217BB9AFCBD2@SN6PR19MB2303.namprd19.prod.outlook.com
|
|
The Lenovo ThinkBook X G2 IAH (MTM 21TU) has an ALC287 codec with four
CS35L41 amplifiers on I2C (CSC3551). It reports codec SSID 17aa:3929,
which it shares with the ThinkBook 13x Gen 5, and PCI SSID 17aa:3842.
Since PCI SSID 17aa:3842 has no quirk entry, the codec SSID matches
ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD. That fixup binds only
two amps (cs35l41-hda.0 and .1), while the CS35L41 configuration table
describes four for 17AA3929. Amps .2 and .3 probe and load firmware,
but they are never bound to the codec, so half of the speakers stay
silent.
Add a ThinkPad-style fixup chain that binds four I2C amps, and match the
laptop by its PCI SSID so the ThinkBook 13x Gen 5 is not affected.
Tested with hda_model=1028:0c4d (alias to ALC287_FIXUP_CS35L41_I2C_4):
all four amps bind, apply their calibration and are runtime-active
during playback.
Cc: stable@vger.kernel.org
Signed-off-by: Evgeny Akhtimirov <evgeny@devduty.com>
Link: https://patch.msgid.link/20261009-thinkbook-x-g2-iah-v1-1-56012188aee0@devduty.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
snd_hdmi_write_eld_info() parses a "sad_count N" line from the
root-writable ELD proc interface and assigns N directly to
e->sad_count with no upper bound, unlike the per-index "sadN_*" lines
a few lines below which are already bounded to ELD_MAX_SAD.
snd_hdmi_eld_update_pcm_info() later iterates
"for (i = 0; i < e->sad_count; i++)" over the fixed
e->sad[ELD_MAX_SAD] array, so an oversized sad_count read from the
proc file causes it to walk past the array.
Reject sad_count values above ELD_MAX_SAD, matching the existing
per-index guard.
Fixes: acb059938810 ("ALSA: hda - ELD proc interface write updates")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20261008085133.9528-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
hdmi_add_cvt() stores each converter's NID into the fixed-size
spec->cvt_nids[] array (used only by the Intel Haswell pin-connection
fixup), but only when spec->num_cvts is still within
ARRAY_SIZE(cvt_nids); the num_cvts counter itself is incremented
unconditionally regardless of whether the store happened. A codec
that reports more converters than cvt_nids[] can hold therefore ends
up with num_cvts > ARRAY_SIZE(cvt_nids).
hdmi_read_pin_conn(), on the intel_hsw_fixup path, copies num_cvts
elements from cvt_nids[] with memcpy(), so once num_cvts exceeds the
array size this reads past cvt_nids[] and writes the resulting
garbage NIDs into per_pin->mux_nids[].
Clamp the copy length to the actual size of cvt_nids[] instead of
trusting num_cvts, which is also used unbounded as the size of the
separate, dynamically-sized spec->cvts array and must not be
truncated at the source.
Fixes: bce0d2a80e42 ("ALSA: hda - Allow unlimited pins and converters in patch_hdmi.c")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20261008085122.9442-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The speakers on the Legion S7 15IMH05 (PCI SSID 17aa:3811, ALC287) stay
silent after a cold boot with the current quirk, which applies
ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS. They only start working after a
suspend/resume cycle.
The amplifier setup is sent through COEF 0x24/0x26 on NID 0x20. On this
machine the first pass of that sequence appears to only wake the
amplifiers. Sending the identical sequence a second time makes both
speakers work, provided the second write comes a few milliseconds after
the first: back-to-back writes leave the speakers silent, a 7 ms gap
makes only the right speaker work, and 8 ms or more is reliable. A dump
of all COEF registers of NID 0x20 taken before and after the second
write shows no difference.
Add a dedicated fixup that writes the sequence, waits 20 ms to keep a
margin over the measured minimum, and writes it again on every codec
init. It chains to the same AUTOMUTE fixup as before. To share the
sequence, move the verbs of ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS into a
named array; this has no functional change for the other users of that
fixup.
Fixes: 67f4c61a73e9 ("ALSA: hda/realtek: Add quirk for Legion S7 15IMH")
Cc: stable@vger.kernel.org
Link: https://github.com/CachyOS/linux-cachyos/issues/792
Signed-off-by: Matej Sochan <matej.sochan@gmail.com>
Link: https://patch.msgid.link/20261007-legion-s7-v1-1-8ea7fb7ee766@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The Sound BlasterX AE-5 and AE-5 Plus expose a 3-pin 5V addressable RGB
header driven directly by the CA0113 PCIe-to-HD-Audio bridge. Rather
than using the CA0132 DSP or MMIO GPIO, the CA0113 contains an
autonomous HDA link sniffer that snoops a designated HDA DMA playback
stream, extracts the 24-bit GRB color payload, and serializes it as
800 kHz single-wire NRZ pulses to the strip (WS2812B protocol).
Expose the strip through volatile card control elements:
"AE-5 LED Strip" (RW, BYTES): 300-byte RGB payload representing
up to 100 addressable LEDs (3 bytes per LED).
"AE-5 LED Strip Count" (RW, INTEGER): Active LED count (1..100).
The controls are marked with IFACE_CARD and SNDRV_CTL_ELEM_ACCESS_VOLATILE
so changes do not trigger unnecessary audio daemon wakeups or state
restoration by alsactl.
Writes allocate an idle HDA playback stream, format a 32 KB DMA buffer
populated with repeating WS2812 frames (preamble, audio words per LED,
and reset gap), configure the CA0113 BAR2 serializers and stream-tag
pin mux, and pulse the stream long enough for the reset latch to fire.
Access is serialized with a per-spec mutex, and the controls are only
registered on QUIRK_AE5 devices.
The strip transport uses snd_hdac_dsp_prepare() / snd_hdac_dsp_cleanup(),
which require CONFIG_SND_HDA_DSP_LOADER. All strip-related code and struct
fields are conditionally compiled under
IS_ENABLED(CONFIG_SND_HDA_DSP_LOADER), with a no-op stub for
ae5_add_strip_controls() when disabled.
Signed-off-by: Devin Christensen <dchristensen8@proton.me>
Link: https://patch.msgid.link/20261007163207.2621040-1-dchristensen8@proton.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> says:
This series adds compressed audio support for SOF with IPC4 firmware.
Supported formats are PCM, MP3, AAC and VORBIS, the feature set is
PAUSE_PUSH/RELEASE, DRAIN and position reporting.
Patches 1-5 are prerequisites in the ALSA compress core and in
soc-compress.c.
These are core fixes rather than driver level workarounds on purpose.
The other users of compressed DPCM have DSP internal ports on their
BEs, driven by code they own. An Intel/SOF BE ends at a third party
CODEC driver which is shared with the non DPCM case and has no reason
to know that the FE is compressed. That set of CODECs is open ended,
so teaching each of them to cope with a compressed FE does not scale.
The core has to hand a BE the same substream state whether the FE is
a PCM or a compressed one.
Two of these patches change behaviour for the existing users of
compressed DPCM, so they would need a look from Qualcomm and NXP:
- "ASoC: soc-compress: Implement trigger FE-BE sequencing as with
normal PCMs" makes the FE/BE trigger order follow
dai_link->trigger[], the way dpcm_fe_dai_do_trigger() does it.
Neither sound/soc/qcom/ nor sound/soc/fsl/ sets it, so both default
to SND_SOC_DPCM_TRIGGER_PRE: START keeps the current order, but
STOP, SUSPEND and PAUSE_PUSH now trigger the BE before the FE.
- "ASoC: soc-compress: Stop running dpcm on free" sends a STOP trigger
from soc_compr_free_fe() if the DPCM is still in START state, which
is the case when the last trigger the stream received was a DRAIN.
Patches 6-20 implement the IPC4 compressed support, patch 21 is a
Kconfig cleanup. The last two patches enable the feature, in Kconfig
for TGL and later and in the topology parser, so the compressed device
type only becomes usable once the code behind it is in place.
Testing:
- IPC4: Arrow Lake, compressed playback on speaker and headphone
(cs42l43), MP3, AAC and VORBIS.
- IPC3: tested by NXP. This does not cover the STOP on free path
above, as they do not implement DRAIN.
Link: https://patch.msgid.link/20261007084955.1256-1-peter.ujfalusi@linux.intel.com
|
|
Commit 1e3e378d63be ("ALSA: hda/realtek: Enable bass speakers on HONOR
MagicBook Pro 16 2024") restricted the speaker pin 0x1b to DAC 0x02, on
the assumption that the second speaker pair would otherwise end up on
DAC 0x03, as channels 3/4 that a stereo stream never reaches. That
assumption was wrong: without the override, pin 0x1b is still connected
to DAC 0x02, the only DAC that pin 0x14 can use, so the override changes
nothing. With and without it the codec routing is identical and the
speakers behave the same with nothing plugged in, with headphones and
with a CTIA headset inserted; without it they also keep working after
suspend/resume.
That commit also got the speaker roles the wrong way round. Pin 0x1b,
which the BIOS does configure, drives the bottom speakers, which carry
the low and mid frequencies; pin 0x14 drives the tweeters next to the
keyboard, and those are the speakers that stay silent without the quirk.
Measured with the internal microphones, enabling one pin at a time: at
1 kHz the 0x14 pair alone is more than 30 dB below the 0x1b pair alone,
while at 6 kHz the two are within 10 dB of each other.
Drop the DAC override and correct the pin comment, so the quirk only
sets pin configurations, like the one for the sibling M1020 board
(HONOR MRB-XXX).
Fixes: 1e3e378d63be ("ALSA: hda/realtek: Enable bass speakers on HONOR MagicBook Pro 16 2024")
Assisted-by: LLM
Signed-off-by: Denis Yakovlev <mfthesun@vivaldi.net>
Link: https://patch.msgid.link/20261005203836.11074-1-mfthesun@vivaldi.net
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The ASUS Vivobook S 14 Q423SA-U5512 (DMI family S5406SA) with the
ALC294 codec has working analog audio when booted directly after a full
shutdown. After a warm reboot from Windows 11, audio works briefly during
Linux startup, then both the internal speakers and headphones become
silent. PCM playback continues without errors.
Coefficient 0x1b is 0x4e4b on a direct cold boot, but 0x4a4b after the
Windows warm reboot. Restoring bit 10 changes it back to 0x4e4b and
immediately enables both analog outputs. Speaker playback, headphone
playback, jack switching, cold boot, and suspend/resume were tested
successfully. The same 0x4a4b state and immediate recovery with 0x4e4b
were independently confirmed on another S5406SA with subsystem 1043:10c4.
The same coefficient write is already used by
ALC294_FIXUP_ASUS_COEF_1B for the ASUS UX431DA. That fixup cannot be
reused here because it chains to ALC289_FIXUP_ASUS_GA401 and applies
unrelated DAC routing and microphone pin configuration.
Add a model-specific fixup for subsystem 1043:10c4 and chain it to the
existing ALC2XX_FIXUP_HEADSET_MIC fixup instead.
Link: https://github.com/thesofproject/sof/issues/11051
Fixes: f2d08f3651fb ("ALSA: hda/realtek: Fix headset mic on ASUS Vivobook S14 S5406SA")
Signed-off-by: Scott Gauche <scott-dev@scottgauche.com>
Link: https://patch.msgid.link/20261005154017.1164657-1-scott-dev@scottgauche.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Now that the shared library correctly skips the BSTS check when the boost
converter is bypassed, the per-instance bsts_unreliable flag added as a
workaround in the HDA side codec driver is unnecessary.
Remove it from the library, the HDA driver, and the shared header.
This also simplifies testing the HDA side codec driver on new devices,
as new models no longer need a quirk entry to bypass the BSTS check.
Users can test via the model= module parameter in alc269 without a custom
kernel.
Signed-off-by: Marco Giunta <marco_giunta@outlook.it>
Link: https://patch.msgid.link/SN6PR19MB2303CC64AF7DEC3C5C98A512FC8F2@SN6PR19MB2303.namprd19.prod.outlook.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Configure the driver to correctly initialize and enable the bass speakers
on devices utilizing the TAS2781 amplifier. Without this change, only the
tweeters or main speakers are active, leading to thin audio output.
Set up the required register sequences and routing to ensure the bass
channels are properly powered and mixed into the audio stream.
Signed-off-by: Georg Wenzel <g.wenzel@gmail.com>
Link: https://patch.msgid.link/20261004071202.89116-1-g.wenzel@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The HONOR MagicBook Pro 16 2024 (DRA-XX, board M1020, ALC256, SSID
1ee7:204e) has a combined 3.5 mm headphone/microphone jack. The BIOS
leaves the headset mic pin 0x19 at 0x411111f0, so the codec parser
builds no capture path for it, and it leaves the jack switch
(coefficient 0x45) in the TRS state, which cuts the microphone contact
off from the codec. A wired headset microphone therefore records
nothing.
Configure 0x19 as a headset microphone (0x03a1113c, "headset mic
without its own jack detect"), the same value already used for the
sibling M1020 board (HONOR MRB-XXX) and by the VAIO quirks, and chain
to the generic headset mode handler, which detects the CTIA/OMTP
headset type on every jack event and programs the jack switch
accordingly. Pin 0x1a is left untouched: there is no evidence that it
is wired on this board.
Fixes: 1e3e378d63be ("ALSA: hda/realtek: Enable bass speakers on HONOR MagicBook Pro 16 2024")
Assisted-by: LLM
Signed-off-by: Denis Yakovlev <mfthesun@vivaldi.net>
Link: https://patch.msgid.link/20261003133325.97507-1-mfthesun@vivaldi.net
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The mute LED on the HP Pavilion Laptop 15-eg3xxx (PCI SSID 103c:8bfd,
Realtek ALC287) does not work because the machine has no entry in the
quirk table. No fixup is applied, so the mute LED is never driven, even
though the mute function itself works.
The LED is controlled via GPIO pin 4 (mask 0x10), which is exactly what
ALC287_FIXUP_HP_GPIO_LED configures. This was verified on the hardware
with hda-verb: setting the GPIO data bit lights the mute LED, and
clearing it turns the LED off.
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x10
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIRECTION 0x10
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x10 # LED on
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x00 # LED off
Add a quirk entry for 103c:8bfd using ALC287_FIXUP_HP_GPIO_LED.
Signed-off-by: Jaidheer Sirigineedi <jaidheer7@gmail.com>
Link: https://patch.msgid.link/20261002185951.33855-1-jaidheer7@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Lenovo ThinkBook Plus G3 IAP shares PCI SSID 17aa:3891 with Yoga Pro
7 14AHP9, but has a different codec SSID (0x17aa3875). Use
HDA_CODEC_QUIRK to select ALC287_FIXUP_CS35L41_I2C_2 and add ACPI
_SUB values 17AA3845/17AA3846 to the CS35L41 property table, since
the BIOS provides no _DSD.
Reported-by: Harry Nixon <harryanixon@yahoo.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222053
Tested-by: Harry Nixon <harryanixon@yahoo.com>
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20261001033920.111061-1-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Some Lenovo BIOSes (e.g. Legion Pro 7 16IRX9H, SSID 17aa:38cd) store
valid V1 calibration data in the CALI_DATA EFI variable but leave the
TimeStamp and CRC fields zeroed. The driver rejects such data, so the
amplifiers always run with default parameters on these machines.
The rejection was silent until
commit 4fe238513407 ("ALSA: hda/tas2781: Move and unified the
calibrated-data getting function for SPI and I2C into the tas2781_hda lib")
turned it into "V1 CRC error".
The stored values are consistent (R0 = 3.82/3.83 ohm, 1/R0 matching
within 1e-4), so accept V1 data when both TimeStamp and CRC are zero
and the first device entry is non-zero, and emit a warning.
Fixes: 5be27f1e3ec9 ("ALSA: hda/tas2781: Add tas2781 HDA driver")
Cc: stable@vger.kernel.org
Signed-off-by: Mohamed Yassine Jebabli <med.jebabli@gmail.com>
Link: https://patch.msgid.link/20261001-tas2781-v1-nocrc-v1-1-ff0c1032ce76@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Fix headphone jack detection for some devices
Signed-off-by: Eckhart Mohr <e.mohr@tuxedocomputers.com>
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Link: https://patch.msgid.link/20261001183403.103990-1-wse@tuxedocomputers.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Pull again 7.3-devel branch for working on snd_card_free auto-clean
changes.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Replace acpi_get_first_physical_node() that is slated for removal
with acpi_bus_get_primary_device() that takes a reference to the
device it is about to return.
This addresses a potential use-after-free that may occur if the
device returned by acpi_get_first_physical_node() is removed right
after dropping its ACPI companion's physical_node_lock in that
function.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/8782185.NyiUUSuA9g@rafael.j.wysocki
|
|
Replace acpi_get_first_physical_node() that is slated for removal
with acpi_bus_get_primary_device() that takes a reference to the
device it is about to return.
This addresses a potential use-after-free that may occur if the
device returned by acpi_get_first_physical_node() is removed right
after dropping its ACPI companion's physical_node_lock in that
function.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/6200303.MhkbZ0Pkbq@rafael.j.wysocki
|
|
The ALC235 (0x10ec0235) is registered as the ALC255 codec variant in
patch_alc269(), but the headset mode functions were missing a case
for it, so the CTIA/OMTP jack type detection and routing never ran
on this codec. As a result, a plugged-in headset is detected (jack
presence works) but the microphone signal is never routed, leaving
the capture stream permanently silent.
Verified on an ASUS M5451GA laptop (HDA:10ec0235,10431814): with the
ALC255 coef sequence applied, the headset microphone works correctly.
Signed-off-by: Zeyu Li <13776528859@163.com>
Link: https://patch.msgid.link/20260926140336.27896-1-13776528859@163.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The Acer Swift SFG16-72 (1025:173b) uses the ALC245 codec, but its
mic-mute LED is not enabled by default. Apply the existing
ALC245_FIXUP_ACER_MICMUTE_LED quirk to enable the mic-mute LED.
Assisted-by: LLM
Cc: stable@vger.kernel.org
Signed-off-by: Jakub Gawlik <jakubgawlik13@gmail.com>
Link: https://patch.msgid.link/20260930145839.374762-1-jakubgawlik13@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The HP ENVY x360 2-in-1 Laptop 15-ey0xxx (SSID 103c:8a31, ALC245 with
CS35L41 I2C amps) currently only gets ALC287_FIXUP_CS35L41_I2C_2, so the
mute and micmute LEDs on the keyboard never light up.
On this machine the mute LED is driven by COEF 0x0b bits 2-3 and the
micmute LED by GPIO 0x04 (active low), which is exactly what
ALC245_FIXUP_HP_X360_MUTE_LEDS sets up. Switch the quirk to
ALC287_FIXUP_CS35L41_I2C_2_HP_MUTE_LEDS, which keeps the CS35L41 setup
and chains to that LED fixup.
Verified by driving the COEF and GPIO values by hand with hda-verb,
following Master Playback Switch and Mic ACP LED Capture Switch.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Harrison Lucas <tiiowsalt@gmail.com>
Link: https://patch.msgid.link/20260929174348.167537-1-tiiowsalt@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The HP Pavilion 14-dv1001TU (subsystem ID 103c:8987) uses a Realtek
ALC287 codec. The mute LED on this machine is controlled by GPIO bit
0x10, which was verified via hda-verb, but the subsystem ID is missing
from the quirk table. As a result, the ALC287_FIXUP_HP_GPIO_LED fixup
that drives GPIO 0x10 is never applied and the mute LED stays off even
though the associated LED class device toggles correctly.
Add the missing SND_PCI_QUIRK entry to map this subsystem ID to
ALC287_FIXUP_HP_GPIO_LED so the mute LED works as expected.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221810
Signed-off-by: renpanpan <renpanpan@kylinos.cn>
Link: https://patch.msgid.link/20260930065504.24151-1-rppxj178543@163.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Pull 7.3-devel branch again for further development of USB-audio stuff.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The bass speakers of the Lenovo Yoga Slim 7 Carbon 14ACN6 (82L0) are
driven by two CS35L41 amplifiers, fed over I2S by the ALC287. The codec
only clocks the I2S bus while pin 0x17 is enabled, but the BIOS reports
the pin as unconnected (0x411111f0). The amplifiers then never see a
clock and fail to power up:
cs35l41-hda i2c-CLSA0102:00-cs35l41-hda.0: Enable(1) failed: -110
Configure pin 0x17 as a speaker and keep it on DAC 0x02 together with
pin 0x14: with DAC 0x06 the path is powered down during stereo
playback, which stops the clock again. Then bind the two CS35L41
amplifiers.
The PCI SSID of this machine is 17aa:0000, so match on the codec SSID.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215632
Assisted-by: Claude Opus 5
Signed-off-by: Ilya Pavlukhin <i.pavluhin@ya.ru>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260920092808.17234-5-i.pavluhin@ya.ru
|
|
The Lenovo Yoga Slim 7 Carbon 14ACN6 (82L0) drives its bass speakers
with two CS35L41 amplifiers, described by ACPI HID CLSA0102 without a
_DSD. The node has the same layout as CLSA0100/CLSA0101: both amps in
one node, reset on GPIO index 0 and the interrupt on a GpioInt. Unlike
the Legion 7 there is no speaker ID GPIO, index 2 is the interrupt line.
The Windows driver runs the amps from an external VSPK supply
(ExternalVspkControl, boost converter disabled), so use
CS35L41_EXT_BOOST with the VSPK switch on GPIO1. With the internal
boost converter enabled the amps report "Amp short error" during
playback.
There is no _SUB in the ACPI node, so the firmware files are looked up
by the codec SSID, 17aa3856.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215632
Assisted-by: Claude Opus 5
Signed-off-by: Ilya Pavlukhin <i.pavluhin@ya.ru>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260920092808.17234-4-i.pavluhin@ya.ru
|
|
The ASUS ExpertBook PM3406CHA uses an ALC256 codec with subsystem
ID 1043:1664. On Linux boot, the internal speakers are silent even
though playback is routed to the codec and the speaker pin is
configured for output.
The codec starts with coefficient 0x10 set to 0x1d20. Writing 0x7f20
to coefficient 0x10 immediately restores internal speaker output.
This was reproduced on the affected hardware from a fresh boot using
hda-verb. Reducing a larger initialization sequence showed that this
coefficient write alone is sufficient; no GPIO, EAPD, pin-control, or
other coefficient changes are required. After applying the coefficient
in userspace, speaker output also remains functional across suspend
and resume.
Add a machine-specific HDA fixup that writes the required coefficient.
The fixup has been compile-tested, but could not be boot-tested because
the affected hardware is no longer available.
Closes: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/2162718
Signed-off-by: Muhtasham Nawr al-Mahmud <muhtaseem2005@gmail.com>
Link: https://patch.msgid.link/20260924144512.3989-1-muhtaseem2005@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Add ALC225_FIXUP_HP_AIO_SPK to enable the internal speaker on
HP Pavilion AiO 24 (103c:85ba).
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221691
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260929091109.400313-1-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The HP Laptop 15-fd2xxx (PCI SSID 103c:8e43, Realtek ALC236) has a
speaker mute LED on the F5 key and a microphone mute LED on the F8 key.
Neither lights up, because the model has no quirk entry and only the
generic HP vendor fallback (ALC269_FIXUP_HP_MUTE_LED) is applied.
Probing the codec with hda-verb showed how the LEDs are wired:
- mute LED: COEF index 0x07, bit 0, on NID 0x20 (set = LED on)
- mic mute LED: codec GPIO0, active low (driven low = LED on)
Driving GPIO1 and GPIO2 did not light the mute LED. This wiring is
exactly what the existing ALC236_FIXUP_HP_MUTE_LED_MICMUTE_GPIO fixup
implements (COEF 0x07 bit 0 for the mute LED, GPIO0 with inverted
polarity for the micmute LED), so use it for this model. The sibling
HP Laptop 15-fd0xxx (103c:8dd7) already uses the same fixup.
Tested on this machine running Ubuntu 7.0.0-34-generic (SOF driver, the
quirk built into snd-hda-codec-alc269 from Ubuntu's 7.0.0-34.34 source
tree): the hda::mute and hda::micmute LEDs are created, follow the
Master mute state and the Dmic0 capture switch respectively, and the
F5 and F8 keys toggle them correctly. Muting the microphone also
silences the capture stream. The LEDs also kept the correct state across
an s2idle suspend/resume cycle (speaker muted in one run, microphone in
another) and still responded to mute changes afterwards; long suspends
were not tested. The desktop session was SwayFX (wlroots) with PipeWire,
which only changes the mute state through the normal mixer controls; no
other desktop was tried. Not tested on a mainline kernel tree directly;
the change is only the quirk table entry.
AI assistance: this patch, the hardware analysis behind it (probing the
codec with hda-verb and choosing the existing fixup) and this commit
message were written by Claude Code (Anthropic, model claude-sonnet-5-5).
The submitter ran the privileged commands and reboots and reported the
LED behavior; Claude Code ran the tests and read the kernel logs.
Assisted-by: Claude:claude-sonnet-5-5
Signed-off-by: Preston Lam <plamlam99@gmail.com>
Link: https://patch.msgid.link/20260928231621.1672704-1-plamlam99@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
On the Minisforum V3 and V3 SE (ALC245, PCI SSID 1f4c:e001) the
internal digital microphone array never produces any audio. The DMIC
pin 0x12 is parsed correctly ("Internal Mic=0x12"), but the headset mic
jack pin 0x19 (BIOS pin config 0x04a19050, jack detect enabled) has no
presence detect wired on these boards: reading GET_PIN_SENSE on 0x19
always returns "present" (as it does on the unused, unconnected pin
0x18), while the headphone jack 0x21 reports correctly.
The generic parser therefore sets up auto-mic switching and, believing
an external mic is always plugged in, permanently routes the ADC to the
empty jack (mixer 0x23 input 0x19 unmuted, input 0x12 muted). The
"Mic Jack" kcontrol reports "on" with nothing plugged in.
Mark pin 0x19 as having no presence detect. The parser then stops
auto-switching and exposes a normal "Capture Source" (Internal Mic /
Mic) control, which desktop audio stacks drive from their Internal
Microphone / Microphone ports. The existing bass speaker DAC routing is
kept by chaining to ALC245_FIXUP_BASS_HP_DAC.
Tested on both models with the same pin config applied through a
snd-hda-intel patch firmware ([pincfg] 0x19 0x04a19150):
- V3 SE (Ryzen 7 7735U, BIOS 1.03), kernel 7.2.6
- V3 (Ryzen 7 8840U, BIOS 1.06), kernel 7.2.7
Both boards report the same codec SSID and the same 0x19 default. On
both, the internal mic records at a normal level, headphone jack
detection on 0x21 still switches output, and the bass routing is
retained (DAC1/DAC2 Playback Volume controls present). A headset mic
on the combo jack was not tested (none available); with this change it
has to be selected manually. V3 users already report that the jack mic
gets no input [1], which is the other symptom of the same broken
presence detect.
The patched alc269.c was build-tested with W=1 on tiwai/sound.git
for-linus (7.3-rc3) without new warnings.
The diagnosis, the fixup and this changelog were written with the help
of an AI coding assistant; I reviewed them and tested the change on the
hardware listed above.
Fixes: e34743018249 ("ALSA: hda/realtek: Add quirk for Minisforum V3 SE")
Link: https://github.com/mudkipme/awesome-minisforum-v3/issues/14 [1]
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Jared Wuerzburger <jwuerz@gmail.com>
Link: https://patch.msgid.link/20260928152925.69032-1-jwuerz@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
On the Huawei MateBook 14 (PCI SSID 19e5:329e), the SN6140 codec
silently routes the speaker output through the headphone pin's
connection select: whatever DAC the headphone pin 0x16 is connected to,
the speaker pin 0x17 follows. The generic parser attaches the playback
stream to DAC 0x10 (shared by the headphone path) and mutes that DAC
when no headphone is plugged, silencing the internal speaker while the
headphone jack keeps working.
Add a quirk for this machine that suppresses the auto-mute, binds the
speaker pin to the shared DAC 0x10, removes the mute switch on that DAC
so userspace cannot mute it, and re-applies the routing after every
output update; at init it routes both pins to DAC 0x10, enables the
speaker EAPD (which the driver otherwise leaves off) and unmutes the
DAC.
Note that this is a different problem than the existing Huawei
Matebook quirk for SSID 19e5:3289 (commit d152afd1cd7a), which fixes a
missing headphone jack; that machine has working speakers.
Tested on Ubuntu 26.04 (kernels 7.0.0-30 and 7.0.0-31): the speaker
plays at boot without any userspace helper, and keeps working across
suspend/resume.
Signed-off-by: Liu Eason <liudongxjtu@outlook.com>
Link: https://lore.kernel.org/ME3PR01MB75042406F30EE48AB6DA3595BD862@ME3PR01MB7504.ausprd01.prod.outlook.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Laptop 15-dw1xxx
The HP Pavilion 15-eh3174nw with an ALC287 codec requires the
ALC287_FIXUP_HP_GPIO_LED fixup for its mute LED to work correctly.
Add subsystem ID 0x103c:0x8bc7 to the quirk table to apply the
existing fixup.
Tested on an HP Pavilion 15-eh3174nw; the mute LED now follows the
speaker mute state.
The HP Laptop 15-dw1xxx with an ALC236 codec requires the
ALC236_FIXUP_HP_MUTE_LED_MICMUTE_GPIO fixup for its mute LED to work correctly.
Add subsystem ID 0x103c:0x85f1 to the quirk table to apply the existing fixup.
Tested on an HP Laptop 15-dw1xxx; the mute LED now follows the speaker
mute state.
Signed-off-by: Bartosz Brom <bartosz.brom06@gmail.com>
Link: https://patch.msgid.link/20260928134335.1875-1-bartosz.brom06@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The HONOR MagicBook Pro 16 2024 (DRA-XX, board M1020, ALC256, SSID
1ee7:204e) has two tweeters and four woofers. The BIOS only configures
the tweeter pin 0x1b; the woofer pin 0x14 is left at 0x411111f0, so the
woofers stay silent.
Pin 0x14 can only be connected to DAC 0x02, while the parser puts the
tweeters on DAC 0x03, which turns the second speaker pair into channels
3/4 that a stereo stream never reaches (and SOF on Meteor Lake only
exposes a 2-channel HDA analog PCM). Configure 0x14 as an internal
speaker and restrict 0x1b to DAC 0x02, so both speaker pairs play the
stereo stream with a shared volume control, as on Windows.
Tested on DRA-XX with SOF (sof-hda-generic-2ch.tplg): woofers and
tweeters play together, headphone auto-mute and the DMICs keep
working.
Assisted-by: LLM
Signed-off-by: Denis Yakovlev <mfthesun@vivaldi.net>
Link: https://patch.msgid.link/20260927210455.13938-1-mfthesun@vivaldi.net
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The HP Victus 15-fb2xxx (PCI SSID 103c:8c2f) with the ALC245 codec
does not turn on the mute LED when audio is muted.
Add a quirk entry to enable it.
Reported-by: erph.briones27@gmail.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221946
Signed-off-by: Krish Gulati <krishgulati7@gmail.com>
Tested-by: Raphael Briones <erph.briones27@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260921131728.8999-1-krishgulati7@gmail.com
|
|
The Acer Nitro AN515-45 requires ALC2XX_FIXUP_HEADSET_MIC to make the
headset microphone work properly.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221925
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260921124450.639601-2-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Fix Bass Speaker volume control on Lenovo ThinkBook G8+ by adding
quirk 17aa:38dc with ALC285_FIXUP_SPEAKER2_TO_DAC1.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221799
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260921124450.639601-1-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The internal speakers of the ASUS ExpertBook PM3606CHA (Realtek ALC256,
PCI SSID 1043:3501) stay silent with the default codec setup, and the
headphone jack is not detected either. The codec needs COEF values that
differ from its power-on defaults: COEF 0x10, 0x16, 0x35, 0x37 and 0x57
on NID 0x20 have to be set to the values used by the Windows driver.
Toggling the codec GPIOs, and the existing ALC256 fixups alone, make no
difference.
Apply the COEFs from a new fixup at the INIT action, so that they are
restored after resume as well. Chain to ALC256_FIXUP_ASUS_MIC_NO_PRESENCE
to keep the headset mic and the jack detection working, which the
fallback pin quirk provided before for this machine.
The COEF values were found by the reporter of the Ubuntu bug below, who
compared the codec state against the one under the Windows driver.
Tested on an ASUS ExpertBook PM3606CHA (BIOS PM3606CHA.304) with the
change applied to v7.2.5: with this fixup alone, the speakers, the
headphones with jack detection, and the headset mic all work, also
after suspend and resume.
Link: https://bugs.launchpad.net/bugs/2167288
Signed-off-by: Saim Masood <s.m.saim074@gmail.com>
Link: https://patch.msgid.link/065927dd-cabf-449a-992d-64887eedda01@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Pull 7.3 devel branch for applying the further HD-audio quirks more
cleanly.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
It lost its headset microphone functionality, and this patch will restore it.
Fixes: 97272a5704bf ("ALSA: hda/realtek - Fixed Headphone noise issue for Dell QCM1255")
Signed-off-by: Kailang Yang <kailang@realtek.com>
Link: https://lore.kernel.org/3c251e40a2944ae4ae479e4c2e4e63a4@realtek.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The Higole F9B is an Alder Lake-N mini PC with a 7" touchscreen and an
ALC269VC codec (subsystem ID 0x10ec111e). Its DMI strings are all
"Default string", so the SSID is the only way to identify it.
The internal speaker is silent out of the box. The generic parser
assigns DAC 0x03 to the speaker pin 0x14 and DAC 0x02 to the headphone
pin 0x15, but the speaker only reproduces what DAC 0x02 plays, whatever
its connection selection says. Checked one path at a time, only the
gain of DAC 0x02 and the mute of pin 0x14 change what comes out of the
speaker. User space only knows the path it was told the speaker uses,
so selecting the speaker turns the path that actually reaches it all
the way down.
Route both 0x14 and 0x15 through mixer 0x0c (DAC 0x02), which is what
ALC290_FIXUP_MONO_SPEAKERS already does. Tested on the device: the
speaker plays.
Cc: <stable@vger.kernel.org>
Assisted-by: LLM
Signed-off-by: Yu-Hsiang Tseng <asas1asas200@gmail.com>
Link: https://patch.msgid.link/20260923141344.1543158-1-asas1asas200@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
