From 6b548ed8d81101ec012fbb3065a9d987b8c68a8e Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Thu, 11 Feb 2021 15:22:51 +0100 Subject: [PATCH] 5.10-stable patches added patches: bpf-fix-32-bit-src-register-truncation-on-div-mod.patch bpf-fix-verifier-jmp32-pruning-decision-logic.patch bpf-fix-verifier-jsgt-branch-analysis-on-max-bound.patch drm-i915-fix-icl-mg-phy-vswing-handling.patch drm-i915-skip-vswing-programming-for-tbt.patch --- ...t-src-register-truncation-on-div-mod.patch | 128 ++++++++++++++++ ...erifier-jmp32-pruning-decision-logic.patch | 145 ++++++++++++++++++ ...er-jsgt-branch-analysis-on-max-bound.patch | 50 ++++++ ...-i915-fix-icl-mg-phy-vswing-handling.patch | 52 +++++++ ...i915-skip-vswing-programming-for-tbt.patch | 53 +++++++ queue-5.10/series | 5 + 6 files changed, 433 insertions(+) create mode 100644 queue-5.10/bpf-fix-32-bit-src-register-truncation-on-div-mod.patch create mode 100644 queue-5.10/bpf-fix-verifier-jmp32-pruning-decision-logic.patch create mode 100644 queue-5.10/bpf-fix-verifier-jsgt-branch-analysis-on-max-bound.patch create mode 100644 queue-5.10/drm-i915-fix-icl-mg-phy-vswing-handling.patch create mode 100644 queue-5.10/drm-i915-skip-vswing-programming-for-tbt.patch diff --git a/queue-5.10/bpf-fix-32-bit-src-register-truncation-on-div-mod.patch b/queue-5.10/bpf-fix-32-bit-src-register-truncation-on-div-mod.patch new file mode 100644 index 00000000000..b1889c3dd95 --- /dev/null +++ b/queue-5.10/bpf-fix-32-bit-src-register-truncation-on-div-mod.patch @@ -0,0 +1,128 @@ +From e88b2c6e5a4d9ce30d75391e4d950da74bb2bd90 Mon Sep 17 00:00:00 2001 +From: Daniel Borkmann +Date: Tue, 9 Feb 2021 18:46:10 +0000 +Subject: bpf: Fix 32 bit src register truncation on div/mod + +From: Daniel Borkmann + +commit e88b2c6e5a4d9ce30d75391e4d950da74bb2bd90 upstream. + +While reviewing a different fix, John and I noticed an oddity in one of the +BPF program dumps that stood out, for example: + + # bpftool p d x i 13 + 0: (b7) r0 = 808464450 + 1: (b4) w4 = 808464432 + 2: (bc) w0 = w0 + 3: (15) if r0 == 0x0 goto pc+1 + 4: (9c) w4 %= w0 + [...] + +In line 2 we noticed that the mov32 would 32 bit truncate the original src +register for the div/mod operation. While for the two operations the dst +register is typically marked unknown e.g. from adjust_scalar_min_max_vals() +the src register is not, and thus verifier keeps tracking original bounds, +simplified: + + 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 + 0: (b7) r0 = -1 + 1: R0_w=invP-1 R1=ctx(id=0,off=0,imm=0) R10=fp0 + 1: (b7) r1 = -1 + 2: R0_w=invP-1 R1_w=invP-1 R10=fp0 + 2: (3c) w0 /= w1 + 3: R0_w=invP(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) R1_w=invP-1 R10=fp0 + 3: (77) r1 >>= 32 + 4: R0_w=invP(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) R1_w=invP4294967295 R10=fp0 + 4: (bf) r0 = r1 + 5: R0_w=invP4294967295 R1_w=invP4294967295 R10=fp0 + 5: (95) exit + processed 6 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0 + +Runtime result of r0 at exit is 0 instead of expected -1. Remove the +verifier mov32 src rewrite in div/mod and replace it with a jmp32 test +instead. After the fix, we result in the following code generation when +having dividend r1 and divisor r6: + + div, 64 bit: div, 32 bit: + + 0: (b7) r6 = 8 0: (b7) r6 = 8 + 1: (b7) r1 = 8 1: (b7) r1 = 8 + 2: (55) if r6 != 0x0 goto pc+2 2: (56) if w6 != 0x0 goto pc+2 + 3: (ac) w1 ^= w1 3: (ac) w1 ^= w1 + 4: (05) goto pc+1 4: (05) goto pc+1 + 5: (3f) r1 /= r6 5: (3c) w1 /= w6 + 6: (b7) r0 = 0 6: (b7) r0 = 0 + 7: (95) exit 7: (95) exit + + mod, 64 bit: mod, 32 bit: + + 0: (b7) r6 = 8 0: (b7) r6 = 8 + 1: (b7) r1 = 8 1: (b7) r1 = 8 + 2: (15) if r6 == 0x0 goto pc+1 2: (16) if w6 == 0x0 goto pc+1 + 3: (9f) r1 %= r6 3: (9c) w1 %= w6 + 4: (b7) r0 = 0 4: (b7) r0 = 0 + 5: (95) exit 5: (95) exit + +x86 in particular can throw a 'divide error' exception for div +instruction not only for divisor being zero, but also for the case +when the quotient is too large for the designated register. For the +edx:eax and rdx:rax dividend pair it is not an issue in x86 BPF JIT +since we always zero edx (rdx). Hence really the only protection +needed is against divisor being zero. + +Fixes: 68fda450a7df ("bpf: fix 32-bit divide by zero") +Co-developed-by: John Fastabend +Signed-off-by: John Fastabend +Signed-off-by: Daniel Borkmann +Acked-by: Alexei Starovoitov +Signed-off-by: Greg Kroah-Hartman +--- + kernel/bpf/verifier.c | 28 +++++++++++++--------------- + 1 file changed, 13 insertions(+), 15 deletions(-) + +--- a/kernel/bpf/verifier.c ++++ b/kernel/bpf/verifier.c +@@ -10866,30 +10866,28 @@ static int fixup_bpf_calls(struct bpf_ve + insn->code == (BPF_ALU | BPF_MOD | BPF_X) || + insn->code == (BPF_ALU | BPF_DIV | BPF_X)) { + bool is64 = BPF_CLASS(insn->code) == BPF_ALU64; +- struct bpf_insn mask_and_div[] = { +- BPF_MOV32_REG(insn->src_reg, insn->src_reg), ++ bool isdiv = BPF_OP(insn->code) == BPF_DIV; ++ struct bpf_insn *patchlet; ++ struct bpf_insn chk_and_div[] = { + /* Rx div 0 -> 0 */ +- BPF_JMP_IMM(BPF_JNE, insn->src_reg, 0, 2), ++ BPF_RAW_INSN((is64 ? BPF_JMP : BPF_JMP32) | ++ BPF_JNE | BPF_K, insn->src_reg, ++ 0, 2, 0), + BPF_ALU32_REG(BPF_XOR, insn->dst_reg, insn->dst_reg), + BPF_JMP_IMM(BPF_JA, 0, 0, 1), + *insn, + }; +- struct bpf_insn mask_and_mod[] = { +- BPF_MOV32_REG(insn->src_reg, insn->src_reg), ++ struct bpf_insn chk_and_mod[] = { + /* Rx mod 0 -> Rx */ +- BPF_JMP_IMM(BPF_JEQ, insn->src_reg, 0, 1), ++ BPF_RAW_INSN((is64 ? BPF_JMP : BPF_JMP32) | ++ BPF_JEQ | BPF_K, insn->src_reg, ++ 0, 1, 0), + *insn, + }; +- struct bpf_insn *patchlet; + +- if (insn->code == (BPF_ALU64 | BPF_DIV | BPF_X) || +- insn->code == (BPF_ALU | BPF_DIV | BPF_X)) { +- patchlet = mask_and_div + (is64 ? 1 : 0); +- cnt = ARRAY_SIZE(mask_and_div) - (is64 ? 1 : 0); +- } else { +- patchlet = mask_and_mod + (is64 ? 1 : 0); +- cnt = ARRAY_SIZE(mask_and_mod) - (is64 ? 1 : 0); +- } ++ patchlet = isdiv ? chk_and_div : chk_and_mod; ++ cnt = isdiv ? ARRAY_SIZE(chk_and_div) : ++ ARRAY_SIZE(chk_and_mod); + + new_prog = bpf_patch_insn_data(env, i + delta, patchlet, cnt); + if (!new_prog) diff --git a/queue-5.10/bpf-fix-verifier-jmp32-pruning-decision-logic.patch b/queue-5.10/bpf-fix-verifier-jmp32-pruning-decision-logic.patch new file mode 100644 index 00000000000..922afb7d7db --- /dev/null +++ b/queue-5.10/bpf-fix-verifier-jmp32-pruning-decision-logic.patch @@ -0,0 +1,145 @@ +From fd675184fc7abfd1e1c52d23e8e900676b5a1c1a Mon Sep 17 00:00:00 2001 +From: Daniel Borkmann +Date: Fri, 5 Feb 2021 20:48:21 +0100 +Subject: bpf: Fix verifier jmp32 pruning decision logic + +From: Daniel Borkmann + +commit fd675184fc7abfd1e1c52d23e8e900676b5a1c1a upstream. + +Anatoly has been fuzzing with kBdysch harness and reported a hang in +one of the outcomes: + + func#0 @0 + 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 + 0: (b7) r0 = 808464450 + 1: R0_w=invP808464450 R1=ctx(id=0,off=0,imm=0) R10=fp0 + 1: (b4) w4 = 808464432 + 2: R0_w=invP808464450 R1=ctx(id=0,off=0,imm=0) R4_w=invP808464432 R10=fp0 + 2: (9c) w4 %= w0 + 3: R0_w=invP808464450 R1=ctx(id=0,off=0,imm=0) R4_w=invP(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) R10=fp0 + 3: (66) if w4 s> 0x30303030 goto pc+0 + R0_w=invP808464450 R1=ctx(id=0,off=0,imm=0) R4_w=invP(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff),s32_max_value=808464432) R10=fp0 + 4: R0_w=invP808464450 R1=ctx(id=0,off=0,imm=0) R4_w=invP(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff),s32_max_value=808464432) R10=fp0 + 4: (7f) r0 >>= r0 + 5: R0_w=invP(id=0) R1=ctx(id=0,off=0,imm=0) R4_w=invP(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff),s32_max_value=808464432) R10=fp0 + 5: (9c) w4 %= w0 + 6: R0_w=invP(id=0) R1=ctx(id=0,off=0,imm=0) R4_w=invP(id=0) R10=fp0 + 6: (66) if w0 s> 0x3030 goto pc+0 + R0_w=invP(id=0,s32_max_value=12336) R1=ctx(id=0,off=0,imm=0) R4_w=invP(id=0) R10=fp0 + 7: R0=invP(id=0,s32_max_value=12336) R1=ctx(id=0,off=0,imm=0) R4=invP(id=0) R10=fp0 + 7: (d6) if w0 s<= 0x303030 goto pc+1 + 9: R0=invP(id=0,s32_max_value=12336) R1=ctx(id=0,off=0,imm=0) R4=invP(id=0) R10=fp0 + 9: (95) exit + propagating r0 + + from 6 to 7: safe + 4: R0_w=invP808464450 R1=ctx(id=0,off=0,imm=0) R4_w=invP(id=0,umin_value=808464433,umax_value=2147483647,var_off=(0x0; 0x7fffffff)) R10=fp0 + 4: (7f) r0 >>= r0 + 5: R0_w=invP(id=0) R1=ctx(id=0,off=0,imm=0) R4_w=invP(id=0,umin_value=808464433,umax_value=2147483647,var_off=(0x0; 0x7fffffff)) R10=fp0 + 5: (9c) w4 %= w0 + 6: R0_w=invP(id=0) R1=ctx(id=0,off=0,imm=0) R4_w=invP(id=0) R10=fp0 + 6: (66) if w0 s> 0x3030 goto pc+0 + R0_w=invP(id=0,s32_max_value=12336) R1=ctx(id=0,off=0,imm=0) R4_w=invP(id=0) R10=fp0 + propagating r0 + 7: safe + propagating r0 + + from 6 to 7: safe + processed 15 insns (limit 1000000) max_states_per_insn 0 total_states 1 peak_states 1 mark_read 1 + +The underlying program was xlated as follows: + + # bpftool p d x i 10 + 0: (b7) r0 = 808464450 + 1: (b4) w4 = 808464432 + 2: (bc) w0 = w0 + 3: (15) if r0 == 0x0 goto pc+1 + 4: (9c) w4 %= w0 + 5: (66) if w4 s> 0x30303030 goto pc+0 + 6: (7f) r0 >>= r0 + 7: (bc) w0 = w0 + 8: (15) if r0 == 0x0 goto pc+1 + 9: (9c) w4 %= w0 + 10: (66) if w0 s> 0x3030 goto pc+0 + 11: (d6) if w0 s<= 0x303030 goto pc+1 + 12: (05) goto pc-1 + 13: (95) exit + +The verifier rewrote original instructions it recognized as dead code with +'goto pc-1', but reality differs from verifier simulation in that we are +actually able to trigger a hang due to hitting the 'goto pc-1' instructions. + +Taking a closer look at the verifier analysis, the reason is that it misjudges +its pruning decision at the first 'from 6 to 7: safe' occasion. What happens +is that while both old/cur registers are marked as precise, they get misjudged +for the jmp32 case as range_within() yields true, meaning that the prior +verification path with a wider register bound could be verified successfully +and therefore the current path with a narrower register bound is deemed safe +as well whereas in reality it's not. R0 old/cur path's bounds compare as +follows: + + old: smin_value=0x8000000000000000,smax_value=0x7fffffffffffffff,umin_value=0x0,umax_value=0xffffffffffffffff,var_off=(0x0; 0xffffffffffffffff) + cur: smin_value=0x8000000000000000,smax_value=0x7fffffff7fffffff,umin_value=0x0,umax_value=0xffffffff7fffffff,var_off=(0x0; 0xffffffff7fffffff) + + old: s32_min_value=0x80000000,s32_max_value=0x00003030,u32_min_value=0x00000000,u32_max_value=0xffffffff + cur: s32_min_value=0x00003031,s32_max_value=0x7fffffff,u32_min_value=0x00003031,u32_max_value=0x7fffffff + +The 64 bit bounds generally look okay and while the information that got +propagated from 32 to 64 bit looks correct as well, it's not precise enough +for judging a conditional jmp32. Given the latter only operates on subregisters +we also need to take these into account as well for a range_within() probe +in order to be able to prune paths. Extending the range_within() constraint +to both bounds will be able to tell us that the old signed 32 bit bounds are +not wider than the cur signed 32 bit bounds. + +With the fix in place, the program will now verify the 'goto' branch case as +it should have been: + + [...] + 6: R0_w=invP(id=0) R1=ctx(id=0,off=0,imm=0) R4_w=invP(id=0) R10=fp0 + 6: (66) if w0 s> 0x3030 goto pc+0 + R0_w=invP(id=0,s32_max_value=12336) R1=ctx(id=0,off=0,imm=0) R4_w=invP(id=0) R10=fp0 + 7: R0=invP(id=0,s32_max_value=12336) R1=ctx(id=0,off=0,imm=0) R4=invP(id=0) R10=fp0 + 7: (d6) if w0 s<= 0x303030 goto pc+1 + 9: R0=invP(id=0,s32_max_value=12336) R1=ctx(id=0,off=0,imm=0) R4=invP(id=0) R10=fp0 + 9: (95) exit + + 7: R0_w=invP(id=0,smax_value=9223372034707292159,umax_value=18446744071562067967,var_off=(0x0; 0xffffffff7fffffff),s32_min_value=12337,u32_min_value=12337,u32_max_value=2147483647) R1=ctx(id=0,off=0,imm=0) R4_w=invP(id=0) R10=fp0 + 7: (d6) if w0 s<= 0x303030 goto pc+1 + R0_w=invP(id=0,smax_value=9223372034707292159,umax_value=18446744071562067967,var_off=(0x0; 0xffffffff7fffffff),s32_min_value=3158065,u32_min_value=3158065,u32_max_value=2147483647) R1=ctx(id=0,off=0,imm=0) R4_w=invP(id=0) R10=fp0 + 8: R0_w=invP(id=0,smax_value=9223372034707292159,umax_value=18446744071562067967,var_off=(0x0; 0xffffffff7fffffff),s32_min_value=3158065,u32_min_value=3158065,u32_max_value=2147483647) R1=ctx(id=0,off=0,imm=0) R4_w=invP(id=0) R10=fp0 + 8: (30) r0 = *(u8 *)skb[808464432] + BPF_LD_[ABS|IND] uses reserved fields + processed 11 insns (limit 1000000) max_states_per_insn 1 total_states 1 peak_states 1 mark_read 1 + +The bug is quite subtle in the sense that when verifier would determine that +a given branch is dead code, it would (here: wrongly) remove these instructions +from the program and hard-wire the taken branch for privileged programs instead +of the 'goto pc-1' rewrites which will cause hard to debug problems. + +Fixes: 3f50f132d840 ("bpf: Verifier, do explicit ALU32 bounds tracking") +Reported-by: Anatoly Trosinenko +Signed-off-by: Daniel Borkmann +Reviewed-by: John Fastabend +Acked-by: Alexei Starovoitov +Signed-off-by: Greg Kroah-Hartman +--- + kernel/bpf/verifier.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/kernel/bpf/verifier.c ++++ b/kernel/bpf/verifier.c +@@ -8465,7 +8465,11 @@ static bool range_within(struct bpf_reg_ + return old->umin_value <= cur->umin_value && + old->umax_value >= cur->umax_value && + old->smin_value <= cur->smin_value && +- old->smax_value >= cur->smax_value; ++ old->smax_value >= cur->smax_value && ++ old->u32_min_value <= cur->u32_min_value && ++ old->u32_max_value >= cur->u32_max_value && ++ old->s32_min_value <= cur->s32_min_value && ++ old->s32_max_value >= cur->s32_max_value; + } + + /* Maximum number of register states that can exist at once */ diff --git a/queue-5.10/bpf-fix-verifier-jsgt-branch-analysis-on-max-bound.patch b/queue-5.10/bpf-fix-verifier-jsgt-branch-analysis-on-max-bound.patch new file mode 100644 index 00000000000..adf270e6d8f --- /dev/null +++ b/queue-5.10/bpf-fix-verifier-jsgt-branch-analysis-on-max-bound.patch @@ -0,0 +1,50 @@ +From ee114dd64c0071500345439fc79dd5e0f9d106ed Mon Sep 17 00:00:00 2001 +From: Daniel Borkmann +Date: Fri, 5 Feb 2021 17:20:14 +0100 +Subject: bpf: Fix verifier jsgt branch analysis on max bound + +From: Daniel Borkmann + +commit ee114dd64c0071500345439fc79dd5e0f9d106ed upstream. + +Fix incorrect is_branch{32,64}_taken() analysis for the jsgt case. The return +code for both will tell the caller whether a given conditional jump is taken +or not, e.g. 1 means branch will be taken [for the involved registers] and the +goto target will be executed, 0 means branch will not be taken and instead we +fall-through to the next insn, and last but not least a -1 denotes that it is +not known at verification time whether a branch will be taken or not. Now while +the jsgt has the branch-taken case correct with reg->s32_min_value > sval, the +branch-not-taken case is off-by-one when testing for reg->s32_max_value < sval +since the branch will also be taken for reg->s32_max_value == sval. The jgt +branch analysis, for example, gets this right. + +Fixes: 3f50f132d840 ("bpf: Verifier, do explicit ALU32 bounds tracking") +Fixes: 4f7b3e82589e ("bpf: improve verifier branch analysis") +Signed-off-by: Daniel Borkmann +Reviewed-by: John Fastabend +Acked-by: Alexei Starovoitov +Signed-off-by: Greg Kroah-Hartman +--- + kernel/bpf/verifier.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/kernel/bpf/verifier.c ++++ b/kernel/bpf/verifier.c +@@ -6822,7 +6822,7 @@ static int is_branch32_taken(struct bpf_ + case BPF_JSGT: + if (reg->s32_min_value > sval) + return 1; +- else if (reg->s32_max_value < sval) ++ else if (reg->s32_max_value <= sval) + return 0; + break; + case BPF_JLT: +@@ -6895,7 +6895,7 @@ static int is_branch64_taken(struct bpf_ + case BPF_JSGT: + if (reg->smin_value > sval) + return 1; +- else if (reg->smax_value < sval) ++ else if (reg->smax_value <= sval) + return 0; + break; + case BPF_JLT: diff --git a/queue-5.10/drm-i915-fix-icl-mg-phy-vswing-handling.patch b/queue-5.10/drm-i915-fix-icl-mg-phy-vswing-handling.patch new file mode 100644 index 00000000000..1212831f6e3 --- /dev/null +++ b/queue-5.10/drm-i915-fix-icl-mg-phy-vswing-handling.patch @@ -0,0 +1,52 @@ +From a2a5f5628e5494ca9353f761f7fe783dfa82fb9a Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= +Date: Mon, 7 Dec 2020 22:35:11 +0200 +Subject: drm/i915: Fix ICL MG PHY vswing handling +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Ville Syrjälä + +commit a2a5f5628e5494ca9353f761f7fe783dfa82fb9a upstream. + +The MH PHY vswing table does have all the entries these days. Get +rid of the old hacks in the code which claim otherwise. + +This hack was totally bogus anyway. The correct way to handle the +lack of those two entries would have been to declare our max +vswing and pre-emph to both be level 2. + +Cc: José Roberto de Souza +Cc: Clinton Taylor +Fixes: 9f7ffa297978 ("drm/i915/tc/icl: Update TC vswing tables") +Signed-off-by: Ville Syrjälä +Link: https://patchwork.freedesktop.org/patch/msgid/20201207203512.1718-1-ville.syrjala@linux.intel.com +Reviewed-by: Imre Deak +Reviewed-by: José Roberto de Souza +(cherry picked from commit 5ec346476e795089b7dac8ab9dcee30c8d80ad84) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/display/intel_ddi.c | 7 +++---- + 1 file changed, 3 insertions(+), 4 deletions(-) + + +--- a/drivers/gpu/drm/i915/display/intel_ddi.c ++++ b/drivers/gpu/drm/i915/display/intel_ddi.c +@@ -2605,12 +2605,11 @@ static void icl_mg_phy_ddi_vswing_sequen + + ddi_translations = icl_get_mg_buf_trans(encoder, type, rate, + &n_entries); +- /* The table does not have values for level 3 and level 9. */ +- if (level >= n_entries || level == 3 || level == 9) { ++ if (level >= n_entries) { + drm_dbg_kms(&dev_priv->drm, + "DDI translation not found for level %d. Using %d instead.", +- level, n_entries - 2); +- level = n_entries - 2; ++ level, n_entries - 1); ++ level = n_entries - 1; + } + + /* Set MG_TX_LINK_PARAMS cri_use_fs32 to 0. */ diff --git a/queue-5.10/drm-i915-skip-vswing-programming-for-tbt.patch b/queue-5.10/drm-i915-skip-vswing-programming-for-tbt.patch new file mode 100644 index 00000000000..e5cec651c3d --- /dev/null +++ b/queue-5.10/drm-i915-skip-vswing-programming-for-tbt.patch @@ -0,0 +1,53 @@ +From eaf5bfe37db871031232d2bf2535b6ca92afbad8 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= +Date: Thu, 28 Jan 2021 17:59:44 +0200 +Subject: drm/i915: Skip vswing programming for TBT +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Ville Syrjälä + +commit eaf5bfe37db871031232d2bf2535b6ca92afbad8 upstream. + +In thunderbolt mode the PHY is owned by the thunderbolt controller. +We are not supposed to touch it. So skip the vswing programming +as well (we already skipped the other steps not applicable to TBT). + +Touching this stuff could supposedly interfere with the PHY +programming done by the thunderbolt controller. + +Cc: stable@vger.kernel.org +Signed-off-by: Ville Syrjälä +Link: https://patchwork.freedesktop.org/patch/msgid/20210128155948.13678-1-ville.syrjala@linux.intel.com +Reviewed-by: Imre Deak +(cherry picked from commit f8c6b615b921d8a1bcd74870f9105e62b0bceff3) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/display/intel_ddi.c | 6 ++++++ + 1 file changed, 6 insertions(+) + + +--- a/drivers/gpu/drm/i915/display/intel_ddi.c ++++ b/drivers/gpu/drm/i915/display/intel_ddi.c +@@ -2597,6 +2597,9 @@ static void icl_mg_phy_ddi_vswing_sequen + u32 n_entries, val; + int ln, rate = 0; + ++ if (enc_to_dig_port(encoder)->tc_mode == TC_PORT_TBT_ALT) ++ return; ++ + if (type != INTEL_OUTPUT_HDMI) { + struct intel_dp *intel_dp = enc_to_intel_dp(encoder); + +@@ -2741,6 +2744,9 @@ tgl_dkl_phy_ddi_vswing_sequence(struct i + u32 n_entries, val, ln, dpcnt_mask, dpcnt_val; + int rate = 0; + ++ if (enc_to_dig_port(encoder)->tc_mode == TC_PORT_TBT_ALT) ++ return; ++ + if (type != INTEL_OUTPUT_HDMI) { + struct intel_dp *intel_dp = enc_to_intel_dp(encoder); + diff --git a/queue-5.10/series b/queue-5.10/series index 51e8cc85786..fe8026f7a50 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -41,3 +41,8 @@ sunrpc-handle-0-length-opaque-xdr-object-data-proper.patch i2c-mediatek-move-suspend-and-resume-handling-to-noi.patch blk-cgroup-use-cond_resched-when-destroy-blkgs.patch regulator-fix-lockdep-warning-resolving-supplies.patch +bpf-fix-verifier-jmp32-pruning-decision-logic.patch +bpf-fix-32-bit-src-register-truncation-on-div-mod.patch +bpf-fix-verifier-jsgt-branch-analysis-on-max-bound.patch +drm-i915-fix-icl-mg-phy-vswing-handling.patch +drm-i915-skip-vswing-programming-for-tbt.patch -- 2.47.2