<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/include/sound, branch v4.19.162</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.19.162</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.19.162'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2020-07-29T08:16:58Z</updated>
<entry>
<title>ASoC: rt5670: Add new gpio1_is_ext_spk_en quirk and enable it on the Lenovo Miix 2 10</title>
<updated>2020-07-29T08:16:58Z</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2020-06-28T15:52:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2005c8285cb99db5ee24243d09db31321cc8381f'/>
<id>urn:sha1:2005c8285cb99db5ee24243d09db31321cc8381f</id>
<content type='text'>
commit 85ca6b17e2bb96b19caac3b02c003d670b66de96 upstream.

The Lenovo Miix 2 10 has a keyboard dock with extra speakers in the dock.
Rather then the ACL5672's GPIO1 pin being used as IRQ to the CPU, it is
actually used to enable the amplifier for these speakers
(the IRQ to the CPU comes directly from the jack-detect switch).

Add a quirk for having an ext speaker-amplifier enable pin on GPIO1
and replace the Lenovo Miix 2 10's dmi_system_id table entry's wrong
GPIO_DEV quirk (which needs to be renamed to GPIO1_IS_IRQ) with the
new RT5670_GPIO1_IS_EXT_SPK_EN quirk, so that we enable the external
speaker-amplifier as necessary.

Also update the ident field for the dmi_system_id table entry, the
Miix models are not Thinkpads.

Fixes: 67e03ff3f32f ("ASoC: codecs: rt5670: add Thinkpad Tablet 10 quirk")
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786723
Link: https://lore.kernel.org/r/20200628155231.71089-4-hdegoede@redhat.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ALSA: compress: fix partial_drain completion state</title>
<updated>2020-07-16T06:17:24Z</updated>
<author>
<name>Vinod Koul</name>
<email>vkoul@kernel.org</email>
</author>
<published>2020-06-29T13:47:37Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ab8dbdcbfbf8e2f225ea1b74485304652c2b0f90'/>
<id>urn:sha1:ab8dbdcbfbf8e2f225ea1b74485304652c2b0f90</id>
<content type='text'>
[ Upstream commit f79a732a8325dfbd570d87f1435019d7e5501c6d ]

On partial_drain completion we should be in SNDRV_PCM_STATE_RUNNING
state, so set that for partially draining streams in
snd_compr_drain_notify() and use a flag for partially draining streams

While at it, add locks for stream state change in
snd_compr_drain_notify() as well.

Fixes: f44f2a5417b2 ("ALSA: compress: fix drain calls blocking other compress functions (v6)")
Reviewed-by: Srinivas Kandagatla &lt;srinivas.kandagatla@linaro.org&gt;
Tested-by: Srinivas Kandagatla &lt;srinivas.kandagatla@linaro.org&gt;
Reviewed-by: Charles Keepax &lt;ckeepax@opensource.cirrus.com&gt;
Tested-by: Charles Keepax &lt;ckeepax@opensource.cirrus.com&gt;
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Link: https://lore.kernel.org/r/20200629134737.105993-4-vkoul@kernel.org
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ALSA: rawmidi: Fix racy buffer resize under concurrent accesses</title>
<updated>2020-05-20T06:18:47Z</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2020-05-07T11:44:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a507658fdb2ad8ca282b0eb42f2a40b805deb1e6'/>
<id>urn:sha1:a507658fdb2ad8ca282b0eb42f2a40b805deb1e6</id>
<content type='text'>
commit c1f6e3c818dd734c30f6a7eeebf232ba2cf3181d upstream.

The rawmidi core allows user to resize the runtime buffer via ioctl,
and this may lead to UAF when performed during concurrent reads or
writes: the read/write functions unlock the runtime lock temporarily
during copying form/to user-space, and that's the race window.

This patch fixes the hole by introducing a reference counter for the
runtime buffer read/write access and returns -EBUSY error when the
resize is performed concurrently against read/write.

Note that the ref count field is a simple integer instead of
refcount_t here, since the all contexts accessing the buffer is
basically protected with a spinlock, hence we need no expensive atomic
ops.  Also, note that this busy check is needed only against read /
write functions, and not in receive/transmit callbacks; the race can
happen only at the spinlock hole mentioned in the above, while the
whole function is protected for receive / transmit callbacks.

Reported-by: butt3rflyh4ck &lt;butterflyhuangxx@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/CAFcO6XMWpUVK_yzzCpp8_XP7+=oUpQvuBeCbMffEDkpe8jWrfg@mail.gmail.com
Link: https://lore.kernel.org/r/s5heerw3r5z.wl-tiwai@suse.de
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ALSA: rawmidi: Avoid bit fields for state flags</title>
<updated>2020-02-28T15:38:59Z</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2020-02-14T11:13:16Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=63495d1e1c7c4c6333359ce831ab865859c2d87d'/>
<id>urn:sha1:63495d1e1c7c4c6333359ce831ab865859c2d87d</id>
<content type='text'>
commit dfa9a5efe8b932a84b3b319250aa3ac60c20f876 upstream.

The rawmidi state flags (opened, append, active_sensing) are stored in
bit fields that can be potentially racy when concurrently accessed
without any locks.  Although the current code should be fine, there is
also no any real benefit by keeping the bitfields for this kind of
short number of members.

This patch changes those bit fields flags to the simple bool fields.
There should be no size increase of the snd_rawmidi_substream by this
change.

Reported-by: syzbot+576cc007eb9f2c968200@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/20200214111316.26939-4-tiwai@suse.de
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ASoC: wm97xx: fix uninitialized regmap pointer problem</title>
<updated>2020-01-27T13:50:01Z</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2018-11-02T15:18:21Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e82db5bec17e6baa0a3594bab5c24decc02f0aa0'/>
<id>urn:sha1:e82db5bec17e6baa0a3594bab5c24decc02f0aa0</id>
<content type='text'>
[ Upstream commit 576ce4075bfa0f03e0e91a89eecc539b3b828b08 ]

gcc notices that without either the ac97 bus or the pdata, we never
initialize the regmap pointer, which leads to an uninitialized variable
access:

sound/soc/codecs/wm9712.c: In function 'wm9712_soc_probe':
sound/soc/codecs/wm9712.c:666:2: error: 'regmap' may be used uninitialized in this function [-Werror=maybe-uninitialized]

Since that configuration is invalid, it's better to return an error
here. I tried to avoid adding complexity to the conditions, and turned
the #ifdef into a regular if(IS_ENABLED()) check for readability.
This in turn requires moving some header file declarations out of
an #ifdef.

The same code is used in three drivers, all of which I'm changing
the same way.

Fixes: 2ed1a8e0ce8d ("ASoC: wm9712: add ac97 new bus support")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ASoC: Define a set of DAPM pre/post-up events</title>
<updated>2019-10-11T16:20:47Z</updated>
<author>
<name>Oleksandr Suvorov</name>
<email>oleksandr.suvorov@toradex.com</email>
</author>
<published>2019-07-19T10:05:30Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=50090b75fa89b742e19a5e533c080662a8ca67e3'/>
<id>urn:sha1:50090b75fa89b742e19a5e533c080662a8ca67e3</id>
<content type='text'>
commit cfc8f568aada98f9608a0a62511ca18d647613e2 upstream.

Prepare to use SND_SOC_DAPM_PRE_POST_PMU definition to
reduce coming code size and make it more readable.

Cc: stable@vger.kernel.org
Signed-off-by: Oleksandr Suvorov &lt;oleksandr.suvorov@toradex.com&gt;
Reviewed-by: Marcel Ziswiler &lt;marcel.ziswiler@toradex.com&gt;
Reviewed-by: Igor Opaniuk &lt;igor.opaniuk@toradex.com&gt;
Reviewed-by: Fabio Estevam &lt;festevam@gmail.com&gt;
Link: https://lore.kernel.org/r/20190719100524.23300-2-oleksandr.suvorov@toradex.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ALSA: compress: Fix regression on compressed capture streams</title>
<updated>2019-08-16T08:12:47Z</updated>
<author>
<name>Charles Keepax</name>
<email>ckeepax@opensource.cirrus.com</email>
</author>
<published>2019-07-22T09:24:33Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b9e2fa1e15b7a9edfe77d0059a2c7e8f31c58a15'/>
<id>urn:sha1:b9e2fa1e15b7a9edfe77d0059a2c7e8f31c58a15</id>
<content type='text'>
[ Upstream commit 4475f8c4ab7b248991a60d9c02808dbb813d6be8 ]

A previous fix to the stop handling on compressed capture streams causes
some knock on issues. The previous fix updated snd_compr_drain_notify to
set the state back to PREPARED for capture streams. This causes some
issues however as the handling for snd_compr_poll differs between the
two states and some user-space applications were relying on the poll
failing after the stream had been stopped.

To correct this regression whilst still fixing the original problem the
patch was addressing, update the capture handling to skip the PREPARED
state rather than skipping the SETUP state as it has done until now.

Fixes: 4f2ab5e1d13d ("ALSA: compress: Fix stop handling on compressed capture streams")
Signed-off-by: Charles Keepax &lt;ckeepax@opensource.cirrus.com&gt;
Acked-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ALSA: compress: Fix stop handling on compressed capture streams</title>
<updated>2019-02-12T18:47:23Z</updated>
<author>
<name>Charles Keepax</name>
<email>ckeepax@opensource.cirrus.com</email>
</author>
<published>2019-02-05T16:29:40Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=93e7d51029bd366c0f4bd432edb9fbfa8430f543'/>
<id>urn:sha1:93e7d51029bd366c0f4bd432edb9fbfa8430f543</id>
<content type='text'>
commit 4f2ab5e1d13d6aa77c55f4914659784efd776eb4 upstream.

It is normal user behaviour to start, stop, then start a stream
again without closing it. Currently this works for compressed
playback streams but not capture ones.

The states on a compressed capture stream go directly from OPEN to
PREPARED, unlike a playback stream which moves to SETUP and waits
for a write of data before moving to PREPARED. Currently however,
when a stop is sent the state is set to SETUP for both types of
streams. This leaves a capture stream in the situation where a new
start can't be sent as that requires the state to be PREPARED and
a new set_params can't be sent as that requires the state to be
OPEN. The only option being to close the stream, and then reopen.

Correct this issues by allowing snd_compr_drain_notify to set the
state depending on the stream direction, as we already do in
set_params.

Fixes: 49bb6402f1aa ("ALSA: compress_core: Add support for capture streams")
Signed-off-by: Charles Keepax &lt;ckeepax@opensource.cirrus.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ALSA: pcm: Fix interval evaluation with openmin/max</title>
<updated>2018-12-13T08:16:16Z</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2018-11-29T11:05:19Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a2928e74981266381b5df13f150384a5c5120ff3'/>
<id>urn:sha1:a2928e74981266381b5df13f150384a5c5120ff3</id>
<content type='text'>
commit 5363857b916c1f48027e9b96ee8be8376bf20811 upstream.

As addressed in alsa-lib (commit b420056604f0), we need to fix the
case where the evaluation of PCM interval "(x x+1]" leading to
-EINVAL.  After applying rules, such an interval may be translated as
"(x x+1)".

Fixes: ff2d6acdf6f1 ("ALSA: pcm: Fix snd_interval_refine first/last with open min/max")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Merge tag 'asoc-v4.19-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus</title>
<updated>2018-09-17T16:59:21Z</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2018-09-17T16:59:21Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=196f4eeeb78f53e0a598db8f9408b6f8b270c355'/>
<id>urn:sha1:196f4eeeb78f53e0a598db8f9408b6f8b270c355</id>
<content type='text'>
ASoC: Fixes for v4.19

This is the usual set of small fixes scatterd around various drivers,
plus one fix for DAPM and a UAPI build fix.  There's not a huge amount
that stands out here relative to anything else.
</content>
</entry>
</feed>
