--- /dev/null
+From 1a10e5244778169a5a53a527d7830cf0438132a1 Mon Sep 17 00:00:00 2001
+From: Stylon Wang <stylon.wang@amd.com>
+Date: Tue, 5 Jan 2021 11:29:34 +0800
+Subject: drm/amd/display: Revert "Fix EDID parsing after resume from suspend"
+
+From: Stylon Wang <stylon.wang@amd.com>
+
+commit 1a10e5244778169a5a53a527d7830cf0438132a1 upstream.
+
+This reverts commit b24bdc37d03a0478189e20a50286092840f414fa.
+It caused memory leak after S3 on 4K HDMI displays.
+
+Signed-off-by: Stylon Wang <stylon.wang@amd.com>
+Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
+Acked-by: Anson Jacob <Anson.Jacob@amd.com>
+Tested-by: Daniel Wheeler <daniel.wheeler@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/display/amdgpu_dm/amdgpu_dm.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+@@ -2278,8 +2278,6 @@ void amdgpu_dm_update_connector_after_de
+
+ drm_connector_update_edid_property(connector,
+ aconnector->edid);
+- drm_add_edid_modes(connector, aconnector->edid);
+-
+ if (aconnector->dc_link->aux_mode)
+ drm_dp_cec_set_edid(&aconnector->dm_dp_aux.aux,
+ aconnector->edid);
--- /dev/null
+From 83404d581471775f37f85e5261ec0d09407d8bed Mon Sep 17 00:00:00 2001
+From: Imre Deak <imre.deak@intel.com>
+Date: Mon, 25 Jan 2021 19:36:35 +0200
+Subject: drm/dp/mst: Export drm_dp_get_vc_payload_bw()
+
+From: Imre Deak <imre.deak@intel.com>
+
+commit 83404d581471775f37f85e5261ec0d09407d8bed upstream.
+
+This function will be needed by the next patch where the driver
+calculates the BW based on driver specific parameters, so export it.
+
+At the same time sanitize the function params, passing the more natural
+link rate instead of the encoding of the same rate.
+
+v2:
+- Fix function documentation. (Lyude)
+
+Cc: Lyude Paul <lyude@redhat.com>
+Cc: Ville Syrjala <ville.syrjala@intel.com>
+Cc: <stable@vger.kernel.org>
+Cc: dri-devel@lists.freedesktop.org
+Signed-off-by: Imre Deak <imre.deak@intel.com>
+Reviewed-by: Lyude Paul <lyude@redhat.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210125173636.1733812-1-imre.deak@intel.com
+(cherry picked from commit a321fc2b4e60fc1b39517d26c8104351636a6062)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/drm_dp_mst_topology.c | 24 ++++++++++++++++++------
+ include/drm/drm_dp_mst_helper.h | 1 +
+ 2 files changed, 19 insertions(+), 6 deletions(-)
+
+--- a/drivers/gpu/drm/drm_dp_mst_topology.c
++++ b/drivers/gpu/drm/drm_dp_mst_topology.c
+@@ -3629,14 +3629,26 @@ static int drm_dp_send_up_ack_reply(stru
+ return 0;
+ }
+
+-static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8 dp_link_count)
++/**
++ * drm_dp_get_vc_payload_bw - get the VC payload BW for an MST link
++ * @link_rate: link rate in 10kbits/s units
++ * @link_lane_count: lane count
++ *
++ * Calculate the total bandwidth of a MultiStream Transport link. The returned
++ * value is in units of PBNs/(timeslots/1 MTP). This value can be used to
++ * convert the number of PBNs required for a given stream to the number of
++ * timeslots this stream requires in each MTP.
++ */
++int drm_dp_get_vc_payload_bw(int link_rate, int link_lane_count)
+ {
+- if (dp_link_bw == 0 || dp_link_count == 0)
+- DRM_DEBUG_KMS("invalid link bandwidth in DPCD: %x (link count: %d)\n",
+- dp_link_bw, dp_link_count);
++ if (link_rate == 0 || link_lane_count == 0)
++ DRM_DEBUG_KMS("invalid link rate/lane count: (%d / %d)\n",
++ link_rate, link_lane_count);
+
+- return dp_link_bw * dp_link_count / 2;
++ /* See DP v2.0 2.6.4.2, VCPayload_Bandwidth_for_OneTimeSlotPer_MTP_Allocation */
++ return link_rate * link_lane_count / 54000;
+ }
++EXPORT_SYMBOL(drm_dp_get_vc_payload_bw);
+
+ /**
+ * drm_dp_read_mst_cap() - check whether or not a sink supports MST
+@@ -3692,7 +3704,7 @@ int drm_dp_mst_topology_mgr_set_mst(stru
+ goto out_unlock;
+ }
+
+- mgr->pbn_div = drm_dp_get_vc_payload_bw(mgr->dpcd[1],
++ mgr->pbn_div = drm_dp_get_vc_payload_bw(drm_dp_bw_code_to_link_rate(mgr->dpcd[1]),
+ mgr->dpcd[2] & DP_MAX_LANE_COUNT_MASK);
+ if (mgr->pbn_div == 0) {
+ ret = -EINVAL;
+--- a/include/drm/drm_dp_mst_helper.h
++++ b/include/drm/drm_dp_mst_helper.h
+@@ -783,6 +783,7 @@ drm_dp_mst_detect_port(struct drm_connec
+
+ struct edid *drm_dp_mst_get_edid(struct drm_connector *connector, struct drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
+
++int drm_dp_get_vc_payload_bw(int link_rate, int link_lane_count);
+
+ int drm_dp_calc_pbn_mode(int clock, int bpp, bool dsc);
+
--- /dev/null
+From 00f9a08fbc3c703b71842a5425c1eb82053c8a70 Mon Sep 17 00:00:00 2001
+From: Andres Calderon Jaramillo <andrescj@chromium.org>
+Date: Tue, 2 Feb 2021 10:45:53 +0200
+Subject: drm/i915/display: Prevent double YUV range correction on HDR planes
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Andres Calderon Jaramillo <andrescj@chromium.org>
+
+commit 00f9a08fbc3c703b71842a5425c1eb82053c8a70 upstream.
+
+Prevent the ICL HDR plane pipeline from performing YUV color range
+correction twice when the input is in limited range. This is done by
+removing the limited-range code from icl_program_input_csc().
+
+Before this patch the following could happen: user space gives us a YUV
+buffer in limited range; per the pipeline in [1], the plane would first
+go through a "YUV Range correct" stage that expands the range; the plane
+would then go through the "Input CSC" stage which would also expand the
+range because icl_program_input_csc() would use a matrix and an offset
+that assume limited-range input; this would ultimately cause dark and
+light colors to appear darker and lighter than they should respectively.
+
+This is an issue because if a buffer switches between being scanned out
+and being composited with the GPU, the user will see a color difference.
+If this switching happens quickly and frequently, the user will perceive
+this as a flickering.
+
+[1] https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-icllp-vol12-displayengine_0.pdf#page=281
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Andres Calderon Jaramillo <andrescj@chromium.org>
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20201215224219.3896256-1-andrescj@google.com
+(cherry picked from commit fed387572040e84ead53852a7820e30a30e515d0)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210202084553.30691-1-ville.syrjala@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/intel_display.c | 2
+ drivers/gpu/drm/i915/display/intel_sprite.c | 65 ++++-----------------------
+ 2 files changed, 12 insertions(+), 55 deletions(-)
+
+--- a/drivers/gpu/drm/i915/display/intel_display.c
++++ b/drivers/gpu/drm/i915/display/intel_display.c
+@@ -4880,6 +4880,8 @@ u32 glk_plane_color_ctl(const struct int
+ plane_color_ctl |= PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
+ } else if (fb->format->is_yuv) {
+ plane_color_ctl |= PLANE_COLOR_INPUT_CSC_ENABLE;
++ if (plane_state->hw.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
++ plane_color_ctl |= PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
+ }
+
+ return plane_color_ctl;
+--- a/drivers/gpu/drm/i915/display/intel_sprite.c
++++ b/drivers/gpu/drm/i915/display/intel_sprite.c
+@@ -469,13 +469,19 @@ skl_program_scaler(struct intel_plane *p
+
+ /* Preoffset values for YUV to RGB Conversion */
+ #define PREOFF_YUV_TO_RGB_HI 0x1800
+-#define PREOFF_YUV_TO_RGB_ME 0x1F00
++#define PREOFF_YUV_TO_RGB_ME 0x0000
+ #define PREOFF_YUV_TO_RGB_LO 0x1800
+
+ #define ROFF(x) (((x) & 0xffff) << 16)
+ #define GOFF(x) (((x) & 0xffff) << 0)
+ #define BOFF(x) (((x) & 0xffff) << 16)
+
++/*
++ * Programs the input color space conversion stage for ICL HDR planes.
++ * Note that it is assumed that this stage always happens after YUV
++ * range correction. Thus, the input to this stage is assumed to be
++ * in full-range YCbCr.
++ */
+ static void
+ icl_program_input_csc(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+@@ -523,52 +529,7 @@ icl_program_input_csc(struct intel_plane
+ 0x0, 0x7800, 0x7F10,
+ },
+ };
+-
+- /* Matrix for Limited Range to Full Range Conversion */
+- static const u16 input_csc_matrix_lr[][9] = {
+- /*
+- * BT.601 Limted range YCbCr -> full range RGB
+- * The matrix required is :
+- * [1.164384, 0.000, 1.596027,
+- * 1.164384, -0.39175, -0.812813,
+- * 1.164384, 2.017232, 0.0000]
+- */
+- [DRM_COLOR_YCBCR_BT601] = {
+- 0x7CC8, 0x7950, 0x0,
+- 0x8D00, 0x7950, 0x9C88,
+- 0x0, 0x7950, 0x6810,
+- },
+- /*
+- * BT.709 Limited range YCbCr -> full range RGB
+- * The matrix required is :
+- * [1.164384, 0.000, 1.792741,
+- * 1.164384, -0.213249, -0.532909,
+- * 1.164384, 2.112402, 0.0000]
+- */
+- [DRM_COLOR_YCBCR_BT709] = {
+- 0x7E58, 0x7950, 0x0,
+- 0x8888, 0x7950, 0xADA8,
+- 0x0, 0x7950, 0x6870,
+- },
+- /*
+- * BT.2020 Limited range YCbCr -> full range RGB
+- * The matrix required is :
+- * [1.164, 0.000, 1.678,
+- * 1.164, -0.1873, -0.6504,
+- * 1.164, 2.1417, 0.0000]
+- */
+- [DRM_COLOR_YCBCR_BT2020] = {
+- 0x7D70, 0x7950, 0x0,
+- 0x8A68, 0x7950, 0xAC00,
+- 0x0, 0x7950, 0x6890,
+- },
+- };
+- const u16 *csc;
+-
+- if (plane_state->hw.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
+- csc = input_csc_matrix[plane_state->hw.color_encoding];
+- else
+- csc = input_csc_matrix_lr[plane_state->hw.color_encoding];
++ const u16 *csc = input_csc_matrix[plane_state->hw.color_encoding];
+
+ intel_de_write_fw(dev_priv, PLANE_INPUT_CSC_COEFF(pipe, plane_id, 0),
+ ROFF(csc[0]) | GOFF(csc[1]));
+@@ -585,14 +546,8 @@ icl_program_input_csc(struct intel_plane
+
+ intel_de_write_fw(dev_priv, PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 0),
+ PREOFF_YUV_TO_RGB_HI);
+- if (plane_state->hw.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
+- intel_de_write_fw(dev_priv,
+- PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1),
+- 0);
+- else
+- intel_de_write_fw(dev_priv,
+- PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1),
+- PREOFF_YUV_TO_RGB_ME);
++ intel_de_write_fw(dev_priv, PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1),
++ PREOFF_YUV_TO_RGB_ME);
+ intel_de_write_fw(dev_priv, PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 2),
+ PREOFF_YUV_TO_RGB_LO);
+ intel_de_write_fw(dev_priv,
--- /dev/null
+From 425cbd1fce10d4d68188123404d1a302a6939e0a Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Thu, 28 Jan 2021 17:59:45 +0200
+Subject: drm/i915: Extract intel_ddi_power_up_lanes()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ville Syrjälä <ville.syrjala@linux.intel.com>
+
+commit 425cbd1fce10d4d68188123404d1a302a6939e0a upstream.
+
+Reduce the copypasta by pulling the combo PHY lane
+power up stuff into a helper. We'll have a third user soon.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210128155948.13678-2-ville.syrjala@linux.intel.com
+Reviewed-by: Imre Deak <imre.deak@intel.com>
+(cherry picked from commit 5cdf706fb91a6e4e6af799bb957c4d598e6a067b)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/intel_ddi.c | 35 ++++++++++++++++---------------
+ 1 file changed, 19 insertions(+), 16 deletions(-)
+
+--- a/drivers/gpu/drm/i915/display/intel_ddi.c
++++ b/drivers/gpu/drm/i915/display/intel_ddi.c
+@@ -3274,6 +3274,23 @@ static void intel_ddi_disable_fec_state(
+ intel_de_posting_read(dev_priv, intel_dp->regs.dp_tp_ctl);
+ }
+
++static void intel_ddi_power_up_lanes(struct intel_encoder *encoder,
++ const struct intel_crtc_state *crtc_state)
++{
++ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
++ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
++ enum phy phy = intel_port_to_phy(i915, encoder->port);
++
++ if (intel_phy_is_combo(i915, phy)) {
++ bool lane_reversal =
++ dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;
++
++ intel_combo_phy_power_up_lanes(i915, phy, false,
++ crtc_state->lane_count,
++ lane_reversal);
++ }
++}
++
+ static void tgl_ddi_pre_enable_dp(struct intel_atomic_state *state,
+ struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+@@ -3367,14 +3384,7 @@ static void tgl_ddi_pre_enable_dp(struct
+ * 7.f Combo PHY: Configure PORT_CL_DW10 Static Power Down to power up
+ * the used lanes of the DDI.
+ */
+- if (intel_phy_is_combo(dev_priv, phy)) {
+- bool lane_reversal =
+- dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;
+-
+- intel_combo_phy_power_up_lanes(dev_priv, phy, false,
+- crtc_state->lane_count,
+- lane_reversal);
+- }
++ intel_ddi_power_up_lanes(encoder, crtc_state);
+
+ /*
+ * 7.g Configure and enable DDI_BUF_CTL
+@@ -3458,14 +3468,7 @@ static void hsw_ddi_pre_enable_dp(struct
+ else
+ intel_prepare_dp_ddi_buffers(encoder, crtc_state);
+
+- if (intel_phy_is_combo(dev_priv, phy)) {
+- bool lane_reversal =
+- dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;
+-
+- intel_combo_phy_power_up_lanes(dev_priv, phy, false,
+- crtc_state->lane_count,
+- lane_reversal);
+- }
++ intel_ddi_power_up_lanes(encoder, crtc_state);
+
+ intel_ddi_init_dp_buf_reg(encoder);
+ if (!is_mst)
--- /dev/null
+From 882554042d138dbc6fb1a43017d0b9c3b38ee5f5 Mon Sep 17 00:00:00 2001
+From: Imre Deak <imre.deak@intel.com>
+Date: Mon, 25 Jan 2021 19:36:36 +0200
+Subject: drm/i915: Fix the MST PBN divider calculation
+
+From: Imre Deak <imre.deak@intel.com>
+
+commit 882554042d138dbc6fb1a43017d0b9c3b38ee5f5 upstream.
+
+Atm the driver will calculate a wrong MST timeslots/MTP (aka time unit)
+value for MST streams if the link parameters (link rate or lane count)
+are limited in a way independent of the sink capabilities (reported by
+DPCD).
+
+One example of such a limitation is when a MUX between the sink and
+source connects only a limited number of lanes to the display and
+connects the rest of the lanes to other peripherals (USB).
+
+Another issue is that atm MST core calculates the divider based on the
+backwards compatible DPCD (at address 0x0000) vs. the extended
+capability info (at address 0x2200). This can result in leaving some
+part of the MST BW unused (For instance in case of the WD19TB dock).
+
+Fix the above two issues by calculating the PBN divider value based on
+the rate and lane count link parameters that the driver uses for all
+other computation.
+
+Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/2977
+Cc: Lyude Paul <lyude@redhat.com>
+Cc: Ville Syrjala <ville.syrjala@intel.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Imre Deak <imre.deak@intel.com>
+Reviewed-by: Ville Syrjala <ville.syrjala@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210125173636.1733812-2-imre.deak@intel.com
+(cherry picked from commit b59c27cab257cfbff939615a87b72bce83925710)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
++++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
+@@ -68,7 +68,9 @@ static int intel_dp_mst_compute_link_con
+
+ slots = drm_dp_atomic_find_vcpi_slots(state, &intel_dp->mst_mgr,
+ connector->port,
+- crtc_state->pbn, 0);
++ crtc_state->pbn,
++ drm_dp_get_vc_payload_bw(crtc_state->port_clock,
++ crtc_state->lane_count));
+ if (slots == -EDEADLK)
+ return slots;
+ if (slots >= 0)
--- /dev/null
+From 761c70a52586a9214b29026d384d2c01b73661a8 Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Mon, 25 Jan 2021 13:21:58 +0000
+Subject: drm/i915/gem: Drop lru bumping on display unpinning
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit 761c70a52586a9214b29026d384d2c01b73661a8 upstream.
+
+Simplify the frontbuffer unpin by removing the lock requirement. The LRU
+bumping was primarily to protect the GTT from being evicted and from
+frontbuffers being eagerly shrunk. Now we protect frontbuffers from the
+shrinker, and we avoid accidentally evicting from the GTT, so the
+benefit from bumping LRU is no more, and we can save more time by not.
+
+Reported-and-tested-by: Matti Hämäläinen <ccr@tnsp.org>
+Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2905
+Fixes: c1793ba86a41 ("drm/i915: Add ww locking to pin_to_display_plane, v2.")
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Reviewed-by: Matthew Auld <matthew.auld@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210119214336.1463-6-chris@chris-wilson.co.uk
+(cherry picked from commit 14ca83eece9565a2d2177291ceb122982dc38420)
+Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
+Cc: Jani Nikula <jani.nikula@intel.com>
+Cc: <stable@vger.kernel.org> # v5.10+
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/intel_display.c | 7 +---
+ drivers/gpu/drm/i915/display/intel_overlay.c | 4 +-
+ drivers/gpu/drm/i915/gem/i915_gem_domain.c | 45 ---------------------------
+ drivers/gpu/drm/i915/gem/i915_gem_object.h | 1
+ 4 files changed, 4 insertions(+), 53 deletions(-)
+
+--- a/drivers/gpu/drm/i915/display/intel_display.c
++++ b/drivers/gpu/drm/i915/display/intel_display.c
+@@ -2294,7 +2294,7 @@ intel_pin_and_fence_fb_obj(struct drm_fr
+ */
+ ret = i915_vma_pin_fence(vma);
+ if (ret != 0 && INTEL_GEN(dev_priv) < 4) {
+- i915_gem_object_unpin_from_display_plane(vma);
++ i915_vma_unpin(vma);
+ vma = ERR_PTR(ret);
+ goto err;
+ }
+@@ -2312,12 +2312,9 @@ err:
+
+ void intel_unpin_fb_vma(struct i915_vma *vma, unsigned long flags)
+ {
+- i915_gem_object_lock(vma->obj, NULL);
+ if (flags & PLANE_HAS_FENCE)
+ i915_vma_unpin_fence(vma);
+- i915_gem_object_unpin_from_display_plane(vma);
+- i915_gem_object_unlock(vma->obj);
+-
++ i915_vma_unpin(vma);
+ i915_vma_put(vma);
+ }
+
+--- a/drivers/gpu/drm/i915/display/intel_overlay.c
++++ b/drivers/gpu/drm/i915/display/intel_overlay.c
+@@ -359,7 +359,7 @@ static void intel_overlay_release_old_vm
+ intel_frontbuffer_flip_complete(overlay->i915,
+ INTEL_FRONTBUFFER_OVERLAY(overlay->crtc->pipe));
+
+- i915_gem_object_unpin_from_display_plane(vma);
++ i915_vma_unpin(vma);
+ i915_vma_put(vma);
+ }
+
+@@ -860,7 +860,7 @@ static int intel_overlay_do_put_image(st
+ return 0;
+
+ out_unpin:
+- i915_gem_object_unpin_from_display_plane(vma);
++ i915_vma_unpin(vma);
+ out_pin_section:
+ atomic_dec(&dev_priv->gpu_error.pending_fb_pin);
+
+--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
++++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+@@ -387,48 +387,6 @@ err:
+ return vma;
+ }
+
+-static void i915_gem_object_bump_inactive_ggtt(struct drm_i915_gem_object *obj)
+-{
+- struct drm_i915_private *i915 = to_i915(obj->base.dev);
+- struct i915_vma *vma;
+-
+- if (list_empty(&obj->vma.list))
+- return;
+-
+- mutex_lock(&i915->ggtt.vm.mutex);
+- spin_lock(&obj->vma.lock);
+- for_each_ggtt_vma(vma, obj) {
+- if (!drm_mm_node_allocated(&vma->node))
+- continue;
+-
+- GEM_BUG_ON(vma->vm != &i915->ggtt.vm);
+- list_move_tail(&vma->vm_link, &vma->vm->bound_list);
+- }
+- spin_unlock(&obj->vma.lock);
+- mutex_unlock(&i915->ggtt.vm.mutex);
+-
+- if (i915_gem_object_is_shrinkable(obj)) {
+- unsigned long flags;
+-
+- spin_lock_irqsave(&i915->mm.obj_lock, flags);
+-
+- if (obj->mm.madv == I915_MADV_WILLNEED &&
+- !atomic_read(&obj->mm.shrink_pin))
+- list_move_tail(&obj->mm.link, &i915->mm.shrink_list);
+-
+- spin_unlock_irqrestore(&i915->mm.obj_lock, flags);
+- }
+-}
+-
+-void
+-i915_gem_object_unpin_from_display_plane(struct i915_vma *vma)
+-{
+- /* Bump the LRU to try and avoid premature eviction whilst flipping */
+- i915_gem_object_bump_inactive_ggtt(vma->obj);
+-
+- i915_vma_unpin(vma);
+-}
+-
+ /**
+ * Moves a single object to the CPU read, and possibly write domain.
+ * @obj: object to act on
+@@ -569,9 +527,6 @@ i915_gem_set_domain_ioctl(struct drm_dev
+ else
+ err = i915_gem_object_set_to_cpu_domain(obj, write_domain);
+
+- /* And bump the LRU for this access */
+- i915_gem_object_bump_inactive_ggtt(obj);
+-
+ i915_gem_object_unlock(obj);
+
+ if (write_domain)
+--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
++++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
+@@ -471,7 +471,6 @@ i915_gem_object_pin_to_display_plane(str
+ u32 alignment,
+ const struct i915_ggtt_view *view,
+ unsigned int flags);
+-void i915_gem_object_unpin_from_display_plane(struct i915_vma *vma);
+
+ void i915_gem_object_make_unshrinkable(struct drm_i915_gem_object *obj);
+ void i915_gem_object_make_shrinkable(struct drm_i915_gem_object *obj);
--- /dev/null
+From e4747cb3ec3c232d65c84cbe77633abd5871fda3 Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Tue, 19 Jan 2021 16:20:57 +0000
+Subject: drm/i915/gt: Close race between enable_breadcrumbs and cancel_breadcrumbs
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit e4747cb3ec3c232d65c84cbe77633abd5871fda3 upstream.
+
+If we enable_breadcrumbs for a request while that request is being
+removed from HW; we may see that the request is active as we take the
+ce->signal_lock and proceed to attach the request to ce->signals.
+However, during unsubmission after marking the request as inactive, we
+see that the request has not yet been added to ce->signals and so skip
+the removal. Pull the check during cancel_breadcrumbs under the same
+spinlock as enabling so that we the two tests are consistent in
+enable/cancel.
+
+Otherwise, we may insert a request onto ce->signals that we expect should
+not be there:
+
+ intel_context_remove_breadcrumbs:488 GEM_BUG_ON(!__i915_request_is_complete(rq))
+
+While updating, we can note that we are always called with
+irqs-disabled, due to the engine->active.lock being held at the single
+caller, and so remove the irqsave/restore making it symmetric to
+enable_breadcrumbs.
+
+Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2931
+Fixes: c18636f76344 ("drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs")
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Cc: Andi Shyti <andi.shyti@intel.com>
+Cc: <stable@vger.kernel.org> # v5.10+
+Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210119162057.31097-1-chris@chris-wilson.co.uk
+(cherry picked from commit e7004ea4f5f528f5a5018f0b70cab36d25315498)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
++++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+@@ -451,10 +451,12 @@ void i915_request_cancel_breadcrumb(stru
+ struct intel_context *ce = rq->context;
+ bool release;
+
+- if (!test_and_clear_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags))
++ spin_lock(&ce->signal_lock);
++ if (!test_and_clear_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags)) {
++ spin_unlock(&ce->signal_lock);
+ return;
++ }
+
+- spin_lock(&ce->signal_lock);
+ list_del_rcu(&rq->signal_link);
+ release = remove_signaling_context(rq->engine->breadcrumbs, ce);
+ spin_unlock(&ce->signal_lock);
--- /dev/null
+From fad9bae9ee5d578afbe6380c82e4715efaddf118 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Thu, 28 Jan 2021 17:59:46 +0200
+Subject: drm/i915: Power up combo PHY lanes for for HDMI as well
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ville Syrjälä <ville.syrjala@linux.intel.com>
+
+commit fad9bae9ee5d578afbe6380c82e4715efaddf118 upstream.
+
+Currently we only explicitly power up the combo PHY lanes
+for DP. The spec says we should do it for HDMI as well.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210128155948.13678-3-ville.syrjala@linux.intel.com
+Reviewed-by: Imre Deak <imre.deak@intel.com>
+(cherry picked from commit 1e0cb7bef35f0d1aed383bf69a209df218b807c9)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/gpu/drm/i915/display/intel_ddi.c
++++ b/drivers/gpu/drm/i915/display/intel_ddi.c
+@@ -3936,6 +3936,8 @@ static void intel_enable_ddi_hdmi(struct
+ intel_de_write(dev_priv, reg, val);
+ }
+
++ intel_ddi_power_up_lanes(encoder, crtc_state);
++
+ /* In HDMI/DVI mode, the port width, and swing/emphasis values
+ * are ignored so nothing special needs to be done besides
+ * enabling the port.
--- /dev/null
+From 19a23da53932bc8011220bd8c410cb76012de004 Mon Sep 17 00:00:00 2001
+From: Peter Gonda <pgonda@google.com>
+Date: Wed, 27 Jan 2021 08:15:24 -0800
+Subject: Fix unsynchronized access to sev members through svm_register_enc_region
+
+From: Peter Gonda <pgonda@google.com>
+
+commit 19a23da53932bc8011220bd8c410cb76012de004 upstream.
+
+Grab kvm->lock before pinning memory when registering an encrypted
+region; sev_pin_memory() relies on kvm->lock being held to ensure
+correctness when checking and updating the number of pinned pages.
+
+Add a lockdep assertion to help prevent future regressions.
+
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Cc: Paolo Bonzini <pbonzini@redhat.com>
+Cc: Joerg Roedel <joro@8bytes.org>
+Cc: Tom Lendacky <thomas.lendacky@amd.com>
+Cc: Brijesh Singh <brijesh.singh@amd.com>
+Cc: Sean Christopherson <seanjc@google.com>
+Cc: x86@kernel.org
+Cc: kvm@vger.kernel.org
+Cc: stable@vger.kernel.org
+Cc: linux-kernel@vger.kernel.org
+Fixes: 1e80fdc09d12 ("KVM: SVM: Pin guest memory when SEV is active")
+Signed-off-by: Peter Gonda <pgonda@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+V2
+ - Fix up patch description
+ - Correct file paths svm.c -> sev.c
+ - Add unlock of kvm->lock on sev_pin_memory error
+
+V1
+ - https://lore.kernel.org/kvm/20210126185431.1824530-1-pgonda@google.com/
+
+Message-Id: <20210127161524.2832400-1-pgonda@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+---
+ arch/x86/kvm/svm/sev.c | 17 ++++++++++-------
+ 1 file changed, 10 insertions(+), 7 deletions(-)
+
+--- a/arch/x86/kvm/svm/sev.c
++++ b/arch/x86/kvm/svm/sev.c
+@@ -320,6 +320,8 @@ static struct page **sev_pin_memory(stru
+ unsigned long first, last;
+ int ret;
+
++ lockdep_assert_held(&kvm->lock);
++
+ if (ulen == 0 || uaddr + ulen < uaddr)
+ return ERR_PTR(-EINVAL);
+
+@@ -1001,12 +1003,20 @@ int svm_register_enc_region(struct kvm *
+ if (!region)
+ return -ENOMEM;
+
++ mutex_lock(&kvm->lock);
+ region->pages = sev_pin_memory(kvm, range->addr, range->size, ®ion->npages, 1);
+ if (IS_ERR(region->pages)) {
+ ret = PTR_ERR(region->pages);
++ mutex_unlock(&kvm->lock);
+ goto e_free;
+ }
+
++ region->uaddr = range->addr;
++ region->size = range->size;
++
++ list_add_tail(®ion->list, &sev->regions_list);
++ mutex_unlock(&kvm->lock);
++
+ /*
+ * The guest may change the memory encryption attribute from C=0 -> C=1
+ * or vice versa for this memory range. Lets make sure caches are
+@@ -1015,13 +1025,6 @@ int svm_register_enc_region(struct kvm *
+ */
+ sev_clflush_pages(region->pages, region->npages);
+
+- region->uaddr = range->addr;
+- region->size = range->size;
+-
+- mutex_lock(&kvm->lock);
+- list_add_tail(®ion->list, &sev->regions_list);
+- mutex_unlock(&kvm->lock);
+-
+ return ret;
+
+ e_free:
--- /dev/null
+From d7e10d47691d1702db1cd1edcc689d3031eefc67 Mon Sep 17 00:00:00 2001
+From: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com>
+Date: Thu, 4 Feb 2021 17:20:56 +0800
+Subject: io_uring: don't modify identity's files uncess identity is cowed
+
+From: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com>
+
+commit d7e10d47691d1702db1cd1edcc689d3031eefc67 upstream.
+
+Abaci Robot reported following panic:
+BUG: kernel NULL pointer dereference, address: 0000000000000000
+PGD 800000010ef3f067 P4D 800000010ef3f067 PUD 10d9df067 PMD 0
+Oops: 0002 [#1] SMP PTI
+CPU: 0 PID: 1869 Comm: io_wqe_worker-0 Not tainted 5.11.0-rc3+ #1
+Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
+RIP: 0010:put_files_struct+0x1b/0x120
+Code: 24 18 c7 00 f4 ff ff ff e9 4d fd ff ff 66 90 0f 1f 44 00 00 41 57 41 56 49 89 fe 41 55 41 54 55 53 48 83 ec 08 e8 b5 6b db ff 41 ff 0e 74 13 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f e9 9c
+RSP: 0000:ffffc90002147d48 EFLAGS: 00010293
+RAX: 0000000000000000 RBX: ffff88810d9a5300 RCX: 0000000000000000
+RDX: ffff88810d87c280 RSI: ffffffff8144ba6b RDI: 0000000000000000
+RBP: 0000000000000080 R08: 0000000000000001 R09: ffffffff81431500
+R10: ffff8881001be000 R11: 0000000000000000 R12: ffff88810ac2f800
+R13: ffff88810af38a00 R14: 0000000000000000 R15: ffff8881057130c0
+FS: 0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 0000000000000000 CR3: 000000010dbaa002 CR4: 00000000003706f0
+DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+Call Trace:
+ __io_clean_op+0x10c/0x2a0
+ io_dismantle_req+0x3c7/0x600
+ __io_free_req+0x34/0x280
+ io_put_req+0x63/0xb0
+ io_worker_handle_work+0x60e/0x830
+ ? io_wqe_worker+0x135/0x520
+ io_wqe_worker+0x158/0x520
+ ? __kthread_parkme+0x96/0xc0
+ ? io_worker_handle_work+0x830/0x830
+ kthread+0x134/0x180
+ ? kthread_create_worker_on_cpu+0x90/0x90
+ ret_from_fork+0x1f/0x30
+Modules linked in:
+CR2: 0000000000000000
+---[ end trace c358ca86af95b1e7 ]---
+
+I guess case below can trigger above panic: there're two threads which
+operates different io_uring ctxs and share same sqthread identity, and
+later one thread exits, io_uring_cancel_task_requests() will clear
+task->io_uring->identity->files to be NULL in sqpoll mode, then another
+ctx that uses same identity will panic.
+
+Indeed we don't need to clear task->io_uring->identity->files here,
+io_grab_identity() should handle identity->files changes well, if
+task->io_uring->identity->files is not equal to current->files,
+io_cow_identity() should handle this changes well.
+
+Cc: stable@vger.kernel.org # 5.5+
+Reported-by: Abaci Robot <abaci@linux.alibaba.com>
+Signed-off-by: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com>
+Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/io_uring.c | 6 ------
+ 1 file changed, 6 deletions(-)
+
+--- a/fs/io_uring.c
++++ b/fs/io_uring.c
+@@ -8782,12 +8782,6 @@ static void io_uring_cancel_task_request
+
+ if ((ctx->flags & IORING_SETUP_SQPOLL) && ctx->sq_data) {
+ atomic_dec(&task->io_uring->in_idle);
+- /*
+- * If the files that are going away are the ones in the thread
+- * identity, clear them out.
+- */
+- if (task->io_uring->identity->files == files)
+- task->io_uring->identity->files = NULL;
+ io_sq_thread_unpark(ctx->sq_data);
+ }
+ }
--- /dev/null
+From 4c9fb5d9140802db4db9f66c23887f43174e113c Mon Sep 17 00:00:00 2001
+From: Joerg Roedel <jroedel@suse.de>
+Date: Tue, 2 Feb 2021 15:54:19 +0100
+Subject: iommu: Check dev->iommu in dev_iommu_priv_get() before dereferencing it
+
+From: Joerg Roedel <jroedel@suse.de>
+
+commit 4c9fb5d9140802db4db9f66c23887f43174e113c upstream.
+
+The dev_iommu_priv_get() needs a similar check to
+dev_iommu_fwspec_get() to make sure no NULL-ptr is dereferenced.
+
+Fixes: 05a0542b456e1 ("iommu/amd: Store dev_data as device iommu private data")
+Cc: stable@vger.kernel.org # v5.8+
+Link: https://lore.kernel.org/r/20210202145419.29143-1-joro@8bytes.org
+Reference: https://bugzilla.kernel.org/show_bug.cgi?id=211241
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/iommu.h | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/include/linux/iommu.h
++++ b/include/linux/iommu.h
+@@ -614,7 +614,10 @@ static inline void dev_iommu_fwspec_set(
+
+ static inline void *dev_iommu_priv_get(struct device *dev)
+ {
+- return dev->iommu->priv;
++ if (dev->iommu)
++ return dev->iommu->priv;
++ else
++ return NULL;
+ }
+
+ static inline void dev_iommu_priv_set(struct device *dev, void *priv)
--- /dev/null
+From f92e04f764b86e55e522988e6f4b6082d19a2721 Mon Sep 17 00:00:00 2001
+From: Fengnan Chang <fengnanchang@gmail.com>
+Date: Sat, 23 Jan 2021 11:32:31 +0800
+Subject: mmc: core: Limit retries when analyse of SDIO tuples fails
+
+From: Fengnan Chang <fengnanchang@gmail.com>
+
+commit f92e04f764b86e55e522988e6f4b6082d19a2721 upstream.
+
+When analysing tuples fails we may loop indefinitely to retry. Let's avoid
+this by using a 10s timeout and bail if not completed earlier.
+
+Signed-off-by: Fengnan Chang <fengnanchang@gmail.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20210123033230.36442-1-fengnanchang@gmail.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/core/sdio_cis.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/mmc/core/sdio_cis.c
++++ b/drivers/mmc/core/sdio_cis.c
+@@ -20,6 +20,8 @@
+ #include "sdio_cis.h"
+ #include "sdio_ops.h"
+
++#define SDIO_READ_CIS_TIMEOUT_MS (10 * 1000) /* 10s */
++
+ static int cistpl_vers_1(struct mmc_card *card, struct sdio_func *func,
+ const unsigned char *buf, unsigned size)
+ {
+@@ -274,6 +276,8 @@ static int sdio_read_cis(struct mmc_card
+
+ do {
+ unsigned char tpl_code, tpl_link;
++ unsigned long timeout = jiffies +
++ msecs_to_jiffies(SDIO_READ_CIS_TIMEOUT_MS);
+
+ ret = mmc_io_rw_direct(card, 0, 0, ptr++, 0, &tpl_code);
+ if (ret)
+@@ -326,6 +330,8 @@ static int sdio_read_cis(struct mmc_card
+ prev = &this->next;
+
+ if (ret == -ENOENT) {
++ if (time_after(jiffies, timeout))
++ break;
+ /* warn about unknown tuples */
+ pr_warn_ratelimited("%s: queuing unknown"
+ " CIS tuple 0x%02x (%u bytes)\n",
--- /dev/null
+From d7fb9c24209556478e65211d7a1f056f2d43cceb Mon Sep 17 00:00:00 2001
+From: Ulf Hansson <ulf.hansson@linaro.org>
+Date: Tue, 26 Jan 2021 10:43:13 +0100
+Subject: mmc: sdhci-pltfm: Fix linking err for sdhci-brcmstb
+
+From: Ulf Hansson <ulf.hansson@linaro.org>
+
+commit d7fb9c24209556478e65211d7a1f056f2d43cceb upstream.
+
+The implementation of sdhci_pltfm_suspend() is only available when
+CONFIG_PM_SLEEP is set, which triggers a linking error:
+
+"undefined symbol: sdhci_pltfm_suspend" when building sdhci-brcmstb.c.
+
+Fix this by implementing the missing stubs when CONFIG_PM_SLEEP is unset.
+
+Reported-by: Arnd Bergmann <arnd@arndb.de>
+Suggested-by: Florian Fainelli <f.fainelli@gmail.com>
+Fixes: 5b191dcba719 ("mmc: sdhci-brcmstb: Fix mmc timeout errors on S5 suspend")
+Cc: stable@vger.kernel.org
+Tested-By: Nicolas Schichan <nschichan@freeebox.fr>
+Acked-by: Arnd Bergmann <arnd@arndb.de>
+Acked-by: Florian Fainelli <f.fainelli@gmail.com>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/sdhci-pltfm.h | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/sdhci-pltfm.h
++++ b/drivers/mmc/host/sdhci-pltfm.h
+@@ -111,8 +111,13 @@ static inline void *sdhci_pltfm_priv(str
+ return host->private;
+ }
+
++extern const struct dev_pm_ops sdhci_pltfm_pmops;
++#ifdef CONFIG_PM_SLEEP
+ int sdhci_pltfm_suspend(struct device *dev);
+ int sdhci_pltfm_resume(struct device *dev);
+-extern const struct dev_pm_ops sdhci_pltfm_pmops;
++#else
++static inline int sdhci_pltfm_suspend(struct device *dev) { return 0; }
++static inline int sdhci_pltfm_resume(struct device *dev) { return 0; }
++#endif
+
+ #endif /* _DRIVERS_MMC_SDHCI_PLTFM_H */
--- /dev/null
+From 538e4a8c571efdf131834431e0c14808bcfb1004 Mon Sep 17 00:00:00 2001
+From: Thorsten Leemhuis <linux@leemhuis.info>
+Date: Fri, 29 Jan 2021 06:24:42 +0100
+Subject: nvme-pci: avoid the deepest sleep state on Kingston A2000 SSDs
+
+From: Thorsten Leemhuis <linux@leemhuis.info>
+
+commit 538e4a8c571efdf131834431e0c14808bcfb1004 upstream.
+
+Some Kingston A2000 NVMe SSDs sooner or later get confused and stop
+working when they use the deepest APST sleep while running Linux. The
+system then crashes and one has to cold boot it to get the SSD working
+again.
+
+Kingston seems to known about this since at least mid-September 2020:
+https://bbs.archlinux.org/viewtopic.php?pid=1926994#p1926994
+
+Someone working for a German company representing Kingston to the German
+press confirmed to me Kingston engineering is aware of the issue and
+investigating; the person stated that to their current knowledge only
+the deepest APST sleep state causes trouble. Therefore, make Linux avoid
+it for now by applying the NVME_QUIRK_NO_DEEPEST_PS to this SSD.
+
+I have two such SSDs, but it seems the problem doesn't occur with them.
+I hence couldn't verify if this patch really fixes the problem, but all
+the data in front of me suggests it should.
+
+This patch can easily be reverted or improved upon if a better solution
+surfaces.
+
+FWIW, there are many reports about the issue scattered around the web;
+most of the users disabled APST completely to make things work, some
+just made Linux avoid the deepest sleep state:
+
+https://bugzilla.kernel.org/show_bug.cgi?id=195039#c65
+https://bugzilla.kernel.org/show_bug.cgi?id=195039#c73
+https://bugzilla.kernel.org/show_bug.cgi?id=195039#c74
+https://bugzilla.kernel.org/show_bug.cgi?id=195039#c78
+https://bugzilla.kernel.org/show_bug.cgi?id=195039#c79
+https://bugzilla.kernel.org/show_bug.cgi?id=195039#c80
+https://askubuntu.com/questions/1222049/nvmekingston-a2000-sometimes-stops-giving-response-in-ubuntu-18-04dell-inspir
+https://community.acer.com/en/discussion/604326/m-2-nvme-ssd-aspire-517-51g-issue-compatibility-kingston-a2000-linux-ubuntu
+
+For the record, some data from 'nvme id-ctrl /dev/nvme0'
+
+NVME Identify Controller:
+vid : 0x2646
+ssvid : 0x2646
+mn : KINGSTON SA2000M81000G
+fr : S5Z42105
+[...]
+ps 0 : mp:9.00W operational enlat:0 exlat:0 rrt:0 rrl:0
+ rwt:0 rwl:0 idle_power:- active_power:-
+ps 1 : mp:4.60W operational enlat:0 exlat:0 rrt:1 rrl:1
+ rwt:1 rwl:1 idle_power:- active_power:-
+ps 2 : mp:3.80W operational enlat:0 exlat:0 rrt:2 rrl:2
+ rwt:2 rwl:2 idle_power:- active_power:-
+ps 3 : mp:0.0450W non-operational enlat:2000 exlat:2000 rrt:3 rrl:3
+ rwt:3 rwl:3 idle_power:- active_power:-
+ps 4 : mp:0.0040W non-operational enlat:15000 exlat:15000 rrt:4 rrl:4
+ rwt:4 rwl:4 idle_power:- active_power:-
+
+Cc: stable@vger.kernel.org # 4.14+
+Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nvme/host/pci.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/nvme/host/pci.c
++++ b/drivers/nvme/host/pci.c
+@@ -3262,6 +3262,8 @@ static const struct pci_device_id nvme_i
+ .driver_data = NVME_QUIRK_DISABLE_WRITE_ZEROES, },
+ { PCI_DEVICE(0x15b7, 0x2001), /* Sandisk Skyhawk */
+ .driver_data = NVME_QUIRK_DISABLE_WRITE_ZEROES, },
++ { PCI_DEVICE(0x2646, 0x2263), /* KINGSTON A2000 NVMe SSD */
++ .driver_data = NVME_QUIRK_NO_DEEPEST_PS, },
+ { PCI_DEVICE(PCI_VENDOR_ID_APPLE, 0x2001),
+ .driver_data = NVME_QUIRK_SINGLE_VECTOR },
+ { PCI_DEVICE(PCI_VENDOR_ID_APPLE, 0x2003) },
xhci-fix-bounce-buffer-usage-for-non-sg-list-case.patch
risc-v-define-maxphysmem_1gb-only-for-rv32.patch
cifs-report-error-instead-of-invalid-when-revalidating-a-dentry-fails.patch
+iommu-check-dev-iommu-in-dev_iommu_priv_get-before-dereferencing-it.patch
+smb3-fix-out-of-bounds-bug-in-smb2_negotiate.patch
+smb3-fix-crediting-for-compounding-when-only-one-request-in-flight.patch
+mmc-sdhci-pltfm-fix-linking-err-for-sdhci-brcmstb.patch
+mmc-core-limit-retries-when-analyse-of-sdio-tuples-fails.patch
+fix-unsynchronized-access-to-sev-members-through-svm_register_enc_region.patch
+drm-dp-mst-export-drm_dp_get_vc_payload_bw.patch
+drm-i915-fix-the-mst-pbn-divider-calculation.patch
+drm-i915-gem-drop-lru-bumping-on-display-unpinning.patch
+drm-i915-gt-close-race-between-enable_breadcrumbs-and-cancel_breadcrumbs.patch
+drm-i915-display-prevent-double-yuv-range-correction-on-hdr-planes.patch
+drm-i915-extract-intel_ddi_power_up_lanes.patch
+drm-i915-power-up-combo-phy-lanes-for-for-hdmi-as-well.patch
+drm-amd-display-revert-fix-edid-parsing-after-resume-from-suspend.patch
+io_uring-don-t-modify-identity-s-files-uncess-identity-is-cowed.patch
+nvme-pci-avoid-the-deepest-sleep-state-on-kingston-a2000-ssds.patch
--- /dev/null
+From 91792bb8089b63b7b780251eb83939348ac58a64 Mon Sep 17 00:00:00 2001
+From: Pavel Shilovsky <pshilov@microsoft.com>
+Date: Tue, 2 Feb 2021 22:34:32 -0600
+Subject: smb3: fix crediting for compounding when only one request in flight
+
+From: Pavel Shilovsky <pshilov@microsoft.com>
+
+commit 91792bb8089b63b7b780251eb83939348ac58a64 upstream.
+
+Currently we try to guess if a compound request is going to
+succeed waiting for credits or not based on the number of
+requests in flight. This approach doesn't work correctly
+all the time because there may be only one request in
+flight which is going to bring multiple credits satisfying
+the compound request.
+
+Change the behavior to fail a request only if there are no requests
+in flight at all and proceed waiting for credits otherwise.
+
+Cc: <stable@vger.kernel.org> # 5.1+
+Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
+Reviewed-by: Tom Talpey <tom@talpey.com>
+Reviewed-by: Shyam Prasad N <nspmangalore@gmail.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/cifs/transport.c | 18 +++++++++++++++---
+ 1 file changed, 15 insertions(+), 3 deletions(-)
+
+--- a/fs/cifs/transport.c
++++ b/fs/cifs/transport.c
+@@ -655,10 +655,22 @@ wait_for_compound_request(struct TCP_Ser
+ spin_lock(&server->req_lock);
+ if (*credits < num) {
+ /*
+- * Return immediately if not too many requests in flight since
+- * we will likely be stuck on waiting for credits.
++ * If the server is tight on resources or just gives us less
++ * credits for other reasons (e.g. requests are coming out of
++ * order and the server delays granting more credits until it
++ * processes a missing mid) and we exhausted most available
++ * credits there may be situations when we try to send
++ * a compound request but we don't have enough credits. At this
++ * point the client needs to decide if it should wait for
++ * additional credits or fail the request. If at least one
++ * request is in flight there is a high probability that the
++ * server will return enough credits to satisfy this compound
++ * request.
++ *
++ * Return immediately if no requests in flight since we will be
++ * stuck on waiting for credits.
+ */
+- if (server->in_flight < num - *credits) {
++ if (server->in_flight == 0) {
+ spin_unlock(&server->req_lock);
+ return -ENOTSUPP;
+ }
--- /dev/null
+From 8d8d1dbefc423d42d626cf5b81aac214870ebaab Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
+Date: Mon, 1 Feb 2021 20:36:54 -0600
+Subject: smb3: Fix out-of-bounds bug in SMB2_negotiate()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Gustavo A. R. Silva <gustavoars@kernel.org>
+
+commit 8d8d1dbefc423d42d626cf5b81aac214870ebaab upstream.
+
+While addressing some warnings generated by -Warray-bounds, I found this
+bug that was introduced back in 2017:
+
+ CC [M] fs/cifs/smb2pdu.o
+fs/cifs/smb2pdu.c: In function ‘SMB2_negotiate’:
+fs/cifs/smb2pdu.c:822:16: warning: array subscript 1 is above array bounds
+of ‘__le16[1]’ {aka ‘short unsigned int[1]’} [-Warray-bounds]
+ 822 | req->Dialects[1] = cpu_to_le16(SMB30_PROT_ID);
+ | ~~~~~~~~~~~~~^~~
+fs/cifs/smb2pdu.c:823:16: warning: array subscript 2 is above array bounds
+of ‘__le16[1]’ {aka ‘short unsigned int[1]’} [-Warray-bounds]
+ 823 | req->Dialects[2] = cpu_to_le16(SMB302_PROT_ID);
+ | ~~~~~~~~~~~~~^~~
+fs/cifs/smb2pdu.c:824:16: warning: array subscript 3 is above array bounds
+of ‘__le16[1]’ {aka ‘short unsigned int[1]’} [-Warray-bounds]
+ 824 | req->Dialects[3] = cpu_to_le16(SMB311_PROT_ID);
+ | ~~~~~~~~~~~~~^~~
+fs/cifs/smb2pdu.c:816:16: warning: array subscript 1 is above array bounds
+of ‘__le16[1]’ {aka ‘short unsigned int[1]’} [-Warray-bounds]
+ 816 | req->Dialects[1] = cpu_to_le16(SMB302_PROT_ID);
+ | ~~~~~~~~~~~~~^~~
+
+At the time, the size of array _Dialects_ was changed from 1 to 3 in struct
+validate_negotiate_info_req, and then in 2019 it was changed from 3 to 4,
+but those changes were never made in struct smb2_negotiate_req, which has
+led to a 3 and a half years old out-of-bounds bug in function
+SMB2_negotiate() (fs/cifs/smb2pdu.c).
+
+Fix this by increasing the size of array _Dialects_ in struct
+smb2_negotiate_req to 4.
+
+Fixes: 9764c02fcbad ("SMB3: Add support for multidialect negotiate (SMB2.1 and later)")
+Fixes: d5c7076b772a ("smb3: add smb3.1.1 to default dialect list")
+Cc: stable@vger.kernel.org
+Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/cifs/smb2pdu.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/cifs/smb2pdu.h
++++ b/fs/cifs/smb2pdu.h
+@@ -286,7 +286,7 @@ struct smb2_negotiate_req {
+ __le32 NegotiateContextOffset; /* SMB3.1.1 only. MBZ earlier */
+ __le16 NegotiateContextCount; /* SMB3.1.1 only. MBZ earlier */
+ __le16 Reserved2;
+- __le16 Dialects[1]; /* One dialect (vers=) at a time for now */
++ __le16 Dialects[4]; /* BB expand this if autonegotiate > 4 dialects */
+ } __packed;
+
+ /* Dialects */
projects / thirdparty / kernel / stable-queue.git / commitdiff
