commit 7e1bdd68ffeecb9ef476f87b791b61910e8c853c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Jun 15 11:53:06 2019 +0200

    Linux 5.1.10

commit cf1fa8c91fbd1111782bac82cdd01b6330bfbbca
Author: Jens Axboe <axboe@kernel.dk>
Date:   Tue May 14 20:00:30 2019 -0600

    io_uring: fix failure to verify SQ_AFF cpu
    
    commit 44a9bd18a0f06bba19d155aeaa11e2edce898293 upstream.
    
    The test case we have is rightfully failing with the current kernel:
    
    io_uring_setup(1, 0x7ffe2cafebe0), flags: IORING_SETUP_SQPOLL|IORING_SETUP_SQ_AFF, resv: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000, sq_thread_cpu: 4
    expected -1, got 3
    
    This is in a vm, and CPU3 is the last valid one, hence asking for 4
    should fail the setup with -EINVAL, not succeed. The problem is that
    we're using array_index_nospec() with nr_cpu_ids as the index, hence we
    wrap and end up using CPU0 instead of CPU4. This makes the setup
    succeed where it should be failing.
    
    We don't need to use array_index_nospec() as we're not indexing any
    array with this. Instead just compare with nr_cpu_ids directly. This
    is fine as we're checking with cpu_online() afterwards.
    
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc9dcb27e9dfbddcb8e1627e509b4e4b637c4415
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Apr 12 11:37:19 2019 +0200

    ALSA: seq: Cover unsubscribe_port() in list_mutex
    
    commit 7c32ae35fbf9cffb7aa3736f44dec10c944ca18e upstream.
    
    The call of unsubscribe_port() which manages the group count and
    module refcount from delete_and_unsubscribe_port() looks racy; it's
    not covered by the group list lock, and it's likely a cause of the
    reported unbalance at port deletion.  Let's move the call inside the
    group list_mutex to plug the hole.
    
    Reported-by: syzbot+e4c8abb920efa77bace9@syzkaller.appspotmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f40c32fdfbf7c0ae98404b5b7203d2fc6bc9ad78
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Wed Feb 27 13:32:11 2019 +0200

    ovl: support stacked SEEK_HOLE/SEEK_DATA
    
    commit 9e46b840c7053b5f7a245e98cd239b60d189a96c upstream.
    
    Overlay file f_pos is the master copy that is preserved
    through copy up and modified on read/write, but only real
    fs knows how to SEEK_HOLE/SEEK_DATA and real fs may impose
    limitations that are more strict than ->s_maxbytes for specific
    files, so we use the real file to perform seeks.
    
    We do not call real fs for SEEK_CUR:0 query and for SEEK_SET:0
    requests.
    
    Fixes: d1d04ef8572b ("ovl: stack file ops")
    Reported-by: Eddie Horng <eddiehorng.tw@gmail.com>
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 289e5e057bfe69008dcd5d8ee1a03a6e48529eed
Author: Jiufei Xue <jiufei.xue@linux.alibaba.com>
Date:   Mon May 6 15:41:02 2019 +0800

    ovl: check the capability before cred overridden
    
    commit 98487de318a6f33312471ae1e2afa16fbf8361fe upstream.
    
    We found that it return success when we set IMMUTABLE_FL flag to a file in
    docker even though the docker didn't have the capability
    CAP_LINUX_IMMUTABLE.
    
    The commit d1d04ef8572b ("ovl: stack file ops") and dab5ca8fd9dd ("ovl: add
    lsattr/chattr support") implemented chattr operations on a regular overlay
    file. ovl_real_ioctl() overridden the current process's subjective
    credentials with ofs->creator_cred which have the capability
    CAP_LINUX_IMMUTABLE so that it will return success in
    vfs_ioctl()->cap_capable().
    
    Fix this by checking the capability before cred overridden. And here we
    only care about APPEND_FL and IMMUTABLE_FL, so get these information from
    inode.
    
    [SzM: move check and call to underlying fs inside inode locked region to
    prevent two such calls from racing with each other]
    
    Signed-off-by: Jiufei Xue <jiufei.xue@linux.alibaba.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Cc: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e73b09c75adaaea1fb446d81e31fa0cc95d571eb
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jun 13 09:36:32 2019 +0200

    Revert "drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)"
    
    This reverts commit 1e07d637497788971018d9e9e5a184940b1ade0f which is
    commit b30a43ac7132cdda833ac4b13dd1ebd35ace14b7 upstream.
    
    Sven reports:
            Commit 1e07d63749 ("drm/nouveau: add kconfig option to turn off nouveau
            legacy contexts. (v3)") has caused a build failure for me when I
            actually tried that option (CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n):
    
            ,----
            | Kernel: arch/x86/boot/bzImage is ready  (#1)
            |   Building modules, stage 2.
            |   MODPOST 290 modules
            | ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
            | scripts/Makefile.modpost:91: recipe for target '__modpost' failed
            `----
    
            Upstream does not have that problem, as commit bed2dd8421 ("drm/ttm:
            Quick-test mmap offset in ttm_bo_mmap()") has removed the use of
            drm_legacy_mmap from nouveau_ttm.c.  Unfortunately that commit does not
            apply in 5.1.9.
    
    The ensuing discussion proposed a number of one-off patches, but no
    solid agreement was made, so just revert the commit for now to get
    people's systems building again.
    
    Reported-by: Sven Joachim <svenjoac@gmx.de>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Dave Airlie <airlied@redhat.com>
    Cc: Thomas Backlund <tmb@mageia.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b528880e8b0167c34cb36c1b4e6165192f76267c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jun 13 09:28:42 2019 +0200

    Revert "Bluetooth: Align minimum encryption key size for LE and BR/EDR connections"
    
    This reverts commit 07e38998a19d72b916c39a983c19134522ae806b which is
    commit d5bb334a8e171b262e48f378bd2096c0ea458265 upstream.
    
    Lots of people have reported issues with this patch, and as there does
    not seem to be a fix going into Linus's kernel tree any time soon,
    revert the commit in the stable trees so as to get people's machines
    working properly again.
    
    Reported-by: Vasily Khoruzhick <anarsoul@gmail.com>
    Reported-by: Hans de Goede <hdegoede@redhat.com>
    Cc: Jeremy Cline <jeremy@jcline.org>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: Johan Hedberg <johan.hedberg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a5abd6ba0bbdd61f728af444e600a84297e08fe
Author: Dennis Zhou <dennis@kernel.org>
Date:   Thu Feb 21 15:54:11 2019 -0800

    percpu: do not search past bitmap when allocating an area
    
    [ Upstream commit 8c43004af01635cc9fbb11031d070e5e0d327ef2 ]
    
    pcpu_find_block_fit() guarantees that a fit is found within
    PCPU_BITMAP_BLOCK_BITS. Iteration is used to determine the first fit as
    it compares against the block's contig_hint. This can lead to
    incorrectly scanning past the end of the bitmap. The behavior was okay
    given the check after for bit_off >= end and the correctness of the
    hints from pcpu_find_block_fit().
    
    This patch fixes this by bounding the end offset by the number of bits
    in a chunk.
    
    Signed-off-by: Dennis Zhou <dennis@kernel.org>
    Reviewed-by: Peng Fan <peng.fan@nxp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e92c1e9a0ae888c4c55d0f10a092bb6d2b7c422e
Author: Andrey Smirnov <andrew.smirnov@gmail.com>
Date:   Sun Mar 10 23:27:31 2019 -0700

    gpio: vf610: Do not share irq_chip
    
    [ Upstream commit 338aa10750ba24d04beeaf5dc5efc032e5cf343f ]
    
    Fix the warning produced by gpiochip_set_irq_hooks() by allocating a
    dedicated IRQ chip per GPIO chip/port.
    
    Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
    Cc: Linus Walleij <linus.walleij@linaro.org>
    Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Cc: Chris Healy <cphealy@gmail.com>
    Cc: Andrew Lunn <andrew@lunn.ch>
    Cc: Heiner Kallweit <hkallweit1@gmail.com>
    Cc: Fabio Estevam <festevam@gmail.com>
    Cc: linux-gpio@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Cc: linux-imx@nxp.com
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 718910bf68c393805a34fbbd7a4fa9a6dd9f9aba
Author: Marek Vasut <marek.vasut+renesas@gmail.com>
Date:   Sun Mar 3 20:41:40 2019 +0100

    ARM: shmobile: porter: enable R-Car Gen2 regulator quirk
    
    [ Upstream commit d5aa84087eadd6f2619628bc9f3d028eeabded0f ]
    
    Porter needs the regulator quirk, just like the other boards.
    But unlike the other boards, the Porter uses DA9063L, which
    is at 0x5a. Otherwise, DA9063L and DA9210 IRQ line is still
    connected to CPU IRQ2 .
    
    Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
    Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 183e82c6bdcf5f0d447c150465534317eea22ec5
Author: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Date:   Thu Feb 28 12:00:48 2019 +0100

    soc: renesas: Identify R-Car M3-W ES1.3
    
    [ Upstream commit 15160f6de0bba712fcea078c5ac7571fe33fcd5d ]
    
    The Product Register of R-Car M3-W ES1.3 incorrectly identifies the SoC
    revision as ES2.1. Add a workaround to fix this.
    
    Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e5f2c46c65203e3cdfab655bbfc5767f79d273f4
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Mar 11 11:48:14 2019 +0100

    usb: typec: fusb302: Check vconn is off when we start toggling
    
    [ Upstream commit 32a155b1a83d6659e2272e8e1eec199667b1897e ]
    
    The datasheet says the vconn MUST be off when we start toggling. The
    tcpm.c state-machine is responsible to make sure vconn is off, but lets
    add a WARN to catch any cases where vconn is not off for some reason.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 06a9410221368ead1f971db464db3666840e535a
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Mon Feb 18 15:34:12 2019 +0100

    ARM: exynos: Fix undefined instruction during Exynos5422 resume
    
    [ Upstream commit 4d8e3e951a856777720272ce27f2c738a3eeef8c ]
    
    During early system resume on Exynos5422 with performance counters enabled
    the following kernel oops happens:
    
        Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP ARM
        Modules linked in:
        CPU: 0 PID: 1433 Comm: bash Tainted: G        W         5.0.0-rc5-next-20190208-00023-gd5fb5a8a13e6-dirty #5480
        Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
        ...
        Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment none
        Control: 10c5387d  Table: 4451006a  DAC: 00000051
        Process bash (pid: 1433, stack limit = 0xb7e0e22f)
        ...
        (reset_ctrl_regs) from [<c0112ad0>] (dbg_cpu_pm_notify+0x1c/0x24)
        (dbg_cpu_pm_notify) from [<c014c840>] (notifier_call_chain+0x44/0x84)
        (notifier_call_chain) from [<c014cbc0>] (__atomic_notifier_call_chain+0x7c/0x128)
        (__atomic_notifier_call_chain) from [<c01ffaac>] (cpu_pm_notify+0x30/0x54)
        (cpu_pm_notify) from [<c055116c>] (syscore_resume+0x98/0x3f4)
        (syscore_resume) from [<c0189350>] (suspend_devices_and_enter+0x97c/0xe74)
        (suspend_devices_and_enter) from [<c0189fb8>] (pm_suspend+0x770/0xc04)
        (pm_suspend) from [<c0187740>] (state_store+0x6c/0xcc)
        (state_store) from [<c09fa698>] (kobj_attr_store+0x14/0x20)
        (kobj_attr_store) from [<c030159c>] (sysfs_kf_write+0x4c/0x50)
        (sysfs_kf_write) from [<c0300620>] (kernfs_fop_write+0xfc/0x1e0)
        (kernfs_fop_write) from [<c0282be8>] (__vfs_write+0x2c/0x160)
        (__vfs_write) from [<c0282ea4>] (vfs_write+0xa4/0x16c)
        (vfs_write) from [<c0283080>] (ksys_write+0x40/0x8c)
        (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
    
    Undefined instruction is triggered during CP14 reset, because bits: #16
    (Secure privileged invasive debug disabled) and #17 (Secure privileged
    noninvasive debug disable) are set in DSCR. Those bits depend on SPNIDEN
    and SPIDEN lines, which are provided by Secure JTAG hardware block. That
    block in turn is powered from cluster 0 (big/Eagle), but the Exynos5422
    boots on cluster 1 (LITTLE/KFC).
    
    To fix this issue it is enough to turn on the power on the cluster 0 for
    a while. This lets the Secure JTAG block to propagate the needed signals
    to LITTLE/KFC cores and change their DSCR.
    
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e940d550426f5188c14cdbc0a6d8d6d6c3d08ca0
Author: Phong Hoang <phong.hoang.wz@renesas.com>
Date:   Tue Mar 19 19:40:08 2019 +0900

    pwm: Fix deadlock warning when removing PWM device
    
    [ Upstream commit 347ab9480313737c0f1aaa08e8f2e1a791235535 ]
    
    This patch fixes deadlock warning if removing PWM device
    when CONFIG_PROVE_LOCKING is enabled.
    
    This issue can be reproceduced by the following steps on
    the R-Car H3 Salvator-X board if the backlight is disabled:
    
     # cd /sys/class/pwm/pwmchip0
     # echo 0 > export
     # ls
     device  export  npwm  power  pwm0  subsystem  uevent  unexport
     # cd device/driver
     # ls
     bind  e6e31000.pwm  uevent  unbind
     # echo e6e31000.pwm > unbind
    
    [   87.659974] ======================================================
    [   87.666149] WARNING: possible circular locking dependency detected
    [   87.672327] 5.0.0 #7 Not tainted
    [   87.675549] ------------------------------------------------------
    [   87.681723] bash/2986 is trying to acquire lock:
    [   87.686337] 000000005ea0e178 (kn->count#58){++++}, at: kernfs_remove_by_name_ns+0x50/0xa0
    [   87.694528]
    [   87.694528] but task is already holding lock:
    [   87.700353] 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c
    [   87.707405]
    [   87.707405] which lock already depends on the new lock.
    [   87.707405]
    [   87.715574]
    [   87.715574] the existing dependency chain (in reverse order) is:
    [   87.723048]
    [   87.723048] -> #1 (pwm_lock){+.+.}:
    [   87.728017]        __mutex_lock+0x70/0x7e4
    [   87.732108]        mutex_lock_nested+0x1c/0x24
    [   87.736547]        pwm_request_from_chip.part.6+0x34/0x74
    [   87.741940]        pwm_request_from_chip+0x20/0x40
    [   87.746725]        export_store+0x6c/0x1f4
    [   87.750820]        dev_attr_store+0x18/0x28
    [   87.754998]        sysfs_kf_write+0x54/0x64
    [   87.759175]        kernfs_fop_write+0xe4/0x1e8
    [   87.763615]        __vfs_write+0x40/0x184
    [   87.767619]        vfs_write+0xa8/0x19c
    [   87.771448]        ksys_write+0x58/0xbc
    [   87.775278]        __arm64_sys_write+0x18/0x20
    [   87.779721]        el0_svc_common+0xd0/0x124
    [   87.783986]        el0_svc_compat_handler+0x1c/0x24
    [   87.788858]        el0_svc_compat+0x8/0x18
    [   87.792947]
    [   87.792947] -> #0 (kn->count#58){++++}:
    [   87.798260]        lock_acquire+0xc4/0x22c
    [   87.802353]        __kernfs_remove+0x258/0x2c4
    [   87.806790]        kernfs_remove_by_name_ns+0x50/0xa0
    [   87.811836]        remove_files.isra.1+0x38/0x78
    [   87.816447]        sysfs_remove_group+0x48/0x98
    [   87.820971]        sysfs_remove_groups+0x34/0x4c
    [   87.825583]        device_remove_attrs+0x6c/0x7c
    [   87.830197]        device_del+0x11c/0x33c
    [   87.834201]        device_unregister+0x14/0x2c
    [   87.838638]        pwmchip_sysfs_unexport+0x40/0x4c
    [   87.843509]        pwmchip_remove+0xf4/0x13c
    [   87.847773]        rcar_pwm_remove+0x28/0x34
    [   87.852039]        platform_drv_remove+0x24/0x64
    [   87.856651]        device_release_driver_internal+0x18c/0x21c
    [   87.862391]        device_release_driver+0x14/0x1c
    [   87.867175]        unbind_store+0xe0/0x124
    [   87.871265]        drv_attr_store+0x20/0x30
    [   87.875442]        sysfs_kf_write+0x54/0x64
    [   87.879618]        kernfs_fop_write+0xe4/0x1e8
    [   87.884055]        __vfs_write+0x40/0x184
    [   87.888057]        vfs_write+0xa8/0x19c
    [   87.891887]        ksys_write+0x58/0xbc
    [   87.895716]        __arm64_sys_write+0x18/0x20
    [   87.900154]        el0_svc_common+0xd0/0x124
    [   87.904417]        el0_svc_compat_handler+0x1c/0x24
    [   87.909289]        el0_svc_compat+0x8/0x18
    [   87.913378]
    [   87.913378] other info that might help us debug this:
    [   87.913378]
    [   87.921374]  Possible unsafe locking scenario:
    [   87.921374]
    [   87.927286]        CPU0                    CPU1
    [   87.931808]        ----                    ----
    [   87.936331]   lock(pwm_lock);
    [   87.939293]                                lock(kn->count#58);
    [   87.945120]                                lock(pwm_lock);
    [   87.950599]   lock(kn->count#58);
    [   87.953908]
    [   87.953908]  *** DEADLOCK ***
    [   87.953908]
    [   87.959821] 4 locks held by bash/2986:
    [   87.963563]  #0: 00000000ace7bc30 (sb_writers#6){.+.+}, at: vfs_write+0x188/0x19c
    [   87.971044]  #1: 00000000287991b2 (&of->mutex){+.+.}, at: kernfs_fop_write+0xb4/0x1e8
    [   87.978872]  #2: 00000000f739d016 (&dev->mutex){....}, at: device_release_driver_internal+0x40/0x21c
    [   87.988001]  #3: 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c
    [   87.995481]
    [   87.995481] stack backtrace:
    [   87.999836] CPU: 0 PID: 2986 Comm: bash Not tainted 5.0.0 #7
    [   88.005489] Hardware name: Renesas Salvator-X board based on r8a7795 ES1.x (DT)
    [   88.012791] Call trace:
    [   88.015235]  dump_backtrace+0x0/0x190
    [   88.018891]  show_stack+0x14/0x1c
    [   88.022204]  dump_stack+0xb0/0xec
    [   88.025514]  print_circular_bug.isra.32+0x1d0/0x2e0
    [   88.030385]  __lock_acquire+0x1318/0x1864
    [   88.034388]  lock_acquire+0xc4/0x22c
    [   88.037958]  __kernfs_remove+0x258/0x2c4
    [   88.041874]  kernfs_remove_by_name_ns+0x50/0xa0
    [   88.046398]  remove_files.isra.1+0x38/0x78
    [   88.050487]  sysfs_remove_group+0x48/0x98
    [   88.054490]  sysfs_remove_groups+0x34/0x4c
    [   88.058580]  device_remove_attrs+0x6c/0x7c
    [   88.062671]  device_del+0x11c/0x33c
    [   88.066154]  device_unregister+0x14/0x2c
    [   88.070070]  pwmchip_sysfs_unexport+0x40/0x4c
    [   88.074421]  pwmchip_remove+0xf4/0x13c
    [   88.078163]  rcar_pwm_remove+0x28/0x34
    [   88.081906]  platform_drv_remove+0x24/0x64
    [   88.085996]  device_release_driver_internal+0x18c/0x21c
    [   88.091215]  device_release_driver+0x14/0x1c
    [   88.095478]  unbind_store+0xe0/0x124
    [   88.099048]  drv_attr_store+0x20/0x30
    [   88.102704]  sysfs_kf_write+0x54/0x64
    [   88.106359]  kernfs_fop_write+0xe4/0x1e8
    [   88.110275]  __vfs_write+0x40/0x184
    [   88.113757]  vfs_write+0xa8/0x19c
    [   88.117065]  ksys_write+0x58/0xbc
    [   88.120374]  __arm64_sys_write+0x18/0x20
    [   88.124291]  el0_svc_common+0xd0/0x124
    [   88.128034]  el0_svc_compat_handler+0x1c/0x24
    [   88.132384]  el0_svc_compat+0x8/0x18
    
    The sysfs unexport in pwmchip_remove() is completely asymmetric
    to what we do in pwmchip_add_with_polarity() and commit 0733424c9ba9
    ("pwm: Unexport children before chip removal") is a strong indication
    that this was wrong to begin with. We should just move
    pwmchip_sysfs_unexport() where it belongs, which is right after
    pwmchip_sysfs_unexport_children(). In that case, we do not need
    separate functions anymore either.
    
    We also really want to remove sysfs irrespective of whether or not
    the chip will be removed as a result of pwmchip_remove(). We can only
    assume that the driver will be gone after that, so we shouldn't leave
    any dangling sysfs files around.
    
    This warning disappears if we move pwmchip_sysfs_unexport() to
    the top of pwmchip_remove(), pwmchip_sysfs_unexport_children().
    That way it is also outside of the pwm_lock section, which indeed
    doesn't seem to be needed.
    
    Moving the pwmchip_sysfs_export() call outside of that section also
    seems fine and it'd be perfectly symmetric with pwmchip_remove() again.
    
    So, this patch fixes them.
    
    Signed-off-by: Phong Hoang <phong.hoang.wz@renesas.com>
    [shimoda: revise the commit log and code]
    Fixes: 76abbdde2d95 ("pwm: Add sysfs interface")
    Fixes: 0733424c9ba9 ("pwm: Unexport children before chip removal")
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Tested-by: Hoan Nguyen An <na-hoan@jinso.co.jp>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
    Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6e63900b7a732e8c6c4e29ef66c819cd66d24b7a
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Thu Mar 14 21:02:17 2019 +0100

    ARM: dts: exynos: Always enable necessary APIO_1V8 and ABB_1V8 regulators on Arndale Octa
    
    [ Upstream commit 5ab99cf7d5e96e3b727c30e7a8524c976bd3723d ]
    
    The PVDD_APIO_1V8 (LDO2) and PVDD_ABB_1V8 (LDO8) regulators were turned
    off by Linux kernel as unused.  However they supply critical parts of
    SoC so they should be always on:
    
    1. PVDD_APIO_1V8 supplies SYS pins (gpx[0-3], PSHOLD), HDMI level shift,
       RTC, VDD1_12 (DRAM internal 1.8 V logic), pull-up for PMIC interrupt
       lines, TTL/UARTR level shift, reset pins and SW-TACT1 button.
       It also supplies unused blocks like VDDQ_SRAM (for SROM controller) and
       VDDQ_GPIO (gpm7, gpy7).
       The LDO2 cannot be turned off (S2MPS11 keeps it on anyway) so
       marking it "always-on" only reflects its real status.
    
    2. PVDD_ABB_1V8 supplies Adaptive Body Bias Generator for ARM cores,
       memory and Mali (G3D).
    
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4effefce24f31270974220e9ddeed8e7e840317a
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Fri Mar 1 08:48:38 2019 -0500

    media: v4l2-fwnode: Defaults may not override endpoint configuration in firmware
    
    [ Upstream commit 9d3863736a267068a0ae67c6695af8770ef330b7 ]
    
    The lack of defaults provided by the caller to
    v4l2_fwnode_endpoint_parse() signals the use of the default lane mapping.
    The default lane mapping must not be used however if the firmmare contains
    the lane mapping. Disable the default lane mapping in that case, and
    improve the debug messages telling of the use of the defaults.
    
    This was missed previously since the default mapping will only unsed in
    this case if the bus type is set, and no driver did both while still
    needing the lane mapping configuration.
    
    Fixes: b4357d21d674 ("media: v4l: fwnode: Support default CSI-2 lane mapping for drivers")
    
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 465a2271ed5cdf52e68b445f5dee0f200753bf1d
Author: Christoph Vogtländer <c.vogtlaender@sigma-surface-science.com>
Date:   Tue Mar 12 14:38:46 2019 +0530

    pwm: tiehrpwm: Update shadow register for disabling PWMs
    
    [ Upstream commit b00ef53053191d3025c15e8041699f8c9d132daf ]
    
    It must be made sure that immediate mode is not already set, when
    modifying shadow register value in ehrpwm_pwm_disable(). Otherwise
    modifications to the action-qualifier continuous S/W force
    register(AQSFRC) will be done in the active register.
    This may happen when both channels are being disabled. In this case,
    only the first channel state will be recorded as disabled in the shadow
    register. Later, when enabling the first channel again, the second
    channel would be enabled as well. Setting RLDCSF to zero, first, ensures
    that the shadow register is updated as desired.
    
    Fixes: 38dabd91ff0b ("pwm: tiehrpwm: Fix disabling of output of PWMs")
    Signed-off-by: Christoph Vogtländer <c.vogtlaender@sigma-surface-science.com>
    [vigneshr@ti.com: Improve commit message]
    Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 754b995f2a5f099ef8b1ec4e9f574c007ae4c8b9
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon Mar 18 18:39:30 2019 +0300

    dmaengine: idma64: Use actual device for DMA transfers
    
    [ Upstream commit 5ba846b1ee0792f5a596b9b0b86d6e8cdebfab06 ]
    
    Intel IOMMU, when enabled, tries to find the domain of the device,
    assuming it's a PCI one, during DMA operations, such as mapping or
    unmapping. Since we are splitting the actual PCI device to couple of
    children via MFD framework (see drivers/mfd/intel-lpss.c for details),
    the DMA device appears to be a platform one, and thus not an actual one
    that performs DMA. In a such situation IOMMU can't find or allocate
    a proper domain for its operations. As a result, all DMA operations are
    failed.
    
    In order to fix this, supply parent of the platform device
    to the DMA engine framework and fix filter functions accordingly.
    
    We may rely on the fact that parent is a real PCI device, because no
    other configuration is present in the wild.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Mark Brown <broonie@kernel.org>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [for tty parts]
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6e578116483372db361afa84b0e49bcf976cde66
Author: Christopher N Bednarz <christopher.n.bednarz@intel.com>
Date:   Tue Feb 26 16:35:16 2019 -0800

    ice: Do not set LB_EN for prune switch rules
    
    [ Upstream commit b58dafbc6f1089942c1e74b8ab9c616fe06dbfac ]
    
    LB_EN for prune switch rules was causing all TX traffic
    to loopback to the internal switch and dropped.  When
    running bi-directional stress workloads with RDMA
    the RDPU would hang blocking tx and rx traffic.
    
    Signed-off-by: Christopher N Bednarz <christopher.n.bednarz@intel.com>
    Reviewed-by: Bruce Allan <bruce.w.allan@intel.com>
    Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
    Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e4774bc4821347a5ac6cca3d8d0c1a5d265b0834
Author: Yashaswini Raghuram Prathivadi Bhayankaram <yashaswini.raghuram.prathivadi.bhayankaram@intel.com>
Date:   Tue Feb 26 16:35:15 2019 -0800

    ice: Enable LAN_EN for the right recipes
    
    [ Upstream commit 277b3a4547b8afbbecdfc52fe7217f018de26c21 ]
    
    In VEB mode, enable LAN_EN bit in the action fields for filter rules
    corresponding to the right recipes.
    
    Signed-off-by: Yashaswini Raghuram Prathivadi Bhayankaram <yashaswini.raghuram.prathivadi.bhayankaram@intel.com>
    Reviewed-by: Bruce Allan <bruce.w.allan@intel.com>
    Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
    Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b7630b793d60048a5683e57d60dde24fd4b749cd
Author: Sven Eckelmann <sven@narfation.org>
Date:   Sun Mar 17 10:50:50 2019 +0100

    batman-adv: Adjust name for batadv_dat_send_data
    
    [ Upstream commit c2d8b9a6c17a3848136b3eb31f26d3c5880acd89 ]
    
    The send functions in batman-adv are expected to consume the skb when
    either the data is queued up for the underlying driver or when some
    precondition failed. batadv_dat_send_data didn't do this and instead
    created a copy of the skb, modified it and queued the copy up for
    transmission. The caller has to take care that the skb is handled correctly
    (for example free'd) when batadv_dat_send_data returns.
    
    This unclear behavior already lead to memory leaks in the recent past.
    Renaming the function to batadv_dat_forward_data should make it easier to
    identify that the data is forwarded but the skb is not actually
    send+consumed.
    
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 864c051bff9e665475fdb25809fab016e4b2ba1f
Author: Dafna Hirschfeld <dafna3@gmail.com>
Date:   Wed Mar 6 16:13:26 2019 -0500

    media: v4l2-ctrl: v4l2_ctrl_request_setup returns with error upon failure
    
    [ Upstream commit 09ca38a50795a263d2b16dc95794dc5bc17c1d5c ]
    
    If one of the controls fails to set,
    then 'v4l2_ctrl_request_setup'
    immediately returns with the error code.
    
    Signed-off-by: Dafna Hirschfeld <dafna3@gmail.com>
    Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 75224c88744c7ef04752a2c1b58a823993e56e54
Author: Brett Creeley <brett.creeley@intel.com>
Date:   Tue Feb 19 15:04:06 2019 -0800

    ice: Add missing case in print_link_msg for printing flow control
    
    [ Upstream commit 203a068ac9e2722e4d118116acaa3a5586f9468a ]
    
    Currently we aren't checking for the ICE_FC_NONE case for the current
    flow control mode. This is causing "Unknown" to be printed for the
    current flow control method if flow control is disabled. Fix this by
    adding the case for ICE_FC_NONE to print "None".
    
    Signed-off-by: Brett Creeley <brett.creeley@intel.com>
    Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
    Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 086542a2cb0fe948ac7de85dd05455649af273eb
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Mar 25 15:43:16 2019 -0700

    gpio: gpio-omap: limit errata 1.101 handling to wkup domain gpios only
    
    [ Upstream commit 21e2118f470302f16bee7ebd1444505eadbc2c20 ]
    
    We need to only apply errata 1.101 handling to clear non-wakeup edge gpios
    for idle to the gpio bank(s) in the wkup domain to prevent spurious wake-up
    events.
    
    And we must restore what we did after idle manually as the gpio bank in
    wkup domain is not restored otherwise.
    
    Let's keep bank->saved_datain register reading separate, that's not related
    to the 1.101 errata and is used separately on restore.
    
    Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
    Cc: Grygorii Strashko <grygorii.strashko@ti.com>
    Cc: Keerthy <j-keerthy@ti.com>
    Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Cc: Russell King <rmk+kernel@armlinux.org.uk>
    Cc: Tero Kristo <t-kristo@ti.com>
    Reported-by: Grygorii Strashko <grygorii.strashko@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0bbdfcb179b833d71b6bef2c7fc42f3bb00c9e0d
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Mar 25 15:43:18 2019 -0700

    gpio: gpio-omap: add check for off wake capable gpios
    
    [ Upstream commit da38ef3ed10a09248e13ae16530c2c6d448dc47d ]
    
    We are currently assuming all GPIOs are non-wakeup capable GPIOs as we
    not configuring the bank->non_wakeup_gpios like we used to earlier with
    platform_data.
    
    Let's add omap_gpio_is_off_wakeup_capable() to make the handling clearer
    while considering that later patches may want to configure SoC specific
    bank->non_wakeup_gpios for the GPIOs in wakeup domain.
    
    Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
    Cc: Grygorii Strashko <grygorii.strashko@ti.com>
    Cc: Keerthy <j-keerthy@ti.com>
    Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Cc: Russell King <rmk+kernel@armlinux.org.uk>
    Cc: Tero Kristo <t-kristo@ti.com>
    Reported-by: Grygorii Strashko <grygorii.strashko@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b53c68f7507a383bcb224955a715ecf6a1fb495
Author: Bjorn Andersson <bjorn.andersson@linaro.org>
Date:   Thu Dec 13 10:32:00 2018 -0800

    arm64: dts: qcom: qcs404: Fix regulator supply names
    
    [ Upstream commit f95f57e4372207ede83ac28f300aba719b271ed5 ]
    
    The regulator definition got their supply names cleaned up during
    upstreaming, so they no longer match the driver defined names. Update
    the supply names.
    
    Also fill out the missing voltage of SMPS 5.
    
    Fixes: 0b363f5b871c ("arm64: dts: qcom: qcs404: Add PMS405 RPM regulators")
    Reported-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
    Reviewed-by: Niklas Cassel <niklas.cassel@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Andy Gross <andy.gross@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dc73a38014e4a8c4d3f4b0e6aa74c9634978caef
Author: Kangjie Lu <kjlu@umn.edu>
Date:   Mon Mar 25 17:19:09 2019 -0500

    PCI: xilinx: Check for __get_free_pages() failure
    
    [ Upstream commit 699ca30162686bf305cdf94861be02eb0cf9bda2 ]
    
    If __get_free_pages() fails, return -ENOMEM to avoid a NULL pointer
    dereference.
    
    Signed-off-by: Kangjie Lu <kjlu@umn.edu>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Steven Price <steven.price@arm.com>
    Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 404ee275baec931a5c405c99dedc5abf6bb1d342
Author: Paolo Valente <paolo.valente@linaro.org>
Date:   Tue Mar 12 09:59:27 2019 +0100

    block, bfq: increase idling for weight-raised queues
    
    [ Upstream commit 778c02a236a8728bb992de10ed1f12c0be5b7b0e ]
    
    If a sync bfq_queue has a higher weight than some other queue, and
    remains temporarily empty while in service, then, to preserve the
    bandwidth share of the queue, it is necessary to plug I/O dispatching
    until a new request arrives for the queue. In addition, a timeout
    needs to be set, to avoid waiting for ever if the process associated
    with the queue has actually finished its I/O.
    
    Even with the above timeout, the device is however not fed with new
    I/O for a while, if the process has finished its I/O. If this happens
    often, then throughput drops and latencies grow. For this reason, the
    timeout is kept rather low: 8 ms is the current default.
    
    Unfortunately, such a low value may cause, on the opposite end, a
    violation of bandwidth guarantees for a process that happens to issue
    new I/O too late. The higher the system load, the higher the
    probability that this happens to some process. This is a problem in
    scenarios where service guarantees matter more than throughput. One
    important case are weight-raised queues, which need to be granted a
    very high fraction of the bandwidth.
    
    To address this issue, this commit lower-bounds the plugging timeout
    for weight-raised queues to 20 ms. This simple change provides
    relevant benefits. For example, on a PLEXTOR PX-256M5S, with which
    gnome-terminal starts in 0.6 seconds if there is no other I/O in
    progress, the same applications starts in
    - 0.8 seconds, instead of 1.2 seconds, if ten files are being read
      sequentially in parallel
    - 1 second, instead of 2 seconds, if, in parallel, five files are
      being read sequentially, and five more files are being written
      sequentially
    
    Tested-by: Holger Hoffstätte <holger@applied-asynchrony.com>
    Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
    Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cd4fb576d783b6a73f27a73ac6c69dab6478b08c
Author: Kangjie Lu <kjlu@umn.edu>
Date:   Mon Apr 1 17:46:58 2019 +0200

    video: imsttfb: fix potential NULL pointer dereferences
    
    [ Upstream commit 1d84353d205a953e2381044953b7fa31c8c9702d ]
    
    In case ioremap fails, the fix releases resources and returns
    -ENOMEM to avoid NULL pointer dereferences.
    
    Signed-off-by: Kangjie Lu <kjlu@umn.edu>
    Cc: Aditya Pakki <pakki001@umn.edu>
    Cc: Finn Thain <fthain@telegraphics.com.au>
    Cc: Rob Herring <robh@kernel.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [b.zolnierkie: minor patch summary fixup]
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 317cc03af259accb428eb28c63619c3ff195f0d7
Author: Kangjie Lu <kjlu@umn.edu>
Date:   Mon Apr 1 17:46:58 2019 +0200

    video: hgafb: fix potential NULL pointer dereference
    
    [ Upstream commit ec7f6aad57ad29e4e66cc2e18e1e1599ddb02542 ]
    
    When ioremap fails, hga_vram should not be dereferenced. The fix
    check the failure to avoid NULL pointer dereference.
    
    Signed-off-by: Kangjie Lu <kjlu@umn.edu>
    Cc: Aditya Pakki <pakki001@umn.edu>
    Cc: Ferenc Bakonyi <fero@drama.obuda.kando.hu>
    [b.zolnierkie: minor patch summary fixup]
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 15337c4e4e86bf850335552e55262c24dc5fdb7e
Author: Jagan Teki <jagan@amarulasolutions.com>
Date:   Wed Apr 3 16:05:34 2019 -0700

    Input: goodix - add GT5663 CTP support
    
    [ Upstream commit a5f50c501321249d67611353dde6d68d48c5b959 ]
    
    GT5663 is capacitive touch controller with customized smart
    wakeup gestures.
    
    Add support for it by adding compatible and supported chip data.
    
    The chip data on GT5663 is similar to GT1151, like
    - config data register has 0x8050 address
    - config data register max len is 240
    - config data checksum has 16-bit
    
    Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f6023d95da385552b6fcba04009647548538fa2f
Author: Giridhar Malavali <gmalavali@marvell.com>
Date:   Tue Apr 2 14:24:22 2019 -0700

    scsi: qla2xxx: Reset the FCF_ASYNC_{SENT|ACTIVE} flags
    
    [ Upstream commit 0257eda08e806b82ee1fc90ef73583b6f022845c ]
    
    Driver maintains state machine for processing and completing switch
    commands. This patch resets FCF_ASYNC_{SENT|ACTIVE} flag to indicate if the
    previous command is active or sent, in order for next GPSC command to
    advance the state machine.
    
    [mkp: commit desc typo]
    
    Signed-off-by: Giridhar Malavali <gmalavali@marvell.com>
    Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e29094bfb092f7a95a2fddb6a5e52ad11520ef20
Author: Marek Vasut <marek.vasut+renesas@gmail.com>
Date:   Mon Mar 25 12:41:01 2019 +0100

    PCI: rcar: Fix 64bit MSI message address handling
    
    [ Upstream commit 954b4b752a4c4e963b017ed8cef4c453c5ed308d ]
    
    The MSI message address in the RC address space can be 64 bit. The
    R-Car PCIe RC supports such a 64bit MSI message address as well.
    The code currently uses virt_to_phys(__get_free_pages()) to obtain
    a reserved page for the MSI message address, and the return value
    of which can be a 64 bit physical address on 64 bit system.
    
    However, the driver only programs PCIEMSIALR register with the bottom
    32 bits of the virt_to_phys(__get_free_pages()) return value and does
    not program the top 32 bits into PCIEMSIAUR, but rather programs the
    PCIEMSIAUR register with 0x0. This worked fine on older 32 bit R-Car
    SoCs, however may fail on new 64 bit R-Car SoCs.
    
    Since from a PCIe controller perspective, an inbound MSI is a memory
    write to a special address (in case of this controller, defined by
    the value in PCIEMSIAUR:PCIEMSIALR), which triggers an interrupt, but
    never hits the DRAM _and_ because allocation of an MSI by a PCIe card
    driver obtains the MSI message address by reading PCIEMSIAUR:PCIEMSIALR
    in rcar_msi_setup_irqs(), incorrectly programmed PCIEMSIAUR cannot
    cause memory corruption or other issues.
    
    There is however the possibility that if virt_to_phys(__get_free_pages())
    returned address above the 32bit boundary _and_ PCIEMSIAUR was programmed
    to 0x0 _and_ if the system had physical RAM at the address matching the
    value of PCIEMSIALR, a PCIe card driver could allocate a buffer with a
    physical address matching the value of PCIEMSIALR and a remote write to
    such a buffer by a PCIe card would trigger a spurious MSI.
    
    Fixes: e015f88c368d ("PCI: rcar: Add support for R-Car H3 to pcie-rcar")
    Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Cc: Geert Uytterhoeven <geert+renesas@glider.be>
    Cc: Phil Edworthy <phil.edworthy@renesas.com>
    Cc: Simon Horman <horms+renesas@verge.net.au>
    Cc: Wolfram Sang <wsa@the-dreams.de>
    Cc: linux-renesas-soc@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d1ee5d2ae978d66ac35636717b60c80bec9bd9e2
Author: Kangjie Lu <kjlu@umn.edu>
Date:   Fri Mar 15 02:29:43 2019 -0500

    PCI: rcar: Fix a potential NULL pointer dereference
    
    [ Upstream commit f0d14edd2ba43b995bef4dd5da5ffe0ae19321a1 ]
    
    In case __get_free_pages() fails and returns NULL, fix the return
    value to -ENOMEM and release resources to avoid dereferencing a
    NULL pointer.
    
    Signed-off-by: Kangjie Lu <kjlu@umn.edu>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4e15f6d7c7ae8bf0733ff2c5b125c27bedcec83c
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date:   Thu Mar 21 15:29:27 2019 +0530

    PCI: dwc: Remove default MSI initialization for platform specific MSI chips
    
    [ Upstream commit fd8a44bd5b76dc77133f814dd63d414d49dc74c0 ]
    
    Platforms which populate msi_host_init() have their own MSI controller
    logic. Writing to MSI control registers on platforms which do not use
    Designware's MSI controller logic might have side effects.
    
    To be safe, do not write to MSI control registers if the platform uses
    its own MSI controller logic instead of Designware's MSI one.
    
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    [lorenzo.pieralisi@arm.com: updated commit log]
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 21bd6db4d396169949265c49423df3bd2802a3c9
Author: Peng Li <lipeng321@huawei.com>
Date:   Thu Apr 4 16:17:51 2019 +0800

    net: hns3: return 0 and print warning when hit duplicate MAC
    
    [ Upstream commit 72110b567479f0282489a9b3747e76d8c67d75f5 ]
    
    When set 2 same MAC to different function of one port, IMP
    will return error as the later one may modify the origin one.
    This will cause bond fail for 2 VFs of one port.
    
    Driver just print warning and return 0 with this patch, so
    if set same MAC address, it will return 0 but do not really
    configure HW.
    
    Signed-off-by: Peng Li <lipeng321@huawei.com>
    Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dae43810b24a763be710994ec62cd436ab5212a7
Author: Chao Yu <yuchao0@huawei.com>
Date:   Tue Apr 2 18:52:19 2019 +0800

    f2fs: fix potential recursive call when enabling data_flush
    
    [ Upstream commit 186857c5a14aee85cace2ae7a36c6e43b9d3c7a5 ]
    
    As Hagbard Celine reported:
    
    Hi, this is a long standing bug that I've hit before on older kernels,
    but I was not able to get the syslog saved because of the nature of
    the bug. This time I had booted form a pen-drive, and was able to save
    the log to it's efi-partition.
    What i did to trigger it was to create a partition and format it f2fs,
    then mount it with options:
    "rw,relatime,lazytime,background_gc=on,disable_ext_identify,discard,heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,data_flush,extent_cache,mode=adaptive,active_logs=6,whint_mode=fs-based,alloc_mode=default,fsync_mode=strict".
    Then I unpacked a big .tar.xz to the partition (I used a
    gentoo-stage3-tarball as I was in process of installing Gentoo).
    
    Same options just without data_flush gives no problems.
    
    Mar 20 20:54:01 usbgentoo kernel: FAT-fs (nvme0n1p4): Volume was not
    properly unmounted. Some data may be corrupt. Please run fsck.
    Mar 20 21:05:23 usbgentoo kernel: kworker/dying (1588) used greatest
    stack depth: 12064 bytes left
    Mar 20 21:06:40 usbgentoo kernel: BUG: stack guard page was hit at
    00000000a4b0733c (stack is 0000000056016422..0000000096e7463f)
    Mar 20 21:06:40 usbgentoo kernel: kernel stack overflow
    
    ......
    
    Mar 20 21:06:40 usbgentoo kernel: Call Trace:
    Mar 20 21:06:40 usbgentoo kernel:  read_node_page+0x71/0xf0
    Mar 20 21:06:40 usbgentoo kernel:  ? xas_load+0x8/0x50
    Mar 20 21:06:40 usbgentoo kernel:  __get_node_page+0x73/0x2a0
    Mar 20 21:06:40 usbgentoo kernel:  f2fs_get_dnode_of_data+0x34e/0x580
    Mar 20 21:06:40 usbgentoo kernel:  f2fs_write_inline_data+0x5e/0x2a0
    Mar 20 21:06:40 usbgentoo kernel:  __write_data_page+0x421/0x690
    Mar 20 21:06:40 usbgentoo kernel:  f2fs_write_cache_pages+0x1cf/0x460
    Mar 20 21:06:40 usbgentoo kernel:  f2fs_write_data_pages+0x2b3/0x2e0
    Mar 20 21:06:40 usbgentoo kernel:  ? f2fs_inode_chksum_verify+0x1d/0xc0
    Mar 20 21:06:40 usbgentoo kernel:  ? read_node_page+0x71/0xf0
    Mar 20 21:06:40 usbgentoo kernel:  do_writepages+0x3c/0xd0
    Mar 20 21:06:40 usbgentoo kernel:  __filemap_fdatawrite_range+0x7c/0xb0
    Mar 20 21:06:40 usbgentoo kernel:  f2fs_sync_dirty_inodes+0xf2/0x200
    Mar 20 21:06:40 usbgentoo kernel:  f2fs_balance_fs_bg+0x2a3/0x2c0
    Mar 20 21:06:40 usbgentoo kernel:  ? f2fs_inode_dirtied+0x21/0xc0
    Mar 20 21:06:40 usbgentoo kernel:  f2fs_balance_fs+0xd6/0x2b0
    Mar 20 21:06:40 usbgentoo kernel:  __write_data_page+0x4fb/0x690
    
    ......
    
    Mar 20 21:06:40 usbgentoo kernel:  __writeback_single_inode+0x2a1/0x340
    Mar 20 21:06:40 usbgentoo kernel:  ? soft_cursor+0x1b4/0x220
    Mar 20 21:06:40 usbgentoo kernel:  writeback_sb_inodes+0x1d5/0x3e0
    Mar 20 21:06:40 usbgentoo kernel:  __writeback_inodes_wb+0x58/0xa0
    Mar 20 21:06:40 usbgentoo kernel:  wb_writeback+0x250/0x2e0
    Mar 20 21:06:40 usbgentoo kernel:  ? 0xffffffff8c000000
    Mar 20 21:06:40 usbgentoo kernel:  ? cpumask_next+0x16/0x20
    Mar 20 21:06:40 usbgentoo kernel:  wb_workfn+0x2f6/0x3b0
    Mar 20 21:06:40 usbgentoo kernel:  ? __switch_to_asm+0x40/0x70
    Mar 20 21:06:40 usbgentoo kernel:  process_one_work+0x1f5/0x3f0
    Mar 20 21:06:40 usbgentoo kernel:  worker_thread+0x28/0x3c0
    Mar 20 21:06:40 usbgentoo kernel:  ? rescuer_thread+0x330/0x330
    Mar 20 21:06:40 usbgentoo kernel:  kthread+0x10e/0x130
    Mar 20 21:06:40 usbgentoo kernel:  ? kthread_create_on_node+0x60/0x60
    Mar 20 21:06:40 usbgentoo kernel:  ret_from_fork+0x35/0x40
    
    The root cause is that we run into an infinite recursive calling in
    between f2fs_balance_fs_bg and writepage() as described below:
    
    - f2fs_write_data_pages         --- A
     - __write_data_page
      - f2fs_balance_fs
       - f2fs_balance_fs_bg         --- B
        - f2fs_sync_dirty_inodes
         - filemap_fdatawrite
          - f2fs_write_data_pages   --- A
    ...
              - f2fs_balance_fs_bg  --- B
    ...
    
    In order to fix this issue, let's detect such condition in __write_data_page()
    and just skip calling f2fs_balance_fs() recursively.
    
    Reported-by: Hagbard Celine <hagbardcelin@gmail.com>
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 95b1b9a1d192482d3857bcb17e6d7f6b8e42bc23
Author: Sven Van Asbroeck <thesven73@gmail.com>
Date:   Fri Feb 15 16:43:02 2019 -0500

    power: supply: max14656: fix potential use-before-alloc
    
    [ Upstream commit 0cd0e49711556d2331a06b1117b68dd786cb54d2 ]
    
    Call order on probe():
    - max14656_hw_init() enables interrupts on the chip
    - devm_request_irq() starts processing interrupts, isr
      could be called immediately
    -    isr: schedules delayed work (irq_work)
    -    irq_work: calls power_supply_changed()
    - devm_power_supply_register() registers the power supply
    
    Depending on timing, it's possible that power_supply_changed()
    is called on an unregistered power supply structure.
    
    Fix by registering the power supply before requesting the irq.
    
    Cc: Alexander Kurz <akurz@blala.de>
    Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 93e97bcfaa4bee62ec401ad7206ace9e8246d43a
Author: Junxiao Chang <junxiao.chang@intel.com>
Date:   Mon Apr 8 17:40:22 2019 +0800

    platform/x86: intel_pmc_ipc: adding error handling
    
    [ Upstream commit e61985d0550df8c2078310202aaad9b41049c36c ]
    
    If punit or telemetry device initialization fails, pmc driver should
    unregister and return failure.
    
    This change is to fix a kernel panic when removing kernel module
    intel_pmc_ipc.
    
    Fixes: 48c1917088ba ("platform:x86: Add Intel telemetry platform device")
    Signed-off-by: Junxiao Chang <junxiao.chang@intel.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit db5d63c11b945949b27638cbf67845646c95c9cd
Author: Binbin Wu <binbin.wu@intel.com>
Date:   Mon Apr 8 18:49:26 2019 +0800

    pinctrl: pinctrl-intel: move gpio suspend/resume to noirq phase
    
    [ Upstream commit 2fef32766861c6e171f436ab99c89198cf0ca6e1 ]
    
    In current driver, SET_LATE_SYSTEM_SLEEP_PM_OPS is used to install the
    callbacks for suspend/resume.
    GPIO pin may be used as the interrupt pin by some device. However, using
    SET_LATE_SYSTEM_SLEEP_PM_OPS() to install the callbacks, the resume
    callback is called after resume_device_irqs(). Unintended interrupts may
    arrive due to resuming device irqs first, but the GPIO controller is not
    properly restored.
    
    Normally, for a SMP system, there are multiple cores, so even when there are
    unintended interrupts, BSP gets the chance to initialize the GPIO chip soon.
    But when there is only 1 core is active (other cores are offlined or
    single core) during resume, it is more easily to observe the unintended
    interrupts.
    
    This patch renames the suspend/resume function by adding suffix "_noirq",
    and installs the callbacks using SET_NOIRQ_SYSTEM_SLEEP_PM_OPS().
    
    Signed-off-by: Binbin Wu <binbin.wu@intel.com>
    Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8274eb869427fe7051248671f77176a0026bdfd8
Author: Kabir Sahane <x0153567@ti.com>
Date:   Tue Apr 9 08:05:17 2019 -0700

    ARM: OMAP2+: pm33xx-core: Do not Turn OFF CEFUSE as PPA may be using it
    
    [ Upstream commit 72aff4ecf1cb85a3c6e6b42ccbda0bc631b090b3 ]
    
    This area is used to store keys by HSPPA in case of AM438x SOC. Leave it
    active.
    
    Signed-off-by: Kabir Sahane <x0153567@ti.com>
    Signed-off-by: Andrew F. Davis <afd@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f02b8f4d791d263bca2e9287b0c4c8cc780339f2
Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Date:   Thu Mar 14 13:46:44 2019 -0400

    drm/amd/display: Use plane->color_space for dpp if specified
    
    [ Upstream commit a1e07ba89d49581471d64c48152dbe03b42bd025 ]
    
    [Why]
    The input color space for the plane was previously ignored even if it
    was set.
    
    If a limited range YUV format was given to DC then the
    wrong color transformation matrix was being used since DC assumed that
    it was full range instead.
    
    [How]
    Respect the given color_space format for the plane if it isn't
    COLOR_SPACE_UNKNOWN. Otherwise, use the implicit default since DM
    didn't specify.
    
    Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
    Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com>
    Acked-by: Aric Cyr <Aric.Cyr@amd.com>
    Acked-by: Leo Li <sunpeng.li@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cac1f3c2b0707aab8449b67e638ff5585ed6fd89
Author: Anthony Koo <Anthony.Koo@amd.com>
Date:   Mon Mar 25 14:30:12 2019 -0400

    drm/amd/display: disable link before changing link settings
    
    [ Upstream commit 15ae3b28f8ca406b449d36d36021e96b66aedb5d ]
    
    [Why]
    If link is already enabled at a different rate (for example 5.4 Gbps)
    then calling VBIOS command table to switch to a new rate
    (for example 2.7 Gbps) will not take effect.
    This can lead to link training failure to occur.
    
    [How]
    If the requested link rate is different than the current link rate,
    the link must be disabled in order to re-enable at the new
    link rate.
    
    In today's logic it is currently only impacting eDP since DP
    connection types will always disable the link during display
    detection, when initial link verification occurs.
    
    Signed-off-by: Anthony Koo <Anthony.Koo@amd.com>
    Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
    Acked-by: Leo Li <sunpeng.li@amd.com>
    Acked-by: Tony Cheng <Tony.Cheng@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9ed244b185f24c4256fcabc43d0eb3bffa394116
Author: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Date:   Fri Mar 22 13:27:21 2019 -0500

    PCI: rpadlpar: Fix leaked device_node references in add/remove paths
    
    [ Upstream commit fb26228bfc4ce3951544848555c0278e2832e618 ]
    
    The find_dlpar_node() helper returns a device node with its reference
    incremented.  Both the add and remove paths use this helper for find the
    appropriate node, but fail to release the reference when done.
    
    Annotate the find_dlpar_node() helper with a comment about the incremented
    reference count and call of_node_put() on the obtained device_node in the
    add and remove paths.  Also, fixup a reference leak in the find_vio_slot()
    helper where we fail to call of_node_put() on the vdevice node after we
    iterate over its children.
    
    Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 09c9989cb55d1bab6cbb4a7872fc90c5a2971e98
Author: Andrey Smirnov <andrew.smirnov@gmail.com>
Date:   Thu Mar 28 23:49:16 2019 -0700

    ARM: dts: imx6qdl: Specify IMX6QDL_CLK_IPG as "ipg" clock to SDMA
    
    [ Upstream commit b14c872eebc501b9640b04f4a152df51d6eaf2fc ]
    
    Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
    clock to determine if it needs to configure the IP block as operating
    at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
    clocks as IMX6QDL_CLK_SDMA results in driver incorrectly thinking that
    ratio is 1:1 which results in broken SDMA funtionality(this at least
    breaks RAVE SP serdev driver on RDU2). Fix the code to specify
    IMX6QDL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect
    clock ratio.
    
    Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
    Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
    Cc: Angus Ainslie (Purism) <angus@akkea.ca>
    Cc: Chris Healy <cphealy@gmail.com>
    Cc: Lucas Stach <l.stach@pengutronix.de>
    Cc: Fabio Estevam <fabio.estevam@nxp.com>
    Cc: Shawn Guo <shawnguo@kernel.org>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    Tested-by: Adam Ford <aford173@gmail.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit afac6100e9eac287d3fb0e121edac706953e6613
Author: Andrey Smirnov <andrew.smirnov@gmail.com>
Date:   Thu Mar 28 23:49:17 2019 -0700

    ARM: dts: imx6sx: Specify IMX6SX_CLK_IPG as "ipg" clock to SDMA
    
    [ Upstream commit 8979117765c19edc3b01cc0ef853537bf93eea4b ]
    
    Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
    clock to determine if it needs to configure the IP block as operating
    at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
    clocks as IMX6SX_CLK_SDMA results in driver incorrectly thinking that
    ratio is 1:1 which results in broken SDMA funtionality. Fix the code
    to specify IMX6SX_CLK_IPG as "ipg" clock for SDMA, to avoid detecting
    incorrect clock ratio.
    
    Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
    Cc: Angus Ainslie (Purism) <angus@akkea.ca>
    Cc: Chris Healy <cphealy@gmail.com>
    Cc: Lucas Stach <l.stach@pengutronix.de>
    Cc: Fabio Estevam <fabio.estevam@nxp.com>
    Cc: Shawn Guo <shawnguo@kernel.org>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit af792fef41544afdb328f1b1162dec6292ef141e
Author: Andrey Smirnov <andrew.smirnov@gmail.com>
Date:   Thu Mar 28 23:49:19 2019 -0700

    ARM: dts: imx6ul: Specify IMX6UL_CLK_IPG as "ipg" clock to SDMA
    
    [ Upstream commit 7b3132ecefdd1fcdf6b86e62021d0e55ea8034db ]
    
    Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
    clock to determine if it needs to configure the IP block as operating
    at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
    clocks as IMX6UL_CLK_SDMA results in driver incorrectly thinking that
    ratio is 1:1 which results in broken SDMA funtionality. Fix the code
    to specify IMX6UL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting
    incorrect clock ratio.
    
    Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
    Cc: Angus Ainslie (Purism) <angus@akkea.ca>
    Cc: Chris Healy <cphealy@gmail.com>
    Cc: Lucas Stach <l.stach@pengutronix.de>
    Cc: Fabio Estevam <fabio.estevam@nxp.com>
    Cc: Shawn Guo <shawnguo@kernel.org>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9edec2023ea109188fa79809490cbb76a69f47fe
Author: Andrey Smirnov <andrew.smirnov@gmail.com>
Date:   Thu Mar 28 23:49:18 2019 -0700

    ARM: dts: imx7d: Specify IMX7D_CLK_IPG as "ipg" clock to SDMA
    
    [ Upstream commit 412b032a1dc72fc9d1c258800355efa6671b6315 ]
    
    Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
    clock to determine if it needs to configure the IP block as operating
    at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
    clocks as IMX7D_CLK_SDMA results in driver incorrectly thinking that
    ratio is 1:1 which results in broken SDMA funtionality. Fix the code
    to specify IMX7D_CLK_IPG as "ipg" clock for SDMA, to avoid detecting
    incorrect clock ratio.
    
    Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
    Cc: Angus Ainslie (Purism) <angus@akkea.ca>
    Cc: Chris Healy <cphealy@gmail.com>
    Cc: Lucas Stach <l.stach@pengutronix.de>
    Cc: Fabio Estevam <fabio.estevam@nxp.com>
    Cc: Shawn Guo <shawnguo@kernel.org>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ad63ba19b2a4c853174e54f7abb15ee1e8372618
Author: Andrey Smirnov <andrew.smirnov@gmail.com>
Date:   Thu Mar 28 23:49:20 2019 -0700

    ARM: dts: imx6sll: Specify IMX6SLL_CLK_IPG as "ipg" clock to SDMA
    
    [ Upstream commit c5ed5daa65d5f665e666b76c3dbfa503066defde ]
    
    Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
    clock to determine if it needs to configure the IP block as operating
    at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
    clocks as IMX6SLL_CLK_SDMA result in driver incorrectly thinking that
    ratio is 1:1 which results in broken SDMA funtionality. Fix the code
    to specify IMX6SLL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting
    incorrect clock ratio.
    
    Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
    Cc: Angus Ainslie (Purism) <angus@akkea.ca>
    Cc: Chris Healy <cphealy@gmail.com>
    Cc: Lucas Stach <l.stach@pengutronix.de>
    Cc: Fabio Estevam <fabio.estevam@nxp.com>
    Cc: Shawn Guo <shawnguo@kernel.org>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 949b328bd8501dc3c4eacc4bfe09206224f25482
Author: Andrey Smirnov <andrew.smirnov@gmail.com>
Date:   Thu Mar 28 23:49:21 2019 -0700

    ARM: dts: imx6sx: Specify IMX6SX_CLK_IPG as "ahb" clock to SDMA
    
    [ Upstream commit cc839d0f8c284fcb7591780b568f13415bbb737c ]
    
    Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
    clock to determine if it needs to configure the IP block as operating
    at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
    clocks as IMX6SL_CLK_SDMA results in driver incorrectly thinking that
    ratio is 1:1 which results in broken SDMA funtionality. Fix the code
    to specify IMX6SL_CLK_AHB as "ahb" clock for SDMA, to avoid detecting
    incorrect clock ratio.
    
    Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
    Cc: Angus Ainslie (Purism) <angus@akkea.ca>
    Cc: Chris Healy <cphealy@gmail.com>
    Cc: Lucas Stach <l.stach@pengutronix.de>
    Cc: Fabio Estevam <fabio.estevam@nxp.com>
    Cc: Shawn Guo <shawnguo@kernel.org>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 360d0b2996954e8420544dc957e143e4c987248c
Author: Andrey Smirnov <andrew.smirnov@gmail.com>
Date:   Thu Mar 28 23:49:22 2019 -0700

    ARM: dts: imx53: Specify IMX5_CLK_IPG as "ahb" clock to SDMA
    
    [ Upstream commit 28c168018e0902c67eb9c60d0fc4c8aa166c4efe ]
    
    Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
    clock to determine if it needs to configure the IP block as operating
    at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
    clocks as IMX5_CLK_SDMA results in driver incorrectly thinking that
    ratio is 1:1 which results in broken SDMA funtionality. Fix the code
    to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting
    incorrect clock ratio.
    
    Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
    Cc: Angus Ainslie (Purism) <angus@akkea.ca>
    Cc: Chris Healy <cphealy@gmail.com>
    Cc: Lucas Stach <l.stach@pengutronix.de>
    Cc: Fabio Estevam <fabio.estevam@nxp.com>
    Cc: Shawn Guo <shawnguo@kernel.org>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cc6fa2bd0da320adaa5044e58b2ed82c4072665b
Author: Andrey Smirnov <andrew.smirnov@gmail.com>
Date:   Thu Mar 28 23:49:24 2019 -0700

    ARM: dts: imx50: Specify IMX5_CLK_IPG as "ahb" clock to SDMA
    
    [ Upstream commit b7b4fda2636296471e29b78c2aa9535d7bedb7a0 ]
    
    Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
    clock to determine if it needs to configure the IP block as operating
    at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
    clocks as IMX5_CLK_SDMA results in driver incorrectly thinking that
    ratio is 1:1 which results in broken SDMA funtionality. Fix the code
    to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting
    incorrect clock ratio.
    
    Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
    Cc: Angus Ainslie (Purism) <angus@akkea.ca>
    Cc: Chris Healy <cphealy@gmail.com>
    Cc: Lucas Stach <l.stach@pengutronix.de>
    Cc: Fabio Estevam <fabio.estevam@nxp.com>
    Cc: Shawn Guo <shawnguo@kernel.org>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1023ef5df460ea83d54a520fc977e0ce547b6f62
Author: Andrey Smirnov <andrew.smirnov@gmail.com>
Date:   Thu Mar 28 23:49:23 2019 -0700

    ARM: dts: imx51: Specify IMX5_CLK_IPG as "ahb" clock to SDMA
    
    [ Upstream commit 918bbde8085ae147a43dcb491953e0dd8f3e9d6a ]
    
    Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
    clock to determine if it needs to configure the IP block as operating
    at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
    clocks as IMX5_CLK_SDMA results in driver incorrectly thinking that
    ratio is 1:1 which results in broken SDMA funtionality. Fix the code
    to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting
    incorrect clock ratio.
    
    Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
    Cc: Angus Ainslie (Purism) <angus@akkea.ca>
    Cc: Chris Healy <cphealy@gmail.com>
    Cc: Lucas Stach <l.stach@pengutronix.de>
    Cc: Fabio Estevam <fabio.estevam@nxp.com>
    Cc: Shawn Guo <shawnguo@kernel.org>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d72da82640a11bc666e937c74250091881191d1c
Author: Andrey Smirnov <andrew.smirnov@gmail.com>
Date:   Fri Apr 5 10:30:00 2019 -0700

    arm64: dts: imx8mq: Mark iomuxc_gpr as i.MX6Q compatible
    
    [ Upstream commit beea0f22566cb32c35de89ab0980852b5bbc1c60 ]
    
    Mark iomuxc_gpr as compatible with "fsl,imx6q-iomuxc-gpr" in order for
    to allow i.MX6 PCIe driver to use it.
    
    Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
    Acked-by: Lucas Stach <l.stach@pengutronix.de>
    Reviewed-by: Fabio Estevam <festevam@gmail.com>
    Cc: Shawn Guo <shawnguo@kernel.org>
    Cc: Fabio Estevam <fabio.estevam@nxp.com>
    Cc: Chris Healy <cphealy@gmail.com>
    Cc: Lucas Stach <l.stach@pengutronix.de>
    Cc: Leonard Crestez <leonard.crestez@nxp.com>
    Cc: "A.s. Dong" <aisheng.dong@nxp.com>
    Cc: Richard Zhu <hongxing.zhu@nxp.com>
    Cc: linux-imx@nxp.com
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 55c355b19df9667330cc1c84192680dc4d4685d1
Author: Douglas Anderson <dianders@chromium.org>
Date:   Tue Apr 9 13:49:05 2019 -0700

    soc: rockchip: Set the proper PWM for rk3288
    
    [ Upstream commit bbdc00a7de24cc90315b1775fb74841373fe12f7 ]
    
    The rk3288 SoC has two PWM implementations available, the "old"
    implementation and the "new" one.  You can switch between the two of
    them by flipping a bit in the grf.
    
    The "old" implementation is the default at chip power up but isn't the
    one that's officially supposed to be used.  ...and, in fact, the
    driver that gets selected in Linux using the rk3288 device tree only
    supports the "new" implementation.
    
    Long ago I tried to get a switch to the right IP block landed in the
    PWM driver (search for "rk3288: Switch to use the proper PWM IP") but
    that got rejected.  In the mean time the grf has grown a full-fledged
    driver that already sets other random bits like this.  That means we
    can now get the fix landed.
    
    For those wondering how things could have possibly worked for the last
    4.5 years, folks have mostly been relying on the bootloader to set
    this bit.  ...but occasionally folks have pointed back to my old patch
    series [1] in downstream kernels.
    
    [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1391597.html
    
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 189a9522fab8634d97723ecd093ca196033fd234
Author: Lu Baolu <baolu.lu@linux.intel.com>
Date:   Fri Apr 12 12:26:13 2019 +0800

    iommu/vt-d: Flush IOTLB for untrusted device in time
    
    [ Upstream commit f7b0c4ce8cb3c09cb3cbfc0c663268bf99e5fa9c ]
    
    By default, for performance consideration, Intel IOMMU
    driver won't flush IOTLB immediately after a buffer is
    unmapped. It schedules a thread and flushes IOTLB in a
    batched mode. This isn't suitable for untrusted device
    since it still can access the memory even if it isn't
    supposed to do so.
    
    Cc: Ashok Raj <ashok.raj@intel.com>
    Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Tested-by: Xu Pengfei <pengfei.xu@intel.com>
    Tested-by: Mika Westerberg <mika.westerberg@intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 80245980872419490f4b43fb78c0f519e02b5bec
Author: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Date:   Fri Apr 12 14:36:37 2019 +0200

    usb: ohci-da8xx: disable the regulator if the overcurrent irq fired
    
    [ Upstream commit d327330185f192411be80563a3c8398f4538cdb2 ]
    
    Historically the power supply management in this driver has been handled
    in two separate places in parallel. Device-tree users simply defined an
    appropriate regulator, while two boards with no DT support (da830-evm and
    omapl138-hawk) passed functions defined in their respective board files
    over platform data. These functions simply used legacy GPIO calls to
    watch the oc GPIO for interrupts and disable the vbus GPIO when the irq
    fires.
    
    Commit d193abf1c913 ("usb: ohci-da8xx: add vbus and overcurrent gpios")
    updated these GPIO calls to the modern API and moved them inside the
    driver.
    
    This however is not the optimal solution for the vbus GPIO which should
    be modeled as a fixed regulator that can be controlled with a GPIO.
    
    In order to keep the overcurrent protection available once we move the
    board files to using fixed regulators we need to disable the enable_reg
    regulator when the overcurrent indicator interrupt fires. Since we
    cannot call regulator_disable() from interrupt context, we need to
    switch to using a oneshot threaded interrupt.
    
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Sekhar Nori <nsekhar@ti.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4fce6bfe22a338866879e5dfc3fafc23cbc3d24d
Author: Douglas Anderson <dianders@chromium.org>
Date:   Thu Apr 11 16:21:53 2019 -0700

    clk: rockchip: Turn on "aclk_dmac1" for suspend on rk3288
    
    [ Upstream commit 57a20248ef3e429dc822f0774bc4e00136c46c83 ]
    
    Experimentally it can be seen that going into deep sleep (specifically
    setting PMU_CLR_DMA and PMU_CLR_BUS in RK3288_PMU_PWRMODE_CON1)
    appears to fail unless "aclk_dmac1" is on.  The failure is that the
    system never signals that it made it into suspend on the GLOBAL_PWROFF
    pin and it just hangs.
    
    NOTE that it's confirmed that it's the actual suspend that fails, not
    one of the earlier calls to read/write registers.  Specifically if you
    comment out the "PMU_GLOBAL_INT_DISABLE" setting in
    rk3288_slp_mode_set() and then comment out the "cpu_do_idle()" call in
    rockchip_lpmode_enter() then you can exercise the whole suspend path
    without any crashing.
    
    This is currently not a problem with suspend upstream because there is
    no current way to exercise the deep suspend code.  However, anyone
    trying to make it work will run into this issue.
    
    This was not a problem on shipping rk3288-based Chromebooks because
    those devices all ran on an old kernel based on 3.14.  On that kernel
    "aclk_dmac1" appears to be left on all the time.
    
    There are several ways to skin this problem.
    
    A) We could add "aclk_dmac1" to the list of critical clocks and that
    apperas to work, but presumably that wastes power.
    
    B) We could keep a list of "struct clk" objects to enable at suspend
    time in clk-rk3288.c and use the standard clock APIs.
    
    C) We could make the rk3288-pmu driver keep a list of clocks to enable
    at suspend time.  Presumably this would require a dts and bindings
    change.
    
    D) We could just whack the clock on in the existing syscore suspend
    function where we whack a bunch of other clocks.  This is particularly
    easy because we know for sure that the clock's only parent
    ("aclk_cpu") is a critical clock so we don't need to do anything more
    than ungate it.
    
    In this case I have chosen D) because it seemed like the least work,
    but any of the other options would presumably also work fine.
    
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Reviewed-by: Elaine Zhang <zhangqing@rock-chips.com>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bd9704bcc578785c7b1ce0639279eabef312fc79
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Thu Mar 7 15:56:51 2019 -0700

    soc: mediatek: pwrap: Zero initialize rdata in pwrap_init_cipher
    
    [ Upstream commit 89e28da82836530f1ac7a3a32fecc31f22d79b3e ]
    
    When building with -Wsometimes-uninitialized, Clang warns:
    
    drivers/soc/mediatek/mtk-pmic-wrap.c:1358:6: error: variable 'rdata' is
    used uninitialized whenever '||' condition is true
    [-Werror,-Wsometimes-uninitialized]
    
    If pwrap_write returns non-zero, pwrap_read will not be called to
    initialize rdata, meaning that we will use some random uninitialized
    stack value in our print statement. Zero initialize rdata in case this
    happens.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/401
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 02cb726bfabbe72fe12c15b26eba0fa949399d0a
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date:   Mon Mar 25 15:09:33 2019 +0530

    PCI: keystone: Prevent ARM32 specific code to be compiled for ARM64
    
    [ Upstream commit f316a2b53cd7f37963ae20ec7072eb27a349a4ce ]
    
    hook_fault_code() is an ARM32 specific API for hooking into data abort.
    
    AM65X platforms (that integrate ARM v8 cores and select CONFIG_ARM64 as
    arch) rely on pci-keystone.c but on them the enumeration of a
    non-present BDF does not trigger a bus error, so the fixup exception
    provided by calling hook_fault_code() is not needed and can be guarded
    with CONFIG_ARM.
    
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    [lorenzo.pieralisi@arm.com: commit log]
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e178094ad8d58b7b4f660d5cd52daa5bb6055369
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date:   Mon Mar 25 15:09:36 2019 +0530

    PCI: keystone: Invoke phy_reset() API before enabling PHY
    
    [ Upstream commit b22af42b3e57c3a49a4c4a54c7d8a1363af75e90 ]
    
    SERDES connected to the PCIe controller in AM654 requires
    power on reset enable (POR_EN) to be set in the SERDES. The
    SERDES driver sets POR_EN in the reset ops and it has to be
    invoked before init or enable ops. In order for SERDES driver
    to set POR_EN, invoke the phy_reset() API in pci-keystone driver.
    
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1f9dc1d54c1278f338444da24d0d43c61dbd5959
Author: Enrico Granata <egranata@chromium.org>
Date:   Wed Apr 3 15:40:36 2019 -0700

    platform/chrome: cros_ec_proto: check for NULL transfer function
    
    [ Upstream commit 94d4e7af14a1170e34cf082d92e4c02de9e9fb88 ]
    
    As new transfer mechanisms are added to the EC codebase, they may
    not support v2 of the EC protocol.
    
    If the v3 initial handshake transfer fails, the kernel will try
    and call cmd_xfer as a fallback. If v2 is not supported, cmd_xfer
    will be NULL, and the code will end up causing a kernel panic.
    
    Add a check for NULL before calling the transfer function, along
    with a helpful comment explaining how one might end up in this
    situation.
    
    Signed-off-by: Enrico Granata <egranata@chromium.org>
    Reviewed-by: Jett Rink <jettrink@chromium.org>
    Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bec4c3b32fe65c520a0af49f79da6d7d2be20872
Author: Tony Lindgren <tony@atomide.com>
Date:   Sun Apr 7 11:12:50 2019 -0700

    power: supply: cpcap-battery: Fix signed counter sample register
    
    [ Upstream commit c68b901ac4fa969db8917b6a9f9b40524a690d20 ]
    
    The accumulator sample register is signed 32-bits wide register on
    droid 4. And only the earlier version of cpcap has a signed 24-bits
    wide register. We're currently passing it around as unsigned, so
    let's fix that and use sign_extend32() for the earlier revision.
    
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Acked-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ace9bdeb06a6a2a2c564e2cf2d75ab167dcdb5a
Author: Adam Ludkiewicz <adam.ludkiewicz@intel.com>
Date:   Wed Feb 6 15:08:15 2019 -0800

    i40e: Queues are reserved despite "Invalid argument" error
    
    [ Upstream commit 3e957b377bf4262aec2dd424f28ece94e36814d4 ]
    
    Added a new local variable in the i40e_setup_tc function named
    old_queue_pairs so num_queue_pairs can be restored to the correct
    value in case configuring queue channels fails. Additionally, moved
    the exit label in the i40e_setup_tc function so the if (need_reset)
    block can be executed.
    Also, fixed data packing in the i40e_setup_tc function.
    
    Signed-off-by: Adam Ludkiewicz <adam.ludkiewicz@intel.com>
    Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ee3798fcf16dbdb2c221a405107050f422f6039e
Author: Jon Hunter <jonathanh@nvidia.com>
Date:   Tue Apr 16 17:48:07 2019 +0100

    soc/tegra: pmc: Remove reset sysfs entries on error
    
    [ Upstream commit a46b51cd2a57d52d5047e1d48240536243eeab34 ]
    
    Commit 5f84bb1a4099 ("soc/tegra: pmc: Add sysfs entries for reset info")
    added sysfs entries for Tegra reset source and level. However, these
    sysfs are not removed on error and so if the registering of PMC device
    is probe deferred, then the next time we attempt to probe the PMC device
    warnings such as the following will be displayed on boot ...
    
      sysfs: cannot create duplicate filename '/devices/platform/7000e400.pmc/reset_reason'
    
    Fix this by calling device_remove_file() for each sysfs entry added on
    failure. Note that we call device_remove_file() unconditionally without
    checking if the sysfs entry was created in the first place, but this
    should be OK because kernfs_remove_by_name_ns() will fail silently.
    
    Fixes: 5f84bb1a4099 ("soc/tegra: pmc: Add sysfs entries for reset info")
    Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 47de03bebf1c89cfc4c65222bc25c4530b25949a
Author: Wenwen Wang <wang6495@umn.edu>
Date:   Wed Apr 17 09:18:50 2019 -0500

    x86/PCI: Fix PCI IRQ routing table memory leak
    
    [ Upstream commit ea094d53580f40c2124cef3d072b73b2425e7bfd ]
    
    In pcibios_irq_init(), the PCI IRQ routing table 'pirq_table' is first
    found through pirq_find_routing_table().  If the table is not found and
    CONFIG_PCI_BIOS is defined, the table is then allocated in
    pcibios_get_irq_routing_table() using kmalloc().  Later, if the I/O APIC is
    used, this table is actually not used.  In that case, the allocated table
    is not freed, which is a memory leak.
    
    Free the allocated table if it is not used.
    
    Signed-off-by: Wenwen Wang <wang6495@umn.edu>
    [bhelgaas: added Ingo's reviewed-by, since the only change since v1 was to
    use the irq_routing_table local variable name he suggested]
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 18d4decc62babc630a98ee05f1362dcde4875c12
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Fri Sep 28 12:21:17 2018 +0300

    net: thunderbolt: Unregister ThunderboltIP protocol handler when suspending
    
    [ Upstream commit 9872760eb7b1d4f6066ad8b560714a5d0a728fdb ]
    
    The XDomain protocol messages may start as soon as Thunderbolt control
    channel is started. This means that if the other host starts sending
    ThunderboltIP packets early enough they will be passed to the network
    driver which then gets confused because its resume hook is not called
    yet.
    
    Fix this by unregistering the ThunderboltIP protocol handler when
    suspending and registering it back on resume.
    
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Acked-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e86a0475c5207eb24bee62b9377e4457323ecd37
Author: Wesley Sheng <wesley.sheng@microchip.com>
Date:   Mon Apr 15 22:41:42 2019 +0800

    switchtec: Fix unintended mask of MRPC event
    
    [ Upstream commit 083c1b5e50b701899dc32445efa8b153685260d5 ]
    
    When running application tool switchtec-user's `firmware update` and `event
    wait` commands concurrently, sometimes the firmware update speed reduced
    significantly.
    
    It is because when the MRPC event happened after MRPC event occurrence
    check but before the event mask loop reaches its header register in event
    ISR, the MRPC event would be masked unintentionally.  Since there's no
    chance to enable it again except for a module reload, all the following
    MRPC execution completion checks time out.
    
    Fix this bug by skipping the mask operation for MRPC event in event ISR,
    same as what we already do for LINK event.
    
    Fixes: 52eabba5bcdb ("switchtec: Add IOCTLs to the Switchtec driver")
    Signed-off-by: Wesley Sheng <wesley.sheng@microchip.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ddfffa597dfb4809d359fce3a64fc89c0ba04e1a
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Apr 23 11:59:36 2019 +0100

    iommu/arm-smmu-v3: Don't disable SMMU in kdump kernel
    
    [ Upstream commit 3f54c447df34ff9efac7809a4a80fd3208efc619 ]
    
    Disabling the SMMU when probing from within a kdump kernel so that all
    incoming transactions are terminated can prevent the core of the crashed
    kernel from being transferred off the machine if all I/O devices are
    behind the SMMU.
    
    Instead, continue to probe the SMMU after it is disabled so that we can
    reinitialise it entirely and re-attach the DMA masters as they are reset.
    Since the kdump kernel may not have drivers for all of the active DMA
    masters, we suppress fault reporting to avoid spamming the console and
    swamping the IRQ threads.
    
    Reported-by: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
    Tested-by: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
    Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a3bde70488edd34a985e89043790bf20df96212
Author: Farhan Ali <alifm@linux.ibm.com>
Date:   Wed Apr 3 14:22:27 2019 -0400

    vfio: Fix WARNING "do not call blocking ops when !TASK_RUNNING"
    
    [ Upstream commit 41be3e2618174fdf3361e49e64f2bf530f40c6b0 ]
    
    vfio_dev_present() which is the condition to
    wait_event_interruptible_timeout(), will call vfio_group_get_device
    and try to acquire the mutex group->device_lock.
    
    wait_event_interruptible_timeout() will set the state of the current
    task to TASK_INTERRUPTIBLE, before doing the condition check. This
    means that we will try to acquire the mutex while already in a
    sleeping state. The scheduler warns us by giving the following
    warning:
    
    [ 4050.264464] ------------[ cut here ]------------
    [ 4050.264508] do not call blocking ops when !TASK_RUNNING; state=1 set at [<00000000b33c00e2>] prepare_to_wait_event+0x14a/0x188
    [ 4050.264529] WARNING: CPU: 12 PID: 35924 at kernel/sched/core.c:6112 __might_sleep+0x76/0x90
    ....
    
     4050.264756] Call Trace:
    [ 4050.264765] ([<000000000017bbaa>] __might_sleep+0x72/0x90)
    [ 4050.264774]  [<0000000000b97edc>] __mutex_lock+0x44/0x8c0
    [ 4050.264782]  [<0000000000b9878a>] mutex_lock_nested+0x32/0x40
    [ 4050.264793]  [<000003ff800d7abe>] vfio_group_get_device+0x36/0xa8 [vfio]
    [ 4050.264803]  [<000003ff800d87c0>] vfio_del_group_dev+0x238/0x378 [vfio]
    [ 4050.264813]  [<000003ff8015f67c>] mdev_remove+0x3c/0x68 [mdev]
    [ 4050.264825]  [<00000000008e01b0>] device_release_driver_internal+0x168/0x268
    [ 4050.264834]  [<00000000008de692>] bus_remove_device+0x162/0x190
    [ 4050.264843]  [<00000000008daf42>] device_del+0x1e2/0x368
    [ 4050.264851]  [<00000000008db12c>] device_unregister+0x64/0x88
    [ 4050.264862]  [<000003ff8015ed84>] mdev_device_remove+0xec/0x130 [mdev]
    [ 4050.264872]  [<000003ff8015f074>] remove_store+0x6c/0xa8 [mdev]
    [ 4050.264881]  [<000000000046f494>] kernfs_fop_write+0x14c/0x1f8
    [ 4050.264890]  [<00000000003c1530>] __vfs_write+0x38/0x1a8
    [ 4050.264899]  [<00000000003c187c>] vfs_write+0xb4/0x198
    [ 4050.264908]  [<00000000003c1af2>] ksys_write+0x5a/0xb0
    [ 4050.264916]  [<0000000000b9e270>] system_call+0xdc/0x2d8
    [ 4050.264925] 4 locks held by sh/35924:
    [ 4050.264933]  #0: 000000001ef90325 (sb_writers#4){.+.+}, at: vfs_write+0x9e/0x198
    [ 4050.264948]  #1: 000000005c1ab0b3 (&of->mutex){+.+.}, at: kernfs_fop_write+0x1cc/0x1f8
    [ 4050.264963]  #2: 0000000034831ab8 (kn->count#297){++++}, at: kernfs_remove_self+0x12e/0x150
    [ 4050.264979]  #3: 00000000e152484f (&dev->mutex){....}, at: device_release_driver_internal+0x5c/0x268
    [ 4050.264993] Last Breaking-Event-Address:
    [ 4050.265002]  [<000000000017bbaa>] __might_sleep+0x72/0x90
    [ 4050.265010] irq event stamp: 7039
    [ 4050.265020] hardirqs last  enabled at (7047): [<00000000001cee7a>] console_unlock+0x6d2/0x740
    [ 4050.265029] hardirqs last disabled at (7054): [<00000000001ce87e>] console_unlock+0xd6/0x740
    [ 4050.265040] softirqs last  enabled at (6416): [<0000000000b8fe26>] __udelay+0xb6/0x100
    [ 4050.265049] softirqs last disabled at (6415): [<0000000000b8fe06>] __udelay+0x96/0x100
    [ 4050.265057] ---[ end trace d04a07d39d99a9f9 ]---
    
    Let's fix this as described in the article
    https://lwn.net/Articles/628628/.
    
    Signed-off-by: Farhan Ali <alifm@linux.ibm.com>
    [remove now redundant vfio_dev_present()]
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 00cf52ed901431742d4e516bd218ec93d58912fc
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Mar 22 15:07:11 2019 +0100

    nfsd: avoid uninitialized variable warning
    
    [ Upstream commit 0ab88ca4bcf18ba21058d8f19220f60afe0d34d8 ]
    
    clang warns that 'contextlen' may be accessed without an initialization:
    
    fs/nfsd/nfs4xdr.c:2911:9: error: variable 'contextlen' is uninitialized when used here [-Werror,-Wuninitialized]
                                                                    contextlen);
                                                                    ^~~~~~~~~~
    fs/nfsd/nfs4xdr.c:2424:16: note: initialize the variable 'contextlen' to silence this warning
            int contextlen;
                          ^
                           = 0
    
    Presumably this cannot happen, as FATTR4_WORD2_SECURITY_LABEL is
    set if CONFIG_NFSD_V4_SECURITY_LABEL is enabled.
    Adding another #ifdef like the other two in this function
    avoids the warning.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 82ade407ad3412084b3f388abbe2afa2bc170365
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Fri Apr 12 16:37:30 2019 -0400

    nfsd: allow fh_want_write to be called twice
    
    [ Upstream commit 0b8f62625dc309651d0efcb6a6247c933acd8b45 ]
    
    A fuzzer recently triggered lockdep warnings about potential sb_writers
    deadlocks caused by fh_want_write().
    
    Looks like we aren't careful to pair each fh_want_write() with an
    fh_drop_write().
    
    It's not normally a problem since fh_put() will call fh_drop_write() for
    us.  And was OK for NFSv3 where we'd do one operation that might call
    fh_want_write(), and then put the filehandle.
    
    But an NFSv4 protocol fuzzer can do weird things like call unlink twice
    in a compound, and then we get into trouble.
    
    I'm a little worried about this approach of just leaving everything to
    fh_put().  But I think there are probably a lot of
    fh_want_write()/fh_drop_write() imbalances so for now I think we need it
    to be more forgiving.
    
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a5ee124e47918b1905c1810236d4fb5f2c0bb85a
Author: Kirill Smelkov <kirr@nexedi.com>
Date:   Wed Mar 27 10:15:19 2019 +0000

    fuse: retrieve: cap requested size to negotiated max_write
    
    [ Upstream commit 7640682e67b33cab8628729afec8ca92b851394f ]
    
    FUSE filesystem server and kernel client negotiate during initialization
    phase, what should be the maximum write size the client will ever issue.
    Correspondingly the filesystem server then queues sys_read calls to read
    requests with buffer capacity large enough to carry request header + that
    max_write bytes. A filesystem server is free to set its max_write in
    anywhere in the range between [1*page, fc->max_pages*page]. In particular
    go-fuse[2] sets max_write by default as 64K, wheres default fc->max_pages
    corresponds to 128K. Libfuse also allows users to configure max_write, but
    by default presets it to possible maximum.
    
    If max_write is < fc->max_pages*page, and in NOTIFY_RETRIEVE handler we
    allow to retrieve more than max_write bytes, corresponding prepared
    NOTIFY_REPLY will be thrown away by fuse_dev_do_read, because the
    filesystem server, in full correspondence with server/client contract, will
    be only queuing sys_read with ~max_write buffer capacity, and
    fuse_dev_do_read throws away requests that cannot fit into server request
    buffer. In turn the filesystem server could get stuck waiting indefinitely
    for NOTIFY_REPLY since NOTIFY_RETRIEVE handler returned OK which is
    understood by clients as that NOTIFY_REPLY was queued and will be sent
    back.
    
    Cap requested size to negotiate max_write to avoid the problem.  This
    aligns with the way NOTIFY_RETRIEVE handler works, which already
    unconditionally caps requested retrieve size to fuse_conn->max_pages.  This
    way it should not hurt NOTIFY_RETRIEVE semantic if we return less data than
    was originally requested.
    
    Please see [1] for context where the problem of stuck filesystem was hit
    for real, how the situation was traced and for more involving patch that
    did not make it into the tree.
    
    [1] https://marc.info/?l=linux-fsdevel&m=155057023600853&w=2
    [2] https://github.com/hanwen/go-fuse
    
    Signed-off-by: Kirill Smelkov <kirr@nexedi.com>
    Cc: Han-Wen Nienhuys <hanwen@google.com>
    Cc: Jakob Unterwurzacher <jakobunt@gmail.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4c55b1f8795586f6b294ec28213dff76f921a969
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Sat Apr 13 11:32:53 2019 +0100

    nvmem: sunxi_sid: Support SID on A83T and H5
    
    [ Upstream commit da75b8909756160b8e785104ba421a20b756c975 ]
    
    The device tree binding already lists compatible strings for these two
    SoCs. They don't have the defect as seen on the H3, and the size and
    register layout is the same as the A64. Furthermore, the driver does
    not include nvmem cell definitions.
    
    Add support for these two compatible strings, re-using the config for
    the A64.
    
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f6fdf2d17af587ff8e54797709df9daed8a68004
Author: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
Date:   Sat Apr 13 11:32:58 2019 +0100

    nvmem: core: fix read buffer in place
    
    [ Upstream commit 2fe518fecb3a4727393be286db9804cd82ee2d91 ]
    
    When the bit_offset in the cell is zero, the pointer to the msb will
    not be properly initialized (ie, will still be pointing to the first
    byte in the buffer).
    
    This being the case, if there are bits to clear in the msb, those will
    be left untouched while the mask will incorrectly clear bit positions
    on the first byte.
    
    This commit also makes sure that any byte unused in the cell is
    cleared.
    
    Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a5fd4faa8766827f9b02cf114b73a056e6720dc
Author: Lu Baolu <baolu.lu@linux.intel.com>
Date:   Fri Apr 19 14:43:29 2019 +0800

    iommu/vt-d: Don't request page request irq under dmar_global_lock
    
    [ Upstream commit a7755c3cfa5df755e39447b08c28203e011fb98c ]
    
    Requesting page reqest irq under dmar_global_lock could cause
    potential lock race condition (caught by lockdep).
    
    [    4.100055] ======================================================
    [    4.100063] WARNING: possible circular locking dependency detected
    [    4.100072] 5.1.0-rc4+ #2169 Not tainted
    [    4.100078] ------------------------------------------------------
    [    4.100086] swapper/0/1 is trying to acquire lock:
    [    4.100094] 000000007dcbe3c3 (dmar_lock){+.+.}, at: dmar_alloc_hwirq+0x35/0x140
    [    4.100112] but task is already holding lock:
    [    4.100120] 0000000060bbe946 (dmar_global_lock){++++}, at: intel_iommu_init+0x191/0x1438
    [    4.100136] which lock already depends on the new lock.
    [    4.100146] the existing dependency chain (in reverse order) is:
    [    4.100155]
                   -> #2 (dmar_global_lock){++++}:
    [    4.100169]        down_read+0x44/0xa0
    [    4.100178]        intel_irq_remapping_alloc+0xb2/0x7b0
    [    4.100186]        mp_irqdomain_alloc+0x9e/0x2e0
    [    4.100195]        __irq_domain_alloc_irqs+0x131/0x330
    [    4.100203]        alloc_isa_irq_from_domain.isra.4+0x9a/0xd0
    [    4.100212]        mp_map_pin_to_irq+0x244/0x310
    [    4.100221]        setup_IO_APIC+0x757/0x7ed
    [    4.100229]        x86_late_time_init+0x17/0x1c
    [    4.100238]        start_kernel+0x425/0x4e3
    [    4.100247]        secondary_startup_64+0xa4/0xb0
    [    4.100254]
                   -> #1 (irq_domain_mutex){+.+.}:
    [    4.100265]        __mutex_lock+0x7f/0x9d0
    [    4.100273]        __irq_domain_add+0x195/0x2b0
    [    4.100280]        irq_domain_create_hierarchy+0x3d/0x40
    [    4.100289]        msi_create_irq_domain+0x32/0x110
    [    4.100297]        dmar_alloc_hwirq+0x111/0x140
    [    4.100305]        dmar_set_interrupt.part.14+0x1a/0x70
    [    4.100314]        enable_drhd_fault_handling+0x2c/0x6c
    [    4.100323]        apic_bsp_setup+0x75/0x7a
    [    4.100330]        x86_late_time_init+0x17/0x1c
    [    4.100338]        start_kernel+0x425/0x4e3
    [    4.100346]        secondary_startup_64+0xa4/0xb0
    [    4.100352]
                   -> #0 (dmar_lock){+.+.}:
    [    4.100364]        lock_acquire+0xb4/0x1c0
    [    4.100372]        __mutex_lock+0x7f/0x9d0
    [    4.100379]        dmar_alloc_hwirq+0x35/0x140
    [    4.100389]        intel_svm_enable_prq+0x61/0x180
    [    4.100397]        intel_iommu_init+0x1128/0x1438
    [    4.100406]        pci_iommu_init+0x16/0x3f
    [    4.100414]        do_one_initcall+0x5d/0x2be
    [    4.100422]        kernel_init_freeable+0x1f0/0x27c
    [    4.100431]        kernel_init+0xa/0x110
    [    4.100438]        ret_from_fork+0x3a/0x50
    [    4.100444]
                   other info that might help us debug this:
    
    [    4.100454] Chain exists of:
                     dmar_lock --> irq_domain_mutex --> dmar_global_lock
    [    4.100469]  Possible unsafe locking scenario:
    
    [    4.100476]        CPU0                    CPU1
    [    4.100483]        ----                    ----
    [    4.100488]   lock(dmar_global_lock);
    [    4.100495]                                lock(irq_domain_mutex);
    [    4.100503]                                lock(dmar_global_lock);
    [    4.100512]   lock(dmar_lock);
    [    4.100518]
                    *** DEADLOCK ***
    
    Cc: Ashok Raj <ashok.raj@intel.com>
    Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
    Cc: Kevin Tian <kevin.tian@intel.com>
    Reported-by: Dave Jiang <dave.jiang@intel.com>
    Fixes: a222a7f0bb6c9 ("iommu/vt-d: Implement page request handling")
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3b837ba07c5da6ecc3eb84f548fa51b0cbdadfee
Author: Valentin Schneider <valentin.schneider@arm.com>
Date:   Tue Apr 16 18:02:21 2019 +0100

    arm64: defconfig: Update UFSHCD for Hi3660 soc
    
    [ Upstream commit 7b3320e6b1795d68b7e30eb3fad0860f2664aedd ]
    
    Commit 7ee7ef24d02d ("scsi: arm64: defconfig: enable configs for Hisilicon ufs")
    set 'CONFIG_SCSI_UFS_HISI=y', but the configs it depends
    on
    
      (CONFIG_SCSI_HFSHCD_PLATFORM && CONFIG_SCSI_UFSHCD)
    
    were left to being built as modules.
    
    Commit 1f4fa50dd48f ("arm64: defconfig: Regenerate for v4.20") "fixed"
    that by reverting to 'CONFIG_SCSI_UFS_HISI=m'.
    
    Thing is, if the rootfs is stored in the on-board flash (which
    is the "canonical" way of doing things), we either need these drivers
    to be built-in, or we need to fiddle with an initramfs to access that
    flash and eventually load the modules installed over there.
    
    The former is the easiest, do that.
    
    Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
    Reviewed-by: Leo Yan <leo.yan@linaro.org>
    Signed-off-by: Olof Johansson <olof@lixom.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7bd4b91a224b70a3762830172d00daf14f55da41
Author: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Date:   Tue Oct 2 10:35:59 2018 -0500

    powerpc/pseries: Track LMB nid instead of using device tree
    
    [ Upstream commit b2d3b5ee66f2a04a918cc043cec0c9ed3de58f40 ]
    
    When removing memory we need to remove the memory from the node
    it was added to instead of looking up the node it should be in
    in the device tree.
    
    During testing we have seen scenarios where the affinity for a
    LMB changes due to a partition migration or PRRN event. In these
    cases the node the LMB exists in may not match the node the device
    tree indicates it belongs in. This can lead to a system crash
    when trying to DLPAR remove the LMB after a migration or PRRN
    event. The current code looks up the node in the device tree to
    remove the LMB from, the crash occurs when we try to offline this
    node and it does not have any data, i.e. node_data[nid] == NULL.
    
    36:mon> e
    cpu 0x36: Vector: 300 (Data Access) at [c0000001828b7810]
        pc: c00000000036d08c: try_offline_node+0x2c/0x1b0
        lr: c0000000003a14ec: remove_memory+0xbc/0x110
        sp: c0000001828b7a90
       msr: 800000000280b033
       dar: 9a28
     dsisr: 40000000
      current = 0xc0000006329c4c80
      paca    = 0xc000000007a55200   softe: 0        irq_happened: 0x01
        pid   = 76926, comm = kworker/u320:3
    
    36:mon> t
    [link register   ] c0000000003a14ec remove_memory+0xbc/0x110
    [c0000001828b7a90] c00000000006a1cc arch_remove_memory+0x9c/0xd0 (unreliable)
    [c0000001828b7ad0] c0000000003a14e0 remove_memory+0xb0/0x110
    [c0000001828b7b20] c0000000000c7db4 dlpar_remove_lmb+0x94/0x160
    [c0000001828b7b60] c0000000000c8ef8 dlpar_memory+0x7e8/0xd10
    [c0000001828b7bf0] c0000000000bf828 handle_dlpar_errorlog+0xf8/0x160
    [c0000001828b7c60] c0000000000bf8cc pseries_hp_work_fn+0x3c/0xa0
    [c0000001828b7c90] c000000000128cd8 process_one_work+0x298/0x5a0
    [c0000001828b7d20] c000000000129068 worker_thread+0x88/0x620
    [c0000001828b7dc0] c00000000013223c kthread+0x1ac/0x1c0
    [c0000001828b7e30] c00000000000b45c ret_from_kernel_thread+0x5c/0x80
    
    To resolve this we need to track the node a LMB belongs to when
    it is added to the system so we can remove it from that node instead
    of the node that the device tree indicates it should belong to.
    
    Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 996fffea2efc7ee8e2b013b737b14e255568d88d
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Apr 30 12:18:28 2019 +0200

    ALSA: hda - Register irq handler after the chip initialization
    
    [ Upstream commit f495222e28275222ab6fd93813bd3d462e16d340 ]
    
    Currently the IRQ handler in HD-audio controller driver is registered
    before the chip initialization.  That is, we have some window opened
    between the azx_acquire_irq() call and the CORB/RIRB setup.  If an
    interrupt is triggered in this small window, the IRQ handler may
    access to the uninitialized RIRB buffer, which leads to a NULL
    dereference Oops.
    
    This is usually no big problem since most of Intel chips do register
    the IRQ via MSI, and we've already fixed the order of the IRQ
    enablement and the CORB/RIRB setup in the former commit b61749a89f82
    ("sound: enable interrupt after dma buffer initialization"), hence the
    IRQ won't be triggered in that room.  However, some platforms use a
    shared IRQ, and this may allow the IRQ trigger by another source.
    
    Another possibility is the kdump environment: a stale interrupt might
    be present in there, the IRQ handler can be falsely triggered as well.
    
    For covering this small race, let's move the azx_acquire_irq() call
    after hda_intel_init_chip() call.  Although this is a bit radical
    change, it can cover more widely than checking the CORB/RIRB setup
    locally in the callee side.
    
    Reported-by: Liwei Song <liwei.song@windriver.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 11ae693f445fd1515b84c86a5d5d57447a78a583
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Tue Apr 30 01:55:29 2019 +0900

    netfilter: nf_flow_table: fix netdev refcnt leak
    
    [ Upstream commit 26a302afbe328ecb7507cae2035d938e6635131b ]
    
    flow_offload_alloc() calls nf_route() to get a dst_entry. Internally,
    nf_route() calls ip_route_output_key() that allocates a dst_entry and
    holds it. So, a dst_entry should be released by dst_release() if
    nf_route() is successful.
    
    Otherwise, netns exit routine cannot be finished and the following
    message is printed:
    
    [  257.490952] unregister_netdevice: waiting for lo to become free. Usage count = 1
    
    Fixes: ac2a66665e23 ("netfilter: add generic flow table infrastructure")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c155f374d89ea0444729e7484181ffcc623f4b2b
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Tue Apr 30 01:55:54 2019 +0900

    netfilter: nf_flow_table: check ttl value in flow offload data path
    
    [ Upstream commit 33cc3c0cfa64c86b6c4bbee86997aea638534931 ]
    
    nf_flow_offload_ip_hook() and nf_flow_offload_ipv6_hook() do not check
    ttl value. So, ttl value overflow may occur.
    
    Fixes: 97add9f0d66d ("netfilter: flow table support for IPv4")
    Fixes: 0995210753a2 ("netfilter: flow table support for IPv6")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c6508f86f9398fed1bd0206f6c9f1e8d2b45c20f
Author: Keith Busch <keith.busch@intel.com>
Date:   Tue Apr 30 09:33:40 2019 -0600

    nvme-pci: shutdown on timeout during deletion
    
    [ Upstream commit 9dc1a38ef1925d23c2933c5867df816386d92ff8 ]
    
    We do not restart a controller in a deleting state for timeout errors.
    When in this state, unblock potential request dispatchers with failed
    completions by shutting down the controller on timeout detection.
    
    Reported-by: Yufen Yu <yuyufen@huawei.com>
    Signed-off-by: Keith Busch <keith.busch@intel.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca6bcc0354532f4c40249ab90c54ac44987e80bd
Author: Keith Busch <keith.busch@intel.com>
Date:   Tue Apr 30 09:33:41 2019 -0600

    nvme-pci: unquiesce admin queue on shutdown
    
    [ Upstream commit c8e9e9b7646ebe1c5066ddc420d7630876277eb4 ]
    
    Just like IO queues, the admin queue also will not be restarted after a
    controller shutdown. Unquiesce this queue so that we do not block
    request dispatch on a permanently disabled controller.
    
    Reported-by: Yufen Yu <yuyufen@huawei.com>
    Signed-off-by: Keith Busch <keith.busch@intel.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d6f90faeec9a2e231ad1b355fe8fd239913e0cdd
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date:   Mon Mar 25 15:09:45 2019 +0530

    PCI: designware-ep: Use aligned ATU window for raising MSI interrupts
    
    [ Upstream commit 6b7330303a8186fb211357e6d379237fe9d2ece1 ]
    
    Certain platforms like K2G reguires the outbound ATU window to be
    aligned. The alignment size is already present in mem->page_size.
    Use the alignment size present in mem->page_size to configure an
    aligned ATU window. In order to raise an interrupt, CPU has to write
    to address offset from the start of the window unlike before where
    writes were always to the beginning of the ATU window.
    
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 449b9fd4650447debccf4967ef62011093eb4327
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date:   Mon Mar 25 15:09:47 2019 +0530

    misc: pci_endpoint_test: Fix test_reg_bar to be updated in pci_endpoint_test
    
    [ Upstream commit 8f220664570e755946db1282f48e07f26e1f2cb4 ]
    
    commit 834b90519925 ("misc: pci_endpoint_test: Add support for
    PCI_ENDPOINT_TEST regs to be mapped to any BAR") while adding
    test_reg_bar in order to map PCI_ENDPOINT_TEST regs to be mapped to any
    BAR failed to update test_reg_bar in pci_endpoint_test, resulting in
    test_reg_bar having invalid value when used outside probe.
    
    Fix it.
    
    Fixes: 834b90519925 ("misc: pci_endpoint_test: Add support for PCI_ENDPOINT_TEST regs to be mapped to any BAR")
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dcaa5e20015d63a1dd3bf1c2dd1c56d83010cd10
Author: Greg Kurz <groug@kaod.org>
Date:   Fri Apr 19 17:37:17 2019 +0200

    vfio-pci/nvlink2: Fix potential VMA leak
    
    [ Upstream commit 2c85f2bd519457073444ec28bbb4743a4e4237a7 ]
    
    If vfio_pci_register_dev_region() fails then we should rollback
    previous changes, ie. unmap the ATSD registers.
    
    Fixes: 7f92891778df ("vfio_pci: Add NVIDIA GV100GL [Tesla V100 SXM2] subdriver")
    Signed-off-by: Greg Kurz <groug@kaod.org>
    Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 47e8097870ee4abdde1f77a4ccb033f88b0e24ad
Author: Lu Baolu <baolu.lu@linux.intel.com>
Date:   Thu May 2 09:34:25 2019 +0800

    iommu/vt-d: Set intel_iommu_gfx_mapped correctly
    
    [ Upstream commit cf1ec4539a50bdfe688caad4615ca47646884316 ]
    
    The intel_iommu_gfx_mapped flag is exported by the Intel
    IOMMU driver to indicate whether an IOMMU is used for the
    graphic device. In a virtualized IOMMU environment (e.g.
    QEMU), an include-all IOMMU is used for graphic device.
    This flag is found to be clear even the IOMMU is used.
    
    Cc: Ashok Raj <ashok.raj@intel.com>
    Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
    Cc: Kevin Tian <kevin.tian@intel.com>
    Reported-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Fixes: c0771df8d5297 ("intel-iommu: Export a flag indicating that the IOMMU is used for iGFX.")
    Suggested-by: Kevin Tian <kevin.tian@intel.com>
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9e2c1b3d0d5820faa4c83badf30e40b5b7e90984
Author: Ming Lei <ming.lei@redhat.com>
Date:   Tue Apr 30 09:52:24 2019 +0800

    blk-mq: move cancel of requeue_work into blk_mq_release
    
    [ Upstream commit fbc2a15e3433058582e5635aabe48a3011a644a8 ]
    
    With holding queue's kobject refcount, it is safe for driver
    to schedule requeue. However, blk_mq_kick_requeue_list() may
    be called after blk_sync_queue() is done because of concurrent
    requeue activities, then requeue work may not be completed when
    freeing queue, and kernel oops is triggered.
    
    So moving the cancel of requeue_work into blk_mq_release() for
    avoiding race between requeue and freeing queue.
    
    Cc: Dongli Zhang <dongli.zhang@oracle.com>
    Cc: James Smart <james.smart@broadcom.com>
    Cc: Bart Van Assche <bart.vanassche@wdc.com>
    Cc: linux-scsi@vger.kernel.org,
    Cc: Martin K . Petersen <martin.petersen@oracle.com>,
    Cc: Christoph Hellwig <hch@lst.de>,
    Cc: James E . J . Bottomley <jejb@linux.vnet.ibm.com>,
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Tested-by: James Smart <james.smart@broadcom.com>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b6349c8814ef87cc16454084b6474c43fe3a878
Author: Vladimir Zapolskiy <vz@mleia.com>
Date:   Tue Mar 12 01:54:25 2019 +0200

    watchdog: fix compile time error of pretimeout governors
    
    [ Upstream commit a223770bfa7b6647f3a70983257bd89f9cafce46 ]
    
    CONFIG_WATCHDOG_PRETIMEOUT_GOV build symbol adds watchdog_pretimeout.o
    object to watchdog.o, the latter is compiled only if CONFIG_WATCHDOG_CORE
    is selected, so it rightfully makes sense to add it as a dependency.
    
    The change fixes the next compilation errors, if CONFIG_WATCHDOG_CORE=n
    and CONFIG_WATCHDOG_PRETIMEOUT_GOV=y are selected:
    
      drivers/watchdog/pretimeout_noop.o: In function `watchdog_gov_noop_register':
      drivers/watchdog/pretimeout_noop.c:35: undefined reference to `watchdog_register_governor'
      drivers/watchdog/pretimeout_noop.o: In function `watchdog_gov_noop_unregister':
      drivers/watchdog/pretimeout_noop.c:40: undefined reference to `watchdog_unregister_governor'
    
      drivers/watchdog/pretimeout_panic.o: In function `watchdog_gov_panic_register':
      drivers/watchdog/pretimeout_panic.c:35: undefined reference to `watchdog_register_governor'
      drivers/watchdog/pretimeout_panic.o: In function `watchdog_gov_panic_unregister':
      drivers/watchdog/pretimeout_panic.c:40: undefined reference to `watchdog_unregister_governor'
    
    Reported-by: Kuo, Hsuan-Chi <hckuo2@illinois.edu>
    Fixes: ff84136cb6a4 ("watchdog: add watchdog pretimeout governor framework")
    Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 81a0eaaae1816a844aff5013177834c12b8afe56
Author: Georg Hofmann <georg@hofmannsweb.com>
Date:   Mon Apr 8 21:25:54 2019 +0200

    watchdog: imx2_wdt: Fix set_timeout for big timeout values
    
    [ Upstream commit b07e228eee69601addba98b47b1a3850569e5013 ]
    
    The documentated behavior is: if max_hw_heartbeat_ms is implemented, the
    minimum of the set_timeout argument and max_hw_heartbeat_ms should be used.
    This patch implements this behavior.
    Previously only the first 7bits were used and the input argument was
    returned.
    
    Signed-off-by: Georg Hofmann <georg@hofmannsweb.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1f46894280cfe406fb0be9ccd088fd6b73b93053
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Apr 30 14:33:22 2019 +0200

    netfilter: nf_tables: fix base chain stat rcu_dereference usage
    
    [ Upstream commit edbd82c5fba009f68d20b5db585be1e667c605f6 ]
    
    Following splat gets triggered when nfnetlink monitor is running while
    xtables-nft selftests are running:
    
    net/netfilter/nf_tables_api.c:1272 suspicious rcu_dereference_check() usage!
    other info that might help us debug this:
    
    1 lock held by xtables-nft-mul/27006:
     #0: 00000000e0f85be9 (&net->nft.commit_mutex){+.+.}, at: nf_tables_valid_genid+0x1a/0x50
    Call Trace:
     nf_tables_fill_chain_info.isra.45+0x6cc/0x6e0
     nf_tables_chain_notify+0xf8/0x1a0
     nf_tables_commit+0x165c/0x1740
    
    nf_tables_fill_chain_info() can be called both from dumps (rcu read locked)
    or from the transaction path if a userspace process subscribed to nftables
    notifications.
    
    In the 'table dump' case, rcu_access_pointer() cannot be used: We do not
    hold transaction mutex so the pointer can be NULLed right after the check.
    Just unconditionally fetch the value, then have the helper return
    immediately if its NULL.
    
    In the notification case we don't hold the rcu read lock, but updates are
    prevented due to transaction mutex. Use rcu_dereference_check() to make lockdep
    aware of this.
    
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b0e7ae14eb66391a01efe89a63f5fbac5604f4ac
Author: Serge Semin <fancer.lancer@gmail.com>
Date:   Fri May 3 20:50:40 2019 +0300

    mips: Make sure dt memory regions are valid
    
    [ Upstream commit 93fa5b280761a4dbb14c5330f260380385ab2b49 ]
    
    There are situations when memory regions coming from dts may be
    too big for the platform physical address space. This especially
    concerns XPA-capable systems. Bootloader may determine more than 4GB
    memory available and pass it to the kernel over dts memory node, while
    kernel is built without XPA/64BIT support. In this case the region
    may either simply be truncated by add_memory_region() method
    or by u64->phys_addr_t type casting. But in worst case the method
    can even drop the memory region if it exceeds PHYS_ADDR_MAX size.
    So lets make sure the retrieved from dts memory regions are valid,
    and if some of them aren't, just manually truncate them with a warning
    printed out.
    
    Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: James Hogan <jhogan@kernel.org>
    Cc: Mike Rapoport <rppt@linux.ibm.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Thomas Bogendoerfer <tbogendoerfer@suse.de>
    Cc: Huacai Chen <chenhc@lemote.com>
    Cc: Stefan Agner <stefan@agner.ch>
    Cc: Stephen Rothwell <sfr@canb.auug.org.au>
    Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Cc: Juergen Gross <jgross@suse.com>
    Cc: Serge Semin <Sergey.Semin@t-platforms.ru>
    Cc: linux-mips@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 58c8298cad9ade78260eec920c2669c76bb9bf4d
Author: Jakub Jankowski <shasta@toxcorp.com>
Date:   Thu Apr 25 23:46:50 2019 +0200

    netfilter: nf_conntrack_h323: restore boundary check correctness
    
    [ Upstream commit f5e85ce8e733c2547827f6268136b70b802eabdb ]
    
    Since commit bc7d811ace4a ("netfilter: nf_ct_h323: Convert
    CHECK_BOUND macro to function"), NAT traversal for H.323
    doesn't work, failing to parse H323-UserInformation.
    nf_h323_error_boundary() compares contents of the bitstring,
    not the addresses, preventing valid H.323 packets from being
    conntrack'd.
    
    This looks like an oversight from when CHECK_BOUND macro was
    converted to a function.
    
    To fix it, stop dereferencing bs->cur and bs->end.
    
    Fixes: bc7d811ace4a ("netfilter: nf_ct_h323: Convert CHECK_BOUND macro to function")
    Signed-off-by: Jakub Jankowski <shasta@toxcorp.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d34b034dc36bc553ddb337ba7f4d344288100137
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Fri May 3 01:56:38 2019 +0900

    netfilter: nf_flow_table: fix missing error check for rhashtable_insert_fast
    
    [ Upstream commit 43c8f131184faf20c07221f3e09724611c6525d8 ]
    
    rhashtable_insert_fast() may return an error value when memory
    allocation fails, but flow_offload_add() does not check for errors.
    This patch just adds missing error checking.
    
    Fixes: ac2a66665e23 ("netfilter: add generic flow table infrastructure")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit db8ca7fdb8b840f78f70d208671f6af06684b26a
Author: Ludovic Barre <ludovic.barre@st.com>
Date:   Fri Apr 26 09:46:35 2019 +0200

    mmc: mmci: Prevent polling for busy detection in IRQ context
    
    [ Upstream commit 8520ce1e17799b220ff421d4f39438c9c572ade3 ]
    
    The IRQ handler, mmci_irq(), loops until all status bits have been cleared.
    However, the status bit signaling busy in variant->busy_detect_flag, may be
    set even if busy detection isn't monitored for the current request.
    
    This may be the case for the CMD11 when switching the I/O voltage, which
    leads to that mmci_irq() busy loops in IRQ context. Fix this problem, by
    clearing the status bit for busy, before continuing to validate the
    condition for the loop. This is safe, because the busy status detection has
    already been taken care of by mmci_cmd_irq().
    
    Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f2ab446fe90f463fedabf06b194b1e5b8b31d736
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Wed Apr 24 19:39:50 2019 +0300

    ovl: do not generate duplicate fsnotify events for "fake" path
    
    [ Upstream commit d989903058a83e8536cc7aadf9256a47d5c173fe ]
    
    Overlayfs "fake" path is used for stacked file operations on underlying
    files.  Operations on files with "fake" path must not generate fsnotify
    events with path data, because those events have already been generated at
    overlayfs layer and because the reported event->fd for fanotify marks on
    underlying inode/filesystem will have the wrong path (the overlayfs path).
    
    Link: https://lore.kernel.org/linux-fsdevel/20190423065024.12695-1-jencce.kernel@gmail.com/
    Reported-by: Murphy Zhou <jencce.kernel@gmail.com>
    Fixes: d1d04ef8572b ("ovl: stack file ops")
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6aaaa535ba448abe2c770fdb09b66d66fa72ea3a
Author: Andreas Schwab <schwab@linux-m68k.org>
Date:   Mon May 6 15:57:47 2019 +0200

    fbcon: Don't reset logo_shown when logo is currently shown
    
    [ Upstream commit 3c5a1b111373e669c8220803464c3a508a87e254 ]
    
    When the logo is currently drawn on a virtual console, and the console
    loglevel is reduced to quiet, logo_shown must be left alone, so that it
    the scrolling region on that virtual console is properly reset.
    
    Fixes: 10993504d647 ("fbcon: Silence fbcon logo on 'quiet' boots")
    Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Yisheng Xie <ysxie@foxmail.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Marko Myllynen <myllynen@redhat.com>
    Cc: Hans de Goede <hdegoede@redhat.com>
    Cc: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62729638350372308e50de4b526b610752d0c0ae
Author: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Date:   Fri Mar 29 11:57:17 2019 +0000

    PCI: dwc: Free MSI IRQ page in dw_pcie_free_msi()
    
    [ Upstream commit dc69a3d567941784c3d00e1d0834582b42b0b3e7 ]
    
    To avoid a memory leak, free the page allocated for MSI IRQ in
    dw_pcie_free_msi().
    
    Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2507c7c9744fdb2f3991224b50dd54c271357fa3
Author: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Date:   Fri Mar 29 11:57:54 2019 +0000

    PCI: dwc: Free MSI in dw_pcie_host_init() error path
    
    [ Upstream commit 9e2b5de5604a6ff2626c51e77014d92c9299722c ]
    
    If we ever did MSI-related initializations, we need to call
    dw_pcie_free_msi() in the error code path.
    
    Remove the IS_ENABLED(CONFIG_PCI_MSI) check for MSI init because
    pci_msi_enabled() already has a stub for !CONFIG_PCI_MSI.
    
    Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 84e5ca83b1ed5f2041c7644d1e508e44ccec77bb
Author: Maciej Żenczykowski <maze@google.com>
Date:   Wed Apr 10 11:11:23 2019 -0700

    uml: fix a boot splat wrt use of cpu_all_mask
    
    [ Upstream commit 689a58605b63173acb0a8cf954af6a8f60440c93 ]
    
    Memory: 509108K/542612K available (3835K kernel code, 919K rwdata, 1028K rodata, 129K init, 211K bss, 33504K reserved, 0K cma-reserved)
    NR_IRQS: 15
    clocksource: timer: mask: 0xffffffffffffffff max_cycles: 0x1cd42e205, max_idle_ns: 881590404426 ns
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 0 at kernel/time/clockevents.c:458 clockevents_register_device+0x72/0x140
    posix-timer cpumask == cpu_all_mask, using cpu_possible_mask instead
    Modules linked in:
    CPU: 0 PID: 0 Comm: swapper Not tainted 5.1.0-rc4-00048-ged79cc87302b #4
    Stack:
     604ebda0 603c5370 604ebe20 6046fd17
     00000000 6006fcbb 604ebdb0 603c53b5
     604ebe10 6003bfc4 604ebdd0 9000001ca
    Call Trace:
     [<6006fcbb>] ? printk+0x0/0x94
     [<60083160>] ? clockevents_register_device+0x72/0x140
     [<6001f16e>] show_stack+0x13b/0x155
     [<603c5370>] ? dump_stack_print_info+0xe2/0xeb
     [<6006fcbb>] ? printk+0x0/0x94
     [<603c53b5>] dump_stack+0x2a/0x2c
     [<6003bfc4>] __warn+0x10e/0x13e
     [<60070320>] ? vprintk_func+0xc8/0xcf
     [<60030fd6>] ? block_signals+0x0/0x16
     [<6006fcbb>] ? printk+0x0/0x94
     [<6003c08b>] warn_slowpath_fmt+0x97/0x99
     [<600311a1>] ? set_signals+0x0/0x3f
     [<6003bff4>] ? warn_slowpath_fmt+0x0/0x99
     [<600842cb>] ? tick_oneshot_mode_active+0x44/0x4f
     [<60030fd6>] ? block_signals+0x0/0x16
     [<6006fcbb>] ? printk+0x0/0x94
     [<6007d2d5>] ? __clocksource_select+0x20/0x1b1
     [<60030fd6>] ? block_signals+0x0/0x16
     [<6006fcbb>] ? printk+0x0/0x94
     [<60083160>] clockevents_register_device+0x72/0x140
     [<60031192>] ? get_signals+0x0/0xf
     [<60030fd6>] ? block_signals+0x0/0x16
     [<6006fcbb>] ? printk+0x0/0x94
     [<60002eec>] um_timer_setup+0xc8/0xca
     [<60001b59>] start_kernel+0x47f/0x57e
     [<600035bc>] start_kernel_proc+0x49/0x4d
     [<6006c483>] ? kmsg_dump_register+0x82/0x8a
     [<6001de62>] new_thread_handler+0x81/0xb2
     [<60003571>] ? kmsg_dumper_stdout_init+0x1a/0x1c
     [<60020c75>] uml_finishsetup+0x54/0x59
    
    random: get_random_bytes called from init_oops_id+0x27/0x34 with crng_init=0
    ---[ end trace 00173d0117a88acb ]---
    Calibrating delay loop... 6941.90 BogoMIPS (lpj=34709504)
    
    Signed-off-by: Maciej Żenczykowski <maze@google.com>
    Cc: Jeff Dike <jdike@addtoit.com>
    Cc: Richard Weinberger <richard@nod.at>
    Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
    Cc: linux-um@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 93e0a6661a295f25acc01b316756131739595397
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Sun May 5 11:03:12 2019 +0800

    configfs: fix possible use-after-free in configfs_register_group
    
    [ Upstream commit 35399f87e271f7cf3048eab00a421a6519ac8441 ]
    
    In configfs_register_group(), if create_default_group() failed, we
    forget to unlink the group. It will left a invalid item in the parent list,
    which may trigger the use-after-free issue seen below:
    
    BUG: KASAN: use-after-free in __list_add_valid+0xd4/0xe0 lib/list_debug.c:26
    Read of size 8 at addr ffff8881ef61ae20 by task syz-executor.0/5996
    
    CPU: 1 PID: 5996 Comm: syz-executor.0 Tainted: G         C        5.0.0+ #5
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0xa9/0x10e lib/dump_stack.c:113
     print_address_description+0x65/0x270 mm/kasan/report.c:187
     kasan_report+0x149/0x18d mm/kasan/report.c:317
     __list_add_valid+0xd4/0xe0 lib/list_debug.c:26
     __list_add include/linux/list.h:60 [inline]
     list_add_tail include/linux/list.h:93 [inline]
     link_obj+0xb0/0x190 fs/configfs/dir.c:759
     link_group+0x1c/0x130 fs/configfs/dir.c:784
     configfs_register_group+0x56/0x1e0 fs/configfs/dir.c:1751
     configfs_register_default_group+0x72/0xc0 fs/configfs/dir.c:1834
     ? 0xffffffffc1be0000
     iio_sw_trigger_init+0x23/0x1000 [industrialio_sw_trigger]
     do_one_initcall+0xbc/0x47d init/main.c:887
     do_init_module+0x1b5/0x547 kernel/module.c:3456
     load_module+0x6405/0x8c10 kernel/module.c:3804
     __do_sys_finit_module+0x162/0x190 kernel/module.c:3898
     do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x462e99
    Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f494ecbcc58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
    RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
    RDX: 0000000000000000 RSI: 0000000020000180 RDI: 0000000000000003
    RBP: 00007f494ecbcc70 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007f494ecbd6bc
    R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
    
    Allocated by task 5987:
     set_track mm/kasan/common.c:87 [inline]
     __kasan_kmalloc.constprop.3+0xa0/0xd0 mm/kasan/common.c:497
     kmalloc include/linux/slab.h:545 [inline]
     kzalloc include/linux/slab.h:740 [inline]
     configfs_register_default_group+0x4c/0xc0 fs/configfs/dir.c:1829
     0xffffffffc1bd0023
     do_one_initcall+0xbc/0x47d init/main.c:887
     do_init_module+0x1b5/0x547 kernel/module.c:3456
     load_module+0x6405/0x8c10 kernel/module.c:3804
     __do_sys_finit_module+0x162/0x190 kernel/module.c:3898
     do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    Freed by task 5987:
     set_track mm/kasan/common.c:87 [inline]
     __kasan_slab_free+0x130/0x180 mm/kasan/common.c:459
     slab_free_hook mm/slub.c:1429 [inline]
     slab_free_freelist_hook mm/slub.c:1456 [inline]
     slab_free mm/slub.c:3003 [inline]
     kfree+0xe1/0x270 mm/slub.c:3955
     configfs_register_default_group+0x9a/0xc0 fs/configfs/dir.c:1836
     0xffffffffc1bd0023
     do_one_initcall+0xbc/0x47d init/main.c:887
     do_init_module+0x1b5/0x547 kernel/module.c:3456
     load_module+0x6405/0x8c10 kernel/module.c:3804
     __do_sys_finit_module+0x162/0x190 kernel/module.c:3898
     do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    The buggy address belongs to the object at ffff8881ef61ae00
     which belongs to the cache kmalloc-192 of size 192
    The buggy address is located 32 bytes inside of
     192-byte region [ffff8881ef61ae00, ffff8881ef61aec0)
    The buggy address belongs to the page:
    page:ffffea0007bd8680 count:1 mapcount:0 mapping:ffff8881f6c03000 index:0xffff8881ef61a700
    flags: 0x2fffc0000000200(slab)
    raw: 02fffc0000000200 ffffea0007ca4740 0000000500000005 ffff8881f6c03000
    raw: ffff8881ef61a700 000000008010000c 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff8881ef61ad00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     ffff8881ef61ad80: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
    >ffff8881ef61ae00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                   ^
     ffff8881ef61ae80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
     ffff8881ef61af00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    
    Fixes: 5cf6a51e6062 ("configfs: allow dynamic group creation")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit da0abba5766fb85a464f796df6d7531cde27ad5a
Author: John Sperbeck <jsperbeck@google.com>
Date:   Tue May 7 18:43:20 2019 -0700

    percpu: remove spurious lock dependency between percpu and sched
    
    [ Upstream commit 198790d9a3aeaef5792d33a560020861126edc22 ]
    
    In free_percpu() we sometimes call pcpu_schedule_balance_work() to
    queue a work item (which does a wakeup) while holding pcpu_lock.
    This creates an unnecessary lock dependency between pcpu_lock and
    the scheduler's pi_lock.  There are other places where we call
    pcpu_schedule_balance_work() without hold pcpu_lock, and this case
    doesn't need to be different.
    
    Moving the call outside the lock prevents the following lockdep splat
    when running tools/testing/selftests/bpf/{test_maps,test_progs} in
    sequence with lockdep enabled:
    
    ======================================================
    WARNING: possible circular locking dependency detected
    5.1.0-dbg-DEV #1 Not tainted
    ------------------------------------------------------
    kworker/23:255/18872 is trying to acquire lock:
    000000000bc79290 (&(&pool->lock)->rlock){-.-.}, at: __queue_work+0xb2/0x520
    
    but task is already holding lock:
    00000000e3e7a6aa (pcpu_lock){..-.}, at: free_percpu+0x36/0x260
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #4 (pcpu_lock){..-.}:
           lock_acquire+0x9e/0x180
           _raw_spin_lock_irqsave+0x3a/0x50
           pcpu_alloc+0xfa/0x780
           __alloc_percpu_gfp+0x12/0x20
           alloc_htab_elem+0x184/0x2b0
           __htab_percpu_map_update_elem+0x252/0x290
           bpf_percpu_hash_update+0x7c/0x130
           __do_sys_bpf+0x1912/0x1be0
           __x64_sys_bpf+0x1a/0x20
           do_syscall_64+0x59/0x400
           entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    -> #3 (&htab->buckets[i].lock){....}:
           lock_acquire+0x9e/0x180
           _raw_spin_lock_irqsave+0x3a/0x50
           htab_map_update_elem+0x1af/0x3a0
    
    -> #2 (&rq->lock){-.-.}:
           lock_acquire+0x9e/0x180
           _raw_spin_lock+0x2f/0x40
           task_fork_fair+0x37/0x160
           sched_fork+0x211/0x310
           copy_process.part.43+0x7b1/0x2160
           _do_fork+0xda/0x6b0
           kernel_thread+0x29/0x30
           rest_init+0x22/0x260
           arch_call_rest_init+0xe/0x10
           start_kernel+0x4fd/0x520
           x86_64_start_reservations+0x24/0x26
           x86_64_start_kernel+0x6f/0x72
           secondary_startup_64+0xa4/0xb0
    
    -> #1 (&p->pi_lock){-.-.}:
           lock_acquire+0x9e/0x180
           _raw_spin_lock_irqsave+0x3a/0x50
           try_to_wake_up+0x41/0x600
           wake_up_process+0x15/0x20
           create_worker+0x16b/0x1e0
           workqueue_init+0x279/0x2ee
           kernel_init_freeable+0xf7/0x288
           kernel_init+0xf/0x180
           ret_from_fork+0x24/0x30
    
    -> #0 (&(&pool->lock)->rlock){-.-.}:
           __lock_acquire+0x101f/0x12a0
           lock_acquire+0x9e/0x180
           _raw_spin_lock+0x2f/0x40
           __queue_work+0xb2/0x520
           queue_work_on+0x38/0x80
           free_percpu+0x221/0x260
           pcpu_freelist_destroy+0x11/0x20
           stack_map_free+0x2a/0x40
           bpf_map_free_deferred+0x3c/0x50
           process_one_work+0x1f7/0x580
           worker_thread+0x54/0x410
           kthread+0x10f/0x150
           ret_from_fork+0x24/0x30
    
    other info that might help us debug this:
    
    Chain exists of:
      &(&pool->lock)->rlock --> &htab->buckets[i].lock --> pcpu_lock
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(pcpu_lock);
                                   lock(&htab->buckets[i].lock);
                                   lock(pcpu_lock);
      lock(&(&pool->lock)->rlock);
    
     *** DEADLOCK ***
    
    3 locks held by kworker/23:255/18872:
     #0: 00000000b36a6e16 ((wq_completion)events){+.+.},
         at: process_one_work+0x17a/0x580
     #1: 00000000dfd966f0 ((work_completion)(&map->work)){+.+.},
         at: process_one_work+0x17a/0x580
     #2: 00000000e3e7a6aa (pcpu_lock){..-.},
         at: free_percpu+0x36/0x260
    
    stack backtrace:
    CPU: 23 PID: 18872 Comm: kworker/23:255 Not tainted 5.1.0-dbg-DEV #1
    Hardware name: ...
    Workqueue: events bpf_map_free_deferred
    Call Trace:
     dump_stack+0x67/0x95
     print_circular_bug.isra.38+0x1c6/0x220
     check_prev_add.constprop.50+0x9f6/0xd20
     __lock_acquire+0x101f/0x12a0
     lock_acquire+0x9e/0x180
     _raw_spin_lock+0x2f/0x40
     __queue_work+0xb2/0x520
     queue_work_on+0x38/0x80
     free_percpu+0x221/0x260
     pcpu_freelist_destroy+0x11/0x20
     stack_map_free+0x2a/0x40
     bpf_map_free_deferred+0x3c/0x50
     process_one_work+0x1f7/0x580
     worker_thread+0x54/0x410
     kthread+0x10f/0x150
     ret_from_fork+0x24/0x30
    
    Signed-off-by: John Sperbeck <jsperbeck@google.com>
    Signed-off-by: Dennis Zhou <dennis@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f9ca872dd8d94c175f9fd1bc256b79fda7a2115
Author: Eugen Hristev <eugen.hristev@microchip.com>
Date:   Fri Apr 12 06:19:49 2019 -0400

    media: atmel: atmel-isc: fix asd memory allocation
    
    [ Upstream commit 1e4e25c4959c10728fbfcc6a286f9503d32dfe02 ]
    
    The subsystem will free the asd memory on notifier cleanup, if the asd is
    added to the notifier.
    However the memory is freed using kfree.
    Thus, we cannot allocate the asd using devm_*
    This can lead to crashes and problems.
    To test this issue, just return an error at probe, but cleanup the
    notifier beforehand.
    
    Fixes: 106267444f ("[media] atmel-isc: add the Image Sensor Controller code")
    
    Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b039536485970829918aa237a08417bd0ed5437c
Author: Chao Yu <yuchao0@huawei.com>
Date:   Mon Apr 15 15:28:35 2019 +0800

    f2fs: fix to do checksum even if inode page is uptodate
    
    [ Upstream commit b42b179bda9ff11075a6fc2bac4d9e400513679a ]
    
    As Jungyeon reported in bugzilla:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=203221
    
    - Overview
    When mounting the attached crafted image and running program, this error is reported.
    
    The image is intentionally fuzzed from a normal f2fs image for testing and I enabled option CONFIG_F2FS_CHECK_FS on.
    
    - Reproduces
    cc poc_07.c
    mkdir test
    mount -t f2fs tmp.img test
    cp a.out test
    cd test
    sudo ./a.out
    
    - Messages
     kernel BUG at fs/f2fs/node.c:1279!
     RIP: 0010:read_node_page+0xcf/0xf0
     Call Trace:
      __get_node_page+0x6b/0x2f0
      f2fs_iget+0x8f/0xdf0
      f2fs_lookup+0x136/0x320
      __lookup_slow+0x92/0x140
      lookup_slow+0x30/0x50
      walk_component+0x1c1/0x350
      path_lookupat+0x62/0x200
      filename_lookup+0xb3/0x1a0
      do_fchmodat+0x3e/0xa0
      __x64_sys_chmod+0x12/0x20
      do_syscall_64+0x43/0xf0
      entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    On below paths, we can have opportunity to readahead inode page
    - gc_node_segment -> f2fs_ra_node_page
    - gc_data_segment -> f2fs_ra_node_page
    - f2fs_fill_dentries -> f2fs_ra_node_page
    
    Unlike synchronized read, on readahead path, we can set page uptodate
    before verifying page's checksum, then read_node_page() will trigger
    kernel panic once it encounters a uptodated page w/ incorrect checksum.
    
    So considering readahead scenario, we have to do checksum each time
    when loading inode page even if it is uptodated.
    
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0fd306ae0d5b39b1e3adcac2c064bd9a1d9d137a
Author: Chao Yu <yuchao0@huawei.com>
Date:   Thu Apr 11 11:48:09 2019 +0800

    f2fs: fix to retrieve inline xattr space
    
    [ Upstream commit 45a746881576977f85504c21a75547f10c5c0a8e ]
    
    With below mkfs and mount option, generic/339 of fstest will report that
    scratch image becomes corrupted.
    
    MKFS_OPTIONS  -- -O extra_attr -O project_quota -O inode_checksum -O flexible_inline_xattr -O inode_crtime -f /dev/zram1
    MOUNT_OPTIONS -- -o acl,user_xattr -o discard,noinline_xattr /dev/zram1 /mnt/scratch_f2fs
    
    [ASSERT] (f2fs_check_dirent_position:1315)  --> Wrong position of dirent pino:1970, name: (...)
    level:8, dir_level:0, pgofs:951, correct range:[900, 901]
    
    In old kernel, inline data and directory always reserved 200 bytes in
    inode layout, even if inline_xattr is disabled, then new kernel tries
    to retrieve that space for non-inline xattr inode, but for inline dentry,
    its layout size should be fixed, so we just keep that reserved space.
    
    But the problem here is that, after inline dentry conversion, inline
    dentry layout no longer exists, if we still reserve inline xattr space,
    after dents updates, there will be a hole in inline xattr space, which
    can break hierarchy hash directory structure.
    
    This patch fixes this issue by retrieving inline xattr space after
    inline dentry conversion.
    
    Fixes: 6afc662e68b5 ("f2fs: support flexible inline xattr size")
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e2877ff9b7fcf886a7d6c63f7b0db65498041e8c
Author: Chao Yu <yuchao0@huawei.com>
Date:   Wed Apr 10 18:45:50 2019 +0800

    f2fs: fix to avoid deadloop in foreground GC
    
    [ Upstream commit 793ab1c8a792f8bccd7ae4c5be02bd275410b3af ]
    
    As Jungyeon reported in bugzilla:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=203211
    
    - Overview
    When mounting the attached crafted image and making a new file, I got this error and the error messages keep repeating.
    
    The image is intentionally fuzzed from a normal f2fs image for testing and I run with option CONFIG_F2FS_CHECK_FS on.
    
    - Reproduces
    mkdir test
    mount -t f2fs tmp.img test
    cd test
    touch t
    
    - Messages
    [   58.820451] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.821485] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.822530] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.823571] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.824616] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.825640] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.826663] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.827698] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.828719] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.829759] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.830783] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.831828] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.832869] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.833888] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.834945] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.835996] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.837028] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.838051] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.839072] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.840100] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.841147] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.842186] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.843214] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.844267] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.845282] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.846305] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    [   58.847341] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
    ... (repeating)
    
    During GC, if segment type stored in SSA and SIT is inconsistent, we just
    skip migrating current segment directly, since we need to know the exact
    type to decide the migration function we use.
    
    So in foreground GC, we will easily run into a infinite loop as we may
    select the same victim segment which has inconsistent type due to greedy
    policy. In order to end up this, we choose to shutdown filesystem. For
    backgrond GC, we need to do that as well, so that we can avoid latter
    potential infinite looped foreground GC.
    
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 53275b02b1329985ee58c1c16e0c2e6bfa8880a6
Author: Chao Yu <yuchao0@huawei.com>
Date:   Mon Apr 15 15:30:51 2019 +0800

    f2fs: fix to do sanity check on valid block count of segment
    
    [ Upstream commit e95bcdb2fefa129f37bd9035af1d234ca92ee4ef ]
    
    As Jungyeon reported in bugzilla:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=203233
    
    - Overview
    When mounting the attached crafted image and running program, following errors are reported.
    Additionally, it hangs on sync after running program.
    
    The image is intentionally fuzzed from a normal f2fs image for testing.
    Compile options for F2FS are as follows.
    CONFIG_F2FS_FS=y
    CONFIG_F2FS_STAT_FS=y
    CONFIG_F2FS_FS_XATTR=y
    CONFIG_F2FS_FS_POSIX_ACL=y
    CONFIG_F2FS_CHECK_FS=y
    
    - Reproduces
    cc poc_13.c
    mkdir test
    mount -t f2fs tmp.img test
    cp a.out test
    cd test
    sudo ./a.out
    sync
    
    - Kernel messages
     F2FS-fs (sdb): Bitmap was wrongly set, blk:4608
     kernel BUG at fs/f2fs/segment.c:2102!
     RIP: 0010:update_sit_entry+0x394/0x410
     Call Trace:
      f2fs_allocate_data_block+0x16f/0x660
      do_write_page+0x62/0x170
      f2fs_do_write_node_page+0x33/0xa0
      __write_node_page+0x270/0x4e0
      f2fs_sync_node_pages+0x5df/0x670
      f2fs_write_checkpoint+0x372/0x1400
      f2fs_sync_fs+0xa3/0x130
      f2fs_do_sync_file+0x1a6/0x810
      do_fsync+0x33/0x60
      __x64_sys_fsync+0xb/0x10
      do_syscall_64+0x43/0xf0
      entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    sit.vblocks and sum valid block count in sit.valid_map may be
    inconsistent, segment w/ zero vblocks will be treated as free
    segment, while allocating in free segment, we may allocate a
    free block, if its bitmap is valid previously, it can cause
    kernel crash due to bitmap verification failure.
    
    Anyway, to avoid further serious metadata inconsistence and
    corruption, it is necessary and worth to detect SIT
    inconsistence. So let's enable check_block_count() to verify
    vblocks and valid_map all the time rather than do it only
    CONFIG_F2FS_CHECK_FS is enabled.
    
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 076d876bb4b9b1058da4dd1c54953a7e6fbb0583
Author: Chao Yu <yuchao0@huawei.com>
Date:   Mon Apr 15 15:28:31 2019 +0800

    f2fs: fix to avoid panic in dec_valid_node_count()
    
    [ Upstream commit ea6d7e72fea49402aa445345aade7a26b81732e3 ]
    
    As Jungyeon reported in bugzilla:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=203213
    
    - Overview
    When mounting the attached crafted image and running program, I got this error.
    Additionally, it hangs on sync after running the this script.
    
    The image is intentionally fuzzed from a normal f2fs image for testing and I enabled option CONFIG_F2FS_CHECK_FS on.
    
    - Reproduces
    mkdir test
    mount -t f2fs tmp.img test
    cp a.out test
    cd test
    sudo ./a.out
    sync
    
     kernel BUG at fs/f2fs/f2fs.h:2012!
     RIP: 0010:truncate_node+0x2c9/0x2e0
     Call Trace:
      f2fs_truncate_xattr_node+0xa1/0x130
      f2fs_remove_inode_page+0x82/0x2d0
      f2fs_evict_inode+0x2a3/0x3a0
      evict+0xba/0x180
      __dentry_kill+0xbe/0x160
      dentry_kill+0x46/0x180
      dput+0xbb/0x100
      do_renameat2+0x3c9/0x550
      __x64_sys_rename+0x17/0x20
      do_syscall_64+0x43/0xf0
      entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    The reason is dec_valid_node_count() will trigger kernel panic due to
    inconsistent count in between inode.i_blocks and actual block.
    
    To avoid panic, let's just print debug message and set SBI_NEED_FSCK to
    give a hint to fsck for latter repairing.
    
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    [Jaegeuk Kim: fix build warning and add unlikely]
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7cc9fda778d0aa98d6c2c92352f275ec823a6895
Author: Chao Yu <yuchao0@huawei.com>
Date:   Thu Apr 11 11:48:10 2019 +0800

    f2fs: fix to use inline space only if inline_xattr is enable
    
    [ Upstream commit 622927f3b8809206f6da54a6a7ed4df1a7770fce ]
    
    With below mkfs and mount option:
    
    MKFS_OPTIONS  -- -O extra_attr -O project_quota -O inode_checksum -O flexible_inline_xattr -O inode_crtime -f
    MOUNT_OPTIONS -- -o noinline_xattr
    
    We may miss xattr data with below testcase:
    - mkdir dir
    - setfattr -n "user.name" -v 0 dir
    - for ((i = 0; i < 190; i++)) do touch dir/$i; done
    - umount
    - mount
    - getfattr -n "user.name" dir
    
    user.name: No such attribute
    
    The root cause is that we persist xattr data into reserved inline xattr
    space, even if inline_xattr is not enable in inline directory inode, after
    inline dentry conversion, reserved space no longer exists, so that xattr
    data missed.
    
    Let's use inline xattr space only if inline_xattr flag is set on inode
    to fix this iusse.
    
    Fixes: 6afc662e68b5 ("f2fs: support flexible inline xattr size")
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3f4a094e32e17cc414e3e54a9ef1fd9727fd7d35
Author: Chao Yu <yuchao0@huawei.com>
Date:   Mon Apr 15 15:28:30 2019 +0800

    f2fs: fix to avoid panic in dec_valid_block_count()
    
    [ Upstream commit 5e159cd349bf3a31fb7e35c23a93308eb30f4f71 ]
    
    As Jungyeon reported in bugzilla:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=203209
    
    - Overview
    When mounting the attached crafted image and running program, I got this error.
    Additionally, it hangs on sync after the this script.
    
    The image is intentionally fuzzed from a normal f2fs image for testing and I enabled option CONFIG_F2FS_CHECK_FS on.
    
    - Reproduces
    cc poc_01.c
    ./run.sh f2fs
    sync
    
     kernel BUG at fs/f2fs/f2fs.h:1788!
     RIP: 0010:f2fs_truncate_data_blocks_range+0x342/0x350
     Call Trace:
      f2fs_truncate_blocks+0x36d/0x3c0
      f2fs_truncate+0x88/0x110
      f2fs_setattr+0x3e1/0x460
      notify_change+0x2da/0x400
      do_truncate+0x6d/0xb0
      do_sys_ftruncate+0xf1/0x160
      do_syscall_64+0x43/0xf0
      entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    The reason is dec_valid_block_count() will trigger kernel panic due to
    inconsistent count in between inode.i_blocks and actual block.
    
    To avoid panic, let's just print debug message and set SBI_NEED_FSCK to
    give a hint to fsck for latter repairing.
    
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    [Jaegeuk Kim: fix build warning and add unlikely]
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 83c46592edc30b30b8246911763e52ae694509c1
Author: Chao Yu <yuchao0@huawei.com>
Date:   Mon Apr 15 15:28:33 2019 +0800

    f2fs: fix to clear dirty inode in error path of f2fs_iget()
    
    [ Upstream commit 546d22f070d64a7b96f57c93333772085d3a5e6d ]
    
    As Jungyeon reported in bugzilla:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=203217
    
    - Overview
    When mounting the attached crafted image and running program, I got this error.
    Additionally, it hangs on sync after running the program.
    
    The image is intentionally fuzzed from a normal f2fs image for testing and I enabled option CONFIG_F2FS_CHECK_FS on.
    
    - Reproduces
    cc poc_test_05.c
    mkdir test
    mount -t f2fs tmp.img test
    sudo ./a.out
    sync
    
    - Messages
     kernel BUG at fs/f2fs/inode.c:707!
     RIP: 0010:f2fs_evict_inode+0x33f/0x3a0
     Call Trace:
      evict+0xba/0x180
      f2fs_iget+0x598/0xdf0
      f2fs_lookup+0x136/0x320
      __lookup_slow+0x92/0x140
      lookup_slow+0x30/0x50
      walk_component+0x1c1/0x350
      path_lookupat+0x62/0x200
      filename_lookup+0xb3/0x1a0
      do_readlinkat+0x56/0x110
      __x64_sys_readlink+0x16/0x20
      do_syscall_64+0x43/0xf0
      entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    During inode loading, __recover_inline_status() can recovery inode status
    and set inode dirty, once we failed in following process, it will fail
    the check in f2fs_evict_inode, result in trigger BUG_ON().
    
    Let's clear dirty inode in error path of f2fs_iget() to avoid panic.
    
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c5722a10c86d641a385299ca4bee200d33e793c6
Author: Chao Yu <yuchao0@huawei.com>
Date:   Mon Apr 15 15:28:36 2019 +0800

    f2fs: fix to do sanity check on free nid
    
    [ Upstream commit 626bcf2b7ce87211dba565f2bfa7842ba5be5c1b ]
    
    As Jungyeon reported in bugzilla:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=203225
    
    - Overview
    When mounting the attached crafted image and unmounting it, following errors are reported.
    Additionally, it hangs on sync after unmounting.
    
    The image is intentionally fuzzed from a normal f2fs image for testing.
    Compile options for F2FS are as follows.
    CONFIG_F2FS_FS=y
    CONFIG_F2FS_STAT_FS=y
    CONFIG_F2FS_FS_XATTR=y
    CONFIG_F2FS_FS_POSIX_ACL=y
    CONFIG_F2FS_CHECK_FS=y
    
    - Reproduces
    mkdir test
    mount -t f2fs tmp.img test
    touch test/t
    umount test
    sync
    
    - Messages
     kernel BUG at fs/f2fs/node.c:3073!
     RIP: 0010:f2fs_destroy_node_manager+0x2f0/0x300
     Call Trace:
      f2fs_put_super+0xf4/0x270
      generic_shutdown_super+0x62/0x110
      kill_block_super+0x1c/0x50
      kill_f2fs_super+0xad/0xd0
      deactivate_locked_super+0x35/0x60
      cleanup_mnt+0x36/0x70
      task_work_run+0x75/0x90
      exit_to_usermode_loop+0x93/0xa0
      do_syscall_64+0xba/0xf0
      entry_SYSCALL_64_after_hwframe+0x44/0xa9
     RIP: 0010:f2fs_destroy_node_manager+0x2f0/0x300
    
    NAT table is corrupted, so reserved meta/node inode ids were added into
    free list incorrectly, during file creation, since reserved id has cached
    in inode hash, so it fails the creation and preallocated nid can not be
    released later, result in kernel panic.
    
    To fix this issue, let's do nid boundary check during free nid loading.
    
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 549161250f22ce1e71148aaa9eced2d3fc3c8635
Author: Chao Yu <yuchao0@huawei.com>
Date:   Mon Apr 15 15:28:34 2019 +0800

    f2fs: fix to avoid panic in f2fs_remove_inode_page()
    
    [ Upstream commit 8b6810f8acfe429fde7c7dad4714692cc5f75651 ]
    
    As Jungyeon reported in bugzilla:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=203219
    
    - Overview
    When mounting the attached crafted image and running program, I got this error.
    Additionally, it hangs on sync after running the program.
    
    The image is intentionally fuzzed from a normal f2fs image for testing and I enabled option CONFIG_F2FS_CHECK_FS on.
    
    - Reproduces
    cc poc_06.c
    mkdir test
    mount -t f2fs tmp.img test
    cp a.out test
    cd test
    sudo ./a.out
    sync
    
    - Messages
     kernel BUG at fs/f2fs/node.c:1183!
     RIP: 0010:f2fs_remove_inode_page+0x294/0x2d0
     Call Trace:
      f2fs_evict_inode+0x2a3/0x3a0
      evict+0xba/0x180
      __dentry_kill+0xbe/0x160
      dentry_kill+0x46/0x180
      dput+0xbb/0x100
      do_renameat2+0x3c9/0x550
      __x64_sys_rename+0x17/0x20
      do_syscall_64+0x43/0xf0
      entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    The reason is f2fs_remove_inode_page() will trigger kernel panic due to
    inconsistent i_blocks value of inode.
    
    To avoid panic, let's just print debug message and set SBI_NEED_FSCK to
    give a hint to fsck for latter repairing of potential image corruption.
    
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    [Jaegeuk Kim: fix build warning and add unlikely]
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d6fa38f7c326d651aa40b0f92373722c8f5ff159
Author: Chao Yu <yuchao0@huawei.com>
Date:   Wed Apr 10 18:45:26 2019 +0800

    f2fs: fix error path of recovery
    
    [ Upstream commit 988385795c7f46b231982d54750587f204bd558b ]
    
    There are some places in where we missed to unlock page or unlock page
    incorrectly, fix them.
    
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit da06b18bf651402937b925ab6a44589c1b810f64
Author: Chao Yu <yuchao0@huawei.com>
Date:   Mon Apr 15 15:30:52 2019 +0800

    f2fs: fix to avoid panic in f2fs_inplace_write_data()
    
    [ Upstream commit 05573d6ccf702df549a7bdeabef31e4753df1a90 ]
    
    As Jungyeon reported in bugzilla:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=203239
    
    - Overview
    When mounting the attached crafted image and running program, following errors are reported.
    Additionally, it hangs on sync after running program.
    
    The image is intentionally fuzzed from a normal f2fs image for testing.
    Compile options for F2FS are as follows.
    CONFIG_F2FS_FS=y
    CONFIG_F2FS_STAT_FS=y
    CONFIG_F2FS_FS_XATTR=y
    CONFIG_F2FS_FS_POSIX_ACL=y
    CONFIG_F2FS_CHECK_FS=y
    
    - Reproduces
    cc poc_15.c
    ./run.sh f2fs
    sync
    
    - Kernel messages
     ------------[ cut here ]------------
     kernel BUG at fs/f2fs/segment.c:3162!
     RIP: 0010:f2fs_inplace_write_data+0x12d/0x160
     Call Trace:
      f2fs_do_write_data_page+0x3c1/0x820
      __write_data_page+0x156/0x720
      f2fs_write_cache_pages+0x20d/0x460
      f2fs_write_data_pages+0x1b4/0x300
      do_writepages+0x15/0x60
      __filemap_fdatawrite_range+0x7c/0xb0
      file_write_and_wait_range+0x2c/0x80
      f2fs_do_sync_file+0x102/0x810
      do_fsync+0x33/0x60
      __x64_sys_fsync+0xb/0x10
      do_syscall_64+0x43/0xf0
      entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    The reason is f2fs_inplace_write_data() will trigger kernel panic due
    to data block locates in node type segment.
    
    To avoid panic, let's just return error code and set SBI_NEED_FSCK to
    give a hint to fsck for latter repairing.
    
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62f9300caa927392e603aa70d7befa57b446b2b3
Author: Chao Yu <yuchao0@huawei.com>
Date:   Mon Apr 15 15:28:37 2019 +0800

    f2fs: fix to avoid panic in do_recover_data()
    
    [ Upstream commit 22d61e286e2d9097dae36f75ed48801056b77cac ]
    
    As Jungyeon reported in bugzilla:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=203227
    
    - Overview
    When mounting the attached crafted image, following errors are reported.
    Additionally, it hangs on sync after trying to mount it.
    
    The image is intentionally fuzzed from a normal f2fs image for testing.
    Compile options for F2FS are as follows.
    CONFIG_F2FS_FS=y
    CONFIG_F2FS_STAT_FS=y
    CONFIG_F2FS_FS_XATTR=y
    CONFIG_F2FS_FS_POSIX_ACL=y
    CONFIG_F2FS_CHECK_FS=y
    
    - Reproduces
    mkdir test
    mount -t f2fs tmp.img test
    sync
    
    - Messages
     kernel BUG at fs/f2fs/recovery.c:549!
     RIP: 0010:recover_data+0x167a/0x1780
     Call Trace:
      f2fs_recover_fsync_data+0x613/0x710
      f2fs_fill_super+0x1043/0x1aa0
      mount_bdev+0x16d/0x1a0
      mount_fs+0x4a/0x170
      vfs_kern_mount+0x5d/0x100
      do_mount+0x200/0xcf0
      ksys_mount+0x79/0xc0
      __x64_sys_mount+0x1c/0x20
      do_syscall_64+0x43/0xf0
      entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    During recovery, if ofs_of_node is inconsistent in between recovered
    node page and original checkpointed node page, let's just fail recovery
    instead of making kernel panic.
    
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 01e0054e3e0d3e00095b3999829c423a7f911363
Author: Miroslav Lichvar <mlichvar@redhat.com>
Date:   Wed Apr 17 10:48:33 2019 +0200

    ntp: Allow TAI-UTC offset to be set to zero
    
    [ Upstream commit fdc6bae940ee9eb869e493990540098b8c0fd6ab ]
    
    The ADJ_TAI adjtimex mode sets the TAI-UTC offset of the system clock.
    It is typically set by NTP/PTP implementations and it is automatically
    updated by the kernel on leap seconds. The initial value is zero (which
    applications may interpret as unknown), but this value cannot be set by
    adjtimex. This limitation seems to go back to the original "nanokernel"
    implementation by David Mills.
    
    Change the ADJ_TAI check to accept zero as a valid TAI-UTC offset in
    order to allow setting it back to the initial value.
    
    Fixes: 153b5d054ac2 ("ntp: support for TAI")
    Suggested-by: Ondrej Mosnacek <omosnace@redhat.com>
    Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: John Stultz <john.stultz@linaro.org>
    Cc: Richard Cochran <richardcochran@gmail.com>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Link: https://lkml.kernel.org/r/20190417084833.7401-1-mlichvar@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b0cb6f12bb80b8d07d48057a90fa116d867ba30
Author: Fabien Dessenne <fabien.dessenne@st.com>
Date:   Wed Apr 24 17:51:05 2019 +0200

    mailbox: stm32-ipcc: check invalid irq
    
    [ Upstream commit 68a1c8485cf83734d4da9d81cd3b5d2ae7c0339b ]
    
    On failure of_irq_get() returns a negative value or zero, which is
    not handled as an error in the existing implementation.
    Instead of using this API, use platform_get_irq() that returns
    exclusively a negative value on failure.
    Also, do not output an error log in case of defer probe error.
    
    Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
    Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e5d4a6e6ad03b57fdce478fec942d4eb2a41d76
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Mon Apr 1 19:57:48 2019 +0200

    pwm: meson: Use the spin-lock only to protect register modifications
    
    [ Upstream commit f173747fffdf037c791405ab4f1ec0eb392fc48e ]
    
    Holding the spin-lock for all of the code in meson_pwm_apply() can
    result in a "BUG: scheduling while atomic". This can happen because
    clk_get_rate() (which is called from meson_pwm_calc()) may sleep.
    Only hold the spin-lock when modifying registers to solve this.
    
    The reason why we need a spin-lock in the driver is because the
    REG_MISC_AB register is shared between the two channels provided by one
    PWM controller. The only functions where REG_MISC_AB is modified are
    meson_pwm_enable() and meson_pwm_disable() so the register reads/writes
    in there need to be protected by the spin-lock.
    
    The original code also used the spin-lock to protect the values in
    struct meson_pwm_channel. This could be necessary if two consumers can
    use the same PWM channel. However, PWM core doesn't allow this so we
    don't need to protect the values in struct meson_pwm_channel with a
    lock.
    
    Fixes: 211ed630753d2f ("pwm: Add support for Meson PWM Controller")
    Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ffbb6164d5afa726abbd58c24594f6281ec95b11
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Fri May 3 00:19:41 2019 +1000

    EDAC/mpc85xx: Prevent building as a module
    
    [ Upstream commit 2b8358a951b1e2a534a54924cd8245e58a1c5fb8 ]
    
    The mpc85xx EDAC driver can be configured as a module but then fails to
    build because it uses two unexported symbols:
    
      ERROR: ".pci_find_hose_for_OF_device" [drivers/edac/mpc85xx_edac_mod.ko] undefined!
      ERROR: ".early_find_capability" [drivers/edac/mpc85xx_edac_mod.ko] undefined!
    
    We don't want to export those symbols just for this driver, so make the
    driver only configurable as a built-in.
    
    This seems to have been broken since at least
    
      c92132f59806 ("edac/85xx: Add PCIe error interrupt edac support")
    
    (Nov 2013).
    
     [ bp: make it depend on EDAC=y so that the EDAC core doesn't get built
       as a module. ]
    
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Acked-by: Johannes Thumshirn <jth@kernel.org>
    Cc: James Morse <james.morse@arm.com>
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
    Cc: linux-edac <linux-edac@vger.kernel.org>
    Cc: linuxppc-dev@ozlabs.org
    Cc: morbidrsa@gmail.com
    Link: https://lkml.kernel.org/r/20190502141941.12927-1-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d16989b484cace3160da966c3bc81b1de163e171
Author: Krzesimir Nowak <krzesimir@kinvolk.io>
Date:   Wed May 8 18:08:58 2019 +0200

    bpf: fix undefined behavior in narrow load handling
    
    [ Upstream commit e2f7fc0ac6957cabff4cecf6c721979b571af208 ]
    
    Commit 31fd85816dbe ("bpf: permits narrower load from bpf program
    context fields") made the verifier add AND instructions to clear the
    unwanted bits with a mask when doing a narrow load. The mask is
    computed with
    
      (1 << size * 8) - 1
    
    where "size" is the size of the narrow load. When doing a 4 byte load
    of a an 8 byte field the verifier shifts the literal 1 by 32 places to
    the left. This results in an overflow of a signed integer, which is an
    undefined behavior. Typically, the computed mask was zero, so the
    result of the narrow load ended up being zero too.
    
    Cast the literal to long long to avoid overflows. Note that narrow
    load of the 4 byte fields does not have the undefined behavior,
    because the load size can only be either 1 or 2 bytes, so shifting 1
    by 8 or 16 places will not overflow it. And reading 4 bytes would not
    be a narrow load of a 4 bytes field.
    
    Fixes: 31fd85816dbe ("bpf: permits narrower load from bpf program context fields")
    Reviewed-by: Alban Crequy <alban@kinvolk.io>
    Reviewed-by: Iago López Galeiras <iago@kinvolk.io>
    Signed-off-by: Krzesimir Nowak <krzesimir@kinvolk.io>
    Cc: Yonghong Song <yhs@fb.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8966652b2c1ad416ed3464ddd9cd6777d8772f83
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Fri May 3 12:23:55 2019 +1000

    drm/nouveau/kms/gv100-: fix spurious window immediate interlocks
    
    [ Upstream commit d2434e4d942c32cadcbdbcd32c58f35098f3b604 ]
    
    Cursor position updates were accidentally causing us to attempt to interlock
    window with window immediate, and without a matching window immediate update,
    NVDisplay could hang forever in some circumstances.
    
    Fixes suspend/resume on (at least) Quadro RTX4000 (TU104).
    
    Reported-by: Lyude Paul <lyude@redhat.com>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fa57e11511208fb3dd2642c7ae3a02a0b0fb175e
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Mon May 13 12:01:31 2019 -0500

    objtool: Don't use ignore flag for fake jumps
    
    [ Upstream commit e6da9567959e164f82bc81967e0d5b10dee870b4 ]
    
    The ignore flag is set on fake jumps in order to keep
    add_jump_destinations() from setting their jump_dest, since it already
    got set when the fake jump was created.
    
    But using the ignore flag is a bit of a hack.  It's normally used to
    skip validation of an instruction, which doesn't really make sense for
    fake jumps.
    
    Also, after the next patch, using the ignore flag for fake jumps can
    trigger a false "why am I validating an ignored function?" warning.
    
    Instead just add an explicit check in add_jump_destinations() to skip
    fake jumps.
    
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.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/71abc072ff48b2feccc197723a9c52859476c068.1557766718.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 06cd48e175913fd19600d9402d0382f83985d879
Author: Matt Redfearn <matt.redfearn@thinci.com>
Date:   Wed Apr 24 13:22:27 2019 +0000

    drm/bridge: adv7511: Fix low refresh rate selection
    
    [ Upstream commit 67793bd3b3948dc8c8384b6430e036a30a0ecb43 ]
    
    The driver currently sets register 0xfb (Low Refresh Rate) based on the
    value of mode->vrefresh. Firstly, this field is specified to be in Hz,
    but the magic numbers used by the code are Hz * 1000. This essentially
    leads to the low refresh rate always being set to 0x01, since the
    vrefresh value will always be less than 24000. Fix the magic numbers to
    be in Hz.
    Secondly, according to the comment in drm_modes.h, the field is not
    supposed to be used in a functional way anyway. Instead, use the helper
    function drm_mode_vrefresh().
    
    Fixes: 9c8af882bf12 ("drm: Add adv7511 encoder driver")
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Matt Redfearn <matt.redfearn@thinci.com>
    Signed-off-by: Sean Paul <seanpaul@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190424132210.26338-1-matt.redfearn@thinci.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4ff8e3e17ab64f52f7faa0c6e7994671726717f1
Author: Peteris Rudzusiks <peteris.rudzusiks@gmail.com>
Date:   Sat May 11 19:08:31 2019 +0200

    drm/nouveau: fix duplication of nv50_head_atom struct
    
    [ Upstream commit c4a52d669690423ee3c99d8eda1e69cd0821fcad ]
    
    nv50_head_atomic_duplicate_state() makes a copy of nv50_head_atom
    struct. This patch adds copying of struct member named "or", which
    previously was left uninitialized in the duplicated structure.
    
    Due to this bug, incorrect nhsync and nvsync values were sometimes used.
    In my particular case, that lead to a mismatch between the output
    resolution of the graphics device (GeForce GT 630 OEM) and the reported
    input signal resolution on the display. xrandr reported 1680x1050, but
    the display reported 1280x1024. As a result of this mismatch, the output
    on the display looked like it was cropped (only part of the output was
    actually visible on the display).
    
    git bisect pointed to commit 2ca7fb5c1cc6 ("drm/nouveau/kms/nv50: handle
    SetControlOutputResource from head"), which added the member "or" to
    nv50_head_atom structure, but forgot to copy it in
    nv50_head_atomic_duplicate_state().
    
    Fixes: 2ca7fb5c1cc6 ("drm/nouveau/kms/nv50: handle SetControlOutputResource from head")
    Signed-off-by: Peteris Rudzusiks <peteris.rudzusiks@gmail.com>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8e1e4616c8ee046b764e87e38d8896743d23cdc9
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Wed May 8 14:54:34 2019 +1000

    drm/nouveau/kms/gf119-gp10x: push HeadSetControlOutputResource() mthd when encoders change
    
    [ Upstream commit a0b694d0af21c9993d1a39a75fd814bd48bf7eb4 ]
    
    HW has error checks in place which check that pixel depth is explicitly
    provided on DP, while HDMI has a "default" setting that we use.
    
    In multi-display configurations with identical modelines, but different
    protocols (HDMI + DP, in this case), it was possible for the DP head to
    get swapped to the head which previously drove the HDMI output, without
    updating HeadSetControlOutputResource(), triggering the error check and
    hanging the core update.
    
    Reported-by: Lyude Paul <lyude@redhat.com>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ffd946c4c350846abc2d0483d61fde151449c0e8
Author: Stephane Eranian <eranian@google.com>
Date:   Mon May 13 17:34:00 2019 -0700

    perf/x86/intel: Allow PEBS multi-entry in watermark mode
    
    [ Upstream commit c7a286577d7592720c2f179aadfb325a1ff48c95 ]
    
    This patch fixes a restriction/bug introduced by:
    
       583feb08e7f7 ("perf/x86/intel: Fix handling of wakeup_events for multi-entry PEBS")
    
    The original patch prevented using multi-entry PEBS when wakeup_events != 0.
    However given that wakeup_events is part of a union with wakeup_watermark, it
    means that in watermark mode, PEBS multi-entry is also disabled which is not the
    intent. This patch fixes this by checking is watermark mode is enabled.
    
    Signed-off-by: Stephane Eranian <eranian@google.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: jolsa@redhat.com
    Cc: kan.liang@intel.com
    Cc: vincent.weaver@maine.edu
    Fixes: 583feb08e7f7 ("perf/x86/intel: Fix handling of wakeup_events for multi-entry PEBS")
    Link: http://lkml.kernel.org/r/20190514003400.224340-1-eranian@google.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b5833cb3c899077dfccfae72ba3de969c4d9521d
Author: Tony Lindgren <tony@atomide.com>
Date:   Thu Feb 14 08:03:45 2019 -0800

    mfd: twl6040: Fix device init errors for ACCCTL register
    
    [ Upstream commit 48171d0ea7caccf21c9ee3ae75eb370f2a756062 ]
    
    I noticed that we can get a -EREMOTEIO errors on at least omap4 duovero:
    
    twl6040 0-004b: Failed to write 2d = 19: -121
    
    And then any following register access will produce errors.
    
    There 2d offset above is register ACCCTL that gets written on twl6040
    powerup. With error checking added to the related regcache_sync() call,
    the -EREMOTEIO error is reproducable on twl6040 powerup at least
    duovero.
    
    To fix the error, we need to wait until twl6040 is accessible after the
    powerup. Based on tests on omap4 duovero, we need to wait over 8ms after
    powerup before register write will complete without failures. Let's also
    make sure we warn about possible errors too.
    
    Note that we have twl6040_patch[] reg_sequence with the ACCCTL register
    configuration and regcache_sync() will write the new value to ACCCTL.
    
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 126847e22b75a8e12fef06e53a13cda3043fb4fd
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Fri May 10 11:57:04 2019 +1000

    drm/nouveau/disp/dp: respect sink limits when selecting failsafe link configuration
    
    [ Upstream commit 13d03e9daf70dab032c03dc172e75bb98ad899c4 ]
    
    Where possible, we want the failsafe link configuration (one which won't
    hang the OR during modeset because of not enough bandwidth for the mode)
    to also be supported by the sink.
    
    This prevents "link rate unsupported by sink" messages when link training
    fails.
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 99f61a90e1a3623cc85bee8cc0ca5a7a79d17e5b
Author: Binbin Wu <binbin.wu@intel.com>
Date:   Mon Apr 8 16:09:10 2019 +0800

    mfd: intel-lpss: Set the device in reset state when init
    
    [ Upstream commit dad06532292d77f37fbe831a02948a593500f682 ]
    
    In virtualized setup, when system reboots due to warm
    reset interrupt storm is seen.
    
    Call Trace:
    <IRQ>
    dump_stack+0x70/0xa5
    __report_bad_irq+0x2e/0xc0
    note_interrupt+0x248/0x290
    ? add_interrupt_randomness+0x30/0x220
    handle_irq_event_percpu+0x54/0x80
    handle_irq_event+0x39/0x60
    handle_fasteoi_irq+0x91/0x150
    handle_irq+0x108/0x180
    do_IRQ+0x52/0xf0
    common_interrupt+0xf/0xf
    </IRQ>
    RIP: 0033:0x76fc2cfabc1d
    Code: 24 28 bf 03 00 00 00 31 c0 48 8d 35 63 77 0e 00 48 8d 15 2e
    94 0e 00 4c 89 f9 49 89 d9 4c 89 d3 e8 b8 e2 01 00 48 8b 54 24 18
    <48> 89 ef 48 89 de 4c 89 e1 e8 d5 97 01 00 84 c0 74 2d 48 8b 04
    24
    RSP: 002b:00007ffd247c1fc0 EFLAGS: 00000293 ORIG_RAX: ffffffffffffffda
    RAX: 0000000000000000 RBX: 00007ffd247c1ff0 RCX: 000000000003d3ce
    RDX: 0000000000000000 RSI: 00007ffd247c1ff0 RDI: 000076fc2cbb6010
    RBP: 000076fc2cded010 R08: 00007ffd247c2210 R09: 00007ffd247c22a0
    R10: 000076fc29465470 R11: 0000000000000000 R12: 00007ffd247c1fc0
    R13: 000076fc2ce8e470 R14: 000076fc27ec9960 R15: 0000000000000414
    handlers:
    [<000000000d3fa913>] idma64_irq
    Disabling IRQ #27
    
    To avoid interrupt storm, set the device in reset state
    before bringing out the device from reset state.
    
    Changelog v2:
    - correct the subject line by adding "mfd: "
    
    Signed-off-by: Binbin Wu <binbin.wu@intel.com>
    Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6cddbdf2feca4d0ae67c57ae3cc9db28da509677
Author: Daniel Gomez <dagmcr@gmail.com>
Date:   Mon Apr 22 21:09:50 2019 +0200

    mfd: tps65912-spi: Add missing of table registration
    
    [ Upstream commit 9e364e87ad7f2c636276c773d718cda29d62b741 ]
    
    MODULE_DEVICE_TABLE(of, <of_match_table> should be called to complete DT
    OF mathing mechanism and register it.
    
    Before this patch:
    modinfo drivers/mfd/tps65912-spi.ko | grep alias
    alias:          spi:tps65912
    
    After this patch:
    modinfo drivers/mfd/tps65912-spi.ko | grep alias
    alias:          of:N*T*Cti,tps65912C*
    alias:          of:N*T*Cti,tps65912
    alias:          spi:tps65912
    
    Reported-by: Javier Martinez Canillas <javier@dowhile0.org>
    Signed-off-by: Daniel Gomez <dagmcr@gmail.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5456681986774e75c7136589777f2beec8069e97
Author: Amit Kucheria <amit.kucheria@linaro.org>
Date:   Wed Mar 20 18:47:52 2019 +0530

    drivers: thermal: tsens: Don't print error message on -EPROBE_DEFER
    
    [ Upstream commit fc7d18cf6a923cde7f5e7ba2c1105bb106d3e29a ]
    
    We print a calibration failure message on -EPROBE_DEFER from
    nvmem/qfprom as follows:
    [    3.003090] qcom-tsens 4a9000.thermal-sensor: version: 1.4
    [    3.005376] qcom-tsens 4a9000.thermal-sensor: tsens calibration failed
    [    3.113248] qcom-tsens 4a9000.thermal-sensor: version: 1.4
    
    This confuses people when, in fact, calibration succeeds later when
    nvmem/qfprom device is available. Don't print this message on a
    -EPROBE_DEFER.
    
    Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
    Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a7ada939fcd8f3bda32e6d4be39ace9ba4159d42
Author: Jiada Wang <jiada_wang@mentor.com>
Date:   Wed Apr 24 14:11:45 2019 +0900

    thermal: rcar_gen3_thermal: disable interrupt in .remove
    
    [ Upstream commit 63f55fcea50c25ae5ad45af92d08dae3b84534c2 ]
    
    Currently IRQ remains enabled after .remove, later if device is probed,
    IRQ is requested before .thermal_init, this may cause IRQ function be
    called before device is initialized.
    
    this patch disables interrupt in .remove, to ensure irq function
    only be called after device is fully initialized.
    
    Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
    Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
    Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b1859f99eec1562f2584824657680451bf643a7f
Author: Cyrill Gorcunov <gorcunov@gmail.com>
Date:   Mon May 13 17:15:40 2019 -0700

    kernel/sys.c: prctl: fix false positive in validate_prctl_map()
    
    [ Upstream commit a9e73998f9d705c94a8dca9687633adc0f24a19a ]
    
    While validating new map we require the @start_data to be strictly less
    than @end_data, which is fine for regular applications (this is why this
    nit didn't trigger for that long).  These members are set from executable
    loaders such as elf handers, still it is pretty valid to have a loadable
    data section with zero size in file, in such case the start_data is equal
    to end_data once kernel loader finishes.
    
    As a result when we're trying to restore such programs the procedure fails
    and the kernel returns -EINVAL.  From the image dump of a program:
    
     | "mm_start_code": "0x400000",
     | "mm_end_code": "0x8f5fb4",
     | "mm_start_data": "0xf1bfb0",
     | "mm_end_data": "0xf1bfb0",
    
    Thus we need to change validate_prctl_map from strictly less to less or
    equal operator use.
    
    Link: http://lkml.kernel.org/r/20190408143554.GY1421@uranus.lan
    Fixes: f606b77f1a9e3 ("prctl: PR_SET_MM -- introduce PR_SET_MM_MAP operation")
    Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
    Cc: Andrey Vagin <avagin@gmail.com>
    Cc: Dmitry Safonov <0x7f454c46@gmail.com>
    Cc: Pavel Emelyanov <xemul@virtuozzo.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ff75e0ecadcd881936c96179acb258c55c02cffa
Author: Qian Cai <cai@lca.pw>
Date:   Mon May 13 17:16:31 2019 -0700

    mm/slab.c: fix an infinite loop in leaks_show()
    
    [ Upstream commit 745e10146c31b1c6ed3326286704ae251b17f663 ]
    
    "cat /proc/slab_allocators" could hang forever on SMP machines with
    kmemleak or object debugging enabled due to other CPUs running do_drain()
    will keep making kmemleak_object or debug_objects_cache dirty and unable
    to escape the first loop in leaks_show(),
    
    do {
            set_store_user_clean(cachep);
            drain_cpu_caches(cachep);
            ...
    
    } while (!is_store_user_clean(cachep));
    
    For example,
    
    do_drain
      slabs_destroy
        slab_destroy
          kmem_cache_free
            __cache_free
              ___cache_free
                kmemleak_free_recursive
                  delete_object_full
                    __delete_object
                      put_object
                        free_object_rcu
                          kmem_cache_free
                            cache_free_debugcheck --> dirty kmemleak_object
    
    One approach is to check cachep->name and skip both kmemleak_object and
    debug_objects_cache in leaks_show().  The other is to set store_user_clean
    after drain_cpu_caches() which leaves a small window between
    drain_cpu_caches() and set_store_user_clean() where per-CPU caches could
    be dirty again lead to slightly wrong information has been stored but
    could also speed up things significantly which sounds like a good
    compromise.  For example,
    
     # cat /proc/slab_allocators
     0m42.778s # 1st approach
     0m0.737s  # 2nd approach
    
    [akpm@linux-foundation.org: tweak comment]
    Link: http://lkml.kernel.org/r/20190411032635.10325-1-cai@lca.pw
    Fixes: d31676dfde25 ("mm/slab: alternative implementation for DEBUG_SLAB_LEAK")
    Signed-off-by: Qian Cai <cai@lca.pw>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Pekka Enberg <penberg@kernel.org>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ecadffd77d42180f8b53e33a2ed39083d79bac88
Author: Yue Hu <huyue2@yulong.com>
Date:   Mon May 13 17:16:37 2019 -0700

    mm/cma_debug.c: fix the break condition in cma_maxchunk_get()
    
    [ Upstream commit f0fd50504a54f5548eb666dc16ddf8394e44e4b7 ]
    
    If not find zero bit in find_next_zero_bit(), it will return the size
    parameter passed in, so the start bit should be compared with bitmap_maxno
    rather than cma->count.  Although getting maxchunk is working fine due to
    zero value of order_per_bit currently, the operation will be stuck if
    order_per_bit is set as non-zero.
    
    Link: http://lkml.kernel.org/r/20190319092734.276-1-zbestahu@gmail.com
    Signed-off-by: Yue Hu <huyue2@yulong.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Joe Perches <joe@perches.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Dmitry Safonov <d.safonov@partner.samsung.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 397b073f8d4f8f64cb16b2d80043934eeb369479
Author: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Date:   Mon May 13 17:19:11 2019 -0700

    mm: page_mkclean vs MADV_DONTNEED race
    
    [ Upstream commit 024eee0e83f0df52317be607ca521e0fc572aa07 ]
    
    MADV_DONTNEED is handled with mmap_sem taken in read mode.  We call
    page_mkclean without holding mmap_sem.
    
    MADV_DONTNEED implies that pages in the region are unmapped and subsequent
    access to the pages in that range is handled as a new page fault.  This
    implies that if we don't have parallel access to the region when
    MADV_DONTNEED is run we expect those range to be unallocated.
    
    w.r.t page_mkclean() we need to make sure that we don't break the
    MADV_DONTNEED semantics.  MADV_DONTNEED check for pmd_none without holding
    pmd_lock.  This implies we skip the pmd if we temporarily mark pmd none.
    Avoid doing that while marking the page clean.
    
    Keep the sequence same for dax too even though we don't support
    MADV_DONTNEED for dax mapping
    
    The bug was noticed by code review and I didn't observe any failures w.r.t
    test run.  This is similar to
    
    commit 58ceeb6bec86d9140f9d91d71a710e963523d063
    Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Date:   Thu Apr 13 14:56:26 2017 -0700
    
        thp: fix MADV_DONTNEED vs. MADV_FREE race
    
    commit ced108037c2aa542b3ed8b7afd1576064ad1362a
    Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Date:   Thu Apr 13 14:56:20 2017 -0700
    
        thp: fix MADV_DONTNEED vs. numa balancing race
    
    Link: http://lkml.kernel.org/r/20190321040610.14226-1-aneesh.kumar@linux.ibm.com
    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc:"Kirill A . Shutemov" <kirill@shutemov.name>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9e3c2b37dd94c2af18d3acbcb18d263d3b22a491
Author: Yue Hu <huyue2@yulong.com>
Date:   Mon May 13 17:17:41 2019 -0700

    mm/cma.c: fix the bitmap status to show failed allocation reason
    
    [ Upstream commit 2b59e01a3aa665f751d1410b99fae9336bd424e1 ]
    
    Currently one bit in cma bitmap represents number of pages rather than
    one page, cma->count means cma size in pages. So to find available pages
    via find_next_zero_bit()/find_next_bit() we should use cma size not in
    pages but in bits although current free pages number is correct due to
    zero value of order_per_bit. Once order_per_bit is changed the bitmap
    status will be incorrect.
    
    The size input in cma_debug_show_areas() is not correct.  It will
    affect the available pages at some position to debug the failure issue.
    
    This is an example with order_per_bit = 1
    
    Before this change:
    [    4.120060] cma: number of available pages: 1@93+4@108+7@121+7@137+7@153+7@169+7@185+7@201+3@213+3@221+3@229+3@237+3@245+3@253+3@261+3@269+3@277+3@285+3@293+3@301+3@309+3@317+3@325+19@333+15@369+512@512=> 638 free of 1024 total pages
    
    After this change:
    [    4.143234] cma: number of available pages: 2@93+8@108+14@121+14@137+14@153+14@169+14@185+14@201+6@213+6@221+6@229+6@237+6@245+6@253+6@261+6@269+6@277+6@285+6@293+6@301+6@309+6@317+6@325+38@333+30@369=> 252 free of 1024 total pages
    
    Obviously the bitmap status before is incorrect.
    
    Link: http://lkml.kernel.org/r/20190320060829.9144-1-zbestahu@gmail.com
    Signed-off-by: Yue Hu <huyue2@yulong.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
    Cc: Randy Dunlap <rdunlap@infradead.org>
    Cc: Laura Abbott <labbott@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e39f78afb731a05d4ca1f55fc17cae7b3d95465e
Author: Baoquan He <bhe@redhat.com>
Date:   Mon May 13 17:17:35 2019 -0700

    mm/memory_hotplug.c: fix the wrong usage of N_HIGH_MEMORY
    
    [ Upstream commit d3ba3ae19751e476b0840a0c9a673a5766fa3219 ]
    
    In node_states_check_changes_online(), N_HIGH_MEMORY is used to substitute
    ZONE_HIGHMEM directly.  This is not right.  N_HIGH_MEMORY is to mark the
    memory state of node.  Here zone index is checked, which should be
    compared with 'ZONE_HIGHMEM' accordingly.
    
    Replace it with ZONE_HIGHMEM.
    
    This is a code cleanup - no known runtime effects.
    
    Link: http://lkml.kernel.org/r/20190320080732.14933-1-bhe@redhat.com
    Fixes: 8efe33f40f3e ("mm/memory_hotplug.c: simplify node_states_check_changes_online")
    Signed-off-by: Baoquan He <bhe@redhat.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Cc: Wei Yang <richard.weiyang@gmail.com>
    Cc: Mike Rapoport <rppt@linux.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f3918ea4962b4238fcc7317974023527ac69342c
Author: Qian Cai <cai@lca.pw>
Date:   Mon May 13 17:17:38 2019 -0700

    mm/compaction.c: fix an undefined behaviour
    
    [ Upstream commit dd7ef7bd14640f11763b54f55131000165f48321 ]
    
    In a low-memory situation, cc->fast_search_fail can keep increasing as it
    is unable to find an available page to isolate in
    fast_isolate_freepages().  As the result, it could trigger an error below,
    so just compare with the maximum bits can be shifted first.
    
    UBSAN: Undefined behaviour in mm/compaction.c:1160:30
    shift exponent 64 is too large for 64-bit type 'unsigned long'
    CPU: 131 PID: 1308 Comm: kcompactd1 Kdump: loaded Tainted: G
    W    L    5.0.0+ #17
    Call trace:
     dump_backtrace+0x0/0x450
     show_stack+0x20/0x2c
     dump_stack+0xc8/0x14c
     __ubsan_handle_shift_out_of_bounds+0x7e8/0x8c4
     compaction_alloc+0x2344/0x2484
     unmap_and_move+0xdc/0x1dbc
     migrate_pages+0x274/0x1310
     compact_zone+0x26ec/0x43bc
     kcompactd+0x15b8/0x1a24
     kthread+0x374/0x390
     ret_from_fork+0x10/0x18
    
    [akpm@linux-foundation.org: code cleanup]
    Link: http://lkml.kernel.org/r/20190320203338.53367-1-cai@lca.pw
    Fixes: 70b44595eafe ("mm, compaction: use free lists to quickly locate a migration source")
    Signed-off-by: Qian Cai <cai@lca.pw>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Acked-by: Mel Gorman <mgorman@techsingularity.net>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a52e81f339305412002af5c82948d4ce07224118
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon May 13 17:18:17 2019 -0700

    initramfs: free initrd memory if opening /initrd.image fails
    
    [ Upstream commit 54c7a8916a887f357088f99e9c3a7720cd57d2c8 ]
    
    Patch series "initramfs tidyups".
    
    I've spent some time chasing down behavior in initramfs and found
    plenty of opportunity to improve the code.  A first stab on that is
    contained in this series.
    
    This patch (of 7):
    
    We free the initrd memory for all successful or error cases except for the
    case where opening /initrd.image fails, which looks like an oversight.
    
    Steven said:
    
    : This also changes the behaviour when CONFIG_INITRAMFS_FORCE is enabled
    : - specifically it means that the initrd is freed (previously it was
    : ignored and never freed).  But that seems like reasonable behaviour and
    : the previous behaviour looks like another oversight.
    
    Link: http://lkml.kernel.org/r/20190213174621.29297-3-hch@lst.de
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Steven Price <steven.price@arm.com>
    Acked-by: Mike Rapoport <rppt@linux.ibm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>   [arm64]
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>   [m68k]
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Russell King <linux@armlinux.org.uk>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Guan Xuetao <gxt@pku.edu.cn>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7df45315cf3047b930952e48d4bb30ba5f2905ec
Author: Yue Hu <huyue2@yulong.com>
Date:   Mon May 13 17:18:14 2019 -0700

    mm/cma.c: fix crash on CMA allocation if bitmap allocation fails
    
    [ Upstream commit 1df3a339074e31db95c4790ea9236874b13ccd87 ]
    
    f022d8cb7ec7 ("mm: cma: Don't crash on allocation if CMA area can't be
    activated") fixes the crash issue when activation fails via setting
    cma->count as 0, same logic exists if bitmap allocation fails.
    
    Link: http://lkml.kernel.org/r/20190325081309.6004-1-zbestahu@gmail.com
    Signed-off-by: Yue Hu <huyue2@yulong.com>
    Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Laura Abbott <labbott@redhat.com>
    Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
    Cc: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a72a64c90bb6edc81a386a0533592397be294f01
Author: Linxu Fang <fanglinxu@huawei.com>
Date:   Mon May 13 17:19:17 2019 -0700

    mem-hotplug: fix node spanned pages when we have a node with only ZONE_MOVABLE
    
    [ Upstream commit 299c83dce9ea3a79bb4b5511d2cb996b6b8e5111 ]
    
    342332e6a925 ("mm/page_alloc.c: introduce kernelcore=mirror option") and
    later patches rewrote the calculation of node spanned pages.
    
    e506b99696a2 ("mem-hotplug: fix node spanned pages when we have a movable
    node"), but the current code still has problems,
    
    When we have a node with only zone_movable and the node id is not zero,
    the size of node spanned pages is double added.
    
    That's because we have an empty normal zone, and zone_start_pfn or
    zone_end_pfn is not between arch_zone_lowest_possible_pfn and
    arch_zone_highest_possible_pfn, so we need to use clamp to constrain the
    range just like the commit <96e907d13602> (bootmem: Reimplement
    __absent_pages_in_range() using for_each_mem_pfn_range()).
    
    e.g.
    Zone ranges:
      DMA      [mem 0x0000000000001000-0x0000000000ffffff]
      DMA32    [mem 0x0000000001000000-0x00000000ffffffff]
      Normal   [mem 0x0000000100000000-0x000000023fffffff]
    Movable zone start for each node
      Node 0: 0x0000000100000000
      Node 1: 0x0000000140000000
    Early memory node ranges
      node   0: [mem 0x0000000000001000-0x000000000009efff]
      node   0: [mem 0x0000000000100000-0x00000000bffdffff]
      node   0: [mem 0x0000000100000000-0x000000013fffffff]
      node   1: [mem 0x0000000140000000-0x000000023fffffff]
    
    node 0 DMA      spanned:0xfff   present:0xf9e   absent:0x61
    node 0 DMA32    spanned:0xff000 present:0xbefe0 absent:0x40020
    node 0 Normal   spanned:0       present:0       absent:0
    node 0 Movable  spanned:0x40000 present:0x40000 absent:0
    On node 0 totalpages(node_present_pages): 1048446
    node_spanned_pages:1310719
    node 1 DMA      spanned:0           present:0           absent:0
    node 1 DMA32    spanned:0           present:0           absent:0
    node 1 Normal   spanned:0x100000    present:0x100000    absent:0
    node 1 Movable  spanned:0x100000    present:0x100000    absent:0
    On node 1 totalpages(node_present_pages): 2097152
    node_spanned_pages:2097152
    Memory: 6967796K/12582392K available (16388K kernel code, 3686K rwdata,
    4468K rodata, 2160K init, 10444K bss, 5614596K reserved, 0K
    cma-reserved)
    
    It shows that the current memory of node 1 is double added.
    After this patch, the problem is fixed.
    
    node 0 DMA      spanned:0xfff   present:0xf9e   absent:0x61
    node 0 DMA32    spanned:0xff000 present:0xbefe0 absent:0x40020
    node 0 Normal   spanned:0       present:0       absent:0
    node 0 Movable  spanned:0x40000 present:0x40000 absent:0
    On node 0 totalpages(node_present_pages): 1048446
    node_spanned_pages:1310719
    node 1 DMA      spanned:0           present:0           absent:0
    node 1 DMA32    spanned:0           present:0           absent:0
    node 1 Normal   spanned:0           present:0           absent:0
    node 1 Movable  spanned:0x100000    present:0x100000    absent:0
    On node 1 totalpages(node_present_pages): 1048576
    node_spanned_pages:1048576
    memory: 6967796K/8388088K available (16388K kernel code, 3686K rwdata,
    4468K rodata, 2160K init, 10444K bss, 1420292K reserved, 0K
    cma-reserved)
    
    Link: http://lkml.kernel.org/r/1554178276-10372-1-git-send-email-fanglinxu@huawei.com
    Signed-off-by: Linxu Fang <fanglinxu@huawei.com>
    Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>
    Cc: Xishi Qiu <qiuxishi@huawei.com>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Pavel Tatashin <pavel.tatashin@microsoft.com>
    Cc: Oscar Salvador <osalvador@suse.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8fc09bd2040f5115cd2c5ef449069441069fc05b
Author: David Hildenbrand <david@redhat.com>
Date:   Mon May 13 17:21:33 2019 -0700

    mm/memory_hotplug: release memory resource after arch_remove_memory()
    
    [ Upstream commit d9eb1417c77df7ce19abd2e41619e9dceccbdf2a ]
    
    Patch series "mm/memory_hotplug: Better error handling when removing
    memory", v1.
    
    Error handling when removing memory is somewhat messed up right now.  Some
    errors result in warnings, others are completely ignored.  Memory unplug
    code can essentially not deal with errors properly as of now.
    remove_memory() will never fail.
    
    We have basically two choices:
    1. Allow arch_remov_memory() and friends to fail, propagating errors via
       remove_memory(). Might be problematic (e.g. DIMMs consisting of multiple
       pieces added/removed separately).
    2. Don't allow the functions to fail, handling errors in a nicer way.
    
    It seems like most errors that can theoretically happen are really corner
    cases and mostly theoretical (e.g.  "section not valid").  However e.g.
    aborting removal of sections while all callers simply continue in case of
    errors is not nice.
    
    If we can gurantee that removal of memory always works (and WARN/skip in
    case of theoretical errors so we can figure out what is going on), we can
    go ahead and implement better error handling when adding memory.
    
    E.g. via add_memory():
    
    arch_add_memory()
    ret = do_stuff()
    if (ret) {
            arch_remove_memory();
            goto error;
    }
    
    Handling here that arch_remove_memory() might fail is basically
    impossible.  So I suggest, let's avoid reporting errors while removing
    memory, warning on theoretical errors instead and continuing instead of
    aborting.
    
    This patch (of 4):
    
    __add_pages() doesn't add the memory resource, so __remove_pages()
    shouldn't remove it.  Let's factor it out.  Especially as it is a special
    case for memory used as system memory, added via add_memory() and friends.
    
    We now remove the resource after removing the sections instead of doing it
    the other way around.  I don't think this change is problematic.
    
    add_memory()
            register memory resource
            arch_add_memory()
    
    remove_memory
            arch_remove_memory()
            release memory resource
    
    While at it, explain why we ignore errors and that it only happeny if
    we remove memory in a different granularity as we added it.
    
    [david@redhat.com: fix printk warning]
      Link: http://lkml.kernel.org/r/20190417120204.6997-1-david@redhat.com
    Link: http://lkml.kernel.org/r/20190409100148.24703-2-david@redhat.com
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
    Cc: Wei Yang <richard.weiyang@gmail.com>
    Cc: Qian Cai <cai@lca.pw>
    Cc: Arun KS <arunks@codeaurora.org>
    Cc: Mathieu Malaterre <malat@debian.org>
    Cc: Andrew Banman <andrew.banman@hpe.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Christophe Leroy <christophe.leroy@c-s.fr>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Mike Rapoport <rppt@linux.ibm.com>
    Cc: Mike Travis <mike.travis@hpe.com>
    Cc: Nicholas Piggin <npiggin@gmail.com>
    Cc: Oscar Salvador <osalvador@suse.com>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: "Rafael J. Wysocki" <rafael@kernel.org>
    Cc: Rich Felker <dalias@libc.org>
    Cc: Rob Herring <robh@kernel.org>
    Cc: Stefan Agner <stefan@agner.ch>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Vasily Gorbik <gor@linux.ibm.com>
    Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eb27e2acdf3292de571a2530cb1fb69d9b7e42e0
Author: Mike Kravetz <mike.kravetz@oracle.com>
Date:   Mon May 13 17:19:38 2019 -0700

    hugetlbfs: on restore reserve error path retain subpool reservation
    
    [ Upstream commit 0919e1b69ab459e06df45d3ba6658d281962db80 ]
    
    When a huge page is allocated, PagePrivate() is set if the allocation
    consumed a reservation.  When freeing a huge page, PagePrivate is checked.
    If set, it indicates the reservation should be restored.  PagePrivate
    being set at free huge page time mostly happens on error paths.
    
    When huge page reservations are created, a check is made to determine if
    the mapping is associated with an explicitly mounted filesystem.  If so,
    pages are also reserved within the filesystem.  The default action when
    freeing a huge page is to decrement the usage count in any associated
    explicitly mounted filesystem.  However, if the reservation is to be
    restored the reservation/use count within the filesystem should not be
    decrementd.  Otherwise, a subsequent page allocation and free for the same
    mapping location will cause the file filesystem usage to go 'negative'.
    
    Filesystem                         Size  Used Avail Use% Mounted on
    nodev                              4.0G -4.0M  4.1G    - /opt/hugepool
    
    To fix, when freeing a huge page do not adjust filesystem usage if
    PagePrivate() is set to indicate the reservation should be restored.
    
    I did not cc stable as the problem has been around since reserves were
    added to hugetlbfs and nobody has noticed.
    
    Link: http://lkml.kernel.org/r/20190328234704.27083-2-mike.kravetz@oracle.com
    Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
    Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Davidlohr Bueso <dave@stgolabs.net>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1d453434275169889dca70523ebb54e3a697406e
Author: Jérôme Glisse <jglisse@redhat.com>
Date:   Mon May 13 17:19:45 2019 -0700

    mm/hmm: select mmu notifier when selecting HMM
    
    [ Upstream commit 734fb89968900b5c5f8edd5038bd4cdeab8c61d2 ]
    
    To avoid random config build issue, select mmu notifier when HMM is
    selected.  In any cases when HMM get selected it will be by users that
    will also wants the mmu notifier.
    
    Link: http://lkml.kernel.org/r/20190403193318.16478-2-jglisse@redhat.com
    Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
    Acked-by: Balbir Singh <bsingharora@gmail.com>
    Cc: Ralph Campbell <rcampbell@nvidia.com>
    Cc: John Hubbard <jhubbard@nvidia.com>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Ira Weiny <ira.weiny@intel.com>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Souptick Joarder <jrdr.linux@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dd39a7e57ca43df62c797568d237d89e7885a910
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue May 14 15:41:48 2019 -0700

    ARM: prevent tracing IPI_CPU_BACKTRACE
    
    [ Upstream commit be167862ae7dd85c56d385209a4890678e1b0488 ]
    
    Patch series "compiler: allow all arches to enable
    CONFIG_OPTIMIZE_INLINING", v3.
    
    This patch (of 11):
    
    When function tracing for IPIs is enabled, we get a warning for an
    overflow of the ipi_types array with the IPI_CPU_BACKTRACE type as
    triggered by raise_nmi():
    
      arch/arm/kernel/smp.c: In function 'raise_nmi':
      arch/arm/kernel/smp.c:489:2: error: array subscript is above array bounds [-Werror=array-bounds]
        trace_ipi_raise(target, ipi_types[ipinr]);
    
    This is a correct warning as we actually overflow the array here.
    
    This patch raise_nmi() to call __smp_cross_call() instead of
    smp_cross_call(), to avoid calling into ftrace.  For clarification, I'm
    also adding a two new code comments describing how this one is special.
    
    The warning appears to have shown up after commit e7273ff49acf ("ARM:
    8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI"), which changed the
    number assignment from '15' to '8', but as far as I can tell has existed
    since the IPI tracepoints were first introduced.  If we decide to
    backport this patch to stable kernels, we probably need to backport
    e7273ff49acf as well.
    
    [yamada.masahiro@socionext.com: rebase on v5.1-rc1]
    Link: http://lkml.kernel.org/r/20190423034959.13525-2-yamada.masahiro@socionext.com
    Fixes: e7273ff49acf ("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI")
    Fixes: 365ec7b17327 ("ARM: add IPI tracepoints") # v3.17
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Christophe Leroy <christophe.leroy@c-s.fr>
    Cc: Mathieu Malaterre <malat@debian.org>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Stefan Agner <stefan@agner.ch>
    Cc: Boris Brezillon <bbrezillon@kernel.org>
    Cc: Miquel Raynal <miquel.raynal@bootlin.com>
    Cc: Richard Weinberger <richard@nod.at>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Cc: Brian Norris <computersforpeace@gmail.com>
    Cc: Marek Vasut <marek.vasut@gmail.com>
    Cc: Russell King <rmk+kernel@arm.linux.org.uk>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 966a46f8d35ddf7c40df7d57190d153ec8438dc9
Author: Mike Rapoport <rppt@linux.ibm.com>
Date:   Mon May 13 17:23:14 2019 -0700

    mm/mprotect.c: fix compilation warning because of unused 'mm' variable
    
    [ Upstream commit 94393c78964c432917014e3a456fa15c3e78f741 ]
    
    Since 0cbe3e26abe0 ("mm: update ptep_modify_prot_start/commit to take
    vm_area_struct as arg") the only place that uses the local 'mm' variable
    in change_pte_range() is the call to set_pte_at().
    
    Many architectures define set_pte_at() as macro that does not use the 'mm'
    parameter, which generates the following compilation warning:
    
     CC      mm/mprotect.o
    mm/mprotect.c: In function 'change_pte_range':
    mm/mprotect.c:42:20: warning: unused variable 'mm' [-Wunused-variable]
      struct mm_struct *mm = vma->vm_mm;
                        ^~
    
    Fix it by passing vma->mm to set_pte_at() and dropping the local 'mm'
    variable in change_pte_range().
    
    [liu.song.a23@gmail.com: fix missed conversions]
      Link: http://lkml.kernel.org/r/CAPhsuW6wcQgYLHNdBdw6m0YiR4RWsS4XzfpSKU7wBLLeOCTbpw@mail.gmail.comLink: http://lkml.kernel.org/r/1557305432-4940-1-git-send-email-rppt@linux.ibm.com
    Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Song Liu <liu.song.a23@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fa70cd418ac2e409827657a5f5f55e404b6ac06a
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Mon May 13 07:46:21 2019 -0700

    drm/pl111: Initialize clock spinlock early
    
    [ Upstream commit 3e01ae2612bdd7975c74ec7123d7f8f5e6eed795 ]
    
    The following warning is seen on systems with broken clock divider.
    
    INFO: trying to register non-static key.
    the code is fine but needs lockdep annotation.
    turning off the locking correctness validator.
    CPU: 0 PID: 1 Comm: swapper Not tainted 5.1.0-09698-g1fb3b52 #1
    Hardware name: ARM Integrator/CP (Device Tree)
    [<c0011be8>] (unwind_backtrace) from [<c000ebb8>] (show_stack+0x10/0x18)
    [<c000ebb8>] (show_stack) from [<c07d3fd0>] (dump_stack+0x18/0x24)
    [<c07d3fd0>] (dump_stack) from [<c0060d48>] (register_lock_class+0x674/0x6f8)
    [<c0060d48>] (register_lock_class) from [<c005de2c>]
            (__lock_acquire+0x68/0x2128)
    [<c005de2c>] (__lock_acquire) from [<c0060408>] (lock_acquire+0x110/0x21c)
    [<c0060408>] (lock_acquire) from [<c07f755c>] (_raw_spin_lock+0x34/0x48)
    [<c07f755c>] (_raw_spin_lock) from [<c0536c8c>]
            (pl111_display_enable+0xf8/0x5fc)
    [<c0536c8c>] (pl111_display_enable) from [<c0502f54>]
            (drm_atomic_helper_commit_modeset_enables+0x1ec/0x244)
    
    Since commit eedd6033b4c8 ("drm/pl111: Support variants with broken clock
    divider"), the spinlock is not initialized if the clock divider is broken.
    Initialize it earlier to fix the problem.
    
    Fixes: eedd6033b4c8 ("drm/pl111: Support variants with broken clock divider")
    Cc: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/1557758781-23586-1-git-send-email-linux@roeck-us.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5b655c4c2da25150f7296119ee1b686896e86892
Author: Brian Masney <masneyb@onstation.org>
Date:   Mon May 13 19:41:05 2019 -0400

    drm/msm: correct attempted NULL pointer dereference in debugfs
    
    [ Upstream commit 90f94660e53189755676543954101de78c26253b ]
    
    msm_gem_describe() would attempt to dereference a NULL pointer via the
    address space pointer when no IOMMU is present. Correct this by adding
    the appropriate check.
    
    Signed-off-by: Brian Masney <masneyb@onstation.org>
    Fixes: 575f0485508b ("drm/msm: Clean up and enhance the output of the 'gem' debugfs node")
    Signed-off-by: Sean Paul <seanpaul@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190513234105.7531-2-masneyb@onstation.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 52dd41c1ca38198de7f76653331d0759fdf42c67
Author: Li Rongqing <lirongqing@baidu.com>
Date:   Tue May 14 15:46:20 2019 -0700

    ipc: prevent lockup on alloc_msg and free_msg
    
    [ Upstream commit d6a2946a88f524a47cc9b79279667137899db807 ]
    
    msgctl10 of ltp triggers the following lockup When CONFIG_KASAN is
    enabled on large memory SMP systems, the pages initialization can take a
    long time, if msgctl10 requests a huge block memory, and it will block
    rcu scheduler, so release cpu actively.
    
    After adding schedule() in free_msg, free_msg can not be called when
    holding spinlock, so adding msg to a tmp list, and free it out of
    spinlock
    
      rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
      rcu:     Tasks blocked on level-1 rcu_node (CPUs 16-31): P32505
      rcu:     Tasks blocked on level-1 rcu_node (CPUs 48-63): P34978
      rcu:     (detected by 11, t=35024 jiffies, g=44237529, q=16542267)
      msgctl10        R  running task    21608 32505   2794 0x00000082
      Call Trace:
       preempt_schedule_irq+0x4c/0xb0
       retint_kernel+0x1b/0x2d
      RIP: 0010:__is_insn_slot_addr+0xfb/0x250
      Code: 82 1d 00 48 8b 9b 90 00 00 00 4c 89 f7 49 c1 ee 03 e8 59 83 1d 00 48 b8 00 00 00 00 00 fc ff df 4c 39 eb 48 89 9d 58 ff ff ff <41> c6 04 06 f8 74 66 4c 8d 75 98 4c 89 f1 48 c1 e9 03 48 01 c8 48
      RSP: 0018:ffff88bce041f758 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
      RAX: dffffc0000000000 RBX: ffffffff8471bc50 RCX: ffffffff828a2a57
      RDX: dffffc0000000000 RSI: dffffc0000000000 RDI: ffff88bce041f780
      RBP: ffff88bce041f828 R08: ffffed15f3f4c5b3 R09: ffffed15f3f4c5b3
      R10: 0000000000000001 R11: ffffed15f3f4c5b2 R12: 000000318aee9b73
      R13: ffffffff8471bc50 R14: 1ffff1179c083ef0 R15: 1ffff1179c083eec
       kernel_text_address+0xc1/0x100
       __kernel_text_address+0xe/0x30
       unwind_get_return_address+0x2f/0x50
       __save_stack_trace+0x92/0x100
       create_object+0x380/0x650
       __kmalloc+0x14c/0x2b0
       load_msg+0x38/0x1a0
       do_msgsnd+0x19e/0xcf0
       do_syscall_64+0x117/0x400
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
      rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
      rcu:     Tasks blocked on level-1 rcu_node (CPUs 0-15): P32170
      rcu:     (detected by 14, t=35016 jiffies, g=44237525, q=12423063)
      msgctl10        R  running task    21608 32170  32155 0x00000082
      Call Trace:
       preempt_schedule_irq+0x4c/0xb0
       retint_kernel+0x1b/0x2d
      RIP: 0010:lock_acquire+0x4d/0x340
      Code: 48 81 ec c0 00 00 00 45 89 c6 4d 89 cf 48 8d 6c 24 20 48 89 3c 24 48 8d bb e4 0c 00 00 89 74 24 0c 48 c7 44 24 20 b3 8a b5 41 <48> c1 ed 03 48 c7 44 24 28 b4 25 18 84 48 c7 44 24 30 d0 54 7a 82
      RSP: 0018:ffff88af83417738 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff13
      RAX: dffffc0000000000 RBX: ffff88bd335f3080 RCX: 0000000000000002
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88bd335f3d64
      RBP: ffff88af83417758 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000001 R11: ffffed13f3f745b2 R12: 0000000000000000
      R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000000
       is_bpf_text_address+0x32/0xe0
       kernel_text_address+0xec/0x100
       __kernel_text_address+0xe/0x30
       unwind_get_return_address+0x2f/0x50
       __save_stack_trace+0x92/0x100
       save_stack+0x32/0xb0
       __kasan_slab_free+0x130/0x180
       kfree+0xfa/0x2d0
       free_msg+0x24/0x50
       do_msgrcv+0x508/0xe60
       do_syscall_64+0x117/0x400
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    Davidlohr said:
     "So after releasing the lock, the msg rbtree/list is empty and new
      calls will not see those in the newly populated tmp_msg list, and
      therefore they cannot access the delayed msg freeing pointers, which
      is good. Also the fact that the node_cache is now freed before the
      actual messages seems to be harmless as this is wanted for
      msg_insert() avoiding GFP_ATOMIC allocations, and after releasing the
      info->lock the thing is freed anyway so it should not change things"
    
    Link: http://lkml.kernel.org/r/1552029161-4957-1-git-send-email-lirongqing@baidu.com
    Signed-off-by: Li RongQing <lirongqing@baidu.com>
    Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
    Reviewed-by: Davidlohr Bueso <dbueso@suse.de>
    Cc: Manfred Spraul <manfred@colorfullife.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 33bc00a54dbcde976a9d927ddaac5a3266de317f
Author: Christian Brauner <christian@brauner.io>
Date:   Tue May 14 15:44:55 2019 -0700

    sysctl: return -EINVAL if val violates minmax
    
    [ Upstream commit e260ad01f0aa9e96b5386d5cd7184afd949dc457 ]
    
    Currently when userspace gives us a values that overflow e.g.  file-max
    and other callers of __do_proc_doulongvec_minmax() we simply ignore the
    new value and leave the current value untouched.
    
    This can be problematic as it gives the illusion that the limit has
    indeed be bumped when in fact it failed.  This commit makes sure to
    return EINVAL when an overflow is detected.  Please note that this is a
    userspace facing change.
    
    Link: http://lkml.kernel.org/r/20190210203943.8227-4-christian@brauner.io
    Signed-off-by: Christian Brauner <christian@brauner.io>
    Acked-by: Luis Chamberlain <mcgrof@kernel.org>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Joe Lawrence <joe.lawrence@redhat.com>
    Cc: Waiman Long <longman@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cafeee0e7a87a27a33d3cdb5e8f4fe00167c4743
Author: Hou Tao <houtao1@huawei.com>
Date:   Tue May 14 15:44:32 2019 -0700

    fs/fat/file.c: issue flush after the writeback of FAT
    
    [ Upstream commit bd8309de0d60838eef6fb575b0c4c7e95841cf73 ]
    
    fsync() needs to make sure the data & meta-data of file are persistent
    after the return of fsync(), even when a power-failure occurs later.  In
    the case of fat-fs, the FAT belongs to the meta-data of file, so we need
    to issue a flush after the writeback of FAT instead before.
    
    Also bail out early when any stage of fsync fails.
    
    Link: http://lkml.kernel.org/r/20190409030158.136316-1-houtao1@huawei.com
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Acked-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Jan Kara <jack@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e87dffa3f19d1ddf488e1d6219997cfa27758e4c
Author: Kangjie Lu <kjlu@umn.edu>
Date:   Tue May 14 15:44:49 2019 -0700

    rapidio: fix a NULL pointer dereference when create_workqueue() fails
    
    [ Upstream commit 23015b22e47c5409620b1726a677d69e5cd032ba ]
    
    In case create_workqueue fails, the fix releases resources and returns
    -ENOMEM to avoid NULL pointer dereference.
    
    Signed-off-by: Kangjie Lu <kjlu@umn.edu>
    Acked-by: Alexandre Bounine <alex.bou9@gmail.com>
    Cc: Matt Porter <mporter@kernel.crashing.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 520a9d95d594f70ca4fd9479fcb20f6700623dad
Author: Jonas Karlman <jonas@kwiboo.se>
Date:   Thu Apr 25 03:12:28 2019 -0400

    media: rockchip/vpu: Add missing dont_use_autosuspend() calls
    
    [ Upstream commit 5c5b90f5cbad77dc15d8b5582efdb2e362bcd710 ]
    
    Those calls are needed to restore a clean PM state when the probe fails
    or when the driver is unloaded such that future ->probe() calls can
    initialize runtime PM again.
    
    Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
    Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f9d40d565b21955002ef15719dd83c42839e0ee
Author: Jonas Karlman <jonas@kwiboo.se>
Date:   Thu Apr 25 03:12:31 2019 -0400

    media: rockchip/vpu: Fix/re-order probe-error/remove path
    
    [ Upstream commit fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f ]
    
    media_device_cleanup() and v4l2_m2m_unregister_media_controller() were
    missing in the probe error path.
    While at it, re-order calls in the remove path to unregister/cleanup
    things in the reverse order they were initialized/registered.
    
    Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
    Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c2d2804b9939402f6ac9514d049e4469b6e1cb5d
Author: Dave Airlie <airlied@redhat.com>
Date:   Thu Apr 18 06:46:33 2019 +1000

    Revert "drm: allow render capable master with DRM_AUTH ioctls"
    
    [ Upstream commit dbb92471674a48892f5e50779425e03388073ab9 ]
    
    This reverts commit 8059add0478e29cb641936011a8fcc9ce9fd80be.
    
    This commit while seemingly a good idea, breaks a radv check,
    for a node being master because something succeeds where it failed
    before now.
    
    Apply the Linus rule, revert early and try again, we don't break
    userspace.
    
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>