commit 5d897eedc505bb8af1f4865ae381eadbfd3bc8c1
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue May 6 07:56:24 2014 -0700

    Linux 3.10.39

commit 6b32172a1d3cffa74067ced96612bd13658d4fcf
Author: Felipe Balbi <balbi@ti.com>
Date:   Tue Feb 25 10:58:43 2014 -0600

    usb: musb: avoid NULL pointer dereference
    
    commit eee3f15d5f1f4f0c283dd4db67dc1b874a2852d1 upstream.
    
    instead of relying on the otg pointer, which
    can be NULL in certain cases, we can use the
    gadget and host pointers we already hold inside
    struct musb.
    
    Tested-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0bf463e6229ba7d2da00acb72e0a25bce9447696
Author: Aaron Sanders <aaron.sanders@hp.com>
Date:   Mon Mar 31 15:54:21 2014 +0200

    USB: pl2303: add ids for Hewlett-Packard HP POS pole displays
    
    commit b16c02fbfb963fa2941b7517ebf1f8a21946775e upstream.
    
    Add device ids to pl2303 for the Hewlett-Packard HP POS pole displays:
    
    LD960: 03f0:0B39
    LCM220: 03f0:3139
    LCM960: 03f0:3239
    
    [ Johan: fix indentation and sort PIDs numerically ]
    
    Signed-off-by: Aaron Sanders <aaron.sanders@hp.com>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fcc742c294c9c189e7040a3de8528ac6f8ee13ef
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sat Apr 12 12:45:25 2014 -0400

    ext4: use i_size_read in ext4_unaligned_aio()
    
    commit 6e6358fc3c3c862bfe9a5bc029d3f8ce43dc9765 upstream.
    
    We haven't taken i_mutex yet, so we need to use i_size_read().
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f78e2d2db6082212ca85a25e9d51d0bd126cb0a8
Author: Jan Kara <jack@suse.cz>
Date:   Mon Apr 7 10:54:21 2014 -0400

    ext4: fix jbd2 warning under heavy xattr load
    
    commit ec4cb1aa2b7bae18dd8164f2e9c7c51abcf61280 upstream.
    
    When heavily exercising xattr code the assertion that
    jbd2_journal_dirty_metadata() shouldn't return error was triggered:
    
    WARNING: at /srv/autobuild-ceph/gitbuilder.git/build/fs/jbd2/transaction.c:1237
    jbd2_journal_dirty_metadata+0x1ba/0x260()
    
    CPU: 0 PID: 8877 Comm: ceph-osd Tainted: G    W 3.10.0-ceph-00049-g68d04c9 #1
    Hardware name: Dell Inc. PowerEdge R410/01V648, BIOS 1.6.3 02/07/2011
     ffffffff81a1d3c8 ffff880214469928 ffffffff816311b0 ffff880214469968
     ffffffff8103fae0 ffff880214469958 ffff880170a9dc30 ffff8802240fbe80
     0000000000000000 ffff88020b366000 ffff8802256e7510 ffff880214469978
    Call Trace:
     [<ffffffff816311b0>] dump_stack+0x19/0x1b
     [<ffffffff8103fae0>] warn_slowpath_common+0x70/0xa0
     [<ffffffff8103fb2a>] warn_slowpath_null+0x1a/0x20
     [<ffffffff81267c2a>] jbd2_journal_dirty_metadata+0x1ba/0x260
     [<ffffffff81245093>] __ext4_handle_dirty_metadata+0xa3/0x140
     [<ffffffff812561f3>] ext4_xattr_release_block+0x103/0x1f0
     [<ffffffff81256680>] ext4_xattr_block_set+0x1e0/0x910
     [<ffffffff8125795b>] ext4_xattr_set_handle+0x38b/0x4a0
     [<ffffffff810a319d>] ? trace_hardirqs_on+0xd/0x10
     [<ffffffff81257b32>] ext4_xattr_set+0xc2/0x140
     [<ffffffff81258547>] ext4_xattr_user_set+0x47/0x50
     [<ffffffff811935ce>] generic_setxattr+0x6e/0x90
     [<ffffffff81193ecb>] __vfs_setxattr_noperm+0x7b/0x1c0
     [<ffffffff811940d4>] vfs_setxattr+0xc4/0xd0
     [<ffffffff8119421e>] setxattr+0x13e/0x1e0
     [<ffffffff811719c7>] ? __sb_start_write+0xe7/0x1b0
     [<ffffffff8118f2e8>] ? mnt_want_write_file+0x28/0x60
     [<ffffffff8118c65c>] ? fget_light+0x3c/0x130
     [<ffffffff8118f2e8>] ? mnt_want_write_file+0x28/0x60
     [<ffffffff8118f1f8>] ? __mnt_want_write+0x58/0x70
     [<ffffffff811946be>] SyS_fsetxattr+0xbe/0x100
     [<ffffffff816407c2>] system_call_fastpath+0x16/0x1b
    
    The reason for the warning is that buffer_head passed into
    jbd2_journal_dirty_metadata() didn't have journal_head attached. This is
    caused by the following race of two ext4_xattr_release_block() calls:
    
    CPU1                                CPU2
    ext4_xattr_release_block()          ext4_xattr_release_block()
    lock_buffer(bh);
    /* False */
    if (BHDR(bh)->h_refcount == cpu_to_le32(1))
    } else {
      le32_add_cpu(&BHDR(bh)->h_refcount, -1);
      unlock_buffer(bh);
                                        lock_buffer(bh);
                                        /* True */
                                        if (BHDR(bh)->h_refcount == cpu_to_le32(1))
                                          get_bh(bh);
                                          ext4_free_blocks()
                                            ...
                                            jbd2_journal_forget()
                                              jbd2_journal_unfile_buffer()
                                              -> JH is gone
      error = ext4_handle_dirty_xattr_block(handle, inode, bh);
      -> triggers the warning
    
    We fix the problem by moving ext4_handle_dirty_xattr_block() under the
    buffer lock. Sadly this cannot be done in nojournal mode as that
    function can call sync_dirty_buffer() which would deadlock. Luckily in
    nojournal mode the race is harmless (we only dirty already freed buffer)
    and thus for nojournal mode we leave the dirtying outside of the buffer
    lock.
    
    Reported-by: Sage Weil <sage@inktank.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5da43e877ea4e51b1096a8973ff6e7a03554fcb0
Author: alex chen <alex.chen@huawei.com>
Date:   Thu Apr 3 14:47:05 2014 -0700

    ocfs2: do not put bh when buffer_uptodate failed
    
    commit f7cf4f5bfe073ad792ab49c04f247626b3e38db6 upstream.
    
    Do not put bh when buffer_uptodate failed in ocfs2_write_block and
    ocfs2_write_super_or_backup, because it will put bh in b_end_io.
    Otherwise it will hit a warning "VFS: brelse: Trying to free free
    buffer".
    
    Signed-off-by: Alex Chen <alex.chen@huawei.com>
    Reviewed-by: Joseph Qi <joseph.qi@huawei.com>
    Reviewed-by: Srinivas Eeda <srinivas.eeda@oracle.com>
    Cc: Mark Fasheh <mfasheh@suse.com>
    Acked-by: Joel Becker <jlbec@evilplan.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a093bceda6927de680e1c16793c5dfc4df3d236f
Author: Junxiao Bi <junxiao.bi@oracle.com>
Date:   Thu Apr 3 14:46:51 2014 -0700

    ocfs2: dlm: fix recovery hung
    
    commit ded2cf71419b9353060e633b59e446c42a6a2a09 upstream.
    
    There is a race window in dlm_do_recovery() between dlm_remaster_locks()
    and dlm_reset_recovery() when the recovery master nearly finish the
    recovery process for a dead node.  After the master sends FINALIZE_RECO
    message in dlm_remaster_locks(), another node may become the recovery
    master for another dead node, and then send the BEGIN_RECO message to
    all the nodes included the old master, in the handler of this message
    dlm_begin_reco_handler() of old master, dlm->reco.dead_node and
    dlm->reco.new_master will be set to the second dead node and the new
    master, then in dlm_reset_recovery(), these two variables will be reset
    to default value.  This will cause new recovery master can not finish
    the recovery process and hung, at last the whole cluster will hung for
    recovery.
    
    old recovery master:                                 new recovery master:
    dlm_remaster_locks()
                                                      become recovery master for
                                                      another dead node.
                                                      dlm_send_begin_reco_message()
    dlm_begin_reco_handler()
    {
     if (dlm->reco.state & DLM_RECO_STATE_FINALIZE) {
      return -EAGAIN;
     }
     dlm_set_reco_master(dlm, br->node_idx);
     dlm_set_reco_dead_node(dlm, br->dead_node);
    }
    dlm_reset_recovery()
    {
     dlm_set_reco_dead_node(dlm, O2NM_INVALID_NODE_NUM);
     dlm_set_reco_master(dlm, O2NM_INVALID_NODE_NUM);
    }
                                                      will hang in dlm_remaster_locks() for
                                                      request dlm locks info
    
    Before send FINALIZE_RECO message, recovery master should set
    DLM_RECO_STATE_FINALIZE for itself and clear it after the recovery done,
    this can break the race windows as the BEGIN_RECO messages will not be
    handled before DLM_RECO_STATE_FINALIZE flag is cleared.
    
    A similar race may happen between new recovery master and normal node
    which is in dlm_finalize_reco_handler(), also fix it.
    
    Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
    Reviewed-by: Srinivas Eeda <srinivas.eeda@oracle.com>
    Reviewed-by: Wengang Wang <wen.gang.wang@oracle.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Mark Fasheh <mfasheh@suse.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 261985c4398c6658e057842ba6c960c74f796d00
Author: Junxiao Bi <junxiao.bi@oracle.com>
Date:   Thu Apr 3 14:46:49 2014 -0700

    ocfs2: dlm: fix lock migration crash
    
    commit 34aa8dac482f1358d59110d5e3a12f4351f6acaa upstream.
    
    This issue was introduced by commit 800deef3f6f8 ("ocfs2: use
    list_for_each_entry where benefical") in 2007 where it replaced
    list_for_each with list_for_each_entry.  The variable "lock" will point
    to invalid data if "tmpq" list is empty and a panic will be triggered
    due to this.  Sunil advised reverting it back, but the old version was
    also not right.  At the end of the outer for loop, that
    list_for_each_entry will also set "lock" to an invalid data, then in the
    next loop, if the "tmpq" list is empty, "lock" will be an stale invalid
    data and cause the panic.  So reverting the list_for_each back and reset
    "lock" to NULL to fix this issue.
    
    Another concern is that this seemes can not happen because the "tmpq"
    list should not be empty.  Let me describe how.
    
    old lock resource owner(node 1):                                  migratation target(node 2):
    image there's lockres with a EX lock from node 2 in
    granted list, a NR lock from node x with convert_type
    EX in converting list.
    dlm_empty_lockres() {
     dlm_pick_migration_target() {
       pick node 2 as target as its lock is the first one
       in granted list.
     }
     dlm_migrate_lockres() {
       dlm_mark_lockres_migrating() {
         res->state |= DLM_LOCK_RES_BLOCK_DIRTY;
         wait_event(dlm->ast_wq, !dlm_lockres_is_dirty(dlm, res));
    	 //after the above code, we can not dirty lockres any more,
         // so dlm_thread shuffle list will not run
                                                                       downconvert lock from EX to NR
                                                                       upconvert lock from NR to EX
    <<< migration may schedule out here, then
    <<< node 2 send down convert request to convert type from EX to
    <<< NR, then send up convert request to convert type from NR to
    <<< EX, at this time, lockres granted list is empty, and two locks
    <<< in the converting list, node x up convert lock followed by
    <<< node 2 up convert lock.
    
    	 // will set lockres RES_MIGRATING flag, the following
    	 // lock/unlock can not run
         dlm_lockres_release_ast(dlm, res);
       }
    
       dlm_send_one_lockres()
                                                                     dlm_process_recovery_data()
                                                                       for (i=0; i<mres->num_locks; i++)
                                                                         if (ml->node == dlm->node_num)
                                                                           for (j = DLM_GRANTED_LIST; j <= DLM_BLOCKED_LIST; j++) {
                                                                            list_for_each_entry(lock, tmpq, list)
                                                                            if (lock) break; <<< lock is invalid as grant list is empty.
                                                                           }
                                                                           if (lock->ml.node != ml->node)
                                                                             BUG() >>> crash here
     }
    
    I see the above locks status from a vmcore of our internal bug.
    
    Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
    Reviewed-by: Wengang Wang <wen.gang.wang@oracle.com>
    Cc: Sunil Mushran <sunil.mushran@gmail.com>
    Reviewed-by: Srinivas Eeda <srinivas.eeda@oracle.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Mark Fasheh <mfasheh@suse.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 82c647cbfc1f77afbaa199f8fe14a186eaa1bfe1
Author: Liu Hua <sdu.liu@huawei.com>
Date:   Mon Apr 7 15:38:57 2014 -0700

    hung_task: check the value of "sysctl_hung_task_timeout_sec"
    
    commit 80df28476505ed4e6701c3448c63c9229a50c655 upstream.
    
    As sysctl_hung_task_timeout_sec is unsigned long, when this value is
    larger then LONG_MAX/HZ, the function schedule_timeout_interruptible in
    watchdog will return immediately without sleep and with print :
    
      schedule_timeout: wrong timeout value ffffffffffffff83
    
    and then the funtion watchdog will call schedule_timeout_interruptible
    again and again.  The screen will be filled with
    
    	"schedule_timeout: wrong timeout value ffffffffffffff83"
    
    This patch does some check and correction in sysctl, to let the function
    schedule_timeout_interruptible allways get the valid parameter.
    
    Signed-off-by: Liu Hua <sdu.liu@huawei.com>
    Tested-by: Satoru Takeuchi <satoru.takeuchi@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 733ad2dce4d6aff1a74529b73aea0434cabfb224
Author: Mizuma, Masayoshi <m.mizuma@jp.fujitsu.com>
Date:   Mon Apr 7 15:37:54 2014 -0700

    mm: hugetlb: fix softlockup when a large number of hugepages are freed.
    
    commit 55f67141a8927b2be3e51840da37b8a2320143ed upstream.
    
    When I decrease the value of nr_hugepage in procfs a lot, softlockup
    happens.  It is because there is no chance of context switch during this
    process.
    
    On the other hand, when I allocate a large number of hugepages, there is
    some chance of context switch.  Hence softlockup doesn't happen during
    this process.  So it's necessary to add the context switch in the
    freeing process as same as allocating process to avoid softlockup.
    
    When I freed 12 TB hugapages with kernel-2.6.32-358.el6, the freeing
    process occupied a CPU over 150 seconds and following softlockup message
    appeared twice or more.
    
    $ echo 6000000 > /proc/sys/vm/nr_hugepages
    $ cat /proc/sys/vm/nr_hugepages
    6000000
    $ grep ^Huge /proc/meminfo
    HugePages_Total:   6000000
    HugePages_Free:    6000000
    HugePages_Rsvd:        0
    HugePages_Surp:        0
    Hugepagesize:       2048 kB
    $ echo 0 > /proc/sys/vm/nr_hugepages
    
    BUG: soft lockup - CPU#16 stuck for 67s! [sh:12883] ...
    Pid: 12883, comm: sh Not tainted 2.6.32-358.el6.x86_64 #1
    Call Trace:
      free_pool_huge_page+0xb8/0xd0
      set_max_huge_pages+0x128/0x190
      hugetlb_sysctl_handler_common+0x113/0x140
      hugetlb_sysctl_handler+0x1e/0x20
      proc_sys_call_handler+0x97/0xd0
      proc_sys_write+0x14/0x20
      vfs_write+0xb8/0x1a0
      sys_write+0x51/0x90
      __audit_syscall_exit+0x265/0x290
      system_call_fastpath+0x16/0x1b
    
    I have not confirmed this problem with upstream kernels because I am not
    able to prepare the machine equipped with 12TB memory now.  However I
    confirmed that the amount of decreasing hugepages was directly
    proportional to the amount of required time.
    
    I measured required times on a smaller machine.  It showed 130-145
    hugepages decreased in a millisecond.
    
      Amount of decreasing     Required time      Decreasing rate
      hugepages                     (msec)         (pages/msec)
      ------------------------------------------------------------
      10,000 pages == 20GB         70 -  74          135-142
      30,000 pages == 60GB        208 - 229          131-144
    
    It means decrement of 6TB hugepages will trigger softlockup with the
    default threshold 20sec, in this decreasing rate.
    
    Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
    Cc: Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.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 77552735ba84a410447af7e3375625eb4cfd577b
Author: Vlastimil Babka <vbabka@suse.cz>
Date:   Mon Apr 7 15:37:50 2014 -0700

    mm: try_to_unmap_cluster() should lock_page() before mlocking
    
    commit 57e68e9cd65b4b8eb4045a1e0d0746458502554c upstream.
    
    A BUG_ON(!PageLocked) was triggered in mlock_vma_page() by Sasha Levin
    fuzzing with trinity.  The call site try_to_unmap_cluster() does not lock
    the pages other than its check_page parameter (which is already locked).
    
    The BUG_ON in mlock_vma_page() is not documented and its purpose is
    somewhat unclear, but apparently it serializes against page migration,
    which could otherwise fail to transfer the PG_mlocked flag.  This would
    not be fatal, as the page would be eventually encountered again, but
    NR_MLOCK accounting would become distorted nevertheless.  This patch adds
    a comment to the BUG_ON in mlock_vma_page() and munlock_vma_page() to that
    effect.
    
    The call site try_to_unmap_cluster() is fixed so that for page !=
    check_page, trylock_page() is attempted (to avoid possible deadlocks as we
    already have check_page locked) and mlock_vma_page() is performed only
    upon success.  If the page lock cannot be obtained, the page is left
    without PG_mlocked, which is again not a problem in the whole unevictable
    memory design.
    
    Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
    Signed-off-by: Bob Liu <bob.liu@oracle.com>
    Reported-by: Sasha Levin <sasha.levin@oracle.com>
    Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
    Cc: Michel Lespinasse <walken@google.com>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Acked-by: Rik van Riel <riel@redhat.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.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 9e9c7bb4839e7de12a08d6e6145e73dad351c1ba
Author: Matt Fleming <matt.fleming@intel.com>
Date:   Thu Apr 3 14:46:20 2014 -0700

    sh: fix format string bug in stack tracer
    
    commit a0c32761e73c9999cbf592b702f284221fea8040 upstream.
    
    Kees reported the following error:
    
       arch/sh/kernel/dumpstack.c: In function 'print_trace_address':
       arch/sh/kernel/dumpstack.c:118:2: error: format not a string literal and no format arguments [-Werror=format-security]
    
    Use the "%s" format so that it's impossible to interpret 'data' as a
    format string.
    
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Reported-by: Kees Cook <keescook@chromium.org>
    Acked-by: Kees Cook <keescook@chromium.org>
    Cc: Paul Mundt <lethal@linux-sh.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 981752df71cfdab8096cb44a76a9b597cdde8796
Author: Felipe Franciosi <felipe@paradoxo.org>
Date:   Thu Mar 13 14:34:20 2014 +0000

    mtip32xx: Set queue bounce limit
    
    commit 1044b1bb9278f2e656a1a7b63dc24a59506540aa upstream.
    
    We need to set the queue bounce limit during the device initialization to
    prevent excessive bouncing on 32 bit architectures.
    
    Signed-off-by: Felipe Franciosi <felipe@paradoxo.org>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59f0103d74e4a32cbaa054d5011ea287fcfb83e4
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed Mar 12 11:30:38 2014 -0400

    USB: unbind all interfaces before rebinding any
    
    commit 6aec044cc2f5670cf3b143c151c8be846499bd15 upstream.
    
    When a driver doesn't have pre_reset, post_reset, or reset_resume
    methods, the USB core unbinds that driver when its device undergoes a
    reset or a reset-resume, and then rebinds it afterward.
    
    The existing straightforward implementation can lead to problems,
    because each interface gets unbound and rebound before the next
    interface is handled.  If a driver claims additional interfaces, the
    claim may fail because the old binding instance may still own the
    additional interface when the new instance tries to claim it.
    
    This patch fixes the problem by first unbinding all the interfaces
    that are marked (i.e., their needs_binding flag is set) and then
    rebinding all of them.
    
    The patch also makes the helper functions in driver.c a little more
    uniform and adjusts some out-of-date comments.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-and-tested-by: "Poulain, Loic" <loic.poulain@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe7f9f59b73a98cff0e62468cb3697a0dec593ff
Author: Michal Simek <michal.simek@xilinx.com>
Date:   Tue Mar 11 13:23:14 2014 +0100

    usb: phy: Add ulpi IDs for SMSC USB3320 and TI TUSB1210
    
    commit ead5178bf442dbae4008ee54bf4f66a1f6a317c9 upstream.
    
    Add new ulpi IDs which are available on Xilinx Zynq boards.
    
    Signed-off-by: Michal Simek <michal.simek@xilinx.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94804de8045ecc8a0a1d33f9dd7b9eb199eaa699
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Tue Jan 14 16:03:37 2014 -0500

    hvc: ensure hvc_init is only ever called once in hvc_console.c
    
    commit f76a1cbed18c86e2d192455f0daebb48458965f3 upstream.
    
    Commit 3e6c6f630a5282df8f3393a59f10eb9c56536d23 ("Delay creation of
    khcvd thread") moved the call of hvc_init from being a device_initcall
    into hvc_alloc, and used a non-null hvc_driver as indication of whether
    hvc_init had already been called.
    
    The problem with this is that hvc_driver is only assigned a value
    at the bottom of hvc_init, and so there is a window where multiple
    hvc_alloc calls can be in progress at the same time and hence try
    and call hvc_init multiple times.  Previously the use of device_init
    guaranteed that hvc_init was only called once.
    
    This manifests itself as sporadic instances of two hvc_init calls
    racing each other, and with the loser of the race getting -EBUSY
    from tty_register_driver() and hence that virtual console fails:
    
        Couldn't register hvc console driver
        virtio-ports vport0p1: error -16 allocating hvc for port
    
    Here we add an atomic_t to guarantee we'll never run hvc_init twice.
    
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Fixes: 3e6c6f630a52 ("Delay creation of khcvd thread")
    Reported-by: Jim Somerville <Jim.Somerville@windriver.com>
    Tested-by: Jim Somerville <Jim.Somerville@windriver.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aede1b94f8ec9bb95d2963ef7881195041c9bf12
Author: Huang Rui <ray.huang@amd.com>
Date:   Tue Jan 7 17:45:50 2014 +0800

    usb: dwc3: fix wrong bit mask in dwc3_event_devt
    
    commit 06f9b6e59661cee510b04513b13ea7927727d758 upstream.
    
    Around DWC USB3 2.30a release another bit has been added to the
    Device-Specific Event (DEVT) Event Information (EvtInfo) bitfield.
    
    Because of that, what used to be 8 bits long, has become 9 bits long.
    
    Per dwc3 2.30a+ spec in the Device-Specific Event (DEVT), the field of
    Event Information Bits(EvtInfo) uses [24:16] bits, and it has 9 bits
    not 8 bits. And the following reserved field uses [31:25] bits not
    [31:24] bits, and it has 7 bits.
    
    So in dwc3_event_devt, the bit mask should be:
    event_info	[24:16]		9 bits
    reserved31_25	[31:25]		7 bits
    
    This patch makes sure that newer core releases will work fine with
    Linux and that we will decode the event information properly on new
    core releases.
    
    [ balbi@ti.com : improve commit log a bit ]
    
    Signed-off-by: Huang Rui <ray.huang@amd.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fdb8dd78feec765217e544972e17e1ce3fe9867
Author: Wolfram Sang <wsa@the-dreams.de>
Date:   Sat Feb 1 15:26:00 2014 -0300

    media: media: gspca: sn9c20x: add ID for Genius Look 1320 V2
    
    commit 61f0319193c44adbbada920162d880b1fdb3aeb3 upstream.
    
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe529a27f1970b373662c175d789e842d418a1b8
Author: Florian Vaussard <florian.vaussard@epfl.ch>
Date:   Fri Jan 17 16:37:38 2014 -0300

    media: omap3isp: preview: Fix the crop margins
    
    commit 8b57b9669aa884ac75b8d09c251d6b1755533c15 upstream.
    
    Commit 3fdfedaaa "[media] omap3isp: preview: Lower the crop margins"
    accidentally changed the previewer's cropping, causing the previewer
    to miss four pixels on each line, thus corrupting the final image.
    Restored the removed setting.
    
    Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6671cbfc06a126f21db1c1c3c7b38b9de2a0bfbf
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Fri Mar 7 07:28:39 2014 -0300

    media: saa7134: fix WARN_ON during resume
    
    commit 30d652823de5fd7907d40e969a2d8e23938d8d03 upstream.
    
    Do not attempt to reload the tuner modules when resuming after a suspend.
    This triggers a WARN_ON in kernel/kmod.c:148 __request_module.
    
    This fixes https://bugzilla.kernel.org/show_bug.cgi?id=69581.
    
    This has always been wrong, but it was never noticed until the WARN_ON
    was added in 3.9.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 57b03c6ecd650b3ae30df07a2fb856768fb26814
Author: Antti Palosaari <crope@iki.fi>
Date:   Tue Mar 11 06:53:16 2014 -0300

    media: em28xx: fix PCTV 290e LNA oops
    
    commit 3ec40dcfb413214b2874aec858870502b61c2202 upstream.
    
    Pointer to device state has been moved to different location during
    some change. PCTV 290e LNA function still uses old pointer, carried
    over FE priv, and it crash.
    
    Reported-by: Janne Kujanpää <jikuja@iki.fi>
    Signed-off-by: Antti Palosaari <crope@iki.fi>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 367a2661476f7f07087f6631db1072c3474f7e18
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Tue Feb 25 23:05:39 2014 -0300

    media: m88rs2000: add caps FE_CAN_INVERSION_AUTO
    
    commit 3c8023a782964c72574ad8268ba0ea4e2d9772fc upstream.
    
    The m88rs2000 frontend is always auto inversion.
    
    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
    Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e180b9ebca26bd4876cf87d3476f0e292d352e5
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Tue Feb 25 23:11:34 2014 -0300

    media: m88rs2000: prevent frontend crash on continuous transponder scans
    
    commit 8272d0a0c0d374a01721e579df6e8add5577132b upstream.
    
    Add m88rs2000_get_tune_settings, min delay of 2000 ms on symbol
    rate more than 3000000 and delay of 3000ms less than this.
    
    Adding min delay prevents crashing the frontend on continuous
    transponder scans. Other dvb_frontend_tune_settings remain as default.
    
    This makes very little time difference to good channel scans, but slows down
    the set frontend where lock can never be achieved i.e. DVB-S2.
    
    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
    Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6cc25a18566d8f7f594b4c370dac9f5be444ade8
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Thu Mar 6 07:24:21 2014 -0300

    media: v4l2-compat-ioctl32: fix wrong VIDIOC_SUBDEV_G/S_EDID32 support
    
    commit bc826d6e39fe5f09cbadf8723e9183e6331b586f upstream.
    
    The wrong ioctl numbers were used due to a copy-and-paste error.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 63e3c3d7bef11c917646fb6babb81c72d0aa4949
Author: Oleksij Rempel <linux@rempel-privat.de>
Date:   Sun Feb 16 06:59:32 2014 -0300

    media: uvcvideo: Do not use usb_set_interface on bulk EP
    
    commit b1e43f232698274871e1358c276d7b0242a7d607 upstream.
    
    The UVC specification uses alternate setting selection to notify devices
    of stream start/stop. This breaks when using bulk-based devices, as the
    video streaming interface has a single alternate setting in that case,
    making video stream start and video stream stop events to appear
    identical to the device. Bulk-based devices are thus not well supported
    by UVC.
    
    The webcam built in the Asus Zenbook UX302LA ignores the set interface
    request and will keep the video stream enabled when the driver tries to
    stop it. If USB autosuspend is enabled the device will then be suspended
    and will crash, requiring a cold reboot.
    
    USB trace capture showed that Windows sends a CLEAR_FEATURE(HALT)
    request to the bulk endpoint when stopping the stream instead of
    selecting alternate setting 0. The camera then behaves correctly, and
    thus seems to require that behaviour.
    
    Replace selection of alternate setting 0 with clearing of the endpoint
    halt feature at video stream stop for bulk-based devices. Let's refrain
    from blaming Microsoft this time, as it's not clear whether this
    Windows-specific but USB-compliant behaviour was specifically developed
    to handle bulkd-based UVC devices, or if the camera just took advantage
    of it.
    
    Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65cadc88d143361a60951b01ae32ec6b9bc88f6b
Author: David Cohen <david.a.cohen@linux.intel.com>
Date:   Fri Apr 25 19:20:16 2014 +0300

    usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM
    
    commit 01bb59ebffdec314da8da66266edf29529372f9b upstream.
    
    When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this
    warning:
    drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined
    but not used [-Wunused-function]
    
    Instead of creating nested #ifdefs, this patch fixes it by defining the
    xHCI PCI stubs as inline.
    
    This warning has been in since 3.2 kernel and was
    caused by commit 421aa841a134f6a743111cf44d0c6d3b45e3cf8c
    "usb/xhci: hide MSI code behind PCI bars", but wasn't noticed
    until 3.13 when a configuration with these options was tried
    
    Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f21d92c460ac39d93559a8bb330066ab9d2d2241
Author: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Date:   Fri Apr 25 19:20:15 2014 +0300

    xhci: extend quirk for Renesas cards
    
    commit 6db249ebefc6bf5c39f35dfaacc046d8ad3ffd70 upstream.
    
    After suspend another Renesas PCI-X USB 3.0 card doesn't work.
    [root@fedora-20 ~]# lspci -vmnnd 1912:
    Device:	03:00.0
    Class:	USB controller [0c03]
    Vendor:	Renesas Technology Corp. [1912]
    Device:	uPD720202 USB 3.0 Host Controller [0015]
    SVendor:	Renesas Technology Corp. [1912]
    SDevice:	uPD720202 USB 3.0 Host Controller [0015]
    Rev:	02
    ProgIf:	30
    
    This patch should be applied to stable kernel 3.14 that contain
    the commit 1aa9578c1a9450fb21501c4f549f5b1edb557e6d
    "xhci: Fix resume issues on Renesas chips in Samsung laptops"
    
    Reported-and-tested-by: Anatoly Kharchenko <rfr-bugs@yandex.ru>
    Reference: http://redmine.russianfedora.pro/issues/1315
    Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 57ff245ed313d593eeb5321501cd4183d1935b14
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Mar 3 19:30:17 2014 +0200

    xhci: Prevent runtime pm from autosuspending during initialization
    
    commit bcffae7708eb8352f44dc510b326541fe43a02a4 upstream.
    
    xHCI driver has its own pci probe function that will call usb_hcd_pci_probe
    to register its usb-2 bus, and then continue to manually register the
    usb-3 bus. usb_hcd_pci_probe does a pm_runtime_put_noidle at the end and
    might thus trigger a runtime suspend before the usb-3 bus is ready.
    
    Prevent the runtime suspend by increasing the usage count in the
    beginning of xhci_pci_probe, and decrease it once the usb-3 bus is
    ready.
    
    xhci-platform driver is not using usb_hcd_pci_probe to set up
    busses and should not need to have it's usage count increased during probe.
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Acked-by: Dan Williams <dan.j.williams@intel.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 261313c0d8de2c4533cfafaa0571dc88b5fb62d7
Author: Roger Quadros <rogerq@ti.com>
Date:   Wed Mar 26 18:46:38 2014 +0200

    usb: gadget: zero: Fix SuperSpeed enumeration for alternate setting 1
    
    commit 9c1b70361e0b38e4acb8e62b54da66538cb77ff2 upstream.
    
    It was impossible to enumerate on a SuperSpeed (XHCI) host
    with alternate setting = 1 due to the wrongly set 'bMaxBurst'
    field in the SuperSpeed Endpoint Companion descriptor.
    
    Testcase:
    <host> modprobe -r usbtest; modprobe usbtest alt=1
    <device> modprobe g_zero
    plug device to SuperSpeed port on the host.
    
    Without this patch the host always complains like so
    "usb 12-2: Not enough bandwidth for new device state.
     usb 12-2: Not enough bandwidth for altsetting 1"
    
    Bug was introduced by commit cf9a08ae in v3.9
    
    Fixes: cf9a08ae5aec (usb: gadget: convert source sink and loopback to
    new function interface)
    
    Reviewed-by: Felipe Balbi <balbi@ti.com>
    Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Roger Quadros <rogerq@ti.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc363768acb132a959ccf86fa2ea303862113c07
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Mar 11 13:26:16 2014 -0700

    usb: gadget: tcm_usb_gadget: stop format strings
    
    commit aba37fd975f0dd58e025c99c2a79b61b20190831 upstream.
    
    This makes sure that the name coming out of configfs cannot be used
    accidentally as a format string.
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d06be05aadf7f66d8415f8e803a28495082dcfe
Author: Jeff Mahoney <jeffm@suse.com>
Date:   Wed Apr 2 14:40:26 2014 -0400

    reiserfs: fix race in readdir
    
    commit 01d8885785a60ae8f4c37b0ed75bdc96d0fc6a44 upstream.
    
    jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-2)
    
    The -ENOENT is due to readdir calling dir_emit on the same entry twice.
    
    If the dir_emit callback sleeps and the tree is changed underneath us,
    we won't be able to trust deh_offset(deh) anymore. We need to save
    next_pos before we might sleep so we can find the next entry.
    
    Signed-off-by: Jeff Mahoney <jeffm@suse.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35d5134b7d5a55e269c953096224248b9f6f72c2
Author: Matt Fleming <matt@console-pimps.org>
Date:   Tue Apr 8 13:14:00 2014 +0100

    x86/efi: Correct EFI boot stub use of code32_start
    
    commit 7e8213c1f3acc064aef37813a39f13cbfe7c3ce7 upstream.
    
    code32_start should point at the start of the protected mode code, and
    *not* at the beginning of the bzImage. This is much easier to do in
    assembly so document that callers of make_boot_params() need to fill out
    code32_start.
    
    The fallout from this bug is that we would end up relocating the image
    but copying the image at some offset, resulting in what appeared to be
    memory corruption.
    
    Reported-by: Thomas Bächler <thomas@archlinux.org>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e2dcd00681f852c1cb1864f79e9992ea1b5981f
Author: Andy Grover <agrover@redhat.com>
Date:   Fri Apr 4 16:44:37 2014 -0700

    target/tcm_fc: Fix use-after-free of ft_tpg
    
    commit 2c42be2dd4f6586728dba5c4e197afd5cfaded78 upstream.
    
    ft_del_tpg checks tpg->tport is set before unlinking the tpg from the
    tport when the tpg is being removed. Set this pointer in ft_tport_create,
    or the unlinking won't happen in ft_del_tpg and tport->tpg will reference
    a deleted object.
    
    This patch sets tpg->tport in ft_tport_create, because that's what
    ft_del_tpg checks, and is the only way to get back to the tport to
    clear tport->tpg.
    
    The bug was occuring when:
    
    - lport created, tport (our per-lport, per-provider context) is
      allocated.
      tport->tpg = NULL
    - tpg created
    - a PRLI is received. ft_tport_create is called, tpg is found and
      tport->tpg is set
    - tpg removed. ft_tpg is freed in ft_del_tpg. Since tpg->tport was not
      set, tport->tpg is not cleared and points at freed memory
    - Future calls to ft_tport_create return tport via first conditional,
      instead of searching for new tpg by calling ft_lport_find_tpg.
      tport->tpg is still invalid, and will access freed memory.
    
    see https://bugzilla.redhat.com/show_bug.cgi?id=1071340
    
    Signed-off-by: Andy Grover <agrover@redhat.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95c1229d8dab9e43a9567c353ea19be908c14cb3
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed Feb 19 23:32:14 2014 +0000

    iscsi-target: Fix ERL=2 ASYNC_EVENT connection pointer bug
    
    commit d444edc679e7713412f243b792b1f964e5cff1e1 upstream.
    
    This patch fixes a long-standing bug in iscsit_build_conn_drop_async_message()
    where during ERL=2 connection recovery, a bogus conn_p pointer could
    end up being used to send the ISCSI_OP_ASYNC_EVENT + DROPPING_CONNECTION
    notifying the initiator that cmd->logout_cid has failed.
    
    The bug was manifesting itself as an OOPs in iscsit_allocate_cmd() with
    a bogus conn_p pointer in iscsit_build_conn_drop_async_message().
    
    Reported-by: Arshad Hussain <arshad.hussain@calsoftinc.com>
    Reported-by: santosh kulkarni <santosh.kulkarni@calsoftinc.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 84bb7edf3385b3250bd761bcf69931dbc33bc42c
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Feb 11 19:06:33 2014 +0300

    SCSI: arcmsr: upper 32 of dma address lost
    
    commit e2c70425f05219b142b3a8a9489a622c736db39d upstream.
    
    The original code always set the upper 32 bits to zero because it was
    doing a shift of the wrong variable.
    
    Fixes: 1a4f550a09f8 ('[SCSI] arcmsr: 1.20.00.15: add SATA RAID plus other fixes')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit daa12c3ab58832e7a0b402f775078bfc71572ede
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Jan 21 10:00:10 2014 +0300

    SCSI: qla2xxx: fix error handling of qla2x00_mem_alloc()
    
    commit b2a72ec32d0f499aaadf41264232517a12326df0 upstream.
    
    qla2x00_mem_alloc() returns 1 on success and -ENOMEM on failure.  On the
    one hand the caller assumes non-zero is success but on the other hand
    the caller also assumes that it returns an error code.
    
    I've fixed it to return zero on success and a negative error code on
    failure.  This matches the documentation as well.
    
    [jejb: checkpatch fix]
    Fixes: e315cd28b9ef ('[SCSI] qla2xxx: Code changes for qla data structure refactoring')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d1e731a8a5f3b5c437dedc8f397d1caf8521a60
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Mon Apr 7 13:58:35 2014 -0400

    ib_srpt: Use correct ib_sg_dma primitives
    
    commit b076808051f2c80d38e03fb2f1294f525c7a446d upstream.
    
    The code was incorrectly using sg_dma_address() and
    sg_dma_len() instead of ib_sg_dma_address() and
    ib_sg_dma_len().
    
    This prevents srpt from functioning with the
    Intel HCA and indeed will corrupt memory
    badly.
    
    Cc: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Tested-by: Vinod Kumar <vinod.kumar@intel.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39821a43f4055058fc99ec1416ecb591c6603890
Author: Yann Droneaud <ydroneaud@opteya.com>
Date:   Mon Mar 10 23:06:25 2014 +0100

    IB/ehca: Returns an error on ib_copy_to_udata() failure
    
    commit 5bdb0f02add5994b0bc17494f4726925ca5d6ba1 upstream.
    
    In case of error when writing to userspace, function ehca_create_cq()
    does not set an error code before following its error path.
    
    This patch sets the error code to -EFAULT when ib_copy_to_udata()
    fails.
    
    This was caught when using spatch (aka. coccinelle)
    to rewrite call to ib_copy_{from,to}_udata().
    
    Link: https://www.gitorious.org/opteya/coccib/source/75ebf2c1033c64c1d81df13e4ae44ee99c989eba:ib_copy_udata.cocci
    Link: http://marc.info/?i=cover.1394485254.git.ydroneaud@opteya.com
    Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45efb79d127058a1ac02530f24380cdd6953ac47
Author: Yann Droneaud <ydroneaud@opteya.com>
Date:   Mon Mar 10 23:06:26 2014 +0100

    IB/mthca: Return an error on ib_copy_to_udata() failure
    
    commit 08e74c4b00c30c232d535ff368554959403d0432 upstream.
    
    In case of error when writing to userspace, the function mthca_create_cq()
    does not set an error code before following its error path.
    
    This patch sets the error code to -EFAULT when ib_copy_to_udata() fails.
    
    This was caught when using spatch (aka. coccinelle)
    to rewrite call to ib_copy_{from,to}_udata().
    
    Link: https://www.gitorious.org/opteya/coccib/source/75ebf2c1033c64c1d81df13e4ae44ee99c989eba:ib_copy_udata.cocci
    Link: http://marc.info/?i=cover.1394485254.git.ydroneaud@opteya.com
    Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f6f203bfc5ab2940a174d961062e1f332d7e5cd
Author: Yann Droneaud <ydroneaud@opteya.com>
Date:   Mon Mar 10 23:06:27 2014 +0100

    IB/nes: Return an error on ib_copy_from_udata() failure instead of NULL
    
    commit 9d194d1025f463392feafa26ff8c2d8247f71be1 upstream.
    
    In case of error while accessing to userspace memory, function
    nes_create_qp() returns NULL instead of an error code wrapped through
    ERR_PTR().  But NULL is not expected by ib_uverbs_create_qp(), as it
    check for error with IS_ERR().
    
    As page 0 is likely not mapped, it is going to trigger an Oops when
    the kernel will try to dereference NULL pointer to access to struct
    ib_qp's fields.
    
    In some rare cases, page 0 could be mapped by userspace, which could
    turn this bug to a vulnerability that could be exploited: the function
    pointers in struct ib_device will be under userspace total control.
    
    This was caught when using spatch (aka. coccinelle)
    to rewrite calls to ib_copy_{from,to}_udata().
    
    Link: https://www.gitorious.org/opteya/ib-hw-nes-create-qp-null
    Link: https://www.gitorious.org/opteya/coccib/source/75ebf2c1033c64c1d81df13e4ae44ee99c989eba:ib_copy_udata.cocci
    Link: http://marc.info/?i=cover.1394485254.git.ydroneaud@opteya.com
    Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a8cf970eeef276b222e7d68c0f8ef770de2b6f07
Author: Dennis Dalessandro <dennis.dalessandro@intel.com>
Date:   Thu Feb 20 11:02:53 2014 -0500

    IB/ipath: Fix potential buffer overrun in sending diag packet routine
    
    commit a2cb0eb8a64adb29a99fd864013de957028f36ae upstream.
    
    Guard against a potential buffer overrun.  The size to read from the
    user is passed in, and due to the padding that needs to be taken into
    account, as well as the place holder for the ICRC it is possible to
    overflow the 32bit value which would cause more data to be copied from
    user space than is allocated in the buffer.
    
    Reported-by: Nico Golde <nico@ngolde.de>
    Reported-by: Fabian Yamaguchi <fabs@goesec.de>
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da05ff98dcc282ca0eebd849bc87594d6c28b506
Author: Jeff Layton <jlayton@redhat.com>
Date:   Tue Apr 15 08:51:48 2014 -0400

    nfsd: set timeparms.to_maxval in setup_callback_client
    
    commit 3758cf7e14b753838fe754ede3862af10b35fdac upstream.
    
    ...otherwise the logic in the timeout handling doesn't work correctly.
    
    Spotted-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8639f243850400d0e64b2b626903b0bcef925d2
Author: Kinglong Mee <kinglongmee@gmail.com>
Date:   Wed Mar 26 22:09:30 2014 +0800

    NFSD: Traverse unconfirmed client through hash-table
    
    commit 2b9056359889c78ea5decb5b654a512c2e8a945c upstream.
    
    When stopping nfsd, I got BUG messages, and soft lockup messages,
    The problem is cuased by double rb_erase() in nfs4_state_destroy_net()
    and destroy_client().
    
    This patch just let nfsd traversing unconfirmed client through
    hash-table instead of rbtree.
    
    [ 2325.021995] BUG: unable to handle kernel NULL pointer dereference at
              (null)
    [ 2325.022809] IP: [<ffffffff8133c18c>] rb_erase+0x14c/0x390
    [ 2325.022982] PGD 7a91b067 PUD 7a33d067 PMD 0
    [ 2325.022982] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
    [ 2325.022982] Modules linked in: nfsd(OF) cfg80211 rfkill bridge stp
    llc snd_intel8x0 snd_ac97_codec ac97_bus auth_rpcgss nfs_acl serio_raw
    e1000 i2c_piix4 ppdev snd_pcm snd_timer lockd pcspkr joydev parport_pc
    snd parport i2c_core soundcore microcode sunrpc ata_generic pata_acpi
    [last unloaded: nfsd]
    [ 2325.022982] CPU: 1 PID: 2123 Comm: nfsd Tainted: GF          O
    3.14.0-rc8+ #2
    [ 2325.022982] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
    VirtualBox 12/01/2006
    [ 2325.022982] task: ffff88007b384800 ti: ffff8800797f6000 task.ti:
    ffff8800797f6000
    [ 2325.022982] RIP: 0010:[<ffffffff8133c18c>]  [<ffffffff8133c18c>]
    rb_erase+0x14c/0x390
    [ 2325.022982] RSP: 0018:ffff8800797f7d98  EFLAGS: 00010246
    [ 2325.022982] RAX: ffff880079c1f010 RBX: ffff880079f4c828 RCX:
    0000000000000000
    [ 2325.022982] RDX: 0000000000000000 RSI: ffff880079bcb070 RDI:
    ffff880079f4c810
    [ 2325.022982] RBP: ffff8800797f7d98 R08: 0000000000000000 R09:
    ffff88007964fc70
    [ 2325.022982] R10: 0000000000000000 R11: 0000000000000400 R12:
    ffff880079f4c800
    [ 2325.022982] R13: ffff880079bcb000 R14: ffff8800797f7da8 R15:
    ffff880079f4c860
    [ 2325.022982] FS:  0000000000000000(0000) GS:ffff88007f900000(0000)
    knlGS:0000000000000000
    [ 2325.022982] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [ 2325.022982] CR2: 0000000000000000 CR3: 000000007a3ef000 CR4:
    00000000000006e0
    [ 2325.022982] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
    0000000000000000
    [ 2325.022982] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400
    [ 2325.022982] Stack:
    [ 2325.022982]  ffff8800797f7de0 ffffffffa0191c6e ffff8800797f7da8
    ffff8800797f7da8
    [ 2325.022982]  ffff880079f4c810 ffff880079bcb000 ffffffff81cc26c0
    ffff880079c1f010
    [ 2325.022982]  ffff880079bcb070 ffff8800797f7e28 ffffffffa01977f2
    ffff8800797f7df0
    [ 2325.022982] Call Trace:
    [ 2325.022982]  [<ffffffffa0191c6e>] destroy_client+0x32e/0x3b0 [nfsd]
    [ 2325.022982]  [<ffffffffa01977f2>] nfs4_state_shutdown_net+0x1a2/0x220
    [nfsd]
    [ 2325.022982]  [<ffffffffa01700b8>] nfsd_shutdown_net+0x38/0x70 [nfsd]
    [ 2325.022982]  [<ffffffffa017013e>] nfsd_last_thread+0x4e/0x80 [nfsd]
    [ 2325.022982]  [<ffffffffa001f1eb>] svc_shutdown_net+0x2b/0x30 [sunrpc]
    [ 2325.022982]  [<ffffffffa017064b>] nfsd_destroy+0x5b/0x80 [nfsd]
    [ 2325.022982]  [<ffffffffa0170773>] nfsd+0x103/0x130 [nfsd]
    [ 2325.022982]  [<ffffffffa0170670>] ? nfsd_destroy+0x80/0x80 [nfsd]
    [ 2325.022982]  [<ffffffff810a8232>] kthread+0xd2/0xf0
    [ 2325.022982]  [<ffffffff810a8160>] ? insert_kthread_work+0x40/0x40
    [ 2325.022982]  [<ffffffff816c493c>] ret_from_fork+0x7c/0xb0
    [ 2325.022982]  [<ffffffff810a8160>] ? insert_kthread_work+0x40/0x40
    [ 2325.022982] Code: 48 83 e1 fc 48 89 10 0f 84 02 01 00 00 48 3b 41 10
    0f 84 08 01 00 00 48 89 51 08 48 89 fa e9 74 ff ff ff 0f 1f 40 00 48 8b
    50 10 <f6> 02 01 0f 84 93 00 00 00 48 8b 7a 10 48 85 ff 74 05 f6 07 01
    [ 2325.022982] RIP  [<ffffffff8133c18c>] rb_erase+0x14c/0x390
    [ 2325.022982]  RSP <ffff8800797f7d98>
    [ 2325.022982] CR2: 0000000000000000
    [ 2325.022982] ---[ end trace 28c27ed011655e57 ]---
    
    [  228.064071] BUG: soft lockup - CPU#0 stuck for 22s! [nfsd:558]
    [  228.064428] Modules linked in: ip6t_rpfilter ip6t_REJECT cfg80211
    xt_conntrack rfkill ebtable_nat ebtable_broute bridge stp llc
    ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
    nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw
    ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
    nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security
    iptable_raw nfsd(OF) auth_rpcgss nfs_acl lockd snd_intel8x0
    snd_ac97_codec ac97_bus joydev snd_pcm snd_timer e1000 sunrpc snd ppdev
    parport_pc serio_raw pcspkr i2c_piix4 microcode parport soundcore
    i2c_core ata_generic pata_acpi
    [  228.064539] CPU: 0 PID: 558 Comm: nfsd Tainted: GF          O
    3.14.0-rc8+ #2
    [  228.064539] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
    VirtualBox 12/01/2006
    [  228.064539] task: ffff880076adec00 ti: ffff880074616000 task.ti:
    ffff880074616000
    [  228.064539] RIP: 0010:[<ffffffff8133ba17>]  [<ffffffff8133ba17>]
    rb_next+0x27/0x50
    [  228.064539] RSP: 0018:ffff880074617de0  EFLAGS: 00000282
    [  228.064539] RAX: ffff880074478010 RBX: ffff88007446f860 RCX:
    0000000000000014
    [  228.064539] RDX: ffff880074478010 RSI: 0000000000000000 RDI:
    ffff880074478010
    [  228.064539] RBP: ffff880074617de0 R08: 0000000000000000 R09:
    0000000000000012
    [  228.064539] R10: 0000000000000001 R11: ffffffffffffffec R12:
    ffffea0001d11a00
    [  228.064539] R13: ffff88007f401400 R14: ffff88007446f800 R15:
    ffff880074617d50
    [  228.064539] FS:  0000000000000000(0000) GS:ffff88007f800000(0000)
    knlGS:0000000000000000
    [  228.064539] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [  228.064539] CR2: 00007fe9ac6ec000 CR3: 000000007a5d6000 CR4:
    00000000000006f0
    [  228.064539] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
    0000000000000000
    [  228.064539] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400
    [  228.064539] Stack:
    [  228.064539]  ffff880074617e28 ffffffffa01ab7db ffff880074617df0
    ffff880074617df0
    [  228.064539]  ffff880079273000 ffffffff81cc26c0 ffffffff81cc26c0
    0000000000000000
    [  228.064539]  0000000000000000 ffff880074617e48 ffffffffa01840b8
    ffffffff81cc26c0
    [  228.064539] Call Trace:
    [  228.064539]  [<ffffffffa01ab7db>] nfs4_state_shutdown_net+0x18b/0x220
    [nfsd]
    [  228.064539]  [<ffffffffa01840b8>] nfsd_shutdown_net+0x38/0x70 [nfsd]
    [  228.064539]  [<ffffffffa018413e>] nfsd_last_thread+0x4e/0x80 [nfsd]
    [  228.064539]  [<ffffffffa00aa1eb>] svc_shutdown_net+0x2b/0x30 [sunrpc]
    [  228.064539]  [<ffffffffa018464b>] nfsd_destroy+0x5b/0x80 [nfsd]
    [  228.064539]  [<ffffffffa0184773>] nfsd+0x103/0x130 [nfsd]
    [  228.064539]  [<ffffffffa0184670>] ? nfsd_destroy+0x80/0x80 [nfsd]
    [  228.064539]  [<ffffffff810a8232>] kthread+0xd2/0xf0
    [  228.064539]  [<ffffffff810a8160>] ? insert_kthread_work+0x40/0x40
    [  228.064539]  [<ffffffff816c493c>] ret_from_fork+0x7c/0xb0
    [  228.064539]  [<ffffffff810a8160>] ? insert_kthread_work+0x40/0x40
    [  228.064539] Code: 1f 44 00 00 55 48 8b 17 48 89 e5 48 39 d7 74 3b 48
    8b 47 08 48 85 c0 75 0e eb 25 66 0f 1f 84 00 00 00 00 00 48 89 d0 48 8b
    50 10 <48> 85 d2 75 f4 5d c3 66 90 48 3b 78 08 75 f6 48 8b 10 48 89 c7
    
    Fixes: ac55fdc408039 (nfsd: move the confirmed and unconfirmed hlists...)
    Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
    Reviewed-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83caff8d1740d76609a9b1bc55247d17be44d85f
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Mon Mar 10 14:17:55 2014 -0400

    nfsd4: fix setclientid encode size
    
    commit 480efaee085235bb848f1063f959bf144103c342 upstream.
    
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 344f3a6bce11dd3d483d7e36dce33b22427ff621
Author: Stanislav Kinsbursky <skinsbursky@parallels.com>
Date:   Wed Feb 26 16:50:01 2014 +0300

    nfsd: check passed socket's net matches NFSd superblock's one
    
    commit 3064639423c48d6e0eb9ecc27c512a58e38c6c57 upstream.
    
    There could be a case, when NFSd file system is mounted in network, different
    to socket's one, like below:
    
    "ip netns exec" creates new network and mount namespace, which duplicates NFSd
    mount point, created in init_net context. And thus NFS server stop in nested
    network context leads to RPCBIND client destruction in init_net.
    Then, on NFSd start in nested network context, rpc.nfsd process creates socket
    in nested net and passes it into "write_ports", which leads to RPCBIND sockets
    creation in init_net context because of the same reason (NFSd monut point was
    created in init_net context). An attempt to register passed socket in nested
    net leads to panic, because no RPCBIND client present in nexted network
    namespace.
    
    This patch add check that passed socket's net matches NFSd superblock's one.
    And returns -EINVAL error to user psace otherwise.
    
    v2: Put socket on exit.
    
    Reported-by: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b57d9c3fe362d805eb848098b7bb994a3b718ebf
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Mon Feb 24 14:59:47 2014 -0500

    nfsd: notify_change needs elevated write count
    
    commit 9f67f189939eccaa54f3d2c9cf10788abaf2d584 upstream.
    
    Looks like this bug has been here since these write counts were
    introduced, not sure why it was just noticed now.
    
    Thanks also to Jan Kara for pointing out the problem.
    
    Reported-by: Matthew Rahtz <mrahtz@rapitasystems.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5aad7571c2cf4366b1b80c7d22446458fe75f629
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Mon Feb 3 16:31:42 2014 -0500

    nfsd4: fix test_stateid error reply encoding
    
    commit a11fcce1544df08c723d950ff0edef3adac40405 upstream.
    
    If the entire operation fails then there's nothing to encode.
    
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4a0a32b202fd49d255bfc689828f0a79d364866
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Tue Jan 28 16:05:15 2014 -0500

    nfsd4: buffer-length check for SUPPATTR_EXCLCREAT
    
    commit de3997a7eeb9ea286b15879fdf8a95aae065b4f7 upstream.
    
    This was an omission from 8c18f2052e756e7d5dea712fc6e7ed70c00e8a39
    "nfsd41: SUPPATTR_EXCLCREAT attribute".
    
    Cc: Benny Halevy <bhalevy@primarydata.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5393b70f9229b3e68146c84888cbfc8be002d72
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Tue Jan 28 16:01:04 2014 -0500

    nfsd4: session needs room for following op to error out
    
    commit 4c69d5855a16f7378648c5733632628fa10431db upstream.
    
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4b034e7b55357d8fae469134405360d508d42f84
Author: Alec Berg <alecaberg@chromium.org>
Date:   Wed Mar 19 18:50:00 2014 +0000

    iio: querying buffer scan_mask should return 0/1
    
    commit 2076a20fc1a06f7b0333c62a2bb4eeeac7ed1bcb upstream.
    
    Ensure that querying the IIO buffer scan_mask returns a value of
    0 or 1. Currently querying the scan mask has the value returned
    by test_bit(), which returns either true or false. For some
    architectures test_bit() may return -1 for true, which will appear
    to return an error when returning from iio_scan_mask_query().
    
    Additionally, it's important for the sysfs interface to consistently
    return the same thing when querying the scan_mask.
    
    Signed-off-by: Alec Berg <alecaberg@chromium.org>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 297d5df003afe5b1a096ca9877e9c5cc8d99396a
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon Apr 14 13:48:47 2014 -0400

    USB: fix crash during hotplug of PCI USB controller card
    
    commit a2ff864b53eac9a0e9b05bfe9d1781ccd6c2af71 upstream.
    
    The code in hcd-pci.c that matches up EHCI controllers with their
    companion UHCI or OHCI controllers assumes that the private drvdata
    fields don't get set too early.  However, it turns out that this field
    gets set by usb_create_hcd(), before hcd-pci expects it, and this can
    result in a crash when two controllers are probed in parallel (as can
    happen when a new controller card is hotplugged).
    
    The companions_rwsem lock was supposed to prevent this sort of thing,
    but usb_create_hcd() is called outside the scope of the rwsem.
    
    A simple solution is to check that the root-hub pointer has been
    initialized as well as the drvdata field.  This doesn't happen until
    usb_add_hcd() is called; that call and the check are both protected by
    the rwsem.
    
    This patch should be applied to stable kernels from 3.10 onward.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Stefani Seibold <stefani@seibold.net>
    Tested-by: Stefani Seibold <stefani@seibold.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4bb7ebb5ec23703c542a38702e4c1a35e6863a39
Author: H. Peter Anvin <hpa@linux.intel.com>
Date:   Sun Mar 16 15:31:54 2014 -0700

    x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
    
    commit b3b42ac2cbae1f3cecbb6229964a4d48af31d382 upstream.
    
    The IRET instruction, when returning to a 16-bit segment, only
    restores the bottom 16 bits of the user space stack pointer.  We have
    a software workaround for that ("espfix") for the 32-bit kernel, but
    it relies on a nonzero stack segment base which is not available in
    32-bit mode.
    
    Since 16-bit support is somewhat crippled anyway on a 64-bit kernel
    (no V86 mode), and most (if not quite all) 64-bit processors support
    virtualization for the users who really need it, simply reject
    attempts at creating a 16-bit segment when running on top of a 64-bit
    kernel.
    
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Link: http://lkml.kernel.org/n/tip-kicdm89kzw9lldryb1br9od0@git.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a42fa0bbf7260c1301a40f59e9bb9394a1d495d9
Author: Petr Mladek <pmladek@suse.cz>
Date:   Mon Feb 24 17:12:20 2014 +0100

    ftrace/x86: One more missing sync after fixup of function modification failure
    
    commit 12729f14d8357fb845d75155228b21e76360272d upstream.
    
    If a failure occurs while modifying ftrace function, it bails out and will
    remove the tracepoints to be back to what the code originally was.
    
    There is missing the final sync run across the CPUs after the fix up is done
    and before the ftrace int3 handler flag is reset.
    
    Here's the description of the problem:
    
    	CPU0				CPU1
    	----				----
      remove_breakpoint();
      modifying_ftrace_code = 0;
    
    				[still sees breakpoint]
    				<takes trap>
    				[sees modifying_ftrace_code as zero]
    				[no breakpoint handler]
    				[goto failed case]
    				[trap exception - kernel breakpoint, no
    				 handler]
    				BUG()
    
    Link: http://lkml.kernel.org/r/1393258342-29978-2-git-send-email-pmladek@suse.cz
    
    Fixes: 8a4d0a687a5 "ftrace: Use breakpoint method to update ftrace caller"
    Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
    Acked-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Petr Mladek <pmladek@suse.cz>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d267970ad9fb54e59f080d8ff80bcd1cd3a0039
Author: Mark Tinguely <tinguely@sgi.com>
Date:   Fri Apr 4 07:10:49 2014 +1100

    xfs: fix directory hash ordering bug
    
    commit c88547a8119e3b581318ab65e9b72f27f23e641d upstream.
    
    Commit f5ea1100 ("xfs: add CRCs to dir2/da node blocks") introduced
    in 3.10 incorrectly converted the btree hash index array pointer in
    xfs_da3_fixhashpath(). It resulted in the the current hash always
    being compared against the first entry in the btree rather than the
    current block index into the btree block's hash entry array. As a
    result, it was comparing the wrong hashes, and so could misorder the
    entries in the btree.
    
    For most cases, this doesn't cause any problems as it requires hash
    collisions to expose the ordering problem. However, when there are
    hash collisions within a directory there is a very good probability
    that the entries will be ordered incorrectly and that actually
    matters when duplicate hashes are placed into or removed from the
    btree block hash entry array.
    
    This bug results in an on-disk directory corruption and that results
    in directory verifier functions throwing corruption warnings into
    the logs. While no data or directory entries are lost, access to
    them may be compromised, and attempts to remove entries from a
    directory that has suffered from this corruption may result in a
    filesystem shutdown.  xfs_repair will fix the directory hash
    ordering without data loss occuring.
    
    [dchinner: wrote useful a commit message]
    
    Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: Mark Tinguely <tinguely@sgi.com>
    Reviewed-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Dave Chinner <david@fromorbit.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c9dcf2b7c7cc5d10cbe8141c957ec86ed75923c
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Wed Apr 16 14:49:33 2014 -0500

    staging: r8712u: Fix case where ethtype was never obtained and always be checked against 0
    
    commit f764cd68d9036498f08fe8834deb6a367b5c2542 upstream.
    
    Zero-initializing ether_type masked that the ether type would never be
    obtained for 8021x packets and the comparison against eapol_type
    would always fail.
    
    Reported-by: Jes Sorensen <Jes.Sorensen@redhat.com>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8012af5c10347fc926083534dab46327892c0804
Author: Himangi Saraogi <himangi774@gmail.com>
Date:   Wed Mar 5 04:59:57 2014 +0530

    staging:serqt_usb2: Fix sparse warning restricted __le16 degrades to integer
    
    commit abe5d64d1a74195a44cd14624f8178b9f48b7cc7 upstream.
    
    This patch fixes the following sparse warning :
    drivers/staging/serqt_usb2/serqt_usb2.c:727:40: warning: restricted __le16 degrades to integer
    
    Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a8be0fe6d1f30cbad40c9ca1a5ef7c080f625a7
Author: David Fries <David@Fries.net>
Date:   Wed Jan 15 22:29:12 2014 -0600

    w1: fix w1_send_slave dropping a slave id
    
    commit 6b355b33a64fd6d8ead2b838ec16fb9b551f71e8 upstream.
    
    Previous logic,
    if (avail > 8) {
    	store slave;
    	return;
    }
    send data; clear;
    
    The logic error is, if there isn't space send the buffer and clear,
    but the slave wasn't added to the now empty buffer loosing that slave
    id.  It also should have been "if (avail >= 8)" because when it is 8,
    there is space.
    
    Instead, if there isn't space send and clear the buffer, then there is
    always space for the slave id.
    
    Signed-off-by: David Fries <David@Fries.net>
    Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81a6cff47303642deafb3f1ac2a7ac33e04bbae2
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Wed Mar 12 16:50:44 2014 +0100

    mfd: tps65910: Fix possible invalid pointer dereference on regmap_add_irq_chip fail
    
    commit 483e2dfdbc94751430e41db9973985f5b054d322 upstream.
    
    Fixes: 4aab3fadad32 ("mfd: tps65910: Move interrupt implementation code to mfd file")
    
    tps65910_irq_init() sets 'tps65910->chip_irq' before calling
    regmap_add_irq_chip(). If the regmap_add_irq_chip() call fails in
    memory allocation of regmap_irq_chip_data members then:
    
    1. The 'tps65910->chip_irq' will still hold some value
    2. 'tps65910->irq_data' will be pointing to already freed memory
       (because regmap_add_irq_chip() will free it on error)
    
    This results in invalid memory access during driver remove because the
    tps65910_irq_exit() tests whether 'tps65910->chip_irq' is not zero.
    
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2736c784b16bb5b5e5a1e8e1dba7638f212a42b
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Tue Feb 11 11:03:34 2014 +0100

    mfd: max8997: Fix possible NULL pointer dereference on i2c_new_dummy error
    
    commit 97dc4ed3fa377ec91bb60ba98b70d645c2099384 upstream.
    
    During probe the driver allocates dummy I2C devices for RTC, haptic and
    MUIC with i2c_new_dummy() but it does not check the return value of this
    calls.
    
    In case of error (i2c_new_device(): memory allocation failure or I2C
    address cannot be used) this function returns NULL which is later used
    by i2c_unregister_device().
    
    If i2c_new_dummy() fails for RTC, haptic or MUIC devices, fail also the
    probe for main MFD driver.
    
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe22769b213aade80d43b12b6f51c0ba7a9c0668
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Tue Feb 11 11:03:35 2014 +0100

    mfd: max8998: Fix possible NULL pointer dereference on i2c_new_dummy error
    
    commit ed26f87b9f71693a1d1ee85f5e6209601505080f upstream.
    
    During probe the driver allocates dummy I2C device for RTC with i2c_new_dummy() but it does not check the return value of this call.
    
    In case of error (i2c_new_device(): memory allocation failure or I2C
    address cannot be used) this function returns NULL which is later used
    by i2c_unregister_device().
    
    If i2c_new_dummy() fails for RTC device, fail also the probe for
    main MFD driver.
    
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64ff251f373e35623e88333c1dc9ea118bbe857b
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Tue Feb 11 11:03:33 2014 +0100

    mfd: max8925: Fix possible NULL pointer dereference on i2c_new_dummy error
    
    commit 96cf3dedc491d2f1f66cc26217f2b06b0c7b6797 upstream.
    
    During probe the driver allocates dummy I2C devices for RTC and ADC
    with i2c_new_dummy() but it does not check the return value of this
    calls.
    
    In case of error (i2c_new_device(): memory allocation failure or I2C
    address cannot be used) this function returns NULL which is later used
    by i2c_unregister_device().
    
    If i2c_new_dummy() fails for RTC or ADC devices, fail also the probe
    for main MFD driver.
    
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d017bfb19b7e3eff402569bedb2c42ff4ce4236
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Tue Feb 11 11:03:32 2014 +0100

    mfd: max77693: Fix possible NULL pointer dereference on i2c_new_dummy error
    
    commit ad09dd6a1f5d6244bd89314015af506ba7f9810a upstream.
    
    During probe the driver allocates dummy I2C devices for MUIC and haptic
    with i2c_new_dummy() but it does not check the return value of this
    calls.
    
    In case of error (i2c_new_device(): memory allocation failure or I2C
    address cannot be used) this function returns NULL which is later used
    by devm_regmap_init_i2c() and i2c_unregister_device().
    
    If i2c_new_dummy() fails for MUIC or haptic devices, fail also the probe
    for main MFD driver.
    
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee2a4e597a86450706cc659f97507b8f69ab06ba
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Tue Feb 11 11:03:31 2014 +0100

    mfd: max77686: Fix possible NULL pointer dereference on i2c_new_dummy error
    
    commit b9e183a1d495cd65412abe0f9df19b151716bfe7 upstream.
    
    During probe the driver allocates dummy I2C device for RTC with
    i2c_new_dummy() but it does not check the return value of this call.
    
    In case of error (i2c_new_device(): memory allocation failure or I2C
    address cannot be used) this function returns NULL which is later used
    by i2c_unregister_device().
    
    If i2c_new_dummy() fails for RTC device, fail also the probe for main
    MFD driver.
    
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe293a297e92c2979ac678b62aedfd78482e2144
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Tue Feb 11 11:03:30 2014 +0100

    mfd: 88pm860x: Fix I2C device resource leak on regmap init fail
    
    commit a7ab1c8b261305af583ce26bb4a14f555fdaa73e upstream.
    
    During probe the driver allocates dummy I2C device for companion chip
    and then allocates a regmap for it. If regmap_init_i2c() fails then the
    I2C driver (allocated with i2c_new_dummy()) is not freed and this
    resource leaks.
    
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da0bc89767da7817dc6df9cfa10321b40ffdf210
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Tue Feb 11 11:03:29 2014 +0100

    mfd: 88pm860x: Fix possible NULL pointer dereference on i2c_new_dummy error
    
    commit 159ce52a6b777fc82fa0b51c7440e25f9e4c6feb upstream.
    
    During probe the driver allocates dummy I2C device for companion chip
    with i2c_new_dummy() but it does not check the return value of this call.
    
    In case of error (i2c_new_device(): memory allocation failure or I2C
    address cannot be used) this function returns NULL which is later used
    by regmap_init_i2c().
    
    If i2c_new_dummy() fails for companion device, fail also the probe for
    main MFD driver.
    
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aea2ad9c6196b0adb3d863e4bcc2f74c4d57e7c2
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Tue Feb 11 10:12:25 2014 +0100

    mfd: sec-core: Fix possible NULL pointer dereference when i2c_new_dummy error
    
    commit 65aba1e04916d72b30c028730a1e31860c225412 upstream.
    
    During probe the sec-core driver allocates dummy I2C device for RTC with
    i2c_new_dummy() but return value is not checked. In case of error
    (i2c_new_device(): memory allocation failure or I2C address cannot be
    used) this function returns NULL which is later used by
    devm_regmap_init_i2c() or i2c_unregister_device().
    
    If i2c_new_dummy() fails for RTC device, fail also the probe for main
    MFD driver.
    
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8343a52ace5428678b689273fe0c2298f7a9e2a9
Author: Tomas Winkler <tomas.winkler@intel.com>
Date:   Tue Mar 25 21:25:18 2014 +0200

    mei: me: do not load the driver if the FW doesn't support MEI interface
    
    commit 5e6533a6f52f1a8283b2f818f5828be99a417dd6 upstream.
    
    NM and SPS  FW types that may run on ME device on server platforms
    do not have valid MEI/HECI interface and driver should not
    be bound to it as this might lead to system hung.
    In practice not all BIOSes effectively hide such devices from the
    OS and in some cases it is not possible.
    
    We determine FW type by examining Host FW status registers in order to
    unbind the driver.
    In this patch we are adding check for ME on Cougar Point, Lynx Point
    Devices
    
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Tested-by: Nikola Ciprich <nikola.ciprich@linuxbox.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a52b43b32fc1886b2a6c62567742962a9188278
Author: Sebastian Ott <sebott@linux.vnet.ibm.com>
Date:   Mon Jan 27 13:26:10 2014 +0100

    s390/cio: fix driver callback initialization for ccw consoles
    
    commit 2253e8d79237c69086ded391e6767afe16972527 upstream.
    
    ccw consoles are in use before they can be properly registered with
    the driver core. For devices which are in use by a device driver we
    rely on the ccw_device's pointer to the driver callbacks to be valid.
    For ccw consoles this pointer is NULL until they are registered later
    during boot and we dereferenced this pointer. This worked by
    chance on 64 bit builds (cdev->drv was NULL but the optional callback
    cdev->drv->path_event was also NULL by coincidence) and was unnoticed
    until we received reports about boot failures on 31 bit systems.
    Fix it by initializing the driver pointer for ccw consoles.
    
    Reported-by: Mike Frysinger <vapier@gentoo.org>
    Reported-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Reviewed-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
    Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa8575ddb36e6295a8ccfcbfb7f2b7009307f292
Author: Kailang Yang <kailang@realtek.com>
Date:   Mon Apr 14 15:09:44 2014 +0800

    ALSA: hda/realtek - Add support of ALC288 codec
    
    commit 7c66593286bcd153e4868383e675673a27071bd5 upstream.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db6338e0efa1cfe54b9f3e6557292419ff2c47e6
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Apr 3 11:51:21 2014 +0200

    ALSA: hda - Fix silent speaker output due to mute LED fixup
    
    commit 415d555e6b398b00fc1733f0113065a54df9106a upstream.
    
    The recent fixups for HP laptops to support the mute LED made the
    speaker output silent on some machines.  It turned out that they use
    the NID 0x18 for the speaker while it's also used for controlling the
    LED via VREF bits although the current driver code blindly assumes
    that such a node is a mic pin (where 0x18 is usually so).
    
    This patch fixes the problem by only changing the VREF bits and
    keeping the other pin ctl bits.
    
    Reported-and-tested-by: Hui Wang <hui.wang@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f13dbe1e97b98c5d2c315b8e3d21e04fa49937d1
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Apr 8 16:58:34 2014 +0200

    ALSA: ice1712: Fix boundary checks in PCM pointer ops
    
    commit 4f8e940095536bc002a81666a4107a581c84e9b9 upstream.
    
    PCM pointer callbacks in ice1712 driver check the buffer size boundary
    wrongly between bytes and frames.  This leads to PCM core warnings
    like:
       snd_pcm_update_hw_ptr0: 105 callbacks suppressed
       ALSA pcm_lib.c:352 BUG: pcmC3D0c:0, pos = 5461, buffer size = 5461, period size = 2730
    
    This patch fixes these checks to be placed after the proper unit
    conversions.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ce77a7a6cc45d0733521dfa16e9259f29e21faf
Author: W. Trevor King <wking@tremily.us>
Date:   Sat Mar 29 17:47:24 2014 -0700

    ALSA: hda - Enable beep for ASUS 1015E
    
    commit a4b7f21d7b42b33609df3f86992a8deff80abfaf upstream.
    
    The `lspci -nnvv` output contains (wrapped for line length):
    
      00:1b.0 Audio device [0403]:
        Intel Corporation 7 Series/C210 Series Chipset Family
        High Definition Audio Controller [8086:1e20] (rev 04)
            Subsystem: ASUSTeK Computer Inc. Device [1043:115d]
    
    Signed-off-by: W. Trevor King <wking@tremily.us>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f80251afe07130734c86628cbadff0caba3af27
Author: Laura Abbott <lauraa@codeaurora.org>
Date:   Thu May 16 19:40:22 2013 +0100

    ARM: 7728/1: mm: Use phys_addr_t properly for ioremap functions
    
    commit 9b97173e785a54c5df0aa23d1e1f680f61e36e43 upstream.
    
    Several of the ioremap functions use unsigned long in places
    resulting in truncation if physical addresses greater than
    4G are passed in. Change the types of the functions and the
    callers accordingly.
    
    Cc: Krzysztof Halasa <khc@pm.waw.pl>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Stephen Boyd <sboyd@codeaurora.org>
    Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Cc: Wang Nan <wangnan0@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e297c3c0930078c08d6a0577dc60fd6fc13484c
Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date:   Wed Mar 26 00:33:58 2014 +0100

    ARM: mvebu: ensure the mdio node has a clock reference on Armada 370/XP
    
    commit a6e03dd451c724f785277d8ecca5d1a0b886d892 upstream.
    
    The mvmdio driver accesses some register of the Ethernet unit. It
    therefore takes a reference and enables a clock. However, on Armada
    370/XP, no clock specification was given in the Device Tree, which
    leads the mvmdio driver to fail when being used as a module and loaded
    before the mvneta driver: it tries to access a register from a
    hardware unit that isn't clocked.
    
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Link: https://lkml.kernel.org/r/1395790439-21332-2-git-send-email-thomas.petazzoni@free-electrons.com
    Acked-by: Andrew Lunn <andrew@lunn.ch>
    Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
    Signed-off-by: Jason Cooper <jason@lakedaemon.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 674ae6c7b4048c35ce8f090657dd4e2e675bf0fa
Author: Liu Hua <sdu.liu@huawei.com>
Date:   Fri Apr 18 07:45:36 2014 +0100

    ARM: 8030/1: ARM : kdump : add arch_crash_save_vmcoreinfo
    
    commit 56b700fd6f1e49149880fb1b6ffee0dca5be45fb upstream.
    
    For vmcore generated by LPAE enabled kernel, user space
    utility such as crash needs additional infomation to
    parse.
    
    So this patch add arch_crash_save_vmcoreinfo as what PAE enabled
    i386 linux does.
    
    Reviewed-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Liu Hua <sdu.liu@huawei.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a91c29ca2e7ae1fa4020e334abfc2174d8c6bdf
Author: Xiangyu Lu <luxiangyu@huawei.com>
Date:   Tue Apr 15 09:38:17 2014 +0100

    ARM: 8027/1: fix do_div() bug in big-endian systems
    
    commit 80bb3ef109ff40a7593d9481c17de9bbc4d7c0e2 upstream.
    
    In big-endian systems, "%1" get the most significant part of the value, cause the instruction to get the wrong result.
    
    When viewing ftrace record in big-endian ARM systems, we found that
    the timestamp errors:
    
    swapper-0   [001] 1325.970000:   0:120:R ==> [001]    16:120:R events/1
    events/1-16 [001] 1325.970000:   16:120:S ==> [001]    0:120:R swapper
    swapper-0   [000] 1325.1000000:  0:120:R   + [000]    15:120:R events/0
    swapper-0   [000] 1325.1000000:  0:120:R ==> [000]    15:120:R events/0
    swapper-0   [000] 1326.030000:   0:120:R   + [000]  1150:120:R sshd
    swapper-0   [000] 1326.030000:   0:120:R ==> [000]  1150:120:R sshd
    
    When viewed ftrace records, it will call the do_div(n, base) function, which achieved arch/arm/include/asm/div64.h in. When n = 10000000, base = 1000000, in do_div(n, base) will execute "umull %Q0, %R0, %1, %Q2".
    
    Reviewed-by: Dave Martin <Dave.Martin@arm.com>
    Reviewed-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Alex Wu <wuquanming@huawei.com>
    Signed-off-by: Xiangyu Lu <luxiangyu@huawei.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec474f3aef984135bbc568ddc903083a5170e308
Author: Christopher Covington <cov@codeaurora.org>
Date:   Wed Mar 19 18:12:25 2014 +0100

    ARM: 8007/1: Remove extraneous kcmp syscall ignore
    
    commit 95c52fe063351192e0f4ffb70ef9bac1aa26f5a4 upstream.
    
    The kcmp system call was ported to ARM in
    commit 3f7d1fe108dbaefd0c57a41753fc2c90b395f458
    "ARM: 7665/1: Wire up kcmp syscall".
    
    Fixes: 3f7d1fe108db ("ARM: 7665/1: Wire up kcmp syscall")
    Signed-off-by: Christopher Covington <cov@codeaurora.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d895644c13bab61f17bc65c86cd2b2c80c44f930
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Feb 7 19:12:27 2014 +0100

    ARM: 7954/1: mm: remove remaining domain support from ARMv6
    
    commit b6ccb9803e90c16b212cf4ed62913a7591e79a39 upstream.
    
    CPU_32v6 currently selects CPU_USE_DOMAINS if CPU_V6 and MMU. This is
    because ARM 1136 r0pX CPUs lack the v6k extensions, and therefore do
    not have hardware thread registers. The lack of these registers requires
    the kernel to update the vectors page at each context switch in order to
    write a new TLS pointer. This write must be done via the userspace
    mapping, since aliasing caches can lead to expensive flushing when using
    kmap. Finally, this requires the vectors page to be mapped r/w for
    kernel and r/o for user, which has implications for things like put_user
    which must trigger CoW appropriately when targetting user pages.
    
    The upshot of all this is that a v6/v7 kernel makes use of domains to
    segregate kernel and user memory accesses. This has the nasty
    side-effect of making device mappings executable, which has been
    observed to cause subtle bugs on recent cores (e.g. Cortex-A15
    performing a speculative instruction fetch from the GIC and acking an
    interrupt in the process).
    
    This patch solves this problem by removing the remaining domain support
    from ARMv6. A new memory type is added specifically for the vectors page
    which allows that page (and only that page) to be mapped as user r/o,
    kernel r/w. All other user r/o pages are mapped also as kernel r/o.
    Patch co-developed with Russell King.
    
    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 93bcdf84139577dc9e84a0d2a977f385d32cbc31
Author: Tomasz Figa <t.figa@samsung.com>
Date:   Fri Feb 14 07:43:54 2014 +0900

    ARM: dts: Keep G3D regulator always on for exynos5250-arndale
    
    commit bfeda827278f09f4db35877e5f1ca9c149ca2890 upstream.
    
    Apparently, if G3D regulator is powered off, the SoC cannot enter low
    power modes and just hangs. This patch fixes this by keeping the
    regulator always on when the system is running, as suggested by Exynos 4
    User's Manual in case of Exynos4210/4x12 SoCs (Exynos5250 UM does not
    have such note, but observed behavior seems to confirm that it is true
    for this SoC as well).
    
    This fixes an issue preventing Arndale board from entering sleep mode
    observed since commit
    
    346f372f7b72a0 clk: exynos5250: Add CLK_IGNORE_UNUSED flag for pmu clock
    
    that landed in kernel 3.10, which has fixed the clock driver to make the
    SoC actually try to enter the sleep mode.
    
    Signed-off-by: Tomasz Figa <t.figa@samsung.com>
    Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
    Tested-by: Tushar Behera <tushar.behera@linaro.org>
    Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3841175f6ea54cfd6f8877c2251ee0276206496f
Author: Roger Quadros <rogerq@ti.com>
Date:   Thu Apr 10 10:18:17 2014 +0300

    ARM: OMAP3: hwmod data: Correct clock domains for USB modules
    
    commit c6c56697ae4bf1226263c19e8353343d7083f40e upstream.
    
    OMAP3 doesn't contain "l3_init_clkdm" clock domain. Use the
    proper clock domains for USB Host and USB TLL modules.
    
    Gets rid of the following warnings during boot
     omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm
     omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm
    
    Reported-by: Nishanth Menon <nm@ti.com>
    Cc: Paul Walmsley <paul@pwsan.com>
    Signed-off-by: Roger Quadros <rogerq@ti.com>
    Fixes: de231388cb80a8ef3e779bbfa0564ba0157b7377 ("ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3")
    Cc: Keshava Munegowda <keshava_mgowda@ti.com>
    Cc: Partha Basak <parthab@india.ti.com>
    Signed-off-by: Paul Walmsley <paul@pwsan.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 042323b540be919f5464336e24fb1e38f0691527
Author: Nishanth Menon <nm@ti.com>
Date:   Wed Mar 12 16:43:20 2014 -0500

    ARM: OMAP4: Fix definition of IS_PM44XX_ERRATUM
    
    commit 07484ca33ef83900f5cfbde075c1a19e5a237aa1 upstream.
    
    Just like IS_PM34XX_ERRATUM, IS_PM44XX_ERRATUM is valid only if
    CONFIG_PM is enabled, else, disabling CONFIG_PM results in build
    failure complaining about the following:
    arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary':
    :(.text+0x8a70): undefined reference to `pm44xx_errata'
    
    Fixes: c962184 (ARM: OMAP4: PM: add errata support)
    Reported-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.ocm>
    Acked-by: Kevin Hilman <khilman@linaro.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eae8deca616b42aed8995bba718e729a650deb00
Author: Stefan Sørensen <stefan.sorensen@spectralink.com>
Date:   Thu Mar 6 16:27:15 2014 +0100

    ARM: OMAP2+: INTC: Acknowledge stuck active interrupts
    
    commit 698b48532539484b012fb7c4176b959d32a17d00 upstream.
    
    When an interrupt has become active on the INTC it will stay active
    until it is acked, even if masked or de-asserted. The
    INTC_PENDING_IRQn registers are however updated and since these are
    used by omap_intc_handle_irq to determine which interrupt to handle,
    it will never see the active interrupt. This will result in a storm of
    useless interrupts that is only stopped when another higher priority
    interrupt is asserted.
    
    Fix by sending the INTC an acknowledge if we find no interrupts to
    handle.
    
    Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d8c3c417bdcddb0798ba54c8032de0ac12cd738
Author: Brian Austin <brian.austin@cirrus.com>
Date:   Tue Mar 18 13:56:21 2014 -0500

    ASoC: cs42l73: Fix mask bits for SOC_VALUE_ENUM_SINGLE
    
    commit 1555b652970e541fa1cb80c61ffc696bbfb92bb7 upstream.
    
    The mask bits values were wrong for the SOC_VALUE_ENUM_SINGLE for the mono mix controls.
    
    Reported-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Brian Austin <brian.austin@cirrus.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 616bdd72f704aec7612dfc8da5e41a894a03b62d
Author: Brian Austin <brian.austin@cirrus.com>
Date:   Tue Mar 18 14:01:47 2014 -0500

    ASoC: cs42l52: Fix mask bits for SOC_VALUE_ENUM_SINGLE
    
    commit d31a33dd7792c7d6c11fda226a3b9e4fb7f86f95 upstream.
    
    The mask bits values were wrong for the SOC_VALUE_ENUM_SINGLE for the PCM/ADC Swap controls
    
    Reported-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Brian Austin <brian.austin@cirrus.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5ac6ad514fcec926a204051d8a66d7a78a8a737
Author: Brian Austin <brian.austin@cirrus.com>
Date:   Wed Mar 19 10:40:02 2014 -0500

    ASoC: cs42l51: Fix SOC_DOUBLE_R_SX_TLV shift values for ADC, PCM, and Analog kcontrols
    
    commit 7272e051157ccd5871b5d939548d0ba5a94a2965 upstream.
    
    The shift values for the ADC,PCM, and Analog kcontrols were wrong causing wrong values for the SOC_DOUBLE_R_SX_TLV macros
    Fixed the TLV for aout_tlv to show -102dB correctly
    
    Fixes: 1d99f2436d (ASoC: core: Rework SOC_DOUBLE_R_SX_TLV add SOC_SINGLE_SX_TLV)
    Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Signed-off-by: Brian Austin <brian.austin@cirrus.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73e8697b71fa956642403304b96442fd4b57ce97
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Wed Mar 12 16:07:06 2014 +0000

    arm64: Make DMA coherent and strongly ordered mappings not executable
    
    commit de2db7432917a82b62d55bb59635586eeca6d1bd upstream.
    
    pgprot_{dmacoherent,writecombine,noncached} don't need to generate
    executable mappings with side-effects like __sync_icache_dcache() being
    called when the mapping is in user space.
    
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Reported-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
    Tested-by: Laura Abbott <lauraa@codeaurora.org>
    Tested-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b1f2bfc9d8bb42b4e5a93470e8a0974cd4c04697
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Wed Mar 12 16:28:09 2014 +0000

    arm64: Do not synchronise I and D caches for special ptes
    
    commit 71fdb6bf61bf0692f004f9daf5650392c0cfe300 upstream.
    
    Special pte mappings are not intended to be executable and do not even
    have an associated struct page. This patch ensures that we do not call
    __sync_icache_dcache() on such ptes.
    
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Reported-by: Steve Capper <Steve.Capper@arm.com>
    Tested-by: Laura Abbott <lauraa@codeaurora.org>
    Tested-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>