From: Greg Kroah-Hartman Date: Mon, 8 Feb 2021 10:47:41 +0000 (+0100) Subject: 5.10-stable patches X-Git-Tag: v4.4.257~26 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=2f1efa425b0127d60481821993ce0db3205cf271;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: drm-amd-display-revert-fix-edid-parsing-after-resume-from-suspend.patch drm-dp-mst-export-drm_dp_get_vc_payload_bw.patch drm-i915-display-prevent-double-yuv-range-correction-on-hdr-planes.patch drm-i915-extract-intel_ddi_power_up_lanes.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-power-up-combo-phy-lanes-for-for-hdmi-as-well.patch fix-unsynchronized-access-to-sev-members-through-svm_register_enc_region.patch io_uring-don-t-modify-identity-s-files-uncess-identity-is-cowed.patch iommu-check-dev-iommu-in-dev_iommu_priv_get-before-dereferencing-it.patch mmc-core-limit-retries-when-analyse-of-sdio-tuples-fails.patch mmc-sdhci-pltfm-fix-linking-err-for-sdhci-brcmstb.patch nvme-pci-avoid-the-deepest-sleep-state-on-kingston-a2000-ssds.patch smb3-fix-crediting-for-compounding-when-only-one-request-in-flight.patch smb3-fix-out-of-bounds-bug-in-smb2_negotiate.patch --- diff --git a/queue-5.10/drm-amd-display-revert-fix-edid-parsing-after-resume-from-suspend.patch b/queue-5.10/drm-amd-display-revert-fix-edid-parsing-after-resume-from-suspend.patch new file mode 100644 index 00000000000..a70b0b73de3 --- /dev/null +++ b/queue-5.10/drm-amd-display-revert-fix-edid-parsing-after-resume-from-suspend.patch @@ -0,0 +1,34 @@ +From 1a10e5244778169a5a53a527d7830cf0438132a1 Mon Sep 17 00:00:00 2001 +From: Stylon Wang +Date: Tue, 5 Jan 2021 11:29:34 +0800 +Subject: drm/amd/display: Revert "Fix EDID parsing after resume from suspend" + +From: Stylon Wang + +commit 1a10e5244778169a5a53a527d7830cf0438132a1 upstream. + +This reverts commit b24bdc37d03a0478189e20a50286092840f414fa. +It caused memory leak after S3 on 4K HDMI displays. + +Signed-off-by: Stylon Wang +Reviewed-by: Rodrigo Siqueira +Acked-by: Anson Jacob +Tested-by: Daniel Wheeler +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.10/drm-dp-mst-export-drm_dp_get_vc_payload_bw.patch b/queue-5.10/drm-dp-mst-export-drm_dp_get_vc_payload_bw.patch new file mode 100644 index 00000000000..94e954a7ce0 --- /dev/null +++ b/queue-5.10/drm-dp-mst-export-drm_dp_get_vc_payload_bw.patch @@ -0,0 +1,86 @@ +From 83404d581471775f37f85e5261ec0d09407d8bed Mon Sep 17 00:00:00 2001 +From: Imre Deak +Date: Mon, 25 Jan 2021 19:36:35 +0200 +Subject: drm/dp/mst: Export drm_dp_get_vc_payload_bw() + +From: Imre Deak + +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 +Cc: Ville Syrjala +Cc: +Cc: dri-devel@lists.freedesktop.org +Signed-off-by: Imre Deak +Reviewed-by: Lyude Paul +Link: https://patchwork.freedesktop.org/patch/msgid/20210125173636.1733812-1-imre.deak@intel.com +(cherry picked from commit a321fc2b4e60fc1b39517d26c8104351636a6062) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman +--- + 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); + diff --git a/queue-5.10/drm-i915-display-prevent-double-yuv-range-correction-on-hdr-planes.patch b/queue-5.10/drm-i915-display-prevent-double-yuv-range-correction-on-hdr-planes.patch new file mode 100644 index 00000000000..2c3aca05771 --- /dev/null +++ b/queue-5.10/drm-i915-display-prevent-double-yuv-range-correction-on-hdr-planes.patch @@ -0,0 +1,149 @@ +From 00f9a08fbc3c703b71842a5425c1eb82053c8a70 Mon Sep 17 00:00:00 2001 +From: Andres Calderon Jaramillo +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 + +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 +Signed-off-by: Ville Syrjälä +Link: https://patchwork.freedesktop.org/patch/msgid/20201215224219.3896256-1-andrescj@google.com +(cherry picked from commit fed387572040e84ead53852a7820e30a30e515d0) +Signed-off-by: Jani Nikula +Link: https://patchwork.freedesktop.org/patch/msgid/20210202084553.30691-1-ville.syrjala@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-5.10/drm-i915-extract-intel_ddi_power_up_lanes.patch b/queue-5.10/drm-i915-extract-intel_ddi_power_up_lanes.patch new file mode 100644 index 00000000000..ad583563a66 --- /dev/null +++ b/queue-5.10/drm-i915-extract-intel_ddi_power_up_lanes.patch @@ -0,0 +1,84 @@ +From 425cbd1fce10d4d68188123404d1a302a6939e0a Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= +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ä + +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ä +Link: https://patchwork.freedesktop.org/patch/msgid/20210128155948.13678-2-ville.syrjala@linux.intel.com +Reviewed-by: Imre Deak +(cherry picked from commit 5cdf706fb91a6e4e6af799bb957c4d598e6a067b) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-5.10/drm-i915-fix-the-mst-pbn-divider-calculation.patch b/queue-5.10/drm-i915-fix-the-mst-pbn-divider-calculation.patch new file mode 100644 index 00000000000..008f68c9286 --- /dev/null +++ b/queue-5.10/drm-i915-fix-the-mst-pbn-divider-calculation.patch @@ -0,0 +1,54 @@ +From 882554042d138dbc6fb1a43017d0b9c3b38ee5f5 Mon Sep 17 00:00:00 2001 +From: Imre Deak +Date: Mon, 25 Jan 2021 19:36:36 +0200 +Subject: drm/i915: Fix the MST PBN divider calculation + +From: Imre Deak + +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 +Cc: Ville Syrjala +Cc: +Signed-off-by: Imre Deak +Reviewed-by: Ville Syrjala +Link: https://patchwork.freedesktop.org/patch/msgid/20210125173636.1733812-2-imre.deak@intel.com +(cherry picked from commit b59c27cab257cfbff939615a87b72bce83925710) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-5.10/drm-i915-gem-drop-lru-bumping-on-display-unpinning.patch b/queue-5.10/drm-i915-gem-drop-lru-bumping-on-display-unpinning.patch new file mode 100644 index 00000000000..278b64e93a3 --- /dev/null +++ b/queue-5.10/drm-i915-gem-drop-lru-bumping-on-display-unpinning.patch @@ -0,0 +1,153 @@ +From 761c70a52586a9214b29026d384d2c01b73661a8 Mon Sep 17 00:00:00 2001 +From: Chris Wilson +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 + +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 +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 +Reviewed-by: Matthew Auld +Link: https://patchwork.freedesktop.org/patch/msgid/20210119214336.1463-6-chris@chris-wilson.co.uk +(cherry picked from commit 14ca83eece9565a2d2177291ceb122982dc38420) +Cc: Joonas Lahtinen +Cc: Jani Nikula +Cc: # v5.10+ +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.10/drm-i915-gt-close-race-between-enable_breadcrumbs-and-cancel_breadcrumbs.patch b/queue-5.10/drm-i915-gt-close-race-between-enable_breadcrumbs-and-cancel_breadcrumbs.patch new file mode 100644 index 00000000000..72301cfb9c5 --- /dev/null +++ b/queue-5.10/drm-i915-gt-close-race-between-enable_breadcrumbs-and-cancel_breadcrumbs.patch @@ -0,0 +1,60 @@ +From e4747cb3ec3c232d65c84cbe77633abd5871fda3 Mon Sep 17 00:00:00 2001 +From: Chris Wilson +Date: Tue, 19 Jan 2021 16:20:57 +0000 +Subject: drm/i915/gt: Close race between enable_breadcrumbs and cancel_breadcrumbs + +From: Chris Wilson + +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 +Cc: Tvrtko Ursulin +Cc: Andi Shyti +Cc: # v5.10+ +Reviewed-by: Tvrtko Ursulin +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.10/drm-i915-power-up-combo-phy-lanes-for-for-hdmi-as-well.patch b/queue-5.10/drm-i915-power-up-combo-phy-lanes-for-for-hdmi-as-well.patch new file mode 100644 index 00000000000..ddc12573e41 --- /dev/null +++ b/queue-5.10/drm-i915-power-up-combo-phy-lanes-for-for-hdmi-as-well.patch @@ -0,0 +1,37 @@ +From fad9bae9ee5d578afbe6380c82e4715efaddf118 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= +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ä + +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ä +Link: https://patchwork.freedesktop.org/patch/msgid/20210128155948.13678-3-ville.syrjala@linux.intel.com +Reviewed-by: Imre Deak +(cherry picked from commit 1e0cb7bef35f0d1aed383bf69a209df218b807c9) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman +--- + 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. diff --git a/queue-5.10/fix-unsynchronized-access-to-sev-members-through-svm_register_enc_region.patch b/queue-5.10/fix-unsynchronized-access-to-sev-members-through-svm_register_enc_region.patch new file mode 100644 index 00000000000..e6ccfb98f21 --- /dev/null +++ b/queue-5.10/fix-unsynchronized-access-to-sev-members-through-svm_register_enc_region.patch @@ -0,0 +1,91 @@ +From 19a23da53932bc8011220bd8c410cb76012de004 Mon Sep 17 00:00:00 2001 +From: Peter Gonda +Date: Wed, 27 Jan 2021 08:15:24 -0800 +Subject: Fix unsynchronized access to sev members through svm_register_enc_region + +From: Peter Gonda + +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 +Cc: Ingo Molnar +Cc: "H. Peter Anvin" +Cc: Paolo Bonzini +Cc: Joerg Roedel +Cc: Tom Lendacky +Cc: Brijesh Singh +Cc: Sean Christopherson +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 +Signed-off-by: Greg Kroah-Hartman + +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 +--- + 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: diff --git a/queue-5.10/io_uring-don-t-modify-identity-s-files-uncess-identity-is-cowed.patch b/queue-5.10/io_uring-don-t-modify-identity-s-files-uncess-identity-is-cowed.patch new file mode 100644 index 00000000000..9c6cf5bd6cd --- /dev/null +++ b/queue-5.10/io_uring-don-t-modify-identity-s-files-uncess-identity-is-cowed.patch @@ -0,0 +1,81 @@ +From d7e10d47691d1702db1cd1edcc689d3031eefc67 Mon Sep 17 00:00:00 2001 +From: Xiaoguang Wang +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 + +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 +Signed-off-by: Xiaoguang Wang +Reviewed-by: Pavel Begunkov +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } + } diff --git a/queue-5.10/iommu-check-dev-iommu-in-dev_iommu_priv_get-before-dereferencing-it.patch b/queue-5.10/iommu-check-dev-iommu-in-dev_iommu_priv_get-before-dereferencing-it.patch new file mode 100644 index 00000000000..13f15329653 --- /dev/null +++ b/queue-5.10/iommu-check-dev-iommu-in-dev_iommu_priv_get-before-dereferencing-it.patch @@ -0,0 +1,36 @@ +From 4c9fb5d9140802db4db9f66c23887f43174e113c Mon Sep 17 00:00:00 2001 +From: Joerg Roedel +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 + +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-5.10/mmc-core-limit-retries-when-analyse-of-sdio-tuples-fails.patch b/queue-5.10/mmc-core-limit-retries-when-analyse-of-sdio-tuples-fails.patch new file mode 100644 index 00000000000..9d7d3bb384a --- /dev/null +++ b/queue-5.10/mmc-core-limit-retries-when-analyse-of-sdio-tuples-fails.patch @@ -0,0 +1,50 @@ +From f92e04f764b86e55e522988e6f4b6082d19a2721 Mon Sep 17 00:00:00 2001 +From: Fengnan Chang +Date: Sat, 23 Jan 2021 11:32:31 +0800 +Subject: mmc: core: Limit retries when analyse of SDIO tuples fails + +From: Fengnan Chang + +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 +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20210123033230.36442-1-fengnanchang@gmail.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + 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", diff --git a/queue-5.10/mmc-sdhci-pltfm-fix-linking-err-for-sdhci-brcmstb.patch b/queue-5.10/mmc-sdhci-pltfm-fix-linking-err-for-sdhci-brcmstb.patch new file mode 100644 index 00000000000..ded4215c4a4 --- /dev/null +++ b/queue-5.10/mmc-sdhci-pltfm-fix-linking-err-for-sdhci-brcmstb.patch @@ -0,0 +1,46 @@ +From d7fb9c24209556478e65211d7a1f056f2d43cceb Mon Sep 17 00:00:00 2001 +From: Ulf Hansson +Date: Tue, 26 Jan 2021 10:43:13 +0100 +Subject: mmc: sdhci-pltfm: Fix linking err for sdhci-brcmstb + +From: Ulf Hansson + +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 +Suggested-by: Florian Fainelli +Fixes: 5b191dcba719 ("mmc: sdhci-brcmstb: Fix mmc timeout errors on S5 suspend") +Cc: stable@vger.kernel.org +Tested-By: Nicolas Schichan +Acked-by: Arnd Bergmann +Acked-by: Florian Fainelli +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + 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 */ diff --git a/queue-5.10/nvme-pci-avoid-the-deepest-sleep-state-on-kingston-a2000-ssds.patch b/queue-5.10/nvme-pci-avoid-the-deepest-sleep-state-on-kingston-a2000-ssds.patch new file mode 100644 index 00000000000..ae0943ea989 --- /dev/null +++ b/queue-5.10/nvme-pci-avoid-the-deepest-sleep-state-on-kingston-a2000-ssds.patch @@ -0,0 +1,81 @@ +From 538e4a8c571efdf131834431e0c14808bcfb1004 Mon Sep 17 00:00:00 2001 +From: Thorsten Leemhuis +Date: Fri, 29 Jan 2021 06:24:42 +0100 +Subject: nvme-pci: avoid the deepest sleep state on Kingston A2000 SSDs + +From: Thorsten Leemhuis + +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 +Signed-off-by: Christoph Hellwig +Signed-off-by: Greg Kroah-Hartman +--- + 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) }, diff --git a/queue-5.10/series b/queue-5.10/series index cd4743e23eb..14a2f0c7424 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -69,3 +69,19 @@ scripts-use-pkg-config-to-locate-libcrypto.patch 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 diff --git a/queue-5.10/smb3-fix-crediting-for-compounding-when-only-one-request-in-flight.patch b/queue-5.10/smb3-fix-crediting-for-compounding-when-only-one-request-in-flight.patch new file mode 100644 index 00000000000..ebe484a6b38 --- /dev/null +++ b/queue-5.10/smb3-fix-crediting-for-compounding-when-only-one-request-in-flight.patch @@ -0,0 +1,57 @@ +From 91792bb8089b63b7b780251eb83939348ac58a64 Mon Sep 17 00:00:00 2001 +From: Pavel Shilovsky +Date: Tue, 2 Feb 2021 22:34:32 -0600 +Subject: smb3: fix crediting for compounding when only one request in flight + +From: Pavel Shilovsky + +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: # 5.1+ +Signed-off-by: Pavel Shilovsky +Reviewed-by: Tom Talpey +Reviewed-by: Shyam Prasad N +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-5.10/smb3-fix-out-of-bounds-bug-in-smb2_negotiate.patch b/queue-5.10/smb3-fix-out-of-bounds-bug-in-smb2_negotiate.patch new file mode 100644 index 00000000000..ea2a17521ef --- /dev/null +++ b/queue-5.10/smb3-fix-out-of-bounds-bug-in-smb2_negotiate.patch @@ -0,0 +1,64 @@ +From 8d8d1dbefc423d42d626cf5b81aac214870ebaab Mon Sep 17 00:00:00 2001 +From: "Gustavo A. R. Silva" +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 + +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 +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + 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 */