linux-toradex.git/sound, branch v2.6.32.69 Linux kernel for Apalis and Colibri modules sound/oss: fix deadlock in sequencer_ioctl(SNDCTL_SEQ_OUTOFBAND) 2015-05-24T08:10:56+00:00 Alexey Khoroshilov khoroshilov@ispras.ru 2015-04-17T23:53:25+00:00 c8412c6c97217654c7a6d9b9030f7910ca9a0b82 A deadlock can be initiated by userspace via ioctl(SNDCTL_SEQ_OUTOFBAND) on /dev/sequencer with TMR_ECHO midi event. In this case the control flow is: sound_ioctl() -> case SND_DEV_SEQ: case SND_DEV_SEQ2: sequencer_ioctl() -> case SNDCTL_SEQ_OUTOFBAND: spin_lock_irqsave(&lock,flags); play_event(); -> case EV_TIMING: seq_timing_event() -> case TMR_ECHO: seq_copy_to_input() -> spin_lock_irqsave(&lock,flags); It seems that spin_lock_irqsave() around play_event() is not necessary, because the only other call location in seq_startplay() makes the call without acquiring spinlock. So, the patch just removes spinlocks around play_event(). By the way, it removes unreachable code in seq_timing_event(), since (seq_mode == SEQ_2) case is handled in the beginning. Compile tested only. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit bc26d4d06e337ade069f33d3f4377593b24e6e36) Signed-off-by: Willy Tarreau <w@1wt.eu> 
A deadlock can be initiated by userspace via ioctl(SNDCTL_SEQ_OUTOFBAND)
on /dev/sequencer with TMR_ECHO midi event.

In this case the control flow is:
sound_ioctl()
-> case SND_DEV_SEQ:
   case SND_DEV_SEQ2:
     sequencer_ioctl()
     -> case SNDCTL_SEQ_OUTOFBAND:
          spin_lock_irqsave(&lock,flags);
          play_event();
          -> case EV_TIMING:
               seq_timing_event()
               -> case TMR_ECHO:
                    seq_copy_to_input()
                    -> spin_lock_irqsave(&lock,flags);

It seems that spin_lock_irqsave() around play_event() is not necessary,
because the only other call location in seq_startplay() makes the call
without acquiring spinlock.

So, the patch just removes spinlocks around play_event().
By the way, it removes unreachable code in seq_timing_event(),
since (seq_mode == SEQ_2) case is handled in the beginning.

Compile tested only.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit bc26d4d06e337ade069f33d3f4377593b24e6e36)
Signed-off-by: Willy Tarreau <w@1wt.eu>
ALSA: control: Fix replacing user controls 2014-12-13T14:16:13+00:00 Lars-Peter Clausen lars@metafoo.de 2014-06-18T11:32:32+00:00 0a592dacc6f5d469d7f5409b06990d4a2ce1b9c5 (commit 82262a46627bebb0febcc26664746c25cef08563 upstream) There are two issues with the current implementation for replacing user controls. The first is that the code does not check if the control is actually a user control and neither does it check if the control is owned by the process that tries to remove it. That allows userspace applications to remove arbitrary controls, which can cause a user after free if a for example a driver does not expect a control to be removed from under its feed. The second issue is that on one hand when a control is replaced the user_ctl_count limit is not checked and on the other hand the user_ctl_count is increased (even though the number of user controls does not change). This allows userspace, once the user_ctl_count limit as been reached, to repeatedly replace a control until user_ctl_count overflows. Once that happens new controls can be added effectively bypassing the user_ctl_count limit. Both issues can be fixed by instead of open-coding the removal of the control that is to be replaced to use snd_ctl_remove_user_ctl(). This function does proper permission checks as well as decrements user_ctl_count after the control has been removed. Note that by using snd_ctl_remove_user_ctl() the check which returns -EBUSY at beginning of the function if the control already exists is removed. This is not a problem though since the check is quite useless, because the lock that is protecting the control list is released between the check and before adding the new control to the list, which means that it is possible that a different control with the same settings is added to the list after the check. Luckily there is another check that is done while holding the lock in snd_ctl_add(), so we'll rely on that to make sure that the same control is not added twice. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Jaroslav Kysela <perex@perex.cz> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> [wt: fixes CVE-2014-4654 & CVE-2014-4655] Signed-off-by: Willy Tarreau <w@1wt.eu> 
(commit 82262a46627bebb0febcc26664746c25cef08563 upstream)

There are two issues with the current implementation for replacing user
controls. The first is that the code does not check if the control is actually a
user control and neither does it check if the control is owned by the process
that tries to remove it. That allows userspace applications to remove arbitrary
controls, which can cause a user after free if a for example a driver does not
expect a control to be removed from under its feed.

The second issue is that on one hand when a control is replaced the
user_ctl_count limit is not checked and on the other hand the user_ctl_count is
increased (even though the number of user controls does not change). This allows
userspace, once the user_ctl_count limit as been reached, to repeatedly replace
a control until user_ctl_count overflows. Once that happens new controls can be
added effectively bypassing the user_ctl_count limit.

Both issues can be fixed by instead of open-coding the removal of the control
that is to be replaced to use snd_ctl_remove_user_ctl(). This function does
proper permission checks as well as decrements user_ctl_count after the control
has been removed.

Note that by using snd_ctl_remove_user_ctl() the check which returns -EBUSY at
beginning of the function if the control already exists is removed. This is not
a problem though since the check is quite useless, because the lock that is
protecting the control list is released between the check and before adding the
new control to the list, which means that it is possible that a different
control with the same settings is added to the list after the check. Luckily
there is another check that is done while holding the lock in snd_ctl_add(), so
we'll rely on that to make sure that the same control is not added twice.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
[wt: fixes CVE-2014-4654 & CVE-2014-4655]
Signed-off-by: Willy Tarreau <w@1wt.eu>
ALSA: control: Don't access controls outside of protected regions 2014-12-13T14:16:13+00:00 Lars-Peter Clausen lars@metafoo.de 2014-06-18T11:32:33+00:00 c99bd4fceec6135a31f95de4716a42e2064909bf (commit fd9f26e4eca5d08a27d12c0933fceef76ed9663d upstream) A control that is visible on the card->controls list can be freed at any time. This means we must not access any of its memory while not holding the controls_rw_lock. Otherwise we risk a use after free access. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Jaroslav Kysela <perex@perex.cz> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> [wt: fixes CVE-2014-4653] Signed-off-by: Willy Tarreau <w@1wt.eu> 
(commit fd9f26e4eca5d08a27d12c0933fceef76ed9663d upstream)

A control that is visible on the card->controls list can be freed at any time.
This means we must not access any of its memory while not holding the
controls_rw_lock. Otherwise we risk a use after free access.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
[wt: fixes CVE-2014-4653]
Signed-off-by: Willy Tarreau <w@1wt.eu>
ALSA: control: Protect user controls against concurrent access 2014-11-23T09:55:36+00:00 Lars-Peter Clausen lars@metafoo.de 2014-06-18T11:32:31+00:00 883f30e7d98d97d704df38cd2972a33be852f23a [ Upstream commit 07f4d9d74a04aa7c72c5dae0ef97565f28f17b92 ] The user-control put and get handlers as well as the tlv do not protect against concurrent access from multiple threads. Since the state of the control is not updated atomically it is possible that either two write operations or a write and a read operation race against each other. Both can lead to arbitrary memory disclosure. This patch introduces a new lock that protects user-controls from concurrent access. Since applications typically access controls sequentially than in parallel a single lock per card should be fine. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Jaroslav Kysela <perex@perex.cz> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> [wt: fixes CVE-2014-4652] Signed-off-by: Willy Tarreau <w@1wt.eu> 
[ Upstream commit 07f4d9d74a04aa7c72c5dae0ef97565f28f17b92 ]

The user-control put and get handlers as well as the tlv do not protect against
concurrent access from multiple threads. Since the state of the control is not
updated atomically it is possible that either two write operations or a write
and a read operation race against each other. Both can lead to arbitrary memory
disclosure. This patch introduces a new lock that protects user-controls from
concurrent access. Since applications typically access controls sequentially
than in parallel a single lock per card should be fine.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
[wt: fixes CVE-2014-4652]
Signed-off-by: Willy Tarreau <w@1wt.eu>
ALSA: control: Handle numid overflow 2014-11-23T09:55:34+00:00 Lars-Peter Clausen lars@metafoo.de 2014-06-18T11:32:34+00:00 199615725dd969a800154f48f739ea83b3c86eec Each control gets automatically assigned its numids when the control is created. The allocation is done by incrementing the numid by the amount of allocated numids per allocation. This means that excessive creation and destruction of controls (e.g. via SNDRV_CTL_IOCTL_ELEM_ADD/REMOVE) can cause the id to eventually overflow. Currently when this happens for the control that caused the overflow kctl->id.numid + kctl->count will also over flow causing it to be smaller than kctl->id.numid. Most of the code assumes that this is something that can not happen, so we need to make sure that it won't happen Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Jaroslav Kysela <perex@perex.cz> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit ac902c112d90a89e59916f751c2745f4dbdbb4bd) [wt: part 2 of CVE-2014-4656] Signed-off-by: Willy Tarreau <w@1wt.eu> 
Each control gets automatically assigned its numids when the control is created.
The allocation is done by incrementing the numid by the amount of allocated
numids per allocation. This means that excessive creation and destruction of
controls (e.g. via SNDRV_CTL_IOCTL_ELEM_ADD/REMOVE) can cause the id to
eventually overflow. Currently when this happens for the control that caused the
overflow kctl->id.numid + kctl->count will also over flow causing it to be
smaller than kctl->id.numid. Most of the code assumes that this is something
that can not happen, so we need to make sure that it won't happen

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit ac902c112d90a89e59916f751c2745f4dbdbb4bd)
[wt: part 2 of CVE-2014-4656]
Signed-off-by: Willy Tarreau <w@1wt.eu>
ALSA: control: Make sure that id->index does not overflow 2014-11-23T09:55:34+00:00 Lars-Peter Clausen lars@metafoo.de 2014-06-18T11:32:35+00:00 365c843b9e11bc85cacd8fe3d93965734297f35b The ALSA control code expects that the range of assigned indices to a control is continuous and does not overflow. Currently there are no checks to enforce this. If a control with a overflowing index range is created that control becomes effectively inaccessible and unremovable since snd_ctl_find_id() will not be able to find it. This patch adds a check that makes sure that controls with a overflowing index range can not be created. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Jaroslav Kysela <perex@perex.cz> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit 883a1d49f0d77d30012f114b2e19fc141beb3e8e) [wt: part 1 of CVE-2014-4656 fix] Signed-off-by: Willy Tarreau <w@1wt.eu> 
The ALSA control code expects that the range of assigned indices to a control is
continuous and does not overflow. Currently there are no checks to enforce this.
If a control with a overflowing index range is created that control becomes
effectively inaccessible and unremovable since snd_ctl_find_id() will not be
able to find it. This patch adds a check that makes sure that controls with a
overflowing index range can not be created.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 883a1d49f0d77d30012f114b2e19fc141beb3e8e)
[wt: part 1 of CVE-2014-4656 fix]
Signed-off-by: Willy Tarreau <w@1wt.eu>
ALSA: ac97 - Fix missing NULL check in snd_ac97_cvol_new() 2013-06-10T09:42:32+00:00 Takashi Iwai tiwai@suse.de 2012-10-11T14:43:40+00:00 cda9add3150b19b35e456250cbb164ec31474d5a commit 733a48e5ae5bf28b046fad984d458c747cbb8c21 upstream. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=44721 Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Willy Tarreau <w@1wt.eu> 
commit 733a48e5ae5bf28b046fad984d458c747cbb8c21 upstream.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=44721

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
ALSA: seq: Fix missing error handling in snd_seq_timer_open() 2013-06-10T09:42:32+00:00 Takashi Iwai tiwai@suse.de 2013-03-08T17:11:17+00:00 402adfdd8f83dd9b9ee8417db32ca508d2a2c65f commit 66efdc71d95887b652a742a5dae51fa834d71465 upstream. snd_seq_timer_open() didn't catch the whole error path but let through if the timer id is a slave. This may lead to Oops by accessing the uninitialized pointer. BUG: unable to handle kernel NULL pointer dereference at 00000000000002ae IP: [<ffffffff819b3477>] snd_seq_timer_open+0xe7/0x130 PGD 785cd067 PUD 76964067 PMD 0 Oops: 0002 [#4] SMP CPU 0 Pid: 4288, comm: trinity-child7 Tainted: G D W 3.9.0-rc1+ #100 Bochs Bochs RIP: 0010:[<ffffffff819b3477>] [<ffffffff819b3477>] snd_seq_timer_open+0xe7/0x130 RSP: 0018:ffff88006ece7d38 EFLAGS: 00010246 RAX: 0000000000000286 RBX: ffff88007851b400 RCX: 0000000000000000 RDX: 000000000000ffff RSI: ffff88006ece7d58 RDI: ffff88006ece7d38 RBP: ffff88006ece7d98 R08: 000000000000000a R09: 000000000000fffe R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff8800792c5400 R14: 0000000000e8f000 R15: 0000000000000007 FS: 00007f7aaa650700(0000) GS:ffff88007f800000(0000) GS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000002ae CR3: 000000006efec000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process trinity-child7 (pid: 4288, threadinfo ffff88006ece6000, task ffff880076a8a290) Stack: 0000000000000286 ffffffff828f2be0 ffff88006ece7d58 ffffffff810f354d 65636e6575716573 2065756575712072 ffff8800792c0030 0000000000000000 ffff88006ece7d98 ffff8800792c5400 ffff88007851b400 ffff8800792c5520 Call Trace: [<ffffffff810f354d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff819b17e9>] snd_seq_queue_timer_open+0x29/0x70 [<ffffffff819ae01a>] snd_seq_ioctl_set_queue_timer+0xda/0x120 [<ffffffff819acb9b>] snd_seq_do_ioctl+0x9b/0xd0 [<ffffffff819acbe0>] snd_seq_ioctl+0x10/0x20 [<ffffffff811b9542>] do_vfs_ioctl+0x522/0x570 [<ffffffff8130a4b3>] ? file_has_perm+0x83/0xa0 [<ffffffff810f354d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff811b95ed>] sys_ioctl+0x5d/0xa0 [<ffffffff813663fe>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff81faed69>] system_call_fastpath+0x16/0x1b Reported-and-tested-by: Tommi Rantala <tt.rantala@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Willy Tarreau <w@1wt.eu> 
commit 66efdc71d95887b652a742a5dae51fa834d71465 upstream.

snd_seq_timer_open() didn't catch the whole error path but let through
if the timer id is a slave.  This may lead to Oops by accessing the
uninitialized pointer.

 BUG: unable to handle kernel NULL pointer dereference at 00000000000002ae
 IP: [<ffffffff819b3477>] snd_seq_timer_open+0xe7/0x130
 PGD 785cd067 PUD 76964067 PMD 0
 Oops: 0002 [#4] SMP
 CPU 0
 Pid: 4288, comm: trinity-child7 Tainted: G      D W 3.9.0-rc1+ #100 Bochs Bochs
 RIP: 0010:[<ffffffff819b3477>]  [<ffffffff819b3477>] snd_seq_timer_open+0xe7/0x130
 RSP: 0018:ffff88006ece7d38  EFLAGS: 00010246
 RAX: 0000000000000286 RBX: ffff88007851b400 RCX: 0000000000000000
 RDX: 000000000000ffff RSI: ffff88006ece7d58 RDI: ffff88006ece7d38
 RBP: ffff88006ece7d98 R08: 000000000000000a R09: 000000000000fffe
 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
 R13: ffff8800792c5400 R14: 0000000000e8f000 R15: 0000000000000007
 FS:  00007f7aaa650700(0000) GS:ffff88007f800000(0000) GS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00000000000002ae CR3: 000000006efec000 CR4: 00000000000006f0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
 Process trinity-child7 (pid: 4288, threadinfo ffff88006ece6000, task ffff880076a8a290)
 Stack:
  0000000000000286 ffffffff828f2be0 ffff88006ece7d58 ffffffff810f354d
  65636e6575716573 2065756575712072 ffff8800792c0030 0000000000000000
  ffff88006ece7d98 ffff8800792c5400 ffff88007851b400 ffff8800792c5520
 Call Trace:
  [<ffffffff810f354d>] ? trace_hardirqs_on+0xd/0x10
  [<ffffffff819b17e9>] snd_seq_queue_timer_open+0x29/0x70
  [<ffffffff819ae01a>] snd_seq_ioctl_set_queue_timer+0xda/0x120
  [<ffffffff819acb9b>] snd_seq_do_ioctl+0x9b/0xd0
  [<ffffffff819acbe0>] snd_seq_ioctl+0x10/0x20
  [<ffffffff811b9542>] do_vfs_ioctl+0x522/0x570
  [<ffffffff8130a4b3>] ? file_has_perm+0x83/0xa0
  [<ffffffff810f354d>] ? trace_hardirqs_on+0xd/0x10
  [<ffffffff811b95ed>] sys_ioctl+0x5d/0xa0
  [<ffffffff813663fe>] ? trace_hardirqs_on_thunk+0x3a/0x3f
  [<ffffffff81faed69>] system_call_fastpath+0x16/0x1b

Reported-and-tested-by: Tommi Rantala <tt.rantala@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
ALSA: hda - Add a pin-fix for FSC Amilo Pi1505 2013-06-10T09:42:31+00:00 Takashi Iwai tiwai@suse.de 2009-12-01T11:19:37+00:00 0b6c9f057c24cfb1543c55c378a7e3ecb61716d9 FSC Amilo Pi 1505 has a buggy BIOS and doesn't set up the HP and speaker pins properly. Add the pinfix entry for that. Reference: Novell bnc#557403 https://bugzilla.novell.com/show_bug.cgi?id=557403 [2.6.32: additional background from Jonathan below] > Hi Willy, > > Please consider > > cfc9b06f0bef ALSA: hda - Add a pin-fix for FSC Amilo Pi1505 > > for application to the 2.6.32.y tree. Without this patch, the Amilo > Pi 1505's internal speaker is silent unless a jack is plugged into its > headphone jack. > > Jose Manuel Castroagudin noticed[1] that 2.6.30 is not affected, so > this seems to be a regression. > > The patch was applied upstream during the 2.6.33 merge window, where > it worked. That said, I didn't manage to track down anyone with a > Pi1505 to test it against 2.6.32, so thoughts from alsa folks on > whether this is appropriate for 2.6.32.y would be useful. > > Hope that helps, > Jonathan > > [1] http://bugs.debian.org/599582 has many more details. Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit cfc9b06f0befe50ef02253f72b76946363549031) Cc: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Willy Tarreau <w@1wt.eu> 
FSC Amilo Pi 1505 has a buggy BIOS and doesn't set up the HP and
speaker pins properly.  Add the pinfix entry for that.

Reference: Novell bnc#557403
   https://bugzilla.novell.com/show_bug.cgi?id=557403

[2.6.32: additional background from Jonathan below]
> Hi Willy,
>
> Please consider
>
>   cfc9b06f0bef ALSA: hda - Add a pin-fix for FSC Amilo Pi1505
>
> for application to the 2.6.32.y tree.  Without this patch, the Amilo
> Pi 1505's internal speaker is silent unless a jack is plugged into its
> headphone jack.
>
> Jose Manuel Castroagudin noticed[1] that 2.6.30 is not affected, so
> this seems to be a regression.
>
> The patch was applied upstream during the 2.6.33 merge window, where
> it worked.  That said, I didn't manage to track down anyone with a
> Pi1505 to test it against 2.6.32, so thoughts from alsa folks on
> whether this is appropriate for 2.6.32.y would be useful.
>
> Hope that helps,
> Jonathan
>
> [1] http://bugs.debian.org/599582 has many more details.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit cfc9b06f0befe50ef02253f72b76946363549031)
Cc: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
ALSA: hda - More ALC663 fixes and support of compatible chips 2013-06-10T09:42:31+00:00 Kailang Yang kailang@realtek.com.tw 2009-12-17T11:23:00+00:00 da8aad73d6ae5936483ee9b5dfc100be8bfadbc5 commit ebb83eeb6469bedda83b4dc6f23ddf93eb32b347 upstream. 1. Add more ASUS NB model. 2. Fixed alc663_m51va_setup M51VA has Digital Mic that NID is 0x12. The record source index is 0x9 for ALC663. So, to modify the alc663_m51va_setup function to index 0x9 and add analog Mic aupport function alc663_mode1_setup. 3. Add ASUS mode7 and mode8 modules for ALC663 [jn: backport to 2.6.32.y to address http://bugs.debian.org/688564] Signed-off-by: Kailang Yang <kailang@realtek.com.tw> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Tested-by: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> # Vaio w/ ALC275 Signed-off-by: Willy Tarreau <w@1wt.eu> 
commit ebb83eeb6469bedda83b4dc6f23ddf93eb32b347 upstream.

1. Add more ASUS NB model.
2. Fixed alc663_m51va_setup
   M51VA has Digital Mic that NID is 0x12. The record source index is
   0x9 for ALC663.
   So, to modify the alc663_m51va_setup function to index 0x9
   and add analog Mic aupport function alc663_mode1_setup.
3. Add ASUS mode7 and mode8 modules for ALC663

[jn: backport to 2.6.32.y to address http://bugs.debian.org/688564]

Signed-off-by: Kailang Yang <kailang@realtek.com.tw>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Tested-by: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> # Vaio w/ ALC275
Signed-off-by: Willy Tarreau <w@1wt.eu>