Skip to content
Commits on Mar 24, 2011
  1. @gregkh

    Linux 2.6.32.35

    gregkh committed Mar 24, 2011
  2. @gregkh

    Revert "perf: Handle stopped state with tracepoints"

    gregkh committed Mar 24, 2011
    This reverts commit 6f197b7, which was
    originally commit a0f7d0f upstream.
    
    This breaks the build, thanks to Jiri Slaby for pointing this out.
    
    Reported-by: Jiri Slaby <jslaby@suse.cz>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Commits on Mar 23, 2011
  1. @gregkh

    Linux 2.6.32.34

    gregkh committed Mar 23, 2011
  2. @vivien @gregkh

    hwmon: (sht15) Fix integer overflow in humidity calculation

    vivien committed with gregkh Mar 21, 2011
    commit ccd32e7 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 <vivien.didelot@savoirfairelinux.com>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Cc: Jonathan Cameron <jic23@cam.ac.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @heukelum @gregkh

    x86, binutils, xen: Fix another wrong size directive

    heukelum committed with gregkh Mar 11, 2011
    commit 371c394 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 3d75e1b:
    
         3d75e1b        (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 <heukelum@fastmail.fm>
    Cc: Jeremy Fitzhardinge <jeremy@goop.org>
    Cc: Jan Beulich <jbeulich@novell.com>
    Cc: H.J. Lu <hjl.tools@gmail.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Kees Cook <kees.cook@canonical.com>
    LKML-Reference: <1299877178-26063-1-git-send-email-heukelum@fastmail.fm>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  4. @mdmillerii @gregkh

    powerpc: rtas_flash needs to use rtas_data_buf

    mdmillerii committed with gregkh Jun 12, 2010
    commit bd2b64a upstream.
    
    When trying to flash a machine via the update_flash command, Anton received the
    following error:
    
        Restarting system.
        FLASH: kernel bug...flash list header addr above 4GB
    
    The code in question has a comment that the flash list should be in
    the kernel data and therefore under 4GB:
    
            /* NOTE: the "first" block list is a global var with no data
             * blocks in the kernel data segment.  We do this because
             * we want to ensure this block_list addr is under 4GB.
             */
    
    Unfortunately the Kconfig option is marked tristate which means the variable
    may not be in the kernel data and could be above 4GB.
    
    Instead of relying on the data segment being below 4GB, use the static
    data buffer allocated by the kernel for use by rtas.  Since we don't
    use the header struct directly anymore, convert it to a simple pointer.
    
    Reported-By: Anton Blanchard <anton@samba.org>
    Signed-Off-By: Milton Miller <miltonm@bga.com>
    Tested-By: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. @mikey @gregkh

    powerpc/kdump: Fix race in kdump shutdown

    mikey committed with gregkh May 13, 2010
    commit 60adec6 upstream.
    
    When we are crashing, the crashing/primary CPU IPIs the secondaries to
    turn off IRQs, go into real mode and wait in kexec_wait.  While this
    is happening, the primary tears down all the MMU maps.  Unfortunately
    the primary doesn't check to make sure the secondaries have entered
    real mode before doing this.
    
    On PHYP machines, the secondaries can take a long time shutting down
    the IRQ controller as RTAS calls are need.  These RTAS calls need to
    be serialised which resilts in the secondaries contending in
    lock_rtas() and hence taking a long time to shut down.
    
    We've hit this on large POWER7 machines, where some secondaries are
    still waiting in lock_rtas(), when the primary tears down the HPTEs.
    
    This patch makes sure all secondaries are in real mode before the
    primary tears down the MMU.  It uses the new kexec_state entry in the
    paca.  It times out if the secondaries don't reach real mode after
    10sec.
    
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
    cc: Anton Blanchard <anton@samba.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  6. @mikey @gregkh

    powerpc/kexec: Fix race in kexec shutdown

    mikey committed with gregkh May 13, 2010
    commit 1fc711f upstream.
    
    In kexec_prepare_cpus, the primary CPU IPIs the secondary CPUs to
    kexec_smp_down().  kexec_smp_down() calls kexec_smp_wait() which sets
    the hw_cpu_id() to -1.  The primary does this while leaving IRQs on
    which means the primary can take a timer interrupt which can lead to
    the IPIing one of the secondary CPUs (say, for a scheduler re-balance)
    but since the secondary CPU now has a hw_cpu_id = -1, we IPI CPU
    -1... Kaboom!
    
    We are hitting this case regularly on POWER7 machines.
    
    There is also a second race, where the primary will tear down the MMU
    mappings before knowing the secondaries have entered real mode.
    
    Also, the secondaries are clearing out any pending IPIs before
    guaranteeing that no more will be received.
    
    This changes kexec_prepare_cpus() so that we turn off IRQs in the
    primary CPU much earlier.  It adds a paca flag to say that the
    secondaries have entered the kexec_smp_down() IPI and turned off IRQs,
    rather than overloading hw_cpu_id with -1.  This new paca flag is
    again used to in indicate when the secondaries has entered real mode.
    
    It also ensures that all CPUs have their IRQs off before we clear out
    any pending IPI requests (in kexec_cpu_down()) to ensure there are no
    trailing IPIs left unacknowledged.
    
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
    cc: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
  7. @gregkh

    mmc: sdio: remember new card RCA when redetecting card

    Stefan Nilsson XK committed with gregkh Mar 1, 2011
    commit 0aab399 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 <stefan.xk.nilsson@stericsson.com>
    Reviewed-by: Ulf Hansson <ulf.hansson@stericsson.com>
    Reviewed-by: Pawel Wieczorkiewicz <pawel.wieczorkiewicz@stericsson.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  8. @gregkh

    i2c: Fix typo in instantiating-devices document

    Roman Fietze committed with gregkh Mar 20, 2011
    commit 6ced9e6 upstream.
    
    The struct i2c_board_info member holding the name is "type", not
    "name".
    
    Signed-off-by: Roman Fietze <roman.fietze@telemotive.de>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  9. @gregkh

    fix per-cpu flag problem in the cpu affinity checkers

    Thomas Gleixner committed with gregkh Feb 7, 2011
    commit 9804c9e 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 <tglx@linutronix.de>
    Signed-off-by: James Bottomley <James.Bottomley@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  10. @gregkh

    smp_call_function_many: handle concurrent clearing of mask

    Milton Miller committed with gregkh Mar 15, 2011
    commit 723aae2 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 <efault@gmx.de>
    Reported-by: Jan Beulich <JBeulich@novell.com>
    Acked-by: Jan Beulich <jbeulich@novell.com>
    Signed-off-by: Milton Miller <miltonm@bga.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  11. @tilmanschmidt @gregkh

    isdn: avoid calling tty_ldisc_flush() in atomic context

    tilmanschmidt committed with gregkh Jul 5, 2010
    commit bc10f96 upstream.
    
    Remove the call to tty_ldisc_flush() from the RESULT_NO_CARRIER
    branch of isdn_tty_modem_result(), as already proposed in commit
    00409bb.
    This avoids a "sleeping function called from invalid context" BUG
    when the hardware driver calls the statcallb() callback with
    command==ISDN_STAT_DHUP in atomic context, which in turn calls
    isdn_tty_modem_result(RESULT_NO_CARRIER, ~), and from there,
    tty_ldisc_flush() which may sleep.
    
    Signed-off-by: Tilman Schmidt <tilman@imap.cc>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. @gregkh

    x86: Flush TLB if PGD entry is changed in i386 PAE mode

    Shaohua Li committed with gregkh Mar 16, 2011
    commit 4981d01 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<y-goto@jp.fujitsu.com>
    Tested-by: Yasunori Goto<y-goto@jp.fujitsu.com>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Signed-off-by: Shaohua Li<shaohua.li@intel.com>
    Cc: Mallick Asit K <asit.k.mallick@intel.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: linux-mm <linux-mm@kvack.org>
    LKML-Reference: <1300246649.2337.95.camel@sli10-conroe>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  13. @gregkh

    call_function_many: add missing ordering

    Milton Miller committed with gregkh Mar 15, 2011
    commit 45a5791 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 <paulmck@linux.vnet.ibm.com>
    Signed-off-by: Milton Miller <miltonm@bga.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  14. @gregkh

    call_function_many: fix list delete vs add race

    Milton Miller committed with gregkh Mar 15, 2011
    commit e6cd1e0 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 <peterz@infradead.org>
    Signed-off-by: Milton Miller <miltonm@bga.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  15. @gregkh

    ext3: Always set dx_node's fake_dirent explicitly.

    Eric Sandeen committed with gregkh Mar 4, 2011
    commit d743314 upstream.
    
    (crossport of 1f7bebb
    by Andreas Schlick <schlick@lavabit.com>)
    
    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 <sandeen@redhat.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  16. @antonblanchard @gregkh

    perf, powerpc: Handle events that raise an exception without overflowing

    antonblanchard committed with gregkh Mar 9, 2011
    commit 0837e32 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 <anton@samba.org>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    LKML-Reference: <20110309143842.6c22845e@kryten>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  17. @fweisbec @gregkh

    perf: Handle stopped state with tracepoints

    fweisbec committed with gregkh Mar 7, 2011
    commit a0f7d0f 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 <fweisbec@gmail.com>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Stephane Eranian <eranian@google.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    LKML-Reference: <1299529629-18280-2-git-send-email-fweisbec@gmail.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  18. @gregkh

    SUNRPC: Ensure we always run the tk_callback before tk_action

    Trond Myklebust committed with gregkh Mar 15, 2011
    commit e020c68 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 <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  19. @gregkh

    ALSA: ctxfi - Clear input settings before initialization

    Przemyslaw Bruski committed with gregkh Mar 13, 2011
    commit efed5f2 upstream.
    
    Clear input settings before initialization.
    
    Signed-off-by: Przemyslaw Bruski <pbruskispam@op.pl>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  20. @gregkh

    ALSA: ctxfi - Fix SPDIF status retrieval

    Przemyslaw Bruski committed with gregkh Mar 13, 2011
    commit f164753 upstream.
    
    SDPIF status retrieval always returned the default settings instead of
    the actual ones.
    
    Signed-off-by: Przemyslaw Bruski <pbruskispam@op.pl>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  21. @gregkh

    ALSA: ctxfi - Fix incorrect SPDIF status bit mask

    Przemyslaw Bruski committed with gregkh Mar 13, 2011
    commit 4c1847e upstream.
    
    SPDIF status mask creation was incorrect.
    
    Signed-off-by: Przemyslaw Bruski <pbruskispam@op.pl>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  22. @gregkh

    PCI: sysfs: Fix failure path for addition of "vpd" attribute

    Ben Hutchings committed with gregkh Jan 13, 2011
    commit 0f12a4e 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 <bhutchings@solarflare.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  23. @gregkh

    PCI: do not create quirk I/O regions below PCIBIOS_MIN_IO for ICH

    Jiri Slaby committed with gregkh Feb 28, 2011
    commit 87e3dc3 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 <jslaby@suse.cz>
    Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Thomas Renninger <trenn@suse.de>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  24. @gregkh

    PCI: add more checking to ICH region quirks

    Jiri Slaby committed with gregkh Feb 28, 2011
    commit cdb9755 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 <jslaby@suse.cz>
    Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Thomas Renninger <trenn@suse.de>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  25. @jbrandeb @gregkh

    PCI: remove quirk for pre-production systems

    jbrandeb committed with gregkh Feb 14, 2011
    commit b99af4b upstream.
    
    Revert commit 7eb93b1
    Author: Yu Zhao <yu.zhao@intel.com>
    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 <yu.zhao@intel.com>
        Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    
    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 <jesse.brandeburg@intel.com>
    CC: Yu Zhao <yu.zhao@intel.com>
    CC: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  26. @gregkh

    ALSA: hda - fix digital mic selection in mixer on 92HD8X codecs

    Vitaliy Kulikov committed with gregkh Mar 9, 2011
    commit 094a424 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 <Vitaliy.Kulikov@idt.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  27. @gregkh

    xhci: Fix cycle bit calculation during stall handling.

    Sarah Sharp committed with gregkh Feb 23, 2011
    commit 01a1fdb upstream.
    
    When an endpoint stalls, we need to update the xHCI host's internal
    dequeue pointer to move it past the stalled transfer.  This includes
    updating the cycle bit (TRB ownership bit) if we have moved the dequeue
    pointer past a link TRB with the toggle cycle bit set.
    
    When we're trying to find the new dequeue segment, find_trb_seg() is
    supposed to keep track of whether we've passed any link TRBs with the
    toggle cycle bit set.  However, this while loop's body
    
    	while (cur_seg->trbs > trb ||
    			&cur_seg->trbs[TRBS_PER_SEGMENT - 1] < trb) {
    
    Will never get executed if the ring only contains one segment.
    find_trb_seg() will return immediately, without updating the new cycle
    bit.  Since find_trb_seg() has no idea where in the segment the TD that
    stalled was, make the caller, xhci_find_new_dequeue_state(), check for
    this special case and update the cycle bit accordingly.
    
    This patch should be queued to kernels all the way back to 2.6.31.
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Tested-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  28. @udknight @gregkh

    USB: serial: ch341: add new id

    udknight committed with gregkh Mar 11, 2011
    commit d078138 upstream.
    
    I picked up a new DAK-780EX(professional digitl reverb/mix system),
    which use CH341T chipset to communication with computer on 3/2011
    and the CH341T's vendor code is 1a86
    
    Looking up the CH341T's vendor and product id's I see:
    
    1a86  QinHeng Electronics
      5523  CH341 in serial mode, usb to serial port converter
    
    CH341T,CH341 are the products of the same company, maybe
    have some common hardware, and I test the ch341.c works
    well with CH341T
    
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  29. @gregkh

    USB: serial/kobil_sct, fix potential tty NULL dereference

    Jiri Slaby committed with gregkh Feb 28, 2011
    commit 6960f40 upstream.
    
    Make sure that we check the return value of tty_port_tty_get.
    Sometimes it may return NULL and we later dereference that.
    
    The only place here is in kobil_read_int_callback, so fix it.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Cc: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  30. @gregkh

    ath9k_hw: Fix incorrect macversion and macrev checks

    Senthil Balasubramanian committed with gregkh Dec 22, 2010
    commit ac45c12 upstream.
    
    There are few places where we are checking for macversion and revsions
    before RTC is powered ON. However we are reading the macversion and
    revisions only after RTC is powered ON and so both macversion and
    revisions are actully zero and this leads to incorrect srev checks
    
    Incorrect srev checks can cause registers to be configured wrongly and can
    cause unexpected behavior. Fixing this seems to address the ASPM issue that
    we have observed. The laptop becomes very slow and hangs mostly with ASPM L1
    enabled without this fix.
    
    fix this by reading the macversion and revisisons even before we start
    using them. There is no reason why should we delay reading this info
    until RTC is powered on as this is just a register information.
    
    Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  31. @gregkh

    x86, quirk: Fix SB600 revision check

    Andreas Herrmann committed with gregkh Mar 15, 2011
    commit 1d3e09a upstream.
    
    Commit 7f74f8f
    (x86 quirk: Fix polarity for IRQ0 pin2 override on SB800
    systems) introduced a regression. It removed some SB600 specific
    code to determine the revision ID without adapting a
    corresponding revision ID check for SB600.
    
    See this mail thread:
    
      http://marc.info/?l=linux-kernel&m=129980296006380&w=2
    
    This patch adapts the corresponding check to cover all SB600
    revisions.
    
    Tested-by: Wang Lei <f3d27b@gmail.com>
    Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    LKML-Reference: <20110315143137.GD29499@alberich.amd.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  32. @shefty @gregkh

    IB/cm: Bump reference count on cm_id before invoking callback

    shefty committed with gregkh Feb 23, 2011
    commit 2996343 upstream.
    
    When processing a SIDR REQ, the ib_cm allocates a new cm_id.  The
    refcount of the cm_id is initialized to 1.  However, cm_process_work
    will decrement the refcount after invoking all callbacks.  The result
    is that the cm_id will end up with refcount set to 0 by the end of the
    sidr req handler.
    
    If a user tries to destroy the cm_id, the destruction will proceed,
    under the incorrect assumption that no other threads are referencing
    the cm_id.  This can lead to a crash when the cm callback thread tries
    to access the cm_id.
    
    This problem was noticed as part of a larger investigation with kernel
    crashes in the rdma_cm when running on a real time OS.
    
    Signed-off-by: Sean Hefty <sean.hefty@intel.com>
    Acked-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  33. @shefty @gregkh

    RDMA/cma: Fix crash in request handlers

    shefty committed with gregkh Feb 23, 2011
    commit 25ae21a upstream.
    
    Doug Ledford and Red Hat reported a crash when running the rdma_cm on
    a real-time OS.  The crash has the following call trace:
    
        cm_process_work
           cma_req_handler
              cma_disable_callback
              rdma_create_id
                 kzalloc
                 init_completion
              cma_get_net_info
              cma_save_net_info
              cma_any_addr
                 cma_zero_addr
              rdma_translate_ip
                 rdma_copy_addr
              cma_acquire_dev
                 rdma_addr_get_sgid
                 ib_find_cached_gid
                 cma_attach_to_dev
              ucma_event_handler
                 kzalloc
                 ib_copy_ah_attr_to_user
              cma_comp
    
    [ preempted ]
    
        cma_write
            copy_from_user
            ucma_destroy_id
               copy_from_user
               _ucma_find_context
               ucma_put_ctx
               ucma_free_ctx
                  rdma_destroy_id
                     cma_exch
                     cma_cancel_operation
                     rdma_node_get_transport
    
            rt_mutex_slowunlock
            bad_area_nosemaphore
            oops_enter
    
    They were able to reproduce the crash multiple times with the
    following details:
    
        Crash seems to always happen on the:
                mutex_unlock(&conn_id->handler_mutex);
        as conn_id looks to have been freed during this code path.
    
    An examination of the code shows that a race exists in the request
    handlers.  When a new connection request is received, the rdma_cm
    allocates a new connection identifier.  This identifier has a single
    reference count on it.  If a user calls rdma_destroy_id() from another
    thread after receiving a callback, rdma_destroy_id will proceed to
    destroy the id and free the associated memory.  However, the request
    handlers may still be in the process of running.  When control returns
    to the request handlers, they can attempt to access the newly created
    identifiers.
    
    Fix this by holding a reference on the newly created rdma_cm_id until
    the request handler is through accessing it.
    
    Signed-off-by: Sean Hefty <sean.hefty@intel.com>
    Acked-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Something went wrong with that request. Please try again.