--- /dev/null
+From e88b2c6e5a4d9ce30d75391e4d950da74bb2bd90 Mon Sep 17 00:00:00 2001
+From: Daniel Borkmann <daniel@iogearbox.net>
+Date: Tue, 9 Feb 2021 18:46:10 +0000
+Subject: bpf: Fix 32 bit src register truncation on div/mod
+
+From: Daniel Borkmann <daniel@iogearbox.net>
+
+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 <john.fastabend@gmail.com>
+Signed-off-by: John Fastabend <john.fastabend@gmail.com>
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Acked-by: Alexei Starovoitov <ast@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
--- /dev/null
+From fd675184fc7abfd1e1c52d23e8e900676b5a1c1a Mon Sep 17 00:00:00 2001
+From: Daniel Borkmann <daniel@iogearbox.net>
+Date: Fri, 5 Feb 2021 20:48:21 +0100
+Subject: bpf: Fix verifier jmp32 pruning decision logic
+
+From: Daniel Borkmann <daniel@iogearbox.net>
+
+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 <anatoly.trosinenko@gmail.com>
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Reviewed-by: John Fastabend <john.fastabend@gmail.com>
+Acked-by: Alexei Starovoitov <ast@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 */
--- /dev/null
+From ee114dd64c0071500345439fc79dd5e0f9d106ed Mon Sep 17 00:00:00 2001
+From: Daniel Borkmann <daniel@iogearbox.net>
+Date: Fri, 5 Feb 2021 17:20:14 +0100
+Subject: bpf: Fix verifier jsgt branch analysis on max bound
+
+From: Daniel Borkmann <daniel@iogearbox.net>
+
+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 <daniel@iogearbox.net>
+Reviewed-by: John Fastabend <john.fastabend@gmail.com>
+Acked-by: Alexei Starovoitov <ast@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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:
--- /dev/null
+From a2a5f5628e5494ca9353f761f7fe783dfa82fb9a Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+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ä <ville.syrjala@linux.intel.com>
+
+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 <jose.souza@intel.com>
+Cc: Clinton Taylor <clinton.a.taylor@intel.com>
+Fixes: 9f7ffa297978 ("drm/i915/tc/icl: Update TC vswing tables")
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20201207203512.1718-1-ville.syrjala@linux.intel.com
+Reviewed-by: Imre Deak <imre.deak@intel.com>
+Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
+(cherry picked from commit 5ec346476e795089b7dac8ab9dcee30c8d80ad84)
+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 | 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. */
--- /dev/null
+From eaf5bfe37db871031232d2bf2535b6ca92afbad8 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: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ä <ville.syrjala@linux.intel.com>
+
+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ä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210128155948.13678-1-ville.syrjala@linux.intel.com
+Reviewed-by: Imre Deak <imre.deak@intel.com>
+(cherry picked from commit f8c6b615b921d8a1bcd74870f9105e62b0bceff3)
+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 | 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);
+
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
