<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/include/sound, branch v5.0.16</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.0.16</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.0.16'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2019-05-10T16:36:05Z</updated>
<entry>
<title>ASoC: dpcm: prevent snd_soc_dpcm use after free</title>
<updated>2019-05-10T16:36:05Z</updated>
<author>
<name>KaiChieh Chuang</name>
<email>kaichieh.chuang@mediatek.com</email>
</author>
<published>2019-03-08T05:05:53Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f4f4303c6d54d7d7238776ff9afba7fbaeddf384'/>
<id>urn:sha1:f4f4303c6d54d7d7238776ff9afba7fbaeddf384</id>
<content type='text'>
[ Upstream commit a9764869779081e8bf24da07ac040e8f3efcf13a ]

The dpcm get from fe_clients/be_clients
may be free before use

Add a spin lock at snd_soc_card level,
to protect the dpcm instance.
The lock may be used in atomic context, so use spin lock.

Use irq spin lock version,
since the lock may be used in interrupts.

possible race condition between
void dpcm_be_disconnect(
	...
	list_del(&amp;dpcm-&gt;list_be);
	list_del(&amp;dpcm-&gt;list_fe);
	kfree(dpcm);
	...

and
	for_each_dpcm_fe()
	for_each_dpcm_be*()

race condition example
Thread 1:
    snd_soc_dapm_mixer_update_power()
        -&gt; soc_dpcm_runtime_update()
            -&gt; dpcm_be_disconnect()
                -&gt; kfree(dpcm);
Thread 2:
    dpcm_fe_dai_trigger()
        -&gt; dpcm_be_dai_trigger()
            -&gt; snd_soc_dpcm_can_be_free_stop()
                -&gt; if (dpcm-&gt;fe == fe)

Excpetion Scenario:
	two FE link to same BE
	FE1 -&gt; BE
	FE2 -&gt;

	Thread 1: switch of mixer between FE2 -&gt; BE
	Thread 2: pcm_stop FE1

Exception:

Unable to handle kernel paging request at virtual address dead0000000000e0

pc=&lt;&gt; [&lt;ffffff8960e2cd10&gt;] dpcm_be_dai_trigger+0x29c/0x47c
	sound/soc/soc-pcm.c:3226
		if (dpcm-&gt;fe == fe)
lr=&lt;&gt; [&lt;ffffff8960e2f694&gt;] dpcm_fe_dai_do_trigger+0x94/0x26c

Backtrace:
[&lt;ffffff89602dba80&gt;] notify_die+0x68/0xb8
[&lt;ffffff896028c7dc&gt;] die+0x118/0x2a8
[&lt;ffffff89602a2f84&gt;] __do_kernel_fault+0x13c/0x14c
[&lt;ffffff89602a27f4&gt;] do_translation_fault+0x64/0xa0
[&lt;ffffff8960280cf8&gt;] do_mem_abort+0x4c/0xd0
[&lt;ffffff8960282ad0&gt;] el1_da+0x24/0x40
[&lt;ffffff8960e2cd10&gt;] dpcm_be_dai_trigger+0x29c/0x47c
[&lt;ffffff8960e2f694&gt;] dpcm_fe_dai_do_trigger+0x94/0x26c
[&lt;ffffff8960e2edec&gt;] dpcm_fe_dai_trigger+0x3c/0x44
[&lt;ffffff8960de5588&gt;] snd_pcm_do_stop+0x50/0x5c
[&lt;ffffff8960dded24&gt;] snd_pcm_action+0xb4/0x13c
[&lt;ffffff8960ddfdb4&gt;] snd_pcm_drop+0xa0/0x128
[&lt;ffffff8960de69bc&gt;] snd_pcm_common_ioctl+0x9d8/0x30f0
[&lt;ffffff8960de1cac&gt;] snd_pcm_ioctl_compat+0x29c/0x2f14
[&lt;ffffff89604c9d60&gt;] compat_SyS_ioctl+0x128/0x244
[&lt;ffffff8960283740&gt;] el0_svc_naked+0x34/0x38
[&lt;ffffffffffffffff&gt;] 0xffffffffffffffff

Signed-off-by: KaiChieh Chuang &lt;kaichieh.chuang@mediatek.com&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>ALSA: compress: Fix stop handling on compressed capture streams</title>
<updated>2019-02-05T21:01:41Z</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=4f2ab5e1d13d6aa77c55f4914659784efd776eb4'/>
<id>urn:sha1:4f2ab5e1d13d6aa77c55f4914659784efd776eb4</id>
<content type='text'>
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;
</content>
</entry>
<entry>
<title>ALSA: hda - Serialize codec registrations</title>
<updated>2019-02-01T10:30:09Z</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2019-01-30T16:46:03Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=305a0ade180981686eec1f92aa6252a7c6ebb1cf'/>
<id>urn:sha1:305a0ade180981686eec1f92aa6252a7c6ebb1cf</id>
<content type='text'>
In the current code, the codec registration may happen both at the
codec bind time and the end of the controller probe time.  In a rare
occasion, they race with each other, leading to Oops due to the still
uninitialized card device.

This patch introduces a simple flag to prevent the codec registration
at the codec bind time as long as the controller probe is going on.
The controller probe invokes snd_card_register() that does the whole
registration task, and we don't need to register each piece
beforehand.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
</entry>
<entry>
<title>Merge tag 'asoc-fix-v5.0-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus</title>
<updated>2019-01-18T14:17:17Z</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2019-01-18T14:17:17Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b3c4014c2b25856b9aeaf0792df330e417a8bd7b'/>
<id>urn:sha1:b3c4014c2b25856b9aeaf0792df330e417a8bd7b</id>
<content type='text'>
ASoC: Fixes for v5.0

Quite a big batch of fixes here.  There's a couple of things going on,
the main one is that we found some issues with not deferring probe when
we should, causing us to skip some driver initialization.  The fixes for
this then in turn exposed some issues with how we were searching for
components which had previously gone unnoticed due to the original
issue.

There's also been the normal driver specific stuff and there's been what
looks like several batches of automated scanning for issues which have
generated quite a large set of smaller fixes for potential crashes and
missed error handling.
</content>
</entry>
<entry>
<title>ASoC: soc-core: fix init platform memory handling</title>
<updated>2019-01-14T22:48:16Z</updated>
<author>
<name>Curtis Malainey</name>
<email>cujomalainey@chromium.org</email>
</author>
<published>2019-01-11T00:21:04Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=09ac6a817bd687e7f5dac00470262efdd72f9319'/>
<id>urn:sha1:09ac6a817bd687e7f5dac00470262efdd72f9319</id>
<content type='text'>
snd_soc_init_platform initializes pointers to snd_soc_dai_link which is
statically allocated and it does this by devm_kzalloc. In the event of
an EPROBE_DEFER the memory will be freed and the pointers are left
dangling. snd_soc_init_platform sees the dangling pointers and assumes
they are pointing to initialized memory and does not reallocate them on
the second probe attempt which results in a use after free bug since
devm has freed the memory from the first probe attempt.

Since the intention for snd_soc_dai_link-&gt;platform is that it can be set
statically by the machine driver we need to respect the pointer in the
event we did not set it but still catch dangling pointers. The solution
is to add a flag to track whether the pointer was dynamically allocated
or not.

Signed-off-by: Curtis Malainey &lt;cujomalainey@chromium.org&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>ALSA: HD-Audio: SKL+: force HDaudio legacy or SKL+ driver selection</title>
<updated>2018-12-19T17:07:23Z</updated>
<author>
<name>Pierre-Louis Bossart</name>
<email>pierre-louis.bossart@linux.intel.com</email>
</author>
<published>2018-12-15T20:07:23Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d82b51c855a20eb456ac09f2f40ea98312373263'/>
<id>urn:sha1:d82b51c855a20eb456ac09f2f40ea98312373263</id>
<content type='text'>
For HDaudio and Skylake drivers, add module parameter "pci_binding"

When pci_binding == 0 (AUTO), the PCI class/subclass info is used to
select drivers based on the presence of the DSP.

pci_binding == 1 (LEGACY) forces the use of the HDAudio legacy driver,
even if the DSP is present.

pci_binding == 2 (ASOC) forces the use of the ASOC driver. The
information on the DSP presence is bypassed.

The value for the module parameter needs to be identical for both
drivers. This parameter is intended as a back-up solution if the
automatic detection fails or when the DSP usage fails. Such cases
should be reported on the alsa-devel mailing list for analysis.

Signed-off-by: Pierre-Louis Bossart &lt;pierre-louis.bossart@linux.intel.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
</entry>
<entry>
<title>ALSA: HDA: export process_unsol_events()</title>
<updated>2018-12-19T17:07:18Z</updated>
<author>
<name>Keyon Jie</name>
<email>yang.jie@linux.intel.com</email>
</author>
<published>2018-12-11T21:30:27Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=18d43c9b88eb335440c5e769eb6c2d5bc908dc61'/>
<id>urn:sha1:18d43c9b88eb335440c5e769eb6c2d5bc908dc61</id>
<content type='text'>
The SOF implementation does not rely on the hdac_bus library, however
for HDMI and HDaudio codec support it does need to deal with
unsolicited events. Instead of re-inventing the wheel, export this
symbol to reuse this part of the library directly.

Signed-off-by: Keyon Jie &lt;yang.jie@linux.intel.com&gt;
Signed-off-by: Pierre-Louis Bossart &lt;pierre-louis.bossart@linux.intel.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
</entry>
<entry>
<title>Merge tag 'asoc-v4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next</title>
<updated>2018-12-18T13:59:56Z</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2018-12-18T13:59:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ed49e839199e73966b9ff5946c3e87759827b40e'/>
<id>urn:sha1:ed49e839199e73966b9ff5946c3e87759827b40e</id>
<content type='text'>
ASoC: Updates for v4.21

Not much work on the core this time around but we've seen quite a bit of
driver work, including on the generic DT drivers.  There's also a large
part of the diff from a merge of the DaVinci and OMAP directories, along
with some active development there:

 - Preparatory work from Morimoto-san for merging the audio-graph and
   audio-graph-scu cards.
 - A merge of the TI OMAP and DaVinci directories, the OMAP product line
   has been merged into the DaVinci product line so there is now a lot
   of IP sharing which meant that the split directories just got in the
   way.  This has pulled in a few architecture changes as well.
 - A big cleanup of the Maxim MAX9867 driver from Ladislav Michl.
 - Support for Asahi Kaesi AKM4118, AMD ACP3x, Intel platforms with
   RT5660, Meson AXG S/PDIF inputs, several Qualcomm IPs and Xilinx I2S
   controllers.
</content>
</entry>
<entry>
<title>Merge branch 'asoc-4.21' into asoc-next</title>
<updated>2018-12-18T12:23:59Z</updated>
<author>
<name>Mark Brown</name>
<email>broonie@kernel.org</email>
</author>
<published>2018-12-18T12:23:59Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a7a850dba82498a1e050d8d153cae67ce0edb3b2'/>
<id>urn:sha1:a7a850dba82498a1e050d8d153cae67ce0edb3b2</id>
<content type='text'>
</content>
</entry>
<entry>
<title>ALSA: soc-compress: add support to snd_compr_set_runtime_buffer()</title>
<updated>2018-12-14T12:43:41Z</updated>
<author>
<name>Srinivas Kandagatla</name>
<email>srinivas.kandagatla@linaro.org</email>
</author>
<published>2018-11-15T18:13:20Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ba02eed9f300b6512181d526311d4e11aaa9714f'/>
<id>urn:sha1:ba02eed9f300b6512181d526311d4e11aaa9714f</id>
<content type='text'>
Existing compress offload code allocates data buffers using simple kmalloc,
however there are situations where these buffers have to be mapped
in smmu. So provide a way to set the runtime buffer by the driver itself,
simillar to what we do with pcm.

This patch adds support to set runtime dma buffer on compressed stream.

Signed-off-by: Srinivas Kandagatla &lt;srinivas.kandagatla@linaro.org&gt;
Acked-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
</feed>
