commit db397d9c6e66afdd34ae430172db122632b5f8a7
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Aug 6 19:00:06 2017 -0700

    Linux 4.9.41

commit 007dffc661cf20f9e924eccc7b161ce2419ba81b
Author: Patrick Lai <plai@codeaurora.org>
Date:   Sat Dec 31 22:44:39 2016 -0800

    ASoC: dpcm: Avoid putting stream state to STOP when FE stream is paused
    
    
    [ Upstream commit 9f169b9f52a4afccdab7a7d2311b0c53a78a1e6b ]
    
    When multiple front-ends are using the same back-end, putting state of a
    front-end to STOP state upon receiving pause command will result in backend
    stream getting released by DPCM framework unintentionally. In order to
    avoid backend to be released when another active front-end stream is
    present, put the stream state to PAUSED state instead of STOP state.
    
    Signed-off-by: Patrick Lai <plai@codeaurora.org>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27ef0283b60ecb0445a7530db1f3a997ce89715a
Author: Jeeja KP <jeeja.kp@intel.com>
Date:   Mon Jan 2 09:50:05 2017 +0530

    ASoC: Intel: Skylake: Release FW ctx in cleanup
    
    
    [ Upstream commit bc65a326c579e93a5c2120a65ede72f11369ee5a ]
    
    Saved firmware ctx was not never released, so release Firmware
    ctx in cleanup routine.
    
    Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
    Acked-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23ab274ddf83931ecc21968d11c773a2a972e462
Author: Benjamin Poirier <bpoirier@suse.com>
Date:   Fri Dec 23 20:40:19 2016 -0800

    scsi: bfa: Increase requested firmware version to 3.2.5.1
    
    
    [ Upstream commit 2d1148f0f45079d25a0fa0d67e4fdb2a656d12fb ]
    
    bna & bfa firmware version 3.2.5.1 was submitted to linux-firmware on
    Feb 17 19:10:20 2015 -0500 in 0ab54ff1dc ("linux-firmware: Add QLogic BR
    Series Adapter Firmware").
    
    bna was updated to use the newer firmware on Feb 19 16:02:32 2015 -0500 in
    3f307c3d70 ("bna: Update the Driver and Firmware Version")
    
    bfa was not updated. I presume this was an oversight but it broke support
    for bfa+bna cards such as the following
            04:00.0 Fibre Channel [0c04]: Brocade Communications Systems, Inc.
                    1010/1020/1007/1741 10Gbps CNA [1657:0014] (rev 01)
            04:00.1 Fibre Channel [0c04]: Brocade Communications Systems, Inc.
                    1010/1020/1007/1741 10Gbps CNA [1657:0014] (rev 01)
            04:00.2 Ethernet controller [0200]: Brocade Communications Systems,
                    Inc. 1010/1020/1007/1741 10Gbps CNA [1657:0014] (rev 01)
            04:00.3 Ethernet controller [0200]: Brocade Communications Systems,
                    Inc. 1010/1020/1007/1741 10Gbps CNA [1657:0014] (rev 01)
    
    Currently, if the bfa module is loaded first, bna fails to probe the
    respective devices with
    [  215.026787] bna: QLogic BR-series 10G Ethernet driver - version: 3.2.25.1
    [  215.043707] bna 0000:04:00.2: bar0 mapped to ffffc90001fc0000, len 262144
    [  215.060656] bna 0000:04:00.2: initialization failed err=1
    [  215.073893] bna 0000:04:00.3: bar0 mapped to ffffc90002040000, len 262144
    [  215.090644] bna 0000:04:00.3: initialization failed err=1
    
    Whereas if bna is loaded first, bfa fails with
    [  249.592109] QLogic BR-series BFA FC/FCOE SCSI driver - version: 3.2.25.0
    [  249.610738] bfa 0000:04:00.0: Running firmware version is incompatible with the driver version
    [  249.833513] bfa 0000:04:00.0: bfa init failed
    [  249.833919] scsi host6: QLogic BR-series FC/FCOE Adapter, hwpath: 0000:04:00.0 driver: 3.2.25.0
    [  249.841446] bfa 0000:04:00.1: Running firmware version is incompatible with the driver version
    [  250.045449] bfa 0000:04:00.1: bfa init failed
    [  250.045962] scsi host7: QLogic BR-series FC/FCOE Adapter, hwpath: 0000:04:00.1 driver: 3.2.25.0
    
    Increase bfa's requested firmware version. Also increase the driver
    version.  I only tested that all of the devices probe without error.
    
    Reported-by: Tim Ehlers <tehlers@gwdg.de>
    Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
    Acked-by: Rasesh Mody <rasesh.mody@cavium.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f704071920299073d23be138939545158ce42d1
Author: Burak Ok <burak-kernel@bur0k.de>
Date:   Wed Dec 21 14:45:53 2016 +0100

    scsi: snic: Return error code on memory allocation failure
    
    
    [ Upstream commit 0371adcdaca92912baaa3256ed13e058a016e62d ]
    
    If a call to mempool_create_slab_pool() in snic_probe() returns NULL,
    return -ENOMEM to indicate failure. mempool_creat_slab_pool() only fails
    if it cannot allocate memory.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=189061
    
    Reported-by: bianpan2010@ruc.edu.cn
    Signed-off-by: Burak Ok <burak-kernel@bur0k.de>
    Signed-off-by: Andreas Schaertl <andreas.schaertl@fau.de>
    Acked-by: Narsimhulu Musini <nmusini@cisco.com>
    Reviewed-by: Ewan D. Milne <emilne@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2803ea76366a735f69d81dbaeae19b8dbf44a48d
Author: Satish Kharat <satishkh@cisco.com>
Date:   Wed Dec 14 13:20:41 2016 -0800

    scsi: fnic: Avoid sending reset to firmware when another reset is in progress
    
    
    [ Upstream commit 9698b6f473555a722bf81a3371998427d5d27bde ]
    
    This fix is to avoid calling fnic_fw_reset_handler through
    fnic_host_reset when a finc reset is alreay in progress.
    
    Signed-off-by: Satish Kharat <satishkh@cisco.com>
    Signed-off-by: Sesidhar Baddela <sebaddel@cisco.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b6f4e292cbdd46c03303a20417e0c05ddb73bda
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Thu Jan 5 14:25:59 2017 +0100

    HID: ignore Petzl USB headlamp
    
    
    [ Upstream commit 08f9572671c8047e7234cbf150869aa3c3d59a97 ]
    
    This headlamp contains a dummy HID descriptor which pretends to be
    a mouse-like device, but can't be used as a mouse at all.
    
    Reported-by: Lukas Ocilka <lukas.ocilka@suse.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f0dfa11cc0da608fc513f53b50efebb9827f371
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Wed Jan 4 15:44:52 2017 -0600

    ASoC: Intel: bytcr-rt5640: fix settings in internal clock mode
    
    
    [ Upstream commit 60448b077ed93d227e6c117a9e87db76ff0c1911 ]
    
    Frequency value of zero did not make sense, use same 24.576MHz
    setting and only change the clock source in idle mode
    
    Suggested-by: Bard Liao <bardliao@realtek.com>
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b899142ce21d53b496fe7d1534ba7ca62538ca37
Author: David Carrillo-Cisneros <davidcc@google.com>
Date:   Thu Dec 22 17:17:40 2016 -0800

    perf/x86: Set pmu->module in Intel PMU modules
    
    
    [ Upstream commit 74545f63890e38520eb4d1dbedcadaa9c0dbc824 ]
    
    The conversion of Intel PMU drivers into modules did not include reference
    counting. The machine will crash when attempting to  access deleted code
    if an event from a module PMU is started and the module removed before the
    event is destroyed.
    
    i.e. this crashes the machine:
    
            $ insmod intel-rapl-perf.ko
            $ perf stat -e power/energy-cores/ -C 0 &
            $ rmmod intel-rapl-perf.ko
    
    Set THIS_MODULE to pmu->module in Intel module PMUs so that generic code
    can handle reference counting and deny rmmod while an event still exists.
    
    Signed-off-by: David Carrillo-Cisneros <davidcc@google.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Kan Liang <kan.liang@intel.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Paul Turner <pjt@google.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/1482455860-116269-1-git-send-email-davidcc@google.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit efa225254a4a57b871b279cc38fd4048a0fbfa76
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon Jan 2 11:24:50 2017 +0200

    x86/platform/intel-mid: Rename 'spidev' to 'mrfld_spidev'
    
    
    [ Upstream commit 159d3726db12b3476bc59ea0ab0a702103d466b5 ]
    
    The current implementation supports only Intel Merrifield platforms. Don't mess
    with the rest of the Intel MID family by not registering device with wrong
    properties.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/20170102092450.87229-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12dac5fcf5ec156f9f056aff1a8cbed04fde5538
Author: Ioan-Adrian Ratiu <adi@adirat.com>
Date:   Thu Jan 5 00:37:47 2017 +0200

    ALSA: usb-audio: test EP_FLAG_RUNNING at urb completion
    
    
    [ Upstream commit 13a6c8328e6056932dc680e447d4c5e8ad9add17 ]
    
    Testing EP_FLAG_RUNNING in snd_complete_urb() before running the completion
    logic allows us to save a few cpu cycles by returning early, skipping the
    pending urb in case the stream was stopped; the stop logic handles the urb
    and sets the completion callbacks to NULL.
    
    Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 301681d60003b172af1a70fdd833567e16f55d9a
Author: Yuriy Kolerov <yuriy.kolerov@synopsys.com>
Date:   Wed Dec 28 11:46:25 2016 +0300

    ARCv2: IRQ: Call entry/exit functions for chained handlers in MCIP
    
    
    [ Upstream commit e51d5d02f688c45b6f644f472f0c80fdfa73f0cb ]
    
    It is necessary to call entry/exit functions for parent interrupt
    controllers for proper masking/unmasking of interrupt lines.
    
    Signed-off-by: Yuriy Kolerov <yuriy.kolerov@synopsys.com>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f10e2065ce76b8ca54301d2de40aa9b351daf407
Author: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date:   Wed Jan 4 23:10:23 2017 +0300

    sh_eth: enable RX descriptor word 0 shift on SH7734
    
    
    [ Upstream commit 71eae1ca77fd6be218d8a952d97bba827e56516d ]
    
    The RX descriptor word 0 on SH7734 has the RFS[9:0] field in bits 16-25
    (bits  0-15 usually used for that are occupied by the packet checksum).
    Thus  we need to set the 'shift_rd0'  field in the SH7734 SoC data...
    
    Fixes: f0e81fecd4f8 ("net: sh_eth: Add support SH7734")
    Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2909c9c2d7138f1900bddf16d0515025306a8e05
Author: Caleb Crome <caleb@crome.org>
Date:   Tue Jan 3 10:22:57 2017 -0800

    ASoC: fsl_ssi: set fifo watermark to more reliable value
    
    
    [ Upstream commit 4ee437fbf626b5ad756889d8bc0fcead3d66dde7 ]
    
    The fsl_ssi fifo watermark is by default set to 2 free spaces (i.e.
    activate DMA on FIFO when only 2 spaces are left.)  This means the
    DMA must service the fifo within 2 audio samples, which is just not
    enough time  for many use cases with high data rate.  In many
    configurations the audio channel slips (causing l/r swap in stereo
    configurations, or channel slipping in multi-channel configurations).
    
    This patch gives more breathing room and allows the SSI to operate
    reliably by changing the fifio refill watermark to 8.
    
    There is no change in behavior for older chips (with an 8-deep fifo).
    Only the newer chips with a 15-deep fifo get the new behavior. I
    suspect a new fifo depth setting could be optimized on the older
    chips too, but I have not tested.
    
    Signed-off-by: Caleb Crome <caleb@crome.org>
    Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2548d893a542bab079ef72266ff297ff61a20ef3
Author: Peter Chen <peter.chen@nxp.com>
Date:   Tue Jan 3 17:22:20 2017 +0800

    net: usb: asix_devices: add .reset_resume for USB PM
    
    
    [ Upstream commit 63dfb0dac9055145db85ce764355aef2f563739a ]
    
    The USB core may call reset_resume when it fails to resume asix device.
    And USB core can recovery this abnormal resume at low level driver,
    the same .resume at asix driver can work too. Add .reset_resume can
    avoid disconnecting after backing from system resume, and NFS can
    still be mounted after this commit.
    
    Signed-off-by: Peter Chen <peter.chen@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7526723b7fced9fc0dfa033c4227f040e351e78
Author: Daniel Schultz <d.schultz@phytec.de>
Date:   Wed Jan 4 16:18:10 2017 +0000

    nvmem: imx-ocotp: Fix wrong register size
    
    
    [ Upstream commit 14ba972842f9e84e6d3264bc0302101b8a792288 ]
    
    All i.MX6 SoCs have an OCOTP Controller with 4kbit fuses. The i.MX6SL is
    an exception and has only 2kbit fuses.
    
    In the TRM for the i.MX6DQ (IMX6QDRM - Rev 2, 06/2014) the fuses size is
    described in chapter 46.1.1 with:
    "32-bit word restricted program and read to 4Kbits of eFuse OTP(512x8)."
    
    In the TRM for the i.MX6SL (IMX6SLRM - Rev 2, 06/2015) the fuses size is
    described in chapter 34.1.1 with:
    "32-bit word restricted program and read to 2 kbit of eFuse OTP(128x8)."
    
    Since the Freescale Linux kernel OCOTP driver works with a fuses size of
    2 kbit for the i.MX6SL, it looks like the TRM is wrong and the formula
    to calculate the correct fuses size has to be 256x8.
    
    Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e95ec3582a295d95de8d9ebf5e31426599563c7f
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Tue Jan 3 14:27:26 2017 +0000

    arm64: mm: fix show_pte KERN_CONT fallout
    
    
    [ Upstream commit 6ef4fb387d50fa8f3bffdffc868b57e981cdd709 ]
    
    Recent changes made KERN_CONT mandatory for continued lines. In the
    absence of KERN_CONT, a newline may be implicit inserted by the core
    printk code.
    
    In show_pte, we (erroneously) use printk without KERN_CONT for continued
    prints, resulting in output being split across a number of lines, and
    not matching the intended output, e.g.
    
    [ff000000000000] *pgd=00000009f511b003
    , *pud=00000009f4a80003
    , *pmd=0000000000000000
    
    Fix this by using pr_cont() for all the continuations.
    
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 812a7df6556faae25deb42dbcc9e47829855556f
Author: Arvind Yadav <arvind.yadav.cs@gmail.com>
Date:   Tue Jan 3 17:26:46 2017 +0530

    vfio-pci: Handle error from pci_iomap
    
    
    [ Upstream commit e19f32da5ded958238eac1bbe001192acef191a2 ]
    
    Here, pci_iomap can fail, handle this case release selected
    pci regions and return -ENOMEM.
    
    Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a417ea5b9d22dc5733f6fac5cee72735cb7f8d99
Author: Arvind Yadav <arvind.yadav.cs@gmail.com>
Date:   Tue Dec 13 13:50:52 2016 +0530

    video: fbdev: cobalt_lcdfb: Handle return NULL error from devm_ioremap
    
    
    [ Upstream commit 4dcd19bfabaee8f9f4bcf203afba09b98ccbaf76 ]
    
    Here, If devm_ioremap will fail. It will return NULL.
    Kernel can run into a NULL-pointer dereference.
    This error check will avoid NULL pointer dereference.
    
    Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
    Acked-by: Yoichi Yuasa <yuasa@linux-mips.org>
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ddc0ec3be8077a689e0136c873519bf851a741e6
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Tue Jan 3 15:19:21 2017 -0300

    perf symbols: Robustify reading of build-id from sysfs
    
    
    [ Upstream commit 7934c98a6e04028eb34c1293bfb5a6b0ab630b66 ]
    
    Markus reported that perf segfaults when reading /sys/kernel/notes from
    a kernel linked with GNU gold, due to what looks like a gold bug, so do
    some bounds checking to avoid crashing in that case.
    
    Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
    Report-Link: http://lkml.kernel.org/r/20161219161821.GA294@x4
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: David Ahern <dsahern@gmail.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Wang Nan <wangnan0@huawei.com>
    Link: http://lkml.kernel.org/n/tip-ryhgs6a6jxvz207j2636w31c@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8086c3bd3a556e7598c93e5d303f771356adf9f
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Tue Jan 3 12:03:59 2017 -0300

    perf tools: Install tools/lib/traceevent plugins with install-bin
    
    
    [ Upstream commit 30a9c6444810429aa2b7cbfbd453ce339baaadbf ]
    
    Those are binaries as well, so should be installed by:
    
      make -C tools/perf install-bin'
    
    too.
    
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Link: http://lkml.kernel.org/n/tip-3841b37u05evxrs1igkyu6ks@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b8656414e29578f00e40e7d19c411039b9ab71e
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date:   Tue Feb 14 07:43:56 2017 +0100

    xfrm: Don't use sk_family for socket policy lookups
    
    commit 4c86d77743a54fb2d8a4d18a037a074c892bb3be upstream.
    
    On IPv4-mapped IPv6 addresses sk_family is AF_INET6,
    but the flow informations are created based on AF_INET.
    So the routing set up 'struct flowi4' but we try to
    access 'struct flowi6' what leads to an out of bounds
    access. Fix this by using the family we get with the
    dst_entry, like we do it for the standard policy lookup.
    
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Tested-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab5e7df9e064d54f442108544d5dfb8116cb2f41
Author: Daniel Bristot de Oliveira <bristot@redhat.com>
Date:   Tue Jan 3 12:42:42 2017 +0100

    tools lib traceevent: Fix prev/next_prio for deadline tasks
    
    
    [ Upstream commit 074859184d770824f4437dca716bdeb625ae8b1c ]
    
    Currently, the sched:sched_switch tracepoint reports deadline tasks with
    priority -1. But when reading the trace via perf script I've got the
    following output:
    
      # ./d & # (d is a deadline task, see [1])
      # perf record -e sched:sched_switch -a sleep 1
      # perf script
          ...
             swapper     0 [000]  2146.962441: sched:sched_switch: swapper/0:0 [120] R ==> d:2593 [4294967295]
                   d  2593 [000]  2146.972472: sched:sched_switch: d:2593 [4294967295] R ==> g:2590 [4294967295]
    
    The task d reports the wrong priority [4294967295]. This happens because
    the "int prio" is stored in an unsigned long long val. Although it is
    set as a %lld, as int is shorter than unsigned long long,
    trace_seq_printf prints it as a positive number.
    
    The fix is just to cast the val as an int, and print it as a %d,
    as in the sched:sched_switch tracepoint's "format".
    
    The output with the fix is:
    
      # ./d &
      # perf record -e sched:sched_switch -a sleep 1
      # perf script
          ...
             swapper     0 [000]  4306.374037: sched:sched_switch: swapper/0:0 [120] R ==> d:10941 [-1]
                   d 10941 [000]  4306.383823: sched:sched_switch: d:10941 [-1] R ==> swapper/0:0 [120]
    
    [1] d.c
    
     ---
      #include <stdio.h>
      #include <unistd.h>
      #include <sys/syscall.h>
      #include <linux/types.h>
      #include <linux/sched.h>
    
      struct sched_attr {
            __u32 size, sched_policy;
            __u64 sched_flags;
            __s32 sched_nice;
            __u32 sched_priority;
            __u64 sched_runtime, sched_deadline, sched_period;
      };
    
      int sched_setattr(pid_t pid, const struct sched_attr *attr, unsigned int flags)
      {
            return syscall(__NR_sched_setattr, pid, attr, flags);
      }
    
      int main(void)
      {
            struct sched_attr attr = {
                    .size           = sizeof(attr),
                    .sched_policy   = SCHED_DEADLINE, /* This creates a 10ms/30ms reservation */
                    .sched_runtime  = 10 * 1000 * 1000,
                    .sched_period   = attr.sched_deadline = 30 * 1000 * 1000,
            };
    
            if (sched_setattr(0, &attr, 0) < 0) {
                    perror("sched_setattr");
                    return -1;
            }
    
            for(;;);
      }
     ---
    
    Committer notes:
    
    Got the program from the provided URL, http://bristot.me/lkml/d.c,
    trimmed it and included in the cset log above, so that we have
    everything needed to test it in one place.
    
    Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
    Acked-by: Steven Rostedt <rostedt@goodmis.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/866ef75bcebf670ae91c6a96daa63597ba981f0d.1483443552.git.bristot@redhat.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 704a6d719d4c4228c7f0b1fbaf6bc35fe2ccf1d8
Author: Jiandi An <anjiandi@codeaurora.org>
Date:   Tue Dec 27 18:47:32 2016 -0600

    Xen: ARM: Zero reserved fields of xatp before making hypervisor call
    
    
    [ Upstream commit 0b47a6bd1150f4846b1d61925a4cc5a96593a541 ]
    
    Ensure all reserved fields of xatp are zero before making
    hypervisor call to XEN in xen_map_device_mmio().
    xenmem_add_to_physmap_one() in XEN fails the mapping request if
    extra.res reserved field in xatp is not zero for XENMAPSPACE_dev_mmio
    request.
    
    Signed-off-by: Jiandi An <anjiandi@codeaurora.org>
    Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f76ddff6c5215131483efed20acc896e021abb9f
Author: Liu Bo <bo.li.liu@oracle.com>
Date:   Thu Dec 22 17:13:54 2016 -0800

    Btrfs: adjust outstanding_extents counter properly when dio write is split
    
    
    [ Upstream commit c2931667c83ded6504b3857e99cc45b21fa496fb ]
    
    Currently how btrfs dio deals with split dio write is not good
    enough if dio write is split into several segments due to the
    lack of contiguous space, a large dio write like 'dd bs=1G count=1'
    can end up with incorrect outstanding_extents counter and endio
    would complain loudly with an assertion.
    
    This fixes the problem by compensating the outstanding_extents
    counter in inode if a large dio write gets split.
    
    Reported-by: Anand Jain <anand.jain@oracle.com>
    Tested-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49fc90b443c71b3cdbfaf15c0c15fc7e3ffc5731
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Tue Jan 3 16:26:04 2017 +0100

    benet: stricter vxlan offloading check in be_features_check
    
    
    [ Upstream commit 096de2f83ebc8e0404c5b7e847a4abd27b9739da ]
    
    When VXLAN offloading is enabled, be_features_check() tries to check if
    an encapsulated packet is indeed a VXLAN packet. The check is not strict
    enough, and considers any UDP-encapsulated ethernet frame with a 8-byte
    tunnel header as being VXLAN. Unfortunately, both GENEVE and VXLAN-GPE
    have a 8-byte header, so they get through this check.
    
    Force the UDP destination port to be the one that has been offloaded to
    hardware.
    
    Without this, GENEVE-encapsulated packets can end up having an incorrect
    checksum when both a GENEVE and a VXLAN (offloaded) tunnel are
    configured.
    
    This is similar to commit a547224dceed ("mlx4e: Do not attempt to
    offload VXLAN ports that are unrecognized").
    
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6731212836059c7ac3575e21c499380e795516a9
Author: Liu Bo <bo.li.liu@oracle.com>
Date:   Wed Nov 30 16:20:25 2016 -0800

    Btrfs: fix lockdep warning about log_mutex
    
    
    [ Upstream commit 781feef7e6befafd4d9787d1f7ada1f9ccd504e4 ]
    
    While checking INODE_REF/INODE_EXTREF for a corner case, we may acquire a
    different inode's log_mutex with holding the current inode's log_mutex, and
    lockdep has complained this with a possilble deadlock warning.
    
    Fix this by using mutex_lock_nested() when processing the other inode's
    log_mutex.
    
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78418b86733462c913aea82e081594b1005751ba
Author: Liu Bo <bo.li.liu@oracle.com>
Date:   Wed Nov 30 16:11:04 2016 -0800

    Btrfs: use down_read_nested to make lockdep silent
    
    
    [ Upstream commit e321f8a801d7b4c40da8005257b05b9c2b51b072 ]
    
    If @block_group is not @used_bg, it'll try to get @used_bg's lock without
    droping @block_group 's lock and lockdep has throwed a scary deadlock warning
    about it.
    Fix it by using down_read_nested.
    
    Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92d6a813b03a576dd821667b6566a1ddf7617137
Author: David Lechner <david@lechnology.com>
Date:   Mon Jan 2 17:28:39 2017 -0600

    usb: gadget: Fix copy/pasted error message
    
    
    [ Upstream commit 43aef5c2ca90535b3227e97e71604291875444ed ]
    
    This fixes an error message that was probably copied and pasted. The same
    message is used for both the in and out endpoints, so it makes it impossible
    to know which one actually failed because both cases say "IN".
    
    Make the out endpoint error message say "OUT".
    
    Signed-off-by: David Lechner <david@lechnology.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a15a3d92eca8dd20f55ba574ff5cd1c527af4272
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Fri Dec 30 02:27:31 2016 +0100

    ACPI / scan: Prefer devices without _HID/_CID for _ADR matching
    
    
    [ Upstream commit c2a6bbaf0c5f90463a7011a295bbdb7e33c80b51 ]
    
    The way acpi_find_child_device() works currently is that, if there
    are two (or more) devices with the same _ADR value in the same
    namespace scope (which is not specifically allowed by the spec and
    the OS behavior in that case is not defined), the first one of them
    found to be present (with the help of _STA) will be returned.
    
    This covers the majority of cases, but is not sufficient if some of
    the devices in question have a _HID (or _CID) returning some valid
    ACPI/PNP device IDs (which is disallowed by the spec) and the
    ASL writers' expectation appears to be that the OS will match
    devices without a valid ACPI/PNP device ID against a given bus
    address first.
    
    To cover this special case as well, modify find_child_checks()
    to prefer devices without ACPI/PNP device IDs over devices that
    have them.
    
    Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Tested-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebd4642ee412ba3719274d80658a4c785fc43678
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Thu Dec 29 14:41:05 2016 +0200

    ARM: s3c2410_defconfig: Fix invalid values for NF_CT_PROTO_*
    
    
    [ Upstream commit 3ef01c968fbfb21c2f16281445d30a865ee4412c ]
    
    NF_CT_PROTO_DCCP/SCTP/UDPLITE were switched from tristate to boolean so
    defconfig needs to be adjusted to silence warnings:
            warning: symbol value 'm' invalid for NF_CT_PROTO_DCCP
            warning: symbol value 'm' invalid for NF_CT_PROTO_SCTP
            warning: symbol value 'm' invalid for NF_CT_PROTO_UDPLITE
    
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69f3df1fd01322d90a35bac071c53b9497ea3601
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Tue Jan 3 00:20:49 2017 +0900

    perf probe: Fix to get correct modname from elf header
    
    
    [ Upstream commit 1f2ed153b916c95a49a1ca9d7107738664224b7f ]
    
    Since 'perf probe' supports cross-arch probes, it is possible to analyze
    different arch kernel image which has different bits-per-long.
    
    In that case, it fails to get the module name because it uses the
    MOD_NAME_OFFSET macro based on the host machine bits-per-long, instead
    of the target arch bits-per-long.
    
    This fixes above issue by changing modname-offset based on the target
    archs bit width. This is ok because linux kernel uses LP64 model on
    64bit arch.
    
    E.g. without this (on x86_64, and target module is arm32):
    
      $ perf probe -m build-arm/fs/configfs/configfs.ko -D configfs_lookup
      p:probe/configfs_lookup :configfs_lookup+0
                              ^-Here is an empty module name.
    
    With this fix, you can see correct module name:
    
      $ perf probe -m build-arm/fs/configfs/configfs.ko -D configfs_lookup
      p:probe/configfs_lookup configfs:configfs_lookup+0
    
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/148337043836.6752.383495516397005695.stgit@devbox
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3209f3f69eeb187d5174f253b1b91fbdbf264f33
Author: Moritz Fischer <mdf@kernel.org>
Date:   Thu Dec 22 09:19:25 2016 -0800

    ARM64: zynqmp: Fix i2c node's compatible string
    
    
    [ Upstream commit c415f9e8304a1d235ef118d912f374ee2e46c45d ]
    
    The Zynq Ultrascale MP uses version 1.4 of the Cadence IP core
    which fixes some silicon bugs that needed software workarounds
    in Version 1.0 that was used on Zynq systems.
    
    Signed-off-by: Moritz Fischer <mdf@kernel.org>
    Cc: Michal Simek <michal.simek@xilinx.com>
    Cc: Sören Brinkmann <soren.brinkmann@xilinx.com>
    Cc: Rob Herring <robh+dt@kernel.org>
    Acked-by: Sören Brinkmann <soren.brinkmann@xilinx.com>
    Signed-off-by: Michal Simek <michal.simek@xilinx.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3603533ae6394f377bf3a767787cddecc176696
Author: Michal Simek <michal.simek@xilinx.com>
Date:   Tue Nov 15 14:53:13 2016 +0100

    ARM64: zynqmp: Fix W=1 dtc 1.4 warnings
    
    
    [ Upstream commit 4ea2a6be9565455f152c12f80222af1582ede0c7 ]
    
    The patch removes these warnings reported by dtc 1.4:
    Warning (unit_address_vs_reg): Node /amba_apu has a reg or ranges
    property, but no unit name
    Warning (unit_address_vs_reg): Node /memory has a reg or ranges
    property, but no unit name
    
    Signed-off-by: Michal Simek <michal.simek@xilinx.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8af0937aee50d1d1f41f1caf56aefcf364d3b1b9
Author: Grygorii Strashko <grygorii.strashko@ti.com>
Date:   Mon Dec 12 13:37:52 2016 -0600

    usb: dwc3: omap: fix race of pm runtime with irq handler in probe
    
    
    [ Upstream commit 12a7f17fac5b370bec87259e4c718faf563ce900 ]
    
    Now races can happen between interrupt handler execution and PM runtime in
    error handling code path in probe and in dwc3_omap_remove() which will lead
    to system crash:
    
    in probe:
    ...
     err1:
            pm_runtime_put_sync(dev);
    ^^ PM runtime can race with IRQ handler when deferred probing happening
       due to extcon
            pm_runtime_disable(dev);
    
            return ret;
    
    in dwc3_omap_remove:
    ...
            dwc3_omap_disable_irqs(omap);
    ^^ IRQs are disabled in HW, but handler may still run
            of_platform_depopulate(omap->dev);
            pm_runtime_put_sync(&pdev->dev);
    ^^ PM runtime can race with IRQ handler
            pm_runtime_disable(&pdev->dev);
    
            return 0;
    
    So, OMAP DWC3 IRQ need to be disabled before calling
    pm_runtime_put() in probe and in dwc3_omap_remove().
    
    Acked-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29e0adf8bacd3cb91893ec90eb6a61d938209a24
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Dec 19 06:33:51 2016 +0100

    dmaengine: ti-dma-crossbar: Add some 'of_node_put()' in error path.
    
    
    [ Upstream commit 75bdc7f31a3a6e9a12e218b31a44a1f54a91554c ]
    
    Add some missing 'of_node_put()' in early exit error path.
    
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 000224c1106c2abc21a376c5bb851b1ffe4b4458
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Fri Dec 30 19:48:19 2016 +0100

    l2tp: consider '::' as wildcard address in l2tp_ip6 socket lookup
    
    
    [ Upstream commit 97b84fd6d91766ea57dcc350d78f42639e011c30 ]
    
    An L2TP socket bound to the unspecified address should match with any
    address. If not, it can't receive any packet and __l2tp_ip6_bind_lookup()
    can't prevent another socket from binding on the same device/tunnel ID.
    
    While there, rename the 'addr' variable to 'sk_laddr' (local addr), to
    make following patch clearer.
    
    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2804b21f2e7f46f76500aa58850127b31054c84
Author: Dave Jiang <dave.jiang@intel.com>
Date:   Tue Dec 13 11:15:27 2016 -0700

    dmaengine: ioatdma: workaround SKX ioatdma version
    
    
    [ Upstream commit 34a31f0af84158955a9747fb5c6712da5bbb5331 ]
    
    The Skylake ioatdma is technically CBDMA 3.2+ and contains the same hardware
    bits with some additional 3.3 features, but it's not really 3.3 where the
    driver is concerned.
    
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2987ce159fb9b0894d9bf000b8317e07cfed3fa8
Author: Dave Jiang <dave.jiang@intel.com>
Date:   Tue Dec 13 11:15:21 2016 -0700

    dmaengine: ioatdma: Add Skylake PCI Dev ID
    
    
    [ Upstream commit 1594c18fd297a8edcc72bc4b161f3f52603ebb92 ]
    
    Adding Skylake Xeon PCI device ids for ioatdma and related bits.
    
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88a86f8dfaad6b7185ad1658a8283f12dc4a351b
Author: Stafford Horne <shorne@gmail.com>
Date:   Wed Dec 14 21:27:57 2016 +0900

    openrisc: Add _text symbol to fix ksym build error
    
    
    [ Upstream commit 086cc1c31a0ec075dac02425367c871bb65bc2c9 ]
    
    The build robot reports:
    
       .tmp_kallsyms1.o: In function `kallsyms_relative_base':
    >> (.rodata+0x8a18): undefined reference to `_text'
    
    This is when using 'make alldefconfig'. Adding this _text symbol to mark
    the start of the kernel as in other architecture fixes this.
    
    Signed-off-by: Stafford Horne <shorne@gmail.com>
    Acked-by: Jonas Bonn <jonas@southpole.se>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 033d5ce4ad8d7b56bd562ff1107ac5780fb85eb7
Author: Stefan Wahren <stefan.wahren@i2se.com>
Date:   Tue Dec 27 18:29:57 2016 +0000

    irqchip/mxs: Enable SKIP_SET_WAKE and MASK_ON_SUSPEND
    
    
    [ Upstream commit 88e20c74ee020f9e0c99dfce0dd9aa61c3f0cca0 ]
    
    The ICOLL controller doesn't provide any facility to configure the
    wakeup sources. That's the reason why this implementation lacks
    the irq_set_wake implementation. But this prevent us from properly
    entering power management states like "suspend to idle".
    
    So enable the flags IRQCHIP_SKIP_SET_WAKE and
    IRQCHIP_MASK_ON_SUSPEND to let the irqchip core allows and handles
    the power management.
    
    Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
    Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
    Link: https://lkml.kernel.org/r/1482863397-11400-1-git-send-email-stefan.wahren@i2se.com
    Signed-off-by: Jason Cooper <jason@lakedaemon.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c612bba54b8c412ee81c8dd071fa81e4ab689505
Author: John Hsu <KCHSU0@nuvoton.com>
Date:   Tue Dec 20 12:03:09 2016 +0800

    ASoC: nau8825: fix invalid configuration in Pre-Scalar of FLL
    
    
    [ Upstream commit a1792cda51300e15b03549cccf0b09f3be82e697 ]
    
    The clk_ref_div is not configured in the correct position of the
    register. The patch fixes that clk_ref_div, Pre-Scalar, is assigned
    the wrong value.
    
    Signed-off-by: John Hsu <KCHSU0@nuvoton.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14e5c8c61791d03e69de94affc149dcb6735aa66
Author: Phil Reid <preid@electromag.com.au>
Date:   Thu Dec 22 17:18:12 2016 +0800

    spi: dw: Make debugfs name unique between instances
    
    
    [ Upstream commit 13288bdf4adbaa6bd1267f10044c1bc25d90ce7f ]
    
    Some system have multiple dw devices. Currently the driver uses a
    fixed name for the debugfs dir. Append dev name to the debugfs dir
    name to make it unique.
    
    Signed-off-by: Phil Reid <preid@electromag.com.au>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed788dc6fa65f74a5f82f9fe5d7ea46d17cdaf87
Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
Date:   Fri Dec 23 11:21:10 2016 +0200

    ASoC: tlv320aic3x: Mark the RESET register as volatile
    
    
    [ Upstream commit 63c3194b82530bd71fd49db84eb7ab656b8d404a ]
    
    The RESET register only have one self clearing bit and it should not be
    cached. If it is cached, when we sync the registers back to the chip we
    will initiate a software reset as well, which is not desirable.
    
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Reviewed-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca40b2d039dc443ed82957260dbcc3097f8f80d6
Author: Strashko, Grygorii <grygorii.strashko@ti.com>
Date:   Thu Dec 8 17:33:10 2016 -0600

    irqchip/keystone: Fix "scheduling while atomic" on rt
    
    
    [ Upstream commit 2f884e6e688a0deb69e6c9552e51aef8b7e3f5f1 ]
    
    The below call chain generates "scheduling while atomic" backtrace and
    causes system crash when Keystone 2 IRQ chip driver is used with RT-kernel:
    
    gic_handle_irq()
     |-__handle_domain_irq()
      |-generic_handle_irq()
       |-keystone_irq_handler()
        |-regmap_read()
         |-regmap_lock_spinlock()
          |-rt_spin_lock()
    
    The reason is that Keystone driver dispatches IRQ using chained IRQ handler
    and accesses I/O memory through syscon->regmap(mmio) which is implemented
    as fast_io regmap and uses regular spinlocks for synchronization, but
    spinlocks transformed to rt_mutexes on RT.
    
    Hence, convert Keystone 2 IRQ driver to use generic irq handler instead of
    chained IRQ handler. This way it will be compatible with RT kernel where it
    will be forced thread IRQ handler while in non-RT kernel it still will be
    executed in HW IRQ context.
    
    Cc: Suman Anna <s-anna@ti.com>
    Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
    Tested-by: Suman Anna <s-anna@ti.com>
    Link: https://lkml.kernel.org/r/20161208233310.10329-1-grygorii.strashko@ti.com
    Signed-off-by: Jason Cooper <jason@lakedaemon.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7d0c0d84808783740b69a06f5512b2c50200f5f
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Dec 30 08:13:47 2016 -0700

    vfio-pci: use 32-bit comparisons for register address for gcc-4.5
    
    
    [ Upstream commit 45e869714489431625c569d21fc952428d761476 ]
    
    Using ancient compilers (gcc-4.5 or older) on ARM, we get a link
    failure with the vfio-pci driver:
    
    ERROR: "__aeabi_lcmp" [drivers/vfio/pci/vfio-pci.ko] undefined!
    
    The reason is that the compiler tries to do a comparison of
    a 64-bit range. This changes it to convert to a 32-bit number
    explicitly first, as newer compilers do for themselves.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d33b41d34f57547e66c27e96075f8210a47b1b5
Author: Jordan Crouse <jcrouse@codeaurora.org>
Date:   Tue Dec 20 08:54:31 2016 -0700

    drm/msm: Verify that MSM_SUBMIT_BO_FLAGS are set
    
    
    [ Upstream commit a6cb3b864b21b7345f824a4faa12b723c8aaf099 ]
    
    For every submission buffer object one of MSM_SUBMIT_BO_WRITE
    and MSM_SUBMIT_BO_READ must be set (and nothing else). If we
    allowed zero then the buffer object would never get queued to
    be unreferenced.
    
    Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
    Signed-off-by: Rob Clark <robdclark@gmail.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 50e3950d77ba7d897c5509ca6192f1aaed426dd0
Author: Jordan Crouse <jcrouse@codeaurora.org>
Date:   Tue Dec 20 08:54:30 2016 -0700

    drm/msm: Put back the vaddr in submit_reloc()
    
    
    [ Upstream commit 6490abc4bc35fa4f3bdb9c7e49096943c50e29ea ]
    
    The error cases in submit_reloc() need to put back the virtual
    address of the bo before failling. Add a single failure path
    for the function.
    
    Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
    Signed-off-by: Rob Clark <robdclark@gmail.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0d5bb92c07bee2205212ad7aa6f1a85451db6ed
Author: Jordan Crouse <jcrouse@codeaurora.org>
Date:   Tue Dec 20 08:54:29 2016 -0700

    drm/msm: Ensure that the hardware write pointer is valid
    
    
    [ Upstream commit 88b333b0ed790f9433ff542b163bf972953b74d3 ]
    
    Currently the value written to CP_RB_WPTR is calculated on the fly as
    (rb->next - rb->start). But as the code is designed rb->next is wrapped
    before writing the commands so if a series of commands happened to
    fit perfectly in the ringbuffer, rb->next would end up being equal to
    rb->size / 4 and thus result in an out of bounds address to CP_RB_WPTR.
    
    The easiest way to fix this is to mask WPTR when writing it to the
    hardware; it makes the hardware happy and the rest of the ringbuffer
    math appears to work and there isn't any point in upsetting anything.
    
    Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
    [squash in is_power_of_2() check]
    Signed-off-by: Rob Clark <robdclark@gmail.com>
    
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 237652fae500c0ecacdd28281db18878ba46f521
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date:   Thu Dec 29 18:37:13 2016 +0200

    net/mlx4_core: Fix raw qp flow steering rules under SRIOV
    
    
    [ Upstream commit 10b1c04e92229ebeb38ccd0dcf2b6d3ec73c0575 ]
    
    Demoting simple flow steering rule priority (for DPDK) was achieved by
    wrapping FW commands MLX4_QP_FLOW_STEERING_ATTACH/DETACH for the PF
    as well, and forcing the priority to MLX4_DOMAIN_NIC in the wrapper
    function for the PF and all VFs.
    
    In function mlx4_ib_create_flow(), this change caused the main rule
    creation for the PF to be wrapped, while it left the associated
    tunnel steering rule creation unwrapped for the PF.
    
    This mismatch caused rule deletion failures in mlx4_ib_destroy_flow()
    for the PF when the detach wrapper function did not find the associated
    tunnel-steering rule (since creation of that rule for the PF did not
    go through the wrapper function).
    
    Fix this by setting MLX4_QP_FLOW_STEERING_ATTACH/DETACH to be "native"
    (so that the PF invocation does not go through the wrapper), and perform
    the required priority demotion for the PF in the mlx4_ib_create_flow()
    code path.
    
    Fixes: 48564135cba8 ("net/mlx4_core: Demote simple multicast and broadcast flow steering rules")
    Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e150f79134e7eabb5315975ae34bf3169beff4c
Author: Leon Romanovsky <leonro@mellanox.com>
Date:   Thu Dec 29 18:37:11 2016 +0200

    net/mlx4: Remove BUG_ON from ICM allocation routine
    
    
    [ Upstream commit c1d5f8ff80ea84768f5fae1ca9d1abfbb5e6bbaa ]
    
    This patch removes BUG_ON() macro from mlx4_alloc_icm_coherent()
    by checking DMA address alignment in advance and performing proper
    folding in case of error.
    
    Fixes: 5b0bf5e25efe ("mlx4_core: Support ICM tables in coherent memory")
    Reported-by: Ozgur Karatas <okaratas@member.fsf.org>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a8820678afe1289cd35431ff847d817cdeffcadf
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date:   Thu Dec 29 18:37:09 2016 +0200

    net/mlx4_core: Use-after-free causes a resource leak in flow-steering detach
    
    
    [ Upstream commit 3b01fe7f91c8e4f9afc4fae3c5af72c14958d2d8 ]
    
    mlx4_QP_FLOW_STEERING_DETACH_wrapper first removes the steering
    rule (which results in freeing the rule structure), and then
    references a field in this struct (the qp number) when releasing the
    busy-status on the rule's qp.
    
    Since this memory was freed, it could reallocated and changed.
    Therefore, the qp number in the struct may be incorrect,
    so that we are releasing the incorrect qp. This leaves the rule's qp
    in the busy state (and could possibly release an incorrect qp as well).
    
    Fix this by saving the qp number in a local variable, for use after
    removing the steering rule.
    
    Fixes: 2c473ae7e582 ("net/mlx4_core: Disallow releasing VF QPs which have steering rules")
    Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aeb230318ddbfc4b06f0d4befd755090ec0c4d6f
Author: Zheng Li <james.z.li@ericsson.com>
Date:   Wed Dec 28 23:23:46 2016 +0800

    ipv6: Should use consistent conditional judgement for ip6 fragment between __ip6_append_data and ip6_finish_output
    
    
    [ Upstream commit e4c5e13aa45c23692e4acf56f0b3533f328199b2 ]
    
    There is an inconsistent conditional judgement between __ip6_append_data
    and ip6_finish_output functions, the variable length in __ip6_append_data
    just include the length of application's payload and udp6 header, don't
    include the length of ipv6 header, but in ip6_finish_output use
    (skb->len > ip6_skb_dst_mtu(skb)) as judgement, and skb->len include the
    length of ipv6 header.
    
    That causes some particular application's udp6 payloads whose length are
    between (MTU - IPv6 Header) and MTU were fragmented by ip6_fragment even
    though the rst->dev support UFO feature.
    
    Add the length of ipv6 header to length in __ip6_append_data to keep
    consistent conditional judgement as ip6_finish_output for ip6 fragment.
    
    Signed-off-by: Zheng Li <james.z.li@ericsson.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea703cb0140bdeed8b5576816d3cbe6cf09c44d5
Author: Or Gerlitz <ogerlitz@mellanox.com>
Date:   Wed Dec 28 14:58:31 2016 +0200

    net/mlx5: Disable RoCE on the e-switch management port under switchdev mode
    
    
    [ Upstream commit 9da34cd34e85aacc55af8774b81b1f23e86014f9 ]
    
    Under the switchdev/offloads mode, packets that don't match any
    e-switch steering rule are sent towards the e-switch management
    port. We use a NIC HW steering rule set per vport (uplink and VFs)
    to make them be received into the host OS through the respective
    vport representor netdevice.
    
    Currnetly such missed RoCE packets will not get to this NIC steering
    rule, and hence VF RoCE will not work over the slow path of the offloads
    mode. This is b/c these packets will be matched by a steering rule added
    by the firmware that serves RoCE traffic set on the PF NIC vport which
    is also the e-switch management port under SRIOV.
    
    Disabling RoCE on the e-switch management vport when we are in the offloads
    mode, will signal to the firmware to remove their RoCE rule, and then the
    missed RoCE packets will be matched by the representor NIC steering rule
    as any other missed packets.
    
    To achieve that, we disable RoCE on the PF vport. We do that by removing
    (hot-unplugging) the IB device instance associated with the PF. This is
    also required by our current model where the PF serves as the uplink
    representor and hence only SW switching (TC, bridge, OVS) applications
    and slow path vport mlx5e net-device should be running over that vport.
    
    Fixes: c930a3ad7453 ('net/mlx5e: Add devlink based SRIOV mode changes')
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Reviewed-by: Hadar Hen Zion <hadarh@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0a4dd4469048544407e5c6f7466af4dc48a2571
Author: Pali Rohár <pali.rohar@gmail.com>
Date:   Wed Dec 14 22:29:44 2016 +0100

    ARM: dts: n900: Mark eMMC slot with no-sdio and no-sd flags
    
    
    [ Upstream commit 4cf48f1d7520a4d325af58eded4d8090e1b40be7 ]
    
    Trying to initialize eMMC slot as SDIO or SD cause failure in n900 port of
    qemu. eMMC itself is not detected and is not working.
    
    Real Nokia N900 harware does not have this problem. As eMMC is really not
    SDIO or SD based such change is harmless and will fix support for qemu.
    
    Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
    Acked-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ce84ef6a29655b9f985827e149dbf0d23b02dc2
Author: Roger Quadros <rogerq@ti.com>
Date:   Mon Dec 12 11:58:05 2016 +0200

    ARM: dts: am57xx-idk: Put USB2 port in peripheral mode
    
    
    [ Upstream commit 5acd016c88937be3667ba4e6b60f0f74455b5e80 ]
    
    USB2 port can be operated in dual-role mode but till we
    have dual-role support in dwc3 driver let's limit this
    port to peripheral mode.
    
    If we don't do so it defaults to host mode. USB1 port
    is meant for host only operation and we don't want
    both ports in host only mode.
    
    Signed-off-by: Roger Quadros <rogerq@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2bc4d1c9578454d1fae8fb731c50ad1f30656f69
Author: Milo Kim <woogyom.kim@gmail.com>
Date:   Fri Dec 9 15:28:33 2016 +0900

    dt-bindings: input: Specify the interrupt number of TPS65217 power button
    
    
    [ Upstream commit 820381572fc015baa4f5744f5d4583ec0c0f1b82 ]
    
    Specify the power button interrupt number which is from the datasheet.
    
    Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
    Acked-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b1164693f770988e6a164dd813d3408cb7c1762e
Author: Milo Kim <woogyom.kim@gmail.com>
Date:   Fri Dec 9 15:28:32 2016 +0900

    dt-bindings: power/supply: Update TPS65217 properties
    
    
    [ Upstream commit 81d7358d7038dd1001547950087e5b0641732f3f ]
    
    Add interrupt specifiers for USB and AC charger input. Interrupt numbers
    are from the datasheet.
    Fix wrong property for compatible string.
    
    Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
    Acked-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0686a9bc42adff7e70f345685a059ccd2de6f42d
Author: Maninder Singh <maninder1.s@samsung.com>
Date:   Thu Dec 8 09:40:30 2016 +0530

    ARM: omap2+: fixing wrong strcat for Non-NULL terminated string
    
    
    [ Upstream commit 5066d5296ff2db20625e5f46e7338872c90c649f ]
    
    Issue caught with static analysis tool:
    "Dangerous usage of 'name' (strncpy doesn't always 0-terminate it)"
    
    Use strlcpy _includes_ the NUL terminator, and  strlcat() which ensures
    that it won't overflow the buffer.
    
    Reported-by: Maninder Singh <maninder1.s@samsung.com>
    Signed-off-by: Vaneet Narang <v.narang@samsung.com>
    CC: Russell King <linux@armlinux.org.uk>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82338e9ffba55e611613f6a5dfd17697fd76e1e2
Author: Chun-Hao Lin <hau@realtek.com>
Date:   Tue Dec 27 16:29:43 2016 +0800

    r8169: add support for RTL8168 series add-on card.
    
    
    [ Upstream commit 610c908773d30907c950ca3b2ee8ac4b2813537b ]
    
    This chip is the same as RTL8168, but its device id is 0x8161.
    
    Signed-off-by: Chun-Hao Lin <hau@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34fae9c906ec93d7c783d17b365cf1b84db415ec
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon Dec 26 22:58:20 2016 +0100

    x86/mce/AMD: Make the init code more robust
    
    
    [ Upstream commit 0dad3a3014a0b9e72521ff44f17e0054f43dcdea ]
    
    If mce_device_init() fails then the mce device pointer is NULL and the
    AMD mce code happily dereferences it.
    
    Add a sanity check.
    
    Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
    Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a3ff46097a1d05fc95e34f9c4ca493488d8fe766
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Jul 18 17:49:14 2017 -0700

    device-dax: fix sysfs duplicate warnings
    
    commit bbb3be170ac2891526ad07b18af7db226879a8e7 upstream.
    
    Fix warnings of the form...
    
         WARNING: CPU: 10 PID: 4983 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80
         sysfs: cannot create duplicate filename '/class/dax/dax12.0'
         Call Trace:
          dump_stack+0x63/0x86
          __warn+0xcb/0xf0
          warn_slowpath_fmt+0x5a/0x80
          ? kernfs_path_from_node+0x4f/0x60
          sysfs_warn_dup+0x62/0x80
          sysfs_do_create_link_sd.isra.2+0x97/0xb0
          sysfs_create_link+0x25/0x40
          device_add+0x266/0x630
          devm_create_dax_dev+0x2cf/0x340 [dax]
          dax_pmem_probe+0x1f5/0x26e [dax_pmem]
          nvdimm_bus_probe+0x71/0x120
    
    ...by reusing the namespace id for the device-dax instance name.
    
    Now that we have decided that there will never by more than one
    device-dax instance per libnvdimm-namespace parent device [1], we can
    directly reuse the namepace ids. There are some possible follow-on
    cleanups, but those are saved for a later patch to simplify the -stable
    backport.
    
    [1]: https://lists.01.org/pipermail/linux-nvdimm/2016-December/008266.html
    
    Fixes: 98a29c39dc68 ("libnvdimm, namespace: allow creation of multiple pmem...")
    Cc: Jeff Moyer <jmoyer@redhat.com>
    Reported-by: Dariusz Dokupil <dariusz.dokupil@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48a70be0de9e014994c4bd4749c9ccc15bc7731a
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Feb 3 14:29:42 2017 -0800

    net: skb_needs_check() accepts CHECKSUM_NONE for tx
    
    commit 6e7bc478c9a006c701c14476ec9d389a484b4864 upstream.
    
    My recent change missed fact that UFO would perform a complete
    UDP checksum before segmenting in frags.
    
    In this case skb->ip_summed is set to CHECKSUM_NONE.
    
    We need to add this valid case to skb_needs_check()
    
    Fixes: b2504a5dbef3 ("net: reduce skb_warn_bad_offload() noise")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e10f7bd6a6b8484ebe140a793d30b0cc56603620
Author: Kees Cook <keescook@chromium.org>
Date:   Sun Mar 5 22:08:58 2017 -0800

    pstore: Use dynamic spinlock initializer
    
    commit e9a330c4289f2ba1ca4bf98c2b430ab165a8931b upstream.
    
    The per-prz spinlock should be using the dynamic initializer so that
    lockdep can correctly track it. Without this, under lockdep, we get a
    warning at boot that the lock is in non-static memory.
    
    Fixes: 109704492ef6 ("pstore: Make spinlock per zone instead of global")
    Fixes: 76d5692a5803 ("pstore: Correctly initialize spinlock and flags")
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0840275e3ebddd5d1349cd4908777e11ba50311
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Feb 9 15:43:44 2017 -0800

    pstore: Correctly initialize spinlock and flags
    
    commit 76d5692a58031696e282384cbd893832bc92bd76 upstream.
    
    The ram backend wasn't always initializing its spinlock correctly. Since
    it was coming from kzalloc memory, though, it was harmless on
    architectures that initialize unlocked spinlocks to 0 (at least x86 and
    ARM). This also fixes a possibly ignored flag setting too.
    
    When running under CONFIG_DEBUG_SPINLOCK, the following Oops was visible:
    
    [    0.760836] persistent_ram: found existing buffer, size 29988, start 29988
    [    0.765112] persistent_ram: found existing buffer, size 30105, start 30105
    [    0.769435] persistent_ram: found existing buffer, size 118542, start 118542
    [    0.785960] persistent_ram: found existing buffer, size 0, start 0
    [    0.786098] persistent_ram: found existing buffer, size 0, start 0
    [    0.786131] pstore: using zlib compression
    [    0.790716] BUG: spinlock bad magic on CPU#0, swapper/0/1
    [    0.790729]  lock: 0xffffffc0d1ca9bb0, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
    [    0.790742] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc2+ #913
    [    0.790747] Hardware name: Google Kevin (DT)
    [    0.790750] Call trace:
    [    0.790768] [<ffffff900808ae88>] dump_backtrace+0x0/0x2bc
    [    0.790780] [<ffffff900808b164>] show_stack+0x20/0x28
    [    0.790794] [<ffffff9008460ee0>] dump_stack+0xa4/0xcc
    [    0.790809] [<ffffff9008113cfc>] spin_dump+0xe0/0xf0
    [    0.790821] [<ffffff9008113d3c>] spin_bug+0x30/0x3c
    [    0.790834] [<ffffff9008113e28>] do_raw_spin_lock+0x50/0x1b8
    [    0.790846] [<ffffff9008a2d2ec>] _raw_spin_lock_irqsave+0x54/0x6c
    [    0.790862] [<ffffff90083ac3b4>] buffer_size_add+0x48/0xcc
    [    0.790875] [<ffffff90083acb34>] persistent_ram_write+0x60/0x11c
    [    0.790888] [<ffffff90083aab1c>] ramoops_pstore_write_buf+0xd4/0x2a4
    [    0.790900] [<ffffff90083a9d3c>] pstore_console_write+0xf0/0x134
    [    0.790912] [<ffffff900811c304>] console_unlock+0x48c/0x5e8
    [    0.790923] [<ffffff900811da18>] register_console+0x3b0/0x4d4
    [    0.790935] [<ffffff90083aa7d0>] pstore_register+0x1a8/0x234
    [    0.790947] [<ffffff90083ac250>] ramoops_probe+0x6b8/0x7d4
    [    0.790961] [<ffffff90085ca548>] platform_drv_probe+0x7c/0xd0
    [    0.790972] [<ffffff90085c76ac>] driver_probe_device+0x1b4/0x3bc
    [    0.790982] [<ffffff90085c7ac8>] __device_attach_driver+0xc8/0xf4
    [    0.790996] [<ffffff90085c4bfc>] bus_for_each_drv+0xb4/0xe4
    [    0.791006] [<ffffff90085c7414>] __device_attach+0xd0/0x158
    [    0.791016] [<ffffff90085c7b18>] device_initial_probe+0x24/0x30
    [    0.791026] [<ffffff90085c648c>] bus_probe_device+0x50/0xe4
    [    0.791038] [<ffffff90085c35b8>] device_add+0x3a4/0x76c
    [    0.791051] [<ffffff90087d0e84>] of_device_add+0x74/0x84
    [    0.791062] [<ffffff90087d19b8>] of_platform_device_create_pdata+0xc0/0x100
    [    0.791073] [<ffffff90087d1a2c>] of_platform_device_create+0x34/0x40
    [    0.791086] [<ffffff900903c910>] of_platform_default_populate_init+0x58/0x78
    [    0.791097] [<ffffff90080831fc>] do_one_initcall+0x88/0x160
    [    0.791109] [<ffffff90090010ac>] kernel_init_freeable+0x264/0x31c
    [    0.791123] [<ffffff9008a25bd0>] kernel_init+0x18/0x11c
    [    0.791133] [<ffffff9008082ec0>] ret_from_fork+0x10/0x50
    [    0.793717] console [pstore-1] enabled
    [    0.797845] pstore: Registered ramoops as persistent store backend
    [    0.804647] ramoops: attached 0x100000@0xf7edc000, ecc: 0/0
    
    Fixes: 663deb47880f ("pstore: Allow prz to control need for locking")
    Fixes: 109704492ef6 ("pstore: Make spinlock per zone instead of global")
    Reported-by: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4693080316e671580459875723795fdb805a6cf4
Author: Joel Fernandes <joelaf@google.com>
Date:   Thu Oct 20 00:34:01 2016 -0700

    pstore: Allow prz to control need for locking
    
    commit 663deb47880f2283809669563c5a52ac7c6aef1a upstream.
    
    In preparation of not locking at all for certain buffers depending on if
    there's contention, make locking optional depending on the initialization
    of the prz.
    
    Signed-off-by: Joel Fernandes <joelaf@google.com>
    [kees: moved locking flag into prz instead of via caller arguments]
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5463a3dccf10204577b8c1c170ca66efa7b65e3e
Author: Andrzej Hajda <a.hajda@samsung.com>
Date:   Thu Jan 5 10:34:07 2017 -0200

    v4l: s5c73m3: fix negation operator
    
    commit a2370ba2752538404e363346b339869c9973aeac upstream.
    
    Bool values should be negated using logical operators. Using bitwise operators
    results in unexpected and possibly incorrect results.
    
    Reported-by: David Binderman <dcb314@hotmail.com>
    Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad25f11ed216d5ce3b5566b2f187b59fa3061b40
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Jul 7 14:51:19 2017 -0400

    dentry name snapshots
    
    commit 49d31c2f389acfe83417083e1208422b4091cd9e upstream.
    
    take_dentry_name_snapshot() takes a safe snapshot of dentry name;
    if the name is a short one, it gets copied into caller-supplied
    structure, otherwise an extra reference to external name is grabbed
    (those are never modified).  In either case the pointer to stable
    string is stored into the same structure.
    
    dentry must be held by the caller of take_dentry_name_snapshot(),
    but may be freely dropped afterwards - the snapshot will stay
    until destroyed by release_dentry_name_snapshot().
    
    Intended use:
            struct name_snapshot s;
    
            take_dentry_name_snapshot(&s, dentry);
            ...
            access s.name
            ...
            release_dentry_name_snapshot(&s);
    
    Replaces fsnotify_oldname_...(), gets used in fsnotify to obtain the name
    to pass down with event.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d933777b1b1b15c61bb464f715afdc249606ac00
Author: Valentin Vidic <Valentin.Vidic@CARNet.hr>
Date:   Fri May 5 21:07:33 2017 +0200

    ipmi/watchdog: fix watchdog timeout set on reboot
    
    commit 860f01e96981a68553f3ca49f574ff14fe955e72 upstream.
    
    systemd by default starts watchdog on reboot and sets the timer to
    ShutdownWatchdogSec=10min.  Reboot handler in ipmi_watchdog than reduces
    the timer to 120s which is not enough time to boot a Xen machine with
    a lot of RAM.  As a result the machine is rebooted the second time
    during the long run of (XEN) Scrubbing Free RAM.....
    
    Fix this by setting the timer to 120s only if it was previously
    set to a low value.
    
    Signed-off-by: Valentin Vidic <Valentin.Vidic@CARNet.hr>
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 196553666dced915c535ee6fb6cacd98ad80cdff
Author: Ismail, Mustafa <mustafa.ismail@intel.com>
Date:   Fri Jul 14 09:41:30 2017 -0500

    RDMA/uverbs: Fix the check for port number
    
    commit 5a7a88f1b488e4ee49eb3d5b82612d4d9ffdf2c3 upstream.
    
    The port number is only valid if IB_QP_PORT is set in the mask.
    So only check port number if it is valid to prevent modify_qp from
    failing due to an invalid port number.
    
    Fixes: 5ecce4c9b17b("Check port number supplied by user verbs cmds")
    Reviewed-by: Steve Wise <swise@opengridcomputing.com>
    Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com>
    Tested-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62b5776c8c86bc91acf7693a00d1ca82d3aa6a9c
Author: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date:   Wed Feb 8 14:27:27 2017 +0300

    sched/cgroup: Move sched_online_group() back into css_online() to fix crash
    
    commit 96b777452d8881480fd5be50112f791c17db4b6b upstream.
    
    Commit:
    
      2f5177f0fd7e ("sched/cgroup: Fix/cleanup cgroup teardown/init")
    
    .. moved sched_online_group() from css_online() to css_alloc().
    It exposes half-baked task group into global lists before initializing
    generic cgroup stuff.
    
    LTP testcase (third in cgroup_regression_test) written for testing
    similar race in kernels 2.6.26-2.6.28 easily triggers this oops:
    
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      IP: kernfs_path_from_node_locked+0x260/0x320
      CPU: 1 PID: 30346 Comm: cat Not tainted 4.10.0-rc5-test #4
      Call Trace:
      ? kernfs_path_from_node+0x4f/0x60
      kernfs_path_from_node+0x3e/0x60
      print_rt_rq+0x44/0x2b0
      print_rt_stats+0x7a/0xd0
      print_cpu+0x2fc/0xe80
      ? __might_sleep+0x4a/0x80
      sched_debug_show+0x17/0x30
      seq_read+0xf2/0x3b0
      proc_reg_read+0x42/0x70
      __vfs_read+0x28/0x130
      ? security_file_permission+0x9b/0xc0
      ? rw_verify_area+0x4e/0xb0
      vfs_read+0xa5/0x170
      SyS_read+0x46/0xa0
      entry_SYSCALL_64_fastpath+0x1e/0xad
    
    Here the task group is already linked into the global RCU-protected 'task_groups'
    list, but the css->cgroup pointer is still NULL.
    
    This patch reverts this chunk and moves online back to css_online().
    
    Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Fixes: 2f5177f0fd7e ("sched/cgroup: Fix/cleanup cgroup teardown/init")
    Link: http://lkml.kernel.org/r/148655324740.424917.5302984537258726349.stgit@buzz
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 016a638a518c828719147e2f2d9cd9a0941fe6dd
Author: Sudeep Holla <sudeep.holla@arm.com>
Date:   Tue Mar 21 11:30:16 2017 +0000

    mailbox: handle empty message in tx_tick
    
    commit cb710ab1d8a23f68ff8f45aedf3e552bb90e70de upstream.
    
    We already check if the message is empty before calling the client
    tx_done callback. Calling completion on a wait event is also invalid
    if the message is empty.
    
    This patch moves the existing empty message check earlier.
    
    Fixes: 2b6d83e2b8b7 ("mailbox: Introduce framework for mailbox")
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit abe9090ac07b1294c88686336ea881e833312a9e
Author: Sudeep Holla <sudeep.holla@arm.com>
Date:   Tue Mar 21 11:30:15 2017 +0000

    mailbox: skip complete wait event if timer expired
    
    commit cc6eeaa3029a6dbcb4ad41b1f92876483bd88965 upstream.
    
    If a wait_for_completion_timeout() call returns due to a timeout,
    complete() can get called after returning from the wait which is
    incorrect and can cause subsequent transmissions on a channel to fail.
    Since the wait_for_completion_timeout() sees the completion variable
    is non-zero caused by the erroneous/spurious complete() call, and
    it immediately returns without waiting for the time as expected by the
    client.
    
    This patch fixes the issue by skipping complete() call for the timer
    expiry.
    
    Fixes: 2b6d83e2b8b7 ("mailbox: Introduce framework for mailbox")
    Reported-by: Alexey Klimov <alexey.klimov@arm.com>
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a23fba8182039d7162d6b19c9030a414f43f7f62
Author: Sudeep Holla <sudeep.holla@arm.com>
Date:   Tue Mar 21 11:30:14 2017 +0000

    mailbox: always wait in mbox_send_message for blocking Tx mode
    
    commit c61b781ee084e69855477d23dd33e7e6caad652c upstream.
    
    There exists a race when msg_submit return immediately as there was an
    active request being processed which may have completed just before it's
    checked again in mbox_send_message. This will result in return to the
    caller without waiting in mbox_send_message even when it's blocking Tx.
    
    This patch fixes the issue by waiting for the completion always if Tx
    is in blocking mode.
    
    Fixes: 2b6d83e2b8b7 ("mailbox: Introduce framework for mailbox")
    Reported-by: Alexey Klimov <alexey.klimov@arm.com>
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Reviewed-by: Alexey Klimov <alexey.klimov@arm.com>
    Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f16bcd4dba9980a1d237b0fa0c697aa7547c2d6
Author: Lior David <qca_liord@qca.qualcomm.com>
Date:   Wed Nov 23 16:06:41 2016 +0200

    wil6210: fix deadlock when using fw_no_recovery option
    
    commit dfb5b098e0f40b68aa07f2ec55f4dd762efefbfa upstream.
    
    When FW crashes with no_fw_recovery option, driver
    waits for manual recovery with wil->mutex held, this
    can easily create deadlocks.
    Fix the problem by moving the wait outside the lock.
    
    Signed-off-by: Lior David <qca_liord@qca.qualcomm.com>
    Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
    Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59153e6589366f09eb42b92c8bc8c2fce72fe8fe
Author: Michal Kazior <michal.kazior@tieto.com>
Date:   Mon Nov 14 14:25:23 2016 +0100

    ath10k: fix null deref on wmi-tlv when trying spectral scan
    
    commit 18ae68fff392e445af3c2d8be9bef8a16e1c72a7 upstream.
    
    WMI ops wrappers did not properly check for null
    function pointers for spectral scan. This caused
    null dereference crash with WMI-TLV based firmware
    which doesn't implement spectral scan.
    
    The crash could be triggered with:
    
      ip link set dev wlan0 up
      echo background > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
    
    The crash looked like this:
    
      [  168.031989] BUG: unable to handle kernel NULL pointer dereference at           (null)
      [  168.037406] IP: [<          (null)>]           (null)
      [  168.040395] PGD cdd4067 PUD fa0f067 PMD 0
      [  168.043303] Oops: 0010 [#1] SMP
      [  168.045377] Modules linked in: ath10k_pci(O) ath10k_core(O) ath mac80211 cfg80211 [last unloaded: cfg80211]
      [  168.051560] CPU: 1 PID: 1380 Comm: bash Tainted: G        W  O    4.8.0 #78
      [  168.054336] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
      [  168.059183] task: ffff88000c460c00 task.stack: ffff88000d4bc000
      [  168.061736] RIP: 0010:[<0000000000000000>]  [<          (null)>]           (null)
      ...
      [  168.100620] Call Trace:
      [  168.101910]  [<ffffffffa03b9566>] ? ath10k_spectral_scan_config+0x96/0x200 [ath10k_core]
      [  168.104871]  [<ffffffff811386e2>] ? filemap_fault+0xb2/0x4a0
      [  168.106696]  [<ffffffffa03b97e6>] write_file_spec_scan_ctl+0x116/0x280 [ath10k_core]
      [  168.109618]  [<ffffffff812da3a1>] full_proxy_write+0x51/0x80
      [  168.111443]  [<ffffffff811957b8>] __vfs_write+0x28/0x120
      [  168.113090]  [<ffffffff812f1a2d>] ? security_file_permission+0x3d/0xc0
      [  168.114932]  [<ffffffff8109b912>] ? percpu_down_read+0x12/0x60
      [  168.116680]  [<ffffffff811965f8>] vfs_write+0xb8/0x1a0
      [  168.118293]  [<ffffffff81197966>] SyS_write+0x46/0xa0
      [  168.119912]  [<ffffffff818f2972>] entry_SYSCALL_64_fastpath+0x1a/0xa4
      [  168.121737] Code:  Bad RIP value.
      [  168.123318] RIP  [<          (null)>]           (null)
    
    Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
    Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b3a66739ff01fcd9b8007a18ddd29edd2cb74f7
Author: Annie Cherkaev <annie.cherk@gmail.com>
Date:   Sat Jul 15 15:08:58 2017 -0600

    isdn/i4l: fix buffer overflow
    
    commit 9f5af546e6acc30f075828cb58c7f09665033967 upstream.
    
    This fixes a potential buffer overflow in isdn_net.c caused by an
    unbounded strcpy.
    
    [ ISDN seems to be effectively unmaintained, and the I4L driver in
      particular is long deprecated, but in case somebody uses this..
        - Linus ]
    
    Signed-off-by: Jiten Thakkar <jitenmt@gmail.com>
    Signed-off-by: Annie Cherkaev <annie.cherk@gmail.com>
    Cc: Karsten Keil <isdn@linux-pingi.de>
    Cc: Kees Cook <keescook@chromium.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b756862459d2b8a977538e5f61345e3633c51d0f
Author: Jia-Ju Bai <baijiaju1990@163.com>
Date:   Wed May 31 09:40:11 2017 +0800

    isdn: Fix a sleep-in-atomic bug
    
    commit e8f4ae85439f34bec3b0ab69223a41809dab28c9 upstream.
    
    The driver may sleep under a spin lock, the function call path is:
    isdn_ppp_mp_receive (acquire the lock)
      isdn_ppp_mp_reassembly
        isdn_ppp_push_higher
          isdn_ppp_decompress
            isdn_ppp_ccp_reset_trans
              isdn_ppp_ccp_reset_alloc_state
                kzalloc(GFP_KERNEL) --> may sleep
    
    To fixed it, the "GFP_KERNEL" is replaced with "GFP_ATOMIC".
    
    Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c78197e4a69c19e61dfe904fdc661b2aee8ec20
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Sun Mar 5 12:34:49 2017 -0800

    net: phy: Do not perform software reset for Generic PHY
    
    commit 0878fff1f42c18e448ab5b8b4f6a3eb32365b5b6 upstream.
    
    The Generic PHY driver is a catch-all PHY driver and it should preserve
    whatever prior initialization has been done by boot loader or firmware
    agents. For specific PHY device configuration it is expected that a
    specialized PHY driver would take over that role.
    
    Resetting the generic PHY was a bad idea that has lead to several
    complaints and downstream workarounds e.g: in OpenWrt/LEDE so restore
    the behavior prior to 87aa9f9c61ad ("net: phy: consolidate PHY
    reset in phy_init_hw()").
    
    Reported-by: Felix Fietkau <nbd@nbd.name>
    Fixes: 87aa9f9c61ad ("net: phy: consolidate PHY reset in phy_init_hw()")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 57154f0302cd39a7ff5f3f4ceef23bda4112c77e
Author: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Date:   Tue Dec 20 21:09:04 2016 +0000

    nfc: fdp: fix NULL pointer dereference
    
    commit b6355fb3f5f40bbce165847d277e64896cab8f95 upstream.
    
    We are checking phy after dereferencing it. We can print the debug
    information after checking it. If phy is NULL then we will get a good
    stack trace to tell us that we are in this irq handler.
    
    Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35bdf9a61dc9bd8e47f988b729e038a1ac8b7c9d
Author: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Date:   Sat Feb 4 10:16:56 2017 +0900

    nfc: Fix hangup of RC-S380* in port100_send_ack()
    
    commit 2497128133f8169b24b928852ba6eae34fc495e5 upstream.
    
    If port100_send_ack() was called twice or more, it has race to hangup.
    
      port100_send_ack()          port100_send_ack()
        init_completion()
        [...]
        dev->cmd_cancel = true
                                    /* this removes previous from completion */
                                    init_completion()
                                    [...]
                                    dev->cmd_cancel = true
                                    wait_for_completion()
        /* never be waked up */
        wait_for_completion()
    
    Like above race, this code is not assuming port100_send_ack() is
    called twice or more.
    
    To fix, this checks dev->cmd_cancel to know if prior cancel is
    in-flight or not. And never be remove prior task from completion by
    using reinit_completion(), so this guarantees to be waked up properly
    soon or later.
    
    Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b3d13fe67da15aca3186c11c016b6abd00f0469
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Jul 11 22:06:24 2017 +0200

    smp/hotplug: Replace BUG_ON and react useful
    
    commit dea1d0f5f1284e3defee4b8484d9fc230686cd42 upstream.
    
    The move of the unpark functions to the control thread moved the BUG_ON()
    there as well. While it made some sense in the idle thread of the upcoming
    CPU, it's bogus to crash the control thread on the already online CPU,
    especially as the function has a return value and the callsite is prepared
    to handle an error return.
    
    Replace it with a WARN_ON_ONCE() and return a proper error code.
    
    Fixes: 9cd4f1a4e7a8 ("smp/hotplug: Move unparking of percpu threads to the control CPU")
    Rightfully-ranted-at-by: Linux Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b4e4b18ea64f95a8502199e792cbe75297c66ef
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Jul 4 22:20:23 2017 +0200

    smp/hotplug: Move unparking of percpu threads to the control CPU
    
    commit 9cd4f1a4e7a858849e889a081a99adff83e08e4c upstream.
    
    Vikram reported the following backtrace:
    
       BUG: scheduling while atomic: swapper/7/0/0x00000002
       CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.32-perf+ #680
       schedule
       schedule_hrtimeout_range_clock
       schedule_hrtimeout
       wait_task_inactive
       __kthread_bind_mask
       __kthread_bind
       __kthread_unpark
       kthread_unpark
       cpuhp_online_idle
       cpu_startup_entry
       secondary_start_kernel
    
    He analyzed correctly that a parked cpu hotplug thread of an offlined CPU
    was still on the runqueue when the CPU came back online and tried to unpark
    it. This causes the thread which invoked kthread_unpark() to call
    wait_task_inactive() and subsequently schedule() with preemption disabled.
    His proposed workaround was to "make sure" that a parked thread has
    scheduled out when the CPU goes offline, so the situation cannot happen.
    
    But that's still wrong because the root cause is not the fact that the
    percpu thread is still on the runqueue and neither that preemption is
    disabled, which could be simply solved by enabling preemption before
    calling kthread_unpark().
    
    The real issue is that the calling thread is the idle task of the upcoming
    CPU, which is not supposed to call anything which might sleep.  The moron,
    who wrote that code, missed completely that kthread_unpark() might end up
    in schedule().
    
    The solution is simpler than expected. The thread which controls the
    hotplug operation is waiting for the CPU to call complete() on the hotplug
    state completion. So the idle task of the upcoming CPU can set its state to
    CPUHP_AP_ONLINE_IDLE and invoke complete(). This in turn wakes the control
    task on a different CPU, which then can safely do the unpark and kick the
    now unparked hotplug thread of the upcoming CPU to complete the bringup to
    the final target state.
    
    Control CPU                     AP
    
    bringup_cpu();
      __cpu_up()  ------------>
                                    bringup_ap();
      bringup_wait_for_ap()
        wait_for_completion();
                                    cpuhp_online_idle();
                    <------------    complete();
        unpark(AP->stopper);
        unpark(AP->hotplugthread);
                                    while(1)
                                      do_idle();
        kick(AP->hotplugthread);
        wait_for_completion();      hotplug_thread()
                                      run_online_callbacks();
                                      complete();
    
    Fixes: 8df3e07e7f21 ("cpu/hotplug: Let upcoming cpu bring itself fully up")
    Reported-by: Vikram Mulukutla <markivx@codeaurora.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Sebastian Sewior <bigeasy@linutronix.de>
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1707042218020.2131@nanos
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 755f65501f704219eab609601c9fa043f2131fb9
Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Date:   Wed Oct 19 00:51:35 2016 +0300

    drm: rcar-du: Simplify and fix probe error handling
    
    commit 4f7b0d263833928e947e172eff2d2997179c5cb9 upstream.
    
    It isn't safe to call drm_dev_unregister() without first initializing
    mode setting with drm_mode_config_init(). This leads to a crash if
    either IO memory can't be remapped or vblank initialization fails.
    
    Fix this by reordering the initialization sequence. Move vblank
    initialization after the drm_mode_config_init() call, and move IO
    remapping before drm_dev_alloc() to avoid the need to perform clean up
    in case of failure.
    
    While at it remove the explicit drm_vblank_cleanup() call from
    rcar_du_remove() as the drm_dev_unregister() function already cleans up
    vblank.
    
    Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Signed-off-by: thongsyho <thong.ho.px@rvc.renesas.com>
    Signed-off-by: Nhan Nguyen <nhan.nguyen.yb@renesas.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9bf0d78bf640c95a3e9e7e1eeb9e0596a651bbe7
Author: Cheah Kok Cheong <thrust73@gmail.com>
Date:   Fri Dec 30 19:25:52 2016 +0800

    Staging: comedi: comedi_fops: Avoid orphaned proc entry
    
    commit bf279ece37d2a3eaaa9813fcd7a1d8a81eb29c20 upstream.
    
    Move comedi_proc_init to the end to avoid orphaned proc entry
    if module loading failed.
    
    Signed-off-by: Cheah Kok Cheong <thrust73@gmail.com>
    Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f31691508c64a139da303f17b31ed3dcbf63de1
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Aug 3 12:26:04 2017 -0700

    Revert "powerpc/numa: Fix percpu allocations to be NUMA aware"
    
    This reverts commit b4624ff952ec7d268a9651cd9184a1995befc271 which is
    commit ba4a648f12f4cd0a8003dd229b6ca8a53348ee4b upstream.
    
    Michal Hocko writes:
    
    JFYI. We have encountered a regression after applying this patch on a
    large ppc machine. While the patch is the right thing to do it doesn't
    work well with the current vmalloc area size on ppc and large machines
    where NUMA nodes are very far from each other. Just for the reference
    the boot fails on such a machine with bunch of warning preceeding it.
    See http://lkml.kernel.org/r/20170724134240.GL25221@dhcp22.suse.cz
    
    It seems the right thing to do is to enlarge the vmalloc space on ppc
    but this is not the case in the upstream kernel yet AFAIK. It is also
    questionable whether that is a stable material but I will decision on
    you here.
    
    We have reverted this patch from our 4.4 based kernel.
    
    Newer kernels do not have enlarged vmalloc space yet AFAIK so they won't
    work properly eiter. This bug is quite rare though because you need a
    specific HW configuration to trigger the issue - namely NUMA nodes have
    to be far away from each other in the physical memory space.
    
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c39c3aeb2b417f0f12ab729f9631d9f90cd830f3
Author: Paul Mackerras <paulus@ozlabs.org>
Date:   Fri Jun 16 11:53:19 2017 +1000

    KVM: PPC: Book3S HV: Save/restore host values of debug registers
    
    commit 7ceaa6dcd8c6f59588428cec37f3c8093dd1011f upstream.
    
    At present, HV KVM on POWER8 and POWER9 machines loses any instruction
    or data breakpoint set in the host whenever a guest is run.
    Instruction breakpoints are currently only used by xmon, but ptrace
    and the perf_event subsystem can set data breakpoints as well as xmon.
    
    To fix this, we save the host values of the debug registers (CIABR,
    DAWR and DAWRX) before entering the guest and restore them on exit.
    To provide space to save them in the stack frame, we expand the stack
    frame allocated by kvmppc_hv_entry() from 112 to 144 bytes.
    
    [paulus@ozlabs.org - Adjusted stack offsets since we aren't saving
     POWER9-specific registers.]
    
    Fixes: b005255e12a3 ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs", 2014-01-08)
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5cd34d10459e20a78514efcd7a45cfc370743c2
Author: Paul Mackerras <paulus@ozlabs.org>
Date:   Thu Jun 15 15:43:17 2017 +1000

    KVM: PPC: Book3S HV: Restore critical SPRs to host values on guest exit
    
    commit 4c3bb4ccd074e1a0552078c0bf94c662367a1658 upstream.
    
    This restores several special-purpose registers (SPRs) to sane values
    on guest exit that were missed before.
    
    TAR and VRSAVE are readable and writable by userspace, and we need to
    save and restore them to prevent the guest from potentially affecting
    userspace execution (not that TAR or VRSAVE are used by any known
    program that run uses the KVM_RUN ioctl).  We save/restore these
    in kvmppc_vcpu_run_hv() rather than on every guest entry/exit.
    
    FSCR affects userspace execution in that it can prohibit access to
    certain facilities by userspace.  We restore it to the normal value
    for the task on exit from the KVM_RUN ioctl.
    
    IAMR is normally 0, and is restored to 0 on guest exit.  However,
    with a radix host on POWER9, it is set to a value that prevents the
    kernel from executing user-accessible memory.  On POWER9, we save
    IAMR on guest entry and restore it on guest exit to the saved value
    rather than 0.  On POWER8 we continue to set it to 0 on guest exit.
    
    PSPB is normally 0.  We restore it to 0 on guest exit to prevent
    userspace taking advantage of the guest having set it non-zero
    (which would allow userspace to set its SMT priority to high).
    
    UAMOR is normally 0.  We restore it to 0 on guest exit to prevent
    the AMR from being used as a covert channel between userspace
    processes, since the AMR is not context-switched at present.
    
    [paulus@ozlabs.org - removed IAMR bits that are only needed on POWER9]
    
    Fixes: b005255e12a3 ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs", 2014-01-08)
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae8faca6e2e727105f8ed485783ea25a25a425ee
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Tue Jul 25 11:06:47 2017 +1000

    drm/nouveau/bar/gf100: fix access to upper half of BAR2
    
    commit 38bcb208f60924a031b9f809f7cd252ea4a94e5f upstream.
    
    Bit 30 being set causes the upper half of BAR2 to stay in physical mode,
    mapped over the end of VRAM, even when the rest of the BAR has been set
    to virtual mode.
    
    We inherited our initial value from RM, but I'm not aware of any reason
    we need to keep it that way.
    
    This fixes severe GPU hang/lockup issues revealed by Wayland on F26.
    
    Shout-out to NVIDIA for the quick response with the potential cause!
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34da5f74eb5caf1ae3873463aa5e2b801fa450c3
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date:   Wed Jun 28 08:24:45 2017 -0400

    drm/nouveau/disp/nv50-: bump max chans to 21
    
    commit a90e049cacd965dade4dae7263b4d3fd550e78b6 upstream.
    
    GP102's cursors go from chan 17..20. Increase the array size to hold
    their data properly.
    
    Fixes: e50fcff15f ("drm/nouveau/disp/gp102: fix cursor/overlay immediate channel indices")
    Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e41779886b90cf928cdc3e790dd31104fdab00fa
Author: Sinclair Yeh <syeh@vmware.com>
Date:   Mon Jul 17 23:28:36 2017 -0700

    drm/vmwgfx: Fix gcc-7.1.1 warning
    
    commit fcfffdd8f98ac305285dca568b5065ef86be6458 upstream.
    
    The current code does not look correct, and the reason for it is
    probably lost.  Since this now generates a compiler warning,
    fix it to what makes sense.
    
    Reported-by: Arnd Bergmann <arnd@arndb.de>
    Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sinclair Yeh <syeh@vmware.com>
    Reviewed-by: Brian Paul <brianp@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fabc7dffe9e123e5be2456139853a7e12c5adce8
Author: Ofer Heifetz <oferh@marvell.com>
Date:   Mon Jul 24 09:17:40 2017 +0300

    md/raid5: add thread_group worker async_tx_issue_pending_all
    
    commit 7e96d559634b73a8158ee99a7abece2eacec2668 upstream.
    
    Since thread_group worker and raid5d kthread are not in sync, if
    worker writes stripe before raid5d then requests will be waiting
    for issue_pendig.
    
    Issue observed when building raid5 with ext4, in some build runs
    jbd2 would get hung and requests were waiting in the HW engine
    waiting to be issued.
    
    Fix this by adding a call to async_tx_issue_pending_all in the
    raid5_do_work.
    
    Signed-off-by: Ofer Heifetz <oferh@marvell.com>
    Signed-off-by: Shaohua Li <shli@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d745f0f67b70afafd4d5f300ec422dae26bbd938
Author: Paul Mackerras <paulus@ozlabs.org>
Date:   Fri Jul 21 13:57:14 2017 +1000

    KVM: PPC: Book3S HV: Enable TM before accessing TM registers
    
    commit e47057151422a67ce08747176fa21cb3b526a2c9 upstream.
    
    Commit 46a704f8409f ("KVM: PPC: Book3S HV: Preserve userspace HTM state
    properly", 2017-06-15) added code to read transactional memory (TM)
    registers but forgot to enable TM before doing so.  The result is
    that if userspace does have live values in the TM registers, a KVM_RUN
    ioctl will cause a host kernel crash like this:
    
    [  181.328511] Unrecoverable TM Unavailable Exception f60 at d00000001e7d9980
    [  181.328605] Oops: Unrecoverable TM Unavailable Exception, sig: 6 [#1]
    [  181.328613] SMP NR_CPUS=2048
    [  181.328613] NUMA
    [  181.328618] PowerNV
    [  181.328646] Modules linked in: vhost_net vhost tap nfs_layout_nfsv41_files rpcsec_gss_krb5 nfsv4 dns_resolver nfs
    +fscache xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat
    +nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 tun ebtable_filter ebtables
    +ip6table_filter ip6_tables iptable_filter bridge stp llc kvm_hv kvm nfsd ses enclosure scsi_transport_sas ghash_generic
    +auth_rpcgss gf128mul xts sg ctr nfs_acl lockd vmx_crypto shpchp ipmi_powernv i2c_opal grace ipmi_devintf i2c_core
    +powernv_rng sunrpc ipmi_msghandler ibmpowernv uio_pdrv_genirq uio leds_powernv powernv_op_panel ip_tables xfs sd_mod
    +lpfc ipr bnx2x libata mdio ptp pps_core scsi_transport_fc libcrc32c dm_mirror dm_region_hash dm_log dm_mod
    [  181.329278] CPU: 40 PID: 9926 Comm: CPU 0/KVM Not tainted 4.12.0+ #1
    [  181.329337] task: c000003fc6980000 task.stack: c000003fe4d80000
    [  181.329396] NIP: d00000001e7d9980 LR: d00000001e77381c CTR: d00000001e7d98f0
    [  181.329465] REGS: c000003fe4d837e0 TRAP: 0f60   Not tainted  (4.12.0+)
    [  181.329523] MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>
    [  181.329527]   CR: 24022448  XER: 00000000
    [  181.329608] CFAR: d00000001e773818 SOFTE: 1
    [  181.329608] GPR00: d00000001e77381c c000003fe4d83a60 d00000001e7ef410 c000003fdcfe0000
    [  181.329608] GPR04: c000003fe4f00000 0000000000000000 0000000000000000 c000003fd7954800
    [  181.329608] GPR08: 0000000000000001 c000003fc6980000 0000000000000000 d00000001e7e2880
    [  181.329608] GPR12: d00000001e7d98f0 c000000007b19000 00000001295220e0 00007fffc0ce2090
    [  181.329608] GPR16: 0000010011886608 00007fff8c89f260 0000000000000001 00007fff8c080028
    [  181.329608] GPR20: 0000000000000000 00000100118500a6 0000010011850000 0000010011850000
    [  181.329608] GPR24: 00007fffc0ce1b48 0000010011850000 00000000d673b901 0000000000000000
    [  181.329608] GPR28: 0000000000000000 c000003fdcfe0000 c000003fdcfe0000 c000003fe4f00000
    [  181.330199] NIP [d00000001e7d9980] kvmppc_vcpu_run_hv+0x90/0x6b0 [kvm_hv]
    [  181.330264] LR [d00000001e77381c] kvmppc_vcpu_run+0x2c/0x40 [kvm]
    [  181.330322] Call Trace:
    [  181.330351] [c000003fe4d83a60] [d00000001e773478] kvmppc_set_one_reg+0x48/0x340 [kvm] (unreliable)
    [  181.330437] [c000003fe4d83b30] [d00000001e77381c] kvmppc_vcpu_run+0x2c/0x40 [kvm]
    [  181.330513] [c000003fe4d83b50] [d00000001e7700b4] kvm_arch_vcpu_ioctl_run+0x114/0x2a0 [kvm]
    [  181.330586] [c000003fe4d83bd0] [d00000001e7642f8] kvm_vcpu_ioctl+0x598/0x7a0 [kvm]
    [  181.330658] [c000003fe4d83d40] [c0000000003451b8] do_vfs_ioctl+0xc8/0x8b0
    [  181.330717] [c000003fe4d83de0] [c000000000345a64] SyS_ioctl+0xc4/0x120
    [  181.330776] [c000003fe4d83e30] [c00000000000b004] system_call+0x58/0x6c
    [  181.330833] Instruction dump:
    [  181.330869] e92d0260 e9290b50 e9290108 792807e3 41820058 e92d0260 e9290b50 e9290108
    [  181.330941] 792ae8a4 794a1f87 408204f4 e92d0260 <7d4022a6> f9490ff0 e92d0260 7d4122a6
    [  181.331013] ---[ end trace 6f6ddeb4bfe92a92 ]---
    
    The fix is just to turn on the TM bit in the MSR before accessing the
    registers.
    
    Fixes: 46a704f8409f ("KVM: PPC: Book3S HV: Preserve userspace HTM state properly")
    Reported-by: Jan Stancek <jstancek@redhat.com>
    Tested-by: Jan Stancek <jstancek@redhat.com>
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9eb088e57edd9aa38e7d7a6c86424b4e6d5400eb
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Mon Jul 17 15:32:30 2017 +0800

    crypto: authencesn - Fix digest_null crash
    
    commit 41cdf7a45389e01991ee31e3301ed83cb3e3f7dc upstream.
    
    When authencesn is used together with digest_null a crash will
    occur on the decrypt path.  This is because normally we perform
    a special setup to preserve the ESN, but this is skipped if there
    is no authentication.  However, on the post-authentication path
    it always expects the preservation to be in place, thus causing
    a crash when digest_null is used.
    
    This patch fixes this by also skipping the post-processing when
    there is no authentication.
    
    Fixes: 104880a6b470 ("crypto: authencesn - Convert to new AEAD...")
    Reported-by: Jan Tluka <jtluka@redhat.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d2a354861e9257824a201d39a11e6a4d2a60cb4
Author: Benjamin Coddington <bcodding@redhat.com>
Date:   Fri Jul 28 12:33:54 2017 -0400

    NFSv4.1: Fix a race where CB_NOTIFY_LOCK fails to wake a waiter
    
    commit b7dbcc0e433f0f61acb89ed9861ec996be4f2b38 upstream.
    
    nfs4_retry_setlk() sets the task's state to TASK_INTERRUPTIBLE within the
    same region protected by the wait_queue's lock after checking for a
    notification from CB_NOTIFY_LOCK callback.  However, after releasing that
    lock, a wakeup for that task may race in before the call to
    freezable_schedule_timeout_interruptible() and set TASK_WAKING, then
    freezable_schedule_timeout_interruptible() will set the state back to
    TASK_INTERRUPTIBLE before the task will sleep.  The result is that the task
    will sleep for the entire duration of the timeout.
    
    Since we've already set TASK_INTERRUPTIBLE in the locked section, just use
    freezable_schedule_timout() instead.
    
    Fixes: a1d617d8f134 ("nfs: allow blocking locks to be awoken by lock callbacks")
    Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
    Reviewed-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b087b8b11e52f3ae9278d01f62db7cddb7236fee
Author: NeilBrown <neilb@suse.com>
Date:   Mon Jul 24 13:18:50 2017 +1000

    NFS: invalidate file size when taking a lock.
    
    commit 442ce0499c0535f8972b68fa1fda357357a5c953 upstream.
    
    Prior to commit ca0daa277aca ("NFS: Cache aggressively when file is open
    for writing"), NFS would revalidate, or invalidate, the file size when
    taking a lock.  Since that commit it only invalidates the file content.
    
    If the file size is changed on the server while wait for the lock, the
    client will have an incorrect understanding of the file size and could
    corrupt data.  This particularly happens when writing beyond the
    (supposed) end of file and can be easily be demonstrated with
    posix_fallocate().
    
    If an application opens an empty file, waits for a write lock, and then
    calls posix_fallocate(), glibc will determine that the underlying
    filesystem doesn't support fallocate (assuming version 4.1 or earlier)
    and will write out a '0' byte at the end of each 4K page in the region
    being fallocated that is after the end of the file.
    NFS will (usually) detect that these writes are beyond EOF and will
    expand them to cover the whole page, and then will merge the pages.
    Consequently, NFS will write out large blocks of zeroes beyond where it
    thought EOF was.  If EOF had moved, the pre-existing part of the file
    will be over-written.  Locking should have protected against this,
    but it doesn't.
    
    This patch restores the use of nfs_zap_caches() which invalidated the
    cached attributes.  When posix_fallocate() asks for the file size, the
    request will go to the server and get a correct answer.
    
    Fixes: ca0daa277aca ("NFS: Cache aggressively when file is open for writing")
    Signed-off-by: NeilBrown <neilb@suse.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d3d93ca2ef8ae97f68f1aa03ec5b826a7f29f1e
Author: Laurent Vivier <lvivier@redhat.com>
Date:   Fri Jul 21 16:51:39 2017 +0200

    powerpc/pseries: Fix of_node_put() underflow during reconfig remove
    
    commit 4fd1bd443e80b12f0a01a45fb9a793206b41cb72 upstream.
    
    As for commit 68baf692c435 ("powerpc/pseries: Fix of_node_put()
    underflow during DLPAR remove"), the call to of_node_put() must be
    removed from pSeries_reconfig_remove_node().
    
    dlpar_detach_node() and pSeries_reconfig_remove_node() both call
    of_detach_node(), and thus the node should not be released in both
    cases.
    
    Fixes: 0829f6d1f69e ("of: device_node kobject lifecycle fixes")
    Signed-off-by: Laurent Vivier <lvivier@redhat.com>
    Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa2aa76efe7d07b8920defea92072bf1df2df7b1
Author: Helge Deller <deller@gmx.de>
Date:   Tue Jul 25 21:41:41 2017 +0200

    parisc: Suspend lockup detectors before system halt
    
    commit 56188832a50f09998cb570ba3771a1d25c193c0e upstream.
    
    Some machines can't power off the machine, so disable the lockup detectors to
    avoid this watchdog BUG to show up every few seconds:
    watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [systemd-shutdow:1]
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f0d23fa632430cee981ea2b662b52c62915fc9bc
Author: John David Anglin <dave.anglin@bell.net>
Date:   Tue Jul 25 17:23:35 2017 -0400

    parisc: Extend disabled preemption in copy_user_page
    
    commit 56008c04ebc099940021b714da2d7779117cf6a7 upstream.
    
    It's always bothered me that we only disable preemption in
    copy_user_page around the call to flush_dcache_page_asm.
    This patch extends this to after the copy.
    
    Signed-off-by: John David Anglin <dave.anglin@bell.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit afe9fc012bc1ba720d83959af3918de501fda3d5
Author: John David Anglin <dave.anglin@bell.net>
Date:   Tue Jul 25 17:11:26 2017 -0400

    parisc: Prevent TLB speculation on flushed pages on CPUs that only support equivalent aliases
    
    commit ae7a609c34b6fb12328c553b5f9aab26ae74a28e upstream.
    
    Helge noticed that we flush the TLB page in flush_cache_page but not in
    flush_cache_range or flush_cache_mm.
    
    For a long time, we have had random segmentation faults building
    packages on machines with PA8800/8900 processors.  These machines only
    support equivalent aliases.  We don't see these faults on machines that
    don't require strict coherency.  So, it appears TLB speculation
    sometimes leads to cache corruption on machines that require coherency.
    
    This patch adds TLB flushes to flush_cache_range and flush_cache_mm when
    coherency is required.  We only flush the TLB in flush_cache_page when
    coherency is required.
    
    The patch also optimizes flush_cache_range.  It turns out we always have
    the right context to use flush_user_dcache_range_asm and
    flush_user_icache_range_asm.
    
    The patch has been tested for some time on rp3440, rp3410 and A500-44.
    It's been boot tested on c8000.  No random segmentation faults were
    observed during testing.
    
    Signed-off-by: John David Anglin <dave.anglin@bell.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f8bdd5edc82987b40db73e8af93c1f0b9e10048
Author: Daniel Dadap <ddadap@nvidia.com>
Date:   Thu Jul 13 19:27:39 2017 -0500

    ALSA: hda - Add missing NVIDIA GPU codec IDs to patch table
    
    commit 74ec118152ea494a25ebb677cbc83a75c982ac5f upstream.
    
    Add codec IDs for several recently released, pending, and historical
    NVIDIA GPU audio controllers to the patch table, to allow the correct
    patch functions to be selected for them.
    
    Signed-off-by: Daniel Dadap <ddadap@nvidia.com>
    Reviewed-by: Andy Ritger <aritger@nvidia.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d955095c597a6deac43ab2f388da12d11af7aee
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Sun Jul 16 21:40:03 2017 +0300

    ALSA: fm801: Initialize chip after IRQ handler is registered
    
    commit 610e1ae9b533be82b3aa118b907e0a703256913d upstream.
    
    The commit b56fa687e02b ("ALSA: fm801: detect FM-only card earlier")
    rearranged initialization calls, i.e. it makes snd_fm801_chip_init() to
    be called before we register interrupt handler and set PCI bus
    mastering.
    
    Somehow it prevents FM801-AU to work properly. Thus, partially revert
    initialization order changed by commit mentioned above.
    
    Fixes: b56fa687e02b ("ALSA: fm801: detect FM-only card earlier")
    Reported-by: Émeric MASCHINO <emeric.maschino@gmail.com>
    Tested-by: Émeric MASCHINO <emeric.maschino@gmail.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a79e1c8e709db0174dbafc5dcd9785e4bf36250
Author: Jan Kara <jack@suse.cz>
Date:   Thu Jun 22 15:31:10 2017 +0200

    jfs: Don't clear SGID when inheriting ACLs
    
    commit 9bcf66c72d726322441ec82962994e69157613e4 upstream.
    
    When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
    set, DIR1 is expected to have SGID bit set (and owning group equal to
    the owning group of 'DIR0'). However when 'DIR0' also has some default
    ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
    'DIR1' to get cleared if user is not member of the owning group.
    
    Fix the problem by moving posix_acl_update_mode() out of
    __jfs_set_acl() into jfs_set_acl(). That way the function will not be
    called when inheriting ACLs which is what we want as it prevents SGID
    bit clearing and the mode has been properly set by posix_acl_create()
    anyway.
    
    Fixes: 073931017b49d9458aa351605b43a7e34598caef
    CC: jfs-discussion@lists.sourceforge.net
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26d01aa8a110b9809d2bd138be42ee39ed4e3183
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jan 31 10:20:32 2017 -0800

    net: reduce skb_warn_bad_offload() noise
    
    commit b2504a5dbef3305ef41988ad270b0e8ec289331c upstream.
    
    Dmitry reported warnings occurring in __skb_gso_segment() [1]
    
    All SKB_GSO_DODGY producers can allow user space to feed
    packets that trigger the current check.
    
    We could prevent them from doing so, rejecting packets, but
    this might add regressions to existing programs.
    
    It turns out our SKB_GSO_DODGY handlers properly set up checksum
    information that is needed anyway when packets needs to be segmented.
    
    By checking again skb_needs_check() after skb_mac_gso_segment(),
    we should remove these pesky warnings, at a very minor cost.
    
    With help from Willem de Bruijn
    
    [1]
    WARNING: CPU: 1 PID: 6768 at net/core/dev.c:2439 skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434
    lo: caps=(0x000000a2803b7c69, 0x0000000000000000) len=138 data_len=0 gso_size=15883 gso_type=4 ip_summed=0
    Kernel panic - not syncing: panic_on_warn set ...
    
    CPU: 1 PID: 6768 Comm: syz-executor1 Not tainted 4.9.0 #5
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
     ffff8801c063ecd8 ffffffff82346bdf ffffffff00000001 1ffff100380c7d2e
     ffffed00380c7d26 0000000041b58ab3 ffffffff84b37e38 ffffffff823468f1
     ffffffff84820740 ffffffff84f289c0 dffffc0000000000 ffff8801c063ee20
    Call Trace:
     [<ffffffff82346bdf>] __dump_stack lib/dump_stack.c:15 [inline]
     [<ffffffff82346bdf>] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
     [<ffffffff81827e34>] panic+0x1fb/0x412 kernel/panic.c:179
     [<ffffffff8141f704>] __warn+0x1c4/0x1e0 kernel/panic.c:542
     [<ffffffff8141f7e5>] warn_slowpath_fmt+0xc5/0x100 kernel/panic.c:565
     [<ffffffff8356cbaf>] skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434
     [<ffffffff83585cd2>] __skb_gso_segment+0x482/0x780 net/core/dev.c:2706
     [<ffffffff83586f19>] skb_gso_segment include/linux/netdevice.h:3985 [inline]
     [<ffffffff83586f19>] validate_xmit_skb+0x5c9/0xc20 net/core/dev.c:2969
     [<ffffffff835892bb>] __dev_queue_xmit+0xe6b/0x1e70 net/core/dev.c:3383
     [<ffffffff8358a2d7>] dev_queue_xmit+0x17/0x20 net/core/dev.c:3424
     [<ffffffff83ad161d>] packet_snd net/packet/af_packet.c:2930 [inline]
     [<ffffffff83ad161d>] packet_sendmsg+0x32ed/0x4d30 net/packet/af_packet.c:2955
     [<ffffffff834f0aaa>] sock_sendmsg_nosec net/socket.c:621 [inline]
     [<ffffffff834f0aaa>] sock_sendmsg+0xca/0x110 net/socket.c:631
     [<ffffffff834f329a>] ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1954
     [<ffffffff834f5e58>] __sys_sendmsg+0x138/0x300 net/socket.c:1988
     [<ffffffff834f604d>] SYSC_sendmsg net/socket.c:1999 [inline]
     [<ffffffff834f604d>] SyS_sendmsg+0x2d/0x50 net/socket.c:1995
     [<ffffffff84371941>] entry_SYSCALL_64_fastpath+0x1f/0xc2
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Dmitry Vyukov  <dvyukov@google.com>
    Cc: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Mark Salyzyn <salyzyn@android.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d97aff4f9770582a14461ed57c0985a7288d3480
Author: Joel Fernandes <joelaf@google.com>
Date:   Thu Oct 20 00:34:00 2016 -0700

    pstore: Make spinlock per zone instead of global
    
    commit 109704492ef637956265ec2eb72ae7b3b39eb6f4 upstream.
    
    Currently pstore has a global spinlock for all zones. Since the zones
    are independent and modify different areas of memory, there's no need
    to have a global lock, so we should use a per-zone lock as introduced
    here. Also, when ramoops's ftrace use-case has a FTRACE_PER_CPU flag
    introduced later, which splits the ftrace memory area into a single zone
    per CPU, it will eliminate the need for locking. In preparation for this,
    make the locking optional.
    
    Signed-off-by: Joel Fernandes <joelaf@google.com>
    [kees: updated commit message]
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Cc: Leo Yan <leo.yan@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f94b36de37c73bdb3affe7352acac819082d360
Author: Yuejie Shi <syjcnss@gmail.com>
Date:   Fri Mar 31 15:10:20 2017 +0800

    af_key: Add lock to key dump
    
    commit 89e357d83c06b6fac581c3ca7f0ee3ae7e67109e upstream.
    
    A dump may come in the middle of another dump, modifying its dump
    structure members. This race condition will result in NULL pointer
    dereference in kernel. So add a lock to prevent that race.
    
    Fixes: 83321d6b9872 ("[AF_KEY]: Dump SA/SP entries non-atomically")
    Signed-off-by: Yuejie Shi <syjcnss@gmail.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Mark Salyzyn <salyzyn@android.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>