--- /dev/null
+From 07d7e12091f4ab869cc6a4bb276399057e73b0b3 Mon Sep 17 00:00:00 2001
+From: Andrei Vagin <avagin@gmail.com>
+Date: Sun, 7 Apr 2019 21:15:42 -0700
+Subject: alarmtimer: Return correct remaining time
+
+From: Andrei Vagin <avagin@gmail.com>
+
+commit 07d7e12091f4ab869cc6a4bb276399057e73b0b3 upstream.
+
+To calculate a remaining time, it's required to subtract the current time
+from the expiration time. In alarm_timer_remaining() the arguments of
+ktime_sub are swapped.
+
+Fixes: d653d8457c76 ("alarmtimer: Implement remaining callback")
+Signed-off-by: Andrei Vagin <avagin@gmail.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
+Cc: Stephen Boyd <sboyd@kernel.org>
+Cc: John Stultz <john.stultz@linaro.org>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20190408041542.26338-1-avagin@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/time/alarmtimer.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/time/alarmtimer.c
++++ b/kernel/time/alarmtimer.c
+@@ -594,7 +594,7 @@ static ktime_t alarm_timer_remaining(str
+ {
+ struct alarm *alarm = &timr->it.alarm.alarmtimer;
+
+- return ktime_sub(now, alarm->node.expires);
++ return ktime_sub(alarm->node.expires, now);
+ }
+
+ /**
--- /dev/null
+From 09f91381fa5de1d44bc323d8bf345f5d57b3d9b5 Mon Sep 17 00:00:00 2001
+From: Peter Geis <pgwipeout@gmail.com>
+Date: Wed, 13 Mar 2019 19:02:30 +0000
+Subject: arm64: dts: rockchip: fix rk3328 sdmmc0 write errors
+
+From: Peter Geis <pgwipeout@gmail.com>
+
+commit 09f91381fa5de1d44bc323d8bf345f5d57b3d9b5 upstream.
+
+Various rk3328 based boards experience occasional sdmmc0 write errors.
+This is due to the rk3328.dtsi tx drive levels being set to 4ma, vs
+8ma per the rk3328 datasheet default settings.
+
+Fix this by setting the tx signal pins to 8ma.
+Inspiration from tonymac32's patch,
+https://github.com/ayufan-rock64/linux-kernel/commit/dc1212b347e0da17c5460bcc0a56b07d02bac3f8
+
+Fixes issues on the rk3328-roc-cc and the rk3328-rock64 (as per the
+above commit message).
+
+Tested on the rk3328-roc-cc board.
+
+Fixes: 52e02d377a72 ("arm64: dts: rockchip: add core dtsi file for RK3328 SoCs")
+Cc: stable@vger.kernel.org
+Signed-off-by: Peter Geis <pgwipeout@gmail.com>
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/boot/dts/rockchip/rk3328.dtsi | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
++++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+@@ -1431,11 +1431,11 @@
+
+ sdmmc0 {
+ sdmmc0_clk: sdmmc0-clk {
+- rockchip,pins = <1 RK_PA6 1 &pcfg_pull_none_4ma>;
++ rockchip,pins = <1 RK_PA6 1 &pcfg_pull_none_8ma>;
+ };
+
+ sdmmc0_cmd: sdmmc0-cmd {
+- rockchip,pins = <1 RK_PA4 1 &pcfg_pull_up_4ma>;
++ rockchip,pins = <1 RK_PA4 1 &pcfg_pull_up_8ma>;
+ };
+
+ sdmmc0_dectn: sdmmc0-dectn {
+@@ -1447,14 +1447,14 @@
+ };
+
+ sdmmc0_bus1: sdmmc0-bus1 {
+- rockchip,pins = <1 RK_PA0 1 &pcfg_pull_up_4ma>;
++ rockchip,pins = <1 RK_PA0 1 &pcfg_pull_up_8ma>;
+ };
+
+ sdmmc0_bus4: sdmmc0-bus4 {
+- rockchip,pins = <1 RK_PA0 1 &pcfg_pull_up_4ma>,
+- <1 RK_PA1 1 &pcfg_pull_up_4ma>,
+- <1 RK_PA2 1 &pcfg_pull_up_4ma>,
+- <1 RK_PA3 1 &pcfg_pull_up_4ma>;
++ rockchip,pins = <1 RK_PA0 1 &pcfg_pull_up_8ma>,
++ <1 RK_PA1 1 &pcfg_pull_up_8ma>,
++ <1 RK_PA2 1 &pcfg_pull_up_8ma>,
++ <1 RK_PA3 1 &pcfg_pull_up_8ma>;
+ };
+
+ sdmmc0_gpio: sdmmc0-gpio {
--- /dev/null
+From dade58ed5af6365ac50ff4259c2a0bf31219e285 Mon Sep 17 00:00:00 2001
+From: Yan Zhao <yan.y.zhao@intel.com>
+Date: Wed, 27 Mar 2019 00:54:51 -0400
+Subject: drm/i915/gvt: do not deliver a workload if its creation fails
+
+From: Yan Zhao <yan.y.zhao@intel.com>
+
+commit dade58ed5af6365ac50ff4259c2a0bf31219e285 upstream.
+
+in workload creation routine, if any failure occurs, do not queue this
+workload for delivery. if this failure is fatal, enter into failsafe
+mode.
+
+Fixes: 6d76303553ba ("drm/i915/gvt: Move common vGPU workload creation into scheduler.c")
+Cc: stable@vger.kernel.org #4.19+
+Cc: zhenyuw@linux.intel.com
+Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
+Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/gvt/scheduler.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/i915/gvt/scheduler.c
++++ b/drivers/gpu/drm/i915/gvt/scheduler.c
+@@ -1475,8 +1475,9 @@ intel_vgpu_create_workload(struct intel_
+ intel_runtime_pm_put(dev_priv);
+ }
+
+- if (ret && (vgpu_is_vm_unhealthy(ret))) {
+- enter_failsafe_mode(vgpu, GVT_FAILSAFE_GUEST_ERR);
++ if (ret) {
++ if (vgpu_is_vm_unhealthy(ret))
++ enter_failsafe_mode(vgpu, GVT_FAILSAFE_GUEST_ERR);
+ intel_vgpu_destroy_workload(workload);
+ return ERR_PTR(ret);
+ }
--- /dev/null
+From cd9063757a227cf31ebf5391ccda2bf583b0806e Mon Sep 17 00:00:00 2001
+From: Jernej Skrabec <jernej.skrabec@siol.net>
+Date: Sun, 24 Mar 2019 20:06:09 +0100
+Subject: drm/sun4i: DW HDMI: Lower max. supported rate for H6
+
+From: Jernej Skrabec <jernej.skrabec@siol.net>
+
+commit cd9063757a227cf31ebf5391ccda2bf583b0806e upstream.
+
+Currently resolutions with pixel clock higher than 340 MHz don't work
+with H6 HDMI controller. They just produce a blank screen.
+
+Limit maximum pixel clock rate to 340 MHz until scrambling is supported.
+
+Cc: stable@vger.kernel.org # 5.0
+Fixes: 40bb9d3147b2 ("drm/sun4i: Add support for H6 DW HDMI controller")
+Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
+Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20190324190609.32721-1-jernej.skrabec@siol.net
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
++++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+@@ -48,8 +48,13 @@ static enum drm_mode_status
+ sun8i_dw_hdmi_mode_valid_h6(struct drm_connector *connector,
+ const struct drm_display_mode *mode)
+ {
+- /* This is max for HDMI 2.0b (4K@60Hz) */
+- if (mode->clock > 594000)
++ /*
++ * Controller support maximum of 594 MHz, which correlates to
++ * 4K@60Hz 4:4:4 or RGB. However, for frequencies greater than
++ * 340 MHz scrambling has to be enabled. Because scrambling is
++ * not yet implemented, just limit to 340 MHz for now.
++ */
++ if (mode->clock > 340000)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
--- /dev/null
+From 9b39b013037fbfa8d4b999345d9e904d8a336fc2 Mon Sep 17 00:00:00 2001
+From: Dave Airlie <airlied@redhat.com>
+Date: Fri, 5 Apr 2019 13:17:13 +1000
+Subject: drm/udl: add a release method and delay modeset teardown
+
+From: Dave Airlie <airlied@redhat.com>
+
+commit 9b39b013037fbfa8d4b999345d9e904d8a336fc2 upstream.
+
+If we unplug a udl device, the usb callback with deinit the
+mode_config struct, however userspace will still have an open
+file descriptor and a framebuffer on that device. When userspace
+closes the fd, we'll oops because it'll try and look stuff up
+in the object idr which we've destroyed.
+
+This punts destroying the mode objects until release time instead.
+
+Cc: stable@vger.kernel.org
+Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20190405031715.5959-2-airlied@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/udl/udl_drv.c | 1 +
+ drivers/gpu/drm/udl/udl_drv.h | 1 +
+ drivers/gpu/drm/udl/udl_main.c | 8 +++++++-
+ 3 files changed, 9 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/udl/udl_drv.c
++++ b/drivers/gpu/drm/udl/udl_drv.c
+@@ -51,6 +51,7 @@ static struct drm_driver driver = {
+ .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME,
+ .load = udl_driver_load,
+ .unload = udl_driver_unload,
++ .release = udl_driver_release,
+
+ /* gem hooks */
+ .gem_free_object_unlocked = udl_gem_free_object,
+--- a/drivers/gpu/drm/udl/udl_drv.h
++++ b/drivers/gpu/drm/udl/udl_drv.h
+@@ -104,6 +104,7 @@ void udl_urb_completion(struct urb *urb)
+
+ int udl_driver_load(struct drm_device *dev, unsigned long flags);
+ void udl_driver_unload(struct drm_device *dev);
++void udl_driver_release(struct drm_device *dev);
+
+ int udl_fbdev_init(struct drm_device *dev);
+ void udl_fbdev_cleanup(struct drm_device *dev);
+--- a/drivers/gpu/drm/udl/udl_main.c
++++ b/drivers/gpu/drm/udl/udl_main.c
+@@ -378,6 +378,12 @@ void udl_driver_unload(struct drm_device
+ udl_free_urb_list(dev);
+
+ udl_fbdev_cleanup(dev);
+- udl_modeset_cleanup(dev);
+ kfree(udl);
+ }
++
++void udl_driver_release(struct drm_device *dev)
++{
++ udl_modeset_cleanup(dev);
++ drm_dev_fini(dev);
++ kfree(dev);
++}
--- /dev/null
+From 6147e136ff5071609b54f18982dea87706288e21 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Fri, 5 Apr 2019 18:38:53 -0700
+Subject: include/linux/bitrev.h: fix constant bitrev
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit 6147e136ff5071609b54f18982dea87706288e21 upstream.
+
+clang points out with hundreds of warnings that the bitrev macros have a
+problem with constant input:
+
+ drivers/hwmon/sht15.c:187:11: error: variable '__x' is uninitialized when used within its own initialization
+ [-Werror,-Wuninitialized]
+ u8 crc = bitrev8(data->val_status & 0x0F);
+ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ include/linux/bitrev.h:102:21: note: expanded from macro 'bitrev8'
+ __constant_bitrev8(__x) : \
+ ~~~~~~~~~~~~~~~~~~~^~~~
+ include/linux/bitrev.h:67:11: note: expanded from macro '__constant_bitrev8'
+ u8 __x = x; \
+ ~~~ ^
+
+Both the bitrev and the __constant_bitrev macros use an internal
+variable named __x, which goes horribly wrong when passing one to the
+other.
+
+The obvious fix is to rename one of the variables, so this adds an extra
+'_'.
+
+It seems we got away with this because
+
+ - there are only a few drivers using bitrev macros
+
+ - usually there are no constant arguments to those
+
+ - when they are constant, they tend to be either 0 or (unsigned)-1
+ (drivers/isdn/i4l/isdnhdlc.o, drivers/iio/amplifiers/ad8366.c) and
+ give the correct result by pure chance.
+
+In fact, the only driver that I could find that gets different results
+with this is drivers/net/wan/slic_ds26522.c, which in turn is a driver
+for fairly rare hardware (adding the maintainer to Cc for testing).
+
+Link: http://lkml.kernel.org/r/20190322140503.123580-1-arnd@arndb.de
+Fixes: 556d2f055bf6 ("ARM: 8187/1: add CONFIG_HAVE_ARCH_BITREVERSE to support rbit instruction")
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
+Cc: Zhao Qiang <qiang.zhao@nxp.com>
+Cc: Yalin Wang <yalin.wang@sonymobile.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/bitrev.h | 46 +++++++++++++++++++++++-----------------------
+ 1 file changed, 23 insertions(+), 23 deletions(-)
+
+--- a/include/linux/bitrev.h
++++ b/include/linux/bitrev.h
+@@ -34,41 +34,41 @@ static inline u32 __bitrev32(u32 x)
+
+ #define __constant_bitrev32(x) \
+ ({ \
+- u32 __x = x; \
+- __x = (__x >> 16) | (__x << 16); \
+- __x = ((__x & (u32)0xFF00FF00UL) >> 8) | ((__x & (u32)0x00FF00FFUL) << 8); \
+- __x = ((__x & (u32)0xF0F0F0F0UL) >> 4) | ((__x & (u32)0x0F0F0F0FUL) << 4); \
+- __x = ((__x & (u32)0xCCCCCCCCUL) >> 2) | ((__x & (u32)0x33333333UL) << 2); \
+- __x = ((__x & (u32)0xAAAAAAAAUL) >> 1) | ((__x & (u32)0x55555555UL) << 1); \
+- __x; \
++ u32 ___x = x; \
++ ___x = (___x >> 16) | (___x << 16); \
++ ___x = ((___x & (u32)0xFF00FF00UL) >> 8) | ((___x & (u32)0x00FF00FFUL) << 8); \
++ ___x = ((___x & (u32)0xF0F0F0F0UL) >> 4) | ((___x & (u32)0x0F0F0F0FUL) << 4); \
++ ___x = ((___x & (u32)0xCCCCCCCCUL) >> 2) | ((___x & (u32)0x33333333UL) << 2); \
++ ___x = ((___x & (u32)0xAAAAAAAAUL) >> 1) | ((___x & (u32)0x55555555UL) << 1); \
++ ___x; \
+ })
+
+ #define __constant_bitrev16(x) \
+ ({ \
+- u16 __x = x; \
+- __x = (__x >> 8) | (__x << 8); \
+- __x = ((__x & (u16)0xF0F0U) >> 4) | ((__x & (u16)0x0F0FU) << 4); \
+- __x = ((__x & (u16)0xCCCCU) >> 2) | ((__x & (u16)0x3333U) << 2); \
+- __x = ((__x & (u16)0xAAAAU) >> 1) | ((__x & (u16)0x5555U) << 1); \
+- __x; \
++ u16 ___x = x; \
++ ___x = (___x >> 8) | (___x << 8); \
++ ___x = ((___x & (u16)0xF0F0U) >> 4) | ((___x & (u16)0x0F0FU) << 4); \
++ ___x = ((___x & (u16)0xCCCCU) >> 2) | ((___x & (u16)0x3333U) << 2); \
++ ___x = ((___x & (u16)0xAAAAU) >> 1) | ((___x & (u16)0x5555U) << 1); \
++ ___x; \
+ })
+
+ #define __constant_bitrev8x4(x) \
+ ({ \
+- u32 __x = x; \
+- __x = ((__x & (u32)0xF0F0F0F0UL) >> 4) | ((__x & (u32)0x0F0F0F0FUL) << 4); \
+- __x = ((__x & (u32)0xCCCCCCCCUL) >> 2) | ((__x & (u32)0x33333333UL) << 2); \
+- __x = ((__x & (u32)0xAAAAAAAAUL) >> 1) | ((__x & (u32)0x55555555UL) << 1); \
+- __x; \
++ u32 ___x = x; \
++ ___x = ((___x & (u32)0xF0F0F0F0UL) >> 4) | ((___x & (u32)0x0F0F0F0FUL) << 4); \
++ ___x = ((___x & (u32)0xCCCCCCCCUL) >> 2) | ((___x & (u32)0x33333333UL) << 2); \
++ ___x = ((___x & (u32)0xAAAAAAAAUL) >> 1) | ((___x & (u32)0x55555555UL) << 1); \
++ ___x; \
+ })
+
+ #define __constant_bitrev8(x) \
+ ({ \
+- u8 __x = x; \
+- __x = (__x >> 4) | (__x << 4); \
+- __x = ((__x & (u8)0xCCU) >> 2) | ((__x & (u8)0x33U) << 2); \
+- __x = ((__x & (u8)0xAAU) >> 1) | ((__x & (u8)0x55U) << 1); \
+- __x; \
++ u8 ___x = x; \
++ ___x = (___x >> 4) | (___x << 4); \
++ ___x = ((___x & (u8)0xCCU) >> 2) | ((___x & (u8)0x33U) << 2); \
++ ___x = ((___x & (u8)0xAAU) >> 1) | ((___x & (u8)0x55U) << 1); \
++ ___x; \
+ })
+
+ #define bitrev32(x) \
--- /dev/null
+From ede885ecb2cdf8a8dd5367702e3d964ec846a2d5 Mon Sep 17 00:00:00 2001
+From: David Rientjes <rientjes@google.com>
+Date: Tue, 19 Mar 2019 15:19:56 -0700
+Subject: kvm: svm: fix potential get_num_contig_pages overflow
+
+From: David Rientjes <rientjes@google.com>
+
+commit ede885ecb2cdf8a8dd5367702e3d964ec846a2d5 upstream.
+
+get_num_contig_pages() could potentially overflow int so make its type
+consistent with its usage.
+
+Reported-by: Cfir Cohen <cfir@google.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: David Rientjes <rientjes@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/svm.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/arch/x86/kvm/svm.c
++++ b/arch/x86/kvm/svm.c
+@@ -6422,11 +6422,11 @@ e_free:
+ return ret;
+ }
+
+-static int get_num_contig_pages(int idx, struct page **inpages,
+- unsigned long npages)
++static unsigned long get_num_contig_pages(unsigned long idx,
++ struct page **inpages, unsigned long npages)
+ {
+ unsigned long paddr, next_paddr;
+- int i = idx + 1, pages = 1;
++ unsigned long i = idx + 1, pages = 1;
+
+ /* find the number of contiguous pages starting from idx */
+ paddr = __sme_page_pa(inpages[idx]);
+@@ -6445,12 +6445,12 @@ static int get_num_contig_pages(int idx,
+
+ static int sev_launch_update_data(struct kvm *kvm, struct kvm_sev_cmd *argp)
+ {
+- unsigned long vaddr, vaddr_end, next_vaddr, npages, size;
++ unsigned long vaddr, vaddr_end, next_vaddr, npages, pages, size, i;
+ struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info;
+ struct kvm_sev_launch_update_data params;
+ struct sev_data_launch_update_data *data;
+ struct page **inpages;
+- int i, ret, pages;
++ int ret;
+
+ if (!sev_guest(kvm))
+ return -ENOTTY;
--- /dev/null
+From c6f3c5ee40c10bb65725047a220570f718507001 Mon Sep 17 00:00:00 2001
+From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
+Date: Fri, 5 Apr 2019 18:39:10 -0700
+Subject: mm/huge_memory.c: fix modifying of page protection by insert_pfn_pmd()
+
+From: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
+
+commit c6f3c5ee40c10bb65725047a220570f718507001 upstream.
+
+With some architectures like ppc64, set_pmd_at() cannot cope with a
+situation where there is already some (different) valid entry present.
+
+Use pmdp_set_access_flags() instead to modify the pfn which is built to
+deal with modifying existing PMD entries.
+
+This is similar to commit cae85cb8add3 ("mm/memory.c: fix modifying of
+page protection by insert_pfn()")
+
+We also do similar update w.r.t insert_pfn_pud eventhough ppc64 don't
+support pud pfn entries now.
+
+Without this patch we also see the below message in kernel log "BUG:
+non-zero pgtables_bytes on freeing mm:"
+
+Link: http://lkml.kernel.org/r/20190402115125.18803-1-aneesh.kumar@linux.ibm.com
+Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
+Reported-by: Chandan Rajendra <chandan@linux.ibm.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Cc: Dan Williams <dan.j.williams@intel.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/huge_memory.c | 36 ++++++++++++++++++++++++++++++++++++
+ 1 file changed, 36 insertions(+)
+
+--- a/mm/huge_memory.c
++++ b/mm/huge_memory.c
+@@ -753,6 +753,21 @@ static void insert_pfn_pmd(struct vm_are
+ spinlock_t *ptl;
+
+ ptl = pmd_lock(mm, pmd);
++ if (!pmd_none(*pmd)) {
++ if (write) {
++ if (pmd_pfn(*pmd) != pfn_t_to_pfn(pfn)) {
++ WARN_ON_ONCE(!is_huge_zero_pmd(*pmd));
++ goto out_unlock;
++ }
++ entry = pmd_mkyoung(*pmd);
++ entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma);
++ if (pmdp_set_access_flags(vma, addr, pmd, entry, 1))
++ update_mmu_cache_pmd(vma, addr, pmd);
++ }
++
++ goto out_unlock;
++ }
++
+ entry = pmd_mkhuge(pfn_t_pmd(pfn, prot));
+ if (pfn_t_devmap(pfn))
+ entry = pmd_mkdevmap(entry);
+@@ -764,11 +779,16 @@ static void insert_pfn_pmd(struct vm_are
+ if (pgtable) {
+ pgtable_trans_huge_deposit(mm, pmd, pgtable);
+ mm_inc_nr_ptes(mm);
++ pgtable = NULL;
+ }
+
+ set_pmd_at(mm, addr, pmd, entry);
+ update_mmu_cache_pmd(vma, addr, pmd);
++
++out_unlock:
+ spin_unlock(ptl);
++ if (pgtable)
++ pte_free(mm, pgtable);
+ }
+
+ vm_fault_t vmf_insert_pfn_pmd(struct vm_area_struct *vma, unsigned long addr,
+@@ -819,6 +839,20 @@ static void insert_pfn_pud(struct vm_are
+ spinlock_t *ptl;
+
+ ptl = pud_lock(mm, pud);
++ if (!pud_none(*pud)) {
++ if (write) {
++ if (pud_pfn(*pud) != pfn_t_to_pfn(pfn)) {
++ WARN_ON_ONCE(!is_huge_zero_pud(*pud));
++ goto out_unlock;
++ }
++ entry = pud_mkyoung(*pud);
++ entry = maybe_pud_mkwrite(pud_mkdirty(entry), vma);
++ if (pudp_set_access_flags(vma, addr, pud, entry, 1))
++ update_mmu_cache_pud(vma, addr, pud);
++ }
++ goto out_unlock;
++ }
++
+ entry = pud_mkhuge(pfn_t_pud(pfn, prot));
+ if (pfn_t_devmap(pfn))
+ entry = pud_mkdevmap(entry);
+@@ -828,6 +862,8 @@ static void insert_pfn_pud(struct vm_are
+ }
+ set_pud_at(mm, addr, pud, entry);
+ update_mmu_cache_pud(vma, addr, pud);
++
++out_unlock:
+ spin_unlock(ptl);
+ }
+
--- /dev/null
+From 157c99c5a2956a9ab1ae12de0136a2d8a1b1a307 Mon Sep 17 00:00:00 2001
+From: Daniel Drake <drake@endlessm.com>
+Date: Tue, 26 Mar 2019 15:04:14 +0800
+Subject: mmc: alcor: don't write data before command has completed
+
+From: Daniel Drake <drake@endlessm.com>
+
+commit 157c99c5a2956a9ab1ae12de0136a2d8a1b1a307 upstream.
+
+The alcor driver is setting up data transfer and submitting the associated
+MMC command at the same time. While this works most of the time, it
+occasionally causes problems upon write.
+
+In the working case, after setting up the data transfer and submitting
+the MMC command, an interrupt comes in a moment later with CMD_END and
+WRITE_BUF_RDY bits set. The data transfer then happens without problem.
+
+However, on occasion, the interrupt that arrives at that point only
+has WRITE_BUF_RDY set. The hardware notifies that it's ready to write
+data, but the associated MMC command is still running. Regardless, the
+driver was proceeding to write data immediately, and that would then cause
+another interrupt indicating data CRC error, and the write would fail.
+
+Additionally, the transfer setup function alcor_trigger_data_transfer()
+was being called 3 times for each write operation, which was confusing
+and may be contributing to this issue.
+
+Solve this by tweaking the driver behaviour to follow the sequence observed
+in the original ampe_stor vendor driver:
+ 1. When starting request handling, write 0 to DATA_XFER_CTRL
+ 2. Submit the command
+ 3. Wait for CMD_END interrupt and then trigger data transfer
+ 4. For the PIO case, trigger the next step of the data transfer only
+ upon the following DATA_END interrupt, which occurs after the block has
+ been written.
+
+I confirmed that the read path still works (DMA & PIO) and also now
+presents more consistency with the operations performed by ampe_stor.
+
+Signed-off-by: Daniel Drake <drake@endlessm.com>
+Fixes: c5413ad815a6 ("mmc: add new Alcor Micro Cardreader SD/MMC driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/alcor.c | 34 +++++++++++++---------------------
+ 1 file changed, 13 insertions(+), 21 deletions(-)
+
+--- a/drivers/mmc/host/alcor.c
++++ b/drivers/mmc/host/alcor.c
+@@ -48,7 +48,6 @@ struct alcor_sdmmc_host {
+ struct mmc_command *cmd;
+ struct mmc_data *data;
+ unsigned int dma_on:1;
+- unsigned int early_data:1;
+
+ struct mutex cmd_mutex;
+
+@@ -144,8 +143,7 @@ static void alcor_data_set_dma(struct al
+ host->sg_count--;
+ }
+
+-static void alcor_trigger_data_transfer(struct alcor_sdmmc_host *host,
+- bool early)
++static void alcor_trigger_data_transfer(struct alcor_sdmmc_host *host)
+ {
+ struct alcor_pci_priv *priv = host->alcor_pci;
+ struct mmc_data *data = host->data;
+@@ -155,13 +153,6 @@ static void alcor_trigger_data_transfer(
+ ctrl |= AU6601_DATA_WRITE;
+
+ if (data->host_cookie == COOKIE_MAPPED) {
+- if (host->early_data) {
+- host->early_data = false;
+- return;
+- }
+-
+- host->early_data = early;
+-
+ alcor_data_set_dma(host);
+ ctrl |= AU6601_DATA_DMA_MODE;
+ host->dma_on = 1;
+@@ -231,6 +222,7 @@ static void alcor_prepare_sg_miter(struc
+ static void alcor_prepare_data(struct alcor_sdmmc_host *host,
+ struct mmc_command *cmd)
+ {
++ struct alcor_pci_priv *priv = host->alcor_pci;
+ struct mmc_data *data = cmd->data;
+
+ if (!data)
+@@ -248,7 +240,7 @@ static void alcor_prepare_data(struct al
+ if (data->host_cookie != COOKIE_MAPPED)
+ alcor_prepare_sg_miter(host);
+
+- alcor_trigger_data_transfer(host, true);
++ alcor_write8(priv, 0, AU6601_DATA_XFER_CTRL);
+ }
+
+ static void alcor_send_cmd(struct alcor_sdmmc_host *host,
+@@ -435,7 +427,7 @@ static int alcor_cmd_irq_done(struct alc
+ if (!host->data)
+ return false;
+
+- alcor_trigger_data_transfer(host, false);
++ alcor_trigger_data_transfer(host);
+ host->cmd = NULL;
+ return true;
+ }
+@@ -456,7 +448,7 @@ static void alcor_cmd_irq_thread(struct
+ if (!host->data)
+ alcor_request_complete(host, 1);
+ else
+- alcor_trigger_data_transfer(host, false);
++ alcor_trigger_data_transfer(host);
+ host->cmd = NULL;
+ }
+
+@@ -487,15 +479,9 @@ static int alcor_data_irq_done(struct al
+ break;
+ case AU6601_INT_READ_BUF_RDY:
+ alcor_trf_block_pio(host, true);
+- if (!host->blocks)
+- break;
+- alcor_trigger_data_transfer(host, false);
+ return 1;
+ case AU6601_INT_WRITE_BUF_RDY:
+ alcor_trf_block_pio(host, false);
+- if (!host->blocks)
+- break;
+- alcor_trigger_data_transfer(host, false);
+ return 1;
+ case AU6601_INT_DMA_END:
+ if (!host->sg_count)
+@@ -508,8 +494,14 @@ static int alcor_data_irq_done(struct al
+ break;
+ }
+
+- if (intmask & AU6601_INT_DATA_END)
+- return 0;
++ if (intmask & AU6601_INT_DATA_END) {
++ if (!host->dma_on && host->blocks) {
++ alcor_trigger_data_transfer(host);
++ return 1;
++ } else {
++ return 0;
++ }
++ }
+
+ return 1;
+ }
--- /dev/null
+From 5c41ea6d52003b5bc77c2a82fd5ca7d480237d89 Mon Sep 17 00:00:00 2001
+From: Faiz Abbas <faiz_abbas@ti.com>
+Date: Thu, 11 Apr 2019 14:29:37 +0530
+Subject: mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning
+
+From: Faiz Abbas <faiz_abbas@ti.com>
+
+commit 5c41ea6d52003b5bc77c2a82fd5ca7d480237d89 upstream.
+
+commit 5b0d62108b46 ("mmc: sdhci-omap: Add platform specific reset
+callback") skips data resets during tuning operation. Because of this,
+a data error or data finish interrupt might still arrive after a command
+error has been handled and the mrq ended. This ends up with a "mmc0: Got
+data interrupt 0x00000002 even though no data operation was in progress"
+error message.
+
+Fix this by adding a platform specific callback for sdhci_irq. Mark the
+mrq as a failure but wait for a data interrupt instead of calling
+finish_mrq().
+
+Fixes: 5b0d62108b46 ("mmc: sdhci-omap: Add platform specific reset
+callback")
+Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-omap.c | 38 ++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 38 insertions(+)
+
+--- a/drivers/mmc/host/sdhci-omap.c
++++ b/drivers/mmc/host/sdhci-omap.c
+@@ -797,6 +797,43 @@ void sdhci_omap_reset(struct sdhci_host
+ sdhci_reset(host, mask);
+ }
+
++#define CMD_ERR_MASK (SDHCI_INT_CRC | SDHCI_INT_END_BIT | SDHCI_INT_INDEX |\
++ SDHCI_INT_TIMEOUT)
++#define CMD_MASK (CMD_ERR_MASK | SDHCI_INT_RESPONSE)
++
++static u32 sdhci_omap_irq(struct sdhci_host *host, u32 intmask)
++{
++ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
++ struct sdhci_omap_host *omap_host = sdhci_pltfm_priv(pltfm_host);
++
++ if (omap_host->is_tuning && host->cmd && !host->data_early &&
++ (intmask & CMD_ERR_MASK)) {
++
++ /*
++ * Since we are not resetting data lines during tuning
++ * operation, data error or data complete interrupts
++ * might still arrive. Mark this request as a failure
++ * but still wait for the data interrupt
++ */
++ if (intmask & SDHCI_INT_TIMEOUT)
++ host->cmd->error = -ETIMEDOUT;
++ else
++ host->cmd->error = -EILSEQ;
++
++ host->cmd = NULL;
++
++ /*
++ * Sometimes command error interrupts and command complete
++ * interrupt will arrive together. Clear all command related
++ * interrupts here.
++ */
++ sdhci_writel(host, intmask & CMD_MASK, SDHCI_INT_STATUS);
++ intmask &= ~CMD_MASK;
++ }
++
++ return intmask;
++}
++
+ static struct sdhci_ops sdhci_omap_ops = {
+ .set_clock = sdhci_omap_set_clock,
+ .set_power = sdhci_omap_set_power,
+@@ -807,6 +844,7 @@ static struct sdhci_ops sdhci_omap_ops =
+ .platform_send_init_74_clocks = sdhci_omap_init_74_clocks,
+ .reset = sdhci_omap_reset,
+ .set_uhs_signaling = sdhci_omap_set_uhs_signaling,
++ .irq = sdhci_omap_irq,
+ };
+
+ static int sdhci_omap_set_capabilities(struct sdhci_omap_host *omap_host)
--- /dev/null
+From f324fa58327791b2696628b31480e7e21c745706 Mon Sep 17 00:00:00 2001
+From: Sven Schnelle <svens@stackframe.org>
+Date: Thu, 4 Apr 2019 18:16:04 +0200
+Subject: parisc: also set iaoq_b in instruction_pointer_set()
+
+From: Sven Schnelle <svens@stackframe.org>
+
+commit f324fa58327791b2696628b31480e7e21c745706 upstream.
+
+When setting the instruction pointer on PA-RISC we also need
+to set the back of the instruction queue to the new offset, otherwise
+we will execute on instruction from the new location, and jumping
+back to the old location stored in iaoq_b.
+
+Signed-off-by: Sven Schnelle <svens@stackframe.org>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Fixes: 75ebedf1d263 ("parisc: Add HAVE_REGS_AND_STACK_ACCESS_API feature")
+Cc: stable@vger.kernel.org # 4.19+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/parisc/include/asm/ptrace.h | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/parisc/include/asm/ptrace.h
++++ b/arch/parisc/include/asm/ptrace.h
+@@ -28,7 +28,8 @@ static inline unsigned long regs_return_
+ static inline void instruction_pointer_set(struct pt_regs *regs,
+ unsigned long val)
+ {
+- regs->iaoq[0] = val;
++ regs->iaoq[0] = val;
++ regs->iaoq[1] = val + 4;
+ }
+
+ /* Query offset/name of register from its name/offset */
--- /dev/null
+From d006e95b5561f708d0385e9677ffe2c46f2ae345 Mon Sep 17 00:00:00 2001
+From: Helge Deller <deller@gmx.de>
+Date: Tue, 2 Apr 2019 12:13:27 +0200
+Subject: parisc: Detect QEMU earlier in boot process
+
+From: Helge Deller <deller@gmx.de>
+
+commit d006e95b5561f708d0385e9677ffe2c46f2ae345 upstream.
+
+While adding LASI support to QEMU, I noticed that the QEMU detection in
+the kernel happens much too late. For example, when a LASI chip is found
+by the kernel, it registers the LASI LED driver as well. But when we
+run on QEMU it makes sense to avoid spending unnecessary CPU cycles, so
+we need to access the running_on_QEMU flag earlier than before.
+
+This patch now makes the QEMU detection the fist task of the Linux
+kernel by moving it to where the kernel enters the C-coding.
+
+Fixes: 310d82784fb4 ("parisc: qemu idle sleep support")
+Signed-off-by: Helge Deller <deller@gmx.de>
+Cc: stable@vger.kernel.org # v4.14+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/parisc/kernel/process.c | 6 ------
+ arch/parisc/kernel/setup.c | 3 +++
+ 2 files changed, 3 insertions(+), 6 deletions(-)
+
+--- a/arch/parisc/kernel/process.c
++++ b/arch/parisc/kernel/process.c
+@@ -210,12 +210,6 @@ void __cpuidle arch_cpu_idle(void)
+
+ static int __init parisc_idle_init(void)
+ {
+- const char *marker;
+-
+- /* check QEMU/SeaBIOS marker in PAGE0 */
+- marker = (char *) &PAGE0->pad0;
+- running_on_qemu = (memcmp(marker, "SeaBIOS", 8) == 0);
+-
+ if (!running_on_qemu)
+ cpu_idle_poll_ctrl(1);
+
+--- a/arch/parisc/kernel/setup.c
++++ b/arch/parisc/kernel/setup.c
+@@ -396,6 +396,9 @@ void __init start_parisc(void)
+ int ret, cpunum;
+ struct pdc_coproc_cfg coproc_cfg;
+
++ /* check QEMU/SeaBIOS marker in PAGE0 */
++ running_on_qemu = (memcmp(&PAGE0->pad0, "SeaBIOS", 8) == 0);
++
+ cpunum = smp_processor_id();
+
+ init_cpu_topology();
--- /dev/null
+From 45efd871bf0a47648f119d1b41467f70484de5bc Mon Sep 17 00:00:00 2001
+From: Sven Schnelle <svens@stackframe.org>
+Date: Thu, 4 Apr 2019 18:16:03 +0200
+Subject: parisc: regs_return_value() should return gpr28
+
+From: Sven Schnelle <svens@stackframe.org>
+
+commit 45efd871bf0a47648f119d1b41467f70484de5bc upstream.
+
+While working on kretprobes for PA-RISC I was wondering while the
+kprobes sanity test always fails on kretprobes. This is caused by
+returning gpr20 instead of gpr28.
+
+Signed-off-by: Sven Schnelle <svens@stackframe.org>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Cc: stable@vger.kernel.org # 4.14+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/parisc/include/asm/ptrace.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/parisc/include/asm/ptrace.h
++++ b/arch/parisc/include/asm/ptrace.h
+@@ -22,7 +22,7 @@ unsigned long profile_pc(struct pt_regs
+
+ static inline unsigned long regs_return_value(struct pt_regs *regs)
+ {
+- return regs->gr[20];
++ return regs->gr[28];
+ }
+
+ static inline void instruction_pointer_set(struct pt_regs *regs,
alsa-hda-realtek-add-quirk-for-tuxedo-xc-1509.patch
alsa-xen-front-do-not-use-stream-buffer-size-before-it-is-set.patch
alsa-hda-add-two-more-machines-to-the-power_save_blacklist.patch
+mm-huge_memory.c-fix-modifying-of-page-protection-by-insert_pfn_pmd.patch
+arm64-dts-rockchip-fix-rk3328-sdmmc0-write-errors.patch
+mmc-alcor-don-t-write-data-before-command-has-completed.patch
+mmc-sdhci-omap-don-t-finish_mrq-on-a-command-error-during-tuning.patch
+parisc-detect-qemu-earlier-in-boot-process.patch
+parisc-regs_return_value-should-return-gpr28.patch
+parisc-also-set-iaoq_b-in-instruction_pointer_set.patch
+alarmtimer-return-correct-remaining-time.patch
+drm-i915-gvt-do-not-deliver-a-workload-if-its-creation-fails.patch
+drm-sun4i-dw-hdmi-lower-max.-supported-rate-for-h6.patch
+drm-udl-add-a-release-method-and-delay-modeset-teardown.patch
+kvm-svm-fix-potential-get_num_contig_pages-overflow.patch
+include-linux-bitrev.h-fix-constant-bitrev.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
