Linux 3.0.31

commit bea37381fd9a34c6660e5195d31beea86aa3dda3
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 7 09:02:36 2012 -0700

    Linux 3.0.31

commit 8792953929b01e82e57bce07cc717a0bf24384bc
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri May 4 12:09:39 2012 -0700

    hfsplus: Fix potential buffer overflows

    commit 6f24f892871acc47b40dd594c63606a17c714f77 upstream.

    Commit ec81aecb2966 ("hfs: fix a potential buffer overflow") fixed a few
    potential buffer overflows in the hfs filesystem.  But as Timo Warns
    pointed out, these changes also need to be made on the hfsplus
    filesystem as well.

    Reported-by: Timo Warns <warns@pre-sense.de>
    Acked-by: WANG Cong <amwang@redhat.com>
    Cc: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Cc: Miklos Szeredi <mszeredi@suse.cz>
    Cc: Sage Weil <sage@newdream.net>
    Cc: Eugene Teo <eteo@redhat.com>
    Cc: Roman Zippel <zippel@linux-m68k.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: Dave Anderson <anderson@redhat.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 7bfac470b517b18d496e96acc90be58353df2159
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Mar 1 15:04:46 2012 +0100

    sched: Fix nohz load accounting -- again!

    commit c308b56b5398779cd3da0f62ab26b0453494c3d4 upstream.
    [ backported to 3.0 by Kerin Millar <kerframil@gmail.com>]

    Various people reported nohz load tracking still being wrecked, but Doug
    spotted the actual problem. We fold the nohz remainder in too soon,
    causing us to loose samples and under-account.

    So instead of playing catch-up up-front, always do a single load-fold
    with whatever state we encounter and only then fold the nohz remainder
    and play catch-up.

    Reported-by: Doug Smythies <dsmythies@telus.net>
    Reported-by: LesÅ=82aw Kope=C4=87 <leslaw.kopec@nasza-klasa.pl>
    Reported-by: Aman Gupta <aman@tmm1.net>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/n/tip-4v31etnhgg9kwd6ocgx3rxl8@git.kernel.org
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Cc: Kerin Millar <kerframil@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aef49be82379e995b42648f36dd02d70f979ef2a
Author: Grazvydas Ignotas <notasas@gmail.com>
Date:   Thu Apr 26 23:07:44 2012 +0300

    wl1251: fix crash on remove due to leftover work item

    commit 4c1bcdb5a3354b250b82a67549f57ac27a3bb85f upstream.

    This driver currently leaves elp_work behind when stopping, which
    occasionally results in data corruption because work function ends
    up accessing freed memory, typical symptoms of this are various
    worker_thread crashes. Fix it by cancelling elp_work.

    Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 137c55d525bbdc509cb59abbc48fc04ba7b6a0da
Author: Grazvydas Ignotas <notasas@gmail.com>
Date:   Thu Apr 26 23:07:43 2012 +0300

    wl1251: fix crash on remove due to premature kfree

    commit 328c32f0f85467af5a6c4c3289e168d9ad2555af upstream.

    Currently SDIO glue frees it's own structure before calling
    wl1251_free_hw(), which in turn calls ieee80211_unregister_hw().
    The later call may result in a need to communicate with the chip
    to stop it (as it happens now if the interface is still up before
    rmmod), which means calls are made back to the glue, resulting in
    freed memory access.

    Fix this by freeing glue data last.

    Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4aef4293263c455992c4943fe53b8045209f383
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Thu Apr 19 21:39:06 2012 -0500

    rtlwifi: Fix oops on unload

    commit 44eb65cfd8da4b9c231238998729e858e963a980 upstream.

    Under some circumstances, a PCI-based driver reports the following OOPs:

    Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Oops: 0000 [#1] SMP
    --snip--
    Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Pid: 19627, comm: rmmod
    Not tainted 3.2.9-2.fc16.x86_64 #1 LENOVO 05962RU/05962RU
    Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP:
    0010:[<ffffffffa0418d39>]  [<ffffffffa0418d39>]
    rtl92ce_get_desc+0x19/0xd0 [rtl8192ce]
    --snip--
    Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Process rmmod (pid:
    19627, threadinfo ffff880050262000, task ffff8801156d5cc0)
    Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Stack:
    Mar 19 08:14:35 kvothe kernel: [ 6584.626011]  0000000000000002
    ffff8801176c2540 ffff880050263ca8 ffffffffa03348e7
    Mar 19 08:14:35 kvothe kernel: [ 6584.626011]  0000000000000282
    0000000180150014 ffff880050263fd8 ffff8801176c2810
    Mar 19 08:14:35 kvothe kernel: [ 6584.626011]  ffff880050263bc8
    ffffffff810550e2 00000000000002c0 ffff8801176c0d40
    Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Call Trace:
    Mar 19 08:14:35 kvothe kernel: [ 6584.626011]  [<ffffffffa03348e7>]
    _rtl_pci_rx_interrupt+0x187/0x650 [rtlwifi]
    --snip--
    Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Code: ff 09 d0 89 07 48
    83 c4 08 5b 5d c3 66 0f 1f 44 00 00 55 48 89 e5 53 48 83 ec 08 66 66
    66 66 90 40 84 f6 89 d3 74 13 84 d2 75 57 <8b> 07 48 83 c4 08 5b 5d c1
    e8 1f c3 0f 1f 00 84 d2 74 ed 80 fa
    Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP
    [<ffffffffa0418d39>] rtl92ce_get_desc+0x19/0xd0 [rtl8192ce]
    Mar 19 08:14:35 kvothe kernel: [ 6584.626011]  RSP <ffff880050263b58>
    Mar 19 08:14:35 kvothe kernel: [ 6584.626011] CR2: 00000000000006e0
    Mar 19 08:14:35 kvothe kernel: [ 6584.646491] ---[ end trace
    8636c766dcfbe0e6 ]---

    This oops is due to interrupts not being disabled in this particular path.

    Reported-by: Dave Airlie <airlied@gmail.com>
    Tested-by: Dave Airlie <airlied@gmail.com>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9bd46fe16654ee5a10dc269ebe3fc44903424707
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sun Apr 29 15:44:16 2012 +0200

    mac80211: fix AP mode EAP tx for VLAN stations

    commit 66f2c99af3d6f2d0aa1120884cf1c60613ef61c0 upstream.

    EAP frames for stations in an AP VLAN are sent on the main AP interface
    to avoid race conditions wrt. moving stations.
    For that to work properly, sta_info_get_bss must be used instead of
    sta_info_get when sending EAP packets.
    Previously this was only done for cooked monitor injected packets, so
    this patch adds a check for tx->skb->protocol to the same place.

    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b00c5b8d8590a0fe2713a4bee24e9562480ccb9e
Author: Stanislav Yakovlev <stas.yakovlev@gmail.com>
Date:   Thu Apr 19 15:55:09 2012 -0400

    ipw2200: Fix race condition in the command completion acknowledge

    commit dd447319895d0c0af423e483d9b63f84f3f8869a upstream.

    Driver incorrectly validates command completion: instead of waiting
    for a command to be acknowledged it continues execution.  Most of the
    time driver gets acknowledge of the command completion in a tasklet
    before it executes the next one. But sometimes it sends the next
    command before it gets acknowledge for the previous one. In such a
    case one of the following error messages appear in the log:

    Failed to send SYSTEM_CONFIG: Already sending a command.
    Failed to send ASSOCIATE: Already sending a command.
    Failed to send TX_POWER: Already sending a command.

    After that you need to reload the driver to get it working again.

    This bug occurs during roaming (reported by Sam Varshavchik)
    https://bugzilla.redhat.com/show_bug.cgi?id=738508
    and machine booting (reported by Tom Gundersen and Mads Kiilerich)
    https://bugs.archlinux.org/task/28097
    https://bugzilla.redhat.com/show_bug.cgi?id=802106

    This patch doesn't fix the delay issue during firmware load.
    But at least device now works as usual after boot.

    Signed-off-by: Stanislav Yakovlev <stas.yakovlev@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b476e58a834f099aa0f7b4d0a71853e6c61ee6d8
Author: Roland Stigge <stigge@antcom.de>
Date:   Wed Apr 4 10:34:37 2012 +0200

    i2c: pnx: Disable clk in suspend

    commit 6c557cfee08751d22aed34840f389b846f0f4508 upstream.

    In the driver's suspend function, clk_enable() was used instead of
    clk_disable(). This is corrected with this patch.

    Signed-off-by: Roland Stigge <stigge@antcom.de>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    [wsa: reworded commit header slightly]
    Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9051b1e1aed62944eb634c3a85fad76353e5fa05
Author: Lin Ming <ming.m.lin@intel.com>
Date:   Thu May 3 22:15:07 2012 +0800

    libata: skip old error history when counting probe trials

    commit 6868225e3e92399068be9a5f1635752d91012ad5 upstream.

    Commit d902747("[libata] Add ATA transport class") introduced
    ATA_EFLAG_OLD_ER to mark entries in the error ring as cleared.

    But ata_count_probe_trials_cb() didn't check this flag and it still
    counts the old error history. So wrong probe trials count is returned
    and it causes problem, for example, SATA link speed is slowed down from
    3.0Gbps to 1.5Gbps.

    Fix it by checking ATA_EFLAG_OLD_ER in ata_count_probe_trials_cb().

    Signed-off-by: Lin Ming <ming.m.lin@intel.com>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad567d13573186f184fb4a2ec0d3a1ca94baedbb
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Mon Apr 30 09:18:01 2012 -0400

    hwmon: (coretemp) fix oops on cpu unplug

    commit b704871124b477807966f06789c2b32f2de58bf7 upstream.

    coretemp tries to access core_data array beyond bounds on cpu unplug if
    core id of the cpu if more than NUM_REAL_CORES-1.

    BUG: unable to handle kernel NULL pointer dereference at 000000000000013c
    IP: [<ffffffffa00159af>] coretemp_cpu_callback+0x93/0x1ba [coretemp]
    PGD 673e5a067 PUD 66e9b3067 PMD 0
    Oops: 0000 [#1] SMP
    CPU 79
    Modules linked in: sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf bnep bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter nf_conntrack_ipv4 nf_defrag_ipv4 ip6_tables xt_state nf_conntrack coretemp crc32c_intel asix tpm_tis pcspkr usbnet iTCO_wdt i2c_i801 microcode mii joydev tpm i2c_core iTCO_vendor_support tpm_bios i7core_edac igb ioatdma edac_core dca megaraid_sas [last unloaded: oprofile]

    Pid: 3315, comm: set-cpus Tainted: G        W    3.4.0-rc5+ #2 QCI QSSC-S4R/QSSC-S4R
    RIP: 0010:[<ffffffffa00159af>]  [<ffffffffa00159af>] coretemp_cpu_callback+0x93/0x1ba [coretemp]
    RSP: 0018:ffff880472fb3d48  EFLAGS: 00010246
    RAX: 0000000000000124 RBX: 0000000000000034 RCX: 00000000ffffffff
    RDX: 0000000000000000 RSI: 0000000000000046 RDI: 0000000000000246
    RBP: ffff880472fb3d88 R08: ffff88077fcd36c0 R09: 0000000000000001
    R10: ffffffff8184bc48 R11: 0000000000000000 R12: ffff880273095800
    R13: 0000000000000013 R14: ffff8802730a1810 R15: 0000000000000000
    FS:  00007f694a20f720(0000) GS:ffff88077fcc0000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 000000000000013c CR3: 000000067209b000 CR4: 00000000000007e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process set-cpus (pid: 3315, threadinfo ffff880472fb2000, task ffff880471fa0000)
    Stack:
     ffff880277b4c308 0000000000000003 ffff880472fb3d88 0000000000000005
     0000000000000034 00000000ffffffd1 ffffffff81cadc70 ffff880472fb3e14
     ffff880472fb3dc8 ffffffff8161f48d ffff880471fa0000 0000000000000034
    Call Trace:
     [<ffffffff8161f48d>] notifier_call_chain+0x4d/0x70
     [<ffffffff8107f1be>] __raw_notifier_call_chain+0xe/0x10
     [<ffffffff81059d30>] __cpu_notify+0x20/0x40
     [<ffffffff815fa251>] _cpu_down+0x81/0x270
     [<ffffffff815fa477>] cpu_down+0x37/0x50
     [<ffffffff815fd6a3>] store_online+0x63/0xc0
     [<ffffffff813c7078>] dev_attr_store+0x18/0x30
     [<ffffffff811f02cf>] sysfs_write_file+0xef/0x170
     [<ffffffff81180443>] vfs_write+0xb3/0x180
     [<ffffffff8118076a>] sys_write+0x4a/0x90
     [<ffffffff816236a9>] system_call_fastpath+0x16/0x1b
    Code: 48 c7 c7 94 60 01 a0 44 0f b7 ac 10 ac 00 00 00 31 c0 e8 41 b7 5f e1 41 83 c5 02 49 63 c5 49 8b 44 c4 10 48 85 c0 74 56 45 31 ff <39> 58 18 75 4e eb 1f 49 63 d7 4c 89 f7 48 89 45 c8 48 6b d2 28
    RIP  [<ffffffffa00159af>] coretemp_cpu_callback+0x93/0x1ba [coretemp]
     RSP <ffff880472fb3d48>
    CR2: 000000000000013c

    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c31943d4c5e3facc3a67768090a2f3bf2eb757f3
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Date:   Tue May 1 08:15:42 2012 -0700

    hwmon: (coretemp) Increase CPU core limit

    commit bdc71c9a87b898e4c380c23b2e3e18071312ecde upstream.

    CPU core ID is used to index the core_data[] array. The core ID is, however, not
    sequential; 10-core CPUS can have a core ID as high as 25. Increase the limit to
    32 to be able to deal with current CPUs.

    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Acked-by: Jean Delvare <khali@linux-fr.org>
    Acked-by: Durgadoss R <durgadoss.r@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ecc53109a021559a49beb81c9c4c859012ee975e
Author: Matthew Garrett <mjg@redhat.com>
Date:   Thu May 3 16:50:46 2012 -0400

    efivars: Improve variable validation

    commit 54b3a4d311c98ad94b737802a8b5f2c8c6bfd627 upstream.

    Ben Hutchings pointed out that the validation in efivars was inadequate -
    most obviously, an entry with size 0 would server as a DoS against the
    kernel. Improve this based on his suggestions.

    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 173c412ef8f37d781eb90f5cc8eeab118b987e68
Author: Matthew Garrett <mjg@redhat.com>
Date:   Mon Apr 30 16:11:30 2012 -0400

    efi: Validate UEFI boot variables

    commit fec6c20b570bcf541e581fc97f2e0cbdb9725b98 upstream.

    A common flaw in UEFI systems is a refusal to POST triggered by a malformed
    boot variable. Once in this state, machines may only be restored by
    reflashing their firmware with an external hardware device. While this is
    obviously a firmware bug, the serious nature of the outcome suggests that
    operating systems should filter their variable writes in order to prevent
    a malicious user from rendering the machine unusable.

    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca14f0481bc8653c39e7b2fca81bc5131ac9afa8
Author: Tony Luck <tony.luck@intel.com>
Date:   Tue Aug 2 15:08:30 2011 -0700

    efivars: fix warnings when CONFIG_PSTORE=n

    commit b728a5c806fb36f9adebf2a862bbd015e074afca upstream.

    drivers/firmware/efivars.c:161: warning: ‘utf16_strlen’ defined but not used
    utf16_strlen() is only used inside CONFIG_PSTORE - make this "static inline"
    to shut the compiler up [thanks to hpa for the suggestion].

    drivers/firmware/efivars.c:602: warning: initialization from incompatible pointer type
    Between v1 and v2 of this patch series we decided to make the "part" number
    unsigned - but missed fixing the stub version of efi_pstore_write()

    Acked-by: Matthew Garrett <mjg@redhat.com>
    Acked-by: Mike Waychison <mikew@google.com>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    [took the static part of the patch, not the pstore part, for 3.0-stable,
    to fix the compiler warning we had - gregkh]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f0c771dfaece0bca44cead53ea6df64e099ae10
Author: Mike Waychison <mikew@google.com>
Date:   Thu Jul 21 16:57:57 2011 -0400

    efivars: String functions

    commit a2940908391f3cee72e38769b30e829b22742b5b upstream.

    Fix the string functions in the efivars driver to be called utf16_*
    instead of utf8_* as the encoding is utf16, not utf8.

    As well, rename utf16_strlen to utf16_strnlen as it takes a maxlength
    argument and the name should be consistent with the standard C function
    names.  utf16_strlen is still provided for convenience in a subsequent
    patch.

    Signed-off-by: Mike Waychison <mikew@google.com>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34dea1cae3e37fe34ddf7b0f7b581aebcb70db97
Author: Matthew Garrett <mjg@redhat.com>
Date:   Mon Apr 30 16:11:29 2012 -0400

    efi: Add new variable attributes

    commit 41b3254c93acc56adc3c4477fef7c9512d47659e upstream.

    More recent versions of the UEFI spec have added new attributes for
    variables. Add them.

    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cfea9a253443f5b02ea1e0f9667e6cf987069f9b
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Mar 20 10:50:27 2012 -0700

    SCSI: libsas: fix false positive 'device attached' conditions

    commit 7d1d865181185bdf1316d236b1b4bd02c9020729 upstream.

    Normalize phy->attached_sas_addr to return a zero-address in the case
    when device-type == NO_DEVICE or the linkrate is invalid to handle
    expanders that put non-zero sas addresses in the discovery response:

     sas: ex 5001b4da000f903f phy02:U:0 attached: 0100000000000000 (no device)
     sas: ex 5001b4da000f903f phy01:U:0 attached: 0100000000000000 (no device)
     sas: ex 5001b4da000f903f phy03:U:0 attached: 0100000000000000 (no device)
     sas: ex 5001b4da000f903f phy00:U:0 attached: 0100000000000000 (no device)

    Reported-by: Andrzej Jakowski <andrzej.jakowski@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c5f01a4e19099d740d85ea63e2605aa705cdd9e
Author: Thomas Jackson <thomas.p.jackson@intel.com>
Date:   Fri Feb 17 18:33:10 2012 -0800

    SCSI: libsas: fix sas_find_bcast_phy() in the presence of 'vacant' phys

    commit 1699490db339e2c6b3037ea8e7dcd6b2755b688e upstream.

    If an expander reports 'PHY VACANT' for a phy index prior to the one
    that generated a BCN libsas fails rediscovery.  Since a vacant phy is
    defined as a valid phy index that will never have an attached device
    just continue the search.

    Signed-off-by: Thomas Jackson <thomas.p.jackson@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62a17c9c34a40907e250b5ac110a5c64325f0aef
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Apr 27 12:45:07 2012 +0100

    ARM: 7403/1: tls: remove covert channel via TPIDRURW

    commit 6a1c53124aa161eb624ce7b1e40ade728186d34c upstream.

    TPIDRURW is a user read/write register forming part of the group of
    thread registers in more recent versions of the ARM architecture (~v6+).

    Currently, the kernel does not touch this register, which allows tasks
    to communicate covertly by reading and writing to the register without
    context-switching affecting its contents.

    This patch clears TPIDRURW when TPIDRURO is updated via the set_tls
    macro, which is called directly from __switch_to. Since the current
    behaviour makes the register useless to userspace as far as thread
    pointers are concerned, simply clearing the register (rather than saving
    and restoring it) will not cause any problems to userspace.

    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 70403b35a5e2d08c9e2727b2e8dd78cb0b1391b3
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Apr 29 13:30:08 2012 -0700

    autofs: make the autofsv5 packet file descriptor use a packetized pipe

    commit 64f371bc3107e69efce563a3d0f0e6880de0d537 upstream.

    The autofs packet size has had a very unfortunate size problem on x86:
    because the alignment of 'u64' differs in 32-bit and 64-bit modes, and
    because the packet data was not 8-byte aligned, the size of the autofsv5
    packet structure differed between 32-bit and 64-bit modes despite
    looking otherwise identical (300 vs 304 bytes respectively).

    We first fixed that up by making the 64-bit compat mode know about this
    problem in commit a32744d4abae ("autofs: work around unhappy compat
    problem on x86-64"), and that made a 32-bit 'systemd' work happily on a
    64-bit kernel because everything then worked the same way as on a 32-bit
    kernel.

    But it turned out that 'automount' had actually known and worked around
    this problem in user space, so fixing the kernel to do the proper 32-bit
    compatibility handling actually *broke* 32-bit automount on a 64-bit
    kernel, because it knew that the packet sizes were wrong and expected
    those incorrect sizes.

    As a result, we ended up reverting that compatibility mode fix, and
    thus breaking systemd again, in commit fcbf94b9dedd.

    With both automount and systemd doing a single read() system call, and
    verifying that they get *exactly* the size they expect but using
    different sizes, it seemed that fixing one of them inevitably seemed to
    break the other.  At one point, a patch I seriously considered applying
    from Michael Tokarev did a "strcmp()" to see if it was automount that
    was doing the operation.  Ugly, ugly.

    However, a prettier solution exists now thanks to the packetized pipe
    mode.  By marking the communication pipe as being packetized (by simply
    setting the O_DIRECT flag), we can always just write the bigger packet
    size, and if user-space does a smaller read, it will just get that
    partial end result and the extra alignment padding will simply be thrown
    away.

    This makes both automount and systemd happy, since they now get the size
    they asked for, and the kernel side of autofs simply no longer needs to
    care - it could pad out the packet arbitrarily.

    Of course, if there is some *other* user of autofs (please, please,
    please tell me it ain't so - and we haven't heard of any) that tries to
    read the packets with multiple writes, that other user will now be
    broken - the whole point of the packetized mode is that one system call
    gets exactly one packet, and you cannot read a packet in pieces.

    Tested-by: Michael Tokarev <mjt@tls.msk.ru>
    Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Cc: David Miller <davem@davemloft.net>
    Cc: Ian Kent <raven@themaw.net>
    Cc: Thomas Meyer <thomas@m3y3r.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit beed6c2e00e0dde6722b590e6a02c20248224c68
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Apr 29 13:12:42 2012 -0700

    pipes: add a "packetized pipe" mode for writing

    commit 9883035ae7edef3ec62ad215611cb8e17d6a1a5d upstream.

    The actual internal pipe implementation is already really about
    individual packets (called "pipe buffers"), and this simply exposes that
    as a special packetized mode.

    When we are in the packetized mode (marked by O_DIRECT as suggested by
    Alan Cox), a write() on a pipe will not merge the new data with previous
    writes, so each write will get a pipe buffer of its own.  The pipe
    buffer is then marked with the PIPE_BUF_FLAG_PACKET flag, which in turn
    will tell the reader side to break the read at that boundary (and throw
    away any partial packet contents that do not fit in the read buffer).

    End result: as long as you do writes less than PIPE_BUF in size (so that
    the pipe doesn't have to split them up), you can now treat the pipe as a
    packet interface, where each read() system call will read one packet at
    a time.  You can just use a sufficiently big read buffer (PIPE_BUF is
    sufficient, since bigger than that doesn't guarantee atomicity anyway),
    and the return value of the read() will naturally give you the size of
    the packet.

    NOTE! We do not support zero-sized packets, and zero-sized reads and
    writes to a pipe continue to be no-ops.  Also note that big packets will
    currently be split at write time, but that the size at which that
    happens is not really specified (except that it's bigger than PIPE_BUF).
    Currently that limit is the system page size, but we might want to
    explicitly support bigger packets some day.

    The main user for this is going to be the autofs packet interface,
    allowing us to stop having to care so deeply about exact packet sizes
    (which have had bugs with 32/64-bit compatibility modes).  But user
    space can create packetized pipes with "pipe2(fd, O_DIRECT)", which will
    fail with an EINVAL on kernels that do not support this interface.

    Tested-by: Michael Tokarev <mjt@tls.msk.ru>
    Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Cc: David Miller <davem@davemloft.net>
    Cc: Ian Kent <raven@themaw.net>
    Cc: Thomas Meyer <thomas@m3y3r.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1cb1976ecd018b02825e5a0fba06ffe95bdaedc6
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Tue Apr 24 11:29:42 2012 +0200

    usb gadget: uvc: uvc_request_data::length field must be signed

    commit 6f6543f53f9ce136e01d7114bf6f0818ca54fb41 upstream.

    The field is used to pass the UVC request data length, but can also be
    used to signal an error when setting it to a negative value. Switch from
    unsigned int to __s32.

    Reported-by: Fernandez Gonzalo <gfernandez@copreci.es>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06200304e7eb237015f433bd8884975e93aba1f5
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed Apr 11 16:09:10 2012 -0400

    USB: gadget: storage gadgets send wrong error code for unknown commands

    commit c85dcdac5852295cf6822f5c4331a6ddab72581f upstream.

    This patch (as1539) fixes a minor bug in the mass-storage gadget
    drivers.  When an unknown command is received, the error code sent
    back is "Invalid Field in CDB" rather than "Invalid Command".  This is
    because the bitmask of CDB bytes allowed to be nonzero is incorrect.

    When handling an unknown command, we don't care which command bytes
    are nonzero.  All the bits in the mask should be set, not just eight
    of them.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    CC: Michal Nazarewicz <mina86@mina86.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a8eaeff79eb97662e2d06cc1919d902fc251e9da
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue Apr 24 14:07:22 2012 -0400

    USB: EHCI: fix crash during suspend on ASUS computers

    commit 151b61284776be2d6f02d48c23c3625678960b97 upstream.

    This patch (as1545) fixes a problem affecting several ASUS computers:
    The machine crashes or corrupts memory when going into suspend if the
    ehci-hcd driver is bound to any controllers.  Users have been forced
    to unbind or unload ehci-hcd before putting their systems to sleep.

    After extensive testing, it was determined that the machines don't
    like going into suspend when any EHCI controllers are in the PCI D3
    power state.  Presumably this is a firmware bug, but there's nothing
    we can do about it except to avoid putting the controllers in D3
    during system sleep.

    The patch adds a new flag to indicate whether the problem is present,
    and avoids changing the controller's power state if the flag is set.
    Runtime suspend is unaffected; this matters only for system suspend.
    However as a side effect, the controller will not respond to remote
    wakeup requests while the system is asleep.  Hence USB wakeup is not
    functional -- but of course, this is already true in the current state
    of affairs.

    This fixes Bugzilla #42728.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Tested-by: Steven Rostedt <rostedt@goodmis.org>
    Tested-by: Andrey Rahmatullin <wrar@wrar.name>
    Tested-by: Oleksij Rempel (fishor) <bug-track@fisher-privat.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 197d1155b07b582d9969f456f61ee07d632af7e1
Author: Oliver Neukum <oliver@neukum.org>
Date:   Thu Apr 26 21:59:10 2012 +0200

    USB: cdc-wdm: fix race leading leading to memory corruption

    commit 5c22837adca7c30b66121cf18ad3e160134268d4 upstream.

    This patch fixes a race whereby a pointer to a buffer
    would be overwritten while the buffer was in use leading
    to a double free and a memory leak. This causes crashes.
    This bug was introduced in 2.6.34

    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Tested-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca288ca1de5957cb50e170dcdb5375c0e6467405
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Apr 29 18:09:01 2012 -0700

    Revert "usb: Fix build error due to dma_mask is not at pdev_archdata at ARM"

    This reverts commit d39514c14bd941232976b68e2750dc725b90e724 which is
    e90fc3cb087ce5c5f81e814358222cd6d197b5db upstream as it causes oopses on
    some ppc systems.

    Reported-by: Chen Peter-B29397 <B29397@freescale.com>
    Cc: Ramneek Mehresh <ramneek.mehresh@freescale.com>
    Cc: Peter Chen <peter.chen@freescale.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 034199be7b5b9efd9b99f34fe2f229f15e166865
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Apr 27 17:54:38 2012 -0500

    nfsd: fix error values returned by nfsd4_lockt() when nfsd_open() fails

    commit 04da6e9d63427b2d0fd04766712200c250b3278f upstream.

    nfsd_open() already returns an NFS error value; only vfs_test_lock()
    result needs to be fed through nfserrno().  Broken by commit 55ef12
    (nfsd: Ensure nfsv4 calls the underlying filesystem on LOCKT)
    three years ago...

    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2fd339e9fa7343f521e72add938fd1120f3f8d9
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Apr 27 17:42:43 2012 -0500

    nfsd: fix b0rken error value for setattr on read-only mount

    commit 96f6f98501196d46ce52c2697dd758d9300c63f5 upstream.

    ..._want_write() returns -EROFS on failure, _not_ an NFS error value.

    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dbe7f938e41ed62242b4dfc1fc77f918646fad5c
Author: Eric Bénard <eric@eukrea.com>
Date:   Fri Apr 27 17:31:18 2012 -0500

    mmc: unbreak sdhci-esdhc-imx on i.MX25

    commit b89152824f993a9572b47eb31f4579feadeac34c upstream.

    This was broken by me in 37865fe91582582a6f6c00652f6a2b1ff71f8a78
    ("mmc: sdhci-esdhc-imx: fix timeout on i.MX's sdhci") where more
    extensive tests would have shown that read or write of data to the
    card were failing (even if the partition table was correctly read).

    Signed-off-by: Eric Bénard <eric@eukrea.com>
    Acked-by: Wolfram Sang <w.sang@pengutronix.de>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a674bcab9066a2b2541d8276f5e9ff86f50ce13e
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Fri Apr 27 16:54:08 2012 -0500

    KVM: unmap pages from the iommu when slots are removed

    commit 32f6daad4651a748a58a3ab6da0611862175722f upstream.

    We've been adding new mappings, but not destroying old mappings.
    This can lead to a page leak as pages are pinned using
    get_user_pages, but only unpinned with put_page if they still
    exist in the memslots list on vm shutdown.  A memslot that is
    destroyed while an iommu domain is enabled for the guest will
    therefore result in an elevated page reference count that is
    never cleared.

    Additionally, without this fix, the iommu is only programmed
    with the first translation for a gpa.  This can result in
    peer-to-peer errors if a mapping is destroyed and replaced by a
    new mapping at the same gpa as the iommu will still be pointing
    to the original, pinned memory address.

    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9239fabf848397ec26356b5f267c787840ba4bb7
Author: David Miller <davem@davemloft.net>
Date:   Wed Apr 25 19:41:32 2012 -0500

    Fix modpost failures in fedora 17

    commit e88aa7bbbe3046a125ea1936b16bb921cc9c6349 upstream.

    The symbol table on x86-64 starts to have entries that have names
    like:

    _GLOBAL__sub_I_65535_0___mod_x86cpu_device_table

    They are of type STT_FUNCTION and this one had a length of 18.  This
    matched the device ID validation logic and it barfed because the
    length did not meet the device type's criteria.

    --------------------
    FATAL: arch/x86/crypto/aesni-intel: sizeof(struct x86cpu_device_id)=16 is not a modulo of the size of section __mod_x86cpu_device_table=18.
    Fix definition of struct x86cpu_device_id in mod_devicetable.h
    --------------------

    These are some kind of compiler tool internal stuff being emitted and
    not something we want to inspect in modpost's device ID table
    validation code.

    So skip the symbol if it is not of type STT_OBJECT.

    Signed-off-by: David S. Miller <davem@davemloft.net>
    Acked-by: Sam Ravnborg <sam@ravnborg.org>
    Signed-off-by: Michal Marek <mmarek@suse.cz>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 326f0492f8b0d4e3f1e1a7f47eddd0c0f7a644d9
Author: Arend van Spriel <arend@broadcom.com>
Date:   Wed Apr 25 17:39:59 2012 -0500

    brcm80211: smac: resume transmit fifo upon receiving frames

    commit badc4f07622f0f7093a201638f45e85765f1b5e4 upstream.

    There have been reports about not being able to use access-points
    on channel 12 and 13 or having connectivity issues when these channels
    were part of the selected regulatory domain. Upon switching to these
    channels the brcmsmac driver suspends the transmit dma fifos. This
    patch resumes them upon handing over the first received beacon to
    mac80211.

    This patch is to be applied to the stable tree for kernel versions
    3.2 and 3.3.

    Tested-by: Francesco Saverio Schiavarelli <fschiava@libero.it>
    Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
    Reviewed-by: Brett Rudley <brudley@broadcom.com>
    Signed-off-by: Arend van Spriel <arend@broadcom.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb30a2fb48b70262f9989a0d0bbc2a42ec156a22
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed Apr 25 01:17:42 2012 -0500

    EHCI: fix criterion for resuming the root hub

    commit dc75ce9d929aabeb0843a6b1a4ab320e58ba1597 upstream.

    This patch (as1542) changes the criterion ehci-hcd uses to tell when
    it needs to resume the controller's root hub.  A resume is needed when
    a port status change is detected, obviously, but only if the root hub
    is currently suspended.

    Right now the driver tests whether the root hub is running, and that
    is not the correct test.  In particular, if the controller has died
    then the root hub should not be restarted.  In addition, some buggy
    hardware occasionally requires the root hub to be running and
    sending out SOF packets even while it is nominally supposed to be
    suspended.

    In the end, the test needs to be changed.  Rather than checking whether
    the root hub is currently running, the driver will now check whether
    the root hub is currently suspended.  This will yield the correct
    behavior in all cases.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    CC: Peter Chen <B29397@freescale.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

commit 20eae41274bb811063f95a2dde0b3dda88a3d5a0
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Apr 2 10:51:55 2012 +0200

    nl80211: ensure interface is up in various APIs

    commit 2b5f8b0b44e17e625cfba1e7b88db44f4dcc0441 upstream.
    [backported by Ben Greear]

    The nl80211 handling code should ensure as much as
    it can that the interface is in a valid state, it
    can certainly ensure the interface is running.

    Not doing so can cause calls through mac80211 into
    the driver that result in warnings and unspecified
    behaviour in the driver.

    Reported-by: Ben Greear <greearb@candelatech.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Greear <greearb@candelatech.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e469853fcb813790b1d1152122d83a0f2513fc72
Author: Xi Wang <xi.wang@gmail.com>
Date:   Mon Apr 23 04:06:42 2012 -0400

    drm/i915: fix integer overflow in i915_gem_do_execbuffer()

    commit 44afb3a04391a74309d16180d1e4f8386fdfa745 upstream.

    On 32-bit systems, a large args->num_cliprects from userspace via ioctl
    may overflow the allocation size, leading to out-of-bounds access.

    This vulnerability was introduced in commit 432e58ed ("drm/i915: Avoid
    allocation for execbuffer object list").

    Signed-off-by: Xi Wang <xi.wang@gmail.com>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb247af4ccc4b082dbba85d90a42d31fd48affb2
Author: Xi Wang <xi.wang@gmail.com>
Date:   Mon Apr 23 04:06:41 2012 -0400

    drm/i915: fix integer overflow in i915_gem_execbuffer2()

    commit ed8cd3b2cd61004cab85380c52b1817aca1ca49b upstream.

    On 32-bit systems, a large args->buffer_count from userspace via ioctl
    may overflow the allocation size, leading to out-of-bounds access.

    This vulnerability was introduced in commit 8408c282 ("drm/i915:
    First try a normal large kmalloc for the temporary exec buffers").

    Signed-off-by: Xi Wang <xi.wang@gmail.com>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c9def922a843512c403d348dd033aa301e3eefe
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Apr 1 19:16:18 2012 +0200

    drm/i915: handle input/output sdvo timings separately in mode_set

    commit 6651819b4b4fc3caa6964c5d825eb4bb996f3905 upstream.

    We seem to have a decent confusion between the output timings and the
    input timings of the sdvo encoder. If I understand the code correctly,
    we use the original mode unchanged for the output timings, safe for
    the lvds case. And we should use the adjusted mode for input timings.

    Clarify the situation by adding an explicit output_dtd to the sdvo
    mode_set function and streamline the code-flow by moving the input and
    output mode setting in the sdvo encode together.

    Furthermore testing showed that the sdvo input timing needs the
    unadjusted dotclock, the sdvo chip will automatically compute the
    required pixel multiplier to get a dotclock above 100 MHz.

    Fix this up when converting a drm mode to an sdvo dtd.

    This regression was introduced in

    commit c74696b9c890074c1e1ee3d7496fc71eb3680ced
    Author: Pavel Roskin <proski@gnu.org>
    Date:   Thu Sep 2 14:46:34 2010 -0400

        i915: revert some checks added by commit 32aad86f

    particularly the following hunk:

    #	diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
    #	b/drivers/gpu/drm/i915/intel_sdvo.c
    #	index 093e914..62d22ae 100644
    #	--- a/drivers/gpu/drm/i915/intel_sdvo.c
    #	+++ b/drivers/gpu/drm/i915/intel_sdvo.c
    #	@@ -1122,11 +1123,9 @@ static void intel_sdvo_mode_set(struct drm_encoder *encoder,
    #
    #	     /* We have tried to get input timing in mode_fixup, and filled into
    #		adjusted_mode */
    #	-    if (intel_sdvo->is_tv || intel_sdvo->is_lvds) {
    #	-        intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode);
    #	+    intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode);
    #	+    if (intel_sdvo->is_tv || intel_sdvo->is_lvds)
    #		 input_dtd.part2.sdvo_flags = intel_sdvo->sdvo_flags;
    #	-    } else
    #	-        intel_sdvo_get_dtd_from_mode(&input_dtd, mode);
    #
    #	     /* If it's a TV, we already set the output timing in mode_fixup.
    #	      * Otherwise, the output timing is equal to the input timing.

    Due to questions raised in review, below a more elaborate analysis of
    the bug at hand:

    Sdvo seems to have two timings, one is the output timing which will be
    sent over whatever is connected on the other side of the sdvo chip (panel,
    hdmi screen, tv), the other is the input timing which will be generated by
    the gmch pipe. It looks like sdvo is expected to scale between the two.

    To make things slightly more complicated, we have a bunch of special
    cases:
    - For lvds panel we always use a fixed output timing, namely
      intel_sdvo->sdvo_lvds_fixed_mode, hence that special case.
    - Sdvo has an interface to generate a preferred input timing for a given
      output timing. This is the confusing thing that I've tried to clear up
      with the follow-on patches.
    - A special requirement is that the input pixel clock needs to be between
      100MHz and 200MHz (likely to keep it within the electromechanical design
      range of PCIe), 270MHz on later gen4+. Lower pixel clocks are
      doubled/quadrupled.

    The thing this patch tries to fix is that the pipe needs to be
    explicitly instructed to double/quadruple the pixels and needs the
    correspondingly higher pixel clock, whereas the sdvo adaptor seems to
    do that itself and needs the unadjusted pixel clock. For the sdvo
    encode side we already set the pixel mutliplier with a different
    command (0x21).

    This patch tries to fix this mess by:
    - Keeping the output mode timing in the unadjusted plain mode, safe
      for the lvds case.
    - Storing the input timing in the adjusted_mode with the adjusted
      pixel clock. This way we don't need to frob around with the core
      crtc mode set code.
    - Fixing up the pixelclock when constructing the sdvo dtd timing
      struct. This is why the first hunk of the patch is an integral part
      of the series.
    - Dropping the is_tv special case because input_dtd is equivalent to
      adjusted_mode after these changes. Follow-up patches clear this up
      further (by simply ripping out intel_sdvo->input_dtd because it's
      not needed).

    v2: Extend commit message with an in-depth bug analysis.

    Reported-and-Tested-by: Bernard Blackham <b-linuxgit@largestprime.net>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48157
    Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 893127e466a081703d2e2aac572bdad9c22c00ff
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Date:   Wed Apr 25 13:44:20 2012 -0700

    hwmon: (fam15h_power) Fix pci_device_id array

    commit c3e40a9972428d6e2d8e287ed0233a57a218c30f upstream.

    pci_match_id() takes an *array* of IDs which must be properly zero-
    terminated.

    Reported-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Acked-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d841e23feb06283577bd593ecd18113829a837c
Author: Andre Przywara <andre.przywara@amd.com>
Date:   Mon Apr 9 18:16:34 2012 -0400

    hwmon: fam15h_power: fix bogus values with current BIOSes

    commit 00250ec90963b7ef6678438888f3244985ecde14 upstream.

    Newer BKDG[1] versions recommend a different initialization value for
    the running average range register in the northbridge. This improves
    the power reading by avoiding counter saturations resulting in bogus
    values for anything below about 80% of TDP power consumption.
    Updated BIOSes will have this new value set up from the beginning,
    but meanwhile we correct this value ourselves.
    This needs to be done on all northbridges, even on those where the
    driver itself does not register at.

    This fixes the driver on all current machines to provide proper
    values for idle load.

    [1]
    http://support.amd.com/us/Processor_TechDocs/42301_15h_Mod_00h-0Fh_BKDG.pdf
    Chapter 3.8: D18F5xE0 Processor TDP Running Average (p. 452)

    Signed-off-by: Andre Przywara <andre.przywara@amd.com>
    Acked-by: Jean Delvare <khali@linux-fr.org>
    [guenter.roeck@ericsson.com: Removed unnecessary return statement]
    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17a766decb63b6fe4c43c06069b92b4958d7a642
Author: Nicolas Ferre <nicolas.ferre@atmel.com>
Date:   Mon Apr 16 14:46:30 2012 +0200

    dmaengine: at_hdmac: remove clear-on-read in atc_dostart()

    commit ed8b0d67f33518a16c6b2450fe5ebebf180c2d04 upstream.

    This loop on EBCISR register was designed to clear IRQ sources before enabling
    a DMA channel. This register is clear-on-read so a race condition can appear if
    another channel is already active and has just finished its transfer.
    Removing this read on EBCISR is fixing the issue as there is no case where an IRQ
    could be pending: we already make sure that this register is drained at probe()
    time and during resume.

    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a47462902d03c6e4d3412a5b703069f4dd13c44
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Thu Apr 12 17:29:36 2012 +0100

    ASoC: dapm: Ensure power gets managed for line widgets

    commit 7e1f7c8a6e517900cd84da1b8ae020f08f286c3b upstream.

    Line widgets had not been included in either the power up or power down
    sequences so if a widget had an event associated with it that event would
    never be run. Fix this minimally by adding them to the sequences, we
    should probably be doing away with the specific widget types as they all
    have the same priority anyway.

    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b09471039a7e08329eb1f48f2153bd979188351
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Thu Apr 26 13:50:03 2012 -0400

    xen/smp: Fix crash when booting with ACPI hotplug CPUs.

    commit cf405ae612b0f7e2358db7ff594c0e94846137aa upstream.

    When we boot on a machine that can hotplug CPUs and we
    are using 'dom0_max_vcpus=X' on the Xen hypervisor line
    to clip the amount of CPUs available to the initial domain,
    we get this:

    (XEN) Command line: com1=115200,8n1 dom0_mem=8G noreboot dom0_max_vcpus=8 sync_console mce_verbosity=verbose console=com1,vga loglvl=all guest_loglvl=all
    .. snip..
    DMI: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.99.99.x032.072520111118 07/25/2011
    .. snip.
    SMP: Allowing 64 CPUs, 32 hotplug CPUs
    installing Xen timer for CPU 7
    cpu 7 spinlock event irq 361
    NMI watchdog: disabled (cpu7): hardware events not enabled
    Brought up 8 CPUs
    .. snip..
    	[acpi processor finds the CPUs are not initialized and starts calling
    	arch_register_cpu, which creates /sys/devices/system/cpu/cpu8/online]
    CPU 8 got hotplugged
    CPU 9 got hotplugged
    CPU 10 got hotplugged
    .. snip..
    initcall 1_acpi_battery_init_async+0x0/0x1b returned 0 after 406 usecs
    calling  erst_init+0x0/0x2bb @ 1

    	[and the scheduler sticks newly started tasks on the new CPUs, but
    	said CPUs cannot be initialized b/c the hypervisor has limited the
    	amount of vCPUS to 8 - as per the dom0_max_vcpus=8 flag.
    	The spinlock tries to kick the other CPU, but the structure for that
    	is not initialized and we crash.]
    BUG: unable to handle kernel paging request at fffffffffffffed8
    IP: [<ffffffff81035289>] xen_spin_lock+0x29/0x60
    PGD 180d067 PUD 180e067 PMD 0
    Oops: 0002 [#1] SMP
    CPU 7
    Modules linked in:

    Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc2upstream-00001-gf5154e8 #1 Intel Corporation S2600CP/S2600CP
    RIP: e030:[<ffffffff81035289>]  [<ffffffff81035289>] xen_spin_lock+0x29/0x60
    RSP: e02b:ffff8801fb9b3a70  EFLAGS: 00010282

    With this patch, we cap the amount of vCPUS that the initial domain
    can run, to exactly what dom0_max_vcpus=X has specified.

    In the future, if there is a hypercall that will allow a running
    domain to expand past its initial set of vCPUS, this patch should
    be re-evaluated.

    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa4a6ac6d1eec0fb5c88cbc352a056ae826bc985
Author: David Vrabel <david.vrabel@citrix.com>
Date:   Thu Apr 26 19:44:06 2012 +0100

    xen: correctly check for pending events when restoring irq flags

    commit 7eb7ce4d2e8991aff4ecb71a81949a907ca755ac upstream.

    In xen_restore_fl_direct(), xen_force_evtchn_callback() was being
    called even if no events were pending.  This resulted in (depending on
    workload) about a 100 times as many xen_version hypercalls as
    necessary.

    Fix this by correcting the sense of the conditional jump.

    This seems to give a significant performance benefit for some
    workloads.

    There is some subtle tricksy "..since the check here is trying to
    check both pending and masked in a single cmpw, but I think this is
    correct. It will call check_events now only when the combined
    mask+pending word is 0x0001 (aka unmasked, pending)." (Ian)

    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d25895e8f1e5e29823d373096d8f3d271bf11821
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Apr 28 08:29:56 2012 -0700

    Revert "autofs: work around unhappy compat problem on x86-64"

    commit fcbf94b9dedd2ce08e798a99aafc94fec8668161 upstream.

    This reverts commit a32744d4abae24572eff7269bc17895c41bd0085.

    While that commit was technically the right thing to do, and made the
    x86-64 compat mode work identically to native 32-bit mode (and thus
    fixing the problem with a 32-bit systemd install on a 64-bit kernel), it
    turns out that the automount binaries had workarounds for this compat
    problem.

    Now, the workarounds are disgusting: doing an "uname()" to find out the
    architecture of the kernel, and then comparing it for the 64-bit cases
    and fixing up the size of the read() in automount for those.  And they
    were confused: it's not actually a generic 64-bit issue at all, it's
    very much tied to just x86-64, which has different alignment for an
    'u64' in 64-bit mode than in 32-bit mode.

    But the end result is that fixing the compat layer actually breaks the
    case of a 32-bit automount on a x86-64 kernel.

    There are various approaches to fix this (including just doing a
    "strcmp()" on current->comm and comparing it to "automount"), but I
    think that I will do the one that teaches pipes about a special "packet
    mode", which will allow user space to not have to care too deeply about
    the padding at the end of the autofs packet.

    That change will make the compat workaround unnecessary, so let's revert
    it first, and get automount working again in compat mode.  The
    packetized pipes will then fix autofs for systemd.

    Reported-and-requested-by: Michael Tokarev <mjt@tls.msk.ru>
    Cc: Ian Kent <raven@themaw.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 322fd620a858fab9c1ea85a7cfebe3fc041d7126
Author: Bryan O'Donoghue <bryan.odonoghue@linux.intel.com>
Date:   Wed Apr 18 17:37:39 2012 +0100

    x86, apic: APIC code touches invalid MSR on P5 class machines

    commit cbf2829b61c136edcba302a5e1b6b40e97d32c00 upstream.

    Current APIC code assumes MSR_IA32_APICBASE is present for all systems.
    Pentium Classic P5 and friends didn't have this MSR. MSR_IA32_APICBASE
    was introduced as an architectural MSR by Intel @ P6.

    Code paths that can touch this MSR invalidly are when vendor == Intel &&
    cpu-family == 5 and APIC bit is set in CPUID - or when you simply pass
    lapic on the kernel command line, on a P5.

    The below patch stops Linux incorrectly interfering with the
    MSR_IA32_APICBASE for P5 class machines. Other code paths exist that
    touch the MSR - however those paths are not currently reachable for a
    conformant P5.

    Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linux.intel.com>
    Link: http://lkml.kernel.org/r/4F8EEDD3.1080404@linux.intel.com
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95cb2c603f27af05871e3e6718b6e1e1a6f59417
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Wed Apr 18 12:48:35 2012 -0400

    NFSv4: Ensure that we check lock exclusive/shared type against open modes

    commit 55725513b5ef9d462aa3e18527658a0362aaae83 upstream.

    Since we may be simulating flock() locks using NFS byte range locks,
    we can't rely on the VFS having checked the file open mode for us.

    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03a9f194904985d2844a2906ba02306289b0b4e7
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Wed Apr 18 12:20:10 2012 -0400

    NFSv4: Ensure that the LOCK code sets exception->inode

    commit 05ffe24f5290dc095f98fbaf84afe51ef404ccc5 upstream.

    All callers of nfs4_handle_exception() that need to handle
    NFS4ERR_OPENMODE correctly should set exception->inode

    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb2fee3223eaaeaab386d635fa905ad3925ca539
Author: Jan Kara <jack@suse.cz>
Date:   Sat Sep 3 01:09:43 2011 +0200

    nfs: Enclose hostname in brackets when needed in nfs_do_root_mount

    commit 98a2139f4f4d7b5fcc3a54c7fddbe88612abed20 upstream.

    When hostname contains colon (e.g. when it is an IPv6 address) it needs
    to be enclosed in brackets to make parsing of NFS device string possible.
    Fix nfs_do_root_mount() to enclose hostname properly when needed. NFS code
    actually does not need this as it does not parse the string passed by
    nfs_do_root_mount() but the device string is exposed to userspace in
    /proc/mounts.

    CC: Josh Boyer <jwboyer@redhat.com>
    CC: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>