commit fcd9bfdb9d884f1aab89124dee894e7d821bb5dc
Author: Sasha Levin <sasha.levin@oracle.com>
Date:   Mon Aug 31 18:19:23 2015 -0400

    Linux 3.18.21
    
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 0a4ab28ed2365960f882d0ed6ca18fe8e1707149
Author: Alexander Duyck <alexander.h.duyck@redhat.com>
Date:   Wed May 27 07:16:54 2015 -0700

    ip_vti/ip6_vti: Preserve skb->mark after rcv_cb call
    
    [ Upstream commit d55c670cbc54b2270a465cdc382ce71adae45785 ]
    
    The vti6_rcv_cb and vti_rcv_cb calls were leaving the skb->mark modified
    after completing the function.  This resulted in the original skb->mark
    value being lost.  Since we only need skb->mark to be set for
    xfrm_policy_check we can pull the assignment into the rcv_cb calls and then
    just restore the original mark after xfrm_policy_check has been completed.
    
    Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit cfcf92c2f029f48d3681df800abb6f31d06e1a86
Author: Alexander Duyck <alexander.h.duyck@redhat.com>
Date:   Wed May 27 07:16:49 2015 -0700

    xfrm: Override skb->mark with tunnel->parm.i_key in xfrm_input
    
    [ Upstream commit 049f8e2e28d9c3dac0744cc2f19d3157c7fb5646 ]
    
    This change makes it so that if a tunnel is defined we just use the mark
    from the tunnel instead of the mark from the skb header.  By doing this we
    can avoid the need to set skb->mark inside of the tunnel receive functions.
    
    Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 5508c2605a492642fec53a4f77e354dde2e99e8c
Author: Alexander Duyck <alexander.h.duyck@redhat.com>
Date:   Wed May 27 07:16:43 2015 -0700

    ip_vti/ip6_vti: Do not touch skb->mark on xmit
    
    [ Upstream commit cd5279c194f89c9b97c294af4aaf4ea8c5e3c704 ]
    
    Instead of modifying skb->mark we can simply modify the flowi_mark that is
    generated as a result of the xfrm_decode_session.  By doing this we don't
    need to actually touch the skb->mark and it can be preserved as it passes
    out through the tunnel.
    
    Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a0f0adf9e73f8f8157afc7d587943e70700f2a56
Author: Martin K. Petersen <martin.petersen@oracle.com>
Date:   Wed Jul 15 21:03:23 2015 -0400

    libata: Do not blacklist M510DC
    
    [ Upstream commit 9051bd393cf25e76dfb45409792719a854661500 ]
    
    A new Micron drive was just announced, once again recycling the first
    part of the model string. Add an underscore to the M510/M550 pattern to
    avoid picking up the new DC drive.
    
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit dfacf53c1a6ecfd3ae1d81ac173c00366cb4db79
Author: Arne Fitzenreiter <arne_f@ipfire.org>
Date:   Wed Jul 15 13:54:37 2015 +0200

    libata: force disable trim for SuperSSpeed S238
    
    [ Upstream commit cda57b1b05cf7b8b99ab4b732bea0b05b6c015cc ]
    
    This device loses blocks, often the partition table area, on trim.
    Disable TRIM.
    http://pcengines.ch/msata16a.htm
    
    Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 3fa84d66219c984590bd59959e283fba6d4bc9e0
Author: Arne Fitzenreiter <arne_f@ipfire.org>
Date:   Wed Jul 15 13:54:36 2015 +0200

    libata: add ATA_HORKAGE_NOTRIM
    
    [ Upstream commit 71d126fd28de2d4d9b7b2088dbccd7ca62fad6e0 ]
    
    Some devices lose data on TRIM whether queued or not.  This patch adds
    a horkage to disable TRIM.
    
    tj: Collapsed unnecessary if() nesting.
    
    Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 90eebd37c8175cb60c99b9cd1e3f5e61eb7b7468
Author: Martin K. Petersen <martin.petersen@oracle.com>
Date:   Mon May 4 21:54:19 2015 -0400

    libata: Expose TRIM capability in sysfs
    
    [ Upstream commit f303074160d3401970ccae082014e1ee5a9a52c5 ]
    
    Create a sysfs "trim" attribute for each ata_device that displays
    whether DSM TRIM is "unsupported", "unqueued", "forced_unqueued"
    (blacklisted) or "queued".
    
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit f17728b7a635d5bea4ddd7836140fd7ca1b53638
Author: Martin K. Petersen <martin.petersen@oracle.com>
Date:   Thu Jun 18 14:50:18 2015 -0400

    libata: Do not blacklist Micron M500DC
    
    [ Upstream commit 243918be6393f643e513a26e7882e6ae06ff7717 ]
    
    Queued TRIM got disabled on Micron M500DC drives thanks to the
    "Micron_M500*" pattern we had in place to accommodate the previous
    generation of this drive family. Tweak the blacklist entry slightly so
    we only disable queued TRIM for the non-DC variants of M500 drives.
    
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit d3e2d9ba835e37f7839b2af217507536bafe80eb
Author: Martin K. Petersen <martin.petersen@oracle.com>
Date:   Mon May 4 12:20:29 2015 -0400

    libata: Blacklist queued TRIM on all Samsung 800-series
    
    [ Upstream commit 9a9324d3969678d44b330e1230ad2c8ae67acf81 ]
    
    The queued TRIM problems appear to be generic to Samsung's firmware and
    not tied to a particular model. A recent update to the 840 EVO firmware
    introduced the same issue as we saw on 850 Pro.
    
    Blacklist queued TRIM on all 800-series drives while we work this issue
    with Samsung.
    
    Reported-by: Günter Waller <g.wal@web.de>
    Reported-by: Sven Köhler <sven.koehler@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 049d0178aacb36f2748e239f4a29c84f5d1970dd
Author: Martin K. Petersen <martin.petersen@oracle.com>
Date:   Fri Mar 27 15:17:21 2015 -0400

    libata: Blacklist queued TRIM on Samsung SSD 850 Pro
    
    [ Upstream commit 6fc4d97a4987c5d247655a157a9377996626221a ]
    
    Blacklist queued TRIM on this drive for now.
    
    Reported-by: Stefan Keller <linux-list@zahlenfresser.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    CC: stable@vger.kernel.org
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 35ca66445f872aed209fc9c4e39434384b5726be
Author: Martin K. Petersen <martin.petersen@oracle.com>
Date:   Fri Mar 27 15:17:20 2015 -0400

    libata: Update Crucial/Micron blacklist
    
    [ Upstream commit ff7f53fb82a7801a778e5902bdbbc5e195ab0de0 ]
    
    Micron has released an updated firmware (MU02) for M510/M550/MX100
    drives to fix the issues with queued TRIM. Queued TRIM remains broken on
    M500 but is working fine on later drives such as M600 and MX200.
    
    Tweak our blacklist to reflect the above.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=71371
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit cf39ac141baed8e5bfe0b67c34f5cfb23f0f1f89
Author: Martin K. Petersen <martin.petersen@oracle.com>
Date:   Thu Jan 8 10:34:27 2015 -0500

    libata: Whitelist SSDs that are known to properly return zeroes after TRIM
    
    [ Upstream commit e61f7d1c3c07a7e51036b0796749edb00deff845 ]
    
    As defined, the DRAT (Deterministic Read After Trim) and RZAT (Return
    Zero After Trim) flags in the ATA Command Set are unreliable in the
    sense that they only define what happens if the device successfully
    executed the DSM TRIM command. TRIM is only advisory, however, and the
    device is free to silently ignore all or parts of the request.
    
    In practice this renders the DRAT and RZAT flags completely useless and
    because the results are unpredictable we decided to disable discard in
    MD for 3.18 to avoid the risk of data corruption.
    
    Hardware vendors in the real world obviously need better guarantees than
    what the standards bodies provide. Unfortuntely those guarantees are
    encoded in product requirements documents rather than somewhere we can
    key off of them programatically. So we are compelled to disabling
    discard_zeroes_data for all devices unless we explicitly have data to
    support whitelisting them.
    
    This patch whitelists SSDs from a few of the main vendors. None of the
    whitelists are based on written guarantees. They are purely based on
    empirical evidence collected from internal and external users that have
    tested or qualified these drives in RAID deployments.
    
    The whitelist is only meant as a starting point and is by no means
    comprehensive:
    
       - All intel SSD models except for 510
       - Micron M5?0/M600
       - Samsung SSDs
       - Seagate SSDs
    
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 514f0a944c001cdad24dce56757bfc3bb991c925
Author: Sasha Levin <sasha.levin@oracle.com>
Date:   Sat Aug 22 15:30:23 2015 -0400

    Revert "libata: add ATA_HORKAGE_NOTRIM"
    
    This reverts commit e7a84605061b205350654641d823e1ca9589ec24.

commit ccdf38d8643e69532044d3a5672d8dc8ebf7a1ab
Author: Joe Perches <joe@perches.com>
Date:   Thu Mar 26 20:47:10 2015 -0700

    hpfs: hpfs_error: Remove static buffer, use vsprintf extension %pV instead
    
    [ Upstream commit a28e4b2b18ccb90df402da3f21e1a83c9d4f8ec1 ]
    
    Removing unnecessary static buffers is good.
    Use the vsprintf %pV extension instead.
    
    Signed-off-by: Joe Perches <joe@perches.com>
    Signed-off-by: Mikulas Patocka <mikulas@twibright.com>
    Cc: stable@vger.kernel.org      # v2.6.36+
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 5a59e7240b35d84ef75ba154afb17af97579900a
Author: Len Brown <len.brown@intel.com>
Date:   Tue Feb 10 15:42:03 2015 -0500

    intel_idle: support additional Broadwell model
    
    [ Upstream commit bea57077e44ec9c1e6d3a3c142c8a3c0289e290d ]
    
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 7ff9eeca341ace0ba30599ee5ab195e9b0f44550
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Thu Apr 16 14:47:33 2015 +0200

    kexec: allocate the kexec control page with KEXEC_CONTROL_MEMORY_GFP
    
    [ Upstream commit 7e01b5acd88b3f3108d8c4ce44e3205d67437202 ]
    
    Introduce KEXEC_CONTROL_MEMORY_GFP to allow the architecture code
    to override the gfp flags of the allocation for the kexec control
    page. The loop in kimage_alloc_normal_control_pages allocates pages
    with GFP_KERNEL until a page is found that happens to have an
    address smaller than the KEXEC_CONTROL_MEMORY_LIMIT. On systems
    with a large memory size but a small KEXEC_CONTROL_MEMORY_LIMIT
    the loop will keep allocating memory until the oom killer steps in.
    
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 015bb25d90b8867a1b6a882cc65cc28e3276c888
Author: Devin Ryles <devin.ryles@intel.com>
Date:   Wed Nov 5 16:30:03 2014 -0500

    i2c: i801: Add DeviceIDs for SunrisePoint LP
    
    [ Upstream commit 3eee1799aed90e990e02a73a89bfcff1982c74dd ]
    
    Signed-off-by: Devin Ryles <devin.ryles@intel.com>
    Reviewed-by: Jean Delvare <jdelvare@suse.de>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 1c9660cbca3b2b1c62bb22ab7c94f8f7286619a1
Author: Libin Yang <libin.yang@intel.com>
Date:   Tue Dec 16 13:17:34 2014 +0800

    ALSA: hda/hdmi - apply Haswell fix-ups to Skylake display codec
    
    [ Upstream commit 432ac1a2c028acb289d90f918e3a7b79e4ac8c07 ]
    
    Skylake and Haswell have the same behavior on display audio. So this patch
    applys Haswell fix-ups to Skylake.
    
    Signed-off-by: Libin Yang <libin.yang@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 9935bb27b000ac03f1c151467a00a60925a2d5e4
Author: Libin Yang <libin.yang@intel.com>
Date:   Mon Dec 15 12:49:42 2014 +0800

    ALSA: hda - add codec ID for Skylake display audio codec
    
    [ Upstream commit 99fcb3778b0ec12a8fa8b58435d75e9203bb430d ]
    
    This patch adds codec ID (0x80862809) and module alias for Skylake
    display codec.
    
    Signed-off-by: Libin Yang <libin.yang@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e125aa4484322bec7ff15a8defa3233e27f12f93
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date:   Wed May 13 15:06:09 2015 -0300

    iio: accel: hid-sensor-accel-3d: Fix memory leak in probe()
    
    [ Upstream commit b136faff9bc2f4adea050ed2119c01199f9a86a5 ]
    
    'channels' is allocated via kmemdup and it is never freed in the
    subsequent error paths.
    
    Use 'indio_dev->channels' directly instead, so that we avoid such
    memory leak problem.
    
    Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
    Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 1ca8e343d2afd47e4f157f32987883765cb22217
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date:   Wed May 13 15:06:10 2015 -0300

    iio: gyro: hid-sensor-gyro-3d: Fix memory leak in probe()
    
    [ Upstream commit d8c9d23e29e3d758ea477adaa95e28cbf3556518 ]
    
    'channels' is allocated via kmemdup and it is never freed in the
    subsequent error paths.
    
    Use 'indio_dev->channels' directly instead, so that we avoid such
    memory leak problem.
    
    Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
    Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a9ca142ca231614a2af1085c5d09bddffe897a32
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date:   Wed May 13 15:06:11 2015 -0300

    iio: light: hid-sensor-als.c: Fix memory leak in probe()
    
    [ Upstream commit 9ecdbed7903921f29adae63a3155814b453e7186 ]
    
    'channels' is allocated via kmemdup and it is never freed in the
    subsequent error paths.
    
    Use 'indio_dev->channels' directly instead, so that we avoid such
    memory leak problem.
    
    Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
    Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 8d31c41e51ed690755f0f33716e065e960f9949f
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Wed Jan 7 10:13:10 2015 +0900

    thermal: rcar: fix ENR register value
    
    [ Upstream commit 11313746547015ace605c4c347a40350753051e4 ]
    
    On R-Mobile APE6, since it has 3 thermal zones, ENR register
    has enable bits in bit 19-16, bit 11-8 and bit 3-0.
    
    However, on R-Car gen2, since it has 1 thermal zone, ENR register has
    enable bits in bit 3-0. (In other words, the write value should always
    be 0 for bit 31-4 of ENR register.)
    
    So, this patch fixes the ENR register value using I/O resource sets.
    
    Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit c4a7bf89fbff80e1ced7ca53c51f81231ace912c
Author: Yann Droneaud <ydroneaud@opteya.com>
Date:   Mon Nov 17 23:02:19 2014 +0000

    arm64/mm: Remove hack in mmap randomize layout
    
    [ Upstream commit d6c763afab142a85e4770b4bc2a5f40f256d5c5d ]
    
    Since commit 8a0a9bd4db63 ('random: make get_random_int() more
    random'), get_random_int() returns a random value for each call,
    so comment and hack introduced in mmap_rnd() as part of commit
    1d18c47c735e ('arm64: MMU fault handling and page table management')
    are incorrects.
    
    Commit 1d18c47c735e seems to use the same hack introduced by
    commit a5adc91a4b44 ('powerpc: Ensure random space between stack
    and mmaps'), latter copied in commit 5a0efea09f42 ('sparc64: Sharpen
    address space randomization calculations.').
    
    But both architectures were cleaned up as part of commit
    fa8cbaaf5a68 ('powerpc+sparc64/mm: Remove hack in mmap randomize
    layout') as hack is no more needed since commit 8a0a9bd4db63.
    
    So the present patch removes the comment and the hack around
    get_random_int() on AArch64's mmap_rnd().
    
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Anton Blanchard <anton@samba.org>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Acked-by: Dan McGee <dpmcgee@gmail.com>
    Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 061302c50682840cc9fa7dc492c5ef1407d897a2
Author: Wen-chien Jesse Sung <jesse.sung@canonical.com>
Date:   Wed May 13 11:39:24 2015 +0800

    Bluetooth: ath3k: Add a new ID 0cf3:e006 to ath3k list
    
    [ Upstream commit ca79f232054abd079648fdb4400c71a1310f7bc8 ]
    
    Device info in /sys/kernel/debug/usb/devices:
    
    T:  Bus=01 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#=  3 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0cf3 ProdID=e006 Rev= 0.01
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    
    Signed-off-by: Wen-chien Jesse Sung <jesse.sung@canonical.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 8733dc7b2ac108f9139c34e1299bcc192b3e878e
Author: Kristian Evensen <kristian.evensen@gmail.com>
Date:   Tue Jan 20 17:55:03 2015 +0100

    HID: do not bind to Microchip Pick16F1454
    
    [ Upstream commit a8c8316b11594e616df641b4b19ec9da732f93df ]
    
    The Microchip Pick16F1454 is exported as a HID device and is used by for
    example the Yepkit YKUSH three-port switchable USB hub. However, it is not an
    actual HID-device. On the Yepkit, it is used to power up/down the ports on the
    hub. The HID driver should ignore this device.
    
    Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 1fd9293b1ba4b2bfcfc613282ebdac0e5a15a82a
Author: Dinesh Ram <Dinesh.Ram@cern.ch>
Date:   Tue Oct 15 12:24:41 2013 -0300

    [media] si4713: HID blacklist Si4713 USB development board
    
    [ Upstream commit adc232592337d3ac4c5473ba8bdaf7c202bf215d ]
    
    The Si4713 development board contains a Si4713 FM transmitter chip
    and is handled by the radio-usb-si4713 driver.
    The board reports itself as (10c4:8244) Cygnal Integrated Products, Inc.
    and misidentifies itself as a HID device in its USB interface descriptor.
    This patch ignores this device as an HID device and hence loads the custom driver.
    
    Signed-off-by: Dinesh Ram <dinesh.ram@cern.ch>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Acked-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Tested-by: Eduardo Valentin <edubezval@gmail.com>
    Acked-by: Eduardo Valentin <edubezval@gmail.com>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ae7a92c4be1bb966d762cb2a6b6464ca8b7a83bf
Author: Forest Wilkinson <web11.forest@tibit.com>
Date:   Thu Mar 12 23:58:16 2015 -0700

    HID: tivo: enable all buttons on the TiVo Slide Pro remote
    
    [ Upstream commit 9b028649b9d0ae72090904629dad06b022f4ddc7 ]
    
    The linux kernel has supported the TiVo Slide remote control for some time, but
    does not recognize the USB ID of the newer Slide Pro. This patch adds the
    missing data structures so the newer remote will be recognized by the driver,
    thereby allowing the TiVo, LiveTV, and Thumbs Up/Down buttons to be
    mapped with a hwdb file.
    
    Signed-off-by: Forest Wilkinson <web11.forest@tibit.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 6288fbe9384536d1f01868acaa74d50c723a08c1
Author: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Date:   Fri Nov 14 17:26:38 2014 -0600

    hpsa: fix a couple pci id table mistakes
    
    [ Upstream commit 7d2cce58a765e802959471f8a7edd83f113ad637 ]
    
    Fix a couple of pci id table mistakes:
    Subdevice ID 0x3323 missing from product[] table
    	(another name for HP Smart Storage 1210m)
    Bogus 0x1925 subdevice id removed from hpsa_pci_device_id[] (no such thing.)
    
    Signed-off-by: Don Brace <don.brace@pmcs.com>
    Reviewed-by: Webb Scales <webbnh@hp.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 57a45cb53cba2261d7e909f944a3ddd4d61e8ac2
Author: Lenny Szubowicz <lszubowi@redhat.com>
Date:   Thu Nov 13 13:51:52 2014 -0500

    cpufreq: pcc: Enable autoload of pcc-cpufreq for ACPI processors
    
    [ Upstream commit 7e7e8fe69820c6fa31395dbbd8e348e3c69cd2a9 ]
    
    The pcc-cpufreq driver is not automatically loaded on systems where
    the platform's power management setting requires this driver.
    Instead, on those systems no CPU frequency driver is registered and
    active.
    
    Make the autoloading matching criteria for loading the pcc-cpufreq
    driver the same as done in acpi-cpufreq by commit c655affbd524d01
    ("ACPI / cpufreq: Add ACPI processor device IDs to acpi-cpufreq").
    
    x86 CPU frequency drivers are now typically autoloaded by specifying
    MODULE_DEVICE_TABLE entries and x86cpu model specific matching.
    But pcc-cpufreq was omitted when acpi-cpufreq and other drivers were
    changed to use this approach.
    
    Both acpi-cpufreq and pcc-cpufreq depend on a distinct and mutually
    exclusive set of ACPI methods which are not directly tied to specific
    processor model numbers. Both of these drivers have init routines
    which look for their required ACPI methods. As a result, only the
    appropriate driver registers as the cpu frequency driver and the other
    one ends up being unloaded.
    
    Tested on various systems where acpi-cpufreq, intel_pstate, and
    pcc-cpufreq are the expected cpu frequency drivers.
    
    Signed-off-by: Lenny Szubowicz <lszubowi@redhat.com>
    Signed-off-by: Joseph Szczypek <joseph.szczypek@hp.com>
    Reported-by: Trinh Dao <trinh.dao@hp.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 33fdddbdf9bf8f0200739483c4b562b895c11274
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Tue May 26 20:13:43 2015 +0900

    usb: renesas_usbhs: Don't disable the pipe if Control write status stage
    
    [ Upstream commit b4c2526134d5203e5ef1a17a49ce1edab20b9afd ]
    
    commit 93fb9127cb63a3246b32d48fa273010764687862 upstream.
    
    This patch fixes an issue that sometimes this controller is not able
    to complete the Control write status stage.
    
    This driver should enable DCPCTR.CCPL and PID_BUF to complete the status
    stage. However, if this driver detects the ctrl_stage interruption first
    before the control write data is received, this driver will clear the
    PID_BUF wrongly in the usbhsf_pio_try_pop(). To avoid this issue, this
    patch doesn't clear the PID_BUF in the usbhsf_pio_try_pop().
    (Since also the privious code doesn't disable the PID_BUF after a control
     transfer was finished, this patch doesn't have any side efforts.)
    
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 8066dce0a1bda0d34b1718c93222fe4a6bec80f2
Author: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
Date:   Tue May 26 20:13:42 2015 +0900

    usb: renesas_usbhs: Fix fifo unclear in usbhsf_prepare_pop
    
    [ Upstream commit 5e582ff309288898be3744f093ce2d726f4747fe ]
    
    This patch fixes an issue for control write. When usbhsf_prepare_pop()
    is called after this driver called a gadget setup function, this controller
    doesn't receive the control write data. So, this patch adds a code to clear
    the fifo for control write in usbhsf_prepare_pop().
    
    Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a798a8ecf30bf36d1a92e71bd803626c54ea59c0
Author: Jeff Mahoney <jeffm@suse.com>
Date:   Fri Mar 20 14:02:09 2015 -0400

    btrfs: cleanup orphans while looking up default subvolume
    
    [ Upstream commit 727b9784b6085c99c2f836bf4fcc2848dc9cf904 ]
    
    Orphans in the fs tree are cleaned up via open_ctree and subvolume
    orphans are cleaned via btrfs_lookup_dentry -- except when a default
    subvolume is in use.  The name for the default subvolume uses a manual
    lookup that doesn't trigger orphan cleanup and needs to trigger it
    manually as well. This doesn't apply to the remount case since the
    subvolumes are cleaned up by walking the root radix tree.
    
    Signed-off-by: Jeff Mahoney <jeffm@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.cz>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit d421e91fe7e975b095e5b909e4712a07e0acaee5
Author: Chengyu Song <csong84@gatech.edu>
Date:   Tue Mar 24 18:12:56 2015 -0400

    btrfs: incorrect handling for fiemap_fill_next_extent return
    
    [ Upstream commit 26e726afe01c1c82072cf23a5ed89ce25f39d9f2 ]
    
    fiemap_fill_next_extent returns 0 on success, -errno on error, 1 if this was
    the last extent that will fit in user array. If 1 is returned, the return
    value may eventually returned to user space, which should not happen, according
    to manpage of ioctl.
    
    Signed-off-by: Chengyu Song <csong84@gatech.edu>
    Reviewed-by: David Sterba <dsterba@suse.cz>
    Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 17e0dfc79801744d54534bc3bf22003ccf3de8e4
Author: Axel Lin <axel.lin@ingics.com>
Date:   Wed May 20 08:53:20 2015 +0800

    iio: adc: twl6030-gpadc: Fix modalias
    
    [ Upstream commit e5d732186270e0881f47d95610316c0614b21c3e ]
    
    Remove extra space between platform prefix and DRIVER_NAME in MODULE_ALIAS.
    
    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit dfcc067d2d94affe236614ae1de1a7e3f72b32e4
Author: NeilBrown <neilb@suse.com>
Date:   Fri Aug 14 17:04:21 2015 +1000

    md/bitmap: return an error when bitmap superblock is corrupt.
    
    [ Upstream commit HEAD ]
    
    commit b97e92574c0bf335db1cd2ec491d8ff5cd5d0b49 upstream
        Use separate bitmaps for each nodes in the cluster
    
    bitmap_read_sb() validates the bitmap superblock that it reads in.
    If it finds an inconsistency like a bad magic number or out-of-range
    version number, it prints an error and returns, but it incorrectly
    returns zero, so the array is still assembled with the (invalid) bitmap.
    
    This means it could try to use a bitmap with a new version number which
    it therefore does not understand.
    
    This bug was introduced in 3.5 and fix as part of a larger patch in 4.1.
    So the patch is suitable for any -stable kernel in that range.
    
    Fixes: 27581e5ae01f ("md/bitmap: centralise allocation of bitmap file pages.")
    Signed-off-by: NeilBrown <neilb@suse.com>
    Reported-by: GuoQing Jiang <gqjiang@suse.com>
    
    (cherry picked from commit ed9691677d6dda3fff331673f44d18e85938bd76)
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit b03137288b2ab4e93a5c9c9bbe45e9bbc04c9b6e
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Mar 21 20:08:18 2015 -0400

    sg_start_req(): make sure that there's not too many elements in iovec
    
    [ Upstream commit 451a2886b6bf90e2fb378f7c46c655450fb96e81 ]
    
    unfortunately, allowing an arbitrary 16bit value means a possibility of
    overflow in the calculation of total number of pages in bio_map_user_iov() -
    we rely on there being no more than PAGE_SIZE members of sum in the
    first loop there.  If that sum wraps around, we end up allocating
    too small array of pointers to pages and it's easy to overflow it in
    the second loop.
    
    X-Coverup: TINC (and there's no lumber cartel either)
    Cc: stable@vger.kernel.org # way, way back
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit cc25280443deb9c421eef5914ca739012bf99375
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed Jul 22 23:14:19 2015 -0700

    iscsi-target: Fix iscsit_start_kthreads failure OOPs
    
    [ Upstream commit e54198657b65625085834847ab6271087323ffea ]
    
    This patch fixes a regression introduced with the following commit
    in v4.0-rc1 code, where a iscsit_start_kthreads() failure triggers
    a NULL pointer dereference OOPs:
    
        commit 88dcd2dab5c23b1c9cfc396246d8f476c872f0ca
        Author: Nicholas Bellinger <nab@linux-iscsi.org>
        Date:   Thu Feb 26 22:19:15 2015 -0800
    
            iscsi-target: Convert iscsi_thread_set usage to kthread.h
    
    To address this bug, move iscsit_start_kthreads() immediately
    preceeding the transmit of last login response, before signaling
    a successful transition into full-feature-phase within existing
    iscsi_target_do_tx_login_io() logic.
    
    This ensures that no target-side resource allocation failures can
    occur after the final login response has been successfully sent.
    
    Also, it adds a iscsi_conn->rx_login_comp to allow the RX thread
    to sleep to prevent other socket related failures until the final
    iscsi_post_login_handler() call is able to complete.
    
    Cc: Sagi Grimberg <sagig@mellanox.com>
    Cc: <stable@vger.kernel.org> # v3.10+
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 36ac1d14682122e3d792c66c8ae8d6d1bd093547
Author: Mimi Zohar <zohar@linux.vnet.ibm.com>
Date:   Wed Nov 5 07:53:55 2014 -0500

    ima: extend "mask" policy matching support
    
    [ Upstream commit 747cadeb108665b0474624a374aa9e13f12c9274 ]
    
    commit 4351c294b8c1028077280f761e158d167b592974 upstream.
    
    The current "mask" policy option matches files opened as MAY_READ,
    MAY_WRITE, MAY_APPEND or MAY_EXEC.  This patch extends the "mask"
    option to match files opened containing one of these modes.  For
    example, "mask=^MAY_READ" would match files opened read-write.
    
    Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
    Signed-off-by: Dr. Greg Wettstein <gw@idfusion.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 9a957a6622ab900a78a256d8c9d941b618135980
Author: Mimi Zohar <zohar@linux.vnet.ibm.com>
Date:   Wed Nov 5 07:48:36 2014 -0500

    ima: add support for new "euid" policy condition
    
    [ Upstream commit 139069eff7388407f19794384c42a534d618ccd7 ]
    
    The new "euid" policy condition measures files with the specified
    effective uid (euid).  In addition, for CAP_SETUID files it measures
    files with the specified uid or suid.
    
    Changelog:
    - fixed checkpatch.pl warnings
    - fixed avc denied {setuid} messages - based on Roberto's feedback
    
    Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
    Signed-off-by: Dr. Greg Wettstein <gw@idfusion.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 64aff127959fb0cbe7a9d872a7fd597fc07c54d2
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Thu Jul 23 22:30:31 2015 +0000

    iscsi-target: Fix iser explicit logout TX kthread leak
    
    [ Upstream commit 007d038bdf95ccfe2491d0078be54040d110fd06 ]
    
    This patch fixes a regression introduced with the following commit
    in v4.0-rc1 code, where an explicit iser-target logout would result
    in ->tx_thread_active being incorrectly cleared by the logout post
    handler, and subsequent TX kthread leak:
    
        commit 88dcd2dab5c23b1c9cfc396246d8f476c872f0ca
        Author: Nicholas Bellinger <nab@linux-iscsi.org>
        Date:   Thu Feb 26 22:19:15 2015 -0800
    
            iscsi-target: Convert iscsi_thread_set usage to kthread.h
    
    To address this bug, change iscsit_logout_post_handler_closesession()
    and iscsit_logout_post_handler_samecid() to only cmpxchg() on
    ->tx_thread_active for traditional iscsi/tcp connections.
    
    This is required because iscsi/tcp connections are invoking logout
    post handler logic directly from TX kthread context, while iser
    connections are invoking logout post handler logic from a seperate
    workqueue context.
    
    Cc: Sagi Grimberg <sagig@mellanox.com>
    Cc: <stable@vger.kernel.org> # v3.10+
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 118f2fd7d58df44c3bf830868d70e952ad0d4ecb
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed Jul 22 00:24:09 2015 -0700

    iscsi-target: Fix use-after-free during TPG session shutdown
    
    [ Upstream commit 417c20a9bdd1e876384127cf096d8ae8b559066c ]
    
    This patch fixes a use-after-free bug in iscsit_release_sessions_for_tpg()
    where se_portal_group->session_lock was incorrectly released/re-acquired
    while walking the active se_portal_group->tpg_sess_list.
    
    The can result in a NULL pointer dereference when iscsit_close_session()
    shutdown happens in the normal path asynchronously to this code, causing
    a bogus dereference of an already freed list entry to occur.
    
    To address this bug, walk the session list checking for the same state
    as before, but move entries to a local list to avoid dropping the lock
    while walking the active list.
    
    As before, signal using iscsi_session->session_restatement=1 for those
    list entries to be released locally by iscsit_free_session() code.
    
    Reported-by: Sunilkumar Nadumuttlu <sjn@datera.io>
    Cc: Sunilkumar Nadumuttlu <sjn@datera.io>
    Cc: <stable@vger.kernel.org> # v3.1+
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit b332d923c390c581ba3498d136bfb5127b67d76a
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Fri Jul 24 13:49:48 2015 +0300

    avr32: handle NULL as a valid clock object
    
    [ Upstream commit 5c02a4206538da12c040b51778d310df84c6bf6c ]
    
    Since NULL is used as valid clock object on optional clocks we have to handle
    this case in avr32 implementation as well.
    
    Fixes: e1824dfe0d8e (net: macb: Adjust tx_clk when link speed changes)
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit f9a59d88f99c3149013e44d1aa9245e67c49a800
Author: Marc-André Lureau <marcandre.lureau@redhat.com>
Date:   Fri Jul 17 15:32:03 2015 +0200

    vhost: actually track log eventfd file
    
    [ Upstream commit 7932c0bd7740f4cd2aa168d3ce0199e7af7d72d5 ]
    
    While reviewing vhost log code, I found out that log_file is never
    set. Note: I haven't tested the change (QEMU doesn't use LOG_FD yet).
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit d52f73d1c36d9429f895306403b852980e2632ef
Author: Wengang Wang <wen.gang.wang@oracle.com>
Date:   Mon Jul 6 14:35:11 2015 +0800

    rds: rds_ib_device.refcount overflow
    
    [ Upstream commit 4fabb59449aa44a585b3603ffdadd4c5f4d0c033 ]
    
    Fixes: 3e0249f9c05c ("RDS/IB: add refcount tracking to struct rds_ib_device")
    
    There lacks a dropping on rds_ib_device.refcount in case rds_ib_alloc_fmr
    failed(mr pool running out). this lead to the refcount overflow.
    
    A complain in line 117(see following) is seen. From vmcore:
    s_ib_rdma_mr_pool_depleted is 2147485544 and rds_ibdev->refcount is -2147475448.
    That is the evidence the mr pool is used up. so rds_ib_alloc_fmr is very likely
    to return ERR_PTR(-EAGAIN).
    
    115 void rds_ib_dev_put(struct rds_ib_device *rds_ibdev)
    116 {
    117         BUG_ON(atomic_read(&rds_ibdev->refcount) <= 0);
    118         if (atomic_dec_and_test(&rds_ibdev->refcount))
    119                 queue_work(rds_wq, &rds_ibdev->free_work);
    120 }
    
    fix is to drop refcount when rds_ib_alloc_fmr failed.
    
    Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com>
    Reviewed-by: Haggai Eran <haggaie@mellanox.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 3c239f5a90855526c93c38687c1437a153d737eb
Author: Dmitry Skorodumov <sdmitry@parallels.com>
Date:   Tue Jul 28 18:38:32 2015 +0400

    x86/efi: Use all 64 bit of efi_memmap in setup_e820()
    
    [ Upstream commit 7cc03e48965453b5df1cce5062c826189b04b960 ]
    
    The efi_info structure stores low 32 bits of memory map
    in efi_memmap and high 32 bits in efi_memmap_hi.
    
    While constructing pointer in the setup_e820(), need
    to take into account all 64 bit of the pointer.
    
    It is because on 64bit machine the function
    efi_get_memory_map() may return full 64bit pointer and before
    the patch that pointer was truncated.
    
    The issue is triggered on Parallles virtual machine and
    fixed with this patch.
    
    Signed-off-by: Dmitry Skorodumov <sdmitry@parallels.com>
    Cc: Denis V. Lunev <den@openvz.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 7e4ac93416bb7dbe1ef270e00d3659ab9f89aa29
Author: Zhuang Jin Can <jin.can.zhuang@intel.com>
Date:   Tue Jul 21 17:20:31 2015 +0300

    xhci: do not report PLC when link is in internal resume state
    
    [ Upstream commit aca3a0489ac019b58cf32794d5362bb284cb9b94 ]
    
    Port link change with port in resume state should not be
    reported to usbcore, as this is an internal state to be
    handled by xhci driver. Reporting PLC to usbcore may
    cause usbcore clearing PLC first and port change event irq
    won't be generated.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 7684040671e323842fb19d24de64318c58009af1
Author: Zhuang Jin Can <jin.can.zhuang@intel.com>
Date:   Tue Jul 21 17:20:29 2015 +0300

    xhci: prevent bus_suspend if SS port resuming in phase 1
    
    [ Upstream commit fac4271d1126c45ceaceb7f4a336317b771eb121 ]
    
    When the link is just waken, it's in Resume state, and driver sets PLS to
    U0. This refers to Phase 1. Phase 2 refers to when the link has completed
    the transition from Resume state to U0.
    
    With the fix of xhci: report U3 when link is in resume state, it also
    exposes an issue that usb3 roothub and controller can suspend right
    after phase 1, and this causes a hard hang in controller.
    
    To fix the issue, we need to prevent usb3 bus suspend if any port is
    resuming in phase 1.
    
    [merge separate USB2 and USB3 port resume checking to one -Mathias]
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ad418404a7c6ec68f3c7c71d45577e49f7b01b04
Author: Brian Campbell <bacam@z273.org.uk>
Date:   Tue Jul 21 17:20:28 2015 +0300

    xhci: Calculate old endpoints correctly on device reset
    
    [ Upstream commit 326124a027abc9a7f43f72dc94f6f0f7a55b02b3 ]
    
    When resetting a device the number of active TTs may need to be
    corrected by xhci_update_tt_active_eps, but the number of old active
    endpoints supplied to it was always zero, so the number of TTs and the
    bandwidth reserved for them was not updated, and could rise
    unnecessarily.
    
    This affected systems using Intel's Patherpoint chipset, which rely on
    software bandwidth checking.  For example, a Lenovo X230 would lose the
    ability to use ports on the docking station after enough suspend/resume
    cycles because the bandwidth calculated would rise with every cycle when
    a suitable device is attached.
    
    The correct number of active endpoints is calculated in the same way as
    in xhci_reserve_bandwidth.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Brian Campbell <bacam@z273.org.uk>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit cf584dd3d8b82bfc3a961827259e857c58d831f3
Author: Oliver Neukum <oneukum@suse.com>
Date:   Mon Jul 6 13:12:32 2015 +0200

    usb-storage: ignore ZTE MF 823 card reader in mode 0x1225
    
    [ Upstream commit 5fb2c782f451a4fb9c19c076e2c442839faf0f76 ]
    
    This device automatically switches itself to another mode (0x1405)
    unless the specific access pattern of Windows is followed in its
    initial mode. That makes a dirty unmount of the internal storage
    devices inevitable if they are mounted. So the card reader of
    such a device should be ignored, lest an unclean removal become
    inevitable.
    
    This replaces an earlier patch that ignored all LUNs of this device.
    That patch was overly broad.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    CC: stable@vger.kernel.org
    Reviewed-by: Lars Melin <larsm17@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 274a010fd5b56667261c5ec48a47c46bc839aa55
Author: Lior Amsalem <alior@marvell.com>
Date:   Tue Jun 30 16:09:49 2015 +0200

    ata: pmp: add quirk for Marvell 4140 SATA PMP
    
    [ Upstream commit 945b47441d83d2392ac9f984e0267ad521f24268 ]
    
    This commit adds the necessary quirk to make the Marvell 4140 SATA PMP
    work properly. This PMP doesn't like SRST on port number 4 (the host
    port) so this commit marks this port as not supporting SRST.
    
    Signed-off-by: Lior Amsalem <alior@marvell.com>
    Reviewed-by: Nadav Haklai <nadavh@marvell.com>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 595422856699eec52732e03d3711c7045ab96f08
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Jul 22 18:05:53 2015 -0400

    blkcg: fix gendisk reference leak in blkg_conf_prep()
    
    [ Upstream commit 5f6c2d2b7dbb541c1e922538c49fa04c494ae3d7 ]
    
    When a blkcg configuration is targeted to a partition rather than a
    whole device, blkg_conf_prep fails with -EINVAL; unfortunately, it
    forgets to put the gendisk ref in that case.  Fix it.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 1d9103f6387b1174d769e2f87802af1bd8a7563a
Author: Bernhard Bender <bernhard.bender@bytecmed.com>
Date:   Thu Jul 23 13:58:08 2015 -0700

    Input: usbtouchscreen - avoid unresponsive TSC-30 touch screen
    
    [ Upstream commit 968491709e5b1aaf429428814fff3d932fa90b60 ]
    
    This patch fixes a problem in the usbtouchscreen driver for DMC TSC-30
    touch screen.  Due to a missing delay between the RESET and SET_RATE
    commands, the touch screen may become unresponsive during system startup or
    driver loading.
    
    According to the DMC documentation, a delay is needed after the RESET
    command to allow the chip to complete its internal initialization. As this
    delay is not guaranteed, we had a system where the touch screen
    occasionally did not send any touch data. There was no other indication of
    the problem.
    
    The patch fixes the problem by adding a 150ms delay between the RESET and
    SET_RATE commands.
    
    Cc: stable@vger.kernel.org
    Suggested-by: Jakob Mustafa <jakob.mustafa@bytecmed.com>
    Signed-off-by: Bernhard Bender <bernhard.bender@bytecmed.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ba86d5813c5a676d076c2d580ddc1cbb1b013ebf
Author: Chris Metcalf <cmetcalf@ezchip.com>
Date:   Thu Jul 23 14:11:09 2015 -0400

    tile: use free_bootmem_late() for initrd
    
    [ Upstream commit 3f81d2447b37ac697b3c600039f2c6b628c06e21 ]
    
    We were previously using free_bootmem() and just getting lucky
    that nothing too bad happened.
    
    Signed-off-by: Chris Metcalf <cmetcalf@ezchip.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ed220ba145d8f966a235d04f3cda64d9c2976475
Author: NeilBrown <neilb@suse.com>
Date:   Fri Jul 24 09:22:16 2015 +1000

    md/raid1: fix test for 'was read error from last working device'.
    
    [ Upstream commit 34cab6f42003cb06f48f86a86652984dec338ae9 ]
    
    When we get a read error from the last working device, we don't
    try to repair it, and don't fail the device.  We simple report a
    read error to the caller.
    
    However the current test for 'is this the last working device' is
    wrong.
    When there is only one fully working device, it assumes that a
    non-faulty device is that device.  However a spare which is rebuilding
    would be non-faulty but so not the only working device.
    
    So change the test from "!Faulty" to "In_sync".  If ->degraded says
    there is only one fully working device and this device is in_sync,
    this must be the one.
    
    This bug has existed since we allowed read_balance to read from
    a recovering spare in v3.0
    
    Reported-and-tested-by: Alexander Lyakas <alex.bolshoy@gmail.com>
    Fixes: 76073054c95b ("md/raid1: clean up read_balance.")
    Cc: stable@vger.kernel.org (v3.0+)
    Signed-off-by: NeilBrown <neilb@suse.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit b98982262ccdb0d3f24f1c4858553c3c1c3b84d5
Author: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date:   Wed Jul 22 16:44:26 2015 +0200

    mmc: sdhci-esdhc: Make 8BIT bus work
    
    [ Upstream commit 8e91125ff3f57f15c6568e2a6d32743b3f7815e4 ]
    
    Support for 8BIT bus with was added some time ago to sdhci-esdhc but
    then missed to remove the 8BIT from the reserved bit mask which made
    8BIT non functional.
    
    Fixes: 66b50a00992d ("mmc: esdhc: Add support for 8-bit bus width and..")
    Signed-off-by: Joakim Tjernlund <joakim.tjernlund@transmode.se>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 2dcae0edb07eff075666c233d4e2ac3294d9e99e
Author: Tom Hughes <tom@compton.nu>
Date:   Mon Jun 29 19:41:49 2015 +0100

    mac80211: clear subdir_stations when removing debugfs
    
    [ Upstream commit 4479004e6409087d1b4986881dc98c6c15dffb28 ]
    
    If we don't do this, and we then fail to recreate the debugfs
    directory during a mode change, then we will fail later trying
    to add stations to this now bogus directory:
    
    BUG: unable to handle kernel NULL pointer dereference at 0000006c
    IP: [<c0a92202>] mutex_lock+0x12/0x30
    Call Trace:
    [<c0678ab4>] start_creating+0x44/0xc0
    [<c0679203>] debugfs_create_dir+0x13/0xf0
    [<f8a938ae>] ieee80211_sta_debugfs_add+0x6e/0x490 [mac80211]
    
    Cc: stable@kernel.org
    Signed-off-by: Tom Hughes <tom@compton.nu>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 845a83bb5a03839b77c5b1ccc32ded17f3d4b841
Author: Seymour, Shane M <shane.seymour@hp.com>
Date:   Thu Jul 2 12:01:10 2015 +0000

    st: null pointer dereference panic caused by use after kref_put by st_open
    
    [ Upstream commit e7ac6c6666bec0a354758a1298d3231e4a635362 ]
    
    Two SLES11 SP3 servers encountered similar crashes simultaneously
    following some kind of SAN/tape target issue:
    
    ...
    qla2xxx [0000:81:00.0]-801c:3: Abort command issued nexus=3:0:2 --  1 2002.
    qla2xxx [0000:81:00.0]-801c:3: Abort command issued nexus=3:0:2 --  1 2002.
    qla2xxx [0000:81:00.0]-8009:3: DEVICE RESET ISSUED nexus=3:0:2 cmd=ffff882f89c2c7c0.
    qla2xxx [0000:81:00.0]-800c:3: do_reset failed for cmd=ffff882f89c2c7c0.
    qla2xxx [0000:81:00.0]-800f:3: DEVICE RESET FAILED: Task management failed nexus=3:0:2 cmd=ffff882f89c2c7c0.
    qla2xxx [0000:81:00.0]-8009:3: TARGET RESET ISSUED nexus=3:0:2 cmd=ffff882f89c2c7c0.
    qla2xxx [0000:81:00.0]-800c:3: do_reset failed for cmd=ffff882f89c2c7c0.
    qla2xxx [0000:81:00.0]-800f:3: TARGET RESET FAILED: Task management failed nexus=3:0:2 cmd=ffff882f89c2c7c0.
    qla2xxx [0000:81:00.0]-8012:3: BUS RESET ISSUED nexus=3:0:2.
    qla2xxx [0000:81:00.0]-802b:3: BUS RESET SUCCEEDED nexus=3:0:2.
    qla2xxx [0000:81:00.0]-505f:3: Link is operational (8 Gbps).
    qla2xxx [0000:81:00.0]-8018:3: ADAPTER RESET ISSUED nexus=3:0:2.
    qla2xxx [0000:81:00.0]-00af:3: Performing ISP error recovery - ha=ffff88bf04d18000.
     rport-3:0-0: blocked FC remote port time out: removing target and saving binding
    qla2xxx [0000:81:00.0]-505f:3: Link is operational (8 Gbps).
    qla2xxx [0000:81:00.0]-8017:3: ADAPTER RESET SUCCEEDED nexus=3:0:2.
     rport-2:0-0: blocked FC remote port time out: removing target and saving binding
    sg_rq_end_io: device detached
    BUG: unable to handle kernel NULL pointer dereference at 00000000000002a8
    IP: [<ffffffff8133b268>] __pm_runtime_idle+0x28/0x90
    PGD 7e6586f067 PUD 7e5af06067 PMD 0 [1739975.390354] Oops: 0002 [#1] SMP
    CPU 0
    ...
    Supported: No, Proprietary modules are loaded [1739975.390463]
    Pid: 27965, comm: ABCD Tainted: PF           X 3.0.101-0.29-default #1 HP ProLiant DL580 Gen8
    RIP: 0010:[<ffffffff8133b268>]  [<ffffffff8133b268>] __pm_runtime_idle+0x28/0x90
    RSP: 0018:ffff8839dc1e7c68  EFLAGS: 00010202
    RAX: 0000000000000000 RBX: ffff883f0592fc00 RCX: 0000000000000090
    RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000138
    RBP: 0000000000000138 R08: 0000000000000010 R09: ffffffff81bd39d0
    R10: 00000000000009c0 R11: ffffffff81025790 R12: 0000000000000001
    R13: ffff883022212b80 R14: 0000000000000004 R15: ffff883022212b80
    FS:  00007f8e54560720(0000) GS:ffff88407f800000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 00000000000002a8 CR3: 0000007e6ced6000 CR4: 00000000001407f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process ABCD (pid: 27965, threadinfo ffff8839dc1e6000, task ffff883592e0c640)
    Stack:
     ffff883f0592fc00 00000000fffffffa 0000000000000001 ffff883022212b80
     ffff883eff772400 ffffffffa03fa309 0000000000000000 0000000000000000
     ffffffffa04003a0 ffff883f063196c0 ffff887f0379a930 ffffffff8115ea1e
    Call Trace:
     [<ffffffffa03fa309>] st_open+0x129/0x240 [st]
     [<ffffffff8115ea1e>] chrdev_open+0x13e/0x200
     [<ffffffff811588a8>] __dentry_open+0x198/0x310
     [<ffffffff81167d74>] do_last+0x1f4/0x800
     [<ffffffff81168fe9>] path_openat+0xd9/0x420
     [<ffffffff8116946c>] do_filp_open+0x4c/0xc0
     [<ffffffff8115a00f>] do_sys_open+0x17f/0x250
     [<ffffffff81468d92>] system_call_fastpath+0x16/0x1b
     [<00007f8e4f617fd0>] 0x7f8e4f617fcf
    Code: eb d3 90 48 83 ec 28 40 f6 c6 04 48 89 6c 24 08 4c 89 74 24 20 48 89 fd 48 89 1c 24 4c 89 64 24 10 41 89 f6 4c 89 6c 24 18 74 11 <f0> ff 8f 70 01 00 00 0f 94 c0 45 31 ed 84 c0 74 2b 4c 8d a5 a0
    RIP  [<ffffffff8133b268>] __pm_runtime_idle+0x28/0x90
     RSP <ffff8839dc1e7c68>
    CR2: 00000000000002a8
    
    Analysis reveals the cause of the crash to be due to STp->device
    being NULL. The pointer was NULLed via scsi_tape_put(STp) when it
    calls scsi_tape_release(). In st_open() we jump to err_out after
    scsi_block_when_processing_errors() completes and returns the
    device as offline (sdev_state was SDEV_DEL):
    
    1180 /* Open the device. Needs to take the BKL only because of incrementing the SCSI host
    1181    module count. */
    1182 static int st_open(struct inode *inode, struct file *filp)
    1183 {
    1184         int i, retval = (-EIO);
    1185         int resumed = 0;
    1186         struct scsi_tape *STp;
    1187         struct st_partstat *STps;
    1188         int dev = TAPE_NR(inode);
    1189         char *name;
    ...
    1217         if (scsi_autopm_get_device(STp->device) < 0) {
    1218                 retval = -EIO;
    1219                 goto err_out;
    1220         }
    1221         resumed = 1;
    1222         if (!scsi_block_when_processing_errors(STp->device)) {
    1223                 retval = (-ENXIO);
    1224                 goto err_out;
    1225         }
    ...
    1264  err_out:
    1265         normalize_buffer(STp->buffer);
    1266         spin_lock(&st_use_lock);
    1267         STp->in_use = 0;
    1268         spin_unlock(&st_use_lock);
    1269         scsi_tape_put(STp); <-- STp->device = 0 after this
    1270         if (resumed)
    1271                 scsi_autopm_put_device(STp->device);
    1272         return retval;
    
    The ref count for the struct scsi_tape had already been reduced
    to 1 when the .remove method of the st module had been called.
    The kref_put() in scsi_tape_put() caused scsi_tape_release()
    to be called:
    
    0266 static void scsi_tape_put(struct scsi_tape *STp)
    0267 {
    0268         struct scsi_device *sdev = STp->device;
    0269
    0270         mutex_lock(&st_ref_mutex);
    0271         kref_put(&STp->kref, scsi_tape_release); <-- calls this
    0272         scsi_device_put(sdev);
    0273         mutex_unlock(&st_ref_mutex);
    0274 }
    
    In scsi_tape_release() the struct scsi_device in the struct
    scsi_tape gets set to NULL:
    
    4273 static void scsi_tape_release(struct kref *kref)
    4274 {
    4275         struct scsi_tape *tpnt = to_scsi_tape(kref);
    4276         struct gendisk *disk = tpnt->disk;
    4277
    4278         tpnt->device = NULL; <<<---- where the dev is nulled
    4279
    4280         if (tpnt->buffer) {
    4281                 normalize_buffer(tpnt->buffer);
    4282                 kfree(tpnt->buffer->reserved_pages);
    4283                 kfree(tpnt->buffer);
    4284         }
    4285
    4286         disk->private_data = NULL;
    4287         put_disk(disk);
    4288         kfree(tpnt);
    4289         return;
    4290 }
    
    Although the problem was reported on SLES11.3 the problem appears
    in linux-next as well.
    
    The crash is fixed by reordering the code so we no longer access
    the struct scsi_tape after the kref_put() is done on it in st_open().
    
    Signed-off-by: Shane Seymour <shane.seymour@hp.com>
    Signed-off-by: Darren Lavender <darren.lavender@hp.com>
    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.com>
    Acked-by: Kai Mäkisara <kai.makisara@kolumbus.fi>
    Cc: stable@vger.kernel.org
    Signed-off-by: James Bottomley <JBottomley@Odin.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 1380a063dd9ce1a43e9553e05416c6a9cc156ed7
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jul 30 22:30:29 2015 +0200

    ALSA: hda - Fix MacBook Pro 5,2 quirk
    
    [ Upstream commit 649ccd08534ee26deb2e5b08509800d0e95167f5 ]
    
    MacBook Pro 5,2 with ALC889 codec had already a fixup entry, but this
    seems not working correctly, a fix for pin NID 0x15 is needed in
    addition.  It's equivalent with the fixup for MacBook Air 1,1, so use
    this instead.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=102131
    Reported-and-tested-by: Jeffery Miller <jefferym@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 4e8e9e996e630fe86aeff5c9c258e0cfe2840b08
Author: Yao-Wen Mao <yaowen@google.com>
Date:   Wed Jul 29 15:13:54 2015 +0800

    ALSA: usb-audio: add dB range mapping for some devices
    
    [ Upstream commit 2d1cb7f658fb9c3ba8f9dab8aca297d4dfdec835 ]
    
    Add the correct dB ranges of Bose Companion 5 and Drangonfly DAC 1.2.
    
    Signed-off-by: Yao-Wen Mao <yaowen@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a20f7f285a4f8a665d15c4c564597ffd4677d2cf
Author: Dominic Sacré <dominic.sacre@gmx.de>
Date:   Tue Jun 30 17:41:33 2015 +0200

    ALSA: usb-audio: Add MIDI support for Steinberg MI2/MI4
    
    [ Upstream commit 0689a86ae814f39af94a9736a0a5426dd82eb107 ]
    
    The Steinberg MI2 and MI4 interfaces are compatible with the USB class
    audio spec, but the MIDI part of the devices is reported as a vendor
    specific interface.
    
    This patch adds entries to quirks-table.h to recognize the MIDI
    endpoints. Audio functionality was already working and is unaffected by
    this change.
    
    Signed-off-by: Dominic Sacré <dominic.sacre@gmx.de>
    Signed-off-by: Albert Huitsing <albert@huitsing.nl>
    Acked-by: Clemens Ladisch <clemens@ladisch.de>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 51871c2b908de6353bdafeeda28d52b51dedf306
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Jul 16 14:10:17 2015 +0200

    genirq: Prevent resend to interrupts marked IRQ_NESTED_THREAD
    
    [ Upstream commit 75a06189fc508a2acf470b0b12710362ffb2c4b1 ]
    
    The resend mechanism happily calls the interrupt handler of interrupts
    which are marked IRQ_NESTED_THREAD from softirq context. This can
    result in crashes because the interrupt handler is not the proper way
    to invoke the device handlers. They must be invoked via
    handle_nested_irq.
    
    Prevent the resend even if the interrupt has no valid parent irq
    set. Its better to have a lost interrupt than a crashing machine.
    
    Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit d9698525c8e9f5236d74e36df8a828b6dcc23861
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Mon Jul 6 17:58:19 2015 +0200

    s390/sclp: clear upper register halves in _sclp_print_early
    
    [ Upstream commit f9c87a6f46d508eae0d9ae640be98d50f237f827 ]
    
    If the kernel is compiled with gcc 5.1 and the XZ compression option
    the decompress_kernel function calls _sclp_print_early in 64-bit mode
    while the content of the upper register half of %r6 is non-zero.
    This causes a specification exception on the servc instruction in
    _sclp_servc.
    
    The _sclp_print_early function saves and restores the upper registers
    halves but it fails to clear them for the 31-bit code of the mini sclp
    driver.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 0d814959f8d53f7782c73192cd1c7eaa2c0c3920
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date:   Wed Jul 8 02:42:38 2015 +0100

    freeing unlinked file indefinitely delayed
    
    [ Upstream commit 75a6f82a0d10ef8f13cd8fe7212911a0252ab99e ]
    
    	Normally opening a file, unlinking it and then closing will have
    the inode freed upon close() (provided that it's not otherwise busy and
    has no remaining links, of course).  However, there's one case where that
    does *not* happen.  Namely, if you open it by fhandle with cold dcache,
    then unlink() and close().
    
    	In normal case you get d_delete() in unlink(2) notice that dentry
    is busy and unhash it; on the final dput() it will be forcibly evicted from
    dcache, triggering iput() and inode removal.  In this case, though, we end
    up with *two* dentries - disconnected (created by open-by-fhandle) and
    regular one (used by unlink()).  The latter will have its reference to inode
    dropped just fine, but the former will not - it's considered hashed (it
    is on the ->s_anon list), so it will stay around until the memory pressure
    will finally do it in.  As the result, we have the final iput() delayed
    indefinitely.  It's trivial to reproduce -
    
    void flush_dcache(void)
    {
            system("mount -o remount,rw /");
    }
    
    static char buf[20 * 1024 * 1024];
    
    main()
    {
            int fd;
            union {
                    struct file_handle f;
                    char buf[MAX_HANDLE_SZ];
            } x;
            int m;
    
            x.f.handle_bytes = sizeof(x);
            chdir("/root");
            mkdir("foo", 0700);
            fd = open("foo/bar", O_CREAT | O_RDWR, 0600);
            close(fd);
            name_to_handle_at(AT_FDCWD, "foo/bar", &x.f, &m, 0);
            flush_dcache();
            fd = open_by_handle_at(AT_FDCWD, &x.f, O_RDWR);
            unlink("foo/bar");
            write(fd, buf, sizeof(buf));
            system("df .");			/* 20Mb eaten */
            close(fd);
            system("df .");			/* should've freed those 20Mb */
            flush_dcache();
            system("df .");			/* should be the same as #2 */
    }
    
    will spit out something like
    Filesystem     1K-blocks   Used Available Use% Mounted on
    /dev/root         322023 303843      1131 100% /
    Filesystem     1K-blocks   Used Available Use% Mounted on
    /dev/root         322023 303843      1131 100% /
    Filesystem     1K-blocks   Used Available Use% Mounted on
    /dev/root         322023 283282     21692  93% /
    - inode gets freed only when dentry is finally evicted (here we trigger
    than by remount; normally it would've happened in response to memory
    pressure hell knows when).
    
    Cc: stable@vger.kernel.org # v2.6.38+; earlier ones need s/kill_it/unhash_it/
    Acked-by: J. Bruce Fields <bfields@fieldses.org>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit f9f58191011b986f4a92a792a8328f5c188ea1b3
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed Jun 10 01:33:36 2015 +0200

    ACPI / init: Switch over platform to the ACPI mode later
    
    [ Upstream commit cdbbeb69d4b93455a73edff725639216d7fe0b38 ]
    
    commit b064a8fa77dfead647564c46ac8fc5b13bd1ab73 upstream.
    
    Commit 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before
    timekeeping_init()" moved the ACPI subsystem initialization,
    including the ACPI mode enabling, to an earlier point in the
    initialization sequence, to allow the timekeeping subsystem
    use ACPI early.  Unfortunately, that resulted in boot regressions
    on some systems and the early ACPI initialization was moved toward
    its original position in the kernel initialization code by commit
    c4e1acbb35e4 "ACPI / init: Invoke early ACPI initialization later".
    
    However, that turns out to be insufficient, as boot is still broken
    on the Tyan S8812 mainboard.
    
    To fix that issue, split the ACPI early initialization code into
    two pieces so the majority of it still located in acpi_early_init()
    and the part switching over the platform into the ACPI mode goes into
    a new function, acpi_subsystem_init(), executed at the original early
    ACPI initialization spot.
    
    That fixes the Tyan S8812 boot problem, but still allows ACPI
    tables to be loaded earlier which is useful to the EFI code in
    efi_enter_virtual_mode().
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141
    Fixes: 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before timekeeping_init()"
    Reported-and-tested-by: Marius Tolzmann <tolzmann@molgen.mpg.de>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Acked-by: Toshi Kani <toshi.kani@hp.com>
    Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
    Reviewed-by: Lee, Chun-Yi <jlee@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 9048f810342cc1b4e49a84a98a596e0d36834eeb
Author: Jeff Layton <jlayton@poochiereds.net>
Date:   Thu Jul 30 06:57:46 2015 -0400

    nfsd: do nfs4_check_fh in nfs4_check_file instead of nfs4_check_olstateid
    
    [ Upstream commit 1ccdd6c6e9a342c2ed4ced38faa67303226a2a6a ]
    
    commit 8fcd461db7c09337b6d2e22d25eb411123f379e3 upstream.
    
    Currently, preprocess_stateid_op calls nfs4_check_olstateid which
    verifies that the open stateid corresponds to the current filehandle in the
    call by calling nfs4_check_fh.
    
    If the stateid is a NFS4_DELEG_STID however, then no such check is done.
    This could cause incorrect enforcement of permissions, because the
    nfsd_permission() call in nfs4_check_file uses current the current
    filehandle, but any subsequent IO operation will use the file descriptor
    in the stateid.
    
    Move the call to nfs4_check_fh into nfs4_check_file instead so that it
    can be done for all stateid types.
    
    Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
    [bfields: moved fh check to avoid NULL deref in special stateid case]
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 493a50c6b1d428b1f2bee4356ef073c4d19e4c8e
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu Jun 18 16:44:59 2015 +0200

    nfsd: refactor nfs4_preprocess_stateid_op
    
    [ Upstream commit 3b5c2aed0e5557c6bc4a305e7627a16a764b4cdb ]
    
    commit a0649b2d3fffb1cde8745568c767f3a55a3462bc upstream.
    
    Split out two self contained helpers to make the function more readable.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Cc: Jeff Layton <jlayton@poochiereds.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 4b8ec51eb5e94596b4a3d465b93a3d18375b98b9
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Sat May 30 14:31:24 2015 +0200

    kvm: x86: fix kvm_apic_has_events to check for NULL pointer
    
    [ Upstream commit ce40cd3fc7fa40a6119e5fe6c0f2bc0eb4541009 ]
    
    Malicious (or egregiously buggy) userspace can trigger it, but it
    should never happen in normal operation.
    
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 6f03dcb145cc383bdbef043039d13fc674c8062e
Author: Amanieu d'Antras <amanieu@gmail.com>
Date:   Thu Aug 6 15:46:26 2015 -0700

    signal: fix information leak in copy_siginfo_from_user32
    
    [ Upstream commit 3c00cb5e68dc719f2fc73a33b1b230aadfcb1309 ]
    
    This function can leak kernel stack data when the user siginfo_t has a
    positive si_code value.  The top 16 bits of si_code descibe which fields
    in the siginfo_t union are active, but they are treated inconsistently
    between copy_siginfo_from_user32, copy_siginfo_to_user32 and
    copy_siginfo_to_user.
    
    copy_siginfo_from_user32 is called from rt_sigqueueinfo and
    rt_tgsigqueueinfo in which the user has full control overthe top 16 bits
    of si_code.
    
    This fixes the following information leaks:
    x86:   8 bytes leaked when sending a signal from a 32-bit process to
           itself. This leak grows to 16 bytes if the process uses x32.
           (si_code = __SI_CHLD)
    x86:   100 bytes leaked when sending a signal from a 32-bit process to
           a 64-bit process. (si_code = -1)
    sparc: 4 bytes leaked when sending a signal from a 32-bit process to a
           64-bit process. (si_code = any)
    
    parsic and s390 have similar bugs, but they are not vulnerable because
    rt_[tg]sigqueueinfo have checks that prevent sending a positive si_code
    to a different process.  These bugs are also fixed for consistency.
    
    Signed-off-by: Amanieu d'Antras <amanieu@gmail.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Russell King <rmk@arm.linux.org.uk>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Chris Metcalf <cmetcalf@ezchip.com>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ad98e577ca49e4bc3c2d3afede2c5918dde55ba4
Author: Amanieu d'Antras <amanieu@gmail.com>
Date:   Thu Aug 6 15:46:29 2015 -0700

    signal: fix information leak in copy_siginfo_to_user
    
    [ Upstream commit c08a75d950725cdd87c19232a5a3850c51520359 ]
    
    commit 26135022f85105ad725cda103fa069e29e83bd16 upstream.
    
    This function may copy the si_addr_lsb, si_lower and si_upper fields to
    user mode when they haven't been initialized, which can leak kernel
    stack data to user mode.
    
    Just checking the value of si_code is insufficient because the same
    si_code value is shared between multiple signals.  This is solved by
    checking the value of si_signo in addition to si_code.
    
    Signed-off-by: Amanieu d'Antras <amanieu@gmail.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Russell King <rmk@arm.linux.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ab1bd6fbf4a2fa1c4321428c72029d70a2b8eb95
Author: Amanieu d'Antras <amanieu@gmail.com>
Date:   Thu Aug 6 15:46:33 2015 -0700

    signalfd: fix information leak in signalfd_copyinfo
    
    [ Upstream commit 3ead7c52bdb0ab44f4bb1feed505a8323cc12ba7 ]
    
    This function may copy the si_addr_lsb field to user mode when it hasn't
    been initialized, which can leak kernel stack data to user mode.
    
    Just checking the value of si_code is insufficient because the same
    si_code value is shared between multiple signals.  This is solved by
    checking the value of si_signo in addition to si_code.
    
    Signed-off-by: Amanieu d'Antras <amanieu@gmail.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 1f020ced342358949feec269e3e33801430f89eb
Author: Michal Hocko <mhocko@suse.cz>
Date:   Tue Aug 4 14:36:58 2015 -0700

    mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations
    
    [ Upstream commit ecf5fc6e9654cd7a268c782a523f072b2f1959f9 ]
    
    Nikolay has reported a hang when a memcg reclaim got stuck with the
    following backtrace:
    
    PID: 18308  TASK: ffff883d7c9b0a30  CPU: 1   COMMAND: "rsync"
      #0 __schedule at ffffffff815ab152
      #1 schedule at ffffffff815ab76e
      #2 schedule_timeout at ffffffff815ae5e5
      #3 io_schedule_timeout at ffffffff815aad6a
      #4 bit_wait_io at ffffffff815abfc6
      #5 __wait_on_bit at ffffffff815abda5
      #6 wait_on_page_bit at ffffffff8111fd4f
      #7 shrink_page_list at ffffffff81135445
      #8 shrink_inactive_list at ffffffff81135845
      #9 shrink_lruvec at ffffffff81135ead
     #10 shrink_zone at ffffffff811360c3
     #11 shrink_zones at ffffffff81136eff
     #12 do_try_to_free_pages at ffffffff8113712f
     #13 try_to_free_mem_cgroup_pages at ffffffff811372be
     #14 try_charge at ffffffff81189423
     #15 mem_cgroup_try_charge at ffffffff8118c6f5
     #16 __add_to_page_cache_locked at ffffffff8112137d
     #17 add_to_page_cache_lru at ffffffff81121618
     #18 pagecache_get_page at ffffffff8112170b
     #19 grow_dev_page at ffffffff811c8297
     #20 __getblk_slow at ffffffff811c91d6
     #21 __getblk_gfp at ffffffff811c92c1
     #22 ext4_ext_grow_indepth at ffffffff8124565c
     #23 ext4_ext_create_new_leaf at ffffffff81246ca8
     #24 ext4_ext_insert_extent at ffffffff81246f09
     #25 ext4_ext_map_blocks at ffffffff8124a848
     #26 ext4_map_blocks at ffffffff8121a5b7
     #27 mpage_map_one_extent at ffffffff8121b1fa
     #28 mpage_map_and_submit_extent at ffffffff8121f07b
     #29 ext4_writepages at ffffffff8121f6d5
     #30 do_writepages at ffffffff8112c490
     #31 __filemap_fdatawrite_range at ffffffff81120199
     #32 filemap_flush at ffffffff8112041c
     #33 ext4_alloc_da_blocks at ffffffff81219da1
     #34 ext4_rename at ffffffff81229b91
     #35 ext4_rename2 at ffffffff81229e32
     #36 vfs_rename at ffffffff811a08a5
     #37 SYSC_renameat2 at ffffffff811a3ffc
     #38 sys_renameat2 at ffffffff811a408e
     #39 sys_rename at ffffffff8119e51e
     #40 system_call_fastpath at ffffffff815afa89
    
    Dave Chinner has properly pointed out that this is a deadlock in the
    reclaim code because ext4 doesn't submit pages which are marked by
    PG_writeback right away.
    
    The heuristic was introduced by commit e62e384e9da8 ("memcg: prevent OOM
    with too many dirty pages") and it was applied only when may_enter_fs
    was specified.  The code has been changed by c3b94f44fcb0 ("memcg:
    further prevent OOM with too many dirty pages") which has removed the
    __GFP_FS restriction with a reasoning that we do not get into the fs
    code.  But this is not sufficient apparently because the fs doesn't
    necessarily submit pages marked PG_writeback for IO right away.
    
    ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily
    submit the bio.  Instead it tries to map more pages into the bio and
    mpage_map_one_extent might trigger memcg charge which might end up
    waiting on a page which is marked PG_writeback but hasn't been submitted
    yet so we would end up waiting for something that never finishes.
    
    Fix this issue by replacing __GFP_IO by may_enter_fs check (for case 2)
    before we go to wait on the writeback.  The page fault path, which is
    the only path that triggers memcg oom killer since 3.12, shouldn't
    require GFP_NOFS and so we shouldn't reintroduce the premature OOM
    killer issue which was originally addressed by the heuristic.
    
    As per David Chinner the xfs is doing similar thing since 2.6.15 already
    so ext4 is not the only affected filesystem.  Moreover he notes:
    
    : For example: IO completion might require unwritten extent conversion
    : which executes filesystem transactions and GFP_NOFS allocations. The
    : writeback flag on the pages can not be cleared until unwritten
    : extent conversion completes. Hence memory reclaim cannot wait on
    : page writeback to complete in GFP_NOFS context because it is not
    : safe to do so, memcg reclaim or otherwise.
    
    Cc: stable@vger.kernel.org # 3.9+
    [tytso@mit.edu: corrected the control flow]
    Fixes: c3b94f44fcb0 ("memcg: further prevent OOM with too many dirty pages")
    Reported-by: Nikolay Borisov <kernel@kyup.com>
    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 282caf989e8371a4f0546b85a8c7622cc5c2cc71
Author: Scott Wood <scottwood@freescale.com>
Date:   Fri Jun 26 19:43:58 2015 -0500

    mtd: nand: Fix NAND_USE_BOUNCE_BUFFER flag conflict
    
    [ Upstream commit 5f867db63473f32cce1b868e281ebd42a41f8fad ]
    
    Commit 66507c7bc8895f0da6b ("mtd: nand: Add support to use nand_base
    poi databuf as bounce buffer") added a flag NAND_USE_BOUNCE_BUFFER
    using the same bit value as the existing NAND_BUSWIDTH_AUTO.
    
    Cc: Kamal Dasu <kdasu.kdev@gmail.com>
    Fixes: 66507c7bc8895f0da6b ("mtd: nand: Add support to use nand_base
    	poi databuf as bounce buffer")
    Signed-off-by: Scott Wood <scottwood@freescale.com>
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 93aa06df92f68c9fb0e5e9f04d959d05f5e91af9
Author: Pieter Hollants <pieter@hollants.com>
Date:   Mon Jul 20 11:56:17 2015 +0200

    USB: qcserial: Add support for Dell Wireless 5809e 4G Modem
    
    [ Upstream commit 6da3700c98cdc8360f55c5510915efae1d66deea ]
    
    Added the USB IDs 0x413c:0x81b1 for the "Dell Wireless 5809e Gobi(TM) 4G
    LTE Mobile Broadband Card", a Dell-branded Sierra Wireless EM7305 LTE
    card in M.2 form factor, used eg. in Dell's Latitude E7540 Notebook
    series.
    
    "lsusb -v" output for this device:
    
    Bus 002 Device 003: ID 413c:81b1 Dell Computer Corp.
    Device Descriptor:
      bLength                18
      bDescriptorType         1
      bcdUSB               2.00
      bDeviceClass            0
      bDeviceSubClass         0
      bDeviceProtocol         0
      bMaxPacketSize0        64
      idVendor           0x413c Dell Computer Corp.
      idProduct          0x81b1
      bcdDevice            0.06
      iManufacturer           1 Sierra Wireless, Incorporated
      iProduct                2 Dell Wireless 5809e Gobiâ„¢ 4G LTE Mobile Broadband Card
      iSerial                 3
      bNumConfigurations      2
      Configuration Descriptor:
        bLength                 9
        bDescriptorType         2
        wTotalLength          204
        bNumInterfaces          4
        bConfigurationValue     1
        iConfiguration          0
        bmAttributes         0xe0
          Self Powered
          Remote Wakeup
        MaxPower              500mA
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        0
          bAlternateSetting       0
          bNumEndpoints           2
          bInterfaceClass       255 Vendor Specific Class
          bInterfaceSubClass    255 Vendor Specific Subclass
          bInterfaceProtocol    255 Vendor Specific Protocol
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x81  EP 1 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval               0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x01  EP 1 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval               0
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        2
          bAlternateSetting       0
          bNumEndpoints           3
          bInterfaceClass       255 Vendor Specific Class
          bInterfaceSubClass      0
          bInterfaceProtocol      0
          iInterface              0
          ** UNRECOGNIZED:  05 24 00 10 01
          ** UNRECOGNIZED:  05 24 01 00 00
          ** UNRECOGNIZED:  04 24 02 02
          ** UNRECOGNIZED:  05 24 06 00 00
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x83  EP 3 IN
            bmAttributes            3
              Transfer Type            Interrupt
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x000c  1x 12 bytes
            bInterval               9
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x82  EP 2 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval               0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x02  EP 2 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval               0
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        3
          bAlternateSetting       0
          bNumEndpoints           3
          bInterfaceClass       255 Vendor Specific Class
          bInterfaceSubClass      0
          bInterfaceProtocol      0
          iInterface              0
          ** UNRECOGNIZED:  05 24 00 10 01
          ** UNRECOGNIZED:  05 24 01 00 00
          ** UNRECOGNIZED:  04 24 02 02
          ** UNRECOGNIZED:  05 24 06 00 00
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x85  EP 5 IN
            bmAttributes            3
              Transfer Type            Interrupt
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x000c  1x 12 bytes
            bInterval               9
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x84  EP 4 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval               0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x03  EP 3 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval               0
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        8
          bAlternateSetting       0
          bNumEndpoints           3
          bInterfaceClass       255 Vendor Specific Class
          bInterfaceSubClass    255 Vendor Specific Subclass
          bInterfaceProtocol    255 Vendor Specific Protocol
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x87  EP 7 IN
            bmAttributes            3
              Transfer Type            Interrupt
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x000a  1x 10 bytes
            bInterval               9
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x86  EP 6 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval               0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x04  EP 4 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval               0
            ** UNRECOGNIZED:  2c ff 42 49 53 54 00 01 07 f5 40 f6 00 00 00 00 01 f7 c4 09 02 f8 c4 09 03 f9 88 13 04 fa 10 27 05 fb 10 27 06 fc c4 09 07 fd c4 09
      Configuration Descriptor:
        bLength                 9
        bDescriptorType         2
        wTotalLength           95
        bNumInterfaces          2
        bConfigurationValue     2
        iConfiguration          0
        bmAttributes         0xe0
          Self Powered
          Remote Wakeup
        MaxPower              500mA
        Interface Association:
          bLength                 8
          bDescriptorType        11
          bFirstInterface        12
          bInterfaceCount         2
          bFunctionClass          2 Communications
          bFunctionSubClass      14
          bFunctionProtocol       0
          iFunction               0
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber       12
          bAlternateSetting       0
          bNumEndpoints           1
          bInterfaceClass         2 Communications
          bInterfaceSubClass     14
          bInterfaceProtocol      0
          iInterface              0
          CDC Header:
            bcdCDC               1.10
          CDC Union:
            bMasterInterface        12
            bSlaveInterface         13
          CDC MBIM:
            bcdMBIMVersion       1.00
            wMaxControlMessage   4096
            bNumberFilters       32
            bMaxFilterSize       128
            wMaxSegmentSize      1500
            bmNetworkCapabilities 0x20
              8-byte ntb input size
          CDC MBIM Extended:
            bcdMBIMExtendedVersion           1.00
            bMaxOutstandingCommandMessages     64
            wMTU                             1500
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x82  EP 2 IN
            bmAttributes            3
              Transfer Type            Interrupt
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0040  1x 64 bytes
            bInterval               9
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber       13
          bAlternateSetting       0
          bNumEndpoints           0
          bInterfaceClass        10 CDC Data
          bInterfaceSubClass      0
          bInterfaceProtocol      2
          iInterface              0
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber       13
          bAlternateSetting       1
          bNumEndpoints           2
          bInterfaceClass        10 CDC Data
          bInterfaceSubClass      0
          bInterfaceProtocol      2
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x81  EP 1 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval               0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x01  EP 1 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval               0
    Device Qualifier (for other device speed):
      bLength                10
      bDescriptorType         6
      bcdUSB               2.00
      bDeviceClass            0
      bDeviceSubClass         0
      bDeviceProtocol         0
      bMaxPacketSize0        64
      bNumConfigurations      2
    Device Status:     0x0000
      (Bus Powered)
    
    Signed-off-by: Pieter Hollants <pieter@hollants.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 6d9d1472811336ad2002b2c686a4b78a9da8f8bd
Author: Reinhard Speyerer <rspmn@arcor.de>
Date:   Tue Jul 14 22:55:06 2015 +0200

    USB: qcserial/option: make AT URCs work for Sierra Wireless MC7305/MC7355
    
    [ Upstream commit 653cdc13a340ad1cef29f1bab0d05d0771fa1d57 ]
    
    Tests with a Sierra Wireless MC7355 have shown that 1199:9041 devices
    also require the option_send_setup() code to be used on the USB
    interface for the AT port to make unsolicited response codes work
    correctly. Move these devices from the qcserial driver to the option
    driver like it has been done for the 1199:68c0 devices in commit
    d80c0d14183516f184a5ac88e11008ee4c7d2a2e ("USB: qcserial/option: make
    AT URCs work for Sierra Wireless MC73xx").
    
    Signed-off-by: Reinhard Speyerer <rspmn@arcor.de>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 12c55ffc8168eec4773b927f761865e6f8f96f36
Author: Peter Chen <peter.chen@freescale.com>
Date:   Mon Jul 27 14:51:47 2015 +0800

    usb: gadget: f_uac2: fix calculation of uac2->p_interval
    
    [ Upstream commit c41b7767673cb76adeb2b5fde220209f717ea13c ]
    
    The p_interval should be less if the 'bInterval' at the descriptor
    is larger, eg, if 'bInterval' is 5 for HS, the p_interval should be
    8000 / 16 = 500.
    
    It fixes the patch 9bb87f168931 ("usb: gadget: f_uac2: send
    reasonably sized packets")
    
    Cc: <stable@vger.kernel.org> # v3.18+
    Fixes: 9bb87f168931 ("usb: gadget: f_uac2: send reasonably sized packets")
    Acked-by: Daniel Mack <zonque@gmail.com>
    Signed-off-by: Peter Chen <peter.chen@freescale.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit bf4ec167db2103b5b6a5d110856de9c5f54031a9
Author: NeilBrown <neilb@suse.com>
Date:   Mon Jul 27 11:48:52 2015 +1000

    md/raid1: extend spinlock to protect raid1_end_read_request against inconsistencies
    
    [ Upstream commit 423f04d63cf421ea436bcc5be02543d549ce4b28 ]
    
    raid1_end_read_request() assumes that the In_sync bits are consistent
    with the ->degaded count.
    raid1_spare_active updates the In_sync bit before the ->degraded count
    and so exposes an inconsistency, as does error()
    So extend the spinlock in raid1_spare_active() and error() to hide those
    inconsistencies.
    
    This should probably be part of
      Commit: 34cab6f42003 ("md/raid1: fix test for 'was read error from
      last working device'.")
    as it addresses the same issue.  It fixes the same bug and should go
    to -stable for same reasons.
    
    Fixes: 76073054c95b ("md/raid1: clean up read_balance.")
    Cc: stable@vger.kernel.org (v3.0+)
    Signed-off-by: NeilBrown <neilb@suse.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 4f7aa638b8604a58dc740eb00a67b166a6937ef5
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Tue Jul 14 18:27:46 2015 -0500

    PCI: Restore PCI_MSIX_FLAGS_BIRMASK definition
    
    [ Upstream commit c9ddbac9c89110f77cb0fa07e634aaf1194899aa ]
    
    09a2c73ddfc7 ("PCI: Remove unused PCI_MSIX_FLAGS_BIRMASK definition")
    removed PCI_MSIX_FLAGS_BIRMASK from an exported header because it was
    unused in the kernel.  But that breaks user programs that were using it
    (QEMU in particular).
    
    Restore the PCI_MSIX_FLAGS_BIRMASK definition.
    
    [bhelgaas: changelog]
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    CC: stable@vger.kernel.org	# v3.13+
    
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 5f940c59dc3a527ec581d62002c3ac7752659852
Author: Kinglong Mee <kinglongmee@gmail.com>
Date:   Tue Jul 7 10:16:37 2015 +0800

    nfsd: Drop BUG_ON and ignore SECLABEL on absent filesystem
    
    [ Upstream commit c7e6f05156402364f34669e0fa6fd69b834f994b ]
    
    commit c2227a39a078473115910512aa0f8d53bd915e60 upstream.
    
    On an absent filesystem (one served by another server), we need to be
    able to handle requests for certain attributest (like fs_locations, so
    the client can find out which server does have the filesystem), but
    others we can't.
    
    We forgot to take that into account when adding another attribute
    bitmask work for the SECURITY_LABEL attribute.
    
    There an export entry with the "refer" option can result in:
    
    [   88.414272] kernel BUG at fs/nfsd/nfs4xdr.c:2249!
    [   88.414828] invalid opcode: 0000 [#1] SMP
    [   88.415368] Modules linked in: rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache nfsd xfs libcrc32c iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi iosf_mbi ppdev btrfs coretemp crct10dif_pclmul crc32_pclmul crc32c_intel xor ghash_clmulni_intel raid6_pq vmw_balloon parport_pc parport i2c_piix4 shpchp vmw_vmci acpi_cpufreq auth_rpcgss nfs_acl lockd grace sunrpc vmwgfx drm_kms_helper ttm drm mptspi mptscsih serio_raw mptbase e1000 scsi_transport_spi ata_generic pata_acpi [last unloaded: nfsd]
    [   88.417827] CPU: 0 PID: 2116 Comm: nfsd Not tainted 4.0.7-300.fc22.x86_64 #1
    [   88.418448] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014
    [   88.419093] task: ffff880079146d50 ti: ffff8800785d8000 task.ti: ffff8800785d8000
    [   88.419729] RIP: 0010:[<ffffffffa04b3c10>]  [<ffffffffa04b3c10>] nfsd4_encode_fattr+0x820/0x1f00 [nfsd]
    [   88.420376] RSP: 0000:ffff8800785db998  EFLAGS: 00010206
    [   88.421027] RAX: 0000000000000001 RBX: 000000000018091a RCX: ffff88006668b980
    [   88.421676] RDX: 00000000fffef7fc RSI: 0000000000000000 RDI: ffff880078d05000
    [   88.422315] RBP: ffff8800785dbb58 R08: ffff880078d043f8 R09: ffff880078d4a000
    [   88.422968] R10: 0000000000010000 R11: 0000000000000002 R12: 0000000000b0a23a
    [   88.423612] R13: ffff880078d05000 R14: ffff880078683100 R15: ffff88006668b980
    [   88.424295] FS:  0000000000000000(0000) GS:ffff88007c600000(0000) knlGS:0000000000000000
    [   88.424944] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   88.425597] CR2: 00007f40bc370f90 CR3: 0000000035af5000 CR4: 00000000001407f0
    [   88.426285] Stack:
    [   88.426921]  ffff8800785dbaa8 ffffffffa049e4af ffff8800785dba08 ffffffff813298f0
    [   88.427585]  ffff880078683300 ffff8800769b0de8 0000089d00000001 0000000087f805e0
    [   88.428228]  ffff880000000000 ffff880079434a00 0000000000000000 ffff88006668b980
    [   88.428877] Call Trace:
    [   88.429527]  [<ffffffffa049e4af>] ? exp_get_by_name+0x7f/0xb0 [nfsd]
    [   88.430168]  [<ffffffff813298f0>] ? inode_doinit_with_dentry+0x210/0x6a0
    [   88.430807]  [<ffffffff8123833e>] ? d_lookup+0x2e/0x60
    [   88.431449]  [<ffffffff81236133>] ? dput+0x33/0x230
    [   88.432097]  [<ffffffff8123f214>] ? mntput+0x24/0x40
    [   88.432719]  [<ffffffff812272b2>] ? path_put+0x22/0x30
    [   88.433340]  [<ffffffffa049ac87>] ? nfsd_cross_mnt+0xb7/0x1c0 [nfsd]
    [   88.433954]  [<ffffffffa04b54e0>] nfsd4_encode_dirent+0x1b0/0x3d0 [nfsd]
    [   88.434601]  [<ffffffffa04b5330>] ? nfsd4_encode_getattr+0x40/0x40 [nfsd]
    [   88.435172]  [<ffffffffa049c991>] nfsd_readdir+0x1c1/0x2a0 [nfsd]
    [   88.435710]  [<ffffffffa049a530>] ? nfsd_direct_splice_actor+0x20/0x20 [nfsd]
    [   88.436447]  [<ffffffffa04abf30>] nfsd4_encode_readdir+0x120/0x220 [nfsd]
    [   88.437011]  [<ffffffffa04b58cd>] nfsd4_encode_operation+0x7d/0x190 [nfsd]
    [   88.437566]  [<ffffffffa04aa6dd>] nfsd4_proc_compound+0x24d/0x6f0 [nfsd]
    [   88.438157]  [<ffffffffa0496103>] nfsd_dispatch+0xc3/0x220 [nfsd]
    [   88.438680]  [<ffffffffa006f0cb>] svc_process_common+0x43b/0x690 [sunrpc]
    [   88.439192]  [<ffffffffa0070493>] svc_process+0x103/0x1b0 [sunrpc]
    [   88.439694]  [<ffffffffa0495a57>] nfsd+0x117/0x190 [nfsd]
    [   88.440194]  [<ffffffffa0495940>] ? nfsd_destroy+0x90/0x90 [nfsd]
    [   88.440697]  [<ffffffff810bb728>] kthread+0xd8/0xf0
    [   88.441260]  [<ffffffff810bb650>] ? kthread_worker_fn+0x180/0x180
    [   88.441762]  [<ffffffff81789e58>] ret_from_fork+0x58/0x90
    [   88.442322]  [<ffffffff810bb650>] ? kthread_worker_fn+0x180/0x180
    [   88.442879] Code: 0f 84 93 05 00 00 83 f8 ea c7 85 a0 fe ff ff 00 00 27 30 0f 84 ba fe ff ff 85 c0 0f 85 a5 fe ff ff e9 e3 f9 ff ff 0f 1f 44 00 00 <0f> 0b 66 0f 1f 44 00 00 be 04 00 00 00 4c 89 ef 4c 89 8d 68 fe
    [   88.444052] RIP  [<ffffffffa04b3c10>] nfsd4_encode_fattr+0x820/0x1f00 [nfsd]
    [   88.444658]  RSP <ffff8800785db998>
    [   88.445232] ---[ end trace 6cb9d0487d94a29f ]---
    
    Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 485c37fae5529a5743fd75f4238672aadef04b17
Author: Joseph Qi <joseph.qi@huawei.com>
Date:   Thu Aug 6 15:46:23 2015 -0700

    ocfs2: fix BUG in ocfs2_downconvert_thread_do_work()
    
    [ Upstream commit 209f7512d007980fd111a74a064d70a3656079cf ]
    
    The "BUG_ON(list_empty(&osb->blocked_lock_list))" in
    ocfs2_downconvert_thread_do_work can be triggered in the following case:
    
    ocfs2dc has firstly saved osb->blocked_lock_count to local varibale
    processed, and then processes the dentry lockres.  During the dentry
    put, it calls iput and then deletes rw, inode and open lockres from
    blocked list in ocfs2_mark_lockres_freeing.  And this causes the
    variable `processed' to not reflect the number of blocked lockres to be
    processed, which triggers the BUG.
    
    Signed-off-by: Joseph Qi <joseph.qi@huawei.com>
    Cc: Mark Fasheh <mfasheh@suse.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit b76ac7053d65b5b8bf2af6ef19c7f0ce6782cb7e
Author: Marcus Gelderie <redmnic@gmail.com>
Date:   Thu Aug 6 15:46:10 2015 -0700

    ipc: modify message queue accounting to not take kernel data structures into account
    
    [ Upstream commit de54b9ac253787c366bbfb28d901a31954eb3511 ]
    
    A while back, the message queue implementation in the kernel was
    improved to use btrees to speed up retrieval of messages, in commit
    d6629859b36d ("ipc/mqueue: improve performance of send/recv").
    
    That patch introducing the improved kernel handling of message queues
    (using btrees) has, as a by-product, changed the meaning of the QSIZE
    field in the pseudo-file created for the queue.  Before, this field
    reflected the size of the user-data in the queue.  Since, it also takes
    kernel data structures into account.  For example, if 13 bytes of user
    data are in the queue, on my machine the file reports a size of 61
    bytes.
    
    There was some discussion on this topic before (for example
    https://lkml.org/lkml/2014/10/1/115).  Commenting on a th lkml, Michael
    Kerrisk gave the following background
    (https://lkml.org/lkml/2015/6/16/74):
    
        The pseudofiles in the mqueue filesystem (usually mounted at
        /dev/mqueue) expose fields with metadata describing a message
        queue. One of these fields, QSIZE, as originally implemented,
        showed the total number of bytes of user data in all messages in
        the message queue, and this feature was documented from the
        beginning in the mq_overview(7) page. In 3.5, some other (useful)
        work happened to break the user-space API in a couple of places,
        including the value exposed via QSIZE, which now includes a measure
        of kernel overhead bytes for the queue, a figure that renders QSIZE
        useless for its original purpose, since there's no way to deduce
        the number of overhead bytes consumed by the implementation.
        (The other user-space breakage was subsequently fixed.)
    
    This patch removes the accounting of kernel data structures in the
    queue.  Reporting the size of these data-structures in the QSIZE field
    was a breaking change (see Michael's comment above).  Without the QSIZE
    field reporting the total size of user-data in the queue, there is no
    way to deduce this number.
    
    It should be noted that the resource limit RLIMIT_MSGQUEUE is counted
    against the worst-case size of the queue (in both the old and the new
    implementation).  Therefore, the kernel overhead accounting in QSIZE is
    not necessary to help the user understand the limitations RLIMIT imposes
    on the processes.
    
    Signed-off-by: Marcus Gelderie <redmnic@gmail.com>
    Acked-by: Doug Ledford <dledford@redhat.com>
    Acked-by: Michael Kerrisk <mtk.manpages@gmail.com>
    Acked-by: Davidlohr Bueso <dbueso@suse.de>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: John Duffy <jb_duffy@btinternet.com>
    Cc: Arto Bendiken <arto@bendiken.net>
    Cc: Manfred Spraul <manfred@colorfullife.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a7d57f42a86664881d7e60b33fdb579797c6f7f2
Author: Pali Rohár <pali.rohar@gmail.com>
Date:   Thu Jul 30 20:41:57 2015 +0200

    hwmon: (dell-smm) Blacklist Dell Studio XPS 8100
    
    [ Upstream commit 25ab1617bf735b8a411104c60852651cae6769fd ]
    
    commit a4b45b25f18d1e798965efec429ba5fc01b9f0b6 upstream.
    
    CPU fan speed going up and down on Dell Studio XPS 8100 for
    unknown reasons. Without further debugging on the affected
    machine, it is not possible to find the problem.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=100121
    Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
    Tested-by: Jan C Peters <jcpeters89@gmail.com>
    [groeck: cleaned up description, comments]
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 71b068a631f4734667a4a4a2b705106a74100d31
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Wed Aug 5 09:21:05 2015 +0900

    ALSA: fireworks/firewire-lib: add support for recent firmware quirk
    
    [ Upstream commit 18f5ed365d3f188a91149d528c853000330a4a58 ]
    
    Fireworks uses TSB43CB43(IceLynx-Micro) as its IEC 61883-1/6 interface.
    This chip includes ARM7 core, and loads and runs program. The firmware
    is stored in on-board memory and loaded every powering-on from it.
    
    Echo Audio ships several versions of firmwares for each model. These
    firmwares have each quirk and the quirk changes a sequence of packets.
    
    As long as I investigated, AudioFire2/AudioFire4/AudioFirePre8 have a
    quirk to transfer a first packet with 0x02 in its dbc field. This causes
    ALSA Fireworks driver to detect discontinuity. In this case, firmware
    version 5.7.0, 5.7.3 and 5.8.0 are used.
    
    Payload  CIP      CIP
    quadlets header1  header2
    02       00050002 90ffffff <-
    42       0005000a 90013000
    42       00050012 90014400
    42       0005001a 90015800
    02       0005001a 90ffffff
    42       00050022 90019000
    42       0005002a 9001a400
    42       00050032 9001b800
    02       00050032 90ffffff
    42       0005003a 9001d000
    42       00050042 9001e400
    42       0005004a 9001f800
    02       0005004a 90ffffff
    (AudioFire2 with firmware version 5.7.)
    
    $ dmesg
    snd-fireworks fw1.0: Detect discontinuity of CIP: 00 02
    
    These models, AudioFire8 (since Jul 2009 ) and Gibson Robot Interface
    Pack series uses the same ARM binary as their firmware. Thus, this
    quirk may be observed among them.
    
    This commit adds a new member for AMDTP structure. This member represents
    the value of dbc field in a first AMDTP packet. Drivers can set it with
    a preferred value according to model's quirk.
    
    Tested-by: Johannes Oertei <johannes.oertel@uni-due.de>
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 78d4241231ebd22b09df9133ec98ea0bc4795d4a
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sat Jul 25 03:03:38 2015 +0300

    ALSA: hda - fix cs4210_spdif_automute()
    
    [ Upstream commit 44008f0896ae205b02b0882dbf807f0de149efc4 ]
    
    Smatch complains that we have nested checks for "spdif_present".  It
    turns out the current behavior isn't correct, we should remove the first
    check and keep the second.
    
    Fixes: 1077a024812d ('ALSA: hda - Use generic parser for Cirrus codec driver')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a513c1125b097786fa123b65336938e89de37ab6
Author: Roger Quadros <rogerq@ti.com>
Date:   Thu Jul 16 16:16:44 2015 +0300

    ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc
    
    [ Upstream commit 9a258afa928b45e6dd2efcac46ccf7eea705d35a ]
    
    For hwmods without sysc, _init_mpu_rt_base(oh) won't be called and so
    _find_mpu_rt_port(oh) will return NULL thus preventing ready state check
    on those modules after the module is enabled.
    
    This can potentially cause a bus access error if the module is accessed
    before the module is ready.
    
    Fix this by unconditionally calling _init_mpu_rt_base() during hwmod
    _init(). Do ioremap only if we need SYSC access.
    
    Eventhough _wait_target_ready() check doesn't really need MPU RT port but
    just the PRCM registers, we still mandate that the hwmod must have an
    MPU RT port if ready state check needs to be done. Else it would mean that
    the module is not accessible by MPU so there is no point in waiting
    for target to be ready.
    
    e.g. this fixes the below DCAN bus access error on AM437x-gp-evm.
    
    [   16.672978] ------------[ cut here ]------------
    [   16.677885] WARNING: CPU: 0 PID: 1580 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x234/0x35c()
    [   16.687946] 44000000.ocp:L3 Custom Error: MASTER M2 (64-bit) TARGET L4_PER_0 (Read): Data Access in User mode during Functional access
    [   16.700654] Modules linked in: xhci_hcd btwilink ti_vpfe dwc3 videobuf2_core ov2659 bluetooth v4l2_common videodev ti_am335x_adc kfifo_buf industrialio c_can_platform videobuf2_dma_contig media snd_soc_tlv320aic3x pixcir_i2c_ts c_can dc
    [   16.731144] CPU: 0 PID: 1580 Comm: rpc.statd Not tainted 3.14.26-02561-gf733aa036398 #180
    [   16.739747] Backtrace:
    [   16.742336] [<c0011108>] (dump_backtrace) from [<c00112a4>] (show_stack+0x18/0x1c)
    [   16.750285]  r6:00000093 r5:00000009 r4:eab5b8a8 r3:00000000
    [   16.756252] [<c001128c>] (show_stack) from [<c05a4418>] (dump_stack+0x20/0x28)
    [   16.763870] [<c05a43f8>] (dump_stack) from [<c0037120>] (warn_slowpath_common+0x6c/0x8c)
    [   16.772408] [<c00370b4>] (warn_slowpath_common) from [<c00371e4>] (warn_slowpath_fmt+0x38/0x40)
    [   16.781550]  r8:c05d1f90 r7:c0730844 r6:c0730448 r5:80080003 r4:ed0cd210
    [   16.788626] [<c00371b0>] (warn_slowpath_fmt) from [<c027fa94>] (l3_interrupt_handler+0x234/0x35c)
    [   16.797968]  r3:ed0cd480 r2:c0730508
    [   16.801747] [<c027f860>] (l3_interrupt_handler) from [<c0063758>] (handle_irq_event_percpu+0x54/0x1bc)
    [   16.811533]  r10:ed005600 r9:c084855b r8:0000002a r7:00000000 r6:00000000 r5:0000002a
    [   16.819780]  r4:ed0e6d80
    [   16.822453] [<c0063704>] (handle_irq_event_percpu) from [<c00638f0>] (handle_irq_event+0x30/0x40)
    [   16.831789]  r10:eb2b6938 r9:eb2b6960 r8:bf011420 r7:fa240100 r6:00000000 r5:0000002a
    [   16.840052]  r4:ed005600
    [   16.842744] [<c00638c0>] (handle_irq_event) from [<c00661d8>] (handle_fasteoi_irq+0x74/0x128)
    [   16.851702]  r4:ed005600 r3:00000000
    [   16.855479] [<c0066164>] (handle_fasteoi_irq) from [<c0063068>] (generic_handle_irq+0x28/0x38)
    [   16.864523]  r4:0000002a r3:c0066164
    [   16.868294] [<c0063040>] (generic_handle_irq) from [<c000ef60>] (handle_IRQ+0x38/0x8c)
    [   16.876612]  r4:c081c640 r3:00000202
    [   16.880380] [<c000ef28>] (handle_IRQ) from [<c00084f0>] (gic_handle_irq+0x30/0x5c)
    [   16.888328]  r6:eab5ba38 r5:c0804460 r4:fa24010c r3:00000100
    [   16.894303] [<c00084c0>] (gic_handle_irq) from [<c05a8d80>] (__irq_svc+0x40/0x50)
    [   16.902193] Exception stack(0xeab5ba38 to 0xeab5ba80)
    [   16.907499] ba20:                                                       00000000 00000006
    [   16.916108] ba40: fa1d0000 fa1d0008 ed3d3000 eab5bab4 ed3d3460 c0842af4 bf011420 eb2b6960
    [   16.924716] ba60: eb2b6938 eab5ba8c eab5ba90 eab5ba80 bf035220 bf07702c 600f0013 ffffffff
    [   16.933317]  r7:eab5ba6c r6:ffffffff r5:600f0013 r4:bf07702c
    [   16.939317] [<bf077000>] (c_can_plat_read_reg_aligned_to_16bit [c_can_platform]) from [<bf035220>] (c_can_get_berr_counter+0x38/0x64 [c_can])
    [   16.952696] [<bf0351e8>] (c_can_get_berr_counter [c_can]) from [<bf010294>] (can_fill_info+0x124/0x15c [can_dev])
    [   16.963480]  r5:ec8c9740 r4:ed3d3000
    [   16.967253] [<bf010170>] (can_fill_info [can_dev]) from [<c0502fa8>] (rtnl_fill_ifinfo+0x58c/0x8fc)
    [   16.976749]  r6:ec8c9740 r5:ed3d3000 r4:eb2b6780
    [   16.981613] [<c0502a1c>] (rtnl_fill_ifinfo) from [<c0503408>] (rtnl_dump_ifinfo+0xf0/0x1dc)
    [   16.990401]  r10:ec8c9740 r9:00000000 r8:00000000 r7:00000000 r6:ebd4d1b4 r5:ed3d3000
    [   16.998671]  r4:00000000
    [   17.001342] [<c0503318>] (rtnl_dump_ifinfo) from [<c050e6e4>] (netlink_dump+0xa8/0x1e0)
    [   17.009772]  r10:00000000 r9:00000000 r8:c0503318 r7:ebf3e6c0 r6:ebd4d1b4 r5:ec8c9740
    [   17.018050]  r4:ebd4d000
    [   17.020714] [<c050e63c>] (netlink_dump) from [<c050ec10>] (__netlink_dump_start+0x104/0x154)
    [   17.029591]  r6:eab5bd34 r5:ec8c9980 r4:ebd4d000
    [   17.034454] [<c050eb0c>] (__netlink_dump_start) from [<c0505604>] (rtnetlink_rcv_msg+0x110/0x1f4)
    [   17.043778]  r7:00000000 r6:ec8c9980 r5:00000f40 r4:ebf3e6c0
    [   17.049743] [<c05054f4>] (rtnetlink_rcv_msg) from [<c05108e8>] (netlink_rcv_skb+0xb4/0xc8)
    [   17.058449]  r8:eab5bdac r7:ec8c9980 r6:c05054f4 r5:ec8c9980 r4:ebf3e6c0
    [   17.065534] [<c0510834>] (netlink_rcv_skb) from [<c0504134>] (rtnetlink_rcv+0x24/0x2c)
    [   17.073854]  r6:ebd4d000 r5:00000014 r4:ec8c9980 r3:c0504110
    [   17.079846] [<c0504110>] (rtnetlink_rcv) from [<c05102ac>] (netlink_unicast+0x180/0x1ec)
    [   17.088363]  r4:ed0c6800 r3:c0504110
    [   17.092113] [<c051012c>] (netlink_unicast) from [<c0510670>] (netlink_sendmsg+0x2ac/0x380)
    [   17.100813]  r10:00000000 r8:00000008 r7:ec8c9980 r6:ebd4d000 r5:eab5be70 r4:eab5bee4
    [   17.109083] [<c05103c4>] (netlink_sendmsg) from [<c04dfdb4>] (sock_sendmsg+0x90/0xb0)
    [   17.117305]  r10:00000000 r9:eab5a000 r8:becdda3c r7:0000000c r6:ea978400 r5:eab5be70
    [   17.125563]  r4:c05103c4
    [   17.128225] [<c04dfd24>] (sock_sendmsg) from [<c04e1c28>] (SyS_sendto+0xb8/0xdc)
    [   17.136001]  r6:becdda5c r5:00000014 r4:ecd37040
    [   17.140876] [<c04e1b70>] (SyS_sendto) from [<c000e680>] (ret_fast_syscall+0x0/0x30)
    [   17.148923]  r10:00000000 r8:c000e804 r7:00000122 r6:becdda5c r5:0000000c r4:becdda5c
    [   17.157169] ---[ end trace 2b71e15b38f58bad ]---
    
    Fixes: 6423d6df1440 ("ARM: OMAP2+: hwmod: check for module address space during init")
    Signed-off-by: Roger Quadros <rogerq@ti.com>
    Signed-off-by: Paul Walmsley <paul@pwsan.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit bcde729a9b3d09940941fa04c415cd7ac3b6f0b0
Author: Denis Carikli <denis@eukrea.com>
Date:   Thu Jul 23 10:31:12 2015 +0200

    ARM: dts: i.MX35: Fix can support.
    
    [ Upstream commit e053f96b1a00022b4e2c7ceb7ac0229646626507 ]
    
    Since commit 3d42a379b6fa5b46058e3302b1802b29f64865bb
    ("can: flexcan: add 2nd clock to support imx53 and newer")
    the can driver requires a dt nodes to have a second clock.
    Add them to imx35 to fix probing the flex can driver on the
    respective platforms.
    
    Signed-off-by: Denis Carikli <denis@eukrea.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ba00942e3b59a35676c0fbfea176830e413d4857
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Thu Jul 16 17:36:11 2015 +0300

    rbd: fix copyup completion race
    
    [ Upstream commit 2761713d35e370fd640b5781109f753066b746c4 ]
    
    For write/discard obj_requests that involved a copyup method call, the
    opcode of the first op is CEPH_OSD_OP_CALL and the ->callback is
    rbd_img_obj_copyup_callback().  The latter frees copyup pages, sets
    ->xferred and delegates to rbd_img_obj_callback(), the "normal" image
    object callback, for reporting to block layer and putting refs.
    
    rbd_osd_req_callback() however treats CEPH_OSD_OP_CALL as a trivial op,
    which means obj_request is marked done in rbd_osd_trivial_callback(),
    *before* ->callback is invoked and rbd_img_obj_copyup_callback() has
    a chance to run.  Marking obj_request done essentially means giving
    rbd_img_obj_callback() a license to end it at any moment, so if another
    obj_request from the same img_request is being completed concurrently,
    rbd_img_obj_end_request() may very well be called on such prematurally
    marked done request:
    
    <obj_request-1/2 reply>
    handle_reply()
      rbd_osd_req_callback()
        rbd_osd_trivial_callback()
        rbd_obj_request_complete()
        rbd_img_obj_copyup_callback()
        rbd_img_obj_callback()
                                        <obj_request-2/2 reply>
                                        handle_reply()
                                          rbd_osd_req_callback()
                                            rbd_osd_trivial_callback()
          for_each_obj_request(obj_request->img_request) {
            rbd_img_obj_end_request(obj_request-1/2)
            rbd_img_obj_end_request(obj_request-2/2) <--
          }
    
    Calling rbd_img_obj_end_request() on such a request leads to trouble,
    in particular because its ->xfferred is 0.  We report 0 to the block
    layer with blk_update_request(), get back 1 for "this request has more
    data in flight" and then trip on
    
        rbd_assert(more ^ (which == img_request->obj_request_count));
    
    with rhs (which == ...) being 1 because rbd_img_obj_end_request() has
    been called for both requests and lhs (more) being 1 because we haven't
    got a chance to set ->xfferred in rbd_img_obj_copyup_callback() yet.
    
    To fix this, leverage that rbd wants to call class methods in only two
    cases: one is a generic method call wrapper (obj_request is standalone)
    and the other is a copyup (obj_request is part of an img_request).  So
    make a dedicated handler for CEPH_OSD_OP_CALL and directly invoke
    rbd_img_obj_copyup_callback() from it if obj_request is part of an
    img_request, similar to how CEPH_OSD_OP_READ handler invokes
    rbd_img_obj_request_read_callback().
    
    Since rbd_img_obj_copyup_callback() is now being called from the OSD
    request callback (only), it is renamed to rbd_osd_copyup_callback().
    
    Cc: Alex Elder <elder@linaro.org>
    Cc: stable@vger.kernel.org # 3.10+, needs backporting for < 3.18
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Alex Elder <elder@linaro.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 99b4bdfd4279f65c03f291e1f89abe56f33d69b5
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Wed Jul 22 18:05:35 2015 +0800

    crypto: ixp4xx - Remove bogus BUG_ON on scattered dst buffer
    
    [ Upstream commit f898c522f0e9ac9f3177d0762b76e2ab2d2cf9c0 ]
    
    This patch removes a bogus BUG_ON in the ablkcipher path that
    triggers when the destination buffer is different from the source
    buffer and is scattered.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ca7040c618016748c8a3b6510a6e08ad0073f3c6
Author: Tadeusz Struk <tadeusz.struk@intel.com>
Date:   Tue Jul 21 22:07:47 2015 -0700

    crypto: qat - Fix invalid synchronization between register/unregister sym algs
    
    [ Upstream commit 7047312d383203f7b8447261f1a473cf54aedec3 ]
    
    commit 6f043b50da8e03bdcc5703fd37ea45bc6892432f upstream.
    
    The synchronization method used atomic was bogus.
    Use a proper synchronization with mutex.
    
    Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 25920396cd64d55eec36eb64502ea582e191f390
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Fri Jul 24 13:13:30 2015 +0200

    hwrng: core - correct error check of kthread_run call
    
    [ Upstream commit 17fb874dee093139923af8ed36061faa92cc8e79 ]
    
    The kthread_run() function can return two different error values
    but the hwrng core only checks for -ENOMEM. If the other error
    value -EINTR is returned it is assigned to hwrng_fill and later
    used on a kthread_stop() call which naturally crashes.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 728757eda0dcdfac1f8d46548849cbf2597fe5da
Author: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Date:   Fri Jun 26 03:28:24 2015 +0200

    xen/gntdevt: Fix race condition in gntdev_release()
    
    [ Upstream commit 30b03d05e07467b8c6ec683ea96b5bffcbcd3931 ]
    
    While gntdev_release() is called the MMU notifier is still registered
    and can traverse priv->maps list even if no pages are mapped (which is
    the case -- gntdev_release() is called after all). But
    gntdev_release() will clear that list, so make sure that only one of
    those things happens at the same time.
    
    Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 6b4cd0635d2cd27836ab5f534990073e0ee1a2dd
Author: David Vrabel <david.vrabel@citrix.com>
Date:   Fri Jan 9 18:06:12 2015 +0000

    xen/gntdev: convert priv->lock to a mutex
    
    [ Upstream commit 1401c00e59ea021c575f74612fe2dbba36d6a4ee ]
    
    Unmapping may require sleeping and we unmap while holding priv->lock, so
    convert it to a mutex.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit d172dd24925d7c7315c151f62de4df7d97cade00
Author: Andy Lutomirski <luto@kernel.org>
Date:   Thu Jul 30 14:31:31 2015 -0700

    x86/xen: Probe target addresses in set_aliased_prot() before the hypercall
    
    [ Upstream commit aa1acff356bbedfd03b544051f5b371746735d89 ]
    
    The update_va_mapping hypercall can fail if the VA isn't present
    in the guest's page tables.  Under certain loads, this can
    result in an OOPS when the target address is in unpopulated vmap
    space.
    
    While we're at it, add comments to help explain what's going on.
    
    This isn't a great long-term fix.  This code should probably be
    changed to use something like set_memory_ro.
    
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Cc: Andrew Cooper <andrew.cooper3@citrix.com>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: David Vrabel <dvrabel@cantab.net>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Jan Beulich <jbeulich@suse.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Sasha Levin <sasha.levin@oracle.com>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: security@kernel.org <security@kernel.org>
    Cc: <stable@vger.kernel.org>
    Cc: xen-devel <xen-devel@lists.xen.org>
    Link: http://lkml.kernel.org/r/0b0e55b995cda11e7829f140b833ef932fcabe3a.1438291540.git.luto@kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 30f6445aa3a1e1403f446e2b93222d63774ff788
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Mon Jul 6 17:01:24 2015 +0200

    ASoC: dapm: Lock during userspace access
    
    [ Upstream commit d90d06680f8287f11a5ad6d83680790e5da86f08 ]
    
    commit e50b1e06b79e9d51efbff9627b4dd407184ef43f upstream.
    
    The DAPM lock must be held when accessing the DAPM graph status through
    sysfs or debugfs, otherwise concurrent changes to the graph can result in
    undefined behaviour.
    
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ddc4232eec5c9976052f7c723b4c07a03f50a870
Author: Axel Lin <axel.lin@ingics.com>
Date:   Thu Jul 23 23:22:26 2015 +0800

    ASoC: pcm1681: Fix setting de-emphasis sampling rate selection
    
    [ Upstream commit fa8173a3ef0570affde7da352de202190b3786c2 ]
    
    The de-emphasis sampling rate selection is controlled by BIT[3:4] of
    PCM1681_DEEMPH_CONTROL register. Do proper left shift to set it.
    
    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Acked-by: Marek Belisko <marek.belisko@streamunlimited.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 582ce3de1705e5f91abde79431ae3cb9ddc7985d
Author: Murali Karicheri <m-karicheri2@ti.com>
Date:   Fri May 29 12:04:13 2015 -0400

    ARM: dts: keystone: fix dt bindings to use post div register for mainpll
    
    [ Upstream commit c1bfa985ded82cacdfc6403e78f329c44e35534a ]
    
    All of the keystone devices have a separate register to hold post
    divider value for main pll clock. Currently the fixed-postdiv
    value used for k2hk/l/e SoCs works by sheer luck as u-boot happens to
    use a value of 2 for this. Now that we have fixed this in the pll
    clock driver change the dt bindings for the same.
    
    Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
    Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
    Signed-off-by: Olof Johansson <olof@lixom.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 5a646e642a4e06163f268cdcd479680bb76fe661
Author: Murali Karicheri <m-karicheri2@ti.com>
Date:   Fri May 29 12:04:12 2015 -0400

    clk: keystone: add support for post divider register for main pll
    
    [ Upstream commit 02fdfd708fd252a778709beb6c65d5e7360341ac ]
    
    Main PLL controller has post divider bits in a separate register in
    pll controller. Use the value from this register instead of fixed
    divider when available.
    
    Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
    Signed-off-by: Michael Turquette <mturquette@baylibre.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 370f050fc757716e9b334d705f67a71396701f71
Author: David S. Miller <davem@davemloft.net>
Date:   Thu Aug 6 19:13:25 2015 -0700

    sparc64: Fix userspace FPU register corruptions.
    
    [ Upstream commit 44922150d87cef616fd183220d43d8fde4d41390 ]
    
    If we have a series of events from userpsace, with %fprs=FPRS_FEF,
    like follows:
    
    ETRAP
    	ETRAP
    		VIS_ENTRY(fprs=0x4)
    		VIS_EXIT
    		RTRAP (kernel FPU restore with fpu_saved=0x4)
    	RTRAP
    
    We will not restore the user registers that were clobbered by the FPU
    using kernel code in the inner-most trap.
    
    Traps allocate FPU save slots in the thread struct, and FPU using
    sequences save the "dirty" FPU registers only.
    
    This works at the initial trap level because all of the registers
    get recorded into the top-level FPU save area, and we'll return
    to userspace with the FPU disabled so that any FPU use by the user
    will take an FPU disabled trap wherein we'll load the registers
    back up properly.
    
    But this is not how trap returns from kernel to kernel operate.
    
    The simplest fix for this bug is to always save all FPU register state
    for anything other than the top-most FPU save area.
    
    Getting rid of the optimized inner-slot FPU saving code ends up
    making VISEntryHalf degenerate into plain VISEntry.
    
    Longer term we need to do something smarter to reinstate the partial
    save optimizations.  Perhaps the fundament error is having trap entry
    and exit allocate FPU save slots and restore register state.  Instead,
    the VISEntry et al. calls should be doing that work.
    
    This bug is about two decades old.
    
    Reported-by: James Y Knight <jyknight@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e46e18eb387767fa26356417210ef41d0855ef1e
Author: Benjamin Randazzo <benjamin@randazzo.fr>
Date:   Sat Jul 25 16:36:50 2015 +0200

    md: use kzalloc() when bitmap is disabled
    
    [ Upstream commit 33afeac21b9cb79ad8fc5caf239af89c79e25e1e ]
    
    commit b6878d9e03043695dbf3fa1caa6dfc09db225b16 upstream.
    
    In drivers/md/md.c get_bitmap_file() uses kmalloc() for creating a
    mdu_bitmap_file_t called "file".
    
    5769         file = kmalloc(sizeof(*file), GFP_NOIO);
    5770         if (!file)
    5771                 return -ENOMEM;
    
    This structure is copied to user space at the end of the function.
    
    5786         if (err == 0 &&
    5787             copy_to_user(arg, file, sizeof(*file)))
    5788                 err = -EFAULT
    
    But if bitmap is disabled only the first byte of "file" is initialized
    with zero, so it's possible to read some bytes (up to 4095) of kernel
    space memory from user space. This is an information leak.
    
    5775         /* bitmap disabled, zero the first byte and copy out */
    5776         if (!mddev->bitmap_info.file)
    5777                 file->pathname[0] = '\0';
    
    Signed-off-by: Benjamin Randazzo <benjamin@randazzo.fr>
    Signed-off-by: NeilBrown <neilb@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 35242ba632639463b9b9c82780e2e91bdd1e3231
Author: NeilBrown <neilb@suse.de>
Date:   Thu Apr 16 18:03:04 2015 +1000

    phy: twl4030-usb: make runtime pm more reliable.
    
    [ Upstream commit 56301df6bcaaed31e77b8c500ca1b437f46a3158 ]
    
    A construct like:
    
            if (pm_runtime_suspended(twl->dev))
                   pm_runtime_get_sync(twl->dev);
    
    is against the spirit of the runtime_pm interface as it
    makes the internal refcounting useless.
    
    In this case it is also racy, particularly as 'put_autosuspend'
    is used to drop a reference.
    When that happens a timer is started and the device is
    runtime-suspended after the timeout.
    If the above code runs in this window, the device will not be
    found to be suspended so no pm_runtime reference is taken.
    When the timer expires the device will be suspended, which is
    against the intention of the code.
    
    So be more direct is taking and dropping references.
    If twl->linkstat is VBUS_VALID or ID_GROUND, then hold a
    pm_runtime reference, otherwise don't.
    Define "cable_present()" to test for this condition.
    
    Tested-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 7c70eda72eace5af36fecf69be6f9f5ea376ea2f
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Jan 16 11:32:51 2015 -0500

    usb: udc: core: add device_del() call to error pathway
    
    [ Upstream commit c93e64e91248becd0edb8f01723dff9da890e2ab ]
    
    This patch fixes a bug in the error pathway of
    usb_add_gadget_udc_release() in udc-core.c.  If the udc registration
    fails, the gadget registration is not fully undone; there's a
    put_device(&gadget->dev) call but no device_del().
    
    CC: <stable@vger.kernel.org>
    Acked-by: Peter Chen <peter.chen@freescale.com>
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 6f3dd9c23a8d5b0fe17bfd8e66b42a0adef1d2d0
Author: Dirk Behme <dirk.behme@de.bosch.com>
Date:   Mon Jul 27 08:56:05 2015 +0200

    USB: sierra: add 1199:68AB device ID
    
    [ Upstream commit 74472233233f577eaa0ca6d6e17d9017b6e53150 ]
    
    Add support for the Sierra Wireless AR8550 device with
    USB descriptor 0x1199, 0x68AB.
    
    It is common with MC879x modules 1199:683c/683d which
    also are composite devices with 7 interfaces (0..6)
    and also MDM62xx based as the AR8550.
    
    The major difference are only the interface attributes
    02/02/01 on interfaces 3 and 4 on the AR8550. They are
    vendor specific ff/ff/ff on MC879x modules.
    
    lsusb reports:
    
    Bus 001 Device 004: ID 1199:68ab Sierra Wireless, Inc.
    Device Descriptor:
      bLength                18
      bDescriptorType         1
      bcdUSB               2.00
      bDeviceClass            0 (Defined at Interface level)
      bDeviceSubClass         0
      bDeviceProtocol         0
      bMaxPacketSize0        64
      idVendor           0x1199 Sierra Wireless, Inc.
      idProduct          0x68ab
      bcdDevice            0.06
      iManufacturer           3 Sierra Wireless, Incorporated
      iProduct                2 AR8550
      iSerial                 0
      bNumConfigurations      1
      Configuration Descriptor:
        bLength                 9
        bDescriptorType         2
        wTotalLength          198
        bNumInterfaces          7
        bConfigurationValue     1
        iConfiguration          1 Sierra Configuration
        bmAttributes         0xe0
          Self Powered
          Remote Wakeup
        MaxPower                0mA
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        0
          bAlternateSetting       0
          bNumEndpoints           2
          bInterfaceClass       255 Vendor Specific Class
          bInterfaceSubClass    255 Vendor Specific Subclass
          bInterfaceProtocol    255 Vendor Specific Protocol
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x81  EP 1 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x01  EP 1 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        1
          bAlternateSetting       0
          bNumEndpoints           2
          bInterfaceClass       255 Vendor Specific Class
          bInterfaceSubClass    255 Vendor Specific Subclass
          bInterfaceProtocol    255 Vendor Specific Protocol
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x82  EP 2 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x02  EP 2 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        2
          bAlternateSetting       0
          bNumEndpoints           2
          bInterfaceClass       255 Vendor Specific Class
          bInterfaceSubClass    255 Vendor Specific Subclass
          bInterfaceProtocol    255 Vendor Specific Protocol
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x83  EP 3 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x03  EP 3 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        3
          bAlternateSetting       0
          bNumEndpoints           3
          bInterfaceClass         2 Communications
          bInterfaceSubClass      2 Abstract (modem)
          bInterfaceProtocol      1 AT-commands (v.25ter)
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x84  EP 4 IN
            bmAttributes            3
              Transfer Type            Interrupt
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0040  1x 64 bytes
            bInterval               5
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x85  EP 5 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x04  EP 4 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        4
          bAlternateSetting       0
          bNumEndpoints           3
          bInterfaceClass         2 Communications
          bInterfaceSubClass      2 Abstract (modem)
          bInterfaceProtocol      1 AT-commands (v.25ter)
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x86  EP 6 IN
            bmAttributes            3
              Transfer Type            Interrupt
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0040  1x 64 bytes
            bInterval               5
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x87  EP 7 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x05  EP 5 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        5
          bAlternateSetting       0
          bNumEndpoints           3
          bInterfaceClass       255 Vendor Specific Class
          bInterfaceSubClass    255 Vendor Specific Subclass
          bInterfaceProtocol    255 Vendor Specific Protocol
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x88  EP 8 IN
            bmAttributes            3
              Transfer Type            Interrupt
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0040  1x 64 bytes
            bInterval               5
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x89  EP 9 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x06  EP 6 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        6
          bAlternateSetting       0
          bNumEndpoints           3
          bInterfaceClass       255 Vendor Specific Class
          bInterfaceSubClass    255 Vendor Specific Subclass
          bInterfaceProtocol    255 Vendor Specific Protocol
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x8a  EP 10 IN
            bmAttributes            3
              Transfer Type            Interrupt
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0040  1x 64 bytes
            bInterval               5
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x8b  EP 11 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x07  EP 7 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
    Device Qualifier (for other device speed):
      bLength                10
      bDescriptorType         6
      bcdUSB               2.00
      bDeviceClass            0 (Defined at Interface level)
      bDeviceSubClass         0
      bDeviceProtocol         0
      bMaxPacketSize0        64
      bNumConfigurations      1
    Device Status:     0x0001
      Self Powered
    
    Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
    Cc: Lars Melin <larsm17@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit aab8865bcedc91f55a1ef6c2c80513ac2e97cc82
Author: Gavin Shan <gwshan@linux.vnet.ibm.com>
Date:   Mon Aug 3 16:07:49 2015 +0300

    drivers/usb: Delete XHCI command timer if necessary
    
    [ Upstream commit ffe5adcb7661d94e952d6b5ed7f493cb4ef0c7bc ]
    
    When xhci_mem_cleanup() is called, it's possible that the command
    timer isn't initialized and scheduled. For those cases, to delete
    the command timer causes soft-lockup as below stack dump shows.
    
    The patch avoids deleting the command timer if it's not scheduled
    with the help of timer_pending().
    
    NMI watchdog: BUG: soft lockup - CPU#40 stuck for 23s! [kworker/40:1:8140]
          :
    NIP [c000000000150b30] lock_timer_base.isra.34+0x90/0xa0
    LR [c000000000150c24] try_to_del_timer_sync+0x34/0xa0
    Call Trace:
    [c000000f67c975e0] [c0000000015b84f8] mon_ops+0x0/0x8 (unreliable)
    [c000000f67c97620] [c000000000150c24] try_to_del_timer_sync+0x34/0xa0
    [c000000f67c97660] [c000000000150cf0] del_timer_sync+0x60/0x80
    [c000000f67c97690] [c00000000070ac0c] xhci_mem_cleanup+0x5c/0x5e0
    [c000000f67c97740] [c00000000070c2e8] xhci_mem_init+0x1158/0x13b0
    [c000000f67c97860] [c000000000700978] xhci_init+0x88/0x110
    [c000000f67c978e0] [c000000000701644] xhci_gen_setup+0x2b4/0x590
    [c000000f67c97970] [c0000000006d4410] xhci_pci_setup+0x40/0x190
    [c000000f67c979f0] [c0000000006b1af8] usb_add_hcd+0x418/0xba0
    [c000000f67c97ab0] [c0000000006cb15c] usb_hcd_pci_probe+0x1dc/0x5c0
    [c000000f67c97b50] [c0000000006d3ba4] xhci_pci_probe+0x64/0x1f0
    [c000000f67c97ba0] [c0000000004fe9ac] local_pci_probe+0x6c/0x130
    [c000000f67c97c30] [c0000000000e5ce8] work_for_cpu_fn+0x38/0x60
    [c000000f67c97c60] [c0000000000eacb8] process_one_work+0x198/0x470
    [c000000f67c97cf0] [c0000000000eb6ac] worker_thread+0x37c/0x5a0
    [c000000f67c97d80] [c0000000000f2730] kthread+0x110/0x130
    [c000000f67c97e30] [c000000000009660] ret_from_kernel_thread+0x5c/0x7c
    
    Cc: <stable@vger.kernel.org>
    Reported-by: Priya M. A <priyama2@in.ibm.com>
    Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 38096a07aa1f4851146edcac94efc88553e3bb70
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Aug 3 16:07:48 2015 +0300

    xhci: fix off by one error in TRB DMA address boundary check
    
    [ Upstream commit 7895086afde2a05fa24a0e410d8e6b75ca7c8fdd ]
    
    We need to check that a TRB is part of the current segment
    before calculating its DMA address.
    
    Previously a ring segment didn't use a full memory page, and every
    new ring segment got a new memory page, so the off by one
    error in checking the upper bound was never seen.
    
    Now that we use a full memory page, 256 TRBs (4096 bytes), the off by one
    didn't catch the case when a TRB was the first element of the next segment.
    
    This is triggered if the virtual memory pages for a ring segment are
    next to each in increasing order where the ring buffer wraps around and
    causes errors like:
    
    [  106.398223] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 0 comp_code 1
    [  106.398230] xhci_hcd 0000:00:14.0: Looking for event-dma fffd3000 trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 seg-end fffd4ff0
    
    The trb-end address is one outside the end-seg address.
    
    Cc: <stable@vger.kernel.org>
    Tested-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit d37dfe249a92e5848f5d29b2c567c2884752eef2
Author: Brian King <brking@linux.vnet.ibm.com>
Date:   Tue Jul 14 11:41:33 2015 -0500

    ipr: Fix invalid array indexing for HRRQ
    
    [ Upstream commit 3f1c0581310d5d94bd72740231507e763a6252a4 ]
    
    Fixes another signed / unsigned array indexing bug in the ipr driver.
    Currently, when hrrq_index wraps, it becomes a negative number. We
    do the modulo, but still have a negative number, so we end up indexing
    backwards in the array. Given where the hrrq array is located in memory,
    we probably won't actually reference memory we don't own, but nonetheless
    ipr is still looking at data within struct ipr_ioa_cfg and interpreting it as
    struct ipr_hrr_queue data, so bad things could certainly happen.
    
    Each ipr adapter has anywhere from 1 to 16 HRRQs. By default, we use 2 on new
    adapters.  Let's take an example:
    
    Assume ioa_cfg->hrrq_index=0x7fffffffe and ioa_cfg->hrrq_num=4:
    
    The atomic_add_return will then return -1. We mod this with 3 and get -2, add
    one and get -1 for an array index.
    
    On adapters which support more than a single HRRQ, we dedicate HRRQ to adapter
    initialization and error interrupts so that we can optimize the other queues
    for fast path I/O. So all normal I/O uses HRRQ 1-15. So we want to spread the
    I/O requests across those HRRQs.
    
    With the default module parameter settings, this bug won't hit, only when
    someone sets the ipr.number_of_msix parameter to a value larger than 3 is when
    bad things start to happen.
    
    Cc: <stable@vger.kernel.org>
    Tested-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
    Reviewed-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
    Reviewed-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
    Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: James Bottomley <JBottomley@Odin.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e383a58df7d4625f3e2bbe4a7c6a7aff156f2a19
Author: Brian King <brking@linux.vnet.ibm.com>
Date:   Tue Jul 14 11:41:31 2015 -0500

    ipr: Fix incorrect trace indexing
    
    [ Upstream commit bb7c54339e6a10ecce5c4961adf5e75b3cf0af30 ]
    
    When ipr's internal driver trace was changed to an atomic, a signed/unsigned
    bug slipped in which results in us indexing backwards in our memory buffer
    writing on memory that does not belong to us. This patch fixes this by removing
    the modulo and instead just mask off the low bits.
    
    Cc: <stable@vger.kernel.org>
    Tested-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
    Reviewed-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
    Reviewed-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
    Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: James Bottomley <JBottomley@Odin.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e58bb36e35bba8f4ea1185f04ff35cc0c25c0761
Author: Brian King <brking@linux.vnet.ibm.com>
Date:   Tue Jul 14 11:41:29 2015 -0500

    ipr: Fix locking for unit attention handling
    
    [ Upstream commit 36b8e180e1e929e00b351c3b72aab3147fc14116 ]
    
    Make sure we have the host lock held when calling scsi_report_bus_reset. Fixes
    a crash seen as the __devices list in the scsi host was changing as we were
    iterating through it.
    
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
    Reviewed-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
    Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: James Bottomley <JBottomley@Odin.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 3fa2a2f918ccd66db81a774776dca3ebb7fcfc61
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Aug 3 17:24:10 2015 +0200

    drm/dp-mst: Remove debug WARN_ON
    
    [ Upstream commit 42639ba554655c280ae6cb72df0522b1201f2961 ]
    
    Apparently been in there since forever and fairly easy to hit when
    hotplugging really fast. I can do that since my mst hub has a manual
    button to flick the hpd line for reprobing. The resulting WARNING spam
    isn't pretty.
    
    Cc: Dave Airlie <airlied@gmail.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Thierry Reding <treding@nvidia.com>
    Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 82fbf139b01c499a7d175d8a152c36d616d29630
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Jul 27 19:24:31 2015 -0400

    drm/radeon/combios: add some validation of lvds values
    
    [ Upstream commit 0a90a0cff9f429f886f423967ae053150dce9259 ]
    
    Fixes a broken hsync start value uncovered by:
    abc0b1447d4974963548777a5ba4a4457c82c426
    (drm: Perform basic sanity checks on probed modes)
    
    The driver handled the bad hsync start elsewhere, but
    the above commit prevented it from getting added.
    
    bug:
    https://bugs.freedesktop.org/show_bug.cgi?id=91401
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 89cc013797bc47c50ebf5b4a89ead3d19b1ac2e3
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Jul 15 09:50:42 2015 +0100

    drm/i915: Replace WARN inside I915_READ64_2x32 with retry loop
    
    [ Upstream commit ee0a227b7ac6e75f28e10269f81c7ec6eb600952 ]
    
    Since we may conceivably encounter situations where the upper part of the
    64bit register changes between reads, for example when a timestamp
    counter overflows, change the WARN into a retry loop.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Michał Winiarski <michal.winiarski@intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 81f2af92d90824ba6a37157118d5bf997fc5f4d9
Author: Jan Kara <jack@suse.com>
Date:   Thu Aug 6 15:46:42 2015 -0700

    fsnotify: fix oops in fsnotify_clear_marks_by_group_flags()
    
    [ Upstream commit 8f2f3eb59dff4ec538de55f2e0592fec85966aab ]
    
    fsnotify_clear_marks_by_group_flags() can race with
    fsnotify_destroy_marks() so that when fsnotify_destroy_mark_locked()
    drops mark_mutex, a mark from the list iterated by
    fsnotify_clear_marks_by_group_flags() can be freed and thus the next
    entry pointer we have cached may become stale and we dereference free
    memory.
    
    Fix the problem by first moving marks to free to a special private list
    and then always free the first entry in the special list.  This method
    is safe even when entries from the list can disappear once we drop the
    lock.
    
    Signed-off-by: Jan Kara <jack@suse.com>
    Reported-by: Ashish Sangwan <a.sangwan@samsung.com>
    Reviewed-by: Ashish Sangwan <a.sangwan@samsung.com>
    Cc: Lino Sanfilippo <LinoSanfilippo@gmx.de>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 204041c4a640f004a5df152434f05b96ee76dfab
Author: David Daney <david.daney@cavium.com>
Date:   Mon Aug 3 17:48:43 2015 -0700

    MIPS: Make set_pte() SMP safe.
    
    [ Upstream commit 46011e6ea39235e4aca656673c500eac81a07a17 ]
    
    On MIPS the GLOBAL bit of the PTE must have the same value in any
    aligned pair of PTEs.  These pairs of PTEs are referred to as
    "buddies".  In a SMP system is is possible for two CPUs to be calling
    set_pte() on adjacent PTEs at the same time.  There is a race between
    setting the PTE and a different CPU setting the GLOBAL bit in its
    buddy PTE.
    
    This race can be observed when multiple CPUs are executing
    vmap()/vfree() at the same time.
    
    Make setting the buddy PTE's GLOBAL bit an atomic operation to close
    the race condition.
    
    The case of CONFIG_64BIT_PHYS_ADDR && CONFIG_CPU_MIPS32 is *not*
    handled.
    
    Signed-off-by: David Daney <david.daney@cavium.com>
    Cc: <stable@vger.kernel.org>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/10835/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e1c3e51cf7e1de53b9279ac6a02ceb8630dd15f2
Author: James Hogan <james.hogan@imgtec.com>
Date:   Fri Jul 31 16:29:38 2015 +0100

    MIPS: Flush RPS on kernel entry with EVA
    
    [ Upstream commit 3aff47c062b944a5e1f9af56a37a23f5295628fc ]
    
    When EVA is enabled, flush the Return Prediction Stack (RPS) present on
    some MIPS cores on entry to the kernel from user mode.
    
    This is important specifically for interAptiv with EVA enabled,
    otherwise kernel mode RPS mispredicts may trigger speculative fetches of
    user return addresses, which may be sensitive in the kernel address
    space due to EVA's overlapping user/kernel address spaces.
    
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Markos Chandras <markos.chandras@imgtec.com>
    Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Cc: <stable@vger.kernel.org> # 3.15.x-
    Patchwork: https://patchwork.linux-mips.org/patch/10812/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 101f163197025dfe02aa8c5235baa041d0c00a75
Author: James Hogan <james.hogan@imgtec.com>
Date:   Mon Jul 27 13:50:22 2015 +0100

    MIPS: show_stack: Fix stack trace with EVA
    
    [ Upstream commit 1e77863a51698c4319587df34171bd823691a66a ]
    
    The show_stack() function deals exclusively with kernel contexts, but if
    it gets called in user context with EVA enabled, show_stacktrace() will
    attempt to access the stack using EVA accesses, which will either read
    other user mapped data, or more likely cause an exception which will be
    handled by __get_user().
    
    This is easily reproduced using SysRq t to show all task states, which
    results in the following stack dump output:
    
     Stack : (Bad stack address)
    
    Fix by setting the current user access mode to kernel around the call to
    show_stacktrace(). This causes __get_user() to use normal loads to read
    the kernel stack.
    
    Now we get the correct output, like this:
    
     Stack : 00000000 80168960 00000000 004a0000 00000000 00000000 8060016c 1f3abd0c
               1f172cd8 8056f09c 7ff1e450 8014fc3c 00000001 806dd0b0 0000001d 00000002
               1f17c6a0 1f17c804 1f17c6a0 8066f6e0 00000000 0000000a 00000000 00000000
               00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
               00000000 00000000 00000000 00000000 00000000 0110e800 1f3abd6c 1f17c6a0
               ...
    
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Markos Chandras <markos.chandras@imgtec.com>
    Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Cc: <stable@vger.kernel.org> # 3.15+
    Patchwork: https://patchwork.linux-mips.org/patch/10778/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit e5e8829b1a84bddf48b56c11f22ee8af218da48a
Author: James Hogan <james.hogan@imgtec.com>
Date:   Mon Jul 27 13:50:21 2015 +0100

    MIPS: do_mcheck: Fix kernel code dump with EVA
    
    [ Upstream commit 55c723e181ccec30fb5c672397fe69ec35967d97 ]
    
    If a machine check exception is raised in kernel mode, user context,
    with EVA enabled, then the do_mcheck handler will attempt to read the
    code around the EPC using EVA load instructions, i.e. as if the reads
    were from user mode. This will either read random user data if the
    process has anything mapped at the same address, or it will cause an
    exception which is handled by __get_user, resulting in this output:
    
     Code: (Bad address in epc)
    
    Fix by setting the current user access mode to kernel if the saved
    register context indicates the exception was taken in kernel mode. This
    causes __get_user to use normal loads to read the kernel code.
    
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Markos Chandras <markos.chandras@imgtec.com>
    Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Cc: <stable@vger.kernel.org> # 3.15+
    Patchwork: https://patchwork.linux-mips.org/patch/10777/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit be98cdc06716c01197d843801e9b3a6da1347ba8
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sun Jul 19 00:38:41 2015 +0200

    MIPS: Fix sched_getaffinity with MT FPAFF enabled
    
    [ Upstream commit 1d62d737555e1378eb62a8bba26644f7d97139d2 ]
    
    p->thread.user_cpus_allowed is zero-initialized and is only filled on
    the first sched_setaffinity call.
    
    To avoid adding overhead in the task initialization codepath, simply OR
    the returned mask in sched_getaffinity with p->cpus_allowed.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/10740/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit edf9af7863f2ae49310836de15669704ce1bf876
Author: James Hogan <james.hogan@imgtec.com>
Date:   Fri Jul 17 15:54:41 2015 +0100

    MIPS: Malta: Don't reinitialise RTC
    
    [ Upstream commit 106eccb4d20f35ebc58ff2286c170d9e79c5ff68 ]
    
    On Malta, since commit a87ea88d8f6c ("MIPS: Malta: initialise the RTC at
    boot"), the RTC is reinitialised and forced into binary coded decimal
    (BCD) mode during init, even if the bootloader has already initialised
    it, and may even have already put it into binary mode (as YAMON does).
    This corrupts the current time, can result in the RTC seconds being an
    invalid BCD (e.g. 0x1a..0x1f) for up to 6 seconds, as well as confusing
    YAMON for a while after reset, enough for it to report timeouts when
    attempting to load from TFTP (it actually uses the RTC in that code).
    
    Therefore only initialise the RTC to the extent that is necessary so
    that Linux avoids interfering with the bootloader setup, while also
    allowing it to estimate the CPU frequency without hanging, without a
    bootloader necessarily having done anything with the RTC (for example
    when the kernel is loaded via EJTAG).
    
    The divider control is configured for a 32KHZ reference clock if
    necessary, and the SET bit of the RTC_CONTROL register is cleared if
    necessary without changing any other bits (this bit will be set when
    coming out of reset if the battery has been disconnected).
    
    Fixes: a87ea88d8f6c ("MIPS: Malta: initialise the RTC at boot")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Reviewed-by: Paul Burton <paul.burton@imgtec.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Maciej W. Rozycki <macro@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Cc: <stable@vger.kernel.org> # 3.14+
    Patchwork: https://patchwork.linux-mips.org/patch/10739/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>