<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/sound, branch v4.5-rc3</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>ALSA: timer: Fix leftover link at closing</title>
<updated>2016-02-04T16:19:09+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2016-02-04T16:06:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=094fd3be87b0f102589e2d5c3fa5d06b7e20496d'/>
<id>094fd3be87b0f102589e2d5c3fa5d06b7e20496d</id>
<content type='text'>
In ALSA timer core, the active timer instance is managed in
active_list linked list.  Each element is added / removed dynamically
at timer start, stop and in timer interrupt.  The problem is that
snd_timer_interrupt() has a thinko and leaves the element in
active_list when it's the last opened element.  This eventually leads
to list corruption or use-after-free error.

This hasn't been revealed because we used to delete the list forcibly
in snd_timer_stop() in the past.  However, the recent fix avoids the
double-stop behavior (in commit [f784beb75ce8: ALSA: timer: Fix link
corruption due to double start or stop]), and this leak hits reality.

This patch fixes the link management in snd_timer_interrupt().  Now it
simply unlinks no matter which stream is.

BugLink: http://lkml.kernel.org/r/CACT4Y+Yy2aukHP-EDp8-ziNqNNmb-NTf=jDWXMP7jB8HDa2vng@mail.gmail.com
Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In ALSA timer core, the active timer instance is managed in
active_list linked list.  Each element is added / removed dynamically
at timer start, stop and in timer interrupt.  The problem is that
snd_timer_interrupt() has a thinko and leaves the element in
active_list when it's the last opened element.  This eventually leads
to list corruption or use-after-free error.

This hasn't been revealed because we used to delete the list forcibly
in snd_timer_stop() in the past.  However, the recent fix avoids the
double-stop behavior (in commit [f784beb75ce8: ALSA: timer: Fix link
corruption due to double start or stop]), and this leak hits reality.

This patch fixes the link management in snd_timer_interrupt().  Now it
simply unlinks no matter which stream is.

BugLink: http://lkml.kernel.org/r/CACT4Y+Yy2aukHP-EDp8-ziNqNNmb-NTf=jDWXMP7jB8HDa2vng@mail.gmail.com
Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'topic/core-fixes' into for-linus</title>
<updated>2016-02-03T13:52:41+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2016-02-03T13:52:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2e5dc73fe1c4befaf894ca357edb5443b82148b1'/>
<id>2e5dc73fe1c4befaf894ca357edb5443b82148b1</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: seq: Fix lockdep warnings due to double mutex locks</title>
<updated>2016-02-03T13:51:51+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2016-02-03T07:32:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=7f0973e973cd74aa40747c9d38844560cd184ee8'/>
<id>7f0973e973cd74aa40747c9d38844560cd184ee8</id>
<content type='text'>
The port subscription code uses double mutex locks for source and
destination ports, and this may become racy once when wrongly set up.
It leads to lockdep warning splat, typically triggered by fuzzer like
syzkaller, although the actual deadlock hasn't been seen, so far.

This patch simplifies the handling by reducing to two single locks, so
that no lockdep warning will be trigger any longer.

By splitting to two actions, a still-in-progress element shall be
added in one list while handling another.  For ignoring this element,
a new check is added in deliver_to_subscribers().

Along with it, the code to add/remove the subscribers list element was
cleaned up and refactored.

BugLink: http://lkml.kernel.org/r/CACT4Y+aKQXV7xkBW9hpQbzaDO7LrUvohxWh-UwMxXjDy-yBD=A@mail.gmail.com
Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Tested-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The port subscription code uses double mutex locks for source and
destination ports, and this may become racy once when wrongly set up.
It leads to lockdep warning splat, typically triggered by fuzzer like
syzkaller, although the actual deadlock hasn't been seen, so far.

This patch simplifies the handling by reducing to two single locks, so
that no lockdep warning will be trigger any longer.

By splitting to two actions, a still-in-progress element shall be
added in one list while handling another.  For ignoring this element,
a new check is added in deliver_to_subscribers().

Along with it, the code to add/remove the subscribers list element was
cleaned up and refactored.

BugLink: http://lkml.kernel.org/r/CACT4Y+aKQXV7xkBW9hpQbzaDO7LrUvohxWh-UwMxXjDy-yBD=A@mail.gmail.com
Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Tested-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: rawmidi: Fix race at copying &amp; updating the position</title>
<updated>2016-02-03T13:51:42+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2016-02-03T13:41:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=81f577542af15640cbcb6ef68baa4caa610cbbfc'/>
<id>81f577542af15640cbcb6ef68baa4caa610cbbfc</id>
<content type='text'>
The rawmidi read and write functions manage runtime stream status
such as runtime-&gt;appl_ptr and runtime-&gt;avail.  These point where to
copy the new data and how many bytes have been copied (or to be
read).  The problem is that rawmidi read/write call copy_from_user()
or copy_to_user(), and the runtime spinlock is temporarily unlocked
and relocked while copying user-space.  Since the current code
advances and updates the runtime status after the spin unlock/relock,
the copy and the update may be asynchronous, and eventually
runtime-&gt;avail might go to a negative value when many concurrent
accesses are done.  This may lead to memory corruption in the end.

For fixing this race, in this patch, the status update code is
performed in the same lock before the temporary unlock.  Also, the
spinlock is now taken more widely in snd_rawmidi_kernel_read1() for
protecting more properly during the whole operation.

BugLink: http://lkml.kernel.org/r/CACT4Y+b-dCmNf1GpgPKfDO0ih+uZCL2JV4__j-r1kdhPLSgQCQ@mail.gmail.com
Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Tested-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The rawmidi read and write functions manage runtime stream status
such as runtime-&gt;appl_ptr and runtime-&gt;avail.  These point where to
copy the new data and how many bytes have been copied (or to be
read).  The problem is that rawmidi read/write call copy_from_user()
or copy_to_user(), and the runtime spinlock is temporarily unlocked
and relocked while copying user-space.  Since the current code
advances and updates the runtime status after the spin unlock/relock,
the copy and the update may be asynchronous, and eventually
runtime-&gt;avail might go to a negative value when many concurrent
accesses are done.  This may lead to memory corruption in the end.

For fixing this race, in this patch, the status update code is
performed in the same lock before the temporary unlock.  Also, the
spinlock is now taken more widely in snd_rawmidi_kernel_read1() for
protecting more properly during the whole operation.

BugLink: http://lkml.kernel.org/r/CACT4Y+b-dCmNf1GpgPKfDO0ih+uZCL2JV4__j-r1kdhPLSgQCQ@mail.gmail.com
Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Tested-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: rawmidi: Make snd_rawmidi_transmit() race-free</title>
<updated>2016-02-03T13:51:28+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2016-01-31T10:57:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=06ab30034ed9c200a570ab13c017bde248ddb2a6'/>
<id>06ab30034ed9c200a570ab13c017bde248ddb2a6</id>
<content type='text'>
A kernel WARNING in snd_rawmidi_transmit_ack() is triggered by
syzkaller fuzzer:
  WARNING: CPU: 1 PID: 20739 at sound/core/rawmidi.c:1136
Call Trace:
 [&lt;     inline     &gt;] __dump_stack lib/dump_stack.c:15
 [&lt;ffffffff82999e2d&gt;] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
 [&lt;ffffffff81352089&gt;] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
 [&lt;ffffffff813522b9&gt;] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
 [&lt;ffffffff84f80bd5&gt;] snd_rawmidi_transmit_ack+0x275/0x400 sound/core/rawmidi.c:1136
 [&lt;ffffffff84fdb3c1&gt;] snd_virmidi_output_trigger+0x4b1/0x5a0 sound/core/seq/seq_virmidi.c:163
 [&lt;     inline     &gt;] snd_rawmidi_output_trigger sound/core/rawmidi.c:150
 [&lt;ffffffff84f87ed9&gt;] snd_rawmidi_kernel_write1+0x549/0x780 sound/core/rawmidi.c:1223
 [&lt;ffffffff84f89fd3&gt;] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1273
 [&lt;ffffffff817b0323&gt;] __vfs_write+0x113/0x480 fs/read_write.c:528
 [&lt;ffffffff817b1db7&gt;] vfs_write+0x167/0x4a0 fs/read_write.c:577
 [&lt;     inline     &gt;] SYSC_write fs/read_write.c:624
 [&lt;ffffffff817b50a1&gt;] SyS_write+0x111/0x220 fs/read_write.c:616
 [&lt;ffffffff86336c36&gt;] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185

Also a similar warning is found but in another path:
Call Trace:
 [&lt;     inline     &gt;] __dump_stack lib/dump_stack.c:15
 [&lt;ffffffff82be2c0d&gt;] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
 [&lt;ffffffff81355139&gt;] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
 [&lt;ffffffff81355369&gt;] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
 [&lt;ffffffff8527e69a&gt;] rawmidi_transmit_ack+0x24a/0x3b0 sound/core/rawmidi.c:1133
 [&lt;ffffffff8527e851&gt;] snd_rawmidi_transmit_ack+0x51/0x80 sound/core/rawmidi.c:1163
 [&lt;ffffffff852d9046&gt;] snd_virmidi_output_trigger+0x2b6/0x570 sound/core/seq/seq_virmidi.c:185
 [&lt;     inline     &gt;] snd_rawmidi_output_trigger sound/core/rawmidi.c:150
 [&lt;ffffffff85285a0b&gt;] snd_rawmidi_kernel_write1+0x4bb/0x760 sound/core/rawmidi.c:1252
 [&lt;ffffffff85287b73&gt;] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1302
 [&lt;ffffffff817ba5f3&gt;] __vfs_write+0x113/0x480 fs/read_write.c:528
 [&lt;ffffffff817bc087&gt;] vfs_write+0x167/0x4a0 fs/read_write.c:577
 [&lt;     inline     &gt;] SYSC_write fs/read_write.c:624
 [&lt;ffffffff817bf371&gt;] SyS_write+0x111/0x220 fs/read_write.c:616
 [&lt;ffffffff86660276&gt;] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185

In the former case, the reason is that virmidi has an open code
calling snd_rawmidi_transmit_ack() with the value calculated outside
the spinlock.   We may use snd_rawmidi_transmit() in a loop just for
consuming the input data, but even there, there is a race between
snd_rawmidi_transmit_peek() and snd_rawmidi_tranmit_ack().

Similarly in the latter case, it calls snd_rawmidi_transmit_peek() and
snd_rawmidi_tranmit_ack() separately without protection, so they are
racy as well.

The patch tries to address these issues by the following ways:
- Introduce the unlocked versions of snd_rawmidi_transmit_peek() and
  snd_rawmidi_transmit_ack() to be called inside the explicit lock.
- Rewrite snd_rawmidi_transmit() to be race-free (the former case).
- Make the split calls (the latter case) protected in the rawmidi spin
  lock.

BugLink: http://lkml.kernel.org/r/CACT4Y+YPq1+cYLkadwjWa5XjzF1_Vki1eHnVn-Lm0hzhSpu5PA@mail.gmail.com
BugLink: http://lkml.kernel.org/r/CACT4Y+acG4iyphdOZx47Nyq_VHGbpJQK-6xNpiqUjaZYqsXOGw@mail.gmail.com
Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Tested-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A kernel WARNING in snd_rawmidi_transmit_ack() is triggered by
syzkaller fuzzer:
  WARNING: CPU: 1 PID: 20739 at sound/core/rawmidi.c:1136
Call Trace:
 [&lt;     inline     &gt;] __dump_stack lib/dump_stack.c:15
 [&lt;ffffffff82999e2d&gt;] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
 [&lt;ffffffff81352089&gt;] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
 [&lt;ffffffff813522b9&gt;] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
 [&lt;ffffffff84f80bd5&gt;] snd_rawmidi_transmit_ack+0x275/0x400 sound/core/rawmidi.c:1136
 [&lt;ffffffff84fdb3c1&gt;] snd_virmidi_output_trigger+0x4b1/0x5a0 sound/core/seq/seq_virmidi.c:163
 [&lt;     inline     &gt;] snd_rawmidi_output_trigger sound/core/rawmidi.c:150
 [&lt;ffffffff84f87ed9&gt;] snd_rawmidi_kernel_write1+0x549/0x780 sound/core/rawmidi.c:1223
 [&lt;ffffffff84f89fd3&gt;] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1273
 [&lt;ffffffff817b0323&gt;] __vfs_write+0x113/0x480 fs/read_write.c:528
 [&lt;ffffffff817b1db7&gt;] vfs_write+0x167/0x4a0 fs/read_write.c:577
 [&lt;     inline     &gt;] SYSC_write fs/read_write.c:624
 [&lt;ffffffff817b50a1&gt;] SyS_write+0x111/0x220 fs/read_write.c:616
 [&lt;ffffffff86336c36&gt;] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185

Also a similar warning is found but in another path:
Call Trace:
 [&lt;     inline     &gt;] __dump_stack lib/dump_stack.c:15
 [&lt;ffffffff82be2c0d&gt;] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
 [&lt;ffffffff81355139&gt;] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
 [&lt;ffffffff81355369&gt;] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
 [&lt;ffffffff8527e69a&gt;] rawmidi_transmit_ack+0x24a/0x3b0 sound/core/rawmidi.c:1133
 [&lt;ffffffff8527e851&gt;] snd_rawmidi_transmit_ack+0x51/0x80 sound/core/rawmidi.c:1163
 [&lt;ffffffff852d9046&gt;] snd_virmidi_output_trigger+0x2b6/0x570 sound/core/seq/seq_virmidi.c:185
 [&lt;     inline     &gt;] snd_rawmidi_output_trigger sound/core/rawmidi.c:150
 [&lt;ffffffff85285a0b&gt;] snd_rawmidi_kernel_write1+0x4bb/0x760 sound/core/rawmidi.c:1252
 [&lt;ffffffff85287b73&gt;] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1302
 [&lt;ffffffff817ba5f3&gt;] __vfs_write+0x113/0x480 fs/read_write.c:528
 [&lt;ffffffff817bc087&gt;] vfs_write+0x167/0x4a0 fs/read_write.c:577
 [&lt;     inline     &gt;] SYSC_write fs/read_write.c:624
 [&lt;ffffffff817bf371&gt;] SyS_write+0x111/0x220 fs/read_write.c:616
 [&lt;ffffffff86660276&gt;] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185

In the former case, the reason is that virmidi has an open code
calling snd_rawmidi_transmit_ack() with the value calculated outside
the spinlock.   We may use snd_rawmidi_transmit() in a loop just for
consuming the input data, but even there, there is a race between
snd_rawmidi_transmit_peek() and snd_rawmidi_tranmit_ack().

Similarly in the latter case, it calls snd_rawmidi_transmit_peek() and
snd_rawmidi_tranmit_ack() separately without protection, so they are
racy as well.

The patch tries to address these issues by the following ways:
- Introduce the unlocked versions of snd_rawmidi_transmit_peek() and
  snd_rawmidi_transmit_ack() to be called inside the explicit lock.
- Rewrite snd_rawmidi_transmit() to be race-free (the former case).
- Make the split calls (the latter case) protected in the rawmidi spin
  lock.

BugLink: http://lkml.kernel.org/r/CACT4Y+YPq1+cYLkadwjWa5XjzF1_Vki1eHnVn-Lm0hzhSpu5PA@mail.gmail.com
BugLink: http://lkml.kernel.org/r/CACT4Y+acG4iyphdOZx47Nyq_VHGbpJQK-6xNpiqUjaZYqsXOGw@mail.gmail.com
Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Tested-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: hda - Add fixup for Mac Mini 7,1 model</title>
<updated>2016-02-03T11:32:51+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2016-02-03T11:32:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2154cc0e2d4ae15132d005d17e473327c70c9a06'/>
<id>2154cc0e2d4ae15132d005d17e473327c70c9a06</id>
<content type='text'>
Mac Mini 7,1 model with CS4208 codec reports the headphone jack
detection wrongly in an inverted way.  Moreover, the advertised pins
for the audio input and SPDIF output have actually no jack detection.

This patch addresses these issues.  The inv_jack_detect flag is set
for fixing the headphone jack detection, and the pin configs for audio
input and SPDIF output are marked as non-detectable.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105161
Report-and-tested-by: moosotc@gmail.com
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Mac Mini 7,1 model with CS4208 codec reports the headphone jack
detection wrongly in an inverted way.  Moreover, the advertised pins
for the audio input and SPDIF output have actually no jack detection.

This patch addresses these issues.  The inv_jack_detect flag is set
for fixing the headphone jack detection, and the pin configs for audio
input and SPDIF output are marked as non-detectable.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105161
Report-and-tested-by: moosotc@gmail.com
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: hda/realtek - Support headset mode for ALC225</title>
<updated>2016-02-03T08:05:02+00:00</updated>
<author>
<name>Kailang Yang</name>
<email>kailang@realtek.com</email>
</author>
<published>2016-02-03T07:09:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=4cc9b9d627af2c443cf98e651e3738d84f991cec'/>
<id>4cc9b9d627af2c443cf98e651e3738d84f991cec</id>
<content type='text'>
Support headset mode for ALC225 platforms.

Signed-off-by: Kailang Yang &lt;kailang@realtek.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.4+
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Support headset mode for ALC225 platforms.

Signed-off-by: Kailang Yang &lt;kailang@realtek.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.4+
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: hda/realtek - Support Dell headset mode for ALC225</title>
<updated>2016-02-03T08:04:54+00:00</updated>
<author>
<name>Kailang Yang</name>
<email>kailang@realtek.com</email>
</author>
<published>2016-02-03T07:20:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=cfc5a845e62853edd36e564c23c64588f4adcae6'/>
<id>cfc5a845e62853edd36e564c23c64588f4adcae6</id>
<content type='text'>
Dell create new platform with ALC298 codec.
This patch will enable headset mode for ALC225/ALC3253 platform.

Signed-off-by: Kailang Yang &lt;kailang@realtek.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.4+
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Dell create new platform with ALC298 codec.
This patch will enable headset mode for ALC225/ALC3253 platform.

Signed-off-by: Kailang Yang &lt;kailang@realtek.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.4+
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: hda/realtek - New codec support of ALC225</title>
<updated>2016-02-03T08:04:42+00:00</updated>
<author>
<name>Kailang Yang</name>
<email>kailang@realtek.com</email>
</author>
<published>2016-02-03T07:03:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=4231430da9607fb2eb7ea92f3b93ceef3bc2ed93'/>
<id>4231430da9607fb2eb7ea92f3b93ceef3bc2ed93</id>
<content type='text'>
Add new support for ALC225, yet another variant of ALC298 codec.

Signed-off-by: Kailang Yang &lt;kailang@realtek.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 4.4+
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add new support for ALC225, yet another variant of ALC298 codec.

Signed-off-by: Kailang Yang &lt;kailang@realtek.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 4.4+
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: timer: Sync timer deletion at closing the system timer</title>
<updated>2016-02-02T23:15:42+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2016-02-02T13:14:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f146357f069e71aff8e474c625bcebcd3094b3ab'/>
<id>f146357f069e71aff8e474c625bcebcd3094b3ab</id>
<content type='text'>
ALSA timer core framework has no sync point at stopping because it's
called inside the spinlock.  Thus we need a sync point at close for
avoiding the stray timer task.  This is simply done by implementing
the close callback just calling del_timer_sync().  (It's harmless to
call it unconditionally, as the core timer itself cares of the already
deleted timer instance.)

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ALSA timer core framework has no sync point at stopping because it's
called inside the spinlock.  Thus we need a sync point at close for
avoiding the stray timer task.  This is simply done by implementing
the close callback just calling del_timer_sync().  (It's harmless to
call it unconditionally, as the core timer itself cares of the already
deleted timer instance.)

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
</feed>
