commit c2db2e264bce3b5c82b8786ec3080cbe41b7114c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Feb 13 11:17:29 2012 -0800

    Linux 3.2.6

commit 8f44619e1e633884c5f0bfcf6ae05d7b0304cca3
Author: Andreas Herrmann <andreas.herrmann3@amd.com>
Date:   Fri Jan 6 15:57:55 2012 +0100

    powernow-k8: Fix indexing issue
    
    commit a8eb28480e9b637cc78b9aa5e08612ba97e1317a upstream.
    
    The driver uses the pstate number from the status register as index in
    its table of ACPI pstates (powernow_table). This is wrong as this is
    not a 1-to-1 mapping.
    
    For example we can have _PSS information to just utilize Pstate 0 and
    Pstate 4, ie.
    
      powernow-k8: Core Performance Boosting: on.
      powernow-k8:    0 : pstate 0 (2200 MHz)
      powernow-k8:    1 : pstate 4 (1400 MHz)
    
    In this example the driver's powernow_table has just 2 entries. Using
    the pstate number (4) as index into this table is just plain wrong.
    
    Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
    Signed-off-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af2ff521425c83a3043af8a600b62d32443031dd
Author: Andreas Herrmann <andreas.herrmann3@amd.com>
Date:   Fri Jan 6 15:56:31 2012 +0100

    powernow-k8: Avoid Pstate MSR accesses on systems supporting CPB
    
    commit 201bf0f129e1715a33568d1563d9a75b840ab4d3 upstream.
    
    Due to CPB we can't directly map SW Pstates to Pstate MSRs. Get rid of
    the paranoia check. (assuming that the ACPI Pstate information is
    correct.)
    
    Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
    Signed-off-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6bffce08e4d8f5daf00e3d45dad594764c3fc8f0
Author: Axel Lin <axel.lin@gmail.com>
Date:   Wed Feb 1 12:31:47 2012 +0800

    mmc: cb710 core: Add missing spin_lock_init for irq_lock of struct cb710_chip
    
    commit b5266ea675c5a041e2852c7ccec4cf2d4f5e0cf4 upstream.
    
    Signed-off-by: Axel Lin <axel.lin@gmail.com>
    Acked-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c97f5b2d4924961479e862e8fe516ba217551b3
Author: Dan Magenheimer <dan.magenheimer@oracle.com>
Date:   Wed Jan 25 14:32:51 2012 -0800

    zcache: fix deadlock condition
    
    commit 9256a4789be3dae37d00924c03546ba7958ea5a3 upstream.
    
    I discovered this deadlock condition awhile ago working on RAMster
    but it affects zcache as well.  The list spinlock must be
    locked prior to the page spinlock and released after.  As
    a result, the page copy must also be done while the locks are held.
    
    Applies to 3.2.  Konrad, please push (via GregKH?)...
    this is definitely a bug fix so need not be pushed during
    a -rc0 window.
    
    Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1efec8273372700693661f094324081d8f3ad3d
Author: Dan Magenheimer <dan.magenheimer@oracle.com>
Date:   Mon Jan 23 16:52:20 2012 -0500

    zcache: Set SWIZ_BITS to 8 to reduce tmem bucket lock contention.
    
    commit e8b4553457e78bcff90f70a31212a40a8fd4f0db upstream.
    
    SWIZ_BITS > 8 results in a much larger number of "tmem_obj"
    allocations, likely one per page-placed-in-frontswap.  The
    tmem_obj is not huge (roughly 100 bytes), but it is large
    enough to add a not-insignificant memory overhead to zcache.
    
    The SWIZ_BITS=8  will get roughly the same lock contention
    without the space wastage.
    
    The effect of SWIZ_BITS can be thought of as "2^SWIZ_BITS is
    the number of unique oids that be generated" (This concept is
    limited to frontswap's use of tmem).
    
    Acked-by: Seth Jennings <sjenning@linux.vnet.ibm.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 57c313f71800dd93f10f6641650dcb4167fa8739
Author: Rui li <li.rui27@zte.com.cn>
Date:   Tue Jan 31 15:27:33 2012 +0800

    USB: add new zte 3g-dongle's pid to option.c
    
    commit 1608ea5f4b5d6262cd6e808839491cfb2a67405a upstream.
    
    As ZTE have and will use more pid for new products this year,
    so we need to add some new zte 3g-dongle's pid on option.c ,
    and delete one pid 0x0154 because it use for mass-storage port.
    
    Signed-off-by: Rui li <li.rui27@zte.com.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 294913e9df10298b440f3c8ee1df4b2d02c06f49
Author: Milan Kocian <milon@wq.cz>
Date:   Fri Feb 3 14:28:00 2012 +0100

    USB: usbserial: add new PID number (0xa951) to the ftdi driver
    
    commit 90451e6973a5da155c6f315a409ca0a8d3ce6b76 upstream.
    
    Signed-off-by: Milan Kocian <milon@wq.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0bbd5d1b0a768b0b5761643b601422dfe78fd9c5
Author: Jayachandran C <jayachandranc@netlogicmicro.com>
Date:   Fri Jan 27 20:27:32 2012 +0530

    usb: Skip PCI USB quirk handling for Netlogic XLP
    
    commit e4436a7c17ac2b5e138f93f83a541cba9b311685 upstream.
    
    The Netlogic XLP SoC's on-chip USB controller appears as a PCI
    USB device, but does not need the EHCI/OHCI handoff done in
    usb/host/pci-quirks.c.
    
    The pci-quirks.c is enabled for all vendors and devices, and is
    enabled if USB and PCI are configured.
    
    If we do not skip the qurik handling on XLP, the readb() call in
    ehci_bios_handoff() will cause a crash since byte access is not
    supported for EHCI registers in XLP.
    
    Signed-off-by: Jayachandran C <jayachandranc@netlogicmicro.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d99aad98ef32d6615cef9f91aa213b8484cb4083
Author: Timo Juhani Lindfors <timo.lindfors@iki.fi>
Date:   Sun Jan 29 16:12:13 2012 +0200

    usb: gadget: zero: fix bug in loopback autoresume handling
    
    commit 683da59d7b8ae04891636d4b59893cd4e9b0b7e5 upstream.
    
    ab943a2e125b (USB: gadget: gadget zero uses new suspend/resume hooks)
    introduced a copy-paste error where f_loopback.c writes to a variable
    declared in f_sourcesink.c. This prevents one from creating gadgets
    that only have a loopback function.
    
    Signed-off-by: Timo Juhani Lindfors <timo.lindfors@iki.fi>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 915cf0ec84e35d10f00166d3c9b64b12e605c792
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date:   Tue Jan 31 16:43:50 2012 -0800

    usb: ch9.h: usb_endpoint_maxp() uses __le16_to_cpu()
    
    commit 9c0a835a9d9aed41bcf9c287f5069133a6e2a87b upstream.
    
    The usb/ch9.h will be installed to /usr/include/linux,
    and be used from user space.
    But le16_to_cpu() is only defined for kernel code.
    Without this patch, user space compile will be broken.
    Special thanks to Stefan Becker
    
    Reported-by: Stefan Becker <chemobejk@gmail.com>
    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc5d453eab4506cb52397db8830d1070904265a4
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Sun Feb 5 21:12:26 2012 -0600

    staging: r8712u: Use asynchronous firmware loading
    
    commit 8c213fa59199f9673d66970d6940fa093186642f upstream.
    
    In https://bugs.archlinux.org/task/27996, failure of driver r8712u is
    reported, with a timeout during module loading due to synchronous loading
    of the firmware. The code now uses request_firmware_nowait().
    
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1cbce5d4added4defb84dc19acab3efc86b1e979
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Sat Jan 7 10:07:03 2012 -0600

    staging: r8712u: Add new Sitecom UsB ID
    
    commit 1793bf1deddc8ce25dc41925d5dbe64536c841b6 upstream.
    
    Add USB ID for SITECOM WLA-1000 V1 001 WLAN
    
    Reported-and-tested-by: Roland Gruber <post@rolandgruber.de>
    Reported-and-tested-by: Dario Lucia <dario.lucia@gmail.com>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebb468b38e343782b3271343766d92978f8436a7
Author: Pekka Paalanen <pq@iki.fi>
Date:   Sun Jan 22 16:33:47 2012 +0200

    Staging: asus_oled: fix NULL-ptr crash on unloading
    
    commit 3589e74595a4332ebf77b5ed006f3c6686071ecd upstream.
    
    Asus_oled triggers the following bug on module unloading:
    
     usbcore: deregistering interface driver asus-oled
     BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
     IP: [<ffffffff8111292b>] sysfs_delete_link+0x30/0x66
    
     Call Trace:
      [<ffffffff81225373>] device_remove_class_symlinks+0x6b/0x70
      [<ffffffff812256a8>] device_del+0x9f/0x1ab
      [<ffffffff812257c5>] device_unregister+0x11/0x1e
      [<ffffffffa000cb82>] asus_oled_disconnect+0x4f/0x9e [asus_oled]
      [<ffffffff81277430>] usb_unbind_interface+0x54/0x103
      [<ffffffff812276c4>] __device_release_driver+0xa2/0xeb
      [<ffffffff81227794>] driver_detach+0x87/0xad
      [<ffffffff812269e9>] bus_remove_driver+0x91/0xc1
      [<ffffffff81227fb4>] driver_unregister+0x66/0x6e
      [<ffffffff812771ed>] usb_deregister+0xbb/0xc4
      [<ffffffffa000ce87>] asus_oled_exit+0x2f/0x31 [asus_oled]
      [<ffffffff81068365>] sys_delete_module+0x1b8/0x21b
      [<ffffffff810ae3de>] ? do_munmap+0x2ef/0x313
      [<ffffffff813699bb>] system_call_fastpath+0x16/0x1b
    
    This is due to an incorrect destruction sequence in asus_oled_exit().
    
    Fix the order, fixes the bug. Tested on an Asus G50V laptop only.
    
    Cc: Jakub Schmidtke <sjakub@gmail.com>
    Signed-off-by: Pekka Paalanen <pq@iki.fi>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d352f16e64cab162bb25e4f6af298f1a9d1d9e12
Author: Pekka Paalanen <pq@iki.fi>
Date:   Sun Jan 22 16:33:46 2012 +0200

    Staging: asus_oled: fix image processing
    
    commit 635032cb397b396241372fa0ff36ae758e658b23 upstream.
    
    Programming an image was broken, because odev->buf_offs was not advanced
    for val == 0 in append_values(). This regression was introduced in:
    
     commit 1ff12a4aa354bed093a0240d5e6347b1e27601bc
     Author: Kevin A. Granade <kevin.granade@gmail.com>
     Date:   Sat Sep 5 01:03:39 2009 -0500
    
         Staging: asus_oled: Cleaned up checkpatch issues.
    
    Fix the image processing by special-casing val == 0.
    
    I have tested this change on an Asus G50V laptop only.
    
    Cc: Jakub Schmidtke <sjakub@gmail.com>
    Cc: Kevin A. Granade <kevin.granade@gmail.com>
    Signed-off-by: Pekka Paalanen <pq@iki.fi>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95db7f1f8dee58ba87842ecd5b93e7c2884e0637
Author: Roland Dreier <roland@purestorage.com>
Date:   Tue Jan 17 18:00:57 2012 -0800

    target: Fail INQUIRY commands with EVPD==0 but PAGE CODE!=0
    
    commit bf0053550aebe56f3bb5dd793e9de69238b5b945 upstream.
    
    My draft of SPC-4 says:
    
        If the PAGE CODE field is not set to zero when the EVPD bit is set
        to zero, the command shall be terminated with CHECK CONDITION
        status, with the sense key set to ILLEGAL REQUEST, and the
        additional sense code set to INVALID FIELD IN CDB.
    
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e14d6b67d73aba29df97b9619e97e249a882cbe
Author: Roland Dreier <roland@purestorage.com>
Date:   Tue Jan 17 18:00:56 2012 -0800

    target: Return correct ASC for unimplemented VPD pages
    
    commit bb1acb2ee038a6c13ee99e0b9fb44dacb4a9de84 upstream.
    
    My draft of SPC-4 says:
    
        If the device server does not implement the requested vital product
        data page, then the command shall be terminated with CHECK CONDITION
        status, with the sense key set to ILLEGAL REQUEST, and the
        additional sense code set to INVALID FIELD IN CDB.
    
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f467de45d956d46c692fd6a2331f296e9e872aba
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Fri Jan 13 12:01:34 2012 -0800

    target: Add workaround for zero-length control CDB handling
    
    commit 91ec1d3535b2acf12c599045cc19ad9be3c6a47b upstream.
    
    This patch adds a work-around for handling zero allocation length
    control CDBs (type SCF_SCSI_CONTROL_SG_IO_CDB) that was causing an
    OOPs with the following raw calls:
    
       # sg_raw -v /dev/sdd 3 0 0 0 0 0
       # sg_raw -v /dev/sdd 0x1a 0 1 0 0 0
    
    This patch will follow existing zero-length handling for data I/O
    and silently return with GOOD status.  This addresses the zero length
    issue, but the proper long-term resolution for handling arbitary
    allocation lengths will be to refactor out data-phase handling in
    individual CDB emulation logic within target_core_cdb.c
    
    Reported-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4d055fceeb62aca2303fe076d17005a662690a3
Author: Roland Dreier <roland@purestorage.com>
Date:   Mon Jan 9 17:54:00 2012 -0800

    target: Correct sense key for INVALID FIELD IN {PARAMETER LIST,CDB}
    
    commit 9fbc8909876a2160044e71d376848973b9bfdc3f upstream.
    
    According to SPC-4, the sense key for commands that are failed with
    INVALID FIELD IN PARAMETER LIST and INVALID FIELD IN CDB should be
    ILLEGAL REQUEST (5h) rather than ABORTED COMMAND (Bh).  Without this
    patch, a tcm_loop LUN incorrectly gives:
    
        # sg_raw -r 1 -v /dev/sda 3 1 0 0 ff 0
        Sense Information:
         Fixed format, current;  Sense key: Aborted Command
         Additional sense: Invalid field in cdb
         Raw sense data (in hex):
                70 00 0b 00 00 00 00 0a  00 00 00 00 24 00 00 00
                00 00
    
    While a real SCSI disk gives:
    
        Sense Information:
         Fixed format, current;  Sense key: Illegal Request
         Additional sense: Invalid field in cdb
         Raw sense data (in hex):
                70 00 05 00 00 00 00 18  00 00 00 00 24 00 00 00
                00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
    
    with the main point being that the real disk gives a sense key of
    ILLEGAL REQUEST (5h).
    
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1348bc5266eb73206b11e675656051201f28949b
Author: Marco Sanvido <marco@purestorage.com>
Date:   Tue Jan 3 17:12:58 2012 -0800

    target: Allow PERSISTENT RESERVE IN for non-reservation holder
    
    commit 6816966a8418b980481b4dced7eddd1796b145e8 upstream.
    
    Initiators that aren't the active reservation holder should be able to
    do a PERSISTENT RESERVE IN command in all cases, so add it to the list
    of allowed CDBs in core_scsi3_pr_seq_non_holder().
    
    Signed-off-by: Marco Sanvido <marco@purestorage.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c7a78d3cf820992a6a67ea90423713fb429907f
Author: Marco Sanvido <marco@purestorage.com>
Date:   Tue Jan 3 17:12:57 2012 -0800

    target: Use correct preempted registration sense code
    
    commit 9e08e34e3735ae057eb3834da3570995811b7eb9 upstream.
    
    The comments quote the right parts of the spec:
    
       * d) Establish a unit attention condition for the
       *    initiator port associated with every I_T nexus
       *    that lost its registration other than the I_T
       *    nexus on which the PERSISTENT RESERVE OUT command
       *    was received, with the additional sense code set
       *    to REGISTRATIONS PREEMPTED.
    
    and
    
       * e) Establish a unit attention condition for the initiator
       *    port associated with every I_T nexus that lost its
       *    persistent reservation and/or registration, with the
       *    additional sense code set to REGISTRATIONS PREEMPTED;
    
    but the actual code accidentally uses ASCQ_2AH_RESERVATIONS_PREEMPTED
    instead of ASCQ_2AH_REGISTRATIONS_PREEMPTED.  Fix this.
    
    Signed-off-by: Marco Sanvido <marco@purestorage.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0a77dc1abbe11f8d14a6cce8632d85ff79f3636
Author: Hugh Dickins <hughd@google.com>
Date:   Wed Feb 8 17:13:40 2012 -0800

    mm: fix UP THP spin_is_locked BUGs
    
    commit b9980cdcf2524c5fe15d8cbae9c97b3ed6385563 upstream.
    
    Fix CONFIG_TRANSPARENT_HUGEPAGE=y CONFIG_SMP=n CONFIG_DEBUG_VM=y
    CONFIG_DEBUG_SPINLOCK=n kernel: spin_is_locked() is then always false,
    and so triggers some BUGs in Transparent HugePage codepaths.
    
    asm-generic/bug.h mentions this problem, and provides a WARN_ON_SMP(x);
    but being too lazy to add VM_BUG_ON_SMP, BUG_ON_SMP, WARN_ON_SMP_ONCE,
    VM_WARN_ON_SMP_ONCE, just test NR_CPUS != 1 in the existing VM_BUG_ONs.
    
    Signed-off-by: Hugh Dickins <hughd@google.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 a7d2576c858c397282602fe92adf8c8ac9d6a0e0
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Feb 8 17:13:38 2012 -0800

    mm: compaction: check for overlapping nodes during isolation for migration
    
    commit dc9086004b3d5db75997a645b3fe08d9138b7ad0 upstream.
    
    When isolating pages for migration, migration starts at the start of a
    zone while the free scanner starts at the end of the zone.  Migration
    avoids entering a new zone by never going beyond the free scanned.
    
    Unfortunately, in very rare cases nodes can overlap.  When this happens,
    migration isolates pages without the LRU lock held, corrupting lists
    which will trigger errors in reclaim or during page free such as in the
    following oops
    
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      IP: [<ffffffff810f795c>] free_pcppages_bulk+0xcc/0x450
      PGD 1dda554067 PUD 1e1cb58067 PMD 0
      Oops: 0000 [#1] SMP
      CPU 37
      Pid: 17088, comm: memcg_process_s Tainted: G            X
      RIP: free_pcppages_bulk+0xcc/0x450
      Process memcg_process_s (pid: 17088, threadinfo ffff881c2926e000, task ffff881c2926c0c0)
      Call Trace:
        free_hot_cold_page+0x17e/0x1f0
        __pagevec_free+0x90/0xb0
        release_pages+0x22a/0x260
        pagevec_lru_move_fn+0xf3/0x110
        putback_lru_page+0x66/0xe0
        unmap_and_move+0x156/0x180
        migrate_pages+0x9e/0x1b0
        compact_zone+0x1f3/0x2f0
        compact_zone_order+0xa2/0xe0
        try_to_compact_pages+0xdf/0x110
        __alloc_pages_direct_compact+0xee/0x1c0
        __alloc_pages_slowpath+0x370/0x830
        __alloc_pages_nodemask+0x1b1/0x1c0
        alloc_pages_vma+0x9b/0x160
        do_huge_pmd_anonymous_page+0x160/0x270
        do_page_fault+0x207/0x4c0
        page_fault+0x25/0x30
    
    The "X" in the taint flag means that external modules were loaded but but
    is unrelated to the bug triggering.  The real problem was because the PFN
    layout looks like this
    
      Zone PFN ranges:
        DMA      0x00000010 -> 0x00001000
        DMA32    0x00001000 -> 0x00100000
        Normal   0x00100000 -> 0x01e80000
      Movable zone start PFN for each node
      early_node_map[14] active PFN ranges
          0: 0x00000010 -> 0x0000009b
          0: 0x00000100 -> 0x0007a1ec
          0: 0x0007a354 -> 0x0007a379
          0: 0x0007f7ff -> 0x0007f800
          0: 0x00100000 -> 0x00680000
          1: 0x00680000 -> 0x00e80000
          0: 0x00e80000 -> 0x01080000
          1: 0x01080000 -> 0x01280000
          0: 0x01280000 -> 0x01480000
          1: 0x01480000 -> 0x01680000
          0: 0x01680000 -> 0x01880000
          1: 0x01880000 -> 0x01a80000
          0: 0x01a80000 -> 0x01c80000
          1: 0x01c80000 -> 0x01e80000
    
    The fix is straight-forward.  isolate_migratepages() has to make a
    similar check to isolate_freepage to ensure that it never isolates pages
    from a zone it does not hold the LRU lock for.
    
    This was discovered in a 3.0-based kernel but it affects 3.1.x, 3.2.x
    and current mainline.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Michal Nazarewicz <mina86@mina86.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 d7cd8fc525c9322ceb1f1de26d7c6201aef9d842
Author: Joerg Roedel <joerg.roedel@amd.com>
Date:   Thu Jan 26 18:25:37 2012 +0100

    iommu/msm: Fix error handling in msm_iommu_unmap()
    
    commit 05df1f3c2afaef5672627f2b7095f0d4c4dbc3a0 upstream.
    
    Error handling in msm_iommu_unmap() is broken. On some error
    conditions retval is set to a non-zero value which causes
    the function to return 'len' at the end. This hides the
    error from the user. Zero should be returned in those error
    cases.
    
    Cc: David Brown <davidb@codeaurora.org>
    Cc: Stepan Moskovchenko <stepanm@codeaurora.org>
    Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
    Acked-by: David Brown <davidb@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61c39c6dcc3c7b3278c611a5bdcc135a1e4d825e
Author: Joerg Roedel <joerg.roedel@amd.com>
Date:   Wed Jan 18 14:03:11 2012 +0100

    iommu/amd: Work around broken IVRS tables
    
    commit af1be04901e27ce669b4ecde1c953d5c939498f5 upstream.
    
    On some systems the IVRS table does not contain all PCI
    devices present in the system. In case a device not present
    in the IVRS table is translated by the IOMMU no DMA is
    possible from that device by default.
    This patch fixes this by removing the DTE entry for every
    PCI device present in the system and not covered by IVRS.
    
    Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc7e7c8b2462ed098d18bc54b431341cc69584b2
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Sat Feb 4 20:56:47 2012 +0100

    ALSA: oxygen, virtuoso: fix exchanged L/R volumes of aux and CD inputs
    
    commit 2492250e4412c6411324c14ab289629360640b0a upstream.
    
    The driver accidentally exchanged the left/right fields for stereo AC'97
    mixer registers.  This affected only the aux and CD inputs because the
    line input bypasses the AC'97 codec and the mic input is mono; cards
    without AC'97 (Xonar DS/DG/HDAV Slim, HG2PCI, HiFier) were not affected.
    
    Reported-and-tested-by: Abby Cedar <abbycedar@yahoo.com.au>
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93636af6098a627a1ddc02f2f265be4a9d337201
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Wed Feb 8 17:13:41 2012 -0800

    pcmcia: fix socket refcount decrementing on each resume
    
    commit 025e4ab3db07fcbf62c01e4f30d1012234beb980 upstream.
    
    This fixes a memory-corrupting bug: not only does it cause the warning,
    but as a result of dropping the refcount to zero, it causes the
    pcmcia_socket0 device structure to be freed while it still has
    references, causing slab caches corruption.  A fatal oops quickly
    follows this warning - often even just a 'dmesg' following the warning
    causes the kernel to oops.
    
    While testing suspend/resume on an ARM device with PCMCIA support, and a
    CF card inserted, I found that after five suspend and resumes, the
    kernel would complain, and shortly die after with slab corruption.
    
      WARNING: at include/linux/kref.h:41 kobject_get+0x28/0x50()
    
    As the message doesn't give a clue about which kobject, and the built-in
    debugging in drivers/base/power/main.c happens too late, this was added
    right before each get_device():
    
      printk("%s: %p [%s] %u\n", __func__, dev, kobject_name(&dev->kobj), atomic_read(&dev->kobj.kref.refcount));
    
    and on the 3rd s2ram cycle, the following behaviour observed:
    
    On the 3rd suspend/resume cycle:
    
      dpm_prepare: c1a0d998 [pcmcia_socket0] 3
      dpm_suspend: c1a0d998 [pcmcia_socket0] 3
      dpm_suspend_noirq: c1a0d998 [pcmcia_socket0] 3
      dpm_resume_noirq: c1a0d998 [pcmcia_socket0] 3
      dpm_resume: c1a0d998 [pcmcia_socket0] 3
      dpm_complete: c1a0d998 [pcmcia_socket0] 2
    
    4th:
    
      dpm_prepare: c1a0d998 [pcmcia_socket0] 2
      dpm_suspend: c1a0d998 [pcmcia_socket0] 2
      dpm_suspend_noirq: c1a0d998 [pcmcia_socket0] 2
      dpm_resume_noirq: c1a0d998 [pcmcia_socket0] 2
      dpm_resume: c1a0d998 [pcmcia_socket0] 2
      dpm_complete: c1a0d998 [pcmcia_socket0] 1
    
    5th:
    
      dpm_prepare: c1a0d998 [pcmcia_socket0] 1
      dpm_suspend: c1a0d998 [pcmcia_socket0] 1
      dpm_suspend_noirq: c1a0d998 [pcmcia_socket0] 1
      dpm_resume_noirq: c1a0d998 [pcmcia_socket0] 1
      dpm_resume: c1a0d998 [pcmcia_socket0] 1
      dpm_complete: c1a0d998 [pcmcia_socket0] 0
      ------------[ cut here ]------------
      WARNING: at include/linux/kref.h:41 kobject_get+0x28/0x50()
      Modules linked in: ucb1x00_core
      Backtrace:
      [<c0212090>] (dump_backtrace+0x0/0x110) from [<c04799dc>] (dump_stack+0x18/0x1c)
      [<c04799c4>] (dump_stack+0x0/0x1c) from [<c021cba0>] (warn_slowpath_common+0x50/0x68)
      [<c021cb50>] (warn_slowpath_common+0x0/0x68) from [<c021cbdc>] (warn_slowpath_null+0x24/0x28)
      [<c021cbb8>] (warn_slowpath_null+0x0/0x28) from [<c0335374>] (kobject_get+0x28/0x50)
      [<c033534c>] (kobject_get+0x0/0x50) from [<c03804f4>] (get_device+0x1c/0x24)
      [<c0388c90>] (dpm_complete+0x0/0x1a0) from [<c0389cc0>] (dpm_resume_end+0x1c/0x20)
      ...
    
    Looking at commit 7b24e7988263 ("pcmcia: split up central event handler"),
    the following change was made to cs.c:
    
                    return 0;
            }
     #endif
    -
    -       send_event(skt, CS_EVENT_PM_RESUME, CS_EVENT_PRI_LOW);
    +       if (!(skt->state & SOCKET_CARDBUS) && (skt->callback))
    +               skt->callback->early_resume(skt);
            return 0;
     }
    
    And the corresponding change in ds.c is from:
    
    -static int ds_event(struct pcmcia_socket *skt, event_t event, int priority)
    -{
    -       struct pcmcia_socket *s = pcmcia_get_socket(skt);
    ...
    -       switch (event) {
    ...
    -       case CS_EVENT_PM_RESUME:
    -               if (verify_cis_cache(skt) != 0) {
    -                       dev_dbg(&skt->dev, "cis mismatch - different card\n");
    -                       /* first, remove the card */
    -                       ds_event(skt, CS_EVENT_CARD_REMOVAL, CS_EVENT_PRI_HIGH);
    -                       mutex_lock(&s->ops_mutex);
    -                       destroy_cis_cache(skt);
    -                       kfree(skt->fake_cis);
    -                       skt->fake_cis = NULL;
    -                       s->functions = 0;
    -                       mutex_unlock(&s->ops_mutex);
    -                       /* now, add the new card */
    -                       ds_event(skt, CS_EVENT_CARD_INSERTION,
    -                                CS_EVENT_PRI_LOW);
    -               }
    -               break;
    ...
    -    }
    
    -    pcmcia_put_socket(s);
    
    -    return 0;
    -} /* ds_event */
    
    to:
    
    +static int pcmcia_bus_early_resume(struct pcmcia_socket *skt)
    +{
    +       if (!verify_cis_cache(skt)) {
    +               pcmcia_put_socket(skt);
    +               return 0;
    +       }
    
    +       dev_dbg(&skt->dev, "cis mismatch - different card\n");
    
    +       /* first, remove the card */
    +       pcmcia_bus_remove(skt);
    +       mutex_lock(&skt->ops_mutex);
    +       destroy_cis_cache(skt);
    +       kfree(skt->fake_cis);
    +       skt->fake_cis = NULL;
    +       skt->functions = 0;
    +       mutex_unlock(&skt->ops_mutex);
    
    +       /* now, add the new card */
    +       pcmcia_bus_add(skt);
    +       return 0;
    +}
    
    As can be seen, the original function called pcmcia_get_socket() and
    pcmcia_put_socket() around the guts, whereas the replacement code
    calls pcmcia_put_socket() only in one path.  This creates an imbalance
    in the refcounting.
    
    Testing with pcmcia_put_socket() put removed shows that the bug is gone:
    
      dpm_suspend: c1a10998 [pcmcia_socket0] 5
      dpm_suspend_noirq: c1a10998 [pcmcia_socket0] 5
      dpm_resume_noirq: c1a10998 [pcmcia_socket0] 5
      dpm_resume: c1a10998 [pcmcia_socket0] 5
      dpm_complete: c1a10998 [pcmcia_socket0] 5
    
    Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    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 a79cee16dfd9206eb087fbd25767c4d8dec0b0c5
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Tue Feb 7 17:24:19 2012 +0000

    ASoC: wm8994: Fix typo in VMID ramp setting
    
    commit f647e1526fd6c7c8ab720781c40d11e11f930e93 upstream.
    
    The VMID ramp rate is supposed to be 0x3, not 11b. Fix that.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9ee45b83b21448a8e27309456430890b5fa1ff2
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Mon Feb 6 12:07:08 2012 +0000

    ASoC: wm8994: Enabling VMID should take a runtime PM reference
    
    commit db966f8abb9ba74f7d5a7230f51572f52c31c4e5 upstream.
    
    We can enable VMID independently of the bias in some use cases so we need
    to ensure that the core device is powered up.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef7dcc8c0fd35d7fb937d7bc4ac7b883945b3586
Author: Susan Gao <sgao@opensource.wolfsonmicro.com>
Date:   Mon Jan 30 13:57:04 2012 -0800

    ASoC: wm8962: Fix word length configuration
    
    commit 2b6712b19531e22455e7fa18371c5ba9eec76699 upstream.
    
    Signed-off-by: Susan Gao <sgao@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 520a5189a6745dcd3b61e87562e28d6e8aba12f8
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Wed Feb 1 23:46:58 2012 +0000

    ASoC: wm_hubs: Correct line input to line output 2 paths
    
    commit 43b6cec27e1e50a1de3eff47e66e502f3fe7e66e upstream.
    
    The second line output mixer has the controls for the line input bypasses
    in the opposite order.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f11e42f5205653968c6496e637b1cd524405a9ec
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Tue Jan 31 11:55:32 2012 +0000

    ASoC: wm_hubs: Fix routing of input PGAs to line output mixer
    
    commit ee76744c51ec342df9822b4a85dbbfc3887b6d60 upstream.
    
    IN1L/R is routed to both line output mixers, we don't route IN1 to LINEOUT1
    and IN2 to LINEOUT2.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b88c23d62bcaf794ebd97400869d00f00befcd6
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Mon Jan 16 23:33:48 2012 -0800

    iscsi-target: Fix discovery with INADDR_ANY and IN6ADDR_ANY_INIT
    
    commit 2f9bc894c67dbacae5a6a9875818d2a18a918d18 upstream.
    
    This patch addresses a bug with sendtargets discovery where INADDR_ANY (0.0.0.0)
    + IN6ADDR_ANY_INIT ([0:0:0:0:0:0:0:0]) network portals where incorrectly being
    reported back to initiators instead of the address of the connecting interface.
    To address this, save local socket ->getname() output during iscsi login setup,
    and makes iscsit_build_sendtargets_response() return these TargetAddress keys
    when INADDR_ANY or IN6ADDR_ANY_INIT portals are in use.
    
    Reported-by: Dax Kelson <dkelson@gurulabs.com>
    Reported-by: Andy Grover <agrover@redhat.com>
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49f4afd3b15866b16b72691a6060fad041e8f2dc
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Mon Jan 16 17:11:54 2012 -0800

    iscsi-target: Fix double list_add with iscsit_alloc_buffs reject
    
    commit cd931ee62fd0258fc85c76a7c5499fe85e0f3436 upstream.
    
    This patch fixes a bug where the iscsit_add_reject_from_cmd() call
    from a failure to iscsit_alloc_buffs() was incorrectly passing
    add_to_conn=1 and causing a double list_add after iscsi_cmd->i_list
    had already been added in iscsit_handle_scsi_cmd().
    
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa577fc1c4b43933b74efe8d44075ef93f289516
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Mon Jan 16 16:04:15 2012 -0800

    iscsi-target: Fix reject release handling in iscsit_free_cmd()
    
    commit c1ce4bd56f2846de55043374598fd929ad3b711b upstream.
    
    This patch addresses a bug where iscsit_free_cmd() was incorrectly calling
    iscsit_release_cmd() for ISCSI_OP_REJECT because iscsi_add_reject*() will
    overwrite the original iscsi_cmd->iscsi_opcode assignment.  This bug was
    introduced with the following commit:
    
    commit 0be67f2ed8f577d2c72d917928394c5885fa9134
    Author: Nicholas Bellinger <nab@linux-iscsi.org>
    Date:   Sun Oct 9 01:48:14 2011 -0700
    
        iscsi-target: Remove SCF_SE_LUN_CMD flag abuses
    
    and was manifesting itself as list corruption with the following:
    
    [  131.191092] ------------[ cut here ]------------
    [  131.191092] WARNING: at lib/list_debug.c:53 __list_del_entry+0x8d/0x98()
    [  131.191092] Hardware name: VMware Virtual Platform
    [  131.191092] list_del corruption. prev->next should be ffff880022d3c100, but was 6b6b6b6b6b6b6b6b
    [  131.191092] Modules linked in: tcm_vhost ib_srpt ib_cm ib_sa ib_mad ib_core tcm_qla2xxx qla2xxx tcm_loop tcm_fc libfc scsi_transport_fc crc32c iscsi_target_mod target_core_stgt scsi_tgt target_core_pscsi target_core_file target_core_iblock target_core_mod configfs ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi sr_mod cdrom sd_mod e1000 ata_piix libata mptspi mptscsih mptbase [last unloaded: scsi_wait_scan]
    [  131.191092] Pid: 2250, comm: iscsi_ttx Tainted: G        W    3.2.0-rc4+ #42
    [  131.191092] Call Trace:
    [  131.191092]  [<ffffffff8103b553>] warn_slowpath_common+0x80/0x98
    [  131.191092]  [<ffffffff8103b5ff>] warn_slowpath_fmt+0x41/0x43
    [  131.191092]  [<ffffffff811d0279>] __list_del_entry+0x8d/0x98
    [  131.191092]  [<ffffffffa01395c9>] transport_lun_remove_cmd+0x9b/0xb7 [target_core_mod]
    [  131.191092]  [<ffffffffa013a55c>] transport_generic_free_cmd+0x5d/0x71 [target_core_mod]
    [  131.191092]  [<ffffffffa01a012b>] iscsit_free_cmd+0x1e/0x27 [iscsi_target_mod]
    [  131.191092]  [<ffffffffa01a13be>] iscsit_close_connection+0x14d/0x5b2 [iscsi_target_mod]
    [  131.191092]  [<ffffffffa0196a0c>] iscsit_take_action_for_connection_exit+0xdb/0xe0 [iscsi_target_mod]
    [  131.191092]  [<ffffffffa01a55d4>] iscsi_target_tx_thread+0x15cb/0x1608 [iscsi_target_mod]
    [  131.191092]  [<ffffffff8103609a>] ? check_preempt_wakeup+0x121/0x185
    [  131.191092]  [<ffffffff81030801>] ? __dequeue_entity+0x2e/0x33
    [  131.191092]  [<ffffffffa01a4009>] ? iscsit_send_text_rsp+0x25f/0x25f [iscsi_target_mod]
    [  131.191092]  [<ffffffffa01a4009>] ? iscsit_send_text_rsp+0x25f/0x25f [iscsi_target_mod]
    [  131.191092]  [<ffffffff8138f706>] ? schedule+0x55/0x57
    [  131.191092]  [<ffffffff81056c7d>] kthread+0x7d/0x85
    [  131.191092]  [<ffffffff81399534>] kernel_thread_helper+0x4/0x10
    [  131.191092]  [<ffffffff81056c00>] ? kthread_worker_fn+0x16d/0x16d
    [  131.191092]  [<ffffffff81399530>] ? gs_change+0x13/0x13
    
    Reported-by: <jrepac@yahoo.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6492a0fb92a35630103cc62a1902018dfef8b46c
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Wed Dec 7 14:30:58 2011 +0000

    lockdep, bug: Exclude TAINT_OOT_MODULE from disabling lock debugging
    
    commit 9ec84acee1e221d99dc33237bff5e82839d10cc0 upstream.
    
    We do want to allow lock debugging for GPL-compatible modules
    that are not (yet) built in-tree.  This was disabled as a
    side-effect of commit 2449b8ba0745327c5fa49a8d9acffe03b2eded69
    ('module,bug: Add TAINT_OOT_MODULE flag for modules not built
    in-tree').  Lock debug warnings now include taint flags, so
    kernel developers should still be able to deflect warnings
    caused by out-of-tree modules.
    
    The TAINT_PROPRIETARY_MODULE flag for non-GPL-compatible modules
    will still disable lock debugging.
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Nick Bowler <nbowler@elliptictech.com>
    Cc: Dave Jones <davej@redhat.com>
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Cc: Randy Dunlap <rdunlap@xenotime.net>
    Cc: Debian kernel maintainers <debian-kernel@lists.debian.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Alan Cox <alan@linux.intel.com>
    Link: http://lkml.kernel.org/r/1323268258.18450.11.camel@deadeye
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a90d01be282f295186d58b42d8cbac1d5d7edc4
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Mon Nov 14 13:13:49 2011 +0100

    lockdep, bug: Exclude TAINT_FIRMWARE_WORKAROUND from disabling lockdep
    
    commit df754e6af2f237a6c020c0daff55a1a609338e31 upstream.
    
    It's unlikely that TAINT_FIRMWARE_WORKAROUND causes false
    lockdep messages, so do not disable lockdep in that case.
    We still want to keep lockdep disabled in the
    TAINT_OOT_MODULE case:
    
      - bin-only modules can cause various instabilities in
        their and in unrelated kernel code
    
      - they are impossible to debug for kernel developers
    
      - they also typically do not have the copyright license
        permission to link to the GPL-ed lockdep code.
    
    Suggested-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/n/tip-xopopjjens57r0i13qnyh2yo@git.kernel.org
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1a4af09cec0d39604a99ab58e59276c69c4179a
Author: Hubert Feurstein <h.feurstein@gmail.com>
Date:   Mon Jan 9 17:23:57 2012 +0100

    atmel_lcdfb: fix usage of CONTRAST_CTR in suspend/resume
    
    commit 9f1065032ceb7e86c7c9f16bb86518857e88a172 upstream.
    
    An error was existing in the saving of CONTRAST_CTR register
    across suspend/resume.
    
    Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com>
    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
    Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85f2f3e05e8e0deec4fc8b751324f91acb276d21
Author: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Date:   Thu Feb 2 15:28:28 2012 -0600

    cifs: Fix oops in session setup code for null user mounts
    
    commit de47a4176c532ef5961b8a46a2d541a3517412d3 upstream.
    
    For null user mounts, do not invoke string length function
    during session setup.
    
    Reported-and-Tested-by: Chris Clayton <chris2553@googlemail.com>
    Acked-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 38c8c07ac7383692d0a4f932f6ac611437ed24ed
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Fri Jan 27 05:43:59 2012 -0800

    hwmon: (w83627ehf) Fix number of fans for NCT6776F
    
    commit 585c0fd8216e0c9f98e2434092af7ec0f999522d upstream.
    
    NCT6776F can select fan input pins for fans 3 to 5 with a secondary set of
    chip register bits. Check that second set of bits in addition to the first set
    to detect if fans 3..5 are monitored.
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Acked-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d1b7976d3697421e04c86c7a782833c83244694
Author: Li Wang <liwang@nudt.edu.cn>
Date:   Thu Jan 19 09:44:36 2012 +0800

    eCryptfs: Infinite loop due to overflow in ecryptfs_write()
    
    commit 684a3ff7e69acc7c678d1a1394fe9e757993fd34 upstream.
    
    ecryptfs_write() can enter an infinite loop when truncating a file to a
    size larger than 4G. This only happens on architectures where size_t is
    represented by 32 bits.
    
    This was caused by a size_t overflow due to it incorrectly being used to
    store the result of a calculation which uses potentially large values of
    type loff_t.
    
    [tyhicks@canonical.com: rewrite subject and commit message]
    Signed-off-by: Li Wang <liwang@nudt.edu.cn>
    Signed-off-by: Yunchuan Wen <wenyunchuan@kylinos.com.cn>
    Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69ac25cd32a4032a94c100b52cf52abf6fde90a5
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Dec 14 13:57:03 2011 +0100

    drm/i915: protect force_wake_(get|put) with the gt_lock
    
    commit 9f1f46a45a681d357d1ceedecec3671a5ae957f4 upstream.
    
    The problem this patch solves is that the forcewake accounting
    necessary for register reads is protected by dev->struct_mutex. But the
    hangcheck and error_capture code need to access registers without
    grabbing this mutex because we hold it while waiting for the gpu.
    So a new lock is required. Because currently the error_state capture
    is called from the error irq handler and the hangcheck code runs from
    a timer, it needs to be an irqsafe spinlock (note that the registers
    used by the irq handler (neglecting the error handling part) only uses
    registers that don't need the forcewake dance).
    
    We could tune this down to a normal spinlock when we rework the
    error_state capture and hangcheck code to run from a workqueue.  But
    we don't have any read in a fastpath that needs forcewake, so I've
    decided to not care much about overhead.
    
    This prevents tests/gem_hangcheck_forcewake from i-g-t from killing my
    snb on recent kernels - something must have slightly changed the
    timings. On previous kernels it only trigger a WARN about the broken
    locking.
    
    v2: Drop the previous patch for the register writes.
    
    v3: Improve the commit message per Chris Wilson's suggestions.
    
    Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 97b068a6657ded880cf3b6617e92da865067a0db
Author: Daniel Vetter <daniel@ffwll.ch>
Date:   Fri Jan 13 16:20:06 2012 -0800

    drm/i915: convert force_wake_get to func pointer in the gpu reset code
    
    commit 8109021313c7a3d8947677391ce6ab9cd0bb1d28 upstream.
    
    This was forgotten in the original multi-threaded forcewake
    conversion:
    
    commit 8d715f0024f64ad1b1be85d8c081cf577944c847
    Author: Keith Packard <keithp at keithp.com>
    Date:   Fri Nov 18 20:39:01 2011 -0800
    
        drm/i915: add multi-threaded forcewake support
    
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a390a377bfcf132841798e09e9bb4d0f6c27de91
Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
Date:   Sat Jan 7 23:40:35 2012 -0200

    drm/i915: handle 3rd pipe
    
    commit 07c1e8c1462fa7324de4c36ae9e55da2abd79cee upstream.
    
    We don't need to check 3rd pipe specifically, as it shares PLL with some
    other one.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41977
    Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb10e9cd3a43bcaea5f7d4727b27b8f7e40d9fc7
Author: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Date:   Wed Dec 14 21:10:06 2011 -0200

    drm/i915: Fix TV Out refresh rate.
    
    commit 23bd15ec662344dc10e9918fdd0dbc58bc71526d upstream.
    
    TV Out refresh rate was half of the specification for almost all modes.
    Due to this reason pixel clock was so low for some modes causing flickering screen.
    
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
    Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d0e8c788387c3aea69c498d0cc24a73645b71cb
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Nov 27 18:58:17 2011 +0100

    drm/i915: check ACTHD of all rings
    
    commit 097354eb14fa94d31a09c64d640643f58e4a5a9a upstream.
    
    Otherwise hangcheck spuriously fires when running blitter/bsd-only
    workloads.
    
    Contrary to a similar patch by Ben Widawsky this does not check
    INSTDONE of the other rings. Chris Wilson implied that in a failure to
    detect a hang, most likely because INSTDONE was fluctuating. Thus only
    check ACTHD, which as far as I know is rather reliable. Also, blitter
    and bsd rings can't launch complex tasks from a single instruction
    (like 3D_PRIM on the render with complex or even infinite shaders).
    
    This fixes spurious gpu hang detection when running
    tests/gem_hangcheck_forcewake on snb/ivb.
    
    Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e306967621bd97280eb17c9abab473070a2e5b45
Author: Wu Fengguang <fengguang.wu@intel.com>
Date:   Fri Dec 9 20:42:21 2011 +0800

    drm/i915: DisplayPort hot remove notification to audio driver
    
    commit 832afda6a7d7235ef0e09f4ec46736861540da6d upstream.
    
    On DP monitor hot remove, clear DP_AUDIO_OUTPUT_ENABLE accordingly,
    so that the audio driver will receive hot plug events and take action
    to refresh its device state and ELD contents.
    
    Note that the DP_AUDIO_OUTPUT_ENABLE bit may be enabled or disabled
    only when the link training is complete and set to "Normal".
    
    Tested OK for both hot plug/remove and DPMS on/off.
    
    Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit febaacc3a6165f0cf54ff512f1e7e51563fd27b1
Author: Wu Fengguang <fengguang.wu@intel.com>
Date:   Fri Dec 9 20:42:20 2011 +0800

    drm/i915: HDMI hot remove notification to audio driver
    
    commit 2deed761188d7480eb5f7efbfe7aa77f09322ed8 upstream.
    
    On HDMI monitor hot remove, clear SDVO_AUDIO_ENABLE accordingly, so that
    the audio driver will receive hot plug events and take action to refresh
    its device state and ELD contents.
    
    The cleared SDVO_AUDIO_ENABLE bit needs to be restored to prevent losing
    HDMI audio after DPMS on.
    
    CC: Wang Zhenyu <zhenyu.z.wang@intel.com>
    Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 43f4a516b2f5492bc597f3753b693ad8adc62748
Author: Jan Kara <jack@suse.cz>
Date:   Fri Dec 23 11:53:07 2011 +0100

    udf: Mark LVID buffer as uptodate before marking it dirty
    
    commit 853a0c25baf96b028de1654bea1e0c8857eadf3d upstream.
    
    When we hit EIO while writing LVID, the buffer uptodate bit is cleared.
    This then results in an anoying warning from mark_buffer_dirty() when we
    write the buffer again. So just set uptodate flag unconditionally.
    
    Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Cc: Dave Jones <davej@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff91ca433acbb464e82dbc655c1339498c20d45a
Author: Francois Romieu <romieu@fr.zoreil.com>
Date:   Sun Jan 8 13:41:33 2012 +0000

    8139cp: fix missing napi_gro_flush.
    
    commit b189e810619a676e6b931a942a3e8387f3d39c21 upstream.
    
    The driver uses __napi_complete and napi_gro_receive. Without it, the
    driver hits the BUG_ON(n->gro_list) assertion hard in __napi_complete.
    
    Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
    Tested-by: Marin Glibic <zhilla2@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 695cb013a3332b6c773c8a75be97aa6f91bc227f
Author: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Date:   Wed Feb 1 22:16:36 2012 +0100

    PM / Hibernate: Thaw kernel threads in SNAPSHOT_CREATE_IMAGE ioctl path
    
    commit fe9161db2e6053da21e4649d77bbefaf3030b11d upstream.
    
    In the SNAPSHOT_CREATE_IMAGE ioctl, if the call to hibernation_snapshot()
    fails, the frozen tasks are not thawed.
    
    And in the case of success, if we happen to exit due to a successful freezer
    test, all tasks (including those of userspace) are thawed, whereas actually
    we should have thawed only the kernel threads at that point. Fix both these
    issues.
    
    Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26b67a54a31d8e18f66f52d6bae4907963648d3c
Author: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Date:   Thu Dec 1 22:33:10 2011 +0100

    PM / Hibernate: Thaw processes in SNAPSHOT_CREATE_IMAGE ioctl test path
    
    commit 97819a26224f019e73d88bb2fd4eb5a614860461 upstream.
    
    Commit 2aede851ddf08666f68ffc17be446420e9d2a056 (PM / Hibernate: Freeze
    kernel threads after preallocating memory) moved the freezing of kernel
    threads to hibernation_snapshot() function.
    
    So now, if the call to hibernation_snapshot() returns early due to a
    successful hibernation test, the caller has to thaw processes to ensure
    that the system gets back to its original state.
    
    But in SNAPSHOT_CREATE_IMAGE hibernation ioctl, the caller does not thaw
    processes in case hibernation_snapshot() returned due to a successful
    freezer test. Fix this issue. But note we still send the value of 'in_suspend'
    (which is now 0) to userspace, because we are not in an error path per-se,
    and moreover, the value of in_suspend correctly depicts the situation here.
    
    Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6341f8928cf458016bab6aab444536843083ef0a
Author: Chanho Min <chanho0207@gmail.com>
Date:   Thu Jan 5 20:00:19 2012 +0900

    sched/rt: Fix task stack corruption under __ARCH_WANT_INTERRUPTS_ON_CTXSW
    
    commit cb297a3e433dbdcf7ad81e0564e7b804c941ff0d upstream.
    
    This issue happens under the following conditions:
    
     1. preemption is off
     2. __ARCH_WANT_INTERRUPTS_ON_CTXSW is defined
     3. RT scheduling class
     4. SMP system
    
    Sequence is as follows:
    
     1.suppose current task is A. start schedule()
     2.task A is enqueued pushable task at the entry of schedule()
       __schedule
        prev = rq->curr;
        ...
        put_prev_task
         put_prev_task_rt
          enqueue_pushable_task
     4.pick the task B as next task.
       next = pick_next_task(rq);
     3.rq->curr set to task B and context_switch is started.
       rq->curr = next;
     4.At the entry of context_swtich, release this cpu's rq->lock.
       context_switch
        prepare_task_switch
         prepare_lock_switch
          raw_spin_unlock_irq(&rq->lock);
     5.Shortly after rq->lock is released, interrupt is occurred and start IRQ context
     6.try_to_wake_up() which called by ISR acquires rq->lock
        try_to_wake_up
         ttwu_remote
          rq = __task_rq_lock(p)
          ttwu_do_wakeup(rq, p, wake_flags);
            task_woken_rt
     7.push_rt_task picks the task A which is enqueued before.
       task_woken_rt
        push_rt_tasks(rq)
         next_task = pick_next_pushable_task(rq)
     8.At find_lock_lowest_rq(), If double_lock_balance() returns 0,
       lowest_rq can be the remote rq.
      (But,If preemption is on, double_lock_balance always return 1 and it
       does't happen.)
       push_rt_task
        find_lock_lowest_rq
         if (double_lock_balance(rq, lowest_rq))..
     9.find_lock_lowest_rq return the available rq. task A is migrated to
       the remote cpu/rq.
       push_rt_task
        ...
        deactivate_task(rq, next_task, 0);
        set_task_cpu(next_task, lowest_rq->cpu);
        activate_task(lowest_rq, next_task, 0);
     10. But, task A is on irq context at this cpu.
         So, task A is scheduled by two cpus at the same time until restore from IRQ.
         Task A's stack is corrupted.
    
    To fix it, don't migrate an RT task if it's still running.
    
    Signed-off-by: Chanho Min <chanho.min@lge.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Acked-by: Steven Rostedt <rostedt@goodmis.org>
    Link: http://lkml.kernel.org/r/CAOAMb1BHA=5fm7KTewYyke6u-8DP0iUuJMpgQw54vNeXFsGpoQ@mail.gmail.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 307a5a187c97d1c280e66db8d957249439141850
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Feb 2 10:18:00 2012 -0500

    drm/radeon/kms: fix TRAVIS panel setup
    
    commit 304a48400d9718f74ec35ae46f30868a5f4c4516 upstream.
    
    Different versions of the DP to LVDS bridge chip
    need different panel mode settings depending on
    the chip version used.
    
    Fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=41569
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d11fa680b5daad1ffb72807cfd0ad30237505fff
Author: Seth Forshee <seth.forshee@canonical.com>
Date:   Tue Jan 31 19:06:25 2012 -0600

    drm/radeon/kms: disable output polling when suspended
    
    commit 86698c20f71d488b32c49ed4687fb3cf8a88a5ca upstream.
    
    Polling the outputs when the device is suspended can result in erroneous
    status updates. Disable output polling during suspend to prevent this
    from happening.
    
    Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d15bd1a90e3d768136562ad63e0d25c953d0c85
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Tue Jan 10 10:18:28 2012 +1000

    drm/nouveau/gem: fix fence_sync race / oops
    
    commit 525895ba388c949aa906f26e3ec5cb1ab041f56b upstream.
    
    Due to a race it was possible for a fence to be destroyed while another
    thread was trying to synchronise with it.  If this happened in the fallback
    non-semaphore path, it lead to the following oops due to fence->channel
    being NULL.
    
    BUG: unable to handle kernel NULL pointer dereference at   (null)
    IP: [<fa9632ce>] nouveau_fence_update+0xe/0xe0 [nouveau]
    *pde = a649c067
    SMP
    Modules linked in: fuse nouveau(O) ttm(O) drm_kms_helper(O) drm(O) mxm_wmi video wmi netconsole configfs lockd bnep bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_cobinfmt_misc uinput ata_generic pata_acpi pata_aet2c_algo_bit i2c_core [last unloaded: wmi]
    
    Pid: 2255, comm: gnome-shell Tainted: G           O 3.2.0-0.rc5.git0.1.fc17.i686 #1 System manufacturer System Product Name/M2A-VM
    EIP: 0060:[<fa9632ce>] EFLAGS: 00010296 CPU: 1
    EIP is at nouveau_fence_update+0xe/0xe0 [nouveau]
    EAX: 00000000 EBX: ddfc6dd0 ECX: dd111580 EDX: 00000000
    ESI: 00003e80 EDI: dd111580 EBP: dd121d00 ESP: dd121ce8
     DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
    Process gnome-shell (pid: 2255, ti=dd120000 task=dd111580 task.ti=dd120000)
    Stack:
     7dc86c76 00000000 00003e80 ddfc6dd0 00003e80 dd111580 dd121d0c fa96371f
     00000000 dd121d3c fa963773 dd111580 01000246 000ec53d 00000000 ddfc6dd0
     00001f40 00000000 ddfc6dd0 00000010 dc7df840 dd121d6c fa9639a0 00000000
    Call Trace:
     [<fa96371f>] __nouveau_fence_signalled+0x1f/0x30 [nouveau]
     [<fa963773>] __nouveau_fence_wait+0x43/0xd0 [nouveau]
     [<fa9639a0>] nouveau_fence_sync+0x1a0/0x1c0 [nouveau]
     [<fa964046>] validate_list+0x176/0x300 [nouveau]
     [<f7d9c9c0>] ? ttm_bo_mem_put+0x30/0x30 [ttm]
     [<fa964b8a>] nouveau_gem_ioctl_pushbuf+0x48a/0xfd0 [nouveau]
     [<c0406481>] ? die+0x31/0x80
     [<f7c93d98>] drm_ioctl+0x388/0x490 [drm]
     [<c0406481>] ? die+0x31/0x80
     [<fa964700>] ? nouveau_gem_ioctl_new+0x150/0x150 [nouveau]
     [<c0635c7b>] ? file_has_perm+0xcb/0xe0
     [<f7c93a10>] ? drm_copy_field+0x80/0x80 [drm]
     [<c0564f56>] do_vfs_ioctl+0x86/0x5b0
     [<c0406481>] ? die+0x31/0x80
     [<c0635f22>] ? selinux_file_ioctl+0x62/0x130
     [<c0554f30>] ? fget_light+0x30/0x340
     [<c05654ef>] sys_ioctl+0x6f/0x80
     [<c099e3a4>] syscall_call+0x7/0xb
     [<c0406481>] ? die+0x31/0x80
     [<c0406481>] ? die+0x31/0x80
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 97f2f58ea0382e2e2df0dacc5bba99190cd10846
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Feb 1 12:09:55 2012 +0100

    drm/radeon: Set DESKTOP_HEIGHT register to the framebuffer (not mode) height.
    
    commit 1b61925061660009f5b8047f93c5297e04541273 upstream.
    
    The value of this register is transferred to the V_COUNTER register at the
    beginning of vertical blank. V_COUNTER is the reference for VLINE waits and
    goes from VIEWPORT_Y_START to VIEWPORT_Y_START+VIEWPORT_HEIGHT during scanout,
    so if VIEWPORT_Y_START is not 0, V_COUNTER actually went backwards at the
    beginning of vertical blank, and VLINE waits excluding the whole scanout area
    could never finish (possibly only if VIEWPORT_Y_START is larger than the length
    of vertical blank in scanlines). Setting DESKTOP_HEIGHT to the framebuffer
    height should prevent this for any kind of VLINE wait.
    
    Fixes https://bugs.freedesktop.org/show_bug.cgi?id=45329 .
    
    Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f51d67a64f32cd81ea8b67ca964fb7cf7e783b2e
Author: Venkatesh Pallipadi <venki@google.com>
Date:   Fri Feb 3 22:22:25 2012 +0100

    PM / QoS: CPU C-state breakage with PM Qos change
    
    commit d020283dc694c9ec31b410f522252f7a8397e67d upstream.
    
    Looks like change "PM QoS: Move and rename the implementation files"
    merged during the 3.2 development cycle made PM QoS depend on
    CONFIG_PM which depends on (PM_SLEEP || PM_RUNTIME).
    
    That breaks CPU C-states with kernels not having these CONFIGs, causing CPUs
    to spend time in Polling loop idle instead of going into deep C-states,
    consuming way way more power. This is with either acpi idle or intel idle
    enabled.
    
    Either CONFIG_PM should be enabled with any pm_qos users or
    the !CONFIG_PM pm_qos_request() should return sane defaults not to break
    the existing users. Here's is the patch for the latter option.
    
    [rjw: Modified the changelog slightly.]
    
    Signed-off-by: Venkatesh Pallipadi <venki@google.com>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d483054fe4c66eeb7a03fdc97519b07edb1dc803
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Sun Jan 29 20:35:52 2012 +0100

    PM / Hibernate: Fix s2disk regression related to freezing workqueues
    
    commit 181e9bdef37bfcaa41f3ab6c948a2a0d60a268b5 upstream.
    
    Commit 2aede851ddf08666f68ffc17be446420e9d2a056
    
      PM / Hibernate: Freeze kernel threads after preallocating memory
    
    introduced a mechanism by which kernel threads were frozen after
    the preallocation of hibernate image memory to avoid problems with
    frozen kernel threads not responding to memory freeing requests.
    However, it overlooked the s2disk code path in which the
    SNAPSHOT_CREATE_IMAGE ioctl was run directly after SNAPSHOT_FREE,
    which caused freeze_workqueues_begin() to BUG(), because it saw
    that worqueues had been already frozen.
    
    Although in principle this issue might be addressed by removing
    the relevant BUG_ON() from freeze_workqueues_begin(), that would
    reintroduce the very problem that commit 2aede851ddf08666f68ffc17be4
    attempted to avoid into that particular code path.  For this reason,
    to fix the issue at hand, introduce thaw_kernel_threads() and make
    the SNAPSHOT_FREE ioctl execute it.
    
    Special thanks to Srivatsa S. Bhat for detailed analysis of the
    problem.
    
    Reported-and-tested-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Acked-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9da11afefb6f8ccc0f7731831f7ad73106fc87f3
Author: Mel Gorman <mgorman@suse.de>
Date:   Fri Feb 3 15:37:18 2012 -0800

    mm: compaction: check pfn_valid when entering a new MAX_ORDER_NR_PAGES block during isolation for migration
    
    commit 0bf380bc70ecba68cb4d74dc656cc2fa8c4d801a upstream.
    
    When isolating for migration, migration starts at the start of a zone
    which is not necessarily pageblock aligned.  Further, it stops isolating
    when COMPACT_CLUSTER_MAX pages are isolated so migrate_pfn is generally
    not aligned.  This allows isolate_migratepages() to call pfn_to_page() on
    an invalid PFN which can result in a crash.  This was originally reported
    against a 3.0-based kernel with the following trace in a crash dump.
    
    PID: 9902   TASK: d47aecd0  CPU: 0   COMMAND: "memcg_process_s"
     #0 [d72d3ad0] crash_kexec at c028cfdb
     #1 [d72d3b24] oops_end at c05c5322
     #2 [d72d3b38] __bad_area_nosemaphore at c0227e60
     #3 [d72d3bec] bad_area at c0227fb6
     #4 [d72d3c00] do_page_fault at c05c72ec
     #5 [d72d3c80] error_code (via page_fault) at c05c47a4
        EAX: 00000000  EBX: 000c0000  ECX: 00000001  EDX: 00000807  EBP: 000c0000
        DS:  007b      ESI: 00000001  ES:  007b      EDI: f3000a80  GS:  6f50
        CS:  0060      EIP: c030b15a  ERR: ffffffff  EFLAGS: 00010002
     #6 [d72d3cb4] isolate_migratepages at c030b15a
     #7 [d72d3d14] zone_watermark_ok at c02d26cb
     #8 [d72d3d2c] compact_zone at c030b8de
     #9 [d72d3d68] compact_zone_order at c030bba1
    #10 [d72d3db4] try_to_compact_pages at c030bc84
    #11 [d72d3ddc] __alloc_pages_direct_compact at c02d61e7
    #12 [d72d3e08] __alloc_pages_slowpath at c02d66c7
    #13 [d72d3e78] __alloc_pages_nodemask at c02d6a97
    #14 [d72d3eb8] alloc_pages_vma at c030a845
    #15 [d72d3ed4] do_huge_pmd_anonymous_page at c03178eb
    #16 [d72d3f00] handle_mm_fault at c02f36c6
    #17 [d72d3f30] do_page_fault at c05c70ed
    #18 [d72d3fb0] error_code (via page_fault) at c05c47a4
        EAX: b71ff000  EBX: 00000001  ECX: 00001600  EDX: 00000431
        DS:  007b      ESI: 08048950  ES:  007b      EDI: bfaa3788
        SS:  007b      ESP: bfaa36e0  EBP: bfaa3828  GS:  6f50
        CS:  0073      EIP: 080487c8  ERR: ffffffff  EFLAGS: 00010202
    
    It was also reported by Herbert van den Bergh against 3.1-based kernel
    with the following snippet from the console log.
    
    BUG: unable to handle kernel paging request at 01c00008
    IP: [<c0522399>] isolate_migratepages+0x119/0x390
    *pdpt = 000000002f7ce001 *pde = 0000000000000000
    
    It is expected that it also affects 3.2.x and current mainline.
    
    The problem is that pfn_valid is only called on the first PFN being
    checked and that PFN is not necessarily aligned.  Lets say we have a case
    like this
    
    H = MAX_ORDER_NR_PAGES boundary
    | = pageblock boundary
    m = cc->migrate_pfn
    f = cc->free_pfn
    o = memory hole
    
    H------|------H------|----m-Hoooooo|ooooooH-f----|------H
    
    The migrate_pfn is just below a memory hole and the free scanner is beyond
    the hole.  When isolate_migratepages started, it scans from migrate_pfn to
    migrate_pfn+pageblock_nr_pages which is now in a memory hole.  It checks
    pfn_valid() on the first PFN but then scans into the hole where there are
    not necessarily valid struct pages.
    
    This patch ensures that isolate_migratepages calls pfn_valid when
    necessary.
    
    Reported-by: Herbert van den Bergh <herbert.van.den.bergh@oracle.com>
    Tested-by: Herbert van den Bergh <herbert.van.den.bergh@oracle.com>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Michal Nazarewicz <mina86@mina86.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 e7908f7b777ac850ef6a11cb53aa8e27fcf40a1e
Author: Carsten Otte <carsteno@de.ibm.com>
Date:   Fri Feb 3 15:37:14 2012 -0800

    mm/filemap_xip.c: fix race condition in xip_file_fault()
    
    commit 99f02ef1f18631eb0a4e0ea0a3d56878dbcb4b90 upstream.
    
    Fix a race condition that shows in conjunction with xip_file_fault() when
    two threads of the same user process fault on the same memory page.
    
    In this case, the race winner will install the page table entry and the
    unlucky loser will cause an oops: xip_file_fault calls vm_insert_pfn (via
    vm_insert_mixed) which drops out at this check:
    
    	retval = -EBUSY;
    	if (!pte_none(*pte))
    		goto out_unlock;
    
    The resulting -EBUSY return value will trigger a BUG_ON() in
    xip_file_fault.
    
    This fix simply considers the fault as fixed in this case, because the
    race winner has successfully installed the pte.
    
    [akpm@linux-foundation.org: use conventional (and consistent) comment layout]
    Reported-by: David Sadler <dsadler@us.ibm.com>
    Signed-off-by: Carsten Otte <cotte@de.ibm.com>
    Reported-by: Louis Alex Eisner <leisner@cs.ucsd.edu>
    Cc: Hugh Dickins <hughd@google.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 2139363dee1243badcac4da0af194ed764339c05
Author: Nikolaus Voss <n.voss@weinmann.de>
Date:   Tue Jan 17 10:28:33 2012 +0100

    at_hdmac: bugfix for enabling channel irq
    
    commit bda3a47c886664e86ee14eb79e9072b9e341f575 upstream.
    
    commit 463894705e4089d0ff69e7d877312d496ac70e5b deleted redundant
    chan_id and chancnt initialization in dma drivers as this is done
    in dma_async_device_register().
    
    However, atc_enable_irq() relied on chan_id set before registering
    the device, what left only channel 0 functional for this driver.
    
    This patch introduces atc_enable/disable_chan_irq() as a variant
    of atc_enable/disable_irq() with the channel as explicit argument.
    
    Signed-off-by: Nikolaus Voss <n.voss@weinmann.de>
    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 061d6b14b3b59f140371baa0f98963f761a7080f
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Thu Feb 2 13:54:25 2012 +0200

    Revert "mtd: atmel_nand: optimize read/write buffer functions"
    
    commit 500823195d0c9eec2a4637484f30cc93ec633d4a upstream.
    
    This reverts commit fb5427508abbd635e877fabdf55795488119c2d6.
    
    The reason is that it breaks 16 bits NAND flash as it was reported by
    Nikolaus Voss and confirmed by Eric Bénard.
    
    Nicolas Ferre <nicolas.ferre@atmel.com> alco confirmed:
    "After double checking with designers, I must admit that I misunderstood
    the way of optimizing accesses to SMC. 16 bit nand is not so common
    those days..."
    
    Reported-by: Nikolaus Voss <n.voss@weinmann.de>
    Acked-by: Nicolas Ferre <nicolas.ferre@atmel.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 5e71844e1d3a9ae8681fc18781a3579eed4b2406
Author: Huang Shijie <b32955@freescale.com>
Date:   Wed Jan 4 11:18:46 2012 +0800

    mtd: gpmi-nand bugfix: reset the BCH module when it is not MX23
    
    commit 9398d1ce09b9009996f7d2468e1d3c785fa6feda upstream.
    
    In MX28, if we do not reset the BCH module. The BCH module may
    becomes unstable when the board reboots for several thousands times.
    This bug has been catched in customer's production.
    
    The patch adds some comments (some from Wolfram Sang), and fixes it now.
    
    Also change gpmi_reset_block() to static.
    
    Signed-off-by: Huang Shijie <b32955@freescale.com>
    Acked-by: Marek Vasut <marek.vasut@gmail.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 ff016619c98fa2edcb44b6cffe5a60435328348a
Author: Jiang Liu <liuj97@gmail.com>
Date:   Fri Feb 3 15:37:16 2012 -0800

    kprobes: fix a memory leak in function pre_handler_kretprobe()
    
    commit 55ca6140e9bb307efc97a9301a4f501de02a6fd6 upstream.
    
    In function pre_handler_kretprobe(), the allocated kretprobe_instance
    object will get leaked if the entry_handler callback returns non-zero.
    This may cause all the preallocated kretprobe_instance objects exhausted.
    
    This issue can be reproduced by changing
    samples/kprobes/kretprobe_example.c to probe "mutex_unlock".  And the fix
    is straightforward: just put the allocated kretprobe_instance object back
    onto the free_instances list.
    
    [akpm@linux-foundation.org: use raw_spin_lock/unlock]
    Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
    Acked-by: Jim Keniston <jkenisto@us.ibm.com>
    Acked-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
    Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
    Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    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 3ef7302303a7886fd1e6dea9dd33fe2c41784199
Author: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
Date:   Fri Jan 20 18:43:54 2012 +0000

    RDMA/core: Fix kernel panic by always initializing qp->usecnt
    
    commit e47e321a35c741ee41b67976f8c6a3a7a42bc5c0 upstream.
    
    We have just been investigating kernel panics related to
    cq->ibcq.event_handler() completion calls.  The problem is that
    ib_destroy_qp() fails with -EBUSY.
    
    Further investigation revealed qp->usecnt is not initialized.  This
    counter was introduced in linux-3.2 by commit 0e0ec7e0638e
    ("RDMA/core: Export ib_open_qp() to share XRC TGT QPs") but it only
    gets initialized for IB_QPT_XRC_TGT, but it is checked in
    ib_destroy_qp() for any QP type.
    
    Fix this by initializing qp->usecnt for every QP we create.
    
    Signed-off-by: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
    Signed-off-by: Sven Breuner <sven.breuner@itwm.fraunhofer.de>
    
    [ Initialize qp->usecnt in uverbs too.  - Sean ]
    
    Signed-off-by: Sean Hefty <sean.hefty@intel.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a48d135810111baaedd01dfb833c06b094aa3a68
Author: Jack Morgenstein <jackm@mellanox.com>
Date:   Thu Jan 26 16:41:33 2012 +0200

    IB/mlx4: pass SMP vendor-specific attribute MADs to firmware
    
    commit a6f7feae6d19e84253918d88b04153af09d3a243 upstream.
    
    In the current code, vendor-specific MADs (e.g with the FDR-10
    attribute) are silently dropped by the driver, resulting in timeouts
    at the sending side and inability to query/configure the relevant
    feature.  However, the ConnectX firmware is able to handle such MADs.
    For unsupported attributes, the firmware returns a GET_RESPONSE MAD
    containing an error status.
    
    For example, for a FDR-10 node with LID 11:
    
        # ibstat mlx4_0 1
    
        CA: 'mlx4_0'
        Port 1:
        State: Active
        Physical state: LinkUp
        Rate: 40 (FDR10)
        Base lid: 11
        LMC: 0
        SM lid: 24
        Capability mask: 0x02514868
        Port GUID: 0x0002c903002e65d1
        Link layer: InfiniBand
    
    Extended Port Query (EPI) vendor mad timeouts before the patch:
    
        # smpquery MEPI 11 -d
    
        ibwarn: [4196] smp_query_via: attr 0xff90 mod 0x0 route Lid 11
        ibwarn: [4196] _do_madrpc: retry 1 (timeout 1000 ms)
        ibwarn: [4196] _do_madrpc: retry 2 (timeout 1000 ms)
        ibwarn: [4196] _do_madrpc: timeout after 3 retries, 3000 ms
        ibwarn: [4196] mad_rpc: _do_madrpc failed; dport (Lid 11)
        smpquery: iberror: [pid 4196] main: failed: operation EPI: ext port info query failed
    
    EPI query works OK with the patch:
    
        # smpquery MEPI 11 -d
    
        ibwarn: [6548] smp_query_via: attr 0xff90 mod 0x0 route Lid 11
        ibwarn: [6548] mad_rpc: data offs 64 sz 64
        mad data
        0000 0000 0000 0001 0000 0001 0000 0001
        0000 0000 0000 0000 0000 0000 0000 0000
        0000 0000 0000 0000 0000 0000 0000 0000
        0000 0000 0000 0000 0000 0000 0000 0000
        # Ext Port info: Lid 11 port 0
        StateChangeEnable:...............0x00
        LinkSpeedSupported:..............0x01
        LinkSpeedEnabled:................0x01
        LinkSpeedActive:.................0x01
    
    Signed-off-by: Jack Morgenstein <jackm@mellanox.com>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Acked-by: Ira Weiny <weiny2@llnl.gov>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1a1e15fd6fe7ed496d115ac9b87649e4d827d65
Author: Stefan Richter <stefanr@s5r6.in-berlin.de>
Date:   Sun Jan 29 12:41:15 2012 +0100

    firewire: ohci: disable MSI on Ricoh controllers
    
    commit 320cfa6ce0b3dc794fedfa4bae54c0f65077234d upstream.
    
    The PCIe device
    
        FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd FireWire Host Controller
        [1180:e832] (prog-if 10 [OHCI])
    
    is unable to access attached FireWire devices when MSI is enabled but
    works if MSI is disabled.
    http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28251.html
    
    Hence add the "disable MSI" quirks flag for this device, or in fact for
    safety and simplicity for all current (R5U230, R5U231, R5U240) and
    future Ricoh PCIe 1394 controllers.
    
    Reported-by: Stefan Thomas <kontrapunktstefan@googlemail.com>
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49b7e22b82d73e58a5335820b3f0441b2606515b
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Thu Jan 26 22:05:58 2012 +0100

    firewire: ohci: add reset packet quirk for SB Audigy
    
    commit d1bb399ad03c11e792f6dea198d3b1e23061f094 upstream.
    
    The Audigy's SB1394 controller is actually from Texas Instruments
    and has the same bus reset packet generation bug, so it needs the
    same quirk entry.
    
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 43904e95ba660b59db5899a4d58a00e4ac4d3663
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Tue Jan 31 17:15:11 2012 +0100

    proc: make sure mem_open() doesn't pin the target's memory
    
    commit 6d08f2c7139790c268820a2e590795cb8333181a upstream.
    
    Once /proc/pid/mem is opened, the memory can't be released until
    mem_release() even if its owner exits.
    
    Change mem_open() to do atomic_inc(mm_count) + mmput(), this only
    pins mm_struct. Change mem_rw() to do atomic_inc_not_zero(mm_count)
    before access_remote_vm(), this verifies that this mm is still alive.
    
    I am not sure what should mem_rw() return if atomic_inc_not_zero()
    fails. With this patch it returns zero to match the "mm == NULL" case,
    may be it should return -EINVAL like it did before e268337d.
    
    Perhaps it makes sense to add the additional fatal_signal_pending()
    check into the main loop, to ensure we do not hold this memory if
    the target task was oom-killed.
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 034089b6f4e2ae0d0df38f3409cd73c386ad069a
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Tue Jan 31 17:14:54 2012 +0100

    proc: unify mem_read() and mem_write()
    
    commit 572d34b946bae070debd42db1143034d9687e13f upstream.
    
    No functional changes, cleanup and preparation.
    
    mem_read() and mem_write() are very similar. Move this code into the
    new common helper, mem_rw(), which takes the additional "int write"
    argument.
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a196fbe2650a4465d49f6e84d9360eab60e3bcb
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Tue Jan 31 17:14:38 2012 +0100

    proc: mem_release() should check mm != NULL
    
    commit 71879d3cb3dd8f2dfdefb252775c1b3ea04a3dd4 upstream.
    
    mem_release() can hit mm == NULL, add the necessary check.
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58f75a56e37352b7dea174ee75f2ca52218370a7
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date:   Fri Feb 3 15:37:15 2012 -0800

    drivers/tty/vt/vt_ioctl.c: fix KDFONTOP 32bit compatibility layer
    
    commit cbcb8346054073d000ecac324763372d6abd44ac upstream.
    
    KDFONTOP(GET) currently fails with EIO when being run in a 32bit userland
    with a 64bit kernel if the font width is not 8.
    
    This is because of the setting of the KD_FONT_FLAG_OLD flag, which makes
    con_font_get return EIO in such case.
    
    This flag should *not* be set for KDFONTOP, since it's actually the whole
    point of this flag (see comment in con_font_set for instance).
    
    Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Arthur Taylor <art@ified.ca>
    Cc: Jiri Slaby <jslaby@suse.cz>
    Cc: Jiri Olsa <jolsa@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 04712489fde65768a46fa4a4b240fff446c17aa6
Author: Yegor Yefremov <yegor_sub1@visionsystems.de>
Date:   Mon Jan 23 08:32:23 2012 +0100

    ARM: OMAP2+: GPMC: fix device size setup
    
    commit 8ef5d844cc3a644ea6f7665932a4307e9fad01fa upstream.
    
    following statement can only change device size from 8-bit(0) to 16-bit(1),
    but not vice versa:
    
    regval |= GPMC_CONFIG1_DEVICESIZE(wval);
    
    so as this field has 1 reserved bit, that could be used in future,
    just clear both bits and then OR with the desired value
    
    Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a4e4a6ee0cc6e069926d006b7a6efd73d33edfcc
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon Jan 30 20:23:29 2012 +0100

    ARM: 7308/1: vfp: flush thread hwstate before copying ptrace registers
    
    commit 8130b9d7b9d858aa04ce67805e8951e3cb6e9b2f upstream.
    
    If we are context switched whilst copying into a thread's
    vfp_hard_struct then the partial copy may be corrupted by the VFP
    context switching code (see "ARM: vfp: flush thread hwstate before
    restoring context from sigframe").
    
    This patch updates the ptrace VFP set code so that the thread state is
    flushed before the copy, therefore disabling VFP and preventing
    corruption from occurring.
    
    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 c85ca4cdfafaee9fd428b934fea18e5c2d850fb6
Author: Dave Martin <dave.martin@linaro.org>
Date:   Mon Jan 30 20:22:28 2012 +0100

    ARM: 7307/1: vfp: fix ptrace regset modification race
    
    commit 247f4993a5974e6759606c4d380748eecfd273ff upstream.
    
    In a preemptible kernel, vfp_set() can be preempted, causing the
    hardware VFP context to be switched while the thread vfp state is
    being read and modified.  This leads to a race condition which can
    cause the thread vfp state to become corrupted if lazy VFP context
    save occurs due to preemption in between the time thread->vfpstate
    is read and the time the modified state is written back.
    
    This may occur if preemption occurs during the execution of a
    ptrace() call which modifies the VFP register state of a thread.
    Such instances should be very rare in most realistic scenarios --
    none has been reported, so far as I am aware.  Only uniprocessor
    systems should be affected, since VFP context save is not currently
    lazy in SMP kernels.
    
    The problem was introduced by my earlier patch migrating to use
    regsets to implement ptrace.
    
    This patch does a vfp_sync_hwstate() before reading
    thread->vfpstate, to make sure that the thread's VFP state is not
    live in the hardware registers while the registers are modified.
    
    Thanks to Will Deacon for spotting this.
    
    Signed-off-by: Dave Martin <dave.martin@linaro.org>
    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 04c6e8a2521ffa7049aa6df835d48d4bfce37a8e
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon Jan 30 20:21:42 2012 +0100

    ARM: 7306/1: vfp: flush thread hwstate before restoring context from sigframe
    
    commit 2af276dfb1722e97b190bd2e646b079a2aa674db upstream.
    
    Following execution of a signal handler, we currently restore the VFP
    context from the ucontext in the signal frame. This involves copying
    from the user stack into the current thread's vfp_hard_struct and then
    flushing the new data out to the hardware registers.
    
    This is problematic when using a preemptible kernel because we could be
    context switched whilst updating the vfp_hard_struct. If the current
    thread has made use of VFP since the last context switch, the VFP
    notifier will copy from the hardware registers into the vfp_hard_struct,
    overwriting any data that had been partially copied by the signal code.
    
    Disabling preemption across copy_from_user calls is a terrible idea, so
    instead we move the VFP thread flush *before* we update the
    vfp_hard_struct. Since the flushing is performed lazily, this has the
    effect of disabling VFP and clearing the CPU's VFP state pointer,
    therefore preventing the thread from being updated with stale data on
    the next context switch.
    
    Tested-by: Peter Maydell <peter.maydell@linaro.org>
    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 f886b09222d9ae6a977aa75e7b1e924fddca2d5f
Author: UK KIM <w0806.kim@samsung.com>
Date:   Sat Jan 28 01:52:22 2012 +0900

    ASoC: wm_hubs: fix wrong bits for LINEOUT2 N/P mixer
    
    commit 114395c61ad2eb5a7a5cd163fcadb2414e48245a upstream.
    
    Signed-off-by: UK KIM <w0806.kim@samsung.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e1a603295915f189e0b1b2207f5c9297ee65250
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Fri Jan 20 12:19:43 2012 +0000

    ASoC: wm_hubs: Enable line out VMID buffer for single ended line outputs
    
    commit 77231abe55433aa17eca712718745275853fa66d upstream.
    
    For optimal performance the single ended line outputs require that the
    line output VMID buffer be enabled.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e7c37777276bcae0ead904309644422bace8608
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Feb 2 10:30:17 2012 +0100

    ALSA: hda - Disable dynamic-power control for VIA as default
    
    commit b5bcc189401c815988b7dd37611fc56f40c9139d upstream.
    
    Since the dynamic pin power-control and the analog low-current mode
    may lead to pop-noise, it's safer to set it off as default.
    
    Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=741128
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b23a6ba81e42ad2d95afc04840d08b558092ba24
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Wed Feb 1 12:05:41 2012 +0100

    ALSA: HDA: Fix duplicated output to more than one codec
    
    commit 54c2a89f60fd71b924d0f848ac892442951401a6 upstream.
    
    This typo caused the wrong codec's nid to be checked for wcaps type.
    As a result, sometimes speakers would duplicate the output sent to
    HDMI output.
    
    BugLink: https://bugs.launchpad.net/bugs/924320
    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>

commit cb935a3a4ffa533491976365aa430ad9d586718f
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Feb 1 10:33:23 2012 +0100

    ALSA: hda - Allow analog low-current mode when dynamic power-control is on
    
    commit e9d010c2e8f03952e67a6fd8aed0f0dc92084ccc upstream.
    
    VIA codecs have several different power-saving features, and one of
    them is the analog low-current mode.  But it turned out that the ALC
    mode causes pop-noises at each on/off time on some machines.  As a
    quick workaround, disable the ALC when another power-saving feature,
    the dynamic pin power-control, is turned off, too, since the dynamic
    power-control is already exposed as a mixer enum element so that user
    can turn it on/off freely.
    
    Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=741128
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0f03303d8a9c7c82856c50e6c7ea137c8ca7c83
Author: Dylan Reid <dgreid@chromium.org>
Date:   Tue Jan 31 13:04:41 2012 -0800

    ALSA: hda - Fix calling cs_automic twice for Cirrus codecs.
    
    commit f70eecde3bca92630d3886496e73316ff353f185 upstream.
    
    If cs_automic is called twice (like it is during init) while the mic
    is present, it will over-write the last_input with the new one,
    causing it to switch back to the automic input when the mic is
    unplugged. This leaves the driver in a state (cur_input, last_input,
    and automix_idx the same) where the internal mic can not be selected
    until it is rebooted without the mic attached.
    
    Check that the mic hasn't already been switched to before setting
    last_input.
    
    Signed-off-by: Dylan Reid <dgreid@chromium.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f53e64f2effdcbd8f563411031fdc5172f876ce
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jan 30 10:54:08 2012 +0100

    ALSA: hda - Apply 0x0f-VREF fix to all ASUS laptops with ALC861/660
    
    commit 31150f2327cbb66363f38e13ca1be973d2f9203a upstream.
    
    It turned out that other ASUS laptops require the similar fix to
    enable the VREF on the pin 0x0f for the secret output amp, not only
    ASUS A6Rp.  Moreover, it's required even when the pin is being used
    as the output.  Thus, writing a fixed value doesn't work always.
    
    This patch applies the VREF-fix for all ASUS laptops with ALC861/660
    in a fixup function that checks the current value and turns on only
    the VREF value no matter whether input or output direction is set.
    
    The automute function is modified as well to keep the pin VREF upon
    muting/unmuting via pin-control; otherwise the pin VREF is reset at
    plugging/unplugging a jack.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42588
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab692dfced98f2967cf710941d686e66cf519afb
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Fri Jan 27 14:31:19 2012 +0100

    ALSA: HDA: Remove quirk for Asus N53Jq
    
    commit a389d67cf9849aff1722ed73186a584e2196a873 upstream.
    
    The user reports that he needs to add model=auto for audio to
    work properly. In fact, since node 0x15 is not even a pin node,
    the existing fixup is definitely wrong. Relevant information can
    be found in the buglink below.
    
    BugLink: https://bugs.launchpad.net/bugs/918254
    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>

commit 02e85499ffcb080ef11c8cc1b092e033f90651f5
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Jan 24 13:58:36 2012 +0100

    ALSA: hda - Fix the logic to detect VIA analog low-current mode
    
    commit 924339239fd5ba3e505f9420d41f0939196f3530 upstream.
    
    The analog low-current mode must be enabled when the no stream is
    running but the current detection checks it in a wrong way.
    
    Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=741128
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76af79f393ad562077f79627a4c719219ef09ee8
Author: Shaohua Li <shaohua.li@intel.com>
Date:   Fri Feb 3 15:37:17 2012 -0800

    readahead: fix pipeline break caused by block plug
    
    commit 3deaa7190a8da38453c4fabd9dec7f66d17fff67 upstream.
    
    Herbert Poetzl reported a performance regression since 2.6.39.  The test
    is a simple dd read, but with big block size.  The reason is:
    
    T1: ra (A, A+128k), (A+128k, A+256k)
    T2: lock_page for page A, submit the 256k
    T3: hit page A+128K, ra (A+256k, A+384). the range isn't submitted
    because of plug and there isn't any lock_page till we hit page A+256k
    because all pages from A to A+256k is in memory
    T4: hit page A+256k, ra (A+384, A+ 512). Because of plug, the range isn't
    submitted again.
    T5: lock_page A+256k, so (A+256k, A+512k) will be submitted. The task is
    waitting for (A+256k, A+512k) finish.
    
    There is no request to disk in T3 and T4, so readahead pipeline breaks.
    
    We really don't need block plug for generic_file_aio_read() for buffered
    I/O.  The readahead already has plug and has fine grained control when I/O
    should be submitted.  Deleting plug for buffered I/O fixes the regression.
    
    One side effect is plug makes the request size 256k, the size is 128k
    without it.  This is because default ra size is 128k and not a reason we
    need plug here.
    
    Vivek said:
    
    : We submit some readahead IO to device request queue but because of nested
    : plug, queue never gets unplugged.  When read logic reaches a page which is
    : not in page cache, it waits for page to be read from the disk
    : (lock_page_killable()) and that time we flush the plug list.
    :
    : So effectively read ahead logic is kind of broken in parts because of
    : nested plugging.  Removing top level plug (generic_file_aio_read()) for
    : buffered reads, will allow unplugging queue earlier for readahead.
    
    Signed-off-by: Shaohua Li <shaohua.li@intel.com>
    Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
    Reported-by: Herbert Poetzl <herbert@13thfloor.at>
    Tested-by: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Vivek Goyal <vgoyal@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>