24 Mar, 2011

40 commits

  • Greg Kroah-Hartman
     
  • commit ccd32e735de7a941906e093f8dca924bb05c5794 upstream.

    An integer overflow occurs in the calculation of RHlinear when the
    relative humidity is greater than around 30%. The consequence is a subtle
    (but noticeable) error in the resulting humidity measurement.

    Signed-off-by: Vivien Didelot
    Signed-off-by: Jean Delvare
    Cc: Jonathan Cameron
    Signed-off-by: Greg Kroah-Hartman

    Vivien Didelot
     
  • commit 60d97a840175d3becb2e6de36537a5cdfc0ec3a9 upstream.

    The MUSB driver doesn't see its platform device on DM644x EVM board anymore
    since commit 73b089b052a69020b953312a624a6e1eb5b81fab (usb: musb: split davinci
    to its own platform_driver) because the new probe is called as subsys_initcall()
    now, and the device is registered later than that by the board code. Move the
    registration to davinci_evm_init() -- it's safe to do so because the MUSB core
    device still gets initialized as fs_initcall() -- which is late enough for the
    I2C GPIO expander (which controls VBUS) to be initialized.

    Signed-off-by: Sergei Shtylyov
    Acked-by: Felipe Balbi
    Tested-by: Sekhar Nori
    Signed-off-by: Kevin Hilman
    Signed-off-by: Greg Kroah-Hartman

    Sergei Shtylyov
     
  • commit 371c394af27ab7d1e58a66bc19d9f1f3ac1f67b4 upstream.

    The latest binutils (2.21.0.20110302/Ubuntu) breaks the build
    yet another time, under CONFIG_XEN=y due to a .size directive that
    refers to a slightly differently named (hence, to the now very
    strict and unforgiving assembler, non-existent) symbol.

    [ mingo:

    This unnecessary build breakage caused by new binutils
    version 2.21 gets escallated back several kernel releases spanning
    several years of Linux history, affecting over 130,000 upstream
    kernel commits (!), on CONFIG_XEN=y 64-bit kernels (i.e. essentially
    affecting all major Linux distro kernel configs).

    Git annotate tells us that this slight debug symbol code mismatch
    bug has been introduced in 2008 in commit 3d75e1b8:

    3d75e1b8 (Jeremy Fitzhardinge 2008-07-08 15:06:49 -0700 1231) ENTRY(xen_do_hypervisor_callback) # do_hypervisor_callback(struct *pt_regs)

    The 'bug' is just a slight assymetry in ENTRY()/END()
    debug-symbols sequences, with lots of assembly code between the
    ENTRY() and the END():

    ENTRY(xen_do_hypervisor_callback) # do_hypervisor_callback(struct *pt_regs)
    ...
    END(do_hypervisor_callback)

    Human reviewers almost never catch such small mismatches, and binutils
    never even warned about it either.

    This new binutils version thus breaks the Xen build on all upstream kernels
    since v2.6.27, out of the blue.

    This makes a straightforward Git bisection of all 64-bit Xen-enabled kernels
    impossible on such binutils, for a bisection window of over hundred
    thousand historic commits. (!)

    This is a major fail on the side of binutils and binutils needs to turn
    this show-stopper build failure into a warning ASAP. ]

    Signed-off-by: Alexander van Heukelum
    Cc: Jeremy Fitzhardinge
    Cc: Jan Beulich
    Cc: H.J. Lu
    Cc: Linus Torvalds
    Cc: Andrew Morton
    Cc: "H. Peter Anvin"
    Cc: Kees Cook
    LKML-Reference:
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Alexander van Heukelum
     
  • commit 0aab3995485b8a994bf29a995a008c9ea4a28054 upstream.

    During redetection of a SDIO card, a request for a new card RCA
    was submitted to the card, but was then overwritten by the old RCA.
    This caused the card to be deselected instead of selected when using
    the incorrect RCA. This bug's been present since the "oldcard"
    handling was introduced in 2.6.32.

    Signed-off-by: Stefan Nilsson XK
    Reviewed-by: Ulf Hansson
    Reviewed-by: Pawel Wieczorkiewicz
    Signed-off-by: Linus Walleij
    Signed-off-by: Chris Ball
    Signed-off-by: Greg Kroah-Hartman

    Stefan Nilsson XK
     
  • commit 5fd11c0754fa069b6aba64b65734aa2fb193552d upstream.

    Signed-off-by: Manoj Iyer
    Signed-off-by: Chris Ball
    Signed-off-by: Greg Kroah-Hartman

    Manoj Iyer
     
  • commit 6ced9e6b3901af4ab6ac0a11231402c888286ea6 upstream.

    The struct i2c_board_info member holding the name is "type", not
    "name".

    Signed-off-by: Roman Fietze
    Signed-off-by: Jean Delvare
    Signed-off-by: Greg Kroah-Hartman

    Roman Fietze
     
  • commit 47340bd9fefb571888836da942b5aee0e85e959c upstream.

    This patch add multitouch support for the MacBookPro8,1 and
    MacBookPro8,2 models.

    Signed-off-by: Andy Botting
    Signed-off-by: Henrik Rydberg
    Acked-by: Jiri Kosina
    Signed-off-by: Dmitry Torokhov
    Signed-off-by: Greg Kroah-Hartman

    Andy Botting
     
  • commit 9804c9eaeacfe78651052c5ddff31099f60ef78c upstream.

    The CHECK_IRQ_PER_CPU is wrong, it should be checking
    irq_to_desc(irq)->status not just irq.

    Signed-off-by: Thomas Gleixner
    Signed-off-by: James Bottomley
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     
  • commit f635bd11c8d332d917fb9a4cad3071b2357d5b2a upstream.

    When the multi input quirk is set, there is a new input device
    created for every feature report. Since the idea is to present
    features per hid device, not per input device, revert back to
    the original report loop and change the feature_mapping() callback
    to not take the input device as argument.

    Signed-off-by: Henrik Rydberg
    Tested-by: Benjamin Tissoires
    Signed-off-by: Jiri Kosina
    Signed-off-by: Greg Kroah-Hartman

    Henrik Rydberg
     
  • commit 0ae43810976bc969ee158510c4acbe70ed136e61 upstream.

    This device does not tolerate delayed opening and goes into a coma if
    we try to that. Ubuntu even has a crutch for udev that opened the device
    upon seeing it for the first time, but it did not work if we happened to
    boot with the device attached, since by the time userspace got around
    opening the device it was too late. Let's start the device immediately
    to deal with this issue.

    Reported-by: Sergei Kolzun
    Signed-off-by: Dmitry Torokhov
    Signed-off-by: Jiri Kosina
    Signed-off-by: Greg Kroah-Hartman

    Dmitry Torokhov
     
  • commit 4981d01eada5354d81c8929d5b2836829ba3df7b upstream.

    According to intel CPU manual, every time PGD entry is changed in i386 PAE
    mode, we need do a full TLB flush. Current code follows this and there is
    comment for this too in the code.

    But current code misses the multi-threaded case. A changed page table
    might be used by several CPUs, every such CPU should flush TLB. Usually
    this isn't a problem, because we prepopulate all PGD entries at process
    fork. But when the process does munmap and follows new mmap, this issue
    will be triggered.

    When it happens, some CPUs keep doing page faults:

    http://marc.info/?l=linux-kernel&m=129915020508238&w=2

    Reported-by: Yasunori Goto
    Tested-by: Yasunori Goto
    Reviewed-by: Rik van Riel
    Signed-off-by: Shaohua Li
    Cc: Mallick Asit K
    Cc: Linus Torvalds
    Cc: Andrew Morton
    Cc: linux-mm
    LKML-Reference:
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Shaohua Li
     
  • commit 723aae25d5cdb09962901d36d526b44d4be1051c upstream.

    Mike Galbraith reported finding a lockup ("perma-spin bug") where the
    cpumask passed to smp_call_function_many was cleared by other cpu(s)
    while a cpu was preparing its call_data block, resulting in no cpu to
    clear the last ref and unlock the block.

    Having cpus clear their bit asynchronously could be useful on a mask of
    cpus that might have a translation context, or cpus that need a push to
    complete an rcu window.

    Instead of adding a BUG_ON and requiring yet another cpumask copy, just
    detect the race and handle it.

    Note: arch_send_call_function_ipi_mask must still handle an empty
    cpumask because the data block is globally visible before the that arch
    callback is made. And (obviously) there are no guarantees to which cpus
    are notified if the mask is changed during the call; only cpus that were
    online and had their mask bit set during the whole call are guaranteed
    to be called.

    Reported-by: Mike Galbraith
    Reported-by: Jan Beulich
    Acked-by: Jan Beulich
    Signed-off-by: Milton Miller
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Milton Miller
     
  • commit 45a5791920ae643eafc02e2eedef1a58e341b736 upstream.

    Paul McKenney's review pointed out two problems with the barriers in the
    2.6.38 update to the smp call function many code.

    First, a barrier that would force the func and info members of data to
    be visible before their consumption in the interrupt handler was
    missing. This can be solved by adding a smp_wmb between setting the
    func and info members and setting setting the cpumask; this will pair
    with the existing and required smp_rmb ordering the cpumask read before
    the read of refs. This placement avoids the need a second smp_rmb in
    the interrupt handler which would be executed on each of the N cpus
    executing the call request. (I was thinking this barrier was present
    but was not).

    Second, the previous write to refs (establishing the zero that we the
    interrupt handler was testing from all cpus) was performed by a third
    party cpu. This would invoke transitivity which, as a recient or
    concurrent addition to memory-barriers.txt now explicitly states, would
    require a full smp_mb().

    However, we know the cpumask will only be set by one cpu (the data
    owner) and any preivous iteration of the mask would have cleared by the
    reading cpu. By redundantly writing refs to 0 on the owning cpu before
    the smp_wmb, the write to refs will follow the same path as the writes
    that set the cpumask, which in turn allows us to keep the barrier in the
    interrupt handler a smp_rmb instead of promoting it to a smp_mb (which
    will be be executed by N cpus for each of the possible M elements on the
    list).

    I moved and expanded the comment about our (ab)use of the rcu list
    primitives for the concurrent walk earlier into this function. I
    considered moving the first two paragraphs to the queue list head and
    lock, but felt it would have been too disconected from the code.

    Cc: Paul McKinney
    Signed-off-by: Milton Miller
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Milton Miller
     
  • commit e6cd1e07a185d5f9b0aa75e020df02d3c1c44940 upstream.

    Peter pointed out there was nothing preventing the list_del_rcu in
    smp_call_function_interrupt from running before the list_add_rcu in
    smp_call_function_many.

    Fix this by not setting refs until we have gotten the lock for the list.
    Take advantage of the wmb in list_add_rcu to save an explicit additional
    one.

    I tried to force this race with a udelay before the lock & list_add and
    by mixing all 64 online cpus with just 3 random cpus in the mask, but
    was unsuccessful. Still, inspection shows a valid race, and the fix is
    a extension of the existing protection window in the current code.

    Reported-by: Peter Zijlstra
    Signed-off-by: Milton Miller
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Milton Miller
     
  • commit d7433142b63d727b5a217c37b1a1468b116a9771 upstream.

    (crossport of 1f7bebb9e911d870fa8f997ddff838e82b5715ea
    by Andreas Schlick )

    When ext3_dx_add_entry() has to split an index node, it has to ensure that
    name_len of dx_node's fake_dirent is also zero, because otherwise e2fsck
    won't recognise it as an intermediate htree node and consider the htree to
    be corrupted.

    Signed-off-by: Eric Sandeen
    Signed-off-by: Jan Kara
    Signed-off-by: Greg Kroah-Hartman

    Eric Sandeen
     
  • commit 58d406ed6a5f1ca4bc1dba5390b718c67847fa5f upstream.

    Some versions of grep don't treat '\s' properly. When building perf on such
    systems and using a kernel tarball the perf version is unable to be determined
    from the main kernel Makefile and the user is left with a version of '..'.
    Replacing the use of '\s' with '[[:space:]]', which should work in all grep
    versions, gives a usable version number.

    Reported-by: Tapan Dhimant
    Cc: Ingo Molnar
    Cc: Paul Mackerras
    Cc: Peter Zijlstra
    Cc: Tapan Dhimant
    Cc: linux-kernel@vger.kernel.org
    LKML-Reference:
    Signed-off-by: Josh Hunt
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Greg Kroah-Hartman

    Josh Hunt
     
  • commit 0837e3242c73566fc1c0196b4ec61779c25ffc93 upstream.

    Events on POWER7 can roll back if a speculative event doesn't
    eventually complete. Unfortunately in some rare cases they will
    raise a performance monitor exception. We need to catch this to
    ensure we reset the PMC. In all cases the PMC will be 256 or less
    cycles from overflow.

    Signed-off-by: Anton Blanchard
    Signed-off-by: Peter Zijlstra
    LKML-Reference:
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Anton Blanchard
     
  • commit a0f7d0f7fc02465bb9758501f611f63381792996 upstream.

    We toggle the state from start and stop callbacks but actually
    don't check it when the event triggers. Do it so that
    these callbacks actually work.

    Signed-off-by: Frederic Weisbecker
    Cc: Arnaldo Carvalho de Melo
    Cc: Paul Mackerras
    Cc: Stephane Eranian
    Signed-off-by: Peter Zijlstra
    LKML-Reference:
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Frederic Weisbecker
     
  • commit 91b2f482e62ad0d444222253026a5cbca28c4ab9 upstream.

    Fix the mistakenly inverted check of events state.

    Signed-off-by: Frederic Weisbecker
    Signed-off-by: Peter Zijlstra
    Cc: Arnaldo Carvalho de Melo
    Cc: Paul Mackerras
    Cc: Stephane Eranian
    LKML-Reference:
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Frederic Weisbecker
     
  • commit 8e26de238fd794c8ea56a5c98bf67c40cfeb051d upstream.

    RPC task RPC_TASK_QUEUED bit is set must be checked before trying to wake up
    task rpc_killall_tasks() because task->tk_waitqueue can not be set (equal to
    NULL).
    Also, as Trond Myklebust mentioned, such approach (instead of checking
    tk_waitqueue to NULL) allows us to "optimise away the call to
    rpc_wake_up_queued_task() altogether for those
    tasks that aren't queued".

    Here is an example of dereferencing of tk_waitqueue equal to NULL:

    CPU 0 CPU 1 CPU 2
    -------------------- --------------------- --------------------------
    nfs4_run_open_task
    rpc_run_task
    rpc_execute
    rpc_set_active
    rpc_make_runnable
    (waiting)
    rpc_async_schedule
    nfs4_open_prepare
    nfs_wait_on_sequence
    nfs_umount_begin
    rpc_killall_tasks
    rpc_wake_up_task
    rpc_wake_up_queued_task
    spin_lock(tk_waitqueue == NULL)
    BUG()
    rpc_sleep_on
    spin_lock(&q->lock)
    __rpc_sleep_on
    task->tk_waitqueue = q

    Signed-off-by: Stanislav Kinsbursky
    Signed-off-by: Trond Myklebust
    Signed-off-by: Greg Kroah-Hartman

    Stanislav Kinsbursky
     
  • commit e020c6800c9621a77223bf2c1ff68180e41e8ebf upstream.

    This fixes a race in which the task->tk_callback() puts the rpc_task
    to sleep, setting a new callback. Under certain circumstances, the current
    code may end up executing the task->tk_action before it gets round to the
    callback.

    Signed-off-by: Trond Myklebust
    Signed-off-by: Greg Kroah-Hartman

    Trond Myklebust
     
  • commit ed0f36bc5719b25659b637f80ceea85494b84502 upstream.

    The use of blk_execute_rq_nowait() implies __blk_put_request() is needed
    in stpg_endio() rather than blk_put_request() -- blk_finish_request() is
    called with queue lock already held.

    Signed-off-by: Joseph Gruher
    Signed-off-by: Ilgu Hong
    Signed-off-by: Mike Snitzer
    Signed-off-by: James Bottomley
    Signed-off-by: Greg Kroah-Hartman

    Joseph Gruher
     
  • commit 904f0bc482201fa86e75c330d79dfd11be494cf8 upstream.

    the target infrastructure fails to send the correct conventional size
    to READ_CAPACITY that force a retry with READ_CAPACITY_16, which reads
    the capacity for devices > 2TB. Fix by adding the correct return to
    trigger RC(16).

    Reported-by: Ben Jarvis
    Signed-off-by: Signed-off-by: Nicholas A. Bellinger
    Signed-off-by: James Bottomley
    Signed-off-by: Greg Kroah-Hartman

    Nicholas Bellinger
     
  • commit 64c25a92e865f06ad8782fbdaa1e2a97d50acf73 upstream.

    MONO was renamed to MONO1.

    Signed-off-by: Vasily Khoruzhick
    Acked-by: Liam Girdwood
    Signed-off-by: Mark Brown
    Signed-off-by: Greg Kroah-Hartman

    Vasily Khoruzhick
     
  • commit efed5f26664f93991c929d5bb343e65f900d72bc upstream.

    Clear input settings before initialization.

    Signed-off-by: Przemyslaw Bruski
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Przemyslaw Bruski
     
  • commit f164753a263bfd2daaf3e0273b179de7e099c57d upstream.

    SDPIF status retrieval always returned the default settings instead of
    the actual ones.

    Signed-off-by: Przemyslaw Bruski
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Przemyslaw Bruski
     
  • commit 4c1847e884efddcc3ede371f7839e5e65b25c34d upstream.

    SPDIF status mask creation was incorrect.

    Signed-off-by: Przemyslaw Bruski
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Przemyslaw Bruski
     
  • commit 98d21df431ad55281e1abf780f8d51e3391900b2 upstream.

    loopback_pos_update() can be called in the timer callback, thus the lock
    held should be irq-safe. Otherwise you'll get AB/BA deadlock together
    with substream->self_group.lock.

    Reported-and-tested-by: Knut Petersen
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit 4a122c10fbfe9020df469f0f669da129c5757671 upstream.

    The user-supplied index into the adapters array needs to be checked, or
    an out-of-bounds kernel pointer could be accessed and used, leading to
    potentially exploitable memory corruption.

    Signed-off-by: Dan Rosenberg
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Dan Rosenberg
     
  • commit 0f12a4e29368a9476076515881d9ef4e5876c6e2 upstream.

    Commit 280c73d ("PCI: centralize the capabilities code in
    pci-sysfs.c") changed the initialisation of the "rom" and "vpd"
    attributes, and made the failure path for the "vpd" attribute
    incorrect. We must free the new attribute structure (attr), but
    instead we currently free dev->vpd->attr. That will normally be NULL,
    resulting in a memory leak, but it might be a stale pointer, resulting
    in a double-free.

    Found by inspection; compile-tested only.

    Signed-off-by: Ben Hutchings
    Signed-off-by: Jesse Barnes
    Signed-off-by: Greg Kroah-Hartman

    Ben Hutchings
     
  • commit 87e3dc3855430bd254370afc79f2ed92250f5b7c upstream.

    Some broken BIOSes on ICH4 chipset report an ACPI region which is in
    conflict with legacy IDE ports when ACPI is disabled. Even though the
    regions overlap, IDE ports are working correctly (we cannot find out
    the decoding rules on chipsets).

    So the only problem is the reported region itself, if we don't reserve
    the region in the quirk everything works as expected.

    This patch avoids reserving any quirk regions below PCIBIOS_MIN_IO
    which is 0x1000. Some regions might be (and are by a fast google
    query) below this border, but the only difference is that they won't
    be reserved anymore. They should still work though the same as before.

    The conflicts look like (1f.0 is bridge, 1f.1 is IDE ctrl):
    pci 0000:00:1f.1: address space collision: [io 0x0170-0x0177] conflicts with 0000:00:1f.0 [io 0x0100-0x017f]

    At 0x0100 a 128 bytes long ACPI region is reported in the quirk for
    ICH4. ata_piix then fails to find disks because the IDE legacy ports
    are zeroed:
    ata_piix 0000:00:1f.1: device not available (can't reserve [io 0x0000-0x0007])

    References: https://bugzilla.novell.com/show_bug.cgi?id=558740
    Signed-off-by: Jiri Slaby
    Cc: Bjorn Helgaas
    Cc: "David S. Miller"
    Cc: Thomas Renninger
    Signed-off-by: Jesse Barnes
    Signed-off-by: Greg Kroah-Hartman

    Jiri Slaby
     
  • commit cdb9755849fbaf2bb9c0a009ba5baa817a0f152d upstream.

    Per ICH4 and ICH6 specs, ACPI and GPIO regions are valid iff ACPI_EN
    and GPIO_EN bits are set to 1. Add checks for these bits into the
    quirks prior to the region creation.

    While at it, name the constants by macros.

    Signed-off-by: Jiri Slaby
    Cc: Bjorn Helgaas
    Cc: "David S. Miller"
    Cc: Thomas Renninger
    Signed-off-by: Jesse Barnes
    Signed-off-by: Greg Kroah-Hartman

    Jiri Slaby
     
  • commit b99af4b002e4908d1a5cdaf424529bdf1dc69768 upstream.

    Revert commit 7eb93b175d4de9438a4b0af3a94a112cb5266944
    Author: Yu Zhao
    Date: Fri Apr 3 15:18:11 2009 +0800

    PCI: SR-IOV quirk for Intel 82576 NIC

    If BIOS doesn't allocate resources for the SR-IOV BARs, zero the Flash
    BAR and program the SR-IOV BARs to use the old Flash Memory Space.

    Please refer to Intel 82576 Gigabit Ethernet Controller Datasheet
    section 7.9.2.14.2 for details.
    http://download.intel.com/design/network/datashts/82576_Datasheet.pdf

    Signed-off-by: Yu Zhao
    Signed-off-by: Jesse Barnes

    This quirk was added before SR-IOV was in production and now all machines that
    originally had this issue alreayd have bios updates to correct the issue. The
    quirk itself is no longer needed and in fact causes bugs if run. Remove it.

    Signed-off-by: Jesse Brandeburg
    CC: Yu Zhao
    CC: Jesse Barnes
    Signed-off-by: Jesse Barnes
    Signed-off-by: Greg Kroah-Hartman

    Brandeburg, Jesse
     
  • commit 270fdc0748bd3f7b625caff985f2fcf8e2185ec7 upstream.

    As reported on http://ubuntuforums.org/showthread.php?t=1594007 the
    PKB-1700 needs same special handling as WKB-2000. This change is
    originally based on patch posted by user asmoore82 on the Ubuntu
    forums.

    Signed-off-by: Herton Ronaldo Krzesinski
    Signed-off-by: Jiri Kosina
    Signed-off-by: Greg Kroah-Hartman

    Herton Ronaldo Krzesinski
     
  • commit 2d9ca4e9f393d81d8f37ed37505aecbf3a5e1bd6 upstream.

    The magic trackpad and mouse both report touch orientation in opposite
    direction to the bcm5974 driver and what is written in
    Documents/input/multi-touch-protocol.txt. This patch reverts the
    direction, so that all in-kernel devices with this feature behave the
    same way.

    Since no known application has been utilizing this information yet, it
    seems appropriate also for stable.

    Cc: Michael Poole
    Signed-off-by: Henrik Rydberg
    Acked-by: Chase Douglas
    Signed-off-by: Jiri Kosina
    Signed-off-by: Greg Kroah-Hartman

    Henrik Rydberg
     
  • commit 584c0c4c359bdac37d94157f8d7fc513d26c8328 upstream.

    Currently some special handling for the unusual case like dual-ADCs
    or a single-input-src is done in the tree-parse time in
    set_capture_mixer(). But this setup could be overwritten by static
    init verbs.

    This patch moves the initialization into the init phase so that
    such input-src setup won't be lost.

    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit 094a42452abd5564429045e210281c6d22e67fca upstream.

    When the mux for digital mic is different from the mux for other mics,
    the current auto-parser doesn't handle them in a right way but provides
    only one mic. This patch fixes the issue.

    Signed-off-by: Vitaliy Kulikov
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Vitaliy Kulikov
     
  • commit 0a3fabe30e1a3b2037a12b863b8c45fffce38ee9 upstream.

    Do not initialize again the what has already been initialized as
    multi outs, as this breaks surround speakers.

    Tested-by: Bartłomiej Żogała
    Signed-off-by: David Henningsson
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    David Henningsson
     
  • commit 7e59e097c09b82760bb0fe08b0fa2b704d76c3f4 upstream.

    Without this change, a volume control named "Surround" or "Side" would
    get an unnecessary index, causing it to be ignored by the vmaster and
    PulseAudio.

    Tested-by: Bartłomiej Żogała
    Signed-off-by: David Henningsson
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    David Henningsson