commit ab78f676b9218240a6e8b2265db3fbc98a896811
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Jul 16 09:15:38 2012 -0700

    Linux 3.0.37

commit 05e3b20ed735718a6fecbeb1f1234c15628145f0
Author: Feng Tang <feng.tang@intel.com>
Date:   Mon Jun 4 15:00:05 2012 +0800

    ACPI: Remove one board specific WARN when ignoring timer overriding
    
    commit 7f68b4c2e158019c2ec494b5cfbd9c83b4e5b253 upstream.
    
    Current WARN msg is only for the ati_ixp4x0 board, while this function
    is used by mulitple platforms. So this one board specific warning
    is not appropriate any more.
    
    Signed-off-by: Feng Tang <feng.tang@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62aae691aaecc2695294cfdc6719f7bd5bbcd9c6
Author: Feng Tang <feng.tang@intel.com>
Date:   Mon Jun 4 15:00:04 2012 +0800

    ACPI: Make acpi_skip_timer_override cover all source_irq==0 cases
    
    commit ae10ccdc3093486f8c2369d227583f9d79f628e5 upstream.
    
    Currently when acpi_skip_timer_override is set, it only cover the
    (source_irq == 0 && global_irq == 2) cases. While there is also
    platform which need use this option and its global_irq is not 2.
    This patch will extend acpi_skip_timer_override to cover all
    timer overriding cases as long as the source irq is 0.
    
    This is the first part of a fix to kernel bug bugzilla 40002:
    	"IRQ 0 assigned to VGA"
    https://bugzilla.kernel.org/show_bug.cgi?id=40002
    
    Reported-and-tested-by: Szymon Kowalczyk <fazerxlo@o2.pl>
    Signed-off-by: Feng Tang <feng.tang@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e12fcd38abe8a869cbabd77724008f1cf812a3e7
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Thu Jul 5 16:00:11 2012 -0700

    mm: Hold a file reference in madvise_remove
    
    commit 9ab4233dd08036fe34a89c7dc6f47a8bf2eb29eb upstream.
    
    Otherwise the code races with munmap (causing a use-after-free
    of the vma) or with close (causing a use-after-free of the struct
    file).
    
    The bug was introduced by commit 90ed52ebe481 ("[PATCH] holepunch: fix
    mmap_sem i_mutex deadlock")
    
    [bwh: Backported to 3.2:
     - Adjust context
     - madvise_remove() calls vmtruncate_range(), not do_fallocate()]
    [luto: Backported to 3.0: Adjust context]
    
    Cc: Hugh Dickins <hugh@veritas.com>
    Cc: Miklos Szeredi <mszeredi@suse.cz>
    Cc: Badari Pulavarty <pbadari@us.ibm.com>
    Cc: Nick Piggin <npiggin@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8e252d7a5687e0c9f11d3c36e3a867a1e64b418
Author: Bob Liu <lliubbo@gmail.com>
Date:   Wed Jul 11 14:02:35 2012 -0700

    fs: ramfs: file-nommu: add SetPageUptodate()
    
    commit fea9f718b3d68147f162ed2d870183ce5e0ad8d8 upstream.
    
    There is a bug in the below scenario for !CONFIG_MMU:
    
     1. create a new file
     2. mmap the file and write to it
     3. read the file can't get the correct value
    
    Because
    
      sys_read() -> generic_file_aio_read() -> simple_readpage() -> clear_page()
    
    which causes the page to be zeroed.
    
    Add SetPageUptodate() to ramfs_nommu_expand_for_mapping() so that
    generic_file_aio_read() do not call simple_readpage().
    
    Signed-off-by: Bob Liu <lliubbo@gmail.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Greg Ungerer <gerg@uclinux.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 c58c52e0f44d2883ddc31ac021b88a121b332982
Author: David Rientjes <rientjes@google.com>
Date:   Wed Jul 11 14:02:13 2012 -0700

    mm, thp: abort compaction if migration page cannot be charged to memcg
    
    commit 4bf2bba3750f10aa9e62e6949bc7e8329990f01b upstream.
    
    If page migration cannot charge the temporary page to the memcg,
    migrate_pages() will return -ENOMEM.  This isn't considered in memory
    compaction however, and the loop continues to iterate over all
    pageblocks trying to isolate and migrate pages.  If a small number of
    very large memcgs happen to be oom, however, these attempts will mostly
    be futile leading to an enormous amout of cpu consumption due to the
    page migration failures.
    
    This patch will short circuit and fail memory compaction if
    migrate_pages() returns -ENOMEM.  COMPACT_PARTIAL is returned in case
    some migrations were successful so that the page allocator will retry.
    
    Signed-off-by: David Rientjes <rientjes@google.com>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.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 08ccc046aa38dca8214b8a1dcef2c711d8b94f2f
Author: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Date:   Wed Jul 11 14:02:32 2012 -0700

    drivers/rtc/rtc-mxc.c: fix irq enabled interrupts warning
    
    commit b59f6d1febd6cbe9fae4589bf72da0ed32bc69e0 upstream.
    
    Fixes
    
      WARNING: at irq/handle.c:146 handle_irq_event_percpu+0x19c/0x1b8()
      irq 25 handler mxc_rtc_interrupt+0x0/0xac enabled interrupts
      Modules linked in:
       (unwind_backtrace+0x0/0xf0) from (warn_slowpath_common+0x4c/0x64)
       (warn_slowpath_common+0x4c/0x64) from (warn_slowpath_fmt+0x30/0x40)
       (warn_slowpath_fmt+0x30/0x40) from (handle_irq_event_percpu+0x19c/0x1b8)
       (handle_irq_event_percpu+0x19c/0x1b8) from (handle_irq_event+0x28/0x38)
       (handle_irq_event+0x28/0x38) from (handle_level_irq+0x80/0xc4)
       (handle_level_irq+0x80/0xc4) from (generic_handle_irq+0x24/0x38)
       (generic_handle_irq+0x24/0x38) from (handle_IRQ+0x30/0x84)
       (handle_IRQ+0x30/0x84) from (avic_handle_irq+0x2c/0x4c)
       (avic_handle_irq+0x2c/0x4c) from (__irq_svc+0x40/0x60)
      Exception stack(0xc050bf60 to 0xc050bfa8)
      bf60: 00000001 00000000 003c4208 c0018e20 c050a000 c050a000 c054a4c8 c050a000
      bf80: c05157a8 4117b363 80503bb4 00000000 01000000 c050bfa8 c0018e2c c000e808
      bfa0: 60000013 ffffffff
       (__irq_svc+0x40/0x60) from (default_idle+0x1c/0x30)
       (default_idle+0x1c/0x30) from (cpu_idle+0x68/0xa8)
       (cpu_idle+0x68/0xa8) from (start_kernel+0x22c/0x26c)
    
    Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
    Cc: Alessandro Zummo <a.zummo@towertech.it>
    Cc: Sascha Hauer <kernel@pengutronix.de>
    Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    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 32ef2126fabc8a984506a1a4e83f3459ba1a2075
Author: Jiang Liu <jiang.liu@huawei.com>
Date:   Wed Jul 11 14:01:52 2012 -0700

    memory hotplug: fix invalid memory access caused by stale kswapd pointer
    
    commit d8adde17e5f858427504725218c56aef90e90fc7 upstream.
    
    kswapd_stop() is called to destroy the kswapd work thread when all memory
    of a NUMA node has been offlined.  But kswapd_stop() only terminates the
    work thread without resetting NODE_DATA(nid)->kswapd to NULL.  The stale
    pointer will prevent kswapd_run() from creating a new work thread when
    adding memory to the memory-less NUMA node again.  Eventually the stale
    pointer may cause invalid memory access.
    
    An example stack dump as below. It's reproduced with 2.6.32, but latest
    kernel has the same issue.
    
      BUG: unable to handle kernel NULL pointer dereference at (null)
      IP: [<ffffffff81051a94>] exit_creds+0x12/0x78
      PGD 0
      Oops: 0000 [#1] SMP
      last sysfs file: /sys/devices/system/memory/memory391/state
      CPU 11
      Modules linked in: cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq microcode fuse loop dm_mod tpm_tis rtc_cmos i2c_i801 rtc_core tpm serio_raw pcspkr sg tpm_bios igb i2c_core iTCO_wdt rtc_lib mptctl iTCO_vendor_support button dca bnx2 usbhid hid uhci_hcd ehci_hcd usbcore sd_mod crc_t10dif edd ext3 mbcache jbd fan ide_pci_generic ide_core ata_generic ata_piix libata thermal processor thermal_sys hwmon mptsas mptscsih mptbase scsi_transport_sas scsi_mod
      Pid: 7949, comm: sh Not tainted 2.6.32.12-qiuxishi-5-default #92 Tecal RH2285
      RIP: 0010:exit_creds+0x12/0x78
      RSP: 0018:ffff8806044f1d78  EFLAGS: 00010202
      RAX: 0000000000000000 RBX: ffff880604f22140 RCX: 0000000000019502
      RDX: 0000000000000000 RSI: 0000000000000202 RDI: 0000000000000000
      RBP: ffff880604f22150 R08: 0000000000000000 R09: ffffffff81a4dc10
      R10: 00000000000032a0 R11: ffff880006202500 R12: 0000000000000000
      R13: 0000000000c40000 R14: 0000000000008000 R15: 0000000000000001
      FS:  00007fbc03d066f0(0000) GS:ffff8800282e0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000000 CR3: 000000060f029000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process sh (pid: 7949, threadinfo ffff8806044f0000, task ffff880603d7c600)
      Stack:
       ffff880604f22140 ffffffff8103aac5 ffff880604f22140 ffffffff8104d21e
       ffff880006202500 0000000000008000 0000000000c38000 ffffffff810bd5b1
       0000000000000000 ffff880603d7c600 00000000ffffdd29 0000000000000003
      Call Trace:
        __put_task_struct+0x5d/0x97
        kthread_stop+0x50/0x58
        offline_pages+0x324/0x3da
        memory_block_change_state+0x179/0x1db
        store_mem_state+0x9e/0xbb
        sysfs_write_file+0xd0/0x107
        vfs_write+0xad/0x169
        sys_write+0x45/0x6e
        system_call_fastpath+0x16/0x1b
      Code: ff 4d 00 0f 94 c0 84 c0 74 08 48 89 ef e8 1f fd ff ff 5b 5d 31 c0 41 5c c3 53 48 8b 87 20 06 00 00 48 89 fb 48 8b bf 18 06 00 00 <8b> 00 48 c7 83 18 06 00 00 00 00 00 00 f0 ff 0f 0f 94 c0 84 c0
      RIP  exit_creds+0x12/0x78
       RSP <ffff8806044f1d78>
      CR2: 0000000000000000
    
    [akpm@linux-foundation.org: add pglist_data.kswapd locking comments]
    Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
    Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
    Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Acked-by: David Rientjes <rientjes@google.com>
    Reviewed-by: Minchan Kim <minchan@kernel.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 cc675040202e8f4e825a91997319b4b0bf9e9960
Author: NeilBrown <neilb@suse.de>
Date:   Tue Jul 3 10:37:30 2012 +1000

    md/raid10: Don't try to recovery unmatched (and unused) chunks.
    
    commit fc448a18ae6219af9a73257b1fbcd009efab4a81 upstream.
    
    If a RAID10 has an odd number of chunks - as might happen when there
    are an odd number of devices - the last chunk has no pair and so is
    not mirrored.  We don't store data there, but when recovering the last
    device in an array we retry to recover that last chunk from a
    non-existent location.  This results in an error, and the recovery
    aborts.
    
    When we get to that last chunk we should just stop - there is nothing
    more to do anyway.
    
    This bug has been present since the introduction of RAID10, so the
    patch is appropriate for any -stable kernel.
    
    Reported-by: Christian Balzer <chibi@gol.com>
    Tested-by: Christian Balzer <chibi@gol.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a9ff20c3a8c4e907eb8ae0f7f4f14785cfe2e49
Author: majianpeng <majianpeng@gmail.com>
Date:   Tue Jun 12 08:31:10 2012 +0800

    md/raid5: Do not add data_offset before call to is_badblock
    
    commit 6c0544e255dd6582a9899572e120fb55d9f672a4 upstream.
    
    In chunk_aligned_read() we are adding data_offset before calling
    is_badblock.  But is_badblock also adds data_offset, so that is bad.
    
    So move the addition of data_offset to after the call to
    is_badblock.
    
    This bug was introduced by commit 31c176ecdf3563140e639
         md/raid5: avoid reading from known bad blocks.
    which first appeared in 3.0.  So that patch is suitable for any
    -stable kernel from 3.0.y onwards.  However it will need minor
    revision for most of those (as the comment didn't appear until
    recently).
    
    Signed-off-by: majianpeng <majianpeng@gmail.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    [bwh: Backported to 3.2: ignored missing comment]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8d210c8900b8e4f495c15b4e6238552921eb65c
Author: H. Peter Anvin <hpa@linux.intel.com>
Date:   Fri Jun 22 10:58:06 2012 -0700

    x86, cpufeature: Rename X86_FEATURE_DTS to X86_FEATURE_DTHERM
    
    commit 4ad33411308596f2f918603509729922a1ec4411 upstream.
    
    It makes sense to label "Digital Thermal Sensor" as "DTS", but
    unfortunately the string "dts" was already used for "Debug Store", and
    /proc/cpuinfo is a user space ABI.
    
    Therefore, rename this to "dtherm".
    
    This conflict went into mainline via the hwmon tree without any x86
    maintainer ack, and without any kind of hint in the subject.
    
        a4659053 x86/hwmon: fix initialization of coretemp
    
    Reported-by: Jean Delvare <khali@linux-fr.org>
    Link: http://lkml.kernel.org/r/4FE34BCB.5050305@linux.intel.com
    Cc: Jan Beulich <JBeulich@suse.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    [bwh: Backported to 3.2: drop the coretemp device table change]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 665bcdee8212277aecfb0095cddfd0f864d7f7b2
Author: Tao Guo <glorioustao@gmail.com>
Date:   Wed Jun 13 21:17:21 2012 +0200

    umem: fix up unplugging
    
    commit 32587371ad3db2f9d335de10dbd8cffd4fff5669 upstream.
    
    Fix a regression introduced by 7eaceaccab5f40 ("block: remove per-queue
    plugging").  In that patch, Jens removed the whole mm_unplug_device()
    function, which used to be the trigger to make umem start to work.
    
    We need to implement unplugging to make umem start to work, or I/O will
    never be triggered.
    
    Signed-off-by: Tao Guo <Tao.Guo@emc.com>
    Cc: Neil Brown <neilb@suse.de>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Shaohua Li <shli@kernel.org>
    Cc: <stable@vger.kernel.org>
    Acked-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a62ab54c2f6f5bc52b99e2c6b2382655483bd97
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Wed May 16 11:06:21 2012 +0200

    rtl8187: ->brightness_set can not sleep
    
    commit 0fde0a8cfd0ede7f310d6a681c8e5a7cb3e32406 upstream.
    
    Fix:
    
    BUG: sleeping function called from invalid context at kernel/workqueue.c:2547
    in_atomic(): 1, irqs_disabled(): 0, pid: 629, name: wpa_supplicant
    2 locks held by wpa_supplicant/629:
     #0:  (rtnl_mutex){+.+.+.}, at: [<c08b2b84>] rtnl_lock+0x14/0x20
     #1:  (&trigger->leddev_list_lock){.+.?..}, at: [<c0867f41>] led_trigger_event+0x21/0x80
    Pid: 629, comm: wpa_supplicant Not tainted 3.3.0-0.rc3.git5.1.fc17.i686
    Call Trace:
     [<c046a9f6>] __might_sleep+0x126/0x1d0
     [<c0457d6c>] wait_on_work+0x2c/0x1d0
     [<c045a09a>] __cancel_work_timer+0x6a/0x120
     [<c045a160>] cancel_delayed_work_sync+0x10/0x20
     [<f7dd3c22>] rtl8187_led_brightness_set+0x82/0xf0 [rtl8187]
     [<c0867f7c>] led_trigger_event+0x5c/0x80
     [<f7ff5e6d>] ieee80211_led_radio+0x1d/0x40 [mac80211]
     [<f7ff3583>] ieee80211_stop_device+0x13/0x230 [mac80211]
    
    Removing _sync is ok, because if led_on work is currently running
    it will be finished before led_off work start to perform, since
    they are always queued on the same mac80211 local->workqueue.
    
    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=795176
    
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
    Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Cc: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 457ef719563ead5f78cbb2a6394468e2237436b2
Author: Shaohua Li <shli@kernel.org>
Date:   Tue Jul 3 15:57:19 2012 +1000

    raid5: delayed stripe fix
    
    commit fab363b5ff502d1b39ddcfec04271f5858d9f26e upstream.
    
    There isn't locking setting STRIPE_DELAYED and STRIPE_PREREAD_ACTIVE bits, but
    the two bits have relationship. A delayed stripe can be moved to hold list only
    when preread active stripe count is below IO_THRESHOLD. If a stripe has both
    the bits set, such stripe will be in delayed list and preread count not 0,
    which will make such stripe never leave delayed list.
    
    Signed-off-by: Shaohua Li <shli@fusionio.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df5d64692d422f7df2e3221a95408b4ccf520fd0
Author: Nadav Har'El <nyh@math.technion.ac.il>
Date:   Mon Feb 27 15:07:29 2012 +0200

    vhost: don't forget to schedule()
    
    commit d550dda192c1bd039afb774b99485e88b70d7cb8 upstream.
    
    This is a tiny, but important, patch to vhost.
    
    Vhost's worker thread only called schedule() when it had no work to do, and
    it wanted to go to sleep. But if there's always work to do, e.g., the guest
    is running a network-intensive program like netperf with small message sizes,
    schedule() was *never* called. This had several negative implications (on
    non-preemptive kernels):
    
     1. Passing time was not properly accounted to the "vhost" process (ps and
        top would wrongly show it using zero CPU time).
    
     2. Sometimes error messages about RCU timeouts would be printed, if the
        core running the vhost thread didn't schedule() for a very long time.
    
     3. Worst of all, a vhost thread would "hog" the core. If several vhost
        threads need to share the same core, typically one would get most of the
        CPU time (and its associated guest most of the performance), while the
        others hardly get any work done.
    
    The trivial solution is to add
    
    	if (need_resched())
    		schedule();
    
    After doing every piece of work. This will not do the heavy schedule() all
    the time, just when the timer interrupt decided a reschedule is warranted
    (so need_resched returns true).
    
    Thanks to Abel Gordon for this patch.
    
    Signed-off-by: Nadav Har'El <nyh@il.ibm.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Cc: Jean Delvare <jdelvare@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f437e75ac267fa886bcbe7ab40d8f1ba1de1c865
Author: Vaibhav Nagarnaik <vnagarnaik@google.com>
Date:   Thu May 3 18:59:52 2012 -0700

    tracing: change CPU ring buffer state from tracing_cpumask
    
    commit 71babb2705e2203a64c27ede13ae3508a0d2c16c upstream.
    
    According to Documentation/trace/ftrace.txt:
    
    tracing_cpumask:
    
            This is a mask that lets the user only trace
            on specified CPUS. The format is a hex string
            representing the CPUS.
    
    The tracing_cpumask currently doesn't affect the tracing state of
    per-CPU ring buffers.
    
    This patch enables/disables CPU recording as its corresponding bit in
    tracing_cpumask is set/unset.
    
    Link: http://lkml.kernel.org/r/1336096792-25373-3-git-send-email-vnagarnaik@google.com
    
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Laurent Chavey <chavey@google.com>
    Cc: Justin Teravest <teravest@google.com>
    Cc: David Sharp <dhsharp@google.com>
    Signed-off-by: Vaibhav Nagarnaik <vnagarnaik@google.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ad82cf77831c4597aee3aa5e225eecd535914db
Author: Davide Gerhard <rainbow@irh.it>
Date:   Mon Jun 25 09:04:47 2012 +0200

    ipheth: add support for iPad
    
    commit 6de0298ec9c1edaf330b71b57346241ece8f3346 upstream.
    
    This adds support for the iPad to the ipheth driver.
    (product id = 0x129a)
    
    Signed-off-by: Davide Gerhard <rainbow@irh.it>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 671e3aaf0ce971311ab8405bf2acc295ce999529
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Fri Jun 22 09:51:03 2012 -0700

    xhci: Avoid dead ports when CONFIG_USB_XHCI_HCD=n
    
    Commit 51c9e6c7732b67769c0a514d31f505e49fa82dd4 upstream, but modified
    to get this to apply on 3.0.
    
    If the user chooses to say "no" to CONFIG_USB_XHCI_HCD on a system
    with an Intel Panther Point chipset, the PCI quirks code or the EHCI
    driver will switch the ports over to the xHCI host, but the xHCI driver
    will never load.  The ports will be powered off and seem "dead" to the
    user.
    
    Fix this by only switching the ports over if CONFIG_USB_XHCI_HCD is
    either compiled in, or compiled as a module.
    
    This patch should be backported to the 3.0 stable kernel, since it
    contains the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel
    xhci: Support EHCI/xHCI port switching."
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Reported-by: Eric Anholt <eric.anholt@intel.com>
    Reported-by: David Bein <d.bein@f5.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8cac2a0c0fc42e283e17352bebe1e662fa89c13b
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon Jul 9 11:09:21 2012 -0400

    PCI: EHCI: fix crash during suspend on ASUS computers
    
    commit dbf0e4c7257f8d684ec1a3c919853464293de66e upstream.
    
    Quite a few ASUS computers experience a nasty problem, related to the
    EHCI controllers, when going into system suspend.  It was observed
    that the problem didn't occur if the controllers were not put into the
    D3 power state before starting the suspend, and commit
    151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during
    suspend on ASUS computers) was created to do this.
    
    It turned out this approach messed up other computers that didn't have
    the problem -- it prevented USB wakeup from working.  Consequently
    commit c2fb8a3fa25513de8fedb38509b1f15a5bbee47b (USB: add
    NO_D3_DURING_SLEEP flag and revert 151b61284776be2) was merged; it
    reverted the earlier commit and added a whitelist of known good board
    names.
    
    Now we know the actual cause of the problem.  Thanks to AceLan Kao for
    tracking it down.
    
    According to him, an engineer at ASUS explained that some of their
    BIOSes contain a bug that was added in an attempt to work around a
    problem in early versions of Windows.  When the computer goes into S3
    suspend, the BIOS tries to verify that the EHCI controllers were first
    quiesced by the OS.  Nothing's wrong with this, but the BIOS does it
    by checking that the PCI COMMAND registers contain 0 without checking
    the controllers' power state.  If the register isn't 0, the BIOS
    assumes the controller needs to be quiesced and tries to do so.  This
    involves making various MMIO accesses to the controller, which don't
    work very well if the controller is already in D3.  The end result is
    a system hang or memory corruption.
    
    Since the value in the PCI COMMAND register doesn't matter once the
    controller has been suspended, and since the value will be restored
    anyway when the controller is resumed, we can work around the BIOS bug
    simply by setting the register to 0 during system suspend.  This patch
    (as1590) does so and also reverts the second commit mentioned above,
    which is now unnecessary.
    
    In theory we could do this for every PCI device.  However to avoid
    introducing new problems, the patch restricts itself to EHCI host
    controllers.
    
    Finally the affected systems can suspend with USB wakeup working
    properly.
    
    Reference: https://bugzilla.kernel.org/show_bug.cgi?id=37632
    Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42728
    Based-on-patch-by: AceLan Kao <acelan.kao@canonical.com>
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Tested-by: Dâniel Fraga <fragabr@gmail.com>
    Tested-by: Javier Marcet <jmarcet@gmail.com>
    Tested-by: Andrey Rahmatullin <wrar@wrar.name>
    Tested-by: Oleksij Rempel <bug-track@fisher-privat.net>
    Tested-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
    Acked-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2be9ba94c3fa8b6ae608b8d02930a144afa6ee62
Author: Gaosen Zhang <gaosen.zhang@mediatek.com>
Date:   Thu Jul 5 21:49:00 2012 +0800

    USB: option: Add MEDIATEK product ids
    
    commit aacef9c561a693341566a6850c451ce3df68cb9a upstream.
    
    Signed-off-by: Gaosen Zhang <gaosen.zhang@mediatek.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f029b4965222ae903fad68cd89da60741458a3e
Author: Bjørn Mork <bjorn@mork.no>
Date:   Mon Jul 2 19:53:55 2012 +0200

    USB: option: add ZTE MF60
    
    commit 8e16e33c168a6efd0c9f7fa9dd4c1e1db9a74553 upstream.
    
    Switches into a composite device by ejecting the initial
    driver CD.  The four interfaces are: QCDM, AT, QMI/wwan
    and mass storage.  Let this driver manage the two serial
    interfaces:
    
    T:  Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 28 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=19d2 ProdID=1402 Rev= 0.00
    S:  Manufacturer=ZTE,Incorporated
    S:  Product=ZTE WCDMA Technologies MSM
    S:  SerialNumber=xxxxx
    C:* #Ifs= 4 Cfg#= 1 Atr=c0 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a8d90cd4f0e7be30a8d486da1202752dc86e96f
Author: Bjørn Mork <bjorn@mork.no>
Date:   Mon Jul 2 10:33:14 2012 +0200

    USB: cdc-wdm: fix lockup on error in wdm_read
    
    commit b086b6b10d9f182cd8d2f0dcfd7fd11edba93fc9 upstream.
    
    Clear the WDM_READ flag on empty reads to avoid running
    forever in an infinite tight loop, causing lockups:
    
    Jul  1 21:58:11 nemi kernel: [ 3658.898647] qmi_wwan 2-1:1.2: Unexpected error -71
    Jul  1 21:58:36 nemi kernel: [ 3684.072021] BUG: soft lockup - CPU#0 stuck for 23s! [qmi.pl:12235]
    Jul  1 21:58:36 nemi kernel: [ 3684.072212] CPU 0
    Jul  1 21:58:36 nemi kernel: [ 3684.072355]
    Jul  1 21:58:36 nemi kernel: [ 3684.072367] Pid: 12235, comm: qmi.pl Tainted: P           O 3.5.0-rc2+ #13 LENOVO 2776LEG/2776LEG
    Jul  1 21:58:36 nemi kernel: [ 3684.072383] RIP: 0010:[<ffffffffa0635008>]  [<ffffffffa0635008>] spin_unlock_irq+0x8/0xc [cdc_wdm]
    Jul  1 21:58:36 nemi kernel: [ 3684.072388] RSP: 0018:ffff88022dca1e70  EFLAGS: 00000282
    Jul  1 21:58:36 nemi kernel: [ 3684.072393] RAX: ffff88022fc3f650 RBX: ffffffff811c56f7 RCX: 00000001000ce8c1
    Jul  1 21:58:36 nemi kernel: [ 3684.072398] RDX: 0000000000000010 RSI: 000000000267d810 RDI: ffff88022fc3f650
    Jul  1 21:58:36 nemi kernel: [ 3684.072403] RBP: ffff88022dca1eb0 R08: ffffffffa063578e R09: 0000000000000000
    Jul  1 21:58:36 nemi kernel: [ 3684.072407] R10: 0000000000000008 R11: 0000000000000246 R12: 0000000000000002
    Jul  1 21:58:36 nemi kernel: [ 3684.072412] R13: 0000000000000246 R14: ffffffff00000002 R15: ffff8802281d8c88
    Jul  1 21:58:36 nemi kernel: [ 3684.072418] FS:  00007f666a260700(0000) GS:ffff88023bc00000(0000) knlGS:0000000000000000
    Jul  1 21:58:36 nemi kernel: [ 3684.072423] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    Jul  1 21:58:36 nemi kernel: [ 3684.072428] CR2: 000000000270d9d8 CR3: 000000022e865000 CR4: 00000000000007f0
    Jul  1 21:58:36 nemi kernel: [ 3684.072433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    Jul  1 21:58:36 nemi kernel: [ 3684.072438] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Jul  1 21:58:36 nemi kernel: [ 3684.072444] Process qmi.pl (pid: 12235, threadinfo ffff88022dca0000, task ffff88022ff76380)
    Jul  1 21:58:36 nemi kernel: [ 3684.072448] Stack:
    Jul  1 21:58:36 nemi kernel: [ 3684.072458]  ffffffffa063592e 0000000100020000 ffff88022fc3f650 ffff88022fc3f6a8
    Jul  1 21:58:36 nemi kernel: [ 3684.072466]  0000000000000200 0000000100000000 000000000267d810 0000000000000000
    Jul  1 21:58:36 nemi kernel: [ 3684.072475]  0000000000000000 ffff880212cfb6d0 0000000000000200 ffff880212cfb6c0
    Jul  1 21:58:36 nemi kernel: [ 3684.072479] Call Trace:
    Jul  1 21:58:36 nemi kernel: [ 3684.072489]  [<ffffffffa063592e>] ? wdm_read+0x1a0/0x263 [cdc_wdm]
    Jul  1 21:58:36 nemi kernel: [ 3684.072500]  [<ffffffff8110adb7>] ? vfs_read+0xa1/0xfb
    Jul  1 21:58:36 nemi kernel: [ 3684.072509]  [<ffffffff81040589>] ? alarm_setitimer+0x35/0x64
    Jul  1 21:58:36 nemi kernel: [ 3684.072517]  [<ffffffff8110aec7>] ? sys_read+0x45/0x6e
    Jul  1 21:58:36 nemi kernel: [ 3684.072525]  [<ffffffff813725f9>] ? system_call_fastpath+0x16/0x1b
    Jul  1 21:58:36 nemi kernel: [ 3684.072557] Code: <66> 66 90 c3 83 ff ed 89 f8 74 16 7f 06 83 ff a1 75 0a c3 83 ff f4
    
    The WDM_READ flag is normally cleared by wdm_int_callback
    before resubmitting the read urb, and set by wdm_in_callback
    when this urb returns with data or an error.  But a crashing
    device may cause both a read error and cancelling all urbs.
    Make sure that the flag is cleared by wdm_read if the buffer
    is empty.
    
    We don't clear the flag on errors, as there may be pending
    data in the buffer which should be processed.  The flag will
    instead be cleared on the next wdm_read call.
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Acked-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad54262e86a5220e853f4aaf2cda51926e03f650
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Tue Jun 12 11:17:01 2012 -0700

    eCryptfs: Properly check for O_RDONLY flag before doing privileged open
    
    commit 9fe79d7600497ed8a95c3981cbe5b73ab98222f0 upstream.
    
    If the first attempt at opening the lower file read/write fails,
    eCryptfs will retry using a privileged kthread. However, the privileged
    retry should not happen if the lower file's inode is read-only because a
    read/write open will still be unsuccessful.
    
    The check for determining if the open should be retried was intended to
    be based on the access mode of the lower file's open flags being
    O_RDONLY, but the check was incorrectly performed. This would cause the
    open to be retried by the privileged kthread, resulting in a second
    failed open of the lower file. This patch corrects the check to
    determine if the open request should be handled by the privileged
    kthread.
    
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 092c1927ef479124a34fcf0646cf5c403f9b16e5
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Mon Jun 11 10:21:34 2012 -0700

    eCryptfs: Fix lockdep warning in miscdev operations
    
    commit 60d65f1f07a7d81d3eb3b91fc13fca80f2fdbb12 upstream.
    
    Don't grab the daemon mutex while holding the message context mutex.
    Addresses this lockdep warning:
    
     ecryptfsd/2141 is trying to acquire lock:
      (&ecryptfs_msg_ctx_arr[i].mux){+.+.+.}, at: [<ffffffffa029c213>] ecryptfs_miscdev_read+0x143/0x470 [ecryptfs]
    
     but task is already holding lock:
      (&(*daemon)->mux){+.+...}, at: [<ffffffffa029c2ec>] ecryptfs_miscdev_read+0x21c/0x470 [ecryptfs]
    
     which lock already depends on the new lock.
    
     the existing dependency chain (in reverse order) is:
    
     -> #1 (&(*daemon)->mux){+.+...}:
            [<ffffffff810a3b8d>] lock_acquire+0x9d/0x220
            [<ffffffff8151c6da>] __mutex_lock_common+0x5a/0x4b0
            [<ffffffff8151cc64>] mutex_lock_nested+0x44/0x50
            [<ffffffffa029c5d7>] ecryptfs_send_miscdev+0x97/0x120 [ecryptfs]
            [<ffffffffa029b744>] ecryptfs_send_message+0x134/0x1e0 [ecryptfs]
            [<ffffffffa029a24e>] ecryptfs_generate_key_packet_set+0x2fe/0xa80 [ecryptfs]
            [<ffffffffa02960f8>] ecryptfs_write_metadata+0x108/0x250 [ecryptfs]
            [<ffffffffa0290f80>] ecryptfs_create+0x130/0x250 [ecryptfs]
            [<ffffffff811963a4>] vfs_create+0xb4/0x120
            [<ffffffff81197865>] do_last+0x8c5/0xa10
            [<ffffffff811998f9>] path_openat+0xd9/0x460
            [<ffffffff81199da2>] do_filp_open+0x42/0xa0
            [<ffffffff81187998>] do_sys_open+0xf8/0x1d0
            [<ffffffff81187a91>] sys_open+0x21/0x30
            [<ffffffff81527d69>] system_call_fastpath+0x16/0x1b
    
     -> #0 (&ecryptfs_msg_ctx_arr[i].mux){+.+.+.}:
            [<ffffffff810a3418>] __lock_acquire+0x1bf8/0x1c50
            [<ffffffff810a3b8d>] lock_acquire+0x9d/0x220
            [<ffffffff8151c6da>] __mutex_lock_common+0x5a/0x4b0
            [<ffffffff8151cc64>] mutex_lock_nested+0x44/0x50
            [<ffffffffa029c213>] ecryptfs_miscdev_read+0x143/0x470 [ecryptfs]
            [<ffffffff811887d3>] vfs_read+0xb3/0x180
            [<ffffffff811888ed>] sys_read+0x4d/0x90
            [<ffffffff81527d69>] system_call_fastpath+0x16/0x1b
    
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 542b7a372e617cf3db2f659378e1ed3342fdc31b
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Mon Jun 11 09:24:11 2012 -0700

    eCryptfs: Gracefully refuse miscdev file ops on inherited/passed files
    
    commit 8dc6780587c99286c0d3de747a2946a76989414a upstream.
    
    File operations on /dev/ecryptfs would BUG() when the operations were
    performed by processes other than the process that originally opened the
    file. This could happen with open files inherited after fork() or file
    descriptors passed through IPC mechanisms. Rather than calling BUG(), an
    error code can be safely returned in most situations.
    
    In ecryptfs_miscdev_release(), eCryptfs still needs to handle the
    release even if the last file reference is being held by a process that
    didn't originally open the file. ecryptfs_find_daemon_by_euid() will not
    be successful, so a pointer to the daemon is stored in the file's
    private_data. The private_data pointer is initialized when the miscdev
    file is opened and only used when the file is released.
    
    https://launchpad.net/bugs/994247
    
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Reported-by: Sasha Levin <levinsasha928@gmail.com>
    Tested-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e69325eb5e413816e25d3b8599f67644f4f49698
Author: Mark Rustad <mark.d.rustad@intel.com>
Date:   Tue Jun 26 15:57:30 2012 -0700

    tcm_fc: Resolve suspicious RCU usage warnings
    
    commit 863555be0c81558b1af277addcf68acb8f778860 upstream.
    
    Use rcu_dereference_protected to tell rcu that the ft_lport_lock
    is held during ft_lport_create. This resolved "suspicious RCU usage"
    warnings when debugging options are turned on.
    
    Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
    Tested-by: Ross Brattain <ross.b.brattain@intel.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41318b9db0e59e0ffc6e627251c8640d3307fc0f
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sat Jun 9 19:08:25 2012 +0300

    mtd: cafe_nand: fix an & vs | mistake
    
    commit 48f8b641297df49021093763a3271119a84990a2 upstream.
    
    The intent here was clearly to set result to true if the 0x40000000 flag
    was set.  But instead there was a | vs & typo and we always set result
    to true.
    
    Artem: check the spec at
    wiki.laptop.org/images/5/5c/88ALP01_Datasheet_July_2007.pdf
    and this fix looks correct.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2f2aa2f0c648d1dc22cf9ef4990cfc0b721add8
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Jul 7 10:17:00 2012 -0700

    vfs: make O_PATH file descriptors usable for 'fchdir()'
    
    commit 332a2e1244bd08b9e3ecd378028513396a004a24 upstream.
    
    We already use them for openat() and friends, but fchdir() also wants to
    be able to use O_PATH file descriptors.  This should make it comparable
    to the O_SEARCH of Solaris.  In particular, O_PATH allows you to access
    (not-quite-open) a directory you don't have read persmission to, only
    execute permission.
    
    Noticed during development of multithread support for ksh93.
    
    Reported-by: ольга крыжановская <olga.kryzhanovska@gmail.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c148a3eb63d97d2956a906ebed2def889d07eb21
Author: Stone Piao <piaoyun@marvell.com>
Date:   Wed Jun 20 20:21:10 2012 -0700

    mwifiex: fix 11n rx packet drop issue
    
    commit 925839243dc9aa4ef25305f5afd10ed18258a4ac upstream.
    
    Currently we check the sequence number of last packet received
    against start_win. If a sequence hole is detected, start_win is
    updated to next sequence number.
    
    Since the rx sequence number is initialized to 0, a corner case
    exists when BA setup happens immediately after association. As
    0 is a valid sequence number, start_win gets increased to 1
    incorrectly. This causes the first packet with sequence number 0
    being dropped.
    
    Initialize rx sequence number as 0xffff and skip adjusting
    start_win if the sequence number remains 0xffff. The sequence
    number will be updated once the first packet is received.
    
    Signed-off-by: Stone Piao <piaoyun@marvell.com>
    Signed-off-by: Avinash Patil <patila@marvell.com>
    Signed-off-by: Kiran Divekar <dkiran@marvell.com>
    Signed-off-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1dc1e5ad5a05da69c51446f9c8a2c097884fece7
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Jun 27 15:38:56 2012 +0200

    mac80211: correct behaviour on unrecognised action frames
    
    commit 4b5ebccc40843104d980f0714bc86bfcd5568941 upstream.
    
    When receiving an "individually addressed" action frame, the
    receiver is required to return it to the sender. mac80211
    gets this wrong as it also returns group addressed (mcast)
    frames to the sender. Fix this and update the reference to
    the new 802.11 standards version since things were shuffled
    around significantly.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2b32167957d2cb234636bac6dd46056c17bc272
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Jun 8 16:16:04 2012 +0100

    oprofile: perf: use NR_CPUS instead or nr_cpumask_bits for static array
    
    commit e734568b675c985db2026848fefaac01c22977a5 upstream.
    
    The OProfile perf backend uses a static array to keep track of the
    perf events on the system. When compiling with CONFIG_CPUMASK_OFFSTACK=y
    && SMP, nr_cpumask_bits is not a compile-time constant and the build
    will fail with:
    
    oprofile_perf.c:28: error: variably modified 'perf_events' at file scope
    
    This patch uses NR_CPUs instead of nr_cpumask_bits for the array
    initialisation. If this causes space problems in the future, we can
    always move to dynamic allocation for the events array.
    
    Cc: Matt Fleming <matt@console-pimps.org>
    Reported-by: Russell King - ARM Linux <linux@arm.linux.org.uk>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Robert Richter <robert.richter@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4575efeebc7c614b981f7a399b2ba614fad39689
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Jun 15 00:20:44 2012 +0000

    can: c_can: precedence error in c_can_chip_config()
    
    commit d9cb9bd63eb27ac19f26a8547128c053f43a5da8 upstream.
    
    (CAN_CTRLMODE_LISTENONLY & CAN_CTRLMODE_LOOPBACK) is (0x02 & 0x01) which
    is zero so the condition is never true.  The intent here was to test
    that both flags were set.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
    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 c229e2f6bab8ed64bf44110831d36221c648e1bf
Author: Eliad Peller <eliad@wizery.com>
Date:   Tue Jun 12 12:53:13 2012 +0300

    cfg80211: fix potential deadlock in regulatory
    
    commit fe20b39ec32e975f1054c0b7866c873a954adf05 upstream.
    
    reg_timeout_work() calls restore_regulatory_settings() which
    takes cfg80211_mutex.
    
    reg_set_request_processed() already holds cfg80211_mutex
    before calling cancel_delayed_work_sync(reg_timeout),
    so it might deadlock.
    
    Call the async cancel_delayed_work instead, in order
    to avoid the potential deadlock.
    
    This is the relevant lockdep warning:
    
    cfg80211: Calling CRDA for country: XX
    
    ======================================================
    [ INFO: possible circular locking dependency detected ]
    3.4.0-rc5-wl+ #26 Not tainted
    -------------------------------------------------------
    kworker/0:2/1391 is trying to acquire lock:
     (cfg80211_mutex){+.+.+.}, at: [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]
    
    but task is already holding lock:
     ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #2 ((reg_timeout).work){+.+...}:
           [<c008fd44>] validate_chain+0xb94/0x10f0
           [<c0090b68>] __lock_acquire+0x8c8/0x9b0
           [<c0090d40>] lock_acquire+0xf0/0x114
           [<c005b600>] wait_on_work+0x4c/0x154
           [<c005c000>] __cancel_work_timer+0xd4/0x11c
           [<c005c064>] cancel_delayed_work_sync+0x1c/0x20
           [<bf28b274>] reg_set_request_processed+0x50/0x78 [cfg80211]
           [<bf28bd84>] set_regdom+0x550/0x600 [cfg80211]
           [<bf294cd8>] nl80211_set_reg+0x218/0x258 [cfg80211]
           [<c03c7738>] genl_rcv_msg+0x1a8/0x1e8
           [<c03c6a00>] netlink_rcv_skb+0x5c/0xc0
           [<c03c7584>] genl_rcv+0x28/0x34
           [<c03c6720>] netlink_unicast+0x15c/0x228
           [<c03c6c7c>] netlink_sendmsg+0x218/0x298
           [<c03933c8>] sock_sendmsg+0xa4/0xc0
           [<c039406c>] __sys_sendmsg+0x1e4/0x268
           [<c0394228>] sys_sendmsg+0x4c/0x70
           [<c0013840>] ret_fast_syscall+0x0/0x3c
    
    -> #1 (reg_mutex){+.+.+.}:
           [<c008fd44>] validate_chain+0xb94/0x10f0
           [<c0090b68>] __lock_acquire+0x8c8/0x9b0
           [<c0090d40>] lock_acquire+0xf0/0x114
           [<c04734dc>] mutex_lock_nested+0x48/0x320
           [<bf28b2cc>] reg_todo+0x30/0x538 [cfg80211]
           [<c0059f44>] process_one_work+0x2a0/0x480
           [<c005a4b4>] worker_thread+0x1bc/0x2bc
           [<c0061148>] kthread+0x98/0xa4
           [<c0014af4>] kernel_thread_exit+0x0/0x8
    
    -> #0 (cfg80211_mutex){+.+.+.}:
           [<c008ed58>] print_circular_bug+0x68/0x2cc
           [<c008fb28>] validate_chain+0x978/0x10f0
           [<c0090b68>] __lock_acquire+0x8c8/0x9b0
           [<c0090d40>] lock_acquire+0xf0/0x114
           [<c04734dc>] mutex_lock_nested+0x48/0x320
           [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]
           [<bf28b200>] reg_timeout_work+0x1c/0x20 [cfg80211]
           [<c0059f44>] process_one_work+0x2a0/0x480
           [<c005a4b4>] worker_thread+0x1bc/0x2bc
           [<c0061148>] kthread+0x98/0xa4
           [<c0014af4>] kernel_thread_exit+0x0/0x8
    
    other info that might help us debug this:
    
    Chain exists of:
      cfg80211_mutex --> reg_mutex --> (reg_timeout).work
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock((reg_timeout).work);
                                   lock(reg_mutex);
                                   lock((reg_timeout).work);
      lock(cfg80211_mutex);
    
     *** DEADLOCK ***
    
    2 locks held by kworker/0:2/1391:
     #0:  (events){.+.+.+}, at: [<c0059e94>] process_one_work+0x1f0/0x480
     #1:  ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480
    
    stack backtrace:
    [<c001b928>] (unwind_backtrace+0x0/0x12c) from [<c0471d3c>] (dump_stack+0x20/0x24)
    [<c0471d3c>] (dump_stack+0x20/0x24) from [<c008ef70>] (print_circular_bug+0x280/0x2cc)
    [<c008ef70>] (print_circular_bug+0x280/0x2cc) from [<c008fb28>] (validate_chain+0x978/0x10f0)
    [<c008fb28>] (validate_chain+0x978/0x10f0) from [<c0090b68>] (__lock_acquire+0x8c8/0x9b0)
    [<c0090b68>] (__lock_acquire+0x8c8/0x9b0) from [<c0090d40>] (lock_acquire+0xf0/0x114)
    [<c0090d40>] (lock_acquire+0xf0/0x114) from [<c04734dc>] (mutex_lock_nested+0x48/0x320)
    [<c04734dc>] (mutex_lock_nested+0x48/0x320) from [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211])
    [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211]) from [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211])
    [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211]) from [<c0059f44>] (process_one_work+0x2a0/0x480)
    [<c0059f44>] (process_one_work+0x2a0/0x480) from [<c005a4b4>] (worker_thread+0x1bc/0x2bc)
    [<c005a4b4>] (worker_thread+0x1bc/0x2bc) from [<c0061148>] (kthread+0x98/0xa4)
    [<c0061148>] (kthread+0x98/0xa4) from [<c0014af4>] (kernel_thread_exit+0x0/0x8)
    cfg80211: Calling CRDA to update world regulatory domain
    cfg80211: World regulatory domain updated:
    cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
    cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
    cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
    cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    
    Signed-off-by: Eliad Peller <eliad@wizery.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45412136e830b9f5f80785a3e7d616d1b96fef52
Author: Craig Shelley <craig@microtron.org.uk>
Date:   Tue Jun 26 23:20:04 2012 +0100

    USB: CP210x Add 10 Device IDs
    
    commit 3fcc8f96829776cf181918461923d1e3bbb831a2 upstream.
    
    This patch adds 10 device IDs for CP210x based devices from the following manufacturers:
    Timewave
    Clipsal
    Festo
    Link Instruments
    
    Signed-off-by: Craig Shelley <craig@microtron.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 148e2ad046117ab77ce07b014e3e12fd065c567f
Author: Forest Bond <forest.bond@rapidrollout.com>
Date:   Fri Jun 22 10:30:38 2012 -0400

    USB: option: Add USB ID for Novatel Ovation MC551
    
    commit 065b07e7a14676f4138ce4619d229c0be5a74230 upstream.
    
    This device is also known as the Verizon USB551L.
    
    Signed-off-by: Forest Bond <forest.bond@rapidrollout.com>
    Acked-by: Dan Williams <dcbw@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e12eaef351797bb7fe1e65d94393db4134dd49c
Author: Dmitry Shmygov <shmygov@rambler.ru>
Date:   Wed Jun 20 15:51:40 2012 +0400

    USB: option: add id for Cellient MEN-200
    
    commit 1e2c4e59d2b8797973471b4a287a43eac12a0f40 upstream.
    
    Add vendor and product ID to option.c driver
    for Cellient MEN-200 EVDO Rev.B 450MHz data module.
    http://cellient.com
    
    Signed-off-by: Dmitry Shmygov <shmygov@rambler.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 821d1ea17c0cf16e680e6d5ce4a9d7522769b4b1
Author: Mel Gorman <mgorman@suse.de>
Date:   Thu Jun 21 11:36:50 2012 +0100

    stable: Allow merging of backports for serious user-visible performance issues
    
    commit eb3979f64d25120d60b9e761a4c58f70b1a02f86 upstream.
    
    Distribution kernel maintainers routinely backport fixes for users that
    were deemed important but not "something critical" as defined by the
    rules. To users of these kernels they are very serious and failing to fix
    them reduces the value of -stable.
    
    The problem is that the patches fixing these issues are often subtle and
    prone to regressions in other ways and need greater care and attention.
    To combat this, these "serious" backports should have a higher barrier
    to entry.
    
    This patch relaxes the rules to allow a distribution maintainer to merge
    to -stable a backported patch or small series that fixes a "serious"
    user-visible performance issue. They should include additional information on
    the user-visible bug affected and a link to the bugzilla entry if available.
    The same rules about the patch being already in mainline still apply.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c62f01893379dc5f831f2694553934f41c25bf32
Author: Pavel Vasilyev <pavel@pavlinux.ru>
Date:   Tue Jun 5 00:02:05 2012 -0400

    ACPI sysfs.c strlen fix
    
    commit 9f132652d94c96476b0b0a8caf0c10e96ab10fa8 upstream.
    
    Current code is ignoring the last character of "enable" and "disable"
    in comparisons.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=33732
    
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41d3df3aec2364bcd3197f5bcdc3102e708643ee
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Mon Feb 20 14:20:06 2012 +0800

    ACPI, x86: fix Dell M6600 ACPI reboot regression via DMI
    
    commit 76eb9a30db4bc8fd172f9155247264b5f2686d7b upstream.
    
    Dell Precision M6600 is known to require PCI reboot, so add it to
    the reboot blacklist in pci_reboot_dmi_table[].
    
    https://bugzilla.kernel.org/show_bug.cgi?id=42749
    
    cc: x86@kernel.org
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 13c3a2a53f2b78e57d595c46de9aa1aea2f9af19
Author: Feng Tang <feng.tang@intel.com>
Date:   Mon Jun 4 15:00:06 2012 +0800

    ACPI: Add a quirk for "AMILO PRO V2030" to ignore the timer overriding
    
    commit f6b54f083cc66cf9b11d2120d8df3c2ad4e0836d upstream.
    
    This is the 2nd part of fix for kernel bugzilla 40002:
        "IRQ 0 assigned to VGA"
    https://bugzilla.kernel.org/show_bug.cgi?id=40002
    
    The root cause is the buggy FW, whose ACPI tables assign the GSI 16
    to 2 irqs 0 and 16(VGA), and the VGA is the right owner of GSI 16.
    So add a quirk to ignore the irq0 overriding GSI 16 for the
    FUJITSU SIEMENS AMILO PRO V2030 platform will solve this issue.
    
    Reported-and-tested-by: Szymon Kowalczyk <fazerxlo@o2.pl>
    Signed-off-by: Feng Tang <feng.tang@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c69499a1c8b4925248598f6eebf524968f92414f
Author: Stuart Hayes <Stuart_Hayes@Dell.com>
Date:   Wed Jun 13 16:10:45 2012 -0500

    acpi_pad: fix power_saving thread deadlock
    
    commit 5f1601261050251a5ca293378b492a69d590dacb upstream.
    
    The acpi_pad driver can get stuck in destroy_power_saving_task()
    waiting for kthread_stop() to stop a power_saving thread.  The problem
    is that the isolated_cpus_lock mutex is owned when
    destroy_power_saving_task() calls kthread_stop(), which waits for a
    power_saving thread to end, and the power_saving thread tries to
    acquire the isolated_cpus_lock when it calls round_robin_cpu().  This
    patch fixes the issue by making round_robin_cpu() use its own mutex.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=42981
    
    Signed-off-by: Stuart Hayes <Stuart_Hayes@Dell.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9370dd38fdf9c18618efa68cb09daa5bab9885bb
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jun 21 15:30:41 2012 +0200

    drm/i915: Fix eDP blank screen after S3 resume on HP desktops
    
    commit 6db65cbb941f9d433659bdad02b307f6d94465df upstream.
    
    This patch fixes the problem on some HP desktop machines with eDP
    which give blank screens after S3 resume.
    
    It turned out that BLC_PWM_CPU_CTL must be written after
    BLC_PWM_CPU_CTL2.  Otherwise it doesn't take effect on these
    SNB machines.
    
    Tested with 3.5-rc3 kernel.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49233
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46f82ddcd34cba5230ddbd914f8e18898ab55355
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Tue Jun 26 12:12:30 2012 +1000

    drm/nouveau/fbcon: using nv_two_heads is not a good idea
    
    commit 9bd0c15fcfb42f6245447c53347d65ad9e72080b upstream.
    
    nv_two_heads() was never meant to be used outside of pre-nv50 code.  The
    code checks for >= NV_10 for 2 CRTCs, then downgrades a few specific
    chipsets to 1 CRTC based on (pci_device & 0x0ff0).
    
    The breakage example seen is on GTX 560Ti, with a pciid of 0x1200, which
    gets detected as an NV20 (0x020x) with 1 CRTC by nv_two_heads(), causing
    memory corruption because there's actually 2 CRTCs..
    
    This switches fbcon to use the CRTC count directly from the mode_config
    structure, which will also fix the same issue on Kepler boards which have
    4 CRTCs.
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d25d7c8f997b7de5f7c0d421ea66c78a42daebda
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Jun 19 11:33:06 2012 +0200

    drm/edid: don't return stack garbage from supports_rb
    
    commit b196a4980ff7bb54db478e2a408dc8b12be15304 upstream.
    
    We need to initialize this to false, because the is_rb callback only
    ever sets it to true.
    
    Noticed while reading through the code.
    
    Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Reviewed-by: Adam Jackson <ajax@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0f7cf8a1ab0479ecc37989bd332c28d5ff04f89
Author: Chris Mason <chris.mason@fusionio.com>
Date:   Mon Jul 2 15:29:53 2012 -0400

    Btrfs: run delayed directory updates during log replay
    
    commit b6305567e7d31b0bec1b8cb9ec0cadd7f7086f5f upstream.
    
    While we are resolving directory modifications in the
    tree log, we are triggering delayed metadata updates to
    the filesystem btrees.
    
    This commit forces the delayed updates to run so the
    replay code can find any modifications done.  It stops
    us from crashing because the directory deleltion replay
    expects items to be removed immediately from the tree.
    
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c45f606a03193a95a55ef1802646e5a67fff642b
Author: Hebbar, Gururaja <gururaja.hebbar@ti.com>
Date:   Tue Jun 26 19:25:11 2012 +0530

    ASoC: tlv320aic3x: Fix codec pll configure bug
    
    commit c9fe573a6584034670c1a55ee8162d623519cbbf upstream.
    
    In sound/soc/codecs/tlv320aic3x.c
    
            data = snd_soc_read(codec, AIC3X_PLL_PROGA_REG);
            snd_soc_write(codec, AIC3X_PLL_PROGA_REG,
                          data | (pll_p << PLLP_SHIFT));
    
    In the above code, pll-p value is OR'ed with previous value without
    clearing it. Bug is not seen if pll-p value doesn't change across
    Sampling frequency.
    
    However on some platforms (like AM335x EVM-SK), pll-p may have different
    values across different sampling frequencies. In such case, above code
    configures the pll with a wrong value.
    Because of this bug, when a audio stream is played with pll value
    different from previous stream, audio is heard as differently(like its
    stretched).
    
    Signed-off-by: Hebbar, Gururaja <gururaja.hebbar@ti.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5fe4d12cfbf9ca994640a487439a2ef2f633336c
Author: Panayiotis Karabassis <panayk@gmail.com>
Date:   Tue Jun 26 23:37:17 2012 +0300

    ath9k: enable serialize_regmode for non-PCIE AR9287
    
    commit 7508b657967cf664b5aa0f6367d05016e7e3bc2a upstream.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=42903
    
    Based on the work of <fynivx@gmail.com>
    
    Signed-off-by: Panayiotis Karabassis <panayk@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a3ca923be330c3a8b0f391d8e92040f4987eb21
Author: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Date:   Mon Jun 18 13:13:30 2012 +0530

    ath9k_hw: avoid possible infinite loop in ar9003_get_pll_sqsum_dvc
    
    commit f18e3c6b67f448ec47b3a5b242789bd3d5644879 upstream.
    
    "ath9k: Fix softlockup in AR9485" with commit id
    64bc1239c790e051ff677e023435d770d2ffa174 fixed the reported
    issue, yet its better to avoid the possible infinite loop
    in ar9003_get_pll_sqsum_dvc by having a timeout as suggested
    by ath9k maintainers.
    http://www.spinics.net/lists/linux-wireless/msg92126.html.
    Based on my testing PLL's locking measurement is done in
    ~200us (2 iterations).
    
    Cc: Rolf Offermanns <rolf.offermanns@gmx.net>
    Cc: Sujith Manoharan <c_manoha@qca.qualcomm.com>
    Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
    Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de39eed0da6d7afcf2d758dc0e99811988a3bd06
Author: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Date:   Wed Jun 13 21:28:09 2012 +0530

    ath9k: Fix softlockup in AR9485
    
    commit bcb7ad7bcbef030e6ba71ede1f9866368aca7c99 upstream.
    
    steps to recreate:
    load latest ath9k driver with AR9485
    stop the network-manager and wpa_supplicant
    bring the interface up
    
    	Call Trace:
    	[<ffffffffa0517490>] ? ath_hw_check+0xe0/0xe0 [ath9k]
    	[<ffffffff812cd1e8>] __const_udelay+0x28/0x30
    	[<ffffffffa03bae7a>] ar9003_get_pll_sqsum_dvc+0x4a/0x80 [ath9k_hw]
    	[<ffffffffa05174eb>] ath_hw_pll_work+0x5b/0xe0 [ath9k]
    	[<ffffffff810744fe>] process_one_work+0x11e/0x470
    	[<ffffffff8107530f>] worker_thread+0x15f/0x360
    	[<ffffffff810751b0>] ? manage_workers+0x230/0x230
    	[<ffffffff81079af3>] kthread+0x93/0xa0
    	[<ffffffff815fd3a4>] kernel_thread_helper+0x4/0x10
    	[<ffffffff81079a60>] ? kthread_freezable_should_stop+0x70/0x70
    	[<ffffffff815fd3a0>] ? gs_change+0x13/0x13
    
    ensure that the PLL-WAR for AR9485/AR9340 is executed only if the STA is
    associated (or) IBSS/AP mode had started beaconing. Ideally this WAR
    is needed to recover from some rare beacon stuck during stress testing.
    Before the STA is associated/IBSS had started beaconing, PLL4(0x1618c)
    always seem to have zero even though we had configured PLL3(0x16188) to
    query about PLL's locking status. When we keep on polling infinitely PLL4's
    8th bit(ie check for PLL locking measurements is done), machine hangs
    due to softlockup.
    
    fixes https://bugzilla.redhat.com/show_bug.cgi?id=811142
    
    Reported-by: Rolf Offermanns <rolf.offermanns@gmx.net>
    Tested-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
    Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b1c5701ad6b3e5d21d16f65475651cfaaa41e7aa
Author: Jan Kara <jack@suse.cz>
Date:   Wed Jun 27 21:23:07 2012 +0200

    udf: Fortify loading of sparing table
    
    commit 1df2ae31c724e57be9d7ac00d78db8a5dabdd050 upstream.
    
    Add sanity checks when loading sparing table from disk to avoid accessing
    unallocated memory or writing to it.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8411aa07c7aa22ef3fe269a05e45e672590e4f7f
Author: Jan Kara <jack@suse.cz>
Date:   Wed Jun 27 20:20:22 2012 +0200

    udf: Avoid run away loop when partition table length is corrupted
    
    commit adee11b2085bee90bd8f4f52123ffb07882d6256 upstream.
    
    Check provided length of partition table so that (possibly maliciously)
    corrupted partition table cannot cause accessing data beyond current buffer.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8db7530c08115356964240e4f9cc90fd112d251
Author: Jan Kara <jack@suse.cz>
Date:   Wed Jun 27 20:08:44 2012 +0200

    udf: Use 'ret' instead of abusing 'i' in udf_load_logicalvol()
    
    commit cb14d340ef1737c24125dd663eff77734a482d47 upstream.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f66c6795bdc2dd43b749e90a07c3e1f12caafede
Author: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Date:   Wed Jun 20 12:52:57 2012 -0700

    nilfs2: ensure proper cache clearing for gc-inodes
    
    commit fbb24a3a915f105016f1c828476be11aceac8504 upstream.
    
    A gc-inode is a pseudo inode used to buffer the blocks to be moved by
    garbage collection.
    
    Block caches of gc-inodes must be cleared every time a garbage collection
    function (nilfs_clean_segments) completes.  Otherwise, stale blocks
    buffered in the caches may be wrongly reused in successive calls of the GC
    function.
    
    For user files, this is not a problem because their gc-inodes are
    distinguished by a checkpoint number as well as an inode number.  They
    never buffer different blocks if either an inode number, a checkpoint
    number, or a block offset differs.
    
    However, gc-inodes of sufile, cpfile and DAT file can store different data
    for the same block offset.  Thus, the nilfs_clean_segments function can
    move incorrect block for these meta-data files if an old block is cached.
    I found this is really causing meta-data corruption in nilfs.
    
    This fixes the issue by ensuring cache clear of gc-inodes and resolves
    reported GC problems including checkpoint file corruption, b-tree
    corruption, and the following warning during GC.
    
      nilfs_palloc_freev: entry number 307234 already freed.
      ...
    
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    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 cd2ae436c3ef59659ba10754213c8614d256dc86
Author: Henrik Rydberg <rydberg@euromail.se>
Date:   Thu Jun 7 04:54:29 2012 -0400

    hwmon: (applesmc) Limit key length in warning messages
    
    commit ac852edb47b15900886ba2564eeeb13b3b526e3e upstream.
    
    Key lookups may call read_smc() with a fixed-length key string,
    and if the lookup fails, trailing stack content may appear in the
    kernel log. Fixed with this patch.
    
    Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5a07578befc10cde568f54a2103ad4273ef98c1
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jun 12 19:30:21 2012 +0000

    netpoll: fix netpoll_send_udp() bugs
    
    [ Upstream commit 954fba0274058d27c7c07b5ea07c41b3b7477894 ]
    
    Bogdan Hamciuc diagnosed and fixed following bug in netpoll_send_udp() :
    
    "skb->len += len;" instead of "skb_put(skb, len);"
    
    Meaning that _if_ a network driver needs to call skb_realloc_headroom(),
    only packet headers would be copied, leaving garbage in the payload.
    
    However the skb_realloc_headroom() must be avoided as much as possible
    since it requires memory and netpoll tries hard to work even if memory
    is exhausted (using a pool of preallocated skbs)
    
    It appears netpoll_send_udp() reserved 16 bytes for the ethernet header,
    which happens to work for typicall drivers but not all.
    
    Right thing is to use LL_RESERVED_SPACE(dev)
    (And also add dev->needed_tailroom of tailroom)
    
    This patch combines both fixes.
    
    Many thanks to Bogdan for raising this issue.
    
    Reported-by: Bogdan Hamciuc <bogdan.hamciuc@freescale.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Tested-by: Bogdan Hamciuc <bogdan.hamciuc@freescale.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: Neil Horman <nhorman@tuxdriver.com>
    Reviewed-by: Neil Horman <nhorman@tuxdriver.com>
    Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e7d7c544c8a3ec827f72d9af9c2c3efa45e5325
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Jun 7 22:59:59 2012 +0000

    be2net: fix a race in be_xmit()
    
    [ Upstream commit cd8f76c0a0c6fce0b2cf23c9bd0123f91453f46d ]
    
    As soon as hardware is notified of a transmit, we no longer can assume
    skb can be dereferenced, as TX completion might have freed the packet.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Sathya Perla <sathya.perla@emulex.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 527a2a53232256fbaab9e72637839381eb6f42b1
Author: stephen hemminger <shemminger@vyatta.com>
Date:   Wed Jun 6 10:01:30 2012 +0000

    sky2: fix checksum bit management on some chips
    
    [ Upstream commit 5ff0feac88ced864f44adb145142269196fa79d9 ]
    
    The newer flavors of Yukon II use a different method for receive
    checksum offload. This is indicated in the driver by the SKY2_HW_NEW_LE
    flag. On these newer chips, the BMU_ENA_RX_CHKSUM should not be set.
    
    The driver would get incorrectly toggle the bit, enabling the old
    checksum logic on these chips and cause a BUG_ON() assertion. If
    receive checksum was toggled via ethtool.
    
    Reported-by: Kirill Smelkov <kirr@mns.spb.ru>
    Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5eceb057268c275e8193a03ed159bf540038feac
Author: Thomas Graf <tgraf@suug.ch>
Date:   Mon Jun 18 12:08:33 2012 +0000

    ipv6: Move ipv6 proc file registration to end of init order
    
    [ Upstream commit d189634ecab947c10f6f832258b103d0bbfe73cc ]
    
    /proc/net/ipv6_route reflects the contents of fib_table_hash. The proc
    handler is installed in ip6_route_net_init() whereas fib_table_hash is
    allocated in fib6_net_init() _after_ the proc handler has been installed.
    
    This opens up a short time frame to access fib_table_hash with its pants
    down.
    
    Move the registration of the proc files to a later point in the init
    order to avoid the race.
    
    Tested :-)
    
    Signed-off-by: Thomas Graf <tgraf@suug.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76886430203577bfa3b437630058aa0346cb3168
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jun 12 06:03:51 2012 +0000

    bonding: Fix corrupted queue_mapping
    
    [ Upstream commit 5ee31c6898ea5537fcea160999d60dc63bc0c305 ]
    
    In the transmit path of the bonding driver, skb->cb is used to
    stash the skb->queue_mapping so that the bonding device can set its
    own queue mapping.  This value becomes corrupted since the skb->cb is
    also used in __dev_xmit_skb.
    
    When transmitting through bonding driver, bond_select_queue is
    called from dev_queue_xmit.  In bond_select_queue the original
    skb->queue_mapping is copied into skb->cb (via bond_queue_mapping)
    and skb->queue_mapping is overwritten with the bond driver queue.
    
    Subsequently in dev_queue_xmit, __dev_xmit_skb is called which writes
    the packet length into skb->cb, thereby overwriting the stashed
    queue mappping.  In bond_dev_queue_xmit (called from hard_start_xmit),
    the queue mapping for the skb is set to the stashed value which is now
    the skb length and hence is an invalid queue for the slave device.
    
    If we want to save skb->queue_mapping into skb->cb[], best place is to
    add a field in struct qdisc_skb_cb, to make sure it wont conflict with
    other layers (eg : Qdiscc, Infiniband...)
    
    This patchs also makes sure (struct qdisc_skb_cb)->data is aligned on 8
    bytes :
    
    netem qdisc for example assumes it can store an u64 in it, without
    misalignment penalty.
    
    Note : we only have 20 bytes left in (struct qdisc_skb_cb)->data[].
    The largest user is CHOKe and it fills it.
    
    Based on a previous patch from Tom Herbert.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Tom Herbert <therbert@google.com>
    Cc: John Fastabend <john.r.fastabend@intel.com>
    Cc: Roland Dreier <roland@kernel.org>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4acd9a65e16de99c4afe89e4ac8a16b501c92450
Author: stephen hemminger <shemminger@vyatta.com>
Date:   Tue Jun 26 05:48:45 2012 +0000

    bridge: Assign rtnl_link_ops to bridge devices created via ioctl (v2)
    
    [ Upstream commit 149ddd83a92b02c658d6c61f3276eb6500d585e8 ]
    
    This ensures that bridges created with brctl(8) or ioctl(2) directly
    also carry IFLA_LINKINFO when dumped over netlink. This also allows
    to create a bridge with ioctl(2) and delete it with RTM_DELLINK.
    
    Signed-off-by: Thomas Graf <tgraf@suug.ch>
    Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3a673fb54a4d7f6d8cb4f7e72dac5f91583e6f1
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date:   Sun Jan 22 00:20:40 2012 +0000

    ethtool: allow ETHTOOL_GSSET_INFO for users
    
    [ Upstream commit f80400a26a2e8bff541de12834a1134358bb6642 ]
    
    Allow ETHTOOL_GSSET_INFO ethtool ioctl() for unprivileged users.
    ETHTOOL_GSTRINGS is already allowed, but is unusable without this one.
    
    Signed-off-by: Micha©© Miros©©aw <mirq-linux@rere.qmqm.pl>
    Acked-by: Ben Hutchings <bhutchings@solarflare.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7dd0931198ce3e25901ffb56036bb070efe9f987
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Jun 10 21:11:57 2012 +0000

    dummy: fix rcu_sched self-detected stalls
    
    [ Upstream commit 16b0dc29c1af9df341428f4c49ada4f626258082 ]
    
    Trying to "modprobe dummy numdummies=30000" triggers :
    
    INFO: rcu_sched self-detected stall on CPU { 8} (t=60000 jiffies)
    
    After this splat, RTNL is locked and reboot is needed.
    
    We must call cond_resched() to avoid this, even holding RTNL.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e99e096f4b388824e49ce5c6568eacf46c94438f
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Jun 7 00:07:20 2012 +0000

    net: l2tp_eth: fix kernel panic on rmmod l2tp_eth
    
    [ Upstream commit a06998b88b1651c5f71c0e35f528bf2057188ead ]
    
    We must prevent module unloading if some devices are still attached to
    l2tp_eth driver.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Denys Fedoryshchenko <denys@visp.net.lb>
    Tested-by: Denys Fedoryshchenko <denys@visp.net.lb>
    Cc: James Chapman <jchapman@katalix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49ffa112f667e1739d8c6352d7f902c8afd45dae
Author: Paul Moore <pmoore@redhat.com>
Date:   Fri Jun 1 05:54:56 2012 +0000

    cipso: handle CIPSO options correctly when NetLabel is disabled
    
    [ Upstream commit 20e2a86485967c385d7c7befc1646e4d1d39362e ]
    
    When NetLabel is not enabled, e.g. CONFIG_NETLABEL=n, and the system
    receives a CIPSO tagged packet it is dropped (cipso_v4_validate()
    returns non-zero).  In most cases this is the correct and desired
    behavior, however, in the case where we are simply forwarding the
    traffic, e.g. acting as a network bridge, this becomes a problem.
    
    This patch fixes the forwarding problem by providing the basic CIPSO
    validation code directly in ip_options_compile() without the need for
    the NetLabel or CIPSO code.  The new validation code can not perform
    any of the CIPSO option label/value verification that
    cipso_v4_validate() does, but it can verify the basic CIPSO option
    format.
    
    The behavior when NetLabel is enabled is unchanged.
    
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 325b4161bab9ba01b345c4483bbb0e36cb571943
Author: Jason Wang <jasowang@redhat.com>
Date:   Wed May 30 21:18:10 2012 +0000

    net: sock: validate data_len before allocating skb in sock_alloc_send_pskb()
    
    [ Upstream commit cc9b17ad29ecaa20bfe426a8d4dbfb94b13ff1cc ]
    
    We need to validate the number of pages consumed by data_len, otherwise frags
    array could be overflowed by userspace. So this patch validate data_len and
    return -EMSGSIZE when data_len may occupies more frags than MAX_SKB_FRAGS.
    
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1877392b4dce5d4c74d329777980d2a3ccede99
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Thu Jan 19 15:20:58 2012 +0000

    ARM: fix rcu stalls on SMP platforms
    
    commit 7deabca0acfe02b8e18f59a4c95676012f49a304 upstream.
    
    We can stall RCU processing on SMP platforms if a CPU sits in its idle
    loop for a long time.  This happens because we don't call irq_enter()
    and irq_exit() around generic_smp_call_function_interrupt() and
    friends.  Add the necessary calls, and remove the one from within
    ipi_timer(), so that they're all in a common place.
    
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    [add irq_enter()/irq_exit() in do_local_timer]
    Signed-off-by: UCHINO Satoshi <satoshi.uchino@toshiba.co.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6218ee909f993a8bd5138a5eb1bde620c12a2a9
Author: Michael Krufky <mkrufky@linuxtv.org>
Date:   Fri May 25 09:29:12 2012 -0300

    media: smsusb: add autodetection support for USB ID 2040:f5a0
    
    commit 3e1141e2ce5667301a74ca2ef396d9bd5e995f7f upstream.
    
    Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24ec2125f3c828af6446d8eeee2268a05e78724b
Author: Anton Blanchard <anton@samba.org>
Date:   Thu Jun 28 19:28:57 2012 +0000

    powerpc/xmon: Use cpumask iterator to avoid warning
    
    commit bc1d7702910c7c7e88eb60b58429dbfe293683ce upstream.
    
    We have a bug report where the kernel hits a warning in the cpumask
    code:
    
    WARNING: at include/linux/cpumask.h:107
    
    Which is:
            WARN_ON_ONCE(cpu >= nr_cpumask_bits);
    
    The backtrace is:
            cpu_cmd
            cmds
            xmon_core
            xmon
            die
    
    xmon is iterating through 0 to NR_CPUS. I'm not sure why we are still
    open coding this but iterating above nr_cpu_ids is definitely a bug.
    
    This patch iterates through all possible cpus, in case we issue a
    system reset and CPUs in an offline state call in.
    
    Perhaps the old code was trying to handle CPUs that were in the
    partition but were never started (eg kexec into a kernel with an
    nr_cpus= boot option). They are going to die way before we get into
    xmon since we haven't set any kernel state up for them.
    
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3ea90f6d10bc66b422299934b70e3f9e62fc67e
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Mon Jun 25 19:49:28 2012 +0200

    ALSA: hda - Add Realtek ALC280 codec support
    
    commit befae82e2906cb7155020876a531b0b8c6c8d8c8 upstream.
    
    This chip looks very similar to ALC269 and ALC27* variants. The bug reporter
    has verified that sound was working after this patch had been applied.
    
    BugLink: https://bugs.launchpad.net/bugs/1017017
    Tested-by: Richard Crossley <richardcrossley@o2.co.uk>
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>