commit 6f5405942321c322f1ba83960837b63a8ebb039e
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Aug 20 08:43:19 2013 -0700

    Linux 3.10.8

commit 9fa6018620ff121a3d892394021d4285636b7cd5
Author: Li Zefan <lizefan@huawei.com>
Date:   Tue Aug 13 10:05:59 2013 +0800

    cpuset: fix the return value of cpuset_write_u64()
    
    commit a903f0865a190f8778c73df1a810ea6e25e5d7cf upstream.
    
    Writing to this file always returns -ENODEV:
    
      # echo 1 > cpuset.memory_pressure_enabled
      -bash: echo: write error: No such device
    
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94aa327e13898c4c495a27303ce96cc52280fb25
Author: Jan Kara <jack@suse.cz>
Date:   Mon Aug 12 09:53:28 2013 -0400

    jbd2: Fix use after free after error in jbd2_journal_dirty_metadata()
    
    commit 91aa11fae1cf8c2fd67be0609692ea9741cdcc43 upstream.
    
    When jbd2_journal_dirty_metadata() returns error,
    __ext4_handle_dirty_metadata() stops the handle. However callers of this
    function do not count with that fact and still happily used now freed
    handle. This use after free can result in various issues but very likely
    we oops soon.
    
    The motivation of adding __ext4_journal_stop() into
    __ext4_handle_dirty_metadata() in commit 9ea7a0df seems to be only to
    improve error reporting. So replace __ext4_journal_stop() with
    ext4_journal_abort_handle() which was there before that commit and add
    WARN_ON_ONCE() to dump stack to provide useful information.
    
    Reported-by: Sage Weil <sage@inktank.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9234930d6e89a7671042e6e35e318480d6b82e5f
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Fri Aug 16 20:50:55 2013 -0700

    s390: Fix broken build
    
    commit 215b28a5308f3d332df2ee09ef11fda45d7e4a92 upstream.
    
    Fix this build error:
    
      In file included from fs/exec.c:61:0:
      arch/s390/include/asm/tlb.h:35:23: error: expected identifier or '(' before 'unsigned'
      arch/s390/include/asm/tlb.h:36:1: warning: no semicolon at end of struct or union [enabled by default]
      arch/s390/include/asm/tlb.h: In function 'tlb_gather_mmu':
      arch/s390/include/asm/tlb.h:57:5: error: 'struct mmu_gather' has no member named 'end'
    
    Broken due to commit 2b047252d0 ("Fix TLB gather virtual address range
    invalidation corner cases").
    
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    [ Oh well. We had build testing for ppc amd um, but no s390  - Linus ]
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 571b78a1d829263003a8560cca2c6d109bb19f0a
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Fri Jul 26 00:08:25 2013 +0200

    m68k/atari: ARAnyM - Fix NatFeat module support
    
    commit e8184e10f89736a23ea6eea8e24cd524c5c513d2 upstream.
    
    As pointed out by Andreas Schwab, pointers passed to ARAnyM NatFeat calls
    should be physical addresses, not virtual addresses.
    
    Fortunately on Atari, physical and virtual kernel addresses are the same,
    as long as normal kernel memory is concerned, so this usually worked fine
    without conversion.
    
    But for modules, pointers to literal strings are located in vmalloc()ed
    memory. Depending on the version of ARAnyM, this causes the nf_get_id()
    call to just fail, or worse, crash ARAnyM itself with e.g.
    
        Gotcha! Illegal memory access. Atari PC = $968c
    
    This is a big issue for distro kernels, who want to have all drivers as
    loadable modules in an initrd.
    
    Add a wrapper for nf_get_id() that copies the literal to the stack to
    work around this issue.
    
    Reported-by: Thorsten Glaser <tg@debian.org>
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5a16a446ef5bdb37214b100b93e59ac75e8a445
Author: Andreas Schwab <schwab@linux-m68k.org>
Date:   Fri Aug 9 15:14:08 2013 +0200

    m68k: Truncate base in do_div()
    
    commit ea077b1b96e073eac5c3c5590529e964767fc5f7 upstream.
    
    Explicitly truncate the second operand of do_div() to 32 bits to guard
    against bogus code calling it with a 64-bit divisor.
    
    [Thorsten]
    
    After upgrading from 3.2 to 3.10, mounting a btrfs volume fails with:
    
    btrfs: setting nodatacow, compression disabled
    btrfs: enabling auto recovery
    btrfs: disk space caching is enabled
      *** ZERO DIVIDE ***   FORMAT=2
    Current process id is 722
    BAD KERNEL TRAP: 00000000
    Modules linked in: evdev mac_hid ext4 crc16 jbd2 mbcache btrfs xor lzo_compress zlib_deflate raid6_pq crc32c libcrc32c
    PC: [<319535b2>] __btrfs_map_block+0x11c/0x119a [btrfs]
    SR: 2000  SP: 30c1fab4  a2: 30f0faf0
    d0: 00000000    d1: 00001000    d2: 00000000    d3: 00000000
    d4: 00010000    d5: 00000000    a0: 3085c72c    a1: 3085c72c
    Process mount (pid: 722, task=30f0faf0)
    Frame format=2 instr addr=319535ae
    Stack from 30c1faec:
            00000000 00000020 00000000 00001000 00000000 01401000 30253928 300ffc00
            00a843ac 3026f640 00000000 00010000 0009e250 00d106c0 00011220 00000000
            00001000 301c6830 0009e32a 000000ff 00000009 3085c72c 00000000 00000000
            30c1fd14 00000000 00000020 00000000 30c1fd14 0009e26c 00000020 00000003
            00000000 0009dd8a 300b0b6c 30253928 00a843ac 00001000 00000000 00000000
            0000a008 3194e76a 30253928 00a843ac 00001000 00000000 00000000 00000002
    Call Trace: [<00001000>] kernel_pg_dir+0x0/0x1000
    
        [...]
    
    Code: 222e ff74 2a2e ff5c 2c2e ff60 4c45 1402 <2d40> ff64 2d41 ff68 2205 4c2e 1800 ff68 4c04 0800 2041 d1c0 2206 4c2e 1400 ff68
    
    [Geert]
    
    As diagnosed by Andreas, fs/btrfs/volumes.c:__btrfs_map_block()
    calls
    
        do_div(stripe_nr, stripe_len);
    
    with stripe_len u64, while do_div() assumes the divisor is a 32-bit number.
    
    Due to the lack of truncation in the m68k-specific implementation of
    do_div(), the division is performed using the upper 32-bit word of
    stripe_len, which is zero.
    
    This was introduced by commit 53b381b3abeb86f12787a6c40fee9b2f71edc23b
    ("Btrfs: RAID5 and RAID6"), which changed the divisor from
    map->stripe_len (struct map_lookup.stripe_len is int) to a 64-bit temporary.
    
    Reported-by: Thorsten Glaser <tg@debian.org>
    Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
    Tested-by: Thorsten Glaser <tg@debian.org>
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 859325460d2b15ef9b78b55eff72d766e1b8ea29
Author: Will Deacon <will.deacon@arm.com>
Date:   Wed Aug 7 23:39:41 2013 +0100

    ARM: 7809/1: perf: fix event validation for software group leaders
    
    commit c95eb3184ea1a3a2551df57190c81da695e2144b upstream.
    
    It is possible to construct an event group with a software event as a
    group leader and then subsequently add a hardware event to the group.
    This results in the event group being validated by adding all members
    of the group to a fake PMU and attempting to allocate each event on
    their respective PMU.
    
    Unfortunately, for software events wthout a corresponding arm_pmu, this
    results in a kernel crash attempting to dereference the ->get_event_idx
    function pointer.
    
    This patch fixes the problem by checking explicitly for software events
    and ignoring those in event validation (since they can always be
    scheduled). We will probably want to revisit this for 3.12, since the
    validation checks don't appear to work correctly when dealing with
    multiple hardware PMUs anyway.
    
    Reported-by: Vince Weaver <vincent.weaver@maine.edu>
    Tested-by: Vince Weaver <vincent.weaver@maine.edu>
    Tested-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e220cfd1a9f6c763a108a3b964a888fe341dabd
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Aug 15 11:42:25 2013 -0700

    Fix TLB gather virtual address range invalidation corner cases
    
    commit 2b047252d087be7f2ba088b4933cd904f92e6fce upstream.
    
    Ben Tebulin reported:
    
     "Since v3.7.2 on two independent machines a very specific Git
      repository fails in 9/10 cases on git-fsck due to an SHA1/memory
      failures.  This only occurs on a very specific repository and can be
      reproduced stably on two independent laptops.  Git mailing list ran
      out of ideas and for me this looks like some very exotic kernel issue"
    
    and bisected the failure to the backport of commit 53a59fc67f97 ("mm:
    limit mmu_gather batching to fix soft lockups on !CONFIG_PREEMPT").
    
    That commit itself is not actually buggy, but what it does is to make it
    much more likely to hit the partial TLB invalidation case, since it
    introduces a new case in tlb_next_batch() that previously only ever
    happened when running out of memory.
    
    The real bug is that the TLB gather virtual memory range setup is subtly
    buggered.  It was introduced in commit 597e1c3580b7 ("mm/mmu_gather:
    enable tlb flush range in generic mmu_gather"), and the range handling
    was already fixed at least once in commit e6c495a96ce0 ("mm: fix the TLB
    range flushed when __tlb_remove_page() runs out of slots"), but that fix
    was not complete.
    
    The problem with the TLB gather virtual address range is that it isn't
    set up by the initial tlb_gather_mmu() initialization (which didn't get
    the TLB range information), but it is set up ad-hoc later by the
    functions that actually flush the TLB.  And so any such case that forgot
    to update the TLB range entries would potentially miss TLB invalidates.
    
    Rather than try to figure out exactly which particular ad-hoc range
    setup was missing (I personally suspect it's the hugetlb case in
    zap_huge_pmd(), which didn't have the same logic as zap_pte_range()
    did), this patch just gets rid of the problem at the source: make the
    TLB range information available to tlb_gather_mmu(), and initialize it
    when initializing all the other tlb gather fields.
    
    This makes the patch larger, but conceptually much simpler.  And the end
    result is much more understandable; even if you want to play games with
    partial ranges when invalidating the TLB contents in chunks, now the
    range information is always there, and anybody who doesn't want to
    bother with it won't introduce subtle bugs.
    
    Ben verified that this fixes his problem.
    
    Reported-bisected-and-tested-by: Ben Tebulin <tebulin@googlemail.com>
    Build-testing-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Build-testing-by: Richard Weinberger <richard.weinberger@gmail.com>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f34a4837cd0b28abe7449e591a23cb32ab128520
Author: Thomas Pugliese <thomas.pugliese@gmail.com>
Date:   Fri Aug 9 09:52:13 2013 -0500

    wusbcore: fix kernel panic when disconnecting a wireless USB->serial device
    
    commit ec58fad1feb76c323ef47efff1d1e8660ed4644c upstream.
    
    This patch fixes a kernel panic that can occur when disconnecting a
    wireless USB->serial device.  When the serial device disconnects, the
    device cleanup procedure ends up calling usb_hcd_disable_endpoint on the
    serial device's endpoints.  The wusbcore uses the ABORT_RPIPE command to
    abort all transfers on the given endpoint but it does not properly give
    back the URBs when the transfer results return from the HWA.  This patch
    prevents the transfer result processing code from bailing out when it sees
    a WA_XFER_STATUS_ABORTED result code so that these urbs are flushed
    properly by usb_hcd_disable_endpoint.  It also updates wa_urb_dequeue to
    handle the case where the endpoint has already been cleaned up when
    usb_kill_urb is called which is where the panic originally occurred.
    
    Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1dba303727f52ea062580b0a9b3f0c3b462769cf
Author: Stephen Boyd <sboyd@codeaurora.org>
Date:   Tue Aug 13 14:12:40 2013 -0700

    PM / QoS: Fix workqueue deadlock when using pm_qos_update_request_timeout()
    
    commit 40fea92ffb5fa0ef26d10ae0fe5688bc8e61c791 upstream.
    
    pm_qos_update_request_timeout() updates a qos and then schedules
    a delayed work item to bring the qos back down to the default
    after the timeout. When the work item runs, pm_qos_work_fn() will
    call pm_qos_update_request() and deadlock because it tries to
    cancel itself via cancel_delayed_work_sync(). Future callers of
    that qos will also hang waiting to cancel the work that is
    canceling itself. Let's extract the little bit of code that does
    the real work of pm_qos_update_request() and call it from the
    work function so that we don't deadlock.
    
    Before ed1ac6e (PM: don't use [delayed_]work_pending()) this didn't
    happen because the work function wouldn't try to cancel itself.
    
    [backport to 3.10 - gregkh]
    
    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
    Reviewed-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 237e0153190c92a4deb80782973f60557a6b2cdb
Author: Matt Burtch <matt@grid-net.com>
Date:   Mon Aug 12 10:11:39 2013 -0700

    USB-Serial: Fix error handling of usb_wwan
    
    commit 6c1ee66a0b2bdbd64c078fba684d640cf2fd38a9 upstream.
    
    This fixes an issue where the bulk-in urb used for incoming data transfer
    is not resubmitted if the packet recieved contains an error status.  This
    results in the driver locking until the port is closed and re-opened.
    
    Tested on a custom board with a Cinterion GSM module.
    
    Signed-off-by: Matt Burtch <matt@grid-net.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c72a0e036f9d80c609e608a723751343f1f5e9fc
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed Aug 7 10:58:05 2013 -0400

    USB: EHCI: accept very late isochronous URBs
    
    commit 24f531371de17010f2b1b57d90e42240032e7733 upstream.
    
    Since commits 4005ad4390bf (EHCI: implement new semantics for
    URB_ISO_ASAP) and c75c5ab575af (ALSA: USB: adjust for changed 3.8 USB
    API) became widely distributed, people have been experiencing problems
    with audio transfers.  The slightest underrun causes complete failure,
    requiring the audio stream to be restarted.
    
    It turns out that the current isochronous API doesn't handle underruns
    in the best way.  The ALSA developers would much rather have transfers
    that are submitted too late be accepted and complete in the normal
    fashion, rather than being refused outright.
    
    This patch implements the requested approach.  When an isochronous URB
    submission is so late that all its scheduled slots have already
    expired, a debugging message will be printed in the log and the URB
    will be accepted as usual.  Assuming it was submitted by a completion
    handler (which is normally the case), it will complete shortly
    thereafter with all the usb_iso_packet_descriptor status fields marked
    -EXDEV.
    
    This fixes (for ehci-hcd)
    
    	https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603
    
    It should be applied to all kernels that include commit 4005ad4390bf.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Tested-by: Maksim Boyko <maksboyko@yandex.ru>
    CC: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 91508a9ae0005f05adbf45f116dda26b803b4f5f
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Aug 13 13:27:35 2013 +0200

    USB: keyspan: fix null-deref at disconnect and release
    
    commit ff8a43c10f1440f07a5faca0c1556921259f7f76 upstream.
    
    Make sure to fail properly if the device is not accepted during attach
    in order to avoid null-pointer derefs (of missing interface private
    data) at disconnect or release.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f56852aeaaa9a199ffa0a4c9ba2ef360122021c0
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Aug 13 13:27:34 2013 +0200

    USB: mos7720: fix broken control requests
    
    commit ef6c8c1d733e244f0499035be0dabe1f4ed98c6f upstream.
    
    The parallel-port code of the drivers used a stack allocated
    control-request buffer for asynchronous (and possibly deferred) control
    requests. This not only violates the no-DMA-from-stack requirement but
    could also lead to corrupt control requests being submitted.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d802afca86ce011832ec9e8d8120f0ada9dd1835
Author: Johan Hovold <jhovold@gmail.com>
Date:   Sun Aug 11 16:49:20 2013 +0200

    USB: mos7840: fix big-endian probe
    
    commit d551ec9b690f3de65b0091a2e767f1382adc792d upstream.
    
    Fix bug in device-type detection on big-endian machines originally
    introduced by commit 0eafe4de ("USB: serial: mos7840: add support for
    MCS7810 devices") which always matched on little-endian product ids.
    
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0179a37034fd74b573e63e7175dc6e65249b5389
Author: Johan Hovold <jhovold@gmail.com>
Date:   Sun Aug 11 16:49:23 2013 +0200

    USB: ti_usb_3410_5052: fix big-endian firmware handling
    
    commit e877dd2f2581628b7119df707d4cf03d940cff49 upstream.
    
    Fix endianess bugs in firmware handling introduced by commits cb7a7c6a
    ("ti_usb_3410_5052: add Multi-Tech modem support") and 05a3d905
    ("ti_usb_3410_5052: support alternate firmware") which made the driver
    use the wrong firmware for certain devices on big-endian machines.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7048e6925f52536c37143518644a4beabdc4846f
Author: Oliver Neukum <oneukum@suse.de>
Date:   Wed Aug 14 11:01:46 2013 +0200

    usb: add two quirky touchscreen
    
    commit 304ab4ab079a8ed03ce39f1d274964a532db036b upstream.
    
    These devices tend to become unresponsive after S3
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 289813a71e600f652d995d1e94a50112fb1dcfd7
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Jul 30 22:34:28 2013 +0200

    nl80211: fix another nl80211_fam.attrbuf race
    
    commit c319d50bfcf678c2857038276d9fab3c6646f3bf upstream.
    
    This is similar to the race Linus had reported, but in this case
    it's an older bug: nl80211_prepare_wdev_dump() uses the wiphy
    index in cb->args[0] as it is and thus parses the message over
    and over again instead of just once because 0 is the first valid
    wiphy index. Similar code in nl80211_testmode_dump() correctly
    offsets the wiphy_index by 1, do that here as well.
    
    Reported-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa392433df90eec8059dae7323ed2b398c92ecb2
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Aug 16 08:17:05 2013 +0200

    ALSA: hda - Add a fixup for Gateway LT27
    
    commit 1801928e0f99d94c55e33c584c5eb2ff5e246ee6 upstream.
    
    Gateway LT27 needs a fixup for the inverted digital mic.
    
    Reported-by: "Nathanael D. Noblet" <nathanael@gnat.ca>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db3175e1e8bb0701e2a96a5f5e6bee6038da5fd2
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Aug 9 12:34:42 2013 +0200

    ALSA: hda - Add pinfix for LG LW25 laptop
    
    commit db8a38e5063a4daf61252e65d47ab3495c705f4c upstream.
    
    Correct the pins for a line-in and a headphone on LG LW25 laptop with
    ALC880 codec.  Other pins seem fine.
    
    Reported-and-tested-by: Joonas Saarinen <jonskunator@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b32bd480ca3f42a49174b0e4e960bc4a40a28741
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Aug 8 09:32:37 2013 +0200

    ALSA: hda - Fix missing mute controls for CX5051
    
    commit f69910ddbd8c29391958cf82b598dd78fe5c8640 upstream.
    
    We've added a fake mute control (setting the amp volume to zero) for
    CX5051 at commit [3868137e: ALSA: hda - Add a fake mute feature], but
    this feature was overlooked in the generic parser implementation.  Now
    the driver lacks of mute controls on these codecs.
    
    The fix is just to check both AC_AMPCAP_MUTE and AC_AMPCAP_MIN_MUTE
    bits in each place checking the amp capabilities.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59001
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39d165aba321f11d3c6653acb33b4d2d2d68065e
Author: Torsten Schenk <torsten.schenk@zoho.com>
Date:   Sun Aug 11 11:11:35 2013 +0200

    ALSA: 6fire: make buffers DMA-able (midi)
    
    commit 4c2aee0032b70083dafebd733ed9c774633b2fa3 upstream.
    
    Patch makes midi output buffer DMA-able by allocating it separately.
    
    Signed-off-by: Torsten Schenk <torsten.schenk@zoho.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6c1227df6c1fc67cd70d808429a7ad924d3b154
Author: Torsten Schenk <torsten.schenk@zoho.com>
Date:   Sun Aug 11 11:11:19 2013 +0200

    ALSA: 6fire: make buffers DMA-able (pcm)
    
    commit 5ece263f1d93fba8d992e67e3ab8a71acf674db9 upstream.
    
    Patch makes pcm buffers DMA-able by allocating each one separately.
    
    Signed-off-by: Torsten Schenk <torsten.schenk@zoho.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c75cd55f7fff95ddc45cfb32cca1b65bb2b1caf
Author: Maksim A. Boyko <maksboyko@yandex.ru>
Date:   Sat Aug 10 12:20:02 2013 +0400

    ALSA: usb-audio: Fix invalid volume resolution for Logitech HD Webcam C525
    
    commit 140d37de62ffe8405282a1d6498f3b4099006384 upstream.
    
    Add the volume control quirk for avoiding the kernel warning
    for the Logitech HD Webcam C525
    as in the similar commit 36691e1be6ec551eef4a5225f126a281f8c051c2
    for the Logitech HD Webcam C310.
    
    Reported-by: Maksim Boyko <maksim.a.boyko@gmail.com>
    Tested-by: Maksim Boyko <maksim.a.boyko@gmail.com>
    Signed-off-by: Maksim Boyko <maksim.a.boyko@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e54f0e6c230d511f3159a6e773ab5f790c548390
Author: Stephen Warren <swarren@nvidia.com>
Date:   Wed Aug 14 14:24:16 2013 -0600

    ASoC: tegra: fix Tegra30 I2S capture parameter setup
    
    commit c90c0d7a96e634a73ef1580f1d20993606545647 upstream.
    
    The Tegra30 I2S driver was writing the AHUB interface parameters to the
    playback path register rather than the capture path register. This
    caused the capture parameters not to be configured at all, so if
    capturing using non-HW-default parameters (e.g. 16-bit stereo rather
    than 8-bit mono) the audio would be corrupted.
    
    With this fixed, audio capture from an analog microphone works correctly
    on the Cardhu board.
    
    Signed-off-by: Stephen Warren <swarren@nvidia.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b907d955284264b28692338e9a10fa3586704c6
Author: Brian Austin <brian.austin@cirrus.com>
Date:   Tue Aug 6 12:57:21 2013 -0500

    ASoC: cs42l52: Reorder Min/Max and update to SX_TLV for Beep Volume
    
    commit e2c98a8bba958045bde861fe1d66be54315c7790 upstream.
    
    Beep Volume Min/Max was backwards.
    Change to SOC_SONGLE_SX_TLV for correct volume representation
    
    Signed-off-by: Brian Austin <brian.austin@cirrus.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4bd3f15b77578866fda9b0da4ef027f06ed3b746
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Thu Aug 1 18:30:38 2013 +0200

    ASoC: dapm: Fix empty list check in dapm_new_mux()
    
    commit fe581391147cb3d738d961d0f1233d91a9e1113c upstream.
    
    list_first_entry() will always return a valid pointer, even if the list is
    empty. So the check whether path is NULL will always be false. So we end up
    calling dapm_create_or_share_mixmux_kcontrol() with a path struct that points
    right in the middle of the widget struct and by trying to modify the path the
    widgets memory will become corrupted. Fix this by using list_emtpy() to check if
    the widget doesn't have any paths.
    
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Tested-by: Stephen Warren <swarren@nvidia.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20fd3d46726e60f936e8901745a7d00bae32958f
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Jul 30 10:11:25 2013 +0200

    cfg80211: fix P2P GO interface teardown
    
    commit 74418edec915d0f446debebde08d170c7b8ba0ee upstream.
    
    When a P2P GO interface goes down, cfg80211 doesn't properly
    tear it down, leading to warnings later. Add the GO interface
    type to the enumeration to tear it down like AP interfaces.
    Otherwise, we leave it pending and mac80211's state can get
    very confused, leading to warnings later.
    
    Reported-by: Ilan Peer <ilan.peer@intel.com>
    Tested-by: Ilan Peer <ilan.peer@intel.com>
    Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aab4f8d490ef8c184d854d5f630438c10406765c
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Aug 13 09:04:05 2013 +0200

    genetlink: fix family dump race
    
    commit 58ad436fcf49810aa006016107f494c9ac9013db upstream.
    
    When dumping generic netlink families, only the first dump call
    is locked with genl_lock(), which protects the list of families,
    and thus subsequent calls can access the data without locking,
    racing against family addition/removal. This can cause a crash.
    Fix it - the locking needs to be conditional because the first
    time around it's already locked.
    
    A similar bug was reported to me on an old kernel (3.4.47) but
    the exact scenario that happened there is no longer possible,
    on those kernels the first round wasn't locked either. Looking
    at the current code I found the race described above, which had
    also existed on the old kernel.
    
    Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d00ff4f2e5340b4a1fae711c46d804500e4ad7f9
Author: Stephane Grosjean <s.grosjean@peak-system.com>
Date:   Fri Aug 9 11:44:06 2013 +0200

    can: pcan_usb: fix wrong memcpy() bytes length
    
    commit 3c322a56b01695df15c70bfdc2d02e0ccd80654e upstream.
    
    Fix possibly wrong memcpy() bytes length since some CAN records received from
    PCAN-USB could define a DLC field in range [9..15].
    In that case, the real DLC value MUST be used to move forward the record pointer
    but, only 8 bytes max. MUST be copied into the data field of the struct
    can_frame object of the skb given to the network core.
    
    Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 775f521cd8ebf7edf47e88e6d1424513dc5e70e9
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Jul 31 20:52:03 2013 +0200

    mac80211: continue using disabled channels while connected
    
    commit ddfe49b42d8ad4bfdf92d63d4a74f162660d878d upstream.
    
    In case the AP has different regulatory information than we do,
    it can happen that we connect to an AP based on e.g. the world
    roaming regulatory data, and then update our database with the
    AP's country information disables the channel the AP is using.
    If this happens on an HT AP, the bandwidth tracking code will
    hit the WARN_ON() and disconnect. Since that's not very useful,
    ignore the channel-disable flag in bandwidth tracking.
    
    Reported-by: Chris Wright <chrisw@sous-sol.org>
    Tested-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42c8df37807471eac800b06891329e70b789cb44
Author: Chris Wright <chrisw@sous-sol.org>
Date:   Wed Jul 31 12:12:24 2013 -0700

    mac80211: fix infinite loop in ieee80211_determine_chantype
    
    commit b56e4b857c5210e848bfb80e074e5756a36cd523 upstream.
    
    Commit "3d9646d mac80211: fix channel selection bug" introduced a possible
    infinite loop by moving the out target above the chandef_downgrade
    while loop.  When we downgrade to NL80211_CHAN_WIDTH_20_NOHT, we jump
    back up to re-run the while loop...indefinitely.  Replace goto with
    break and carry on.  This may not be sufficient to connect to the AP,
    but will at least keep the cpu from livelocking.  Thanks to Derek Atkins
    as an extra pair of debugging eyes.
    
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7febdf14e427e1ed642f0a0c97182d50b6ce199e
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Jul 31 11:23:06 2013 +0200

    mac80211: ignore HT primary channel while connected
    
    commit 5cdaed1e878d723d56d04ae0be1738124acf9f46 upstream.
    
    While we're connected, the AP shouldn't change the primary channel
    in the HT information. We checked this, and dropped the connection
    if it did change it.
    
    Unfortunately, this is causing problems on some APs, e.g. on the
    Netgear WRT610NL: the beacons seem to always contain a bad channel
    and if we made a connection using a probe response (correct data)
    we drop the connection immediately and can basically not connect
    properly at all.
    
    Work around this by ignoring the HT primary channel information in
    beacons if we're already connected.
    
    Also print out more verbose messages in the other situations to
    help diagnose similar bugs quicker in the future.
    
    Acked-by: Andy Isaacson <adi@hexapodia.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ae473da2f18b175b7ea794326523e485d6795a5
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Thu Aug 1 12:07:55 2013 +0200

    iwl4965: reset firmware after rfkill off
    
    commit 788f7a56fce1bcb2067b62b851a086fca48a0056 upstream.
    
    Using rfkill switch can make firmware unstable, what cause various
    Microcode errors and kernel warnings. Reseting firmware just after
    rfkill off (radio on) helped with that.
    
    Resolve:
    https://bugzilla.redhat.com/show_bug.cgi?id=977053
    
    Reported-and-tested-by: Justin Pearce <whitefox@guardianfox.net>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2c679243cf6529ec3dda86d6f0124ccc10fbd92
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Thu Aug 1 12:07:13 2013 +0200

    iwl4965: set power mode early
    
    commit eca396d7a5bdcc1fd67b1b12f737c213ac78a6f4 upstream.
    
    If device was put into a sleep and system was restarted or module
    reloaded, we have to wake device up before sending other commands.
    Otherwise it will fail to start with Microcode error.
    
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b45835a8365e91c9166e466b92d91675a0d8d1ac
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Fri Jun 21 13:08:48 2013 +0100

    ARM: KVM: clear exclusive monitor on all exception returns
    
    commit 22cfbb6d730ca2fda236b507d9fba17bf002736c upstream.
    
    Make sure we clear the exclusive monitor on all exception returns,
    which otherwise could lead to lock corruptions.
    
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
    Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 285695e4211008e0f06648c3ae7af8ba09a88399
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Fri Jun 21 13:08:47 2013 +0100

    ARM: KVM: add missing dsb before invalidating Stage-2 TLBs
    
    commit 479c5ae2f8a55509b691494cd13691d3dc31d102 upstream.
    
    When performing a Stage-2 TLB invalidation, it is necessary to
    make sure the write to the page tables is observable by all CPUs.
    
    For this purpose, add a dsb instruction to __kvm_tlb_flush_vmid_ipa
    before doing the TLB invalidation itself.
    
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
    Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 921fa4d670d801e9394f843dd14e2d7faabbba4a
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Fri Jun 21 13:08:46 2013 +0100

    ARM: KVM: perform save/restore of PAR
    
    commit 6a077e4ab9cbfbf279fb955bae05b03781c97013 upstream.
    
    Not saving PAR is an unfortunate oversight. If the guest performs
    an AT* operation and gets scheduled out before reading the result
    of the translation from PAR, it could become corrupted by another
    guest or the host.
    
    Saving this register is made slightly more complicated as KVM also
    uses it on the permission fault handling path, leading to an ugly
    "stash and restore" sequence. Fortunately, this is already a slow
    path so we don't really care. Also, Linux doesn't do any AT*
    operation, so Linux guests are not impacted by this bug.
    
      [ Slightly tweaked to use an even register as first operand to ldrd
        and strd operations in interrupts_head.S - Christoffer ]
    
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
    Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6ad83fce072869921cef7c6f4e86bd91639dc34
Author: Jianpeng Ma <majianpeng@gmail.com>
Date:   Wed Jul 3 13:25:24 2013 +0200

    elevator: Fix a race in elevator switching
    
    commit d50235b7bc3ee0a0427984d763ea7534149531b4 upstream.
    
    There's a race between elevator switching and normal io operation.
        Because the allocation of struct elevator_queue and struct elevator_data
        don't in a atomic operation.So there are have chance to use NULL
        ->elevator_data.
        For example:
            Thread A:                               Thread B
            blk_queu_bio                            elevator_switch
            spin_lock_irq(q->queue_block)           elevator_alloc
            elv_merge                               elevator_init_fn
    
        Because call elevator_alloc, it can't hold queue_lock and the
        ->elevator_data is NULL.So at the same time, threadA call elv_merge and
        nedd some info of elevator_data.So the crash happened.
    
        Move the elevator_alloc into func elevator_init_fn, it make the
        operations in a atomic operation.
    
        Using the follow method can easy reproduce this bug
        1:dd if=/dev/sdb of=/dev/null
        2:while true;do echo noop > scheduler;echo deadline > scheduler;done
    
        The test method also use this method.
    
    Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Cc: Jonghwan Choi <jhbird.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dead45bd0527751cc9e71c0547d8f19f498441ed
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Jul 26 23:48:42 2013 +0200

    sched: Ensure update_cfs_shares() is called for parents of continuously-running tasks
    
    commit bf0bd948d1682e3996adc093b43021ed391983e6 upstream.
    
    We typically update a task_group's shares within the dequeue/enqueue
    path.  However, continuously running tasks sharing a CPU are not
    subject to these updates as they are only put/picked.  Unfortunately,
    when we reverted f269ae046 (in 17bc14b7), we lost the augmenting
    periodic update that was supposed to account for this; resulting in a
    potential loss of fairness.
    
    To fix this, re-introduce the explicit update in
    update_cfs_rq_blocked_load() [called via entity_tick()].
    
    Reported-by: Max Hailperin <max@gustavus.edu>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Reviewed-by: Paul Turner <pjt@google.com>
    Link: http://lkml.kernel.org/n/tip-9545m3apw5d93ubyrotrj31y@git.kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f30d87b004dcb4b260dcb2667d5ef6998f4aac1f
Author: yonghua zheng <younghua.zheng@gmail.com>
Date:   Tue Aug 13 16:01:03 2013 -0700

    fs/proc/task_mmu.c: fix buffer overflow in add_page_map()
    
    commit 8c8296223f3abb142be8fc31711b18a704c0e7d8 upstream.
    
    Recently we met quite a lot of random kernel panic issues after enabling
    CONFIG_PROC_PAGE_MONITOR.  After debuggind we found this has something
    to do with following bug in pagemap:
    
    In struct pagemapread:
    
      struct pagemapread {
          int pos, len;
          pagemap_entry_t *buffer;
          bool v2;
      };
    
    pos is number of PM_ENTRY_BYTES in buffer, but len is the size of
    buffer, it is a mistake to compare pos and len in add_page_map() for
    checking buffer is full or not, and this can lead to buffer overflow and
    random kernel panic issue.
    
    Correct len to be total number of PM_ENTRY_BYTES in buffer.
    
    [akpm@linux-foundation.org: document pagemapread.pos and .len units, fix PM_ENTRY_BYTES definition]
    Signed-off-by: Yonghua Zheng <younghua.zheng@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f6c19e2f7d9204bca6576f03a117bec4eaaa9b5b
Author: Radu Caragea <sinaelgl@gmail.com>
Date:   Tue Aug 13 16:00:59 2013 -0700

    x86 get_unmapped_area(): use proper mmap base for bottom-up direction
    
    commit df54d6fa54275ce59660453e29d1228c2b45a826 upstream.
    
    When the stack is set to unlimited, the bottomup direction is used for
    mmap-ings but the mmap_base is not used and thus effectively renders
    ASLR for mmapings along with PIE useless.
    
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Cc: Michel Lespinasse <walken@google.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Acked-by: Ingo Molnar <mingo@kernel.org>
    Cc: Adrian Sendroiu <molecula2788@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f01c72ef36d3305d6273fe7f1f6670c52745c3d
Author: Michal Simek <michal.simek@xilinx.com>
Date:   Tue Aug 13 16:00:53 2013 -0700

    microblaze: fix clone syscall
    
    commit dfa9771a7c4784bafd0673bc7abcee3813088b77 upstream.
    
    Fix inadvertent breakage in the clone syscall ABI for Microblaze that
    was introduced in commit f3268edbe6fe ("microblaze: switch to generic
    fork/vfork/clone").
    
    The Microblaze syscall ABI for clone takes the parent tid address in the
    4th argument; the third argument slot is used for the stack size.  The
    incorrectly-used CLONE_BACKWARDS type assigned parent tid to the 3rd
    slot.
    
    This commit restores the original ABI so that existing userspace libc
    code will work correctly.
    
    All kernel versions from v3.8-rc1 were affected.
    
    Signed-off-by: Michal Simek <michal.simek@xilinx.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0dcf19b4fb41449de4d1f953f86aa6a90accdff5
Author: Andrey Vagin <avagin@openvz.org>
Date:   Tue Aug 13 16:00:47 2013 -0700

    memcg: don't initialize kmem-cache destroying work for root caches
    
    commit 3e6b11df245180949938734bc192eaf32f3a06b3 upstream.
    
    struct memcg_cache_params has a union.  Different parts of this union
    are used for root and non-root caches.  A part with destroying work is
    used only for non-root caches.
    
    I fixed the same problem in another place v3.9-rc1-16204-gf101a94, but
    didn't notice this one.
    
    This patch fixes the kernel panic:
    
    [   46.848187] BUG: unable to handle kernel paging request at 000000fffffffeb8
    [   46.849026] IP: [<ffffffff811a484c>] kmem_cache_destroy_memcg_children+0x6c/0xc0
    [   46.849092] PGD 0
    [   46.849092] Oops: 0000 [#1] SMP
    ...
    
    Signed-off-by: Andrey Vagin <avagin@openvz.org>
    Cc: Glauber Costa <glommer@openvz.org>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Cc: Balbir Singh <bsingharora@gmail.com>
    Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6664dfcf0573495cdea96d2dd37b7d30290ae25
Author: Stephen Boyd <sboyd@codeaurora.org>
Date:   Wed Aug 7 16:18:08 2013 -0700

    perf/arm: Fix armpmu_map_hw_event()
    
    commit b88a2595b6d8aedbd275c07dfa784657b4f757eb upstream.
    
    Fix constraint check in armpmu_map_hw_event().
    
    Reported-and-tested-by: Vince Weaver <vincent.weaver@maine.edu>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78de90f9f3cbbd93d467cae8ded64f33a159dfe1
Author: Vince Weaver <vincent.weaver@maine.edu>
Date:   Fri Aug 2 10:47:34 2013 -0400

    perf/x86: Fix intel QPI uncore event definitions
    
    commit c9601247f8f3fdc18aed7ed7e490e8dfcd07f122 upstream.
    
    John McCalpin reports that the "drs_data" and "ncb_data" QPI
    uncore events are missing the "extra bit" and always return zero
    values unless the bit is properly set.
    
    More details from him:
    
     According to the Xeon E5-2600 Product Family Uncore Performance
     Monitoring Guide, Table 2-94, about 1/2 of the QPI Link Layer events
     (including the ones that "perf" calls "drs_data" and "ncb_data") require
     that the "extra bit" be set.
    
     This was confusing for a while -- a note at the bottom of page 94 says
     that the "extra bit" is bit 16 of the control register.
     Unfortunately, Table 2-86 clearly says that bit 16 is reserved and must
     be zero.  Looking around a bit, I found that bit 21 appears to be the
     correct "extra bit", and further investigation shows that "perf" actually
     agrees with me:
    	[root@c560-003.stampede]# cat /sys/bus/event_source/devices/uncore_qpi_0/format/event
    	config:0-7,21
    
     So the command
    	# perf -e "uncore_qpi_0/event=drs_data/"
     Is the same as
    	# perf -e "uncore_qpi_0/event=0x02,umask=0x08/"
     While it should be
    	# perf -e "uncore_qpi_0/event=0x102,umask=0x08/"
    
     I confirmed that this last version gives results that agree with the
     amount of data that I expected the STREAM benchmark to move across the QPI
     link in the second (cross-chip) test of the original script.
    
    Reported-by: John McCalpin <mccalpin@tacc.utexas.edu>
    Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
    Cc: zheng.z.yan@intel.com
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
    Cc: Paul Mackerras <paulus@samba.org>
    Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1308021037280.26119@vincent-weaver-1.um.maine.edu
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>