From: Greg Kroah-Hartman Date: Sun, 5 Nov 2017 15:25:18 +0000 (+0100) Subject: 4.9-stable patches X-Git-Tag: v3.18.80~16 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=d4c3a0ae8c4b3a82736d7cd94ac0530c4092b8d9;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: drm-amdgpu-return-enoent-from-uvd-6.0-early-init-for-harvesting.patch drm-i915-edp-read-edp-display-control-registers-unconditionally.patch ocfs2-fstrim-fix-start-offset-of-first-cluster-group-during-fstrim.patch --- diff --git a/queue-4.9/drm-amdgpu-return-enoent-from-uvd-6.0-early-init-for-harvesting.patch b/queue-4.9/drm-amdgpu-return-enoent-from-uvd-6.0-early-init-for-harvesting.patch new file mode 100644 index 00000000000..006c14061e6 --- /dev/null +++ b/queue-4.9/drm-amdgpu-return-enoent-from-uvd-6.0-early-init-for-harvesting.patch @@ -0,0 +1,33 @@ +From cb4b02d7cac56a69d8137d8d843507cca9182aed Mon Sep 17 00:00:00 2001 +From: Leo Liu +Date: Tue, 31 Oct 2017 21:03:39 -0400 +Subject: drm/amdgpu: return -ENOENT from uvd 6.0 early init for harvesting + +From: Leo Liu + +commit cb4b02d7cac56a69d8137d8d843507cca9182aed upstream. + +Fixes init failures on polaris cards with harvested UVD. + +Signed-off-by: Leo Liu +Reviewed-by: Alex Deucher +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c ++++ b/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c +@@ -89,6 +89,10 @@ static int uvd_v6_0_early_init(void *han + { + struct amdgpu_device *adev = (struct amdgpu_device *)handle; + ++ if (!(adev->flags & AMD_IS_APU) && ++ (RREG32_SMC(ixCC_HARVEST_FUSES) & CC_HARVEST_FUSES__UVD_DISABLE_MASK)) ++ return -ENOENT; ++ + uvd_v6_0_set_ring_funcs(adev); + uvd_v6_0_set_irq_funcs(adev); + diff --git a/queue-4.9/drm-i915-edp-read-edp-display-control-registers-unconditionally.patch b/queue-4.9/drm-i915-edp-read-edp-display-control-registers-unconditionally.patch new file mode 100644 index 00000000000..fb22078ce6a --- /dev/null +++ b/queue-4.9/drm-i915-edp-read-edp-display-control-registers-unconditionally.patch @@ -0,0 +1,69 @@ +From 7c838e2a9be5ab79b11c7f1520813bfdf0f45462 Mon Sep 17 00:00:00 2001 +From: Jani Nikula +Date: Thu, 26 Oct 2017 17:29:31 +0300 +Subject: drm/i915/edp: read edp display control registers unconditionally +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Jani Nikula + +commit 7c838e2a9be5ab79b11c7f1520813bfdf0f45462 upstream. + +Per my reading of the eDP spec, DP_DPCD_DISPLAY_CONTROL_CAPABLE bit in +DP_EDP_CONFIGURATION_CAP should be set if the eDP display control +registers starting at offset DP_EDP_DPCD_REV are "enabled". Currently we +check the bit before reading the registers, and DP_EDP_DPCD_REV is the +only way to detect eDP revision. + +Turns out there are (likely buggy) displays that require eDP 1.4+ +features, such as supported link rates and link rate select, but do not +have the bit set. Read the display control registers +unconditionally. They are supposed to read zero anyway if they are not +supported, so there should be no harm in this. + +This fixes the referenced bug by enabling the eDP version check, and +thus reading of the supported link rates. The panel in question has 0 in +DP_MAX_LINK_RATE which is only supported in eDP 1.4+. Without the +supported link rates method we default to RBR which is insufficient for +the panel native mode. As a curiosity, the panel also has a bogus value +of 0x12 in DP_EDP_DPCD_REV, but that passes our check for >= DP_EDP_14 +(which is 0x03). + +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103400 +Reported-and-tested-by: Nicolas P. +Cc: Ville Syrjälä +Reviewed-by: Ville Syrjälä +Reviewed-by: Manasi Navare +Signed-off-by: Jani Nikula +Link: https://patchwork.freedesktop.org/patch/msgid/20171026142932.17737-1-jani.nikula@intel.com +(cherry picked from commit 0501a3b0eb01ac2209ef6fce76153e5d6b07034e) +Signed-off-by: Rodrigo Vivi +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_dp.c | 13 ++++++++++--- + 1 file changed, 10 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/i915/intel_dp.c ++++ b/drivers/gpu/drm/i915/intel_dp.c +@@ -3558,9 +3558,16 @@ intel_edp_init_dpcd(struct intel_dp *int + dev_priv->psr.psr2_support ? "supported" : "not supported"); + } + +- /* Read the eDP Display control capabilities registers */ +- if ((intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] & DP_DPCD_DISPLAY_CONTROL_CAPABLE) && +- drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_DPCD_REV, ++ /* ++ * Read the eDP display control registers. ++ * ++ * Do this independent of DP_DPCD_DISPLAY_CONTROL_CAPABLE bit in ++ * DP_EDP_CONFIGURATION_CAP, because some buggy displays do not have it ++ * set, but require eDP 1.4+ detection (e.g. for supported link rates ++ * method). The display control registers should read zero if they're ++ * not supported anyway. ++ */ ++ if (drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_DPCD_REV, + intel_dp->edp_dpcd, sizeof(intel_dp->edp_dpcd)) == + sizeof(intel_dp->edp_dpcd)) + DRM_DEBUG_KMS("EDP DPCD : %*ph\n", (int) sizeof(intel_dp->edp_dpcd), diff --git a/queue-4.9/ocfs2-fstrim-fix-start-offset-of-first-cluster-group-during-fstrim.patch b/queue-4.9/ocfs2-fstrim-fix-start-offset-of-first-cluster-group-during-fstrim.patch new file mode 100644 index 00000000000..d1f848e4ed2 --- /dev/null +++ b/queue-4.9/ocfs2-fstrim-fix-start-offset-of-first-cluster-group-during-fstrim.patch @@ -0,0 +1,89 @@ +From 105ddc93f06ebe3e553f58563d11ed63dbcd59f0 Mon Sep 17 00:00:00 2001 +From: Ashish Samant +Date: Thu, 2 Nov 2017 15:59:37 -0700 +Subject: ocfs2: fstrim: Fix start offset of first cluster group during fstrim + +From: Ashish Samant + +commit 105ddc93f06ebe3e553f58563d11ed63dbcd59f0 upstream. + +The first cluster group descriptor is not stored at the start of the +group but at an offset from the start. We need to take this into +account while doing fstrim on the first cluster group. Otherwise we +will wrongly start fstrim a few blocks after the desired start block and +the range can cross over into the next cluster group and zero out the +group descriptor there. This can cause filesytem corruption that cannot +be fixed by fsck. + +Link: http://lkml.kernel.org/r/1507835579-7308-1-git-send-email-ashish.samant@oracle.com +Signed-off-by: Ashish Samant +Reviewed-by: Junxiao Bi +Reviewed-by: Joseph Qi +Cc: Mark Fasheh +Cc: Joel Becker +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ocfs2/alloc.c | 24 ++++++++++++++++++------ + 1 file changed, 18 insertions(+), 6 deletions(-) + +--- a/fs/ocfs2/alloc.c ++++ b/fs/ocfs2/alloc.c +@@ -7310,13 +7310,24 @@ out: + + static int ocfs2_trim_extent(struct super_block *sb, + struct ocfs2_group_desc *gd, +- u32 start, u32 count) ++ u64 group, u32 start, u32 count) + { + u64 discard, bcount; ++ struct ocfs2_super *osb = OCFS2_SB(sb); + + bcount = ocfs2_clusters_to_blocks(sb, count); +- discard = le64_to_cpu(gd->bg_blkno) + +- ocfs2_clusters_to_blocks(sb, start); ++ discard = ocfs2_clusters_to_blocks(sb, start); ++ ++ /* ++ * For the first cluster group, the gd->bg_blkno is not at the start ++ * of the group, but at an offset from the start. If we add it while ++ * calculating discard for first group, we will wrongly start fstrim a ++ * few blocks after the desried start block and the range can cross ++ * over into the next cluster group. So, add it only if this is not ++ * the first cluster group. ++ */ ++ if (group != osb->first_cluster_group_blkno) ++ discard += le64_to_cpu(gd->bg_blkno); + + trace_ocfs2_trim_extent(sb, (unsigned long long)discard, bcount); + +@@ -7324,7 +7335,7 @@ static int ocfs2_trim_extent(struct supe + } + + static int ocfs2_trim_group(struct super_block *sb, +- struct ocfs2_group_desc *gd, ++ struct ocfs2_group_desc *gd, u64 group, + u32 start, u32 max, u32 minbits) + { + int ret = 0, count = 0, next; +@@ -7343,7 +7354,7 @@ static int ocfs2_trim_group(struct super + next = ocfs2_find_next_bit(bitmap, max, start); + + if ((next - start) >= minbits) { +- ret = ocfs2_trim_extent(sb, gd, ++ ret = ocfs2_trim_extent(sb, gd, group, + start, next - start); + if (ret < 0) { + mlog_errno(ret); +@@ -7441,7 +7452,8 @@ int ocfs2_trim_fs(struct super_block *sb + } + + gd = (struct ocfs2_group_desc *)gd_bh->b_data; +- cnt = ocfs2_trim_group(sb, gd, first_bit, last_bit, minlen); ++ cnt = ocfs2_trim_group(sb, gd, group, ++ first_bit, last_bit, minlen); + brelse(gd_bh); + gd_bh = NULL; + if (cnt < 0) { diff --git a/queue-4.9/series b/queue-4.9/series index 0eab8330e2f..d46560a717f 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -8,3 +8,6 @@ arm64-ensure-__dump_instr-checks-addr_limit.patch arm-arm64-kvm-set-right-lr-register-value-for-32-bit-guest-when-inject-abort.patch arm-arm64-kvm-disable-branch-profiling-in-hyp-code.patch arm-8715-1-add-a-private-asm-unaligned.h.patch +drm-amdgpu-return-enoent-from-uvd-6.0-early-init-for-harvesting.patch +ocfs2-fstrim-fix-start-offset-of-first-cluster-group-during-fstrim.patch +drm-i915-edp-read-edp-display-control-registers-unconditionally.patch