<feed xmlns='http://www.w3.org/2005/Atom'>
<title>laptop-kernel/sound, branch master</title>
<subtitle>Linux kernel tree for laptop</subtitle>
<id>https://git.zx2c4.com/laptop-kernel/atom/sound?h=master</id>
<link rel='self' href='https://git.zx2c4.com/laptop-kernel/atom/sound?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/laptop-kernel/'/>
<updated>2026-10-13T13:32:22Z</updated>
<entry>
<title>ASoC: amd: yc: disable MSI on resume</title>
<updated>2026-10-13T13:32:22Z</updated>
<author>
<name>Mario Limonciello</name>
<email>mario.limonciello@amd.com</email>
</author>
<published>2026-10-13T12:54:23Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/laptop-kernel/commit/?id=2a31b5378c6db9c4a8d399e5d10d32cd4b732bef'/>
<id>urn:sha1:2a31b5378c6db9c4a8d399e5d10d32cd4b732bef</id>
<content type='text'>
BIOS/firmware may re-enable MSI in PCI config space during system
resume even though this driver only uses legacy INTx interrupts. If MSI
is left enabled with stale address and data registers, the device can
write interrupts to a bogus address and cause an IOMMU IO_PAGE_FAULT.

Clear the MSI Enable bit before reinitializing ACP hardware on system
resume. Keep runtime resume separate because firmware does not restore
PCI configuration on that path.

Fixes: c8212df7bc0f ("ASoC: amd: add acp6x pci driver pm ops")
Reported-by: Marek Borůvka &lt;boruvka.marek@gmail.com&gt;
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222119
Signed-off-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Link: https://patch.msgid.link/20261013125425.3541206-1-mario.limonciello@amd.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>ASoC: Fix controls that write another control's bits</title>
<updated>2026-10-12T18:52:02Z</updated>
<author>
<name>Mark Brown</name>
<email>broonie@kernel.org</email>
</author>
<published>2026-10-12T18:52:02Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/laptop-kernel/commit/?id=8ac49fbf00e580e8ee1a66b120f8b33d9ab81901'/>
<id>urn:sha1:8ac49fbf00e580e8ee1a66b120f8b33d9ab81901</id>
<content type='text'>
HyeongJun An &lt;sammiee5311@gmail.com&gt; says:

In the es8316 thread Mark suggested checking at registration time for
controls whose register fields overlap [1]. Before adding such a check,
I wanted to see what it would find in the tree today.

A script expanded the control tables of every ASoC driver built by
allmodconfig and looked for two controls in one table whose register
fields overlap. It found 80 pairs in 33 drivers. Most are real bugs.
The rest are deliberate, where two names drive the same field, such as
the AC and DRC mode thresholds in sta32x.

This series fixes six that I could confirm against the vendor
datasheet. In each one, writing a control changes a different control,
and the bits it should own cannot be reached. Most date back to the
first version of the driver.

One more is left out on purpose. The cs42l56 ADC Mute Switch writes the
ADC invert bits. The real mute bits are also written by the
cs42l56_mute() callback on every stream start and stop, so moving the
control there would let the stream mute override it. I am not sure
whether you would rather move it or drop it.

I have none of this hardware, so these are checked against the
datasheets only. More fixes, checked against the register headers,
and the registration time check would follow.

[1] https://lore.kernel.org/all/0fefbfe1-021b-46b2-8945-15956e75e37f@sirena.org.uk/

Link: https://patch.msgid.link/20261008130953.2446692-1-sammiee5311@gmail.com
</content>
</entry>
<entry>
<title>ASoC: nau8822: Fix the 128x oversampling switch bits</title>
<updated>2026-10-12T18:52:01Z</updated>
<author>
<name>HyeongJun An</name>
<email>sammiee5311@gmail.com</email>
</author>
<published>2026-10-08T13:09:52Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/laptop-kernel/commit/?id=4db45fc1da3d62d0fa6e8f1e457ae92e8741ed07'/>
<id>urn:sha1:4db45fc1da3d62d0fa6e8f1e457ae92e8741ed07</id>
<content type='text'>
The DAC and ADC 128x Oversampling Switches use bit 5 of R10 and R14.
The NAU8822 datasheet register map puts DACOS and ADCOS at bit 3 of
those registers.

In R14, bit 5 is inside HPF[6:4], which the High Pass Cut Off control
owns. So turning on ADC oversampling changes the high pass cut-off, and
the oversampling bit cannot be set. In R10, bit 5 is reserved, so the
DAC switch has no effect.

Use bit 3 for both.

Fixes: 1e3cb6c321be ("ASoC: nau8822: new codec driver")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An &lt;sammiee5311@gmail.com&gt;
Link: https://patch.msgid.link/20261008130953.2446692-7-sammiee5311@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>ASoC: wm8978: Fix the 128x oversampling switch bits</title>
<updated>2026-10-12T18:52:01Z</updated>
<author>
<name>HyeongJun An</name>
<email>sammiee5311@gmail.com</email>
</author>
<published>2026-10-08T13:09:51Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/laptop-kernel/commit/?id=d0567ca9a2faa33efbe5ae84ef7b86423a93bffd'/>
<id>urn:sha1:d0567ca9a2faa33efbe5ae84ef7b86423a93bffd</id>
<content type='text'>
The DAC and ADC 128x Oversampling Switches use bit 5 of R10 and R14.
Table 66 of the WM8978 datasheet puts DACOSR128 and ADCOSR128 at bit 3
of those registers.

In R14, bit 5 is inside HPFCUT[6:4], which the High Pass Cut Off
control owns. So turning on ADC oversampling changes the high pass
cut-off, and the oversampling bit cannot be set. In R10, bit 5 is
reserved, so the DAC switch has no effect.

Use bit 3 for both.

Fixes: 823dba519122 ("ASoC: Fix broken bitfield definitions in WM8978")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An &lt;sammiee5311@gmail.com&gt;
Link: https://patch.msgid.link/20261008130953.2446692-6-sammiee5311@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>ASoC: max98371: Fix the Speaker DHT Min Volume bits</title>
<updated>2026-10-12T18:52:00Z</updated>
<author>
<name>HyeongJun An</name>
<email>sammiee5311@gmail.com</email>
</author>
<published>2026-10-08T13:09:50Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/laptop-kernel/commit/?id=f7934340c56a84fc1b246ebf6b2e806d775f3b54'/>
<id>urn:sha1:f7934340c56a84fc1b246ebf6b2e806d775f3b54</id>
<content type='text'>
Register 0x31 holds two 4-bit fields. The datasheet puts SPK_GAIN_MIN
at bits 7:4 and DHT_VROT_PNT at bits 3:0. The Speaker DHT Min Volume
and Speaker DHT Rotation Volume controls both use bits 3:0.

So setting the minimum speaker gain changes the DHT rotation point, and
SPK_GAIN_MIN cannot be set.

Move Speaker DHT Min Volume to bits 7:4.

Fixes: ca2cd6bc6663 ("ASoC: Add max98371 codec driver")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An &lt;sammiee5311@gmail.com&gt;
Link: https://patch.msgid.link/20261008130953.2446692-5-sammiee5311@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>ASoC: pcm3168a: Fix the DAC zero flag polarity bit</title>
<updated>2026-10-12T18:52:00Z</updated>
<author>
<name>HyeongJun An</name>
<email>sammiee5311@gmail.com</email>
</author>
<published>2026-10-08T13:09:49Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/laptop-kernel/commit/?id=b26edc925c1cfa0184cd270ed81d4833db045ce0'/>
<id>urn:sha1:b26edc925c1cfa0184cd270ed81d4833db045ce0</id>
<content type='text'>
The DAC Zero Flag Polarity enum uses PCM3168A_DAC_ATSPDA_SHIFT, which
is bit 6 of register 70. That bit is ATSPDA, the attenuation speed,
which the DAC Volume Rate Multiplier enum already owns. The datasheet
puts ZREV, the zero flag polarity, at bit 0. The header defines
PCM3168A_DAC_ZREV_SHIFT for it, but nothing uses it.

So changing the zero flag polarity changes the attenuation speed, and
ZREV cannot be set.

Use PCM3168A_DAC_ZREV_SHIFT.

Fixes: a9b17a638af5 ("ASoC: pcm3168a: Add driver for pcm3168a codec")
Link: https://www.ti.com/lit/ds/symlink/pcm3168a.pdf
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An &lt;sammiee5311@gmail.com&gt;
Reviewed-by: Cezary Rojewski &lt;cezary.rojewski@intel.com&gt;
Link: https://patch.msgid.link/20261008130953.2446692-4-sammiee5311@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>ASoC: cs42l52: Fix the NG Type Switch bit</title>
<updated>2026-10-12T18:52:00Z</updated>
<author>
<name>HyeongJun An</name>
<email>sammiee5311@gmail.com</email>
</author>
<published>2026-10-08T13:09:48Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/laptop-kernel/commit/?id=8b08b98796d2da103f2432550c14a7c687e72080'/>
<id>urn:sha1:8b08b98796d2da103f2432550c14a7c687e72080</id>
<content type='text'>
The NG Type Switch enum selects between "Apply Specific" and "Apply
All", which is the NGALL bit. The datasheet puts NGALL at bit 7 of the
Noise Gate Control register. The enum uses bit 6, which is NG, the
noise gate enable owned by the NG Enable Switch. cs42l52.h names it
CS42L52_NG_ENABLE_SHIFT. cs42l56 has the same Noise Gate register and
puts its NG All Switch at bit 7.

So changing the noise gate type turns the noise gate on or off, and
NGALL cannot be set.

Use bit 7.

Fixes: dfe0f98b8d2e ("ASoC: Add support for CS42L52 Codec")
Link: https://statics.cirrus.com/pubs/proDatasheet/CS42L52_F2.pdf
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An &lt;sammiee5311@gmail.com&gt;
Link: https://patch.msgid.link/20261008130953.2446692-3-sammiee5311@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>ASoC: cs42l56: Put the Limiter Cushion control on the limiter register</title>
<updated>2026-10-12T18:51:59Z</updated>
<author>
<name>HyeongJun An</name>
<email>sammiee5311@gmail.com</email>
</author>
<published>2026-10-08T13:09:47Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/laptop-kernel/commit/?id=203436d2aeb7093290459e344e1912a418a6ebfd'/>
<id>urn:sha1:203436d2aeb7093290459e344e1912a418a6ebfd</id>
<content type='text'>
The Limiter Cushion control writes bits 4:2 of the ALC Thresholds
register. Those bits are ALCMIN, which the ALC MIN control owns. The
datasheet puts CUSH at bits 4:2 of the Limit Thresholds Control
register, next to LMAX, which the Limiter MAX control already uses.

So setting the limiter cushion changes the ALC minimum threshold, and
the cushion itself cannot be set.

Use CS42L56_LIM_THRESHOLD_CTL.

Fixes: 272b5edd3b8f ("ASoC: Add support for CS42L56 CODEC")
Link: https://statics.cirrus.com/pubs/proDatasheet/CS42L56_F2.pdf
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An &lt;sammiee5311@gmail.com&gt;
Link: https://patch.msgid.link/20261008130953.2446692-2-sammiee5311@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>ASoC: stm32: spdifrx: fix synchronization state check</title>
<updated>2026-10-12T18:22:55Z</updated>
<author>
<name>Avi Weiss</name>
<email>thnkslprpt@gmail.com</email>
</author>
<published>2026-10-11T03:54:59Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/laptop-kernel/commit/?id=0936bbd35a247665c64886135835faa3c3f4f29f'/>
<id>urn:sha1:0936bbd35a247665c64886135835faa3c3f4f29f</id>
<content type='text'>
The interrupt handler uses a logical AND to check whether SPDIFRX
was in the SYNC state before clearing errors. Since both SYNC (1)
and ENABLE (3) are nonzero, this also treats ENABLE as SYNC (and
any other non-zero value that might be added).

The logical &amp;&amp; basically just converts this to check for != 0.

So errors occurring while SPDIFRX is enabled cause the driver
to retry synch instead of disconnecting the PCM stream.

Fix is to change the logical &amp;&amp; to equality (==) and only retry
when exactly in sync state.

Fixes: 0c93c291321f2 ("ASoC: stm32: spdifrx: retry synchronization in sync state")
Signed-off-by: Avi Weiss &lt;thnkslprpt@gmail.com&gt;
Reviewed-by: Olivier Moysan &lt;olivier.moysan@foss.st.com&gt;
Link: https://patch.msgid.link/20261011035459.2289403-1-thnkslprpt@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>ASoC: Intel: avs: Reset the stream unless it is already prepared</title>
<updated>2026-10-12T17:59:55Z</updated>
<author>
<name>Sergey Tiraspolsky</name>
<email>stiraspo@gmail.com</email>
</author>
<published>2026-10-10T10:37:53Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/laptop-kernel/commit/?id=f6be9f558a83fe30a03bd3adae461c821a0cef8c'/>
<id>urn:sha1:f6be9f558a83fe30a03bd3adae461c821a0cef8c</id>
<content type='text'>
Commit cfca1637bc2b ("ASoC: Intel: avs: Unprepare a stream when XRUN
occurs") resets the HDA stream when -&gt;prepare() is called in the XRUN
state. User space does not always recover that way. PipeWire's ALSA
backend recovers from an underrun with snd_pcm_drop(), snd_pcm_prepare()
and a new start, so -&gt;prepare() runs in the SETUP state,
hdac_stream-&gt;prepared is still set and the reset is skipped. Every
recovery attempt then fails the same way:

  spa.alsa: hw:avsmax98927,1p: snd_pcm_avail after recover: Broken pipe

On a Google Pixelbook (Kaby Lake, max98927 speakers) this happens after
an occasional underrun during normal playback and silences the speakers
for one to four minutes, until the PCM is closed. It can be provoked by
stopping PipeWire with SIGSTOP for 0.5 s during playback: in one run
that single underrun led to 1297 failed recoveries over two minutes,
until the sink was suspended. A plain alsa-lib program that recovers
with snd_pcm_drop() and snd_pcm_prepare() hits the same loop, while
snd_pcm_prepare() straight from XRUN recovers at once.

Skip the reset only when the stream is already PREPARED, the repeated
-&gt;prepare() case the check exists for, and reset it otherwise. With
this change both kinds of recovery succeed with a single restart.

Fixes: cfca1637bc2b ("ASoC: Intel: avs: Unprepare a stream when XRUN occurs")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Sergey Tiraspolsky &lt;stiraspo@gmail.com&gt;
Acked-by: Cezary Rojewski &lt;cezary.rojewski@intel.com&gt;
Link: https://patch.msgid.link/20261010103753.16969-1-stiraspo@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
</feed>
