commit f0d395108acad87341dcbd026491ec93edbc93a9
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Dec 6 15:57:59 2014 -0800

    Linux 3.17.5

commit 88fd8709858b9cd94e2d28b4b3cac4b752f0683a
Author: bill bonaparte <programme110@gmail.com>
Date:   Thu Nov 6 14:36:48 2014 +0100

    netfilter: conntrack: fix race in __nf_conntrack_confirm against get_next_corpse
    
    commit 5195c14c8b27cc0b18220ddbf0e5ad3328a04187 upstream.
    
    After removal of the central spinlock nf_conntrack_lock, in
    commit 93bb0ceb75be2 ("netfilter: conntrack: remove central
    spinlock nf_conntrack_lock"), it is possible to race against
    get_next_corpse().
    
    The race is against the get_next_corpse() cleanup on
    the "unconfirmed" list (a per-cpu list with seperate locking),
    which set the DYING bit.
    
    Fix this race, in __nf_conntrack_confirm(), by removing the CT
    from unconfirmed list before checking the DYING bit.  In case
    race occured, re-add the CT to the dying list.
    
    While at this, fix coding style of the comment that has been
    updated.
    
    Fixes: 93bb0ceb75be2 ("netfilter: conntrack: remove central spinlock nf_conntrack_lock")
    Reported-by: bill bonaparte <programme110@gmail.com>
    Signed-off-by: bill bonaparte <programme110@gmail.com>
    Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b385019adf661fa20ae263103096acc4e05447d
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Mon Sep 22 13:17:48 2014 +0200

    x86: kvm: use alternatives for VMCALL vs. VMMCALL if kernel text is read-only
    
    commit c1118b3602c2329671ad5ec8bdf8e374323d6343 upstream.
    
    On x86_64, kernel text mappings are mapped read-only with CONFIG_DEBUG_RODATA.
    In that case, KVM will fail to patch VMCALL instructions to VMMCALL
    as required on AMD processors.
    
    The failure mode is currently a divide-by-zero exception, which obviously
    is a KVM bug that has to be fixed.  However, picking the right instruction
    between VMCALL and VMMCALL will be faster and will help if you cannot upgrade
    the hypervisor.
    
    Reported-by: Chris Webb <chris@arachsys.com>
    Tested-by: Chris Webb <chris@arachsys.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: x86@kernel.org
    Acked-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Chris J Arges <chris.j.arges@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f886cdf1f8cb08cd793abb88ac646c3664b83db6
Author: Georgi Djakov <gdjakov@mm-sol.com>
Date:   Fri Oct 10 16:57:24 2014 +0300

    clk: qcom: Fix duplicate rbcpr clock name
    
    commit 9a6cb70f40b0268297024949eb0a2689e3b7769b upstream.
    
    There is a duplication in a clock name for apq8084 platform that causes
    the following warning: "RBCPR_CLK_SRC" redefined
    
    Resolve this by adding a MMSS_ prefix to this clock and making its name
    coherent with msm8974 platform.
    
    Fixes: 2b46cd23a5a2 ("clk: qcom: Add APQ8084 Multimedia Clock Controller (MMCC) support")
    Signed-off-by: Georgi Djakov <gdjakov@mm-sol.com>
    Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
    Signed-off-by: Michael Turquette <mturquette@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a3c5ffb94f165d9a076207ac11dc2c531beb3a8
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Oct 16 20:46:10 2014 +0300

    drm/i915: Ignore long hpds on eDP ports
    
    original upstream id: 7a7f84ccb82e542c845c43f604665ccea1247866
    
    Turning vdd on/off can generate a long hpd pulse on eDP ports. In order
    to handle hpd we would need to turn on vdd to perform aux transfers.
    This would lead to an endless cycle of
    "vdd off -> long hpd -> vdd on -> detect -> vdd off -> ..."
    
    So ignore long hpd pulses on eDP ports. eDP panels should be physically
    tied to the machine anyway so they should not actually disappear and
    thus don't need long hpd handling. Short hpds are still needed for link
    re-train and whatnot so we can't just turn off the hpd interrupt
    entirely for eDP ports. Perhaps we could turn it off whenever the panel
    is disabled, but just ignoring the long hpd seems sufficient.
    
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Reviewed-by: Dave Airlie <airlied@redhat.com>
    Reviewed-by: Todd Previte <tprevite@gmail.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb14996c2a555322ae2610d783e614430b259592
Author: Luciano Coelho <luciano.coelho@intel.com>
Date:   Tue Oct 21 16:12:18 2014 +0300

    iwlwifi: mvm: check TLV flag before trying to use hotspot firmware commands
    
    commit 5ac6c72e594471acfa5b00210c51d533a73413ad upstream.
    
    Older firmwares do not provide support for the HOT_SPOT_CMD command.
    Check for the appropriate TLV flag that declares hotspot support in
    the firmware to prevent a firmware assertion failure that can be
    triggered from the userspace,
    
    Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e709ff658f620bba0c1eb2e0925df2ccc4439ea
Author: Matti Gottlieb <matti.gottlieb@intel.com>
Date:   Mon Sep 29 11:46:04 2014 +0300

    iwlwifi: mvm: ROC - bug fixes around time events and locking
    
    commit a6cc5163149532734b84c86cbffa4994e527074b upstream.
    
    Don't add the time event to the list. We added it several
    times the same time event, which leads to an infinite loop
    when walking the list.
    
    Since we (currently) don't support more than one ROC for STA
    vif at a time, enforce this and don't add the time event
    to any list.
    
    We were also missing the locking of the mutex which led to
    a lockdep splat - fix that.
    
    Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e82d01761ce623228cb21fc2680720f9fcab62a7
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Tue Oct 7 16:12:36 2014 +1100

    powerpc/powernv: Honor the generic "no_64bit_msi" flag
    
    commit 360743814c4082515581aa23ab1d8e699e1fbe88 upstream.
    
    Instead of the arch specific quirk which we are deprecating
    and that drivers don't understand.
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ee96f0b68b9522c063a7952e06333b9f27994bc
Author: Maxime COQUELIN <maxime.coquelin@st.com>
Date:   Thu Nov 6 10:54:19 2014 +0100

    bitops: Fix shift overflow in GENMASK macros
    
    commit 00b4d9a14125f1e51874def2b9de6092e007412d upstream.
    
    On some 32 bits architectures, including x86, GENMASK(31, 0) returns 0
    instead of the expected ~0UL.
    
    This is the same on some 64 bits architectures with GENMASK_ULL(63, 0).
    
    This is due to an overflow in the shift operand, 1 << 32 for GENMASK,
    1 << 64 for GENMASK_ULL.
    
    Reported-by: Eric Paire <eric.paire@st.com>
    Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: linux@rasmusvillemoes.dk
    Cc: gong.chen@linux.intel.com
    Cc: John Sullivan <jsrhbz@kanargh.force9.co.uk>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Fixes: 10ef6b0dffe4 ("bitops: Introduce a more generic BITMASK macro")
    Link: http://lkml.kernel.org/r/1415267659-10563-1-git-send-email-maxime.coquelin@st.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68814ef48cc23572b14b494216598d3116f71096
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Oct 13 13:23:48 2014 -0400

    drm/radeon: initialize sadb to NULL in the audio code
    
    commit 83d04c39f9048807a8500e575ae3f1718a3f45bb upstream.
    
    Fixes kfree of the sadb buffer when it's NULL.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 286d4909c35084ec2dedf86391b3a3abb1e1e04c
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Fri Oct 3 15:18:59 2014 +1000

    gpu/radeon: Set flag to indicate broken 64-bit MSI
    
    commit 91ed6fd2c383bb8f02d66e98b4a4d2f7207249dc upstream.
    
    Some radeon ASICs don't support all 64 address bits of MSIs despite
    advertising support for 64-bit MSIs in their configuration space.
    
    This breaks on systems such as IBM POWER7/8, where 64-bit MSIs can
    be assigned with some of the high address bits set.
    
    This makes use of the newly introduced "no_64bit_msi" flag in structure
    pci_dev to allow the MSI allocation code to fallback to 32-bit MSIs
    on those adapters.
    
    Adding Alex's review tag. Patch to the driver is identical to the
    reviewed one, I dropped the arch/powerpc hunk rewrote the subject
    and cset comment.
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f3972a25bb63af3c3d542af52889b96de9422c0
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Nov 14 12:08:34 2014 -0500

    drm/radeon: report disconnected for LVDS/eDP with PX if ddc fails
    
    commit 1348579433566355e570008929daa09a0db64fd8 upstream.
    
    If ddc fails, presumably the i2c mux (and hopefully the signal
    mux) are switched to the other GPU so don't fetch the edid from
    the vbios so that the connector reports disconnected.
    
    bug:
    https://bugzilla.opensuse.org/show_bug.cgi?id=904417
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7cb9a79e3ee6e414d7f413cd1785d630ace9a1b0
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Tue May 27 21:33:09 2014 +0300

    drm/i915: Ignore SURFLIVE and flip counter when the GPU gets reset
    
    commit bdfa7542d40e6251c232a802231b37116bd31b11 upstream.
    
    During a GPU reset we need to get pending page flip cleared out
    since the ring contents are gone and flip will never complete
    on its own. This used to work until the mmio vs. CS flip race
    detection came about. That piece of code is looking for a
    specific surface address in the SURFLIVE register, but as
    a flip to that address may never happen the check may never
    pass. So we should just skip the SURFLIVE and flip counter
    checks when the GPU gets reset.
    
    intel_display_handle_reset() tries to effectively complete
    the flip anyway by calling .update_primary_plane(). But that
    may not satisfy the conditions of the mmio vs. CS race
    detection since there's no guarantee that a modeset didn't
    sneak in between the GPU reset and intel_display_handle_reset().
    Such a modeset will not wait for pending flips due to the ongoing GPU
    reset, and then the primary plane updates performed by
    intel_display_handle_reset() will already use the new surface
    address, and thus the surface address the flip is waiting for
    might never appear in SURFLIVE. The result is that the flip
    will never complete and attempts to perform further page flips
    will fail with -EBUSY.
    
    During the GPU reset intel_crtc_has_pending_flip() will return
    false regardless, so the deadlock with a modeset vs. the error
    work acquiring crtc->mutex was avoided. And the reset_counter
    check in intel_crtc_has_pending_flip() actually made this bug
    even less severe since it allowed normal modesets to go through
    even though there's a pending flip.
    
    This is a regression introduced by me here:
     commit 75f7f3ec600524c9544cc31695155f1a9ddbe1d9
     Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
     Date:   Tue Apr 15 21:41:34 2014 +0300
    
        drm/i915: Fix mmio vs. CS flip race on ILK+
    
    Testcase: igt/kms_flip/flip-vs-panning-vs-hang
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2579ce3eb6aedd837d7ea583ed498d5061af972
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Nov 14 10:09:49 2014 +0100

    drm/i915: Kick fbdev before vgacon
    
    commit 0485c9dc24ec0939b42ca5104c0373297506b555 upstream.
    
    It's magic, but it seems to work.
    
    This fixes a regression introduced in
    
    commit 1bb9e632a0aeee1121e652ee4dc80e5e6f14bcd2
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Tue Jul 8 10:02:43 2014 +0200
    
        drm/i915: Only unbind vgacon, not other console drivers
    
    My best guess is that the vga fbdev driver falls over if we rip out
    parts of vgacon. Hooray.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82439
    Reported-and-tested-by: Lv Zheng <lv.zheng@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 454a87ce581cec28d88da251f85b4bcfe5938a0f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Nov 14 09:25:29 2014 +0100

    drm/i915: drop WaSetupGtModeTdRowDispatch:snb
    
    commit 2208d655a91f9879bd9a39ff9df05dd668b3512c upstream.
    
    This reverts the regressing
    
    commit 6547fbdbfff62c99e4f7b4f985ff8b3454f33b0f
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Fri Dec 14 23:38:29 2012 +0100
    
        drm/i915: Implement WaSetupGtModeTdRowDispatch
    
    that causes GPU hangs immediately on boot.
    
    Reported-by: Leo Wolf <jclw@ymail.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79996
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    [Jani: amended the commit message slightly.]
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b48f096b4996401fd707e989a9c6c7447404531
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Nov 19 13:12:54 2014 -0500

    drm/radeon: disable native backlight control on pre-r6xx asics (v2)
    
    commit b7bc596ebbe0cddc97d76ef9309f64471bbf13eb upstream.
    
    Just use the acpi interface.  That's what windows uses on this
    generation and it's the only thing that seems to work reliably
    on these generation parts.
    
    You can still force the native backlight interface by setting
    radeon.backlight=1
    
    Bug:
    https://bugzilla.kernel.org/show_bug.cgi?id=88501
    
    v2: merge into above if/else block
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ddf2f3a9a94f98c99a46d75bebeeb743b29d71c0
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Nov 12 19:17:02 2014 -0500

    drm/radeon: fix endian swapping in vbios fetch for tdp table
    
    commit 28731d5818ae25b92d1fb82fe0ac196e97102c1b upstream.
    
    Value needs to be swapped on BE.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49c04e670656d8fac9b32d268ceff34adced15d0
Author: James Hogan <james.hogan@imgtec.com>
Date:   Fri Nov 14 15:32:09 2014 +0000

    clk-divider: Fix READ_ONLY when divider > 1
    
    commit e6d5e7d90be92cee626d7ec16ca9b06f1eed710b upstream.
    
    Commit 79c6ab509558 (clk: divider: add CLK_DIVIDER_READ_ONLY flag) in
    v3.16 introduced the CLK_DIVIDER_READ_ONLY flag which caused the
    recalc_rate() and round_rate() clock callbacks to be omitted.
    
    However using this flag has the unfortunate side effect of causing the
    clock recalculation code when a clock rate change is attempted to always
    treat it as a pass-through clock, i.e. with a fixed divide of 1, which
    may not be the case. Child clock rates are then recalculated using the
    wrong parent rate.
    
    Therefore instead of dropping the recalc_rate() and round_rate()
    callbacks, alter clk_divider_bestdiv() to always report the current
    divider as the best divider so that it is never altered.
    
    For me the read only clock was the system clock, which divided the PLL
    rate by 2, from which both the UART and the SPI clocks were divided.
    Initial setting of the UART rate set it correctly, but when the SPI
    clock was set, the other child clocks were miscalculated. The UART clock
    was recalculated using the PLL rate as the parent rate, resulting in a
    UART new_rate of double what it should be, and a UART which spewed forth
    garbage when the rate changes were propagated.
    
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Thomas Abraham <thomas.ab@samsung.com>
    Cc: Tomasz Figa <t.figa@samsung.com>
    Cc: Max Schwarz <max.schwarz@online.de>
    Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
    Signed-off-by: Michael Turquette <mturquette@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 293cad63678fb72da7360645f2ecbbd83a6fd820
Author: Maurizio Lombardi <mlombard@redhat.com>
Date:   Thu Nov 20 11:17:33 2014 +0100

    bnx2fc: do not add shared skbs to the fcoe_rx_list
    
    commit 01a4cc4d0cd6a836c7b923760e8eb1cbb6a47258 upstream.
    
    In some cases, the fcoe_rx_list may contains multiple instances
    of the same skb (the so called "shared skbs").
    
    the bnx2fc_l2_rcv thread is a loop that extracts a skb from the list,
    modifies (and destroys) its content and then proceed to the next one.
    The problem is that if the skb is shared, the remaining instances will
    be corrupted.
    
    The solution is to use skb_share_check() before adding the skb to the
    fcoe_rx_list.
    
    [ 6286.808725] ------------[ cut here ]------------
    [ 6286.808729] WARNING: at include/scsi/fc_frame.h:173 bnx2fc_l2_rcv_thread+0x425/0x450 [bnx2fc]()
    [ 6286.808748] Modules linked in: bnx2x(-) mdio dm_service_time bnx2fc cnic uio fcoe libfcoe 8021q garp stp mrp libfc llc scsi_transport_fc scsi_tgt sg iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel e1000e ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper ptp cryptd hpilo serio_raw hpwdt lpc_ich pps_core ipmi_si pcspkr mfd_core ipmi_msghandler shpchp pcc_cpufreq mperf nfsd auth_rpcgss nfs_acl lockd sunrpc dm_multipath xfs libcrc32c ata_generic pata_acpi sd_mod crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit ata_piix drm_kms_helper ttm drm libata i2c_core hpsa dm_mirror dm_region_hash dm_log dm_mod [last unloaded: mdio]
    [ 6286.808750] CPU: 3 PID: 1304 Comm: bnx2fc_l2_threa Not tainted 3.10.0-121.el7.x86_64 #1
    [ 6286.808750] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013
    [ 6286.808752]  0000000000000000 000000000b36e715 ffff8800deba1e00 ffffffff815ec0ba
    [ 6286.808753]  ffff8800deba1e38 ffffffff8105dee1 ffffffffa05618c0 ffff8801e4c81888
    [ 6286.808754]  ffffe8ffff663868 ffff8801f402b180 ffff8801f56bc000 ffff8800deba1e48
    [ 6286.808754] Call Trace:
    [ 6286.808759]  [<ffffffff815ec0ba>] dump_stack+0x19/0x1b
    [ 6286.808762]  [<ffffffff8105dee1>] warn_slowpath_common+0x61/0x80
    [ 6286.808763]  [<ffffffff8105e00a>] warn_slowpath_null+0x1a/0x20
    [ 6286.808765]  [<ffffffffa054f415>] bnx2fc_l2_rcv_thread+0x425/0x450 [bnx2fc]
    [ 6286.808767]  [<ffffffffa054eff0>] ? bnx2fc_disable+0x90/0x90 [bnx2fc]
    [ 6286.808769]  [<ffffffff81085aef>] kthread+0xcf/0xe0
    [ 6286.808770]  [<ffffffff81085a20>] ? kthread_create_on_node+0x140/0x140
    [ 6286.808772]  [<ffffffff815fc76c>] ret_from_fork+0x7c/0xb0
    [ 6286.808773]  [<ffffffff81085a20>] ? kthread_create_on_node+0x140/0x140
    [ 6286.808774] ---[ end trace c6cdb939184ccb4e ]---
    
    Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
    Acked-by: Chad Dupuis <chad.dupuis@qlogic.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1d50bd9bd15eded3812bc9ac1bca6875772fbb7
Author: Boris Brezillon <boris.brezillon@free-electrons.com>
Date:   Tue Nov 11 14:33:36 2014 +0100

    irqchip: atmel-aic: Fix irqdomain initialization
    
    commit 45977fe35bf014f5cf9552717e1320783398ae0d upstream.
    
    First of all IRQCHIP_SKIP_SET_WAKE is not a valid irq_gc_flags and thus
    should not be passed as the last argument of
    irq_alloc_domain_generic_chips.
    
    Then pass the correct handler (handle_fasteoi_irq) to
    irq_alloc_domain_generic_chips instead of manually re-setting it in the
    initialization loop.
    
    And eventually initialize default irq flags to the pseudo standard:
    IRQ_REQUEST | IRQ_PROBE | IRQ_AUTOEN.
    
    Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Tested-by: Kevin Hilman <khilman@linaro.org>
    Fixes: b1479ebb77200 ("irqchip: atmel-aic: Add atmel AIC/AIC5 drivers")
    Link: https://lkml.kernel.org/r/1415712816-9202-1-git-send-email-boris.brezillon@free-electrons.com
    Signed-off-by: Jason Cooper <jason@lakedaemon.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 461692058ec81c61ce2642097d256ffcaf8897cf
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Fri Nov 21 23:52:53 2014 -0800

    ixgbe: fix use after free adapter->state test in ixgbe_remove/ixgbe_probe
    
    commit b5b2ffc0574e1f271d79b6b992ee382dc9d5eaa8 upstream.
    
    While working on a different issue, I noticed an annoying use
    after free bug on my machine when unloading the ixgbe driver:
    
    [ 8642.318797] ixgbe 0000:02:00.1: removed PHC on p2p2
    [ 8642.742716] ixgbe 0000:02:00.1: complete
    [ 8642.743784] BUG: unable to handle kernel paging request at ffff8807d3740a90
    [ 8642.744828] IP: [<ffffffffa01c77dc>] ixgbe_remove+0xfc/0x1b0 [ixgbe]
    [ 8642.745886] PGD 20c6067 PUD 81c1f6067 PMD 81c15a067 PTE 80000007d3740060
    [ 8642.746956] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
    [ 8642.748039] Modules linked in: [...]
    [ 8642.752929] CPU: 1 PID: 1225 Comm: rmmod Not tainted 3.18.0-rc2+ #49
    [ 8642.754203] Hardware name: Supermicro X10SLM-F/X10SLM-F, BIOS 1.1b 11/01/2013
    [ 8642.755505] task: ffff8807e34d3fe0 ti: ffff8807b7204000 task.ti: ffff8807b7204000
    [ 8642.756831] RIP: 0010:[<ffffffffa01c77dc>]  [<ffffffffa01c77dc>] ixgbe_remove+0xfc/0x1b0 [ixgbe]
    [...]
    [ 8642.774335] Stack:
    [ 8642.775805]  ffff8807ee824098 ffff8807ee824098 ffffffffa01f3000 ffff8807ee824000
    [ 8642.777326]  ffff8807b7207e18 ffffffff8137720f ffff8807ee824098 ffff8807ee824098
    [ 8642.778848]  ffffffffa01f3068 ffff8807ee8240f8 ffff8807b7207e38 ffffffff8144180f
    [ 8642.780365] Call Trace:
    [ 8642.781869]  [<ffffffff8137720f>] pci_device_remove+0x3f/0xc0
    [ 8642.783395]  [<ffffffff8144180f>] __device_release_driver+0x7f/0xf0
    [ 8642.784876]  [<ffffffff814421f8>] driver_detach+0xb8/0xc0
    [ 8642.786352]  [<ffffffff814414a9>] bus_remove_driver+0x59/0xe0
    [ 8642.787783]  [<ffffffff814429d0>] driver_unregister+0x30/0x70
    [ 8642.789202]  [<ffffffff81375c65>] pci_unregister_driver+0x25/0xa0
    [ 8642.790657]  [<ffffffffa01eb38e>] ixgbe_exit_module+0x1c/0xc8e [ixgbe]
    [ 8642.792064]  [<ffffffff810f93a2>] SyS_delete_module+0x132/0x1c0
    [ 8642.793450]  [<ffffffff81012c61>] ? do_notify_resume+0x61/0xa0
    [ 8642.794837]  [<ffffffff816d2029>] system_call_fastpath+0x12/0x17
    
    The issue is that test_and_set_bit() done on adapter->state is being
    performed *after* the netdevice has been freed via free_netdev().
    
    When netdev is being allocated on initialization time, it allocates
    a private area, here struct ixgbe_adapter, that resides after the
    net_device structure. In ixgbe_probe(), the device init routine,
    we set up the adapter after alloc_etherdev_mq() on the private area
    and add a reference for the pci_dev as well via pci_set_drvdata().
    
    Both in the error path of ixgbe_probe(), but also on module unload
    when ixgbe_remove() is being called, commit 41c62843eb6a ("ixgbe:
    Fix rcu warnings induced by LER") accesses adapter after free_netdev().
    The patch stores the result in a bool and thus fixes above oops on my
    side.
    
    Fixes: 41c62843eb6a ("ixgbe: Fix rcu warnings induced by LER")
    Cc: Mark Rustad <mark.d.rustad@intel.com>
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 927a171886e895b174ed99a06d31fc05bc03750e
Author: Vlad Yasevich <vyasevich@gmail.com>
Date:   Fri Nov 21 23:52:52 2014 -0800

    ixgbe: Correctly disable VLAN filter in promiscuous mode
    
    commit 4556dc591691fca743518edb24f15fbc83b5c8ef upstream.
    
    IXGBE adapter seems to require that VLAN filtering be enabled if
    VMDQ or SRIOV are enabled.  When those functions are disabled,
    VLAN filtering may be disabled in promiscuous mode.
    
    Prior to commit a9b8943ee129 ("ixgbe: remove vlan_filter_disable
    and enable functions")
    
    The logic was correct.  However, after the commit the logic
    got reversed and VLAN filtered in now turned on when VMDQ/SRIOV
    is disabled.
    
    This patch changes the condition to enable hw vlan filtered
    when VMDQ or SRIOV is enabled.
    
    Fixes: a9b8943ee129 ("ixgbe: remove vlan_filter_disable and enable functions")
    CC: Jacob Keller <jacob.e.keller@intel.com>
    Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
    Acked-by: Emil Tantilov <emil.s.tantilov@intel.com>
    Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ffb2d0c0936e44b5e81c34353b539f9ca408e8c
Author: Lu Baolu <baolu.lu@linux.intel.com>
Date:   Tue Nov 18 11:27:13 2014 +0200

    Revert "xhci: clear root port wake on bits if controller isn't wake-up capable"
    
    commit 9b41ebd3cf0f68d8cad779d3eeba336f78262e43 upstream.
    
    commit ff8cbf250b44 ("xhci: clear root port wake on bits if controller isn't")
    can cause device detection error if runtime PM is enabled, and S3 wake
    is disabled. Revert it.
    https://bugzilla.kernel.org/show_bug.cgi?id=85701
    
    This commit got into stable and should be reverted from there as well.
    
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Reported-by: Dmitry Nezhevenko <dion@inhex.net>
    [Mathias Nyman: reword commit message]
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ba3fa868ab8b5f656f04064a7d266cc017fb347
Author: Jane Zhou <a17711@motorola.com>
Date:   Mon Nov 24 11:44:08 2014 -0800

    net/ping: handle protocol mismatching scenario
    
    commit 91a0b603469069cdcce4d572b7525ffc9fd352a6 upstream.
    
    ping_lookup() may return a wrong sock if sk_buff's and sock's protocols
    dont' match. For example, sk_buff's protocol is ETH_P_IPV6, but sock's
    sk_family is AF_INET, in that case, if sk->sk_bound_dev_if is zero, a wrong
    sock will be returned.
    the fix is to "continue" the searching, if no matching, return NULL.
    
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
    Cc: James Morris <jmorris@namei.org>
    Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
    Cc: Patrick McHardy <kaber@trash.net>
    Cc: netdev@vger.kernel.org
    Signed-off-by: Jane Zhou <a17711@motorola.com>
    Signed-off-by: Yiwei Zhao <gbjc64@motorola.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48188bcb26e58365948860f29c81aaadcd12f3ab
Author: Arnaud Ebalard <arno@natisbad.org>
Date:   Wed Nov 19 22:52:36 2014 +0100

    hwmon: (g762) fix call to devm_hwmon_device_register_with_groups()
    
    commit 6b19b66013cfe608d63f0dab38834bbaceb0217a upstream.
    
    g762_remove() needs to first call hwmon_device_unregister() and then
    g762_of_clock_disable(). For that reason, it is not possible to
    convert it to devm_hwmon_device_register_with_groups() and the
    the non device managed version must be used.
    
    This is correctly stated in commit message for 398e16db6262 ("hwmon:
    (g762) Convert to hwmon_device_register_with_groups") but the
    associated changes do in fact introduce a call to the device managed
    version of the function.
    
    This patch fixes that typo by switching to the non devm_ version.
    
    Fixes: 398e16db6262 ("hwmon: (g762) Convert to hwmon_device_register_with_groups")
    Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e14dcec1f787eca0daf0c9302c8583c2e4cf9fa
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Mon Nov 24 14:17:08 2014 +1100

    sound/radeon: Move 64-bit MSI quirk from arch to driver
    
    commit db79afa1e57925ba96ab18514c0ebe42a28e393e upstream.
    
    A number of radeon cards have a HW limitation causing them to be
    unable to generate the full 64-bit of address bits for MSIs. This
    breaks MSIs on some platforms such as POWER machines.
    
    We used to have a powerpc specific quirk to address that on a
    single card, but this doesn't scale very well, this is better
    put under control of the drivers who know precisely what a given
    HW revision can do.
    
    We now have a generic quirk in the PCI code. We should set it
    appropriately for all radeon's from the audio driver.
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Reviewed-by: Takashi Iwai <tiwai@suse.de>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1fe01fbe4220c6d91441aa6416275a6ef984a132
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Wed Nov 19 12:47:50 2014 -0500

    nfsd: Fix slot wake up race in the nfsv4.1 callback code
    
    commit c6c15e1ed303ffc47e696ea1c9a9df1761c1f603 upstream.
    
    The currect code for nfsd41_cb_get_slot() and nfsd4_cb_done() has no
    locking in order to guarantee atomicity, and so allows for races of
    the form.
    
    Task 1                                  Task 2
    ======                                  ======
    if (test_and_set_bit(0) != 0) {
                                            clear_bit(0)
                                            rpc_wake_up_next(queue)
            rpc_sleep_on(queue)
            return false;
    }
    
    This patch breaks the race condition by adding a retest of the bit
    after the call to rpc_sleep_on().
    
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d97056a5ec2b1a110499f6906fbe58865d21ee8a
Author: Christoph Hellwig <hch@lst.de>
Date:   Sat Nov 8 13:11:03 2014 +0100

    nfsd: correctly define v4.2 support attributes
    
    commit 6d0ba0432a5e10bc714ba9c5adc460e726e5fbb4 upstream.
    
    Even when security labels are disabled we support at least the same
    attributes as v4.1.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85ebf941723c4f32d78fe921bce10b772ce3dd47
Author: Liad Kaufman <liad.kaufman@intel.com>
Date:   Mon Nov 10 19:25:22 2014 +0200

    iwlwifi: pcie: fix prph dump length
    
    commit 87dd634ae72bb8f6d0dd12f1cbbc67c7da6dba3b upstream.
    
    The length counting previously done had an error in it, causing
    the length down the data dumping function to be shorter than it
    should be, causing the end of the data to get truncated off and
    lost.
    
    Fixes: 67c65f2cf710 ("iwlwifi: dump periphery registers to fw-error-dump")
    Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
    Reviewed-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 38183f10bd3894811248340efac196d3d77c0f64
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Tue Nov 11 14:28:47 2014 +0100

    rt2x00: do not align payload on modern H/W
    
    commit cfd9167af14eb4ec21517a32911d460083ee3d59 upstream.
    
    RT2800 and newer hardware require padding between header and payload if
    header length is not multiple of 4.
    
    For historical reasons we also align payload to to 4 bytes boundary, but
    such alignment is not needed on modern H/W.
    
    Patch fixes skb_under_panic problems reported from time to time:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=84911
    https://bugzilla.kernel.org/show_bug.cgi?id=72471
    http://marc.info/?l=linux-wireless&m=139108549530402&w=2
    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1087591
    
    Panic happened because we eat 4 bytes of skb headroom on each
    (re)transmission when sending frame without the payload and the header
    length not being multiple of 4 (i.e. QoS header has 26 bytes). On such
    case because paylad_aling=2 is bigger than header_align=0 we increase
    header_align by 4 bytes. To prevent that we could change the check to:
    
    	if (payload_length && payload_align > header_align)
    		header_align += 4;
    
    but not aligning payload at all is more effective and alignment is not
    really needed by H/W (that has been tested on OpenWrt project for few
    years now).
    
    Reported-and-tested-by: Antti S. Lankila <alankila@bel.fi>
    Debugged-by: Antti S. Lankila <alankila@bel.fi>
    Reported-by: Henrik Asp <solenskiner@gmail.com>
    Originally-From: Helmut Schaa <helmut.schaa@googlemail.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5aa3877513cff513d4ac4b8300e77349236c620a
Author: Maxime Ripard <maxime.ripard@free-electrons.com>
Date:   Tue Nov 11 19:35:52 2014 +0100

    dmaengine: sun6i: Fix memcpy operation
    
    commit 1f9cd915b64bb95f7b41667b4bf8b22f0a0a557b upstream.
    
    The prep_memcpy call was not setting any meaningful burst and width because it
    was relying on the dma_slave_config was not set already.
    
    Rework the needed conversion functions, and hardcode the width and burst to
    use.
    
    Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f731713c2ce5651b3b241ccf941da27425c65cdd
Author: Thomas Körper <thomas.koerper@esd.eu>
Date:   Fri Oct 31 07:33:54 2014 +0100

    can: dev: avoid calling kfree_skb() from interrupt context
    
    commit 5247a589c24022ab34e780039cc8000c48f2035e upstream.
    
    ikfree_skb() is Called in can_free_echo_skb(), which might be called from (TX
    Error) interrupt, which triggers the folloing warning:
    
    [ 1153.360705] ------------[ cut here ]------------
    [ 1153.360715] WARNING: CPU: 0 PID: 31 at net/core/skbuff.c:563 skb_release_head_state+0xb9/0xd0()
    [ 1153.360772] Call Trace:
    [ 1153.360778]  [<c167906f>] dump_stack+0x41/0x52
    [ 1153.360782]  [<c105bb7e>] warn_slowpath_common+0x7e/0xa0
    [ 1153.360784]  [<c158b909>] ? skb_release_head_state+0xb9/0xd0
    [ 1153.360786]  [<c158b909>] ? skb_release_head_state+0xb9/0xd0
    [ 1153.360788]  [<c105bc42>] warn_slowpath_null+0x22/0x30
    [ 1153.360791]  [<c158b909>] skb_release_head_state+0xb9/0xd0
    [ 1153.360793]  [<c158be90>] skb_release_all+0x10/0x30
    [ 1153.360795]  [<c158bf06>] kfree_skb+0x36/0x80
    [ 1153.360799]  [<f8486938>] ? can_free_echo_skb+0x28/0x40 [can_dev]
    [ 1153.360802]  [<f8486938>] can_free_echo_skb+0x28/0x40 [can_dev]
    [ 1153.360805]  [<f849a12c>] esd_pci402_interrupt+0x34c/0x57a [esd402]
    [ 1153.360809]  [<c10a75b5>] handle_irq_event_percpu+0x35/0x180
    [ 1153.360811]  [<c10a7623>] ? handle_irq_event_percpu+0xa3/0x180
    [ 1153.360813]  [<c10a7731>] handle_irq_event+0x31/0x50
    [ 1153.360816]  [<c10a9c7f>] handle_fasteoi_irq+0x6f/0x120
    [ 1153.360818]  [<c10a9c10>] ? handle_edge_irq+0x110/0x110
    [ 1153.360822]  [<c1011b61>] handle_irq+0x71/0x90
    [ 1153.360823]  <IRQ>  [<c168152c>] do_IRQ+0x3c/0xd0
    [ 1153.360829]  [<c1680b6c>] common_interrupt+0x2c/0x34
    [ 1153.360834]  [<c107d277>] ? finish_task_switch+0x47/0xf0
    [ 1153.360836]  [<c167c27b>] __schedule+0x35b/0x7e0
    [ 1153.360839]  [<c10a5334>] ? console_unlock+0x2c4/0x4d0
    [ 1153.360842]  [<c13df500>] ? n_tty_receive_buf_common+0x890/0x890
    [ 1153.360845]  [<c10707b6>] ? process_one_work+0x196/0x370
    [ 1153.360847]  [<c167c723>] schedule+0x23/0x60
    [ 1153.360849]  [<c1070de1>] worker_thread+0x161/0x460
    [ 1153.360852]  [<c1090fcf>] ? __wake_up_locked+0x1f/0x30
    [ 1153.360854]  [<c1070c80>] ? rescuer_thread+0x2f0/0x2f0
    [ 1153.360856]  [<c1074f01>] kthread+0xa1/0xc0
    [ 1153.360859]  [<c1680401>] ret_from_kernel_thread+0x21/0x30
    [ 1153.360861]  [<c1074e60>] ? kthread_create_on_node+0x110/0x110
    [ 1153.360863] ---[ end trace 5ff83639cbb74b35 ]---
    
    This patch replaces the kfree_skb() by dev_kfree_skb_any().
    
    Signed-off-by: Thomas Körper <thomas.koerper@esd.eu>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 744e7933a284f0d1c6b55a475c92e5b1d59b2481
Author: Christian Sünkenberg <christian.suenkenberg@hfg-karlsruhe.de>
Date:   Tue Nov 18 20:23:32 2014 +0100

    scsi: add Intel Multi-Flex to scsi scan blacklist
    
    commit 1899045510ff109980d9cc34e330fd8ca3631871 upstream.
    
    Intel Multi-Flex LUNs choke on REPORT SUPPORTED OPERATION CODES
    resulting in sd_mod hanging for several minutes on startup.
    The issue was introduced with WRITE SAME discovery heuristics.
    
    Fixes: 5db44863b6eb ("[SCSI] sd: Implement support for WRITE SAME")
    Signed-off-by: Christian Sünkenberg <christian.suenkenberg@hfg-karlsruhe.de>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aec8181a5a4acb9a8037c4bcb6357bd28f788134
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed Oct 8 06:19:20 2014 +0000

    vhost-scsi: Take configfs group dependency during VHOST_SCSI_SET_ENDPOINT
    
    commit ab8edab132829b26dd13db6caca3c242cce35dc1 upstream.
    
    This patch addresses a bug where individual vhost-scsi configfs endpoint
    groups can be removed from below while active exports to QEMU userspace
    still exist, resulting in an OOPs.
    
    It adds a configfs_depend_item() in vhost_scsi_set_endpoint() to obtain
    an explicit dependency on se_tpg->tpg_group in order to prevent individual
    vhost-scsi WWPN endpoints from being released via normal configfs methods
    while an QEMU ioctl reference still exists.
    
    Also, add matching configfs_undepend_item() in vhost_scsi_clear_endpoint()
    to release the dependency, once QEMU's reference to the individual group
    at /sys/kernel/config/target/vhost/$WWPN/$TPGT is released.
    
    (Fix up vhost_scsi_clear_endpoint() error path - DanC)
    
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Stefan Hajnoczi <stefanha@redhat.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6184818cd6ed588714e56fc6ee7327eb5f570f91
Author: Ronald Wahl <ronald.wahl@raritan.com>
Date:   Thu Nov 6 11:52:13 2014 +0100

    mac80211: Fix regression that triggers a kernel BUG with CCMP
    
    commit 4f031fa9f188b2b0641ac20087d9e16bcfb4e49d upstream.
    
    Commit 7ec7c4a9a686c608315739ab6a2b0527a240883c (mac80211: port CCMP to
    cryptoapi's CCM driver) introduced a regression when decrypting empty
    packets (data_len == 0). This will lead to backtraces like:
    
    (scatterwalk_start) from [<c01312f4>] (scatterwalk_map_and_copy+0x2c/0xa8)
    (scatterwalk_map_and_copy) from [<c013a5a0>] (crypto_ccm_decrypt+0x7c/0x25c)
    (crypto_ccm_decrypt) from [<c032886c>] (ieee80211_aes_ccm_decrypt+0x160/0x170)
    (ieee80211_aes_ccm_decrypt) from [<c031c628>] (ieee80211_crypto_ccmp_decrypt+0x1ac/0x238)
    (ieee80211_crypto_ccmp_decrypt) from [<c032ef28>] (ieee80211_rx_handlers+0x870/0x1d24)
    (ieee80211_rx_handlers) from [<c0330c7c>] (ieee80211_prepare_and_rx_handle+0x8a0/0x91c)
    (ieee80211_prepare_and_rx_handle) from [<c0331260>] (ieee80211_rx+0x568/0x730)
    (ieee80211_rx) from [<c01d3054>] (__carl9170_rx+0x94c/0xa20)
    (__carl9170_rx) from [<c01d3324>] (carl9170_rx_stream+0x1fc/0x320)
    (carl9170_rx_stream) from [<c01cbccc>] (carl9170_usb_tasklet+0x80/0xc8)
    (carl9170_usb_tasklet) from [<c00199dc>] (tasklet_hi_action+0x88/0xcc)
    (tasklet_hi_action) from [<c00193c8>] (__do_softirq+0xcc/0x200)
    (__do_softirq) from [<c0019734>] (irq_exit+0x80/0xe0)
    (irq_exit) from [<c0009c10>] (handle_IRQ+0x64/0x80)
    (handle_IRQ) from [<c000c3a0>] (__irq_svc+0x40/0x4c)
    (__irq_svc) from [<c0009d44>] (arch_cpu_idle+0x2c/0x34)
    
    Such packets can appear for example when using the carl9170 wireless driver
    because hardware sometimes generates garbage when the internal FIFO overruns.
    
    This patch adds an additional length check.
    
    Fixes: 7ec7c4a9a686 ("mac80211: port CCMP to cryptoapi's CCM driver")
    Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Ronald Wahl <ronald.wahl@raritan.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b1b944c5a4eb308f58ff6ba6630b2d58dd4511d3
Author: Qipan Li <Qipan.Li@csr.com>
Date:   Mon Nov 17 23:17:02 2014 +0800

    spi: sirf: fix word width configuration
    
    commit 9c4b19a07dddda3ba35a2eb9b4134d485908e2f5 upstream.
    
    commit 8c328a262f ("spi: sirf: Avoid duplicate code in various
    bits_per_word cases") is wrong in setting data width register of
    fifo is not right, it should use sspi->word_width >> 1 to set
    related bits. According to hardware spec, the mapping between
    register value and data width:
    0 - byte
    1 - WORD
    2 - DWORD
    
    Fixes: 8c328a262f ("spi: sirf: Avoid duplicate code in various bits_per_word cases") is wrong in setting data width register of
    Signed-off-by: Qipan Li <Qipan.Li@csr.com>
    Signed-off-by: Barry Song <Baohua.Song@csr.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f5dbae2894829b607ac5c0558e3ae0b34f8a8c7
Author: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date:   Mon Nov 17 09:14:31 2014 +0000

    spi: Fix mapping from vmalloc-ed buffer to scatter list
    
    commit c1aefbdd050e1fb15e92bcaf34d95b17ea952097 upstream.
    
    We can only use page_address on memory that has been mapped using kmap,
    when the buffer passed to the SPI has been allocated by vmalloc the page
    has not necessarily been mapped through kmap. This means sometimes
    page_address will return NULL causing the pointer we pass to sg_set_buf
    to be invalid.
    
    As we only call page_address so that we can pass a virtual address to
    sg_set_buf which will then immediately call virt_to_page on it, fix this
    by calling sg_set_page directly rather then relying on the sg_set_buf
    helper.
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29d04b78c896725f55c0dc4c3a23eba18a545c73
Author: Thor Thayer <tthayer@opensource.altera.com>
Date:   Thu Nov 6 13:54:27 2014 -0600

    spi: dw: Fix dynamic speed change.
    
    commit 0a8727e69778683495058852f783eeda141a754e upstream.
    
    An IOCTL call that calls spi_setup() and then dw_spi_setup() will
    overwrite the persisted last transfer speed. On each transfer, the
    SPI speed is compared to the last transfer speed to determine if the
    clock divider registers need to be updated (did the speed change?).
    This bug was observed with the spidev driver using spi-config to
    update the max transfer speed.
    
    This fix: Don't overwrite the persisted last transaction clock speed
    when updating the SPI parameters in dw_spi_setup(). On the next
    transaction, the new speed won't match the persisted last speed
    and the hardware registers will be updated.
    On initialization, the persisted last transaction clock
    speed will be 0 but will be updated after the first SPI
    transaction.
    
    Move zeroed clock divider check into clock change test because
    chip->clk_div is zero on startup and would cause a divide-by-zero
    error. The calculation was wrong as well (can't support odd #).
    
    Reported-by: Vlastimil Setka <setka@vsis.cz>
    Signed-off-by: Vlastimil Setka <setka@vsis.cz>
    Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eef17d1416b9ebbf016af3346addf278b82bc9df
Author: Sagi Grimberg <sagig@dev.mellanox.co.il>
Date:   Tue Oct 28 13:45:03 2014 -0700

    iser-target: Handle DEVICE_REMOVAL event on network portal listener correctly
    
    commit 3b726ae2de02a406cc91903f80132daee37b6f1b upstream.
    
    In this case the cm_id->context is the isert_np, and the cm_id->qp
    is NULL, so use that to distinct the cases.
    
    Since we don't expect any other events on this cm_id we can
    just return -1 for explicit termination of the cm_id by the
    cma layer.
    
    Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f627a34869c287134b88879d8ce1bc1d542f73a5
Author: Roland Dreier <roland@purestorage.com>
Date:   Tue Oct 14 14:16:24 2014 -0700

    target: Don't call TFO->write_pending if data_length == 0
    
    commit 885e7b0e181c14e4d0ddd26c688bad2b84c1ada9 upstream.
    
    If an initiator sends a zero-length command (e.g. TEST UNIT READY) but
    sets the transfer direction in the transport layer to indicate a
    data-out phase, we still shouldn't try to transfer data.  At best it's
    a NOP, and depending on the transport, we might crash on an
    uninitialized sg list.
    
    Reported-by: Craig Watson <craig.watson@vanguard-rugged.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 674d238eaee130a0686d06cbcd16e045de925420
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Sun Oct 19 18:05:33 2014 +0300

    srp-target: Retry when QP creation fails with ENOMEM
    
    commit ab477c1ff5e0a744c072404bf7db51bfe1f05b6e upstream.
    
    It is not guaranteed to that srp_sq_size is supported
    by the HCA. So if we failed to create the QP with ENOMEM,
    try with a smaller srp_sq_size. Keep it up until we hit
    MIN_SRPT_SQ_SIZE, then fail the connection.
    
    Reported-by: Mark Lehrer <lehrer@gmail.com>
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b5e10f1c49d03150864e0d8e59b152f9e1ab5ed
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Nov 25 00:38:17 2014 -0800

    Input: xpad - use proper endpoint type
    
    commit a1f9a4072655843fc03186acbad65990cc05dd2d upstream.
    
    The xpad wireless endpoint is not a bulk endpoint on my devices, but
    rather an interrupt one, so the USB core complains when it is submitted.
    I'm guessing that the author really did mean that this should be an
    interrupt urb, but as there are a zillion different xpad devices out
    there, let's cover out bases and handle both bulk and interrupt
    endpoints just as easily.
    
    Signed-off-by: "Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41ca7e138b2eff69434468487e1efcf4d7119902
Author: Ben Sagal <bensagal@gmail.com>
Date:   Sun Nov 16 17:23:40 2014 -0800

    Input: synaptics - adjust min/max on Thinkpad E540
    
    commit bce4f9e764c36bc35dd5c9cf9e057c09f422397d upstream.
    
    The LEN2006 Synaptics touchpad (as found in Thinkpad E540) returns wrong
    min max values.
    
    touchpad-edge-detector output:
    >  Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event6
    >  Move one finger around the touchpad to detect the actual edges
    >  Kernel says:    x [1472..5674], y [1408..4684]
    >  Touchpad sends: x [1264..5675], y [1171..4688]
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88211
    Signed-off-by: Binyamin Sagal <bensagal@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4c2506f41c9c061e4a7e9b2e02ed0377ddfed14
Author: Vladimir Murzin <vladimir.murzin@arm.com>
Date:   Thu Nov 27 11:39:04 2014 +0100

    ARM: 8226/1: cacheflush: get rid of restarting block
    
    commit 3f4aa45ceea5789a4aade536acc27f2e0d3da5e1 upstream.
    
    We cannot restart cacheflush safely if a process provides user-defined
    signal handler and signal is pending. In this case -EINTR is returned
    and it is expected that process re-invokes syscall. However, there are
    a few problems with that:
     * looks like nobody bothers checking return value from cacheflush
     * but if it did, we don't provide the restart address for that, so the
       process has to use the same range again
     * ...and again, what might lead to looping forever
    
    So, remove cacheflush restarting code and terminate cache flushing
    as early as fatal signal is pending.
    
    Reported-by: Chanho Min <chanho.min@lge.com>
    Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
    Acked-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 856b4c2a8dd01ed8bc9386555d5c14ab50983e14
Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date:   Tue Nov 25 18:43:15 2014 +0100

    ARM: 8222/1: mvebu: enable strex backoff delay
    
    commit 995ab5189d1d7264e79e665dfa032a19b3ac646e upstream.
    
    Under extremely rare conditions, in an MPCore node consisting of at
    least 3 CPUs, two CPUs trying to perform a STREX to data on the same
    shared cache line can enter a livelock situation.
    
    This patch enables the HW mechanism that overcomes the bug. This fixes
    the incorrect setup of the STREX backoff delay bit due to a wrong
    description in the specification.
    
    Note that enabling the STREX backoff delay mechanism is done by
    leaving the bit *cleared*, while the bit was currently being set by
    the proc-v7.S code.
    
    [Thomas: adapt to latest mainline, slightly reword the commit log, add
    stable markers.]
    
    Fixes: de4901933f6d ("arm: mm: Add support for PJ4B cpu and init routines")
    
    Signed-off-by: Nadav Haklai <nadavh@marvell.com>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
    Acked-by: Jason Cooper <jason@lakedaemon.net>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f5a994f524d36475501ed3f78b101983a4779e9
Author: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date:   Fri Nov 21 15:29:00 2014 +0100

    ARM: 8216/1: xscale: correct auxiliary register in suspend/resume
    
    commit ef59a20ba375aeb97b3150a118318884743452a8 upstream.
    
    According to the manuals I have, XScale auxiliary register should be
    reached with opc_2 = 1 instead of crn = 1. cpu_xscale_proc_init
    correctly uses c1, c0, 1 arguments, but cpu_xscale_do_suspend and
    cpu_xscale_do_resume use c1, c1, 0. Correct suspend/resume functions to
    also use c1, c0, 1.
    
    The issue was primarily noticed thanks to qemu reporing "unsupported
    instruction" on the pxa suspend path. Confirmed in PXA210/250 and PXA255
    XScale Core manuals and in PXA270 and PXA320 Developers Guides.
    
    Harware tested by me on tosa (pxa255). Robert confirmed on pxa270 board.
    
    Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
    Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58e9cfe0c5ebd757efcd68261a33d2c64b360534
Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date:   Mon Oct 27 16:32:35 2014 +0100

    ARM: mvebu: add missing of_node_put() call in coherency.c
    
    commit 2eb04ae010a8fb165ba7aa56e9aa8e7980887dee upstream.
    
    There is a missing of_node_put() to decrement the device_node
    reference counter after a of_find_matching_node() in coherency_init().
    
    Fixes: 501f928e0097 ("ARM: mvebu: add a coherency_available() call")
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
    Link: https://lkml.kernel.org/r/1414423955-5933-4-git-send-email-thomas.petazzoni@free-electrons.com
    Signed-off-by: Jason Cooper <jason@lakedaemon.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f8d238e13cd3bdc43b1c2623755347a24f4ce7e
Author: Grant Likely <grant.likely@linaro.org>
Date:   Wed Nov 19 16:22:32 2014 +0000

    of/selftest: Fix off-by-one error in removal path
    
    commit c1a2086e2d8c4eb4e8630ba752e911ec180dec67 upstream.
    
    The removal path for selftest data has an off by one error that causes
    the code to dereference beyond the end of the nodes[] array on the first
    pass through. The old code only worked by chance on a lot of platforms,
    but the bug was recently exposed on aarch64.
    
    The fix is simple. Decrement the node count before dereferencing, not
    after.
    
    Reported-by: Kevin Hilman <khilman@linaro.org>
    Cc: Rob Herring <robh+dt@kernel.org>
    Cc: Gaurav Minocha <gaurav.minocha.os@gmail.com>

commit b7b660a4ddc1c09b6eec40a5c211d7082aaa2dd4
Author: Kevin Cernekee <cernekee@gmail.com>
Date:   Sun Nov 9 00:55:47 2014 -0800

    of: Fix crash if an earlycon driver is not found
    
    commit ab74d00a39f70e1bc34a01322bb59f3750ca7a8c upstream.
    
    __earlycon_of_table_sentinel.compatible is a char[128], not a pointer, so
    it will never be NULL.  Checking it against NULL causes the match loop to
    run past the end of the array, and eventually match a bogus entry, under
    the following conditions:
    
     - Kernel command line specifies "earlycon" with no parameters
     - DT has a stdout-path pointing to a UART node
     - The UART driver doesn't use OF_EARLYCON_DECLARE (or maybe the console
       driver is compiled out)
    
    Fix this by checking to see if match->compatible is a non-empty string.
    
    Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8371a5f957953542639df970e8ac58bb2feace42
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Sat Nov 1 17:35:31 2014 -0600

    of/irq: Drop obsolete 'interrupts' vs 'interrupts-extended' text
    
    commit 66865de4314caca30598244b86817e774c188afa upstream.
    
    a9ecdc0fdc54 ("of/irq: Fix lookup to use 'interrupts-extended' property
    first") updated the description to say that:
    
      - Both 'interrupts' and 'interrupts-extended' may be present
      - Software should prefer 'interrupts-extended'
      - Software that doesn't comprehend 'interrupts-extended' may use
        'interrupts'
    
    But there is still a paragraph at the end that prohibits having both and
    says 'interrupts' should be preferred.
    
    Remove the contradictory text.
    
    Fixes: a9ecdc0fdc54 ("of/irq: Fix lookup to use 'interrupts-extended' property first")
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Brian Norris <computersforpeace@gmail.com>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66ce2a9f4e620d22d277707c9e041c8a820ca1ab
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Nov 19 22:13:10 2014 +0100

    brcmfmac: don't include linux/unaligned/access_ok.h
    
    commit a1d69c60c44134f64945bbf6a6dfda22eaf4a214 upstream.
    
    This is a specific implementation, <asm/unaligned.h> is the
    multiplexer that has the arch-specific knowledge of which
    of the implementations needs to be used, so include that.
    
    This issue was revealed by kbuild testing
    when <asm/unaligned.h> was added in <linux/ieee80211.h>
    resulting in redefinition of get_unaligned_be16 (and
    probably others).
    
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Arend van Spriel <arend@broadcom.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 97729fa534ecbbcca0315cf71e8b5a57645d1d1a
Author: Dmitry Torokhov <dtor@chromium.org>
Date:   Fri Nov 14 14:12:21 2014 -0800

    brcmfmac: fix error handling of irq_of_parse_and_map
    
    commit 4c69f05eaa428e37890daf88b86a567ce615570b upstream.
    
    Return value of irq_of_parse_and_map() is unsigned int, with 0
    indicating failure, so testing for negative result never works.
    
    Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
    Acked-by: Arend van Spriel <arend@broadcom.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e309b740b1994a244de8c8a105ef9f1abf71167
Author: Arend van Spriel <arend@broadcom.com>
Date:   Tue Nov 11 13:58:44 2014 +0100

    brcmfmac: fix conversion of channel width 20MHZ_NOHT
    
    commit 0cd75b19899fd86b51a6480fb8c00dcd85a54591 upstream.
    
    The function chandef_to_chanspec() failed when converting a
    chandef with bandwidth set to NL80211_CHAN_WIDTH_20_NOHT. This
    was reported by user running the device in AP mode.
    
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 304 at
    	drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c:381
    		chandef_to_chanspec.isra.11+0x158/0x184()
    
    Modules linked in:
    
    CPU: 0 PID: 304 Comm: hostapd Not tainted 3.16.0-rc7-abb+g64aa90f #8
    
    [<c0014bb4>] (unwind_backtrace) from [<c0012314>] (show_stack+0x10/0x14)
    [<c0012314>] (show_stack) from [<c001d3f8>] (warn_slowpath_common+0x6c/0x8c)
    [<c001d3f8>] (warn_slowpath_common) from [<c001d4b4>] (warn_slowpath_null+0x1c/0x24)
    [<c001d4b4>] (warn_slowpath_null) from [<c03449a4>] (chandef_to_chanspec.isra.11+0x158/0x184)
    [<c03449a4>] (chandef_to_chanspec.isra.11) from [<c0348e00>] (brcmf_cfg80211_start_ap+0x1e4/0x614)
    [<c0348e00>] (brcmf_cfg80211_start_ap) from [<c04d1468>] (nl80211_start_ap+0x288/0x414)
    [<c04d1468>] (nl80211_start_ap) from [<c043d144>] (genl_rcv_msg+0x21c/0x38c)
    [<c043d144>] (genl_rcv_msg) from [<c043c740>] (netlink_rcv_skb+0xac/0xc0)
    [<c043c740>] (netlink_rcv_skb) from [<c043cf14>] (genl_rcv+0x20/0x34)
    [<c043cf14>] (genl_rcv) from [<c043c0a0>] (netlink_unicast+0x150/0x20c)
    [<c043c0a0>] (netlink_unicast) from [<c043c4b8>] (netlink_sendmsg+0x2b8/0x398)
    [<c043c4b8>] (netlink_sendmsg) from [<c04066a4>] (sock_sendmsg+0x84/0xa8)
    [<c04066a4>] (sock_sendmsg) from [<c0407c5c>] (___sys_sendmsg.part.29+0x268/0x278)
    [<c0407c5c>] (___sys_sendmsg.part.29) from [<c0408bdc>] (__sys_sendmsg+0x4c/0x7c)
    [<c0408bdc>] (__sys_sendmsg) from [<c000ec60>] (ret_fast_syscall+0x0/0x44)
    ---[ end trace 965ee2158c9905a2 ]---
    
    Reported-by: Pontus Fuchs <pontusf@broadcom.com>
    Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
    Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com>
    Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
    Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
    Signed-off-by: Arend van Spriel <arend@broadcom.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0fbfdd1bd3ecdf5d2a10a1d19d0124d0d4b847ca
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed Nov 19 01:44:11 2014 +0100

    ACPI / PM: Ignore wakeup setting if the ACPI companion can't wake up
    
    commit 78579b7c7eb45f0e7ec5e9437087ed21749f9a9c upstream.
    
    As reported by Dmitry, on some Chromebooks there are devices with
    corresponding ACPI objects and with unusual system wakeup
    configuration.  Namely, they technically are wakeup-capable, but the
    wakeup is handled via a platform-specific out-of-band mechanism and
    the ACPI PM layer has no information on the wakeup capability.  As
    a result, device_may_wakeup(dev) called from acpi_dev_suspend_late()
    returns 'true' for those devices, but the wakeup.flags.valid flag is
    unset for the corresponding ACPI device objects, so acpi_device_wakeup()
    reproducibly fails for them causing acpi_dev_suspend_late() to return
    an error code.  The entire system suspend is then aborted and the
    machines in question cannot suspend at all.
    
    Address the problem by ignoring the device_may_wakeup(dev) return
    value in acpi_dev_suspend_late() if the ACPI companion of the device
    being handled has wakeup.flags.valid unset (in which case it is clear
    that the wakeup is supposed to be handled by other means).
    
    This fixes a regression introduced by commit a76e9bd89ae7 (i2c:
    attach/detach I2C client device to the ACPI power domain) as the
    affected systems could suspend and resume successfully before that
    commit.
    
    Fixes: a76e9bd89ae7 (i2c: attach/detach I2C client device to the ACPI power domain)
    Reported-by: Dmitry Torokhov <dtor@chromium.org>
    Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2dbfff81a40b5b2be553042ad5c767e34fdd214c
Author: Lv Zheng <lv.zheng@intel.com>
Date:   Thu Aug 21 14:41:26 2014 +0800

    ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC
    
    commit 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4 upstream.
    
    There is platform refusing to respond QR_EC when SCI_EVT isn't set
    which is Acer Aspire V5-573G.
    
    By disallowing QR_EC to be issued before the previous one has been
    completed we are able to reduce the possibilities to trigger issues on
    such platforms.
    
    Note that this fix can only reduce the occurrence rate of this issue, but
    this issue may still occur when such a platform doesn't clear SCI_EVT
    before or immediately after completing the previous QR_EC transaction.
    This patch cannot fix the CLEAR_ON_RESUME quirk which also relies on
    the assumption that the platforms are able to respond even when SCI_EVT
    isn't set.
    
    But this patch is still useful as it can help to reduce the number of
    scheduled QR_EC work items.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611
    Reported-and-tested-by: Alexander Mezin <mezin.alexander@gmail.com>
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c920f72d13325bea8a52d95e4d18b5f9a86a19b5
Author: Chris Mason <clm@fb.com>
Date:   Wed Nov 19 10:25:09 2014 -0800

    btrfs: fix lockups from btrfs_clear_path_blocking
    
    commit f82c458a2c3ffb94b431fc6ad791a79df1b3713e upstream.
    
    The fair reader/writer locks mean that btrfs_clear_path_blocking needs
    to strictly follow lock ordering rules even when we already have
    blocking locks on a given path.
    
    Before we can clear a blocking lock on the path, we need to make sure
    all of the locks have been converted to blocking.  This will remove lock
    inversions against anyone spinning in write_lock() against the buffers
    we're trying to get read locks on.  These inversions didn't exist before
    the fair read/writer locks, but now we need to be more careful.
    
    We papered over this deadlock in the past by changing
    btrfs_try_read_lock() to be a true trylock against both the spinlock and
    the blocking lock.  This was slower, and not sufficient to fix all the
    deadlocks.  This patch adds a btrfs_tree_read_lock_atomic(), which
    basically means get the spinlock but trylock on the blocking lock.
    
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Josef Bacik <jbacik@fb.com>
    Reported-by: Patrick Schmid <schmid@phys.ethz.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89554d77e1b3aa61f27946236157c1df51982f90
Author: Gu Zheng <guz.fnst@cn.fujitsu.com>
Date:   Thu Nov 6 17:46:21 2014 +0800

    aio: fix uncorrent dirty pages accouting when truncating AIO ring buffer
    
    commit 835f252c6debd204fcd607c79975089b1ecd3472 upstream.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=86831
    
    Markus reported that when shutting down mysqld (with AIO support,
    on a ext3 formatted Harddrive) leads to a negative number of dirty pages
    (underrun to the counter). The negative number results in a drastic reduction
    of the write performance because the page cache is not used, because the kernel
    thinks it is still 2 ^ 32 dirty pages open.
    
    Add a warn trace in __dec_zone_state will catch this easily:
    
    static inline void __dec_zone_state(struct zone *zone, enum
    	zone_stat_item item)
    {
         atomic_long_dec(&zone->vm_stat[item]);
    +    WARN_ON_ONCE(item == NR_FILE_DIRTY &&
    	atomic_long_read(&zone->vm_stat[item]) < 0);
         atomic_long_dec(&vm_stat[item]);
    }
    
    [   21.341632] ------------[ cut here ]------------
    [   21.346294] WARNING: CPU: 0 PID: 309 at include/linux/vmstat.h:242
    cancel_dirty_page+0x164/0x224()
    [   21.355296] Modules linked in: wutbox_cp sata_mv
    [   21.359968] CPU: 0 PID: 309 Comm: kworker/0:1 Not tainted 3.14.21-WuT #80
    [   21.366793] Workqueue: events free_ioctx
    [   21.370760] [<c0016a64>] (unwind_backtrace) from [<c0012f88>]
    (show_stack+0x20/0x24)
    [   21.378562] [<c0012f88>] (show_stack) from [<c03f8ccc>]
    (dump_stack+0x24/0x28)
    [   21.385840] [<c03f8ccc>] (dump_stack) from [<c0023ae4>]
    (warn_slowpath_common+0x84/0x9c)
    [   21.393976] [<c0023ae4>] (warn_slowpath_common) from [<c0023bb8>]
    (warn_slowpath_null+0x2c/0x34)
    [   21.402800] [<c0023bb8>] (warn_slowpath_null) from [<c00c0688>]
    (cancel_dirty_page+0x164/0x224)
    [   21.411524] [<c00c0688>] (cancel_dirty_page) from [<c00c080c>]
    (truncate_inode_page+0x8c/0x158)
    [   21.420272] [<c00c080c>] (truncate_inode_page) from [<c00c0a94>]
    (truncate_inode_pages_range+0x11c/0x53c)
    [   21.429890] [<c00c0a94>] (truncate_inode_pages_range) from
    [<c00c0f6c>] (truncate_pagecache+0x88/0xac)
    [   21.439252] [<c00c0f6c>] (truncate_pagecache) from [<c00c0fec>]
    (truncate_setsize+0x5c/0x74)
    [   21.447731] [<c00c0fec>] (truncate_setsize) from [<c013b3a8>]
    (put_aio_ring_file.isra.14+0x34/0x90)
    [   21.456826] [<c013b3a8>] (put_aio_ring_file.isra.14) from
    [<c013b424>] (aio_free_ring+0x20/0xcc)
    [   21.465660] [<c013b424>] (aio_free_ring) from [<c013b4f4>]
    (free_ioctx+0x24/0x44)
    [   21.473190] [<c013b4f4>] (free_ioctx) from [<c003d8d8>]
    (process_one_work+0x134/0x47c)
    [   21.481132] [<c003d8d8>] (process_one_work) from [<c003e988>]
    (worker_thread+0x130/0x414)
    [   21.489350] [<c003e988>] (worker_thread) from [<c00448ac>]
    (kthread+0xd4/0xec)
    [   21.496621] [<c00448ac>] (kthread) from [<c000ec18>]
    (ret_from_fork+0x14/0x20)
    [   21.503884] ---[ end trace 79c4bf42c038c9a1 ]---
    
    The cause is that we set the aio ring file pages as *DIRTY* via SetPageDirty
    (bypasses the VFS dirty pages increment) when init, and aio fs uses
    *default_backing_dev_info* as the backing dev, which does not disable
    the dirty pages accounting capability.
    So truncating aio ring file will contribute to accounting dirty pages (VFS
    dirty pages decrement), then error occurs.
    
    The original goal is keeping these pages in memory (can not be reclaimed
    or swapped) in life-time via marking it dirty. But thinking more, we have
    already pinned pages via elevating the page's refcount, which can already
    achieve the goal, so the SetPageDirty seems unnecessary.
    
    In order to fix the issue, using the __set_page_dirty_no_writeback instead
    of the nop .set_page_dirty, and dropped the SetPageDirty (don't manually
    set the dirty flags, don't disable set_page_dirty(), rely on default behaviour).
    
    With the above change, the dirty pages accounting can work well. But as we
    known, aio fs is an anonymous one, which should never cause any real write-back,
    we can ignore the dirty pages (write back) accounting by disabling the dirty
    pages (write back) accounting capability. So we introduce an aio private
    backing dev info (disabled the ACCT_DIRTY/WRITEBACK/ACCT_WB capabilities) to
    replace the default one.
    
    Reported-by: Markus Königshaus <m.koenigshaus@wut.de>
    Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
    Acked-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65f73a241ee70f2234c4a3008eb41c63b42a8350
Author: Hui Wang <hui.wang@canonical.com>
Date:   Fri Nov 21 17:05:01 2014 +0800

    ALSA: hda - One more HP machine needs to change mute led quirk
    
    commit 911f632c701d9f15a54076cbaca82e7defb339e0 upstream.
    
    The machine originally use the quirk ALC269_FIXUP_HP_GPIO_MIC1_LED,
    but the LED doesn't work at all.
    
    After this change, the machine will change to use
    ALC269_FIXUP_HP_MUTE_LED_MIC1 through pin_fixup_tbl[], and the LED
    works well.
    
    BugLink: https://bugs.launchpad.net/bugs/1389497
    Tested-by: TieFu Chen <tienfu.chen@canonical.com>
    Cc: Kailang Yang <kailang@realtek.com>
    Signed-off-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 6895333a1d046c32a28a79ad0ec6b7ea81f93097
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Oct 1 10:30:53 2014 +0200

    ALSA: hda - Limit 40bit DMA for AMD HDMI controllers
    
    commit 413cbf469a19e7662ba5025695bf5a573927105a upstream.
    
    AMD/ATI HDMI controller chip models, we already have a filter to lower
    to 32bit DMA, but the rest are supposed to be working with 64bit
    although the hardware doesn't really work with 63bit but only with 40
    or 48bit DMA.  In this patch, we take 40bit DMA for safety for the
    AMD/ATI controllers as the graphics drivers does.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d90b70c15c225eb29d6d0a00b440d688ba4d69ed
Author: Jurgen Kramer <gtmkramer@xs4all.nl>
Date:   Sat Nov 15 14:01:21 2014 +0100

    ALSA: usb-audio: Add ctrl message delay quirk for Marantz/Denon devices
    
    commit 6e84a8d7ac3ba246ef44e313e92bc16a1da1b04a upstream.
    
    This patch adds a USB control message delay quirk for a few specific Marantz/Denon
    devices. Without the delay the DACs will not work properly and produces the
    following type of messages:
    
    Nov 15 10:09:21 orwell kernel: [   91.342880] usb 3-13: clock source 41 is not valid, cannot use
    Nov 15 10:09:21 orwell kernel: [   91.343775] usb 3-13: clock source 41 is not valid, cannot use
    
    There are likely other Marantz/Denon devices using the same USB module which exhibit the
    same problems. But as this cannot be verified I limited the patch to the devices
    I could test.
    
    The following two devices are covered by this path:
    - Marantz SA-14S1
    - Marantz HD-DAC1
    
    Signed-off-by: Jurgen Kramer <gtmkramer@xs4all.nl>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 686fad7a92fecdf8bcffeaa6c726af9d1267ddac
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date:   Sat Oct 11 00:31:07 2014 +0400

    can: esd_usb2: fix memory leak on disconnect
    
    commit efbd50d2f62fc1f69a3dcd153e63ba28cc8eb27f upstream.
    
    It seems struct esd_usb2 dev is not deallocated on disconnect. The patch adds
    the missing deallocation.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Acked-by: Matthias Fuchs <matthias.fuchs@esd.eu>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af080c3fd4ddb9d0ca63664f3f4a9150b17f7256
Author: Lu Baolu <baolu.lu@linux.intel.com>
Date:   Tue Nov 18 11:27:14 2014 +0200

    usb: xhci: rework root port wake bits if controller isn't allowed to wakeup
    
    commit a1377e5397ab321e21b793ec8cd2b6f12bd3c718 upstream.
    
    When system is being suspended, if host device is not allowed to do wakeup,
    xhci_suspend() needs to clear all root port wake on bits. Otherwise, some
    platforms may generate spurious wakeup, even if PCI PME# is disabled.
    
    The initial commit ff8cbf250b44 ("xhci: clear root port wake on bits"),
    which also got into stable, turned out to not work correctly and had to
    be reverted, and is now rewritten.
    
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Suggested-by: Alan Stern <stern@rowland.harvard.edu>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    [Mathias Nyman: reword commit message]
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd5b239cd9dd3f109fc7184dd5ca841fdd20fb66
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Tue Nov 18 11:27:12 2014 +0200

    USB: xhci: Reset a halted endpoint immediately when we encounter a stall.
    
    commit 8e71a322fdb127814bcba423a512914ca5bc6cf5 upstream.
    
    If a device is halted and reuturns a STALL, then the halted endpoint
    needs to be cleared both on the host and device side. The host
    side halt is cleared by issueing a xhci reset endpoint command. The device side
    is cleared with a ClearFeature(ENDPOINT_HALT) request, which should
    be issued by the device driver if a URB reruen -EPIPE.
    
    Previously we cleared the host side halt after the device side was cleared.
    To make sure the host side halt is cleared in time we want to issue the
    reset endpoint command immedialtely when a STALL status is encountered.
    
    Otherwise we end up not following the specs and not returning -EPIPE
    several times in a row when trying to transfer data to a halted endpoint.
    
    Fixes: bcef3fd (USB: xhci: Handle errors that cause endpoint halts.)
    Tested-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f20eeea16f6c869a2ca3d2b84e37843dc501a757
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Tue Nov 18 11:27:11 2014 +0200

    USB: xhci: don't start a halted endpoint before its new dequeue is set
    
    commit c3492dbfa1050debf23a5b5cd2bc7514c5b37896 upstream.
    
    A halted endpoint ring must first be reset, then move the ring
    dequeue pointer past the problematic TRB. If we start the ring too
    early after reset, but before moving the dequeue pointer we
    will end up executing the same problematic TRB again.
    
    As we always issue a set transfer dequeue command after a reset
    endpoint command we can skip starting endpoint rings at reset endpoint
    command completion.
    
    Without this fix we end up trying to handle the same faulty TD for
    contol endpoints. causing timeout, and failing testusb ctrl_out write
    tests.
    
    Fixes: e9df17e (USB: xhci: Correct assumptions about number of rings per endpoint.)
    Tested-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 062a6a771515328714abbda630ed901c6098f7d6
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Nov 21 13:28:03 2014 +0100

    USB: uas: Add no-uas quirk for Hitachi usb-3 enclosures 4971:1012
    
    commit 8daee1352d51a32676b84bddcc0e3252d1caa833 upstream.
    
    These disks have a broken uas implementation, the tag field of the status
    iu-s is not set properly, so we need to fall-back to usb-storage for these.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 679233efec00ee734d33c6114ce786cc7214fe15
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Nov 24 11:22:38 2014 +0100

    usb-quirks: Add reset-resume quirk for MS Wireless Laser Mouse 6000
    
    commit 263e80b43559a6103e178a9176938ce171b23872 upstream.
    
    This wireless mouse receiver needs a reset-resume quirk to properly come
    out of reset.
    
    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1165206
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 18562e067b089061b068bd2b77d7c4654223343f
Author: Troy Clark <tclark@matrixorbital.ca>
Date:   Mon Nov 17 14:33:17 2014 -0800

    usb: serial: ftdi_sio: add PIDs for Matrix Orbital products
    
    commit 204ec6e07ea7aff863df0f7c53301f9cbbfbb9d3 upstream.
    
    Add PIDs for new Matrix Orbital GTT series products.
    
    Signed-off-by: Troy Clark <tclark@matrixorbital.ca>
    [johan: shorten commit message ]
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6169a9752eddf54e38d80519c1766f1fbf6b58e
Author: Preston Fick <pffick@gmail.com>
Date:   Fri Nov 7 23:26:11 2014 -0600

    USB: serial: cp210x: add IDs for CEL MeshConnect USB Stick
    
    commit ffcfe30ebd8dd703d0fc4324ffe56ea21f5479f4 upstream.
    
    Signed-off-by: Preston Fick <pffick@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dffe228e3deb810d7e4b5d4b1878f907fee355c2
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Nov 18 11:25:19 2014 +0100

    USB: keyspan: fix tty line-status reporting
    
    commit 5d1678a33c731b56e245e888fdae5e88efce0997 upstream.
    
    Fix handling of TTY error flags, which are not bitmasks and must
    specifically not be ORed together as this prevents the line discipline
    from recognising them.
    
    Also insert null characters when reporting overrun errors as these are
    not associated with the received character.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 035901370d22d597a6d26180e92384b4d433a7a0
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Nov 18 11:25:20 2014 +0100

    USB: keyspan: fix overrun-error reporting
    
    commit 855515a6d3731242d85850a206f2ec084c917338 upstream.
    
    Fix reporting of overrun errors, which are not associated with a
    character. Instead insert a null character and report only once.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit feecb81a8e6c5348aff2c3f567dbef9d855a3a35
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Nov 18 11:25:21 2014 +0100

    USB: ssu100: fix overrun-error reporting
    
    commit 75bcbf29c284dd0154c3e895a0bd1ef0e796160e upstream.
    
    Fix reporting of overrun errors, which should only be reported once
    using the inserted null character.
    
    Fixes: 6b8f1ca5581b ("USB: ssu100: set tty_flags in ssu100_process_packet")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ccb8c720de7f29557b390591ebb82ecdac55c4d
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Thu Nov 27 10:10:21 2014 -0600

    staging: r8188eu: Add new device ID for DLink GO-USB-N150
    
    commit 6d4556fc0309608f760f1d329df56d77fdd0c31a upstream.
    
    The DLink GO-USB-N150 with revision B1 uses this driver.
    
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 438486bd47e7be5161142301aa45a64df1846333
Author: Axel Lin <axel.lin@ingics.com>
Date:   Mon Nov 10 16:04:06 2014 +0800

    iio: adc: men_z188_adc: Add terminating entry for men_z188_ids
    
    commit fbbba1f89eb68e7d07707e104193d56de8e37fe5 upstream.
    
    The mcb_device_id table is supposed to be zero-terminated.
    
    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fbe88b1dea2210fde13cc149ffa6d9166e2d6685
Author: Cristina Ciocan <cristina.ciocan@intel.com>
Date:   Tue Nov 11 16:07:42 2014 +0200

    iio: Fix IIO_EVENT_CODE_EXTRACT_DIR bit mask
    
    commit ccf54555da9a5e91e454b909ca6a5303c7d6b910 upstream.
    
    The direction field is set on 7 bits, thus we need to AND it with 0111 111 mask
    in order to retrieve it, that is 0x7F, not 0xCF as it is now.
    
    Fixes: ade7ef7ba (staging:iio: Differential channel handling)
    Signed-off-by: Cristina Ciocan <cristina.ciocan@intel.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f3ae88ae662a620bd093c3dd0b50e13322fb7d6
Author: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Date:   Thu Nov 20 09:44:36 2014 +0530

    powerpc/powernv: Fix the hmi event version check.
    
    commit 6acbc5a1dab30aa8f7be7bf3852f343f89147ac5 upstream.
    
    The current HMI event structure is an ABI and carries a version field to
    accommodate future changes without affecting/rearranging current structure
    members that are valid for previous versions.
    
    The current version check "if (hmi_evt->version != OpalHMIEvt_V1)"
    doesn't accomodate the fact that the version number may change in
    future.
    
    If firmware starts returning an HMI event with version > 1, this check
    will fail and no HMI information will be printed on older kernels.
    
    This patch fixes this issue.
    
    Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
    [mpe: Reword changelog]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa87a2a50181339df780f383fab94b5e120c4827
Author: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Date:   Mon Nov 24 15:07:53 2014 +0100

    powerpc/pseries: Fix endiannes issue in RTAS call from xmon
    
    commit 3b8a3c01096925a824ed3272601082289d9c23a5 upstream.
    
    On pseries system (LPAR) xmon failed to enter when running in LE mode,
    system is hunging. Inititating xmon will lead to such an output on the
    console:
    
    SysRq : Entering xmon
    cpu 0x15: Vector: 0  at [c0000003f39ffb10]
        pc: c00000000007ed7c: sysrq_handle_xmon+0x5c/0x70
        lr: c00000000007ed7c: sysrq_handle_xmon+0x5c/0x70
        sp: c0000003f39ffc70
       msr: 8000000000009033
      current = 0xc0000003fafa7180
      paca    = 0xc000000007d75e80	 softe: 0	 irq_happened: 0x01
        pid   = 14617, comm = bash
    Bad kernel stack pointer fafb4b0 at eca7cc4
    cpu 0x15: Vector: 300 (Data Access) at [c000000007f07d40]
        pc: 000000000eca7cc4
        lr: 000000000eca7c44
        sp: fafb4b0
       msr: 8000000000001000
       dar: 10000000
     dsisr: 42000000
      current = 0xc0000003fafa7180
      paca    = 0xc000000007d75e80	 softe: 0	 irq_happened: 0x01
        pid   = 14617, comm = bash
    cpu 0x15: Exception 300 (Data Access) in xmon, returning to main loop
    xmon: WARNING: bad recursive fault on cpu 0x15
    
    The root cause is that xmon is calling RTAS to turn off the surveillance
    when entering xmon, and RTAS is requiring big endian parameters.
    
    This patch is byte swapping the RTAS arguments when running in LE mode.
    
    Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d6a7c62b8c7ec36a8eecfb18b2a3cedcda9385b
Author: Gavin Shan <gwshan@linux.vnet.ibm.com>
Date:   Tue Nov 25 09:26:59 2014 +1100

    powerpc/powernv: Replace OPAL_DEASSERT_RESET with EEH_RESET_DEACTIVATE
    
    commit 360d88a9e3fba596a12520b242fbab1c45b983e1 upstream.
    
    The flag passed to ioda_eeh_phb_reset() should be EEH_RESET_DEACTIVATE,
    which is translated to OPAL_DEASSERT_RESET or something else by the
    EEH backend accordingly.
    
    The patch replaces OPAL_DEASSERT_RESET with EEH_RESET_DEACTIVATE for
    ioda_eeh_phb_reset().
    
    Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe075f8be57b840bf37135d1055e4fd9542dd34c
Author: Anton Blanchard <anton@samba.org>
Date:   Thu Nov 27 08:11:28 2014 +1100

    powerpc: 32 bit getcpu VDSO function uses 64 bit instructions
    
    commit 152d44a853e42952f6c8a504fb1f8eefd21fd5fd upstream.
    
    I used some 64 bit instructions when adding the 32 bit getcpu VDSO
    function. Fix it.
    
    Fixes: 18ad51dd342a ("powerpc: Add VDSO version of getcpu")
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9dbd8e228ddfc7564138d73c67652eed34ef96c9
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Tue Oct 7 16:12:55 2014 +1100

    powerpc/pseries: Honor the generic "no_64bit_msi" flag
    
    commit 415072a041bf50dbd6d56934ffc0cbbe14c97be8 upstream.
    
    Instead of the arch specific quirk which we are deprecating
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc91f8b2a55b80a7b4dd6ca0ce364c03fe50a56d
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Fri Nov 14 17:55:03 2014 +1100

    of/base: Fix PowerPC address parsing hack
    
    commit 746c9e9f92dde2789908e51a354ba90a1962a2eb upstream.
    
    We have a historical hack that treats missing ranges properties as the
    equivalent of an empty one. This is needed for ancient PowerMac "bad"
    device-trees, and shouldn't be enabled for any other PowerPC platform,
    otherwise we get some nasty layout of devices in sysfs or even
    duplication when a set of otherwise identically named devices is
    created multiple times under a different parent node with no ranges
    property.
    
    This fix is needed for the PowerNV i2c busses to be exposed properly
    and will fix a number of other embedded cases.
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Acked-by: Grant Likely <grant.likely@linaro.org>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2bf559697785880fbdf073d49a3fce7feed48df1
Author: Miaoqing Pan <miaoqing@qca.qualcomm.com>
Date:   Thu Nov 6 10:52:23 2014 +0530

    ath9k: Fix RTC_DERIVED_CLK usage
    
    commit 4e6ce4dc7ce71d0886908d55129d5d6482a27ff9 upstream.
    
    Based on the reference clock, which could be 25MHz or 40MHz,
    AR_RTC_DERIVED_CLK is programmed differently for AR9340 and AR9550.
    But, when a chip reset is done, processing the initvals
    sets the register back to the default value.
    
    Fix this by moving the code in ath9k_hw_init_pll() to
    ar9003_hw_override_ini(). Also, do this override for AR9531.
    
    Signed-off-by: Miaoqing Pan <miaoqing@qca.qualcomm.com>
    Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d4736e72362ac50353e0f2600858c030d0ba7cc1
Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date:   Wed Nov 12 15:40:44 2014 +0100

    ASoC: cs42l51: re-hook of_match_table pointer
    
    commit 2cb1e0259f50c7be88eb277c7442fa74a3ce7c57 upstream.
    
    In commit a1253ef6d3fa ("ASoC: cs42l51: split i2c from codec driver"),
    the I2C part of the CS42L51 was moved to a separate file, but the
    definition of the of_device_id array was left in the driver file
    itself, no longer connected to the platform_driver structure using the
    .of_match_table pointer.
    
    This commit exports the of_device_id array in cs42l51, and uses it as
    .of_match_able in cs42l51-i2c.c. This solution was suggested by Brian
    Austin.
    
    Fixes: a1253ef6d3fa ("ASoC: cs42l51: split i2c from codec driver")
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Acked-by: Brian Austin <brian.austin@cirrus.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a42f2a6505897a8d222d2d9222e5b8c48fb1ac7
Author: Bard Liao <bardliao@realtek.com>
Date:   Thu Nov 6 12:23:52 2014 +0800

    ASoC: rt5670: correct the incorrect default values
    
    commit ac87f22147098da9cf83a0b413ef7dda42277d85 upstream.
    
    The patch corrects the incorrect default register values.
    
    Signed-off-by: Bard Liao <bardliao@realtek.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c09aebf51ad3344b79cd02b34ca637c11333ef23
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Nov 4 16:52:28 2014 +0100

    ASoC: dpcm: Fix race between FE/BE updates and trigger
    
    commit ea9d0d771fcd32cd56070819749477d511ec9117 upstream.
    
    DPCM can update the FE/BE connection states totally asynchronously
    from the FE's PCM state.  Most of FE/BE state changes are protected by
    mutex, so that they won't race, but there are still some actions that
    are uncovered.  For example, suppose to switch a BE while a FE's
    stream is running.  This would call soc_dpcm_runtime_update(), which
    sets FE's runtime_update flag, then sets up and starts BEs, and clears
    FE's runtime_update flag again.
    
    When a device emits XRUN during this operation, the PCM core triggers
    snd_pcm_stop(XRUN).  Since the trigger action is an atomic ops, this
    isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
    It eventually updates and clears FE's runtime_update flag while
    soc_dpcm_runtime_update() is running concurrently, and it results in
    confusion.
    
    Usually, for avoiding such a race, we take a lock.  There is a PCM
    stream lock for that purpose.  However, as already mentioned, the
    trigger action is atomic, and we can't take the lock for the whole
    soc_dpcm_runtime_update() or other operations that include the lengthy
    jobs like hw_params or prepare.
    
    This patch provides an alternative solution.  This adds a way to defer
    the conflicting trigger callback to be executed at the end of FE/BE
    state changes.  For doing it, two things are introduced:
    
    - Each runtime_update state change of FEs is protected via PCM stream
      lock.
    - The FE's trigger callback checks the runtime_update flag.  If it's
      not set, the trigger action is executed there.  If set, mark the
      pending trigger action and returns immediately.
    - At the exit of runtime_update state change, it checks whether the
      pending trigger is present.  If yes, it executes the trigger action
      at this point.
    
    Reported-and-tested-by: Qiao Zhou <zhouqiao@marvell.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b1ba40bb9de96ccb1563172b1ec3c418b23fc49a
Author: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date:   Mon Nov 17 10:48:21 2014 +0000

    ASoC: wm_adsp: Avoid attempt to free buffers that might still be in use
    
    commit 9da7a5a9fdeeb76b2243f6b473363a7e6147ab6f upstream.
    
    We should not free any buffers associated with writing out coefficients
    to the DSP until all the async writes have completed. This patch updates
    the out of memory path when allocating a new buffer to include a call to
    regmap_async_complete.
    
    Reported-by: JS Park <aitdark.park@samsung.com>
    Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b147cad7f4ca8d0ad42e04f75993b10f895495e9
Author: Jianqun <jay.xu@rock-chips.com>
Date:   Wed Oct 29 17:45:51 2014 +0800

    ASoC: rockchip-i2s: fix infinite loop in rockchip_snd_rxctrl
    
    commit 29f95bd76f6ec1eff88eec6a04191104a11a7f97 upstream.
    
    We can get into an infinite loop if the I2S_CLR register fails to
    clear due to a missing break statement, so add that.
    
    Signed-off-by: Jianqun <jay.xu@rock-chips.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d926a995ebab02ced82afad60eb5a39872dad630
Author: Andreas Färber <afaerber@suse.de>
Date:   Wed Nov 5 17:44:52 2014 +0100

    ASoC: samsung: Add MODULE_DEVICE_TABLE for Snow
    
    commit 62e6a3b6f4e1f9b96fa66ab1cdf2ffd8594df9e9 upstream.
    
    This enables the snd_soc_snow module to be auto-loaded.
    
    Signed-off-by: Andreas Färber <afaerber@suse.de>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b392bd7fd3e5ba047031d5edc3b4d2f1a1c8929
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date:   Fri Nov 14 02:14:47 2014 -0200

    ASoC: sgtl5000: Fix SMALL_POP bit definition
    
    commit c251ea7bd7a04f1f2575467e0de76e803cf59149 upstream.
    
    On a mx28evk with a sgtl5000 codec we notice a loud 'click' sound  to happen
    5 seconds after the end of a playback.
    
    The SMALL_POP bit should fix this, but its definition is incorrect:
    according to the sgtl5000 manual it is bit 0 of CHIP_REF_CTRL register, not
    bit 1.
    
    Fix the definition accordingly and enable the bit as intended per the code
    comment.
    
    After applying this change, no loud 'click' sound is heard after playback
    
    Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3b69d8278e79457a6fee94c0e74b87ae8d14b60
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date:   Tue Oct 28 21:01:53 2014 -0700

    ASoC: fsi: remove unsupported PAUSE flag
    
    commit c1b9b9b1ad2df6144ca3fbe6989f7bd9ea5c5562 upstream.
    
    FSI doesn't support PAUSE.
    Remove SNDRV_PCM_INFO_PAUSE flags from snd_pcm_hardware info
    
    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e16cde16db5b1cae4cafba5e2c045caa6f480e4
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date:   Tue Oct 28 21:02:03 2014 -0700

    ASoC: rsnd: remove unsupported PAUSE flag
    
    commit 706c66213e5e623e23f521b1acbd8171af7a3549 upstream.
    
    R-Car sound doesn't support PAUSE.
    Remove SNDRV_PCM_INFO_PAUSE flags from snd_pcm_hardware info
    
    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d4d4c408e4e1a1b0f81cdf7b02375c20a9311923
Author: Or Gerlitz <ogerlitz@mellanox.com>
Date:   Wed Oct 22 14:55:49 2014 -0700

    ib_isert: Add max_send_sge=2 minimum for control PDU responses
    
    commit f57915cfa5b2b14c1cffa2e83c034f55e3f0e70d upstream.
    
    This patch adds a max_send_sge=2 minimum in isert_conn_setup_qp()
    to ensure outgoing control PDU responses with tx_desc->num_sge=2
    are able to function correctly.
    
    This addresses a bug with RDMA hardware using dev_attr.max_sge=3,
    that in the original code with the ConnectX-2 work-around would
    result in isert_conn->max_sge=1 being negotiated.
    
    Originally reported by Chris with ocrdma driver.
    
    Reported-by: Chris Moore <Chris.Moore@emulex.com>
    Tested-by: Chris Moore <Chris.Moore@emulex.com>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7cd0b977abd527d872fb4fbef9c8e0b78bddee3f
Author: Chris Moore <Chris.Moore@Emulex.Com>
Date:   Tue Nov 4 16:28:29 2014 +0000

    IB/isert: Adjust CQ size to HW limits
    
    commit b1a5ad006b34ded9dc7ec64988deba1b3ecad367 upstream.
    
    isert has an issue of trying to create a CQ with more CQEs than are
    supported by the hardware, that currently results in failures during
    isert_device creation during first session login.
    
    This is the isert version of the patch that Minh Tran submitted for
    iser, and is simple a workaround required to function with existing
    ocrdma hardware.
    
    Signed-off-by: Chris Moore <chris.moore@emulex.com>
    Reviewied-by: Sagi Grimberg <sagig@mellanox.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 391d9c6c3beef96ce3080487cdd158cd4e9711e6
Author: Maxime Ripard <maxime.ripard@free-electrons.com>
Date:   Tue Nov 18 23:59:33 2014 +0100

    clockevent: sun4i: Fix race condition in the probe code
    
    commit 6bab4a8a1888729f17f4923cc5867e4674f66333 upstream.
    
    The interrupts were activated and the handler registered before the clockevent
    was registered in the probe function.
    
    The interrupt handler, however, was making the assumption that the clockevent
    device was registered.
    
    That could cause a null pointer dereference if the timer interrupt was firing
    during this narrow window.
    
    Fix that by moving the clockevent registration before the interrupt is enabled.
    
    Reported-by: Roman Byshko <rbyshko@gmail.com>
    Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b1abe707d14ef7d7557f9b671d9709941cd4810a
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Fri Oct 3 15:13:24 2014 +1000

    PCI/MSI: Add device flag indicating that 64-bit MSIs don't work
    
    commit f144d1496b47e7450f41b767d0d91c724c2198bc upstream.
    
    This can be set by quirks/drivers to be used by the architecture code
    that assigns the MSI addresses.
    
    We additionally add verification in the core MSI code that the values
    assigned by the architecture do satisfy the limitation in order to fail
    gracefully if they don't (ie. the arch hasn't been updated to deal with
    that quirk yet).
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Acked-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 10c05a2788c4ccf2ce9d208ef999bfe323027807
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Wed Nov 19 14:30:32 2014 -0700

    PCI: Support 64-bit bridge windows if we have 64-bit dma_addr_t
    
    commit 7fc986d8a9727e5d40da3c2c1c343da6142e82a9 upstream.
    
    Aaron reported that a 32-bit x86 kernel with Physical Address Extension
    (PAE) support complains about bridge prefetchable memory windows above 4GB:
    
      pci_bus 0000:00: root bus resource [mem 0x380000000000-0x383fffffffff]
      ...
      pci 0000:03:00.0: reg 0x10: [mem 0x383fffc00000-0x383fffdfffff 64bit pref]
      pci 0000:03:00.0: reg 0x20: [mem 0x383fffe04000-0x383fffe07fff 64bit pref]
      pci 0000:03:00.1: reg 0x10: [mem 0x383fffa00000-0x383fffbfffff 64bit pref]
      pci 0000:03:00.1: reg 0x20: [mem 0x383fffe00000-0x383fffe03fff 64bit pref]
      pci 0000:00:02.2: PCI bridge to [bus 03-04]
      pci 0000:00:02.2:   bridge window [io  0x1000-0x1fff]
      pci 0000:00:02.2:   bridge window [mem 0x91900000-0x91cfffff]
      pci 0000:00:02.2: can't handle 64-bit address space for bridge
    
    In this kernel, unsigned long is 32 bits and dma_addr_t is 64 bits.
    Previously we used "unsigned long" to hold the bridge window address.  But
    this is a bus address, so we should use dma_addr_t instead.
    
    Use dma_addr_t to hold the bridge window base and limit.
    
    The question of whether the CPU can actually *address* the window is
    separate and depends on what the physical address space of the CPU is and
    whether the host bridge does any address translation.
    
    [bhelgaas: fix "shift count > width of type", changelog, stable tag]
    Fixes: d56dbf5bab8c ("PCI: Allocate 64-bit BARs above 4G when possible")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=88131
    Reported-by: Aaron Ma <mapengyu@gmail.com>
    Tested-by: Aaron Ma <mapengyu@gmail.com>
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b051cd5f406e8f76854018b28448baef20da701e
Author: Or Gerlitz <ogerlitz@mellanox.com>
Date:   Sun Nov 9 14:25:39 2014 +0200

    net/mlx4_en: Advertize encapsulation offloads features only when VXLAN tunnel is set
    
    [ Upstream commit f4a1edd56120249198073aa4a373b77e3700ac8f ]
    
    Currenly we only support Large-Send and TX checksum offloads for
    encapsulated traffic of type VXLAN. We must make sure to advertize
    these offloads up to the stack only when VXLAN tunnel is set.
    
    Failing to do so, would mislead the the networking stack to assume
    that the driver can offload the internal TX checksum for GRE packets
    and other buggy schemes.
    
    Reported-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f2ac092bb0c831e00fc51c7dd25dc23e15c37c5
Author: Or Gerlitz <ogerlitz@mellanox.com>
Date:   Tue Nov 18 17:51:27 2014 +0200

    net/mlx4_en: Add VXLAN ndo calls to the PF net device ops too
    
    [ Upstream commit 9737c6ab7afbc950e997ef80cba2c40dbbd16ea4 ]
    
    This is currently missing, which results in a crash when one attempts
    to set VXLAN tunnel over the mlx4_en when acting as PF.
    
    	[ 2408.785472] BUG: unable to handle kernel NULL pointer dereference at (null)
    	[...]
    	[ 2408.994104] Call Trace:
    	[ 2408.996584]  [<ffffffffa021f7f5>] ? vxlan_get_rx_port+0xd6/0x103 [vxlan]
    	[ 2409.003316]  [<ffffffffa021f71f>] ? vxlan_lowerdev_event+0xf2/0xf2 [vxlan]
    	[ 2409.010225]  [<ffffffffa0630358>] mlx4_en_start_port+0x862/0x96a [mlx4_en]
    	[ 2409.017132]  [<ffffffffa063070f>] mlx4_en_open+0x17f/0x1b8 [mlx4_en]
    
    While here, make sure to invoke vxlan_get_rx_port() only when VXLAN
    offloads are actually enabled and not when they are only supported.
    
    Reported-by: Ido Shamay <idos@mellanox.com>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0644d66debfc66ea3ed6064d033e90b96a89a904
Author: Jiri Bohac <jbohac@suse.cz>
Date:   Wed Nov 19 23:05:49 2014 +0100

    ipx: fix locking regression in ipx_sendmsg and ipx_recvmsg
    
    [ Upstream commit 01462405f0c093b2f8dfddafcadcda6c9e4c5cdf ]
    
    This fixes an old regression introduced by commit
    b0d0d915 (ipx: remove the BKL).
    
    When a recvmsg syscall blocks waiting for new data, no data can be sent on the
    same socket with sendmsg because ipx_recvmsg() sleeps with the socket locked.
    
    This breaks mars-nwe (NetWare emulator):
    - the ncpserv process reads the request using recvmsg
    - ncpserv forks and spawns nwconn
    - ncpserv calls a (blocking) recvmsg and waits for new requests
    - nwconn deadlocks in sendmsg on the same socket
    
    Commit b0d0d915 has simply replaced BKL locking with
    lock_sock/release_sock. Unlike now, BKL got unlocked while
    sleeping, so a blocking recvmsg did not block a concurrent
    sendmsg.
    
    Only keep the socket locked while actually working with the socket data and
    release it prior to calling skb_recv_datagram().
    
    Signed-off-by: Jiri Bohac <jbohac@suse.cz>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c3e21500a2def0b02ff772f3eb9c23629a1424a
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Nov 19 18:05:26 2014 +0100

    pptp: fix stack info leak in pptp_getname()
    
    [ Upstream commit a5f6fc28d6e6cc379c6839f21820e62262419584 ]
    
    pptp_getname() only partially initializes the stack variable sa,
    particularly only fills the pptp part of the sa_addr union. The code
    thereby discloses 16 bytes of kernel stack memory via getsockname().
    
    Fix this by memset(0)'ing the union before.
    
    Cc: Dmitry Kozlov <xeb@mail.ru>
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9cd8078ff5e80f31a554cae12df0686e12f9edc
Author: Nikolay Aleksandrov <nikolay@redhat.com>
Date:   Tue Nov 18 15:14:44 2014 +0100

    bonding: fix curr_active_slave/carrier with loadbalance arp monitoring
    
    [ Upstream commit b8e4500f42fe4464a33a887579147050bed8fcef ]
    
    Since commit 6fde8f037e60 ("bonding: fix locking in
    bond_loadbalance_arp_mon()") we can have a stale bond carrier state and
    stale curr_active_slave when using arp monitoring in loadbalance modes. The
    reason is that in bond_loadbalance_arp_mon() we can't have
    do_failover == true but slave_state_changed == false, whenever do_failover
    is true then slave_state_changed is also true. Then the following piece
    from bond_loadbalance_arp_mon():
                    if (slave_state_changed) {
                            bond_slave_state_change(bond);
                            if (BOND_MODE(bond) == BOND_MODE_XOR)
                                    bond_update_slave_arr(bond, NULL);
                    } else if (do_failover) {
                            block_netpoll_tx();
                            bond_select_active_slave(bond);
                            unblock_netpoll_tx();
                    }
    
    will execute only the first branch, always and regardless of do_failover.
    Since these two events aren't related in such way, we need to decouple and
    consider them separately.
    
    For example this issue could lead to the following result:
    Bonding Mode: load balancing (round-robin)
    *MII Status: down*
    MII Polling Interval (ms): 0
    Up Delay (ms): 0
    Down Delay (ms): 0
    ARP Polling Interval (ms): 100
    ARP IP target/s (n.n.n.n form): 192.168.9.2
    
    Slave Interface: ens12
    *MII Status: up*
    Speed: 10000 Mbps
    Duplex: full
    Link Failure Count: 2
    Permanent HW addr: 00:0f:53:01:42:2c
    Slave queue ID: 0
    
    Slave Interface: eth1
    *MII Status: up*
    Speed: Unknown
    Duplex: Unknown
    Link Failure Count: 70
    Permanent HW addr: 52:54:00:2f:0f:8e
    Slave queue ID: 0
    
    Since some interfaces are up, then the status of the bond should also be
    up, but it will never change unless something invokes bond_set_carrier()
    (i.e. enslave, bond_select_active_slave etc). Now, if I force the
    calling of bond_select_active_slave via for example changing
    primary_reselect (it can change in any mode), then the MII status goes to
    "up" because it calls bond_select_active_slave() which should've been done
    from bond_loadbalance_arp_mon() itself.
    
    CC: Veaceslav Falico <vfalico@gmail.com>
    CC: Jay Vosburgh <j.vosburgh@gmail.com>
    CC: Andy Gospodarek <andy@greyhouse.net>
    CC: Ding Tianhong <dingtianhong@huawei.com>
    
    Fixes: 6fde8f037e60 ("bonding: fix locking in bond_loadbalance_arp_mon()")
    Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
    Acked-by: Veaceslav Falico <vfalico@gmail.com>
    Acked-by: Andy Gospodarek <gospo@cumulusnetworks.com>
    Acked-by: Ding Tianhong <dingtianhong@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c46c598feb83764aa45630e682411e44ca66a57c
Author: Martin Hauke <mardnh@gmx.de>
Date:   Sun Nov 16 19:55:25 2014 +0100

    qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem
    
    [ Upstream commit bb2bdeb83fb125c95e47fc7eca2a3e8f868e2a74 ]
    
    Added the USB VID/PID for the HP lt4112 LTE/HSPA+ Gobi 4G Modem (Huawei me906e)
    
    Signed-off-by: Martin Hauke <mardnh@gmx.de>
    Acked-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be0eba2d9a1e9dd2b679f049a5bfeb246f0e5d2a
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date:   Sat Nov 15 02:11:59 2014 +0300

    ieee802154: fix error handling in ieee802154fake_probe()
    
    [ Upstream commit 8c2dd54485ccee7fc4086611e188478584758c8d ]
    
    In case of any failure ieee802154fake_probe() just calls unregister_netdev().
    But it does not look safe to unregister netdevice before it was registered.
    
    The patch implements straightforward resource deallocation in case of
    failure in ieee802154fake_probe().
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c919f11d23de2f5f87eedb333bcba4c0942bc4f1
Author: Panu Matilainen <pmatilai@redhat.com>
Date:   Fri Nov 14 13:14:32 2014 +0200

    ipv4: Fix incorrect error code when adding an unreachable route
    
    [ Upstream commit 49dd18ba4615eaa72f15c9087dea1c2ab4744cf5 ]
    
    Trying to add an unreachable route incorrectly returns -ESRCH if
    if custom FIB rules are present:
    
    [root@localhost ~]# ip route add 74.125.31.199 dev eth0 via 1.2.3.4
    RTNETLINK answers: Network is unreachable
    [root@localhost ~]# ip rule add to 55.66.77.88 table 200
    [root@localhost ~]# ip route add 74.125.31.199 dev eth0 via 1.2.3.4
    RTNETLINK answers: No such process
    [root@localhost ~]#
    
    Commit 83886b6b636173b206f475929e58fac75c6f2446 ("[NET]: Change "not found"
    return value for rule lookup") changed fib_rules_lookup()
    to use -ESRCH as a "not found" code internally, but for user space it
    should be translated into -ENETUNREACH. Handle the translation centrally in
    ipv4-specific fib_lookup(), leaving the DECnet case alone.
    
    On a related note, commit b7a71b51ee37d919e4098cd961d59a883fd272d8
    ("ipv4: removed redundant conditional") removed a similar translation from
    ip_route_input_slow() prematurely AIUI.
    
    Fixes: b7a71b51ee37 ("ipv4: removed redundant conditional")
    Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2478e80e662d520b144907763fc281020799c575
Author: Vincent BENAYOUN <vincent.benayoun@trust-in-soft.com>
Date:   Thu Nov 13 13:47:26 2014 +0100

    inetdevice: fixed signed integer overflow
    
    [ Upstream commit 84bc88688e3f6ef843aa8803dbcd90168bb89faf ]
    
    There could be a signed overflow in the following code.
    
    The expression, (32-logmask) is comprised between 0 and 31 included.
    It may be equal to 31.
    In such a case the left shift will produce a signed integer overflow.
    According to the C99 Standard, this is an undefined behavior.
    A simple fix is to replace the signed int 1 with the unsigned int 1U.
    
    Signed-off-by: Vincent BENAYOUN <vincent.benayoun@trust-in-soft.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eec6264fe6f1545af5282674c5318238086b5a97
Author: David S. Miller <davem@davemloft.net>
Date:   Sun Nov 16 13:19:32 2014 -0800

    sparc64: Fix constraints on swab helpers.
    
    [ Upstream commit 5a2b59d3993e8ca4f7788a48a23e5cb303f26954 ]
    
    We are reading the memory location, so we have to have a memory
    constraint in there purely for the sake of showing the data flow
    to the compiler.
    
    Reported-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd624598ec9c269ffb57c698bc83c3ad4c3a245a
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Fri Nov 21 13:26:07 2014 -0800

    uprobes, x86: Fix _TIF_UPROBE vs _TIF_NOTIFY_RESUME
    
    commit 82975bc6a6df743b9a01810fb32cb65d0ec5d60b upstream.
    
    x86 call do_notify_resume on paranoid returns if TIF_UPROBE is set but
    not on non-paranoid returns.  I suspect that this is a mistake and that
    the code only works because int3 is paranoid.
    
    Setting _TIF_NOTIFY_RESUME in the uprobe code was probably a workaround
    for the x86 bug.  With that bug fixed, we can remove _TIF_NOTIFY_RESUME
    from the uprobes code.
    
    Reported-by: Oleg Nesterov <oleg@redhat.com>
    Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Acked-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b58b42442f7e5e8194e23f22e9cedd9543f8354
Author: Kees Cook <keescook@chromium.org>
Date:   Mon Nov 17 16:16:04 2014 -0800

    x86, kaslr: Handle Gold linker for finding bss/brk
    
    commit 70b61e362187b5fccac206506d402f3424e3e749 upstream.
    
    When building with the Gold linker, the .bss and .brk areas of vmlinux
    are shown as consecutive instead of having the same file offset. Allow
    for either state, as long as things add up correctly.
    
    Fixes: e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
    Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Cc: Junjie Mao <eternal.n08@gmail.com>
    Link: http://lkml.kernel.org/r/20141118001604.GA25045@www.outflux.net
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6231385167e0910cfb735735a5bd1307f7dfe8c6
Author: Kees Cook <keescook@chromium.org>
Date:   Fri Nov 14 11:47:37 2014 -0800

    x86, mm: Set NX across entire PMD at boot
    
    commit 45e2a9d4701d8c624d4a4bcdd1084eae31e92f58 upstream.
    
    When setting up permissions on kernel memory at boot, the end of the
    PMD that was split from bss remained executable. It should be NX like
    the rest. This performs a PMD alignment instead of a PAGE alignment to
    get the correct span of memory.
    
    Before:
    ---[ High Kernel Mapping ]---
    ...
    0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
    0xffffffff82200000-0xffffffff82c00000    10M     RW   PSE GLB NX pmd
    0xffffffff82c00000-0xffffffff82df5000  2004K     RW       GLB NX pte
    0xffffffff82df5000-0xffffffff82e00000    44K     RW       GLB x  pte
    0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
    
    After:
    ---[ High Kernel Mapping ]---
    ...
    0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
    0xffffffff82200000-0xffffffff82e00000    12M     RW   PSE GLB NX pmd
    0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
    
    [ tglx: Changed it to roundup(_brk_end, PMD_SIZE) and added a comment.
            We really should unmap the reminder along with the holes
            caused by init,initdata etc. but thats a different issue ]
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Toshi Kani <toshi.kani@hp.com>
    Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
    Cc: David Vrabel <david.vrabel@citrix.com>
    Cc: Wang Nan <wangnan0@huawei.com>
    Cc: Yinghai Lu <yinghai@kernel.org>
    Link: http://lkml.kernel.org/r/20141114194737.GA3091@www.outflux.net
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f156a738cf7a7db67eaaac980da53e41cb05557
Author: Dave Hansen <dave.hansen@linux.intel.com>
Date:   Tue Nov 11 14:01:33 2014 -0800

    x86: Require exact match for 'noxsave' command line option
    
    commit 2cd3949f702692cf4c5d05b463f19cd706a92dd3 upstream.
    
    We have some very similarly named command-line options:
    
    arch/x86/kernel/cpu/common.c:__setup("noxsave", x86_xsave_setup);
    arch/x86/kernel/cpu/common.c:__setup("noxsaveopt", x86_xsaveopt_setup);
    arch/x86/kernel/cpu/common.c:__setup("noxsaves", x86_xsaves_setup);
    
    __setup() is designed to match options that take arguments, like
    "foo=bar" where you would have:
    
    	__setup("foo", x86_foo_func...);
    
    The problem is that "noxsave" actually _matches_ "noxsaves" in
    the same way that "foo" matches "foo=bar".  If you boot an old
    kernel that does not know about "noxsaves" with "noxsaves" on the
    command line, it will interpret the argument as "noxsave", which
    is not what you want at all.
    
    This makes the "noxsave" handler only return success when it finds
    an *exact* match.
    
    [ tglx: We really need to make __setup() more robust. ]
    
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Dave Hansen <dave@sr71.net>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: x86@kernel.org
    Link: http://lkml.kernel.org/r/20141111220133.FE053984@viggo.jf.intel.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a8da23e728d0d5d1e120aa0b645d21547e3720b2
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Sat Nov 22 18:00:33 2014 -0800

    x86_64, traps: Rework bad_iret
    
    commit b645af2d5905c4e32399005b867987919cbfc3ae upstream.
    
    It's possible for iretq to userspace to fail.  This can happen because
    of a bad CS, SS, or RIP.
    
    Historically, we've handled it by fixing up an exception from iretq to
    land at bad_iret, which pretends that the failed iret frame was really
    the hardware part of #GP(0) from userspace.  To make this work, there's
    an extra fixup to fudge the gs base into a usable state.
    
    This is suboptimal because it loses the original exception.  It's also
    buggy because there's no guarantee that we were on the kernel stack to
    begin with.  For example, if the failing iret happened on return from an
    NMI, then we'll end up executing general_protection on the NMI stack.
    This is bad for several reasons, the most immediate of which is that
    general_protection, as a non-paranoid idtentry, will try to deliver
    signals and/or schedule from the wrong stack.
    
    This patch throws out bad_iret entirely.  As a replacement, it augments
    the existing swapgs fudge into a full-blown iret fixup, mostly written
    in C.  It's should be clearer and more correct.
    
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b25aa66b8d25ef7679fa1b8d37a349735b5e3ca2
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Sat Nov 22 18:00:32 2014 -0800

    x86_64, traps: Stop using IST for #SS
    
    commit 6f442be2fb22be02cafa606f1769fa1e6f894441 upstream.
    
    On a 32-bit kernel, this has no effect, since there are no IST stacks.
    
    On a 64-bit kernel, #SS can only happen in user code, on a failed iret
    to user space, a canonical violation on access via RSP or RBP, or a
    genuine stack segment violation in 32-bit kernel code.  The first two
    cases don't need IST, and the latter two cases are unlikely fatal bugs,
    and promoting them to double faults would be fine.
    
    This fixes a bug in which the espfix64 code mishandles a stack segment
    violation.
    
    This saves 4k of memory per CPU and a tiny bit of code.
    
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c769efd690cbc2439d7dd33beb03db83ecb4c514
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Sat Nov 22 18:00:31 2014 -0800

    x86_64, traps: Fix the espfix64 #DF fixup and rewrite it in C
    
    commit af726f21ed8af2cdaa4e93098dc211521218ae65 upstream.
    
    There's nothing special enough about the espfix64 double fault fixup to
    justify writing it in assembly.  Move it to C.
    
    This also fixes a bug: if the double fault came from an IST stack, the
    old asm code would return to a partially uninitialized stack frame.
    
    Fixes: 3891a04aafd668686239349ea58f3314ea2af86b
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40f777934f98746b3a5fc4ef5e496bc5c17b5ffe
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date:   Thu Nov 20 01:05:38 2014 +0200

    MIPS: Loongson: Make platform serial setup always built-in.
    
    commit 26927f76499849e095714452b8a4e09350f6a3b9 upstream.
    
    If SERIAL_8250 is compiled as a module, the platform specific setup
    for Loongson will be a module too, and it will not work very well.
    At least on Loongson 3 it will trigger a build failure,
    since loongson_sysconf is not exported to modules.
    
    Fix by making the platform specific serial code always built-in.
    
    Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Reported-by: Ralf Baechle <ralf@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Cc: Huacai Chen <chenhc@lemote.com>
    Cc: Markos Chandras <Markos.Chandras@imgtec.com>
    Patchwork: https://patchwork.linux-mips.org/patch/8533/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bad492272fb69acc24890a3e1dc5557c0802e668
Author: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
Date:   Thu Nov 27 11:13:08 2014 +0000

    MIPS: tlbex: Fix potential HTW race on TLBL/M/S handlers
    
    commit 070e76cb3ffe43f6855492e77c96680c562598f0 upstream.
    
    There is a potential race when probing the TLB in TLBL/M/S exception
    handlers for a matching entry. Between the time we hit a TLBL/S/M
    exception and the time we get to execute the TLBP instruction, the
    HTW may have replaced the TLB entry we are interested in hence the TLB
    probe may fail. However, in the existing handlers, we never checked the
    status of the TLBP (ie check the result in the C0/Index register). We
    fix this by adding such a check when the core implements the HTW. If
    we couldn't find a matching entry, we return back and try again.
    
    Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
    Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
    Reviewed-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/8599/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b7fbbff75e5c175ad198d5648b30b085d49c89bd
Author: Markos Chandras <markos.chandras@imgtec.com>
Date:   Wed Nov 5 08:25:37 2014 +0000

    MIPS: r4kcache: Add EVA case for protected_writeback_dcache_line
    
    commit 83fd43449baaf88fe5c03dd0081a062041837c51 upstream.
    
    Commit de8974e3f76c0 ("MIPS: asm: r4kcache: Add EVA cache flushing
    functions") added cache function for EVA using the cachee instruction.
    However, it didn't add a case for the protected_writeback_dcache_line.
    mips_dsemul() calls r4k_flush_cache_sigtramp() which in turn uses
    the protected_writeback_dcache_line() to flush the trampoline code
    back to memory. This used the wrong "cache" instruction leading to
    random userland crashes on non-FPU cores.
    
    Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/8331/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3d278918b1fb4003f942a66b19749073b920747
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Tue Oct 28 11:25:51 2014 +0000

    MIPS: fix EVA & non-SMP non-FPU FP context signal handling
    
    commit 14fa12df1d6bc1d3389a0fa842e0ebd8e8a9af26 upstream.
    
    The save_fp_context & restore_fp_context pointers were being assigned
    to the wrong variables if either:
    
      - The kernel is configured for UP & runs on a system without an FPU,
        since b2ead5282885 "MIPS: Move & rename
        fpu_emulator_{save,restore}_context".
    
      - The kernel is configured for EVA, since ca750649e08c "MIPS: kernel:
        signal: Prevent save/restore FPU context in user memory".
    
    This would lead to FP context being clobbered incorrectly when setting
    up a sigcontext, then the garbage values being saved uselessly when
    returning from the signal.
    
    Fix by swapping the pointer assignments appropriately.
    
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/8230/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35508d151a2998527374a240fd1fd3e6c7d84ae5
Author: Markos Chandras <markos.chandras@imgtec.com>
Date:   Mon Nov 10 12:25:34 2014 +0000

    MIPS: cpu-probe: Set the FTLB probability bit on supported cores
    
    commit cf0a8aa0226da5de88011e7f30eff22a894b2f49 upstream.
    
    Make use of the Config6/FLTBP bit to set the probability of a TLBWR
    instruction to hit the FTLB or the VTLB. A value of 0 (which may be
    the default value on certain cores, such as proAptiv or P5600)
    means that a TLBWR instruction will never hit the VTLB which
    leads to performance limitations since it effectively decreases
    the number of available TLB slots.
    
    Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
    Reviewed-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/8368/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44fef5a01e85c15dc2098ffcb57a8fb6aed01ddd
Author: Markos Chandras <markos.chandras@imgtec.com>
Date:   Mon Nov 17 09:30:23 2014 +0000

    MIPS: asm: uaccess: Add v1 register to clobber list on EVA
    
    commit 58563817cfed0432e9a54476d5fc6c3aeba475e4 upstream.
    
    When EVA is turned on and prefetching is being used in memcpy.S,
    the v1 register is being used as a helper register to the PREFE
    instruction. However, v1 ($3) was not in the clobber list, which
    means that the compiler did not preserve it across function calls,
    and that could corrupt the value of the register leading to all
    sorts of userland crashes. We fix this problem by using the
    DADDI_SCRATCH macro to define the clobbered register when
    CONFIG_EVA && CONFIG_CPU_HAS_PREFETCH are enabled.
    
    Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/8510/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea2d1816eb38fc994324b00eb2bc48df463cadcf
Author: James Cowgill <James.Cowgill@imgtec.com>
Date:   Thu Nov 13 11:08:06 2014 +0000

    MIPS: Loongson3: Fix __node_distances undefined error
    
    commit 21255dad9dffa4407cab866f5561cb9568f7f7d8 upstream.
    
    export the __node_distances symbol in the loongson3 numa code to fix the
    build error:
    
      Building modules, stage 2.
      MODPOST 221 modules
    ERROR: "__node_distances" [drivers/block/nvme.ko] undefined!
    scripts/Makefile.modpost:90: recipe for target '__modpost' failed
    
    when building the kernel with:
     CONFIG_CPU_LOONGSON3=y
     CONFIG_NUMA=y
     CONFIG_BLK_DEV_NVME=m
    
    Signed-off-by: James Cowgill <James.Cowgill@imgtec.com>
    Reviewed-by: James Hogan <james.hogan@imgtec.com>
    Reviewed-by: Huacai Chen <chenhc@lemote.com>
    Cc: linux-mips@linux-mips.org
    Cc: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Patchwork: https://patchwork.linux-mips.org/patch/8444/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d17bb5349a8c47681e4b8c13b18d5a474f1447af
Author: Markos Chandras <markos.chandras@imgtec.com>
Date:   Mon Nov 17 09:31:07 2014 +0000

    MIPS: tlb-r4k: Add missing HTW stop/start sequences
    
    commit 6a8dff6ab16c903b0d8ef5fbf21543f39bf5d675 upstream.
    
    HTW needs to stop and start again whenever the EntryHI register
    changes otherwise an inflight HTW operation might use the new
    EntryHI register for updating an old entry and that could lead
    to crashes or even a machine check exception. We fix this by
    ensuring the HTW has stop whenever the EntryHI register is about
    to change
    
    Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/8511/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51b4651a82bb4fee40de9f5bd0770db4eb798e8a
Author: Aaro Koskinen <aaro.koskinen@nsn.com>
Date:   Fri Oct 17 18:10:24 2014 +0300

    MIPS: oprofile: Fix backtrace on 64-bit kernel
    
    commit bbaf113a481b6ce32444c125807ad3618643ce57 upstream.
    
    Fix incorrect cast that always results in wrong address for the new
    frame on 64-bit kernels.
    
    Signed-off-by: Aaro Koskinen <aaro.koskinen@nsn.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/8110/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2782ec76ca4c8760f12426502588b9e1d3c6cd84
Author: Markos Chandras <markos.chandras@imgtec.com>
Date:   Mon Nov 17 09:32:38 2014 +0000

    MIPS: lib: memcpy: Restore NOP on delay slot before returning to caller
    
    commit 51b1029d9966060c6ad02030e6f251425b4f06c1 upstream.
    
    Commit cf62a8b8134dd3 ("MIPS: lib: memcpy: Use macro to build the
    copy_user code") switched to a macro in order to build the memcpy
    symbols in preparation for the EVA support. However, this commit
    also removed the NOP instruction after the 'jr ra' when returning
    back to the caller. This had no visible side-effects since the next
    instruction was a load to the t0 register which was already in the
    clobbered list, but it may have undesired effects in the future
    if some other code is introduced in between the .Ldone and
    the .Ll_exc_copy labels.
    
    Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/8512/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c9de33b93b8681566ae82526662004bea516398
Author: James Cowgill <James.Cowgill@imgtec.com>
Date:   Thu Nov 13 11:08:07 2014 +0000

    MIPS: IP27: Fix __node_distances undefined error
    
    commit 5829b0ecc584d15ae4eeabe69f2ab554bdec4689 upstream.
    
    export the __node_distances symbol in the ip27 memory code to fix the
    build error:
    
      Building modules, stage 2.
      MODPOST 311 modules
    ERROR: "__node_distances" [drivers/block/nvme.ko] undefined!
    scripts/Makefile.modpost:90: recipe for target '__modpost' failed
    
    when building the kernel with:
     CONFIG_SGI_IP27=y
     CONFIG_BLK_DEV_NVME=m
    
    Signed-off-by: James Cowgill <James.Cowgill@imgtec.com>
    Reviewed-by: James Hogan <james.hogan@imgtec.com>
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>