--- /dev/null
+From 8c9d90eebd23b6d40ddf4ce5df5ca2b932336a06 Mon Sep 17 00:00:00 2001
+From: "Jerry (Fangzhi) Zuo" <Jerry.Zuo@amd.com>
+Date: Mon, 17 Dec 2018 10:32:22 -0500
+Subject: drm/amd/display: Fix MST dp_blank REG_WAIT timeout
+
+From: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com>
+
+commit 8c9d90eebd23b6d40ddf4ce5df5ca2b932336a06 upstream.
+
+Need to blank stream before deallocate MST payload.
+
+[drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 10us * 3000 tries - dce110_stream_encoder_dp_blank line:944
+------------[ cut here ]------------
+WARNING: CPU: 0 PID: 2201 at /var/lib/dkms/amdgpu/18.50-690240/build/amd/amdgpu/../display/dc/dc_helper.c:249 generic_reg_wait+0xe7/0x160 [amdgpu]
+Call Trace:
+ dce110_stream_encoder_dp_blank+0x11c/0x180 [amdgpu]
+ core_link_disable_stream+0x40/0x230 [amdgpu]
+ ? generic_reg_update_ex+0xdb/0x130 [amdgpu]
+ dce110_reset_hw_ctx_wrap+0xb7/0x1f0 [amdgpu]
+ dce110_apply_ctx_to_hw+0x30/0x430 [amdgpu]
+ ? dce110_apply_ctx_for_surface+0x206/0x260 [amdgpu]
+ dc_commit_state+0x2ba/0x4d0 [amdgpu]
+ amdgpu_dm_atomic_commit_tail+0x297/0xd70 [amdgpu]
+ ? amdgpu_bo_pin_restricted+0x58/0x260 [amdgpu]
+ ? wait_for_completion_timeout+0x1f/0x120
+ ? wait_for_completion_interruptible+0x1c/0x160
+ commit_tail+0x3d/0x60 [drm_kms_helper]
+ drm_atomic_helper_commit+0xf6/0x100 [drm_kms_helper]
+ drm_atomic_connector_commit_dpms+0xe5/0xf0 [drm]
+ drm_mode_obj_set_property_ioctl+0x14f/0x250 [drm]
+ drm_mode_connector_property_set_ioctl+0x2e/0x40 [drm]
+ drm_ioctl+0x1e0/0x430 [drm]
+ ? drm_mode_connector_set_obj_prop+0x70/0x70 [drm]
+ ? ep_read_events_proc+0xb0/0xb0
+ ? ep_scan_ready_list.constprop.18+0x1e6/0x1f0
+ ? timerqueue_add+0x52/0x80
+ amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
+ do_vfs_ioctl+0x90/0x5f0
+ SyS_ioctl+0x74/0x80
+ do_syscall_64+0x74/0x140
+ entry_SYSCALL_64_after_hwframe+0x3d/0xa2
+---[ end trace 3ed7b77a97d60f72 ]---
+
+Signed-off-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com>
+Reviewed-by: Hersen Wu <hersenxs.wu@amd.com>
+Acked-by: Harry Wentland <harry.wentland@amd.com>
+Acked-by: Alex Deucher <alexander.deucher@amd.com>
+Tested-by: Lyude Paul <lyude@redhat.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/amd/display/dc/core/dc_link.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
++++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+@@ -2457,11 +2457,11 @@ void core_link_disable_stream(struct pip
+ {
+ struct dc *core_dc = pipe_ctx->stream->ctx->dc;
+
++ core_dc->hwss.blank_stream(pipe_ctx);
++
+ if (pipe_ctx->stream->signal == SIGNAL_TYPE_DISPLAY_PORT_MST)
+ deallocate_mst_payload(pipe_ctx);
+
+- core_dc->hwss.blank_stream(pipe_ctx);
+-
+ core_dc->hwss.disable_stream(pipe_ctx, option);
+
+ disable_link(pipe_ctx->stream->sink->link, pipe_ctx->stream->signal);
--- /dev/null
+From f6653a0e0877572c87f6dab5351e7bd6b6b7100c Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Thu, 20 Dec 2018 10:08:46 -0500
+Subject: drm/amdgpu: Add new VegaM pci id
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit f6653a0e0877572c87f6dab5351e7bd6b6b7100c upstream.
+
+Add a new pci id.
+
+Reviewed-by: Leo Liu <leo.liu@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+@@ -753,6 +753,7 @@ static const struct pci_device_id pciidl
+ /* VEGAM */
+ {0x1002, 0x694C, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGAM},
+ {0x1002, 0x694E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGAM},
++ {0x1002, 0x694F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGAM},
+ /* Vega 10 */
+ {0x1002, 0x6860, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10},
+ {0x1002, 0x6861, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10},
--- /dev/null
+From 2d1af6a11cb9d88e0e3dd10258904c437fe1b315 Mon Sep 17 00:00:00 2001
+From: Lyude Paul <lyude@redhat.com>
+Date: Tue, 8 Jan 2019 16:11:28 -0500
+Subject: drm/amdgpu: Don't fail resume process if resuming atomic state fails
+
+From: Lyude Paul <lyude@redhat.com>
+
+commit 2d1af6a11cb9d88e0e3dd10258904c437fe1b315 upstream.
+
+This is an ugly one unfortunately. Currently, all DRM drivers supporting
+atomic modesetting will save the state that userspace had set before
+suspending, then attempt to restore that state on resume. This probably
+worked very well at one point, like many other things, until DP MST came
+into the picture. While it's easy to restore state on normal display
+connectors that were disconnected during suspend regardless of their
+state post-resume, this can't really be done with MST because of the
+fact that setting up a downstream sink requires performing sideband
+transactions between the source and the MST hub, sending out the ACT
+packets, etc.
+
+Because of this, there isn't really a guarantee that we can restore the
+atomic state we had before suspend once we've resumed. This sucks pretty
+bad, but so far I haven't run into any compositors that this actually
+causes serious issues with. Most compositors will notice the hotplug we
+send afterwards, and then reprobe state.
+
+Since nouveau and i915 also don't fail the suspend/resume process due to
+failing to restore the atomic state, let's make amdgpu match this
+behavior. Better to resume the GPU properly, then to stop the process
+half way because of a potentially unavoidable atomic commit failure.
+
+Eventually, we'll have a real fix for this problem on the DRM level. But
+we've got some more important low-hanging fruit to deal with first.
+
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Reviewed-by: Harry Wentland <harry.wentland@amd.com>
+Cc: Jerry Zuo <Jerry.Zuo@amd.com>
+Cc: <stable@vger.kernel.org> # v4.15+
+Link: https://patchwork.freedesktop.org/patch/msgid/20190108211133.32564-3-lyude@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+@@ -750,7 +750,6 @@ static int dm_resume(void *handle)
+ struct drm_plane_state *new_plane_state;
+ struct dm_plane_state *dm_new_plane_state;
+ enum dc_connection_type new_connection_type = dc_connection_none;
+- int ret;
+ int i;
+
+ /* power on hardware */
+@@ -823,13 +822,13 @@ static int dm_resume(void *handle)
+ }
+ }
+
+- ret = drm_atomic_helper_resume(ddev, dm->cached_state);
++ drm_atomic_helper_resume(ddev, dm->cached_state);
+
+ dm->cached_state = NULL;
+
+ amdgpu_dm_irq_resume_late(adev);
+
+- return ret;
++ return 0;
+ }
+
+ static const struct amd_ip_funcs amdgpu_dm_funcs = {
--- /dev/null
+From fe7553bef8d676d1d8b40666868b33ec39b9df5d Mon Sep 17 00:00:00 2001
+From: Lyude Paul <lyude@redhat.com>
+Date: Tue, 8 Jan 2019 16:11:27 -0500
+Subject: drm/amdgpu: Don't ignore rc from drm_dp_mst_topology_mgr_resume()
+
+From: Lyude Paul <lyude@redhat.com>
+
+commit fe7553bef8d676d1d8b40666868b33ec39b9df5d upstream.
+
+drm_dp_mst_topology_mgr_resume() returns whether or not it managed to
+find the topology in question after a suspend resume cycle, and the
+driver is supposed to check this value and disable MST accordingly if
+it's gone-in addition to sending a hotplug in order to notify userspace
+that something changed during suspend.
+
+Currently, amdgpu just makes the mistake of ignoring the return code
+from drm_dp_mst_topology_mgr_resume() which means that if a topology was
+removed in suspend, amdgpu never notices and assumes it's still
+connected which leads to all sorts of problems.
+
+So, fix this by actually checking the rc from
+drm_dp_mst_topology_mgr_resume(). Also, reformat the rest of the
+function while we're at it to fix the over-indenting.
+
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Reviewed-by: Harry Wentland <harry.wentland@amd.com>
+Cc: Jerry Zuo <Jerry.Zuo@amd.com>
+Cc: <stable@vger.kernel.org> # v4.15+
+Link: https://patchwork.freedesktop.org/patch/msgid/20190108211133.32564-2-lyude@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 34 +++++++++++++++-------
+ 1 file changed, 24 insertions(+), 10 deletions(-)
+
+--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+@@ -565,22 +565,36 @@ static void s3_handle_mst(struct drm_dev
+ {
+ struct amdgpu_dm_connector *aconnector;
+ struct drm_connector *connector;
++ struct drm_dp_mst_topology_mgr *mgr;
++ int ret;
++ bool need_hotplug = false;
+
+ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+
+- list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+- aconnector = to_amdgpu_dm_connector(connector);
+- if (aconnector->dc_link->type == dc_connection_mst_branch &&
+- !aconnector->mst_port) {
+-
+- if (suspend)
+- drm_dp_mst_topology_mgr_suspend(&aconnector->mst_mgr);
+- else
+- drm_dp_mst_topology_mgr_resume(&aconnector->mst_mgr);
+- }
++ list_for_each_entry(connector, &dev->mode_config.connector_list,
++ head) {
++ aconnector = to_amdgpu_dm_connector(connector);
++ if (aconnector->dc_link->type != dc_connection_mst_branch ||
++ aconnector->mst_port)
++ continue;
++
++ mgr = &aconnector->mst_mgr;
++
++ if (suspend) {
++ drm_dp_mst_topology_mgr_suspend(mgr);
++ } else {
++ ret = drm_dp_mst_topology_mgr_resume(mgr);
++ if (ret < 0) {
++ drm_dp_mst_topology_mgr_set_mst(mgr, false);
++ need_hotplug = true;
++ }
++ }
+ }
+
+ drm_modeset_unlock(&dev->mode_config.connection_mutex);
++
++ if (need_hotplug)
++ drm_kms_helper_hotplug_event(dev);
+ }
+
+ static int dm_hw_init(void *handle)
--- /dev/null
+From c4a32b266da7bb702e60381ca0c35eaddbc89a6c Mon Sep 17 00:00:00 2001
+From: Yu Zhao <yuzhao@google.com>
+Date: Mon, 7 Jan 2019 15:51:15 -0700
+Subject: drm/amdgpu: validate user GEM object size
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Yu Zhao <yuzhao@google.com>
+
+commit c4a32b266da7bb702e60381ca0c35eaddbc89a6c upstream.
+
+When creating frame buffer, userspace may request to attach to a
+previously allocated GEM object that is smaller than what GPU
+requires. Validation must be done to prevent out-of-bound DMA,
+otherwise it could be exploited to reveal sensitive data.
+
+This fix is not done in a common code path because individual
+driver might have different requirement.
+
+Cc: stable@vger.kernel.org # v4.2+
+Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
+Signed-off-by: Yu Zhao <yuzhao@google.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+@@ -527,6 +527,7 @@ amdgpu_display_user_framebuffer_create(s
+ struct drm_gem_object *obj;
+ struct amdgpu_framebuffer *amdgpu_fb;
+ int ret;
++ int height;
+ struct amdgpu_device *adev = dev->dev_private;
+ int cpp = drm_format_plane_cpp(mode_cmd->pixel_format, 0);
+ int pitch = mode_cmd->pitches[0] / cpp;
+@@ -551,6 +552,13 @@ amdgpu_display_user_framebuffer_create(s
+ return ERR_PTR(-EINVAL);
+ }
+
++ height = ALIGN(mode_cmd->height, 8);
++ if (obj->size < pitch * height) {
++ DRM_DEBUG_KMS("Invalid GEM size: expecting >= %d but got %zu\n",
++ pitch * height, obj->size);
++ return ERR_PTR(-EINVAL);
++ }
++
+ amdgpu_fb = kzalloc(sizeof(*amdgpu_fb), GFP_KERNEL);
+ if (amdgpu_fb == NULL) {
+ drm_gem_object_put_unlocked(obj);
--- /dev/null
+From 89f23b6efef554766177bf51aa754bce14c3e7da Mon Sep 17 00:00:00 2001
+From: Yu Zhao <yuzhao@google.com>
+Date: Mon, 7 Jan 2019 15:51:14 -0700
+Subject: drm/amdgpu: validate user pitch alignment
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Yu Zhao <yuzhao@google.com>
+
+commit 89f23b6efef554766177bf51aa754bce14c3e7da upstream.
+
+Userspace may request pitch alignment that is not supported by GPU.
+Some requests 32, but GPU ignores it and uses default 64 when cpp is
+4. If GEM object is allocated based on the smaller alignment, GPU
+DMA will go out of bound.
+
+Cc: stable@vger.kernel.org # v4.2+
+Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
+Signed-off-by: Yu Zhao <yuzhao@google.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+@@ -527,6 +527,16 @@ amdgpu_display_user_framebuffer_create(s
+ struct drm_gem_object *obj;
+ struct amdgpu_framebuffer *amdgpu_fb;
+ int ret;
++ struct amdgpu_device *adev = dev->dev_private;
++ int cpp = drm_format_plane_cpp(mode_cmd->pixel_format, 0);
++ int pitch = mode_cmd->pitches[0] / cpp;
++
++ pitch = amdgpu_align_pitch(adev, pitch, cpp, false);
++ if (mode_cmd->pitches[0] != pitch) {
++ DRM_DEBUG_KMS("Invalid pitch: expecting %d but got %d\n",
++ pitch, mode_cmd->pitches[0]);
++ return ERR_PTR(-EINVAL);
++ }
+
+ obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[0]);
+ if (obj == NULL) {
--- /dev/null
+From 62d85b3bf9d978ed4b6b2aeef5cf0ccf1423906e Mon Sep 17 00:00:00 2001
+From: Ivan Mironov <mironov.ivan@gmail.com>
+Date: Tue, 8 Jan 2019 12:23:52 +0500
+Subject: drm/fb-helper: Partially bring back workaround for bugs of SDL 1.2
+
+From: Ivan Mironov <mironov.ivan@gmail.com>
+
+commit 62d85b3bf9d978ed4b6b2aeef5cf0ccf1423906e upstream.
+
+SDL 1.2 sets all fields related to the pixel format to zero in some
+cases[1]. Prior to commit db05c48197759 ("drm: fb-helper: Reject all
+pixel format changing requests"), there was an unintentional workaround
+for this that existed for more than a decade. First in device-specific DRM
+drivers, then here in drm_fb_helper.c.
+
+Previous code containing this workaround just ignores pixel format fields
+from userspace code. Not a good thing either, as this way, driver may
+silently use pixel format different from what client actually requested,
+and this in turn will lead to displaying garbage on the screen. I think
+that returning EINVAL to userspace in this particular case is the right
+option, so I decided to left code from problematic commit untouched
+instead of just reverting it entirely.
+
+Here is the steps required to reproduce this problem exactly:
+ 1) Compile fceux[2] with SDL 1.2.15 and without GTK or OpenGL
+ support. SDL should be compiled with fbdev support (which is
+ on by default).
+ 2) Create /etc/fb.modes with following contents (values seems
+ not used, and just required to trigger problematic code in
+ SDL):
+
+ mode "test"
+ geometry 1 1 1 1 1
+ timings 1 1 1 1 1 1 1
+ endmode
+
+ 3) Create ~/.fceux/fceux.cfg with following contents:
+
+ SDL.Hotkeys.Quit = 27
+ SDL.DoubleBuffering = 1
+
+ 4) Ensure that screen resolution is at least 1280x960 (e.g.
+ append "video=Virtual-1:1280x960-32" to the kernel cmdline
+ for qemu/QXL).
+
+ 5) Try to run fceux on VT with some ROM file[3]:
+
+ # ./fceux color_test.nes
+
+[1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c,
+ FB_SetVideoMode()
+[2] http://www.fceux.com
+[3] Example ROM: https://github.com/bokuweb/rustynes/blob/master/roms/color_test.nes
+
+Reported-by: saahriktu <mail@saahriktu.org>
+Suggested-by: saahriktu <mail@saahriktu.org>
+Cc: stable@vger.kernel.org
+Fixes: db05c48197759 ("drm: fb-helper: Reject all pixel format changing requests")
+Signed-off-by: Ivan Mironov <mironov.ivan@gmail.com>
+[danvet: Delete misleading comment.]
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Link: https://patchwork.freedesktop.org/patch/msgid/20190108072353.28078-2-mironov.ivan@gmail.com
+Link: https://patchwork.freedesktop.org/patch/msgid/20190108072353.28078-2-mironov.ivan@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/drm_fb_helper.c | 126 +++++++++++++++++++++++-----------------
+ 1 file changed, 73 insertions(+), 53 deletions(-)
+
+--- a/drivers/gpu/drm/drm_fb_helper.c
++++ b/drivers/gpu/drm/drm_fb_helper.c
+@@ -1621,6 +1621,64 @@ static bool drm_fb_pixel_format_equal(co
+ var_1->transp.msb_right == var_2->transp.msb_right;
+ }
+
++static void drm_fb_helper_fill_pixel_fmt(struct fb_var_screeninfo *var,
++ u8 depth)
++{
++ switch (depth) {
++ case 8:
++ var->red.offset = 0;
++ var->green.offset = 0;
++ var->blue.offset = 0;
++ var->red.length = 8; /* 8bit DAC */
++ var->green.length = 8;
++ var->blue.length = 8;
++ var->transp.offset = 0;
++ var->transp.length = 0;
++ break;
++ case 15:
++ var->red.offset = 10;
++ var->green.offset = 5;
++ var->blue.offset = 0;
++ var->red.length = 5;
++ var->green.length = 5;
++ var->blue.length = 5;
++ var->transp.offset = 15;
++ var->transp.length = 1;
++ break;
++ case 16:
++ var->red.offset = 11;
++ var->green.offset = 5;
++ var->blue.offset = 0;
++ var->red.length = 5;
++ var->green.length = 6;
++ var->blue.length = 5;
++ var->transp.offset = 0;
++ break;
++ case 24:
++ var->red.offset = 16;
++ var->green.offset = 8;
++ var->blue.offset = 0;
++ var->red.length = 8;
++ var->green.length = 8;
++ var->blue.length = 8;
++ var->transp.offset = 0;
++ var->transp.length = 0;
++ break;
++ case 32:
++ var->red.offset = 16;
++ var->green.offset = 8;
++ var->blue.offset = 0;
++ var->red.length = 8;
++ var->green.length = 8;
++ var->blue.length = 8;
++ var->transp.offset = 24;
++ var->transp.length = 8;
++ break;
++ default:
++ break;
++ }
++}
++
+ /**
+ * drm_fb_helper_check_var - implementation for &fb_ops.fb_check_var
+ * @var: screeninfo to check
+@@ -1651,6 +1709,20 @@ int drm_fb_helper_check_var(struct fb_va
+ }
+
+ /*
++ * Workaround for SDL 1.2, which is known to be setting all pixel format
++ * fields values to zero in some cases. We treat this situation as a
++ * kind of "use some reasonable autodetected values".
++ */
++ if (!var->red.offset && !var->green.offset &&
++ !var->blue.offset && !var->transp.offset &&
++ !var->red.length && !var->green.length &&
++ !var->blue.length && !var->transp.length &&
++ !var->red.msb_right && !var->green.msb_right &&
++ !var->blue.msb_right && !var->transp.msb_right) {
++ drm_fb_helper_fill_pixel_fmt(var, fb->format->depth);
++ }
++
++ /*
+ * drm fbdev emulation doesn't support changing the pixel format at all,
+ * so reject all pixel format changing requests.
+ */
+@@ -1961,59 +2033,7 @@ void drm_fb_helper_fill_var(struct fb_in
+ info->var.yoffset = 0;
+ info->var.activate = FB_ACTIVATE_NOW;
+
+- switch (fb->format->depth) {
+- case 8:
+- info->var.red.offset = 0;
+- info->var.green.offset = 0;
+- info->var.blue.offset = 0;
+- info->var.red.length = 8; /* 8bit DAC */
+- info->var.green.length = 8;
+- info->var.blue.length = 8;
+- info->var.transp.offset = 0;
+- info->var.transp.length = 0;
+- break;
+- case 15:
+- info->var.red.offset = 10;
+- info->var.green.offset = 5;
+- info->var.blue.offset = 0;
+- info->var.red.length = 5;
+- info->var.green.length = 5;
+- info->var.blue.length = 5;
+- info->var.transp.offset = 15;
+- info->var.transp.length = 1;
+- break;
+- case 16:
+- info->var.red.offset = 11;
+- info->var.green.offset = 5;
+- info->var.blue.offset = 0;
+- info->var.red.length = 5;
+- info->var.green.length = 6;
+- info->var.blue.length = 5;
+- info->var.transp.offset = 0;
+- break;
+- case 24:
+- info->var.red.offset = 16;
+- info->var.green.offset = 8;
+- info->var.blue.offset = 0;
+- info->var.red.length = 8;
+- info->var.green.length = 8;
+- info->var.blue.length = 8;
+- info->var.transp.offset = 0;
+- info->var.transp.length = 0;
+- break;
+- case 32:
+- info->var.red.offset = 16;
+- info->var.green.offset = 8;
+- info->var.blue.offset = 0;
+- info->var.red.length = 8;
+- info->var.green.length = 8;
+- info->var.blue.length = 8;
+- info->var.transp.offset = 24;
+- info->var.transp.length = 8;
+- break;
+- default:
+- break;
+- }
++ drm_fb_helper_fill_pixel_fmt(&info->var, fb->format->depth);
+
+ info->var.xres = fb_width;
+ info->var.yres = fb_height;
--- /dev/null
+From 4be9bd10e22dfc7fc101c5cf5969ef2d3a042d8a Mon Sep 17 00:00:00 2001
+From: Neil Armstrong <narmstrong@baylibre.com>
+Date: Fri, 28 Sep 2018 14:05:55 +0200
+Subject: drm/fb_helper: Allow leaking fbdev smem_start
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Neil Armstrong <narmstrong@baylibre.com>
+
+commit 4be9bd10e22dfc7fc101c5cf5969ef2d3a042d8a upstream.
+
+Since "drm/fb: Stop leaking physical address", the default behaviour of
+the DRM fbdev emulation is to set the smem_base to 0 and pass the new
+FBINFO_HIDE_SMEM_START flag.
+
+The main reason is to avoid leaking physical addresse to user-space, and
+it follows a general move over the kernel code to avoid user-space to
+manipulate physical addresses and then use some other mechanisms like
+dma-buf to transfer physical buffer handles over multiple subsystems.
+
+But, a lot of devices depends on closed sources binaries to enable
+OpenGL hardware acceleration that uses this smem_start value to
+pass physical addresses to out-of-tree modules in order to render
+into these physical adresses. These should use dma-buf buffers allocated
+from the DRM display device instead and stop relying on fbdev overallocation
+to gather DMA memory (some HW vendors delivers GBM and Wayland capable
+binaries, but older unsupported devices won't have these new binaries
+and are doomed until an Open Source solution like Lima finalizes).
+
+Since these devices heavily depends on this kind of software and because
+the smem_start population was available for years, it's a breakage to
+stop leaking smem_start without any alternative solutions.
+
+This patch adds a Kconfig depending on the EXPERT config and an unsafe
+kernel module parameter tainting the kernel when enabled.
+
+A clear comment and Kconfig help text was added to clarify why and when
+this patch should be reverted, but in the meantime it's a necessary
+feature to keep.
+
+Cc: Dave Airlie <airlied@gmail.com>
+Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
+Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Cc: Noralf Trønnes <noralf@tronnes.org>
+Cc: Maxime Ripard <maxime.ripard@bootlin.com>
+Cc: Eric Anholt <eric@anholt.net>
+Cc: Lucas Stach <l.stach@pengutronix.de>
+Cc: Rob Clark <robdclark@gmail.com>
+Cc: Ben Skeggs <skeggsb@gmail.com>
+Cc: Christian König <christian.koenig@amd.com>
+Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
+Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
+Tested-by: Maxime Ripard <maxime.ripard@bootlin.com>
+Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Acked-by: Dave Airlie <airlied@gmail.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/1538136355-15383-1-git-send-email-narmstrong@baylibre.com
+Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+
+---
+ drivers/gpu/drm/Kconfig | 20 ++++++++++++++++++++
+ drivers/gpu/drm/drm_fb_helper.c | 25 +++++++++++++++++++++++++
+ 2 files changed, 45 insertions(+)
+
+--- a/drivers/gpu/drm/Kconfig
++++ b/drivers/gpu/drm/Kconfig
+@@ -110,6 +110,26 @@ config DRM_FBDEV_OVERALLOC
+ is 100. Typical values for double buffering will be 200,
+ triple buffering 300.
+
++config DRM_FBDEV_LEAK_PHYS_SMEM
++ bool "Shamelessly allow leaking of fbdev physical address (DANGEROUS)"
++ depends on DRM_FBDEV_EMULATION && EXPERT
++ default n
++ help
++ In order to keep user-space compatibility, we want in certain
++ use-cases to keep leaking the fbdev physical address to the
++ user-space program handling the fbdev buffer.
++ This affects, not only, Amlogic, Allwinner or Rockchip devices
++ with ARM Mali GPUs using an userspace Blob.
++ This option is not supported by upstream developers and should be
++ removed as soon as possible and be considered as a broken and
++ legacy behaviour from a modern fbdev device driver.
++
++ Please send any bug reports when using this to your proprietary
++ software vendor that requires this.
++
++ If in doubt, say "N" or spread the word to your closed source
++ library vendor.
++
+ config DRM_LOAD_EDID_FIRMWARE
+ bool "Allow to specify an EDID data set instead of probing for it"
+ depends on DRM
+--- a/drivers/gpu/drm/drm_fb_helper.c
++++ b/drivers/gpu/drm/drm_fb_helper.c
+@@ -56,6 +56,25 @@ MODULE_PARM_DESC(drm_fbdev_overalloc,
+ "Overallocation of the fbdev buffer (%) [default="
+ __MODULE_STRING(CONFIG_DRM_FBDEV_OVERALLOC) "]");
+
++/*
++ * In order to keep user-space compatibility, we want in certain use-cases
++ * to keep leaking the fbdev physical address to the user-space program
++ * handling the fbdev buffer.
++ * This is a bad habit essentially kept into closed source opengl driver
++ * that should really be moved into open-source upstream projects instead
++ * of using legacy physical addresses in user space to communicate with
++ * other out-of-tree kernel modules.
++ *
++ * This module_param *should* be removed as soon as possible and be
++ * considered as a broken and legacy behaviour from a modern fbdev device.
++ */
++#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM)
++static bool drm_leak_fbdev_smem = false;
++module_param_unsafe(drm_leak_fbdev_smem, bool, 0600);
++MODULE_PARM_DESC(fbdev_emulation,
++ "Allow unsafe leaking fbdev physical smem address [default=false]");
++#endif
++
+ static LIST_HEAD(kernel_fb_helper_list);
+ static DEFINE_MUTEX(kernel_fb_helper_lock);
+
+@@ -3041,6 +3060,12 @@ int drm_fb_helper_generic_probe(struct d
+ fbi->screen_size = fb->height * fb->pitches[0];
+ fbi->fix.smem_len = fbi->screen_size;
+ fbi->screen_buffer = buffer->vaddr;
++ /* Shamelessly leak the physical address to user-space */
++#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM)
++ if (drm_leak_fbdev_smem && fbi->fix.smem_start == 0)
++ fbi->fix.smem_start =
++ page_to_phys(virt_to_page(fbi->screen_buffer));
++#endif
+ strcpy(fbi->fix.id, "DRM emulated");
+
+ drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->format->depth);
--- /dev/null
+From 280d479b310298dfeb1d6f9a1617eca37beb6ce4 Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Sat, 22 Dec 2018 03:06:23 +0000
+Subject: drm/i915: Unwind failure on pinning the gen7 ppgtt
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit 280d479b310298dfeb1d6f9a1617eca37beb6ce4 upstream.
+
+If we fail to pin the ggtt vma slot for the ppgtt page tables, we need
+to unwind the locals before reporting the error. Or else on subsequent
+attempts to bind the page tables into the ggtt, we will already believe
+that the vma has been pinned and continue on blithely. If something else
+should happen to be at that location, choas ensues.
+
+Fixes: a2bbf7148342 ("drm/i915/gtt: Only keep gen6 page directories pinned while active")
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
+Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
+Cc: Matthew Auld <matthew.william.auld@gmail.com>
+Cc: <stable@vger.kernel.org> # v4.19+
+Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20181222030623.21710-1-chris@chris-wilson.co.uk
+(cherry picked from commit d4de753526f4d99f541f1b6ed1d963005c09700c)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_gem_gtt.c | 15 ++++++++++++---
+ 1 file changed, 12 insertions(+), 3 deletions(-)
+
+--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
++++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
+@@ -2128,6 +2128,7 @@ static struct i915_vma *pd_vma_create(st
+ int gen6_ppgtt_pin(struct i915_hw_ppgtt *base)
+ {
+ struct gen6_hw_ppgtt *ppgtt = to_gen6_ppgtt(base);
++ int err;
+
+ /*
+ * Workaround the limited maximum vma->pin_count and the aliasing_ppgtt
+@@ -2143,9 +2144,17 @@ int gen6_ppgtt_pin(struct i915_hw_ppgtt
+ * allocator works in address space sizes, so it's multiplied by page
+ * size. We allocate at the top of the GTT to avoid fragmentation.
+ */
+- return i915_vma_pin(ppgtt->vma,
+- 0, GEN6_PD_ALIGN,
+- PIN_GLOBAL | PIN_HIGH);
++ err = i915_vma_pin(ppgtt->vma,
++ 0, GEN6_PD_ALIGN,
++ PIN_GLOBAL | PIN_HIGH);
++ if (err)
++ goto unpin;
++
++ return 0;
++
++unpin:
++ ppgtt->pin_count = 0;
++ return err;
+ }
+
+ void gen6_ppgtt_unpin(struct i915_hw_ppgtt *base)
--- /dev/null
+From e86807862e6880809f191c4cea7f88a489f0ed34 Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o <tytso@mit.edu>
+Date: Sun, 30 Dec 2018 23:20:39 -0500
+Subject: ext4: avoid kernel warning when writing the superblock to a dead device
+
+From: Theodore Ts'o <tytso@mit.edu>
+
+commit e86807862e6880809f191c4cea7f88a489f0ed34 upstream.
+
+The xfstests generic/475 test switches the underlying device with
+dm-error while running a stress test. This results in a large number
+of file system errors, and since we can't lock the buffer head when
+marking the superblock dirty in the ext4_grp_locked_error() case, it's
+possible the superblock to be !buffer_uptodate() without
+buffer_write_io_error() being true.
+
+We need to set buffer_uptodate() before we call mark_buffer_dirty() or
+this will trigger a WARN_ON. It's safe to do this since the
+superblock must have been properly read into memory or the mount would
+have been successful. So if buffer_uptodate() is not set, we can
+safely assume that this happened due to a failed attempt to write the
+superblock.
+
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/super.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/ext4/super.c
++++ b/fs/ext4/super.c
+@@ -4904,7 +4904,7 @@ static int ext4_commit_super(struct supe
+ ext4_superblock_csum_set(sb);
+ if (sync)
+ lock_buffer(sbh);
+- if (buffer_write_io_error(sbh)) {
++ if (buffer_write_io_error(sbh) || !buffer_uptodate(sbh)) {
+ /*
+ * Oh, dear. A previous attempt to write the
+ * superblock failed. This could happen because the
--- /dev/null
+From 2b08b1f12cd664dc7d5c84ead9ff25ae97ad5491 Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o <tytso@mit.edu>
+Date: Tue, 25 Dec 2018 00:56:33 -0500
+Subject: ext4: fix a potential fiemap/page fault deadlock w/ inline_data
+
+From: Theodore Ts'o <tytso@mit.edu>
+
+commit 2b08b1f12cd664dc7d5c84ead9ff25ae97ad5491 upstream.
+
+The ext4_inline_data_fiemap() function calls fiemap_fill_next_extent()
+while still holding the xattr semaphore. This is not necessary and it
+triggers a circular lockdep warning. This is because
+fiemap_fill_next_extent() could trigger a page fault when it writes
+into page which triggers a page fault. If that page is mmaped from
+the inline file in question, this could very well result in a
+deadlock.
+
+This problem can be reproduced using generic/519 with a file system
+configuration which has the inline_data feature enabled.
+
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/inline.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/fs/ext4/inline.c
++++ b/fs/ext4/inline.c
+@@ -1890,12 +1890,12 @@ int ext4_inline_data_fiemap(struct inode
+ physical += (char *)ext4_raw_inode(&iloc) - iloc.bh->b_data;
+ physical += offsetof(struct ext4_inode, i_block);
+
+- if (physical)
+- error = fiemap_fill_next_extent(fieinfo, start, physical,
+- inline_len, flags);
+ brelse(iloc.bh);
+ out:
+ up_read(&EXT4_I(inode)->xattr_sem);
++ if (physical)
++ error = fiemap_fill_next_extent(fieinfo, start, physical,
++ inline_len, flags);
+ return (error < 0 ? error : 0);
+ }
+
--- /dev/null
+From 191ce17876c9367819c4b0a25b503c0f6d9054d8 Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o <tytso@mit.edu>
+Date: Mon, 31 Dec 2018 22:34:31 -0500
+Subject: ext4: fix special inode number checks in __ext4_iget()
+
+From: Theodore Ts'o <tytso@mit.edu>
+
+commit 191ce17876c9367819c4b0a25b503c0f6d9054d8 upstream.
+
+The check for special (reserved) inode number checks in __ext4_iget()
+was broken by commit 8a363970d1dc: ("ext4: avoid declaring fs
+inconsistent due to invalid file handles"). This was caused by a
+botched reversal of the sense of the flag now known as
+EXT4_IGET_SPECIAL (when it was previously named EXT4_IGET_NORMAL).
+Fix the logic appropriately.
+
+Fixes: 8a363970d1dc ("ext4: avoid declaring fs inconsistent...")
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/inode.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/ext4/inode.c
++++ b/fs/ext4/inode.c
+@@ -4803,7 +4803,7 @@ struct inode *__ext4_iget(struct super_b
+ gid_t i_gid;
+ projid_t i_projid;
+
+- if (((flags & EXT4_IGET_NORMAL) &&
++ if ((!(flags & EXT4_IGET_SPECIAL) &&
+ (ino < EXT4_FIRST_INO(sb) && ino != EXT4_ROOT_INO)) ||
+ (ino < EXT4_ROOT_INO) ||
+ (ino > le32_to_cpu(EXT4_SB(sb)->s_es->s_inodes_count))) {
--- /dev/null
+From 812c0cab2c0dfad977605dbadf9148490ca5d93f Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o <tytso@mit.edu>
+Date: Mon, 24 Dec 2018 20:27:08 -0500
+Subject: ext4: make sure enough credits are reserved for dioread_nolock writes
+
+From: Theodore Ts'o <tytso@mit.edu>
+
+commit 812c0cab2c0dfad977605dbadf9148490ca5d93f upstream.
+
+There are enough credits reserved for most dioread_nolock writes;
+however, if the extent tree is sufficiently deep, and/or quota is
+enabled, the code was not allowing for all eventualities when
+reserving journal credits for the unwritten extent conversion.
+
+This problem can be seen using xfstests ext4/034:
+
+ WARNING: CPU: 1 PID: 257 at fs/ext4/ext4_jbd2.c:271 __ext4_handle_dirty_metadata+0x10c/0x180
+ Workqueue: ext4-rsv-conversion ext4_end_io_rsv_work
+ RIP: 0010:__ext4_handle_dirty_metadata+0x10c/0x180
+ ...
+ EXT4-fs: ext4_free_blocks:4938: aborting transaction: error 28 in __ext4_handle_dirty_metadata
+ EXT4: jbd2_journal_dirty_metadata failed: handle type 11 started at line 4921, credits 4/0, errcode -28
+ EXT4-fs error (device dm-1) in ext4_free_blocks:4950: error 28
+
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/inode.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/fs/ext4/inode.c
++++ b/fs/ext4/inode.c
+@@ -2748,7 +2748,8 @@ static int ext4_writepages(struct addres
+ * We may need to convert up to one extent per block in
+ * the page and we may dirty the inode.
+ */
+- rsv_blocks = 1 + (PAGE_SIZE >> inode->i_blkbits);
++ rsv_blocks = 1 + ext4_chunk_trans_blocks(inode,
++ PAGE_SIZE >> inode->i_blkbits);
+ }
+
+ /*
--- /dev/null
+From 95cb67138746451cc84cf8e516e14989746e93b0 Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o <tytso@mit.edu>
+Date: Mon, 31 Dec 2018 00:11:07 -0500
+Subject: ext4: track writeback errors using the generic tracking infrastructure
+
+From: Theodore Ts'o <tytso@mit.edu>
+
+commit 95cb67138746451cc84cf8e516e14989746e93b0 upstream.
+
+We already using mapping_set_error() in fs/ext4/page_io.c, so all we
+need to do is to use file_check_and_advance_wb_err() when handling
+fsync() requests in ext4_sync_file().
+
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/fsync.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/fs/ext4/fsync.c
++++ b/fs/ext4/fsync.c
+@@ -164,6 +164,9 @@ int ext4_sync_file(struct file *file, lo
+ ret = err;
+ }
+ out:
++ err = file_check_and_advance_wb_err(file);
++ if (ret == 0)
++ ret = err;
+ trace_ext4_sync_file_exit(inode, ret);
+ return ret;
+ }
--- /dev/null
+From ad211f3e94b314a910d4af03178a0b52a7d1ee0a Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o <tytso@mit.edu>
+Date: Mon, 31 Dec 2018 00:10:48 -0500
+Subject: ext4: use ext4_write_inode() when fsyncing w/o a journal
+
+From: Theodore Ts'o <tytso@mit.edu>
+
+commit ad211f3e94b314a910d4af03178a0b52a7d1ee0a upstream.
+
+In no-journal mode, we previously used __generic_file_fsync() in
+no-journal mode. This triggers a lockdep warning, and in addition,
+it's not safe to depend on the inode writeback mechanism in the case
+ext4. We can solve both problems by calling ext4_write_inode()
+directly.
+
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/fsync.c | 13 +++++++++----
+ 1 file changed, 9 insertions(+), 4 deletions(-)
+
+--- a/fs/ext4/fsync.c
++++ b/fs/ext4/fsync.c
+@@ -116,8 +116,16 @@ int ext4_sync_file(struct file *file, lo
+ goto out;
+ }
+
++ ret = file_write_and_wait_range(file, start, end);
++ if (ret)
++ return ret;
++
+ if (!journal) {
+- ret = __generic_file_fsync(file, start, end, datasync);
++ struct writeback_control wbc = {
++ .sync_mode = WB_SYNC_ALL
++ };
++
++ ret = ext4_write_inode(inode, &wbc);
+ if (!ret)
+ ret = ext4_sync_parent(inode);
+ if (test_opt(inode->i_sb, BARRIER))
+@@ -125,9 +133,6 @@ int ext4_sync_file(struct file *file, lo
+ goto out;
+ }
+
+- ret = file_write_and_wait_range(file, start, end);
+- if (ret)
+- return ret;
+ /*
+ * data=writeback,ordered:
+ * The caller's filemap_fdatawrite()/wait will sync the data.
--- /dev/null
+From 3f7bb2ec20ce07c02b2002349d256c91a463fcc5 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <marc.zyngier@arm.com>
+Date: Tue, 13 Nov 2018 22:57:34 +0000
+Subject: PCI: dwc: Move interrupt acking into the proper callback
+
+From: Marc Zyngier <marc.zyngier@arm.com>
+
+commit 3f7bb2ec20ce07c02b2002349d256c91a463fcc5 upstream.
+
+The write to the status register is really an ACK for the HW,
+and should be treated as such by the driver. Let's move it to the
+irq_ack() callback, which will prevent people from moving it around
+in order to paper over other bugs.
+
+Fixes: 8c934095fa2f ("PCI: dwc: Clear MSI interrupt status after it is handled,
+not before")
+Fixes: 7c5925afbc58 ("PCI: dwc: Move MSI IRQs allocation to IRQ domains
+hierarchical API")
+Link: https://lore.kernel.org/linux-pci/20181113225734.8026-1-marc.zyngier@arm.com/
+Reported-by: Trent Piepho <tpiepho@impinj.com>
+Tested-by: Niklas Cassel <niklas.cassel@linaro.org>
+Tested-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
+Tested-by: Stanimir Varbanov <svarbanov@mm-sol.com>
+Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
+[lorenzo.pieralisi@arm.com: updated commit log]
+Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/controller/dwc/pcie-designware-host.c | 13 +++++++------
+ 1 file changed, 7 insertions(+), 6 deletions(-)
+
+--- a/drivers/pci/controller/dwc/pcie-designware-host.c
++++ b/drivers/pci/controller/dwc/pcie-designware-host.c
+@@ -99,9 +99,6 @@ irqreturn_t dw_handle_msi_irq(struct pci
+ (i * MAX_MSI_IRQS_PER_CTRL) +
+ pos);
+ generic_handle_irq(irq);
+- dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_STATUS +
+- (i * MSI_REG_CTRL_BLOCK_SIZE),
+- 4, 1 << pos);
+ pos++;
+ }
+ }
+@@ -200,14 +197,18 @@ static void dw_pci_bottom_unmask(struct
+
+ static void dw_pci_bottom_ack(struct irq_data *d)
+ {
+- struct msi_desc *msi = irq_data_get_msi_desc(d);
+- struct pcie_port *pp;
++ struct pcie_port *pp = irq_data_get_irq_chip_data(d);
++ unsigned int res, bit, ctrl;
+ unsigned long flags;
+
+- pp = msi_desc_to_pci_sysdata(msi);
++ ctrl = d->hwirq / MAX_MSI_IRQS_PER_CTRL;
++ res = ctrl * MSI_REG_CTRL_BLOCK_SIZE;
++ bit = d->hwirq % MAX_MSI_IRQS_PER_CTRL;
+
+ raw_spin_lock_irqsave(&pp->lock, flags);
+
++ dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_STATUS + res, 4, 1 << bit);
++
+ if (pp->ops->msi_irq_ack)
+ pp->ops->msi_irq_ack(d->hwirq, pp);
+
--- /dev/null
+From fce5423e4f431c71933d6c1f850b540a314aa6ee Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <marc.zyngier@arm.com>
+Date: Tue, 13 Nov 2018 22:57:33 +0000
+Subject: PCI: dwc: Take lock when ACKing an interrupt
+
+From: Marc Zyngier <marc.zyngier@arm.com>
+
+commit fce5423e4f431c71933d6c1f850b540a314aa6ee upstream.
+
+Bizarrely, there is no lock taken in the irq_ack() helper. This
+puts the ACK callback provided by a specific platform in a awkward
+situation where there is no synchronization that would be expected
+on other callback.
+
+Introduce the required lock, giving some level of uniformity among
+callbacks.
+
+Fixes: 7c5925afbc58 ("PCI: dwc: Move MSI IRQs allocation to IRQ domains
+hierarchical API")
+Link: https://lore.kernel.org/linux-pci/20181113225734.8026-1-marc.zyngier@arm.com/
+Tested-by: Niklas Cassel <niklas.cassel@linaro.org>
+Tested-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
+Tested-by: Stanimir Varbanov <svarbanov@mm-sol.com>
+Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
+[lorenzo.pieralisi@arm.com: updated commit log]
+Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/controller/dwc/pcie-designware-host.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/pci/controller/dwc/pcie-designware-host.c
++++ b/drivers/pci/controller/dwc/pcie-designware-host.c
+@@ -202,11 +202,16 @@ static void dw_pci_bottom_ack(struct irq
+ {
+ struct msi_desc *msi = irq_data_get_msi_desc(d);
+ struct pcie_port *pp;
++ unsigned long flags;
+
+ pp = msi_desc_to_pci_sysdata(msi);
+
++ raw_spin_lock_irqsave(&pp->lock, flags);
++
+ if (pp->ops->msi_irq_ack)
+ pp->ops->msi_irq_ack(d->hwirq, pp);
++
++ raw_spin_unlock_irqrestore(&pp->lock, flags);
+ }
+
+ static struct irq_chip dw_pci_msi_bottom_irq_chip = {
--- /dev/null
+From 830920e065e90db318a0da98bf13a02b641eae7f Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <marc.zyngier@arm.com>
+Date: Tue, 13 Nov 2018 22:57:32 +0000
+Subject: PCI: dwc: Use interrupt masking instead of disabling
+
+From: Marc Zyngier <marc.zyngier@arm.com>
+
+commit 830920e065e90db318a0da98bf13a02b641eae7f upstream.
+
+The dwc driver is showing an interesting level of brokeness, as it
+insists on using the enable/disable set of registers to mask/unmask
+MSIs, meaning that an MSIs being generated while the interrupt is in
+that "disabled" state will simply be lost.
+
+Let's move to the mask/unmask set of registers, which offers the
+expected semantics.
+
+Fixes: 7c5925afbc58 ("PCI: dwc: Move MSI IRQs allocation to IRQ domains
+hierarchical API")
+Link: https://lore.kernel.org/linux-pci/20181113225734.8026-1-marc.zyngier@arm.com/
+Tested-by: Niklas Cassel <niklas.cassel@linaro.org>
+Tested-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
+Tested-by: Stanimir Varbanov <svarbanov@mm-sol.com>
+Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
+[lorenzo.pieralisi@arm.com: updated commit log]
+Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/controller/dwc/pcie-designware-host.c | 19 ++++++++++++-------
+ 1 file changed, 12 insertions(+), 7 deletions(-)
+
+--- a/drivers/pci/controller/dwc/pcie-designware-host.c
++++ b/drivers/pci/controller/dwc/pcie-designware-host.c
+@@ -168,8 +168,8 @@ static void dw_pci_bottom_mask(struct ir
+ bit = data->hwirq % MAX_MSI_IRQS_PER_CTRL;
+
+ pp->irq_status[ctrl] &= ~(1 << bit);
+- dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4,
+- pp->irq_status[ctrl]);
++ dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_MASK + res, 4,
++ ~pp->irq_status[ctrl]);
+ }
+
+ raw_spin_unlock_irqrestore(&pp->lock, flags);
+@@ -191,8 +191,8 @@ static void dw_pci_bottom_unmask(struct
+ bit = data->hwirq % MAX_MSI_IRQS_PER_CTRL;
+
+ pp->irq_status[ctrl] |= 1 << bit;
+- dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4,
+- pp->irq_status[ctrl]);
++ dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_MASK + res, 4,
++ ~pp->irq_status[ctrl]);
+ }
+
+ raw_spin_unlock_irqrestore(&pp->lock, flags);
+@@ -658,10 +658,15 @@ void dw_pcie_setup_rc(struct pcie_port *
+ num_ctrls = pp->num_vectors / MAX_MSI_IRQS_PER_CTRL;
+
+ /* Initialize IRQ Status array */
+- for (ctrl = 0; ctrl < num_ctrls; ctrl++)
+- dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE +
++ for (ctrl = 0; ctrl < num_ctrls; ctrl++) {
++ dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_MASK +
+ (ctrl * MSI_REG_CTRL_BLOCK_SIZE),
+- 4, &pp->irq_status[ctrl]);
++ 4, ~0);
++ dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE +
++ (ctrl * MSI_REG_CTRL_BLOCK_SIZE),
++ 4, ~0);
++ pp->irq_status[ctrl] = 0;
++ }
+
+ /* Setup RC BARs */
+ dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, 0x00000004);
--- /dev/null
+From 85f5a4d666fd9be73856ed16bb36c5af5b406b29 Mon Sep 17 00:00:00 2001
+From: Ilya Dryomov <idryomov@gmail.com>
+Date: Tue, 8 Jan 2019 19:47:38 +0100
+Subject: rbd: don't return 0 on unmap if RBD_DEV_FLAG_REMOVING is set
+
+From: Ilya Dryomov <idryomov@gmail.com>
+
+commit 85f5a4d666fd9be73856ed16bb36c5af5b406b29 upstream.
+
+There is a window between when RBD_DEV_FLAG_REMOVING is set and when
+the device is removed from rbd_dev_list. During this window, we set
+"already" and return 0.
+
+Returning 0 from write(2) can confuse userspace tools because
+0 indicates that nothing was written. In particular, "rbd unmap"
+will retry the write multiple times a second:
+
+ 10:28:05.463299 write(4, "0", 1) = 0
+ 10:28:05.463509 write(4, "0", 1) = 0
+ 10:28:05.463720 write(4, "0", 1) = 0
+ 10:28:05.463942 write(4, "0", 1) = 0
+ 10:28:05.464155 write(4, "0", 1) = 0
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Tested-by: Dongsheng Yang <dongsheng.yang@easystack.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/block/rbd.c | 9 ++++-----
+ 1 file changed, 4 insertions(+), 5 deletions(-)
+
+--- a/drivers/block/rbd.c
++++ b/drivers/block/rbd.c
+@@ -5982,7 +5982,6 @@ static ssize_t do_rbd_remove(struct bus_
+ struct list_head *tmp;
+ int dev_id;
+ char opt_buf[6];
+- bool already = false;
+ bool force = false;
+ int ret;
+
+@@ -6015,13 +6014,13 @@ static ssize_t do_rbd_remove(struct bus_
+ spin_lock_irq(&rbd_dev->lock);
+ if (rbd_dev->open_count && !force)
+ ret = -EBUSY;
+- else
+- already = test_and_set_bit(RBD_DEV_FLAG_REMOVING,
+- &rbd_dev->flags);
++ else if (test_and_set_bit(RBD_DEV_FLAG_REMOVING,
++ &rbd_dev->flags))
++ ret = -EINPROGRESS;
+ spin_unlock_irq(&rbd_dev->lock);
+ }
+ spin_unlock(&rbd_dev_list_lock);
+- if (ret < 0 || already)
++ if (ret)
+ return ret;
+
+ if (force) {
i2c-dev-prevent-adapter-retries-and-timeout-being-set-as-minus-value.patch
mtd-rawnand-qcom-fix-memory-corruption-that-causes-panic.patch
vfio-type1-fix-unmap-overflow-off-by-one.patch
+drm-amdgpu-add-new-vegam-pci-id.patch
+pci-dwc-use-interrupt-masking-instead-of-disabling.patch
+pci-dwc-take-lock-when-acking-an-interrupt.patch
+pci-dwc-move-interrupt-acking-into-the-proper-callback.patch
+drm-amd-display-fix-mst-dp_blank-reg_wait-timeout.patch
+drm-fb_helper-allow-leaking-fbdev-smem_start.patch
+drm-fb-helper-partially-bring-back-workaround-for-bugs-of-sdl-1.2.patch
+drm-i915-unwind-failure-on-pinning-the-gen7-ppgtt.patch
+drm-amdgpu-validate-user-pitch-alignment.patch
+drm-amdgpu-validate-user-gem-object-size.patch
+drm-amdgpu-don-t-ignore-rc-from-drm_dp_mst_topology_mgr_resume.patch
+drm-amdgpu-don-t-fail-resume-process-if-resuming-atomic-state-fails.patch
+rbd-don-t-return-0-on-unmap-if-rbd_dev_flag_removing-is-set.patch
+ext4-make-sure-enough-credits-are-reserved-for-dioread_nolock-writes.patch
+ext4-fix-a-potential-fiemap-page-fault-deadlock-w-inline_data.patch
+ext4-avoid-kernel-warning-when-writing-the-superblock-to-a-dead-device.patch
+ext4-use-ext4_write_inode-when-fsyncing-w-o-a-journal.patch
+ext4-track-writeback-errors-using-the-generic-tracking-infrastructure.patch
+ext4-fix-special-inode-number-checks-in-__ext4_iget.patch
mm-page_mapped-don-t-assume-compound-page-is-huge-or-thp.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
