6.1.68-rc1 review
Subsystems (7)
Greg Kroah-Hartman
maintainerPATCH 141/194 LoongArch: BPF: Dont sign extend memory load operand
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hengqi Chen <[email protected]>
[ Upstream commit fe5757553bf9ebe45ae8ecab5922f6937c8d8dfc ]
The cgrp_local_storage test triggers a kernel panic like:
# ./test_progs -t cgrp_local_storage Can't find bpf_testmod.ko kernel module: -2 WARNING! Selftests relying on bpf_testmod.ko will be skipped. [ 550.930632] CPU 1 Unable to handle kernel paging request at virtual address 0000000000000080, era == ffff80000200be34, ra == ffff80000200be00 [ 550.931781] Oops[#1]: [ 550.931966] CPU: 1 PID: 1303 Comm: test_progs Not tainted 6.7.0-rc2-loong-devel-g2f56bb0d2327 #35 a896aca3f4164f09cc346f89f2e09832e07be5f6 [ 550.932215] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 [ 550.932403] pc ffff80000200be34 ra ffff80000200be00 tp 9000000108350000 sp 9000000108353dc0 [ 550.932545] a0 0000000000000000 a1 0000000000000517 a2 0000000000000118 a3 00007ffffbb15558 [ 550.932682] a4 00007ffffbb15620 a5 90000001004e7700 a6 0000000000000021 a7 0000000000000118 [ 550.932824] t0 ffff80000200bdc0 t1 0000000000000517 t2 0000000000000517 t3 00007ffff1c06ee0 [ 550.932961] t4 0000555578ae04d0 t5 fffffffffffffff8 t6 0000000000000004 t7 0000000000000020 [ 550.933097] t8 0000000000000040 u0 00000000000007b8 s9 9000000108353e00 s0 90000001004e7700 [ 550.933241] s1 9000000004005000 s2 0000000000000001 s3 0000000000000000 s4 0000555555eb2ec8 [ 550.933379] s5 00007ffffbb15bb8 s6 00007ffff1dafd60 s7 000055555663f610 s8 00007ffff1db0050 [ 550.933520] ra: ffff80000200be00 bpf_prog_98f1b9e767be2a84_on_enter+0x40/0x200 [ 550.933911] ERA: ffff80000200be34 bpf_prog_98f1b9e767be2a84_on_enter+0x74/0x200 [ 550.934105] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 550.934596] PRMD: 00000004 (PPLV0 +PIE -PWE) [ 550.934712] EUEN: 00000003 (+FPE +SXE -ASXE -BTE) [ 550.934836] ECFG: 00071c1c (LIE=2-4,10-12 VS=7) [ 550.934976] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [ 550.935097] BADV: 0000000000000080 [ 550.935181] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) [ 550.935291] Modules linked in: [ 550.935391] Process test_progs (pid: 1303, threadinfo=000000006c3b1c41, task=0000000061f84a55) [ 550.935643] Stack : 00007ffffbb15bb8 0000555555eb2ec8 0000000000000000 0000000000000001 [ 550.935844] 9000000004005000 ffff80001b864000 00007ffffbb15450 90000000029aa034 [ 550.935990] 0000000000000000 9000000108353ec0 0000000000000118 d07d9dfb09721a09 [ 550.936175] 0000000000000001 0000000000000000 9000000108353ec0 0000000000000118 [ 550.936314] 9000000101d46ad0 900000000290abf0 000055555663f610 0000000000000000 [ 550.936479] 0000000000000003 9000000108353ec0 00007ffffbb15450 90000000029d7288 [ 550.936635] 00007ffff1dafd60 000055555663f610 0000000000000000 0000000000000003 [ 550.936779] 9000000108353ec0 90000000035dd1f0 00007ffff1dafd58 9000000002841c5c [ 550.936939] 0000000000000119 0000555555eea5a8 00007ffff1d78780 00007ffffbb153e0 [ 550.937083] ffffffffffffffda 00007ffffbb15518 0000000000000040 00007ffffbb15558 [ 550.937224] ... [ 550.937299] Call Trace: [ 550.937521] [<ffff80000200be34>] bpf_prog_98f1b9e767be2a84_on_enter+0x74/0x200 [ 550.937910] [<90000000029aa034>] bpf_trace_run2+0x90/0x154 [ 550.938105] [<900000000290abf0>] syscall_trace_enter.isra.0+0x1cc/0x200 [ 550.938224] [<90000000035dd1f0>] do_syscall+0x48/0x94 [ 550.938319] [<9000000002841c5c>] handle_syscall+0xbc/0x158 [ 550.938477] [ 550.938607] Code: 580009ae 50016000 262402e4 <28c20085> 14092084 03a00084 16000024 03240084 00150006 [ 550.938851] [ 550.939021] ---[ end trace 0000000000000000 ]---
Further investigation shows that this panic is triggered by memory load operations:
ptr = bpf_cgrp_storage_get(&map_a, task->cgroups->dfl_cgrp, 0,
BPF_LOCAL_STORAGE_GET_F_CREATE);
The expression task->cgroups->dfl_cgrp involves two memory load. Since the field offset fits in imm12 or imm14, we use ldd or ldptrd instructions. But both instructions have the side effect that it will signed-extended the imm operand. Finally, we got the wrong addresses and panics is inevitable.
Use a generic ldxd instruction to avoid this kind of issues.
With this change, we have:
# ./test_progs -t cgrp_local_storage Can't find bpf_testmod.ko kernel module: -2 WARNING! Selftests relying on bpf_testmod.ko will be skipped. test_cgrp_local_storage:PASS:join_cgroup /cgrp_local_storage 0 nsec #48/1 cgrp_local_storage/tp_btf:OK test_attach_cgroup:PASS:skel_open 0 nsec test_attach_cgroup:PASS:prog_attach 0 nsec test_attach_cgroup:PASS:prog_attach 0 nsec libbpf: prog 'update_cookie_tracing': failed to attach: ERROR: strerror_r(-524)=22 test_attach_cgroup:FAIL:prog_attach unexpected error: -524 #48/2 cgrp_local_storage/attach_cgroup:FAIL test_recursion:PASS:skel_open_and_load 0 nsec libbpf: prog 'on_lookup': failed to attach: ERROR: strerror_r(-524)=22 libbpf: prog 'on_lookup': failed to auto-attach: -524 test_recursion:FAIL:skel_attach unexpected error: -524 (errno 524) #48/3 cgrp_local_storage/recursion:FAIL #48/4 cgrp_local_storage/negative:OK #48/5 cgrp_local_storage/cgroup_iter_sleepable:OK test_yes_rcu_lock:PASS:skel_open 0 nsec test_yes_rcu_lock:PASS:skel_load 0 nsec libbpf: prog 'yes_rcu_lock': failed to attach: ERROR: strerror_r(-524)=22 libbpf: prog 'yes_rcu_lock': failed to auto-attach: -524 test_yes_rcu_lock:FAIL:skel_attach unexpected error: -524 (errno 524) #48/6 cgrp_local_storage/yes_rcu_lock:FAIL #48/7 cgrp_local_storage/no_rcu_lock:OK #48 cgrp_local_storage:FAIL
All error logs:
test_cgrp_local_storage:PASS:join_cgroup /cgrp_local_storage 0 nsec test_attach_cgroup:PASS:skel_open 0 nsec test_attach_cgroup:PASS:prog_attach 0 nsec test_attach_cgroup:PASS:prog_attach 0 nsec
libbpf: prog 'update_cookie_tracing': failed to attach: ERROR: strerror_r(-524)=22 test_attach_cgroup:FAIL:prog_attach unexpected error: -524
#48/2 cgrp_local_storage/attach_cgroup:FAIL
test_recursion:PASS:skel_open_and_load 0 nsec
libbpf: prog 'on_lookup': failed to attach: ERROR: strerror_r(-524)=22
libbpf: prog 'on_lookup': failed to auto-attach: -524 test_recursion:FAIL:skel_attach unexpected error: -524 (errno 524)
#48/3 cgrp_local_storage/recursion:FAIL
test_yes_rcu_lock:PASS:skel_open 0 nsec test_yes_rcu_lock:PASS:skel_load 0 nsec
libbpf: prog 'yes_rcu_lock': failed to attach: ERROR: strerror_r(-524)=22
libbpf: prog 'yes_rcu_lock': failed to auto-attach: -524 test_yes_rcu_lock:FAIL:skel_attach unexpected error: -524 (errno 524)
#48/6 cgrp_local_storage/yes_rcu_lock:FAIL
#48 cgrp_local_storage:FAIL
Summary: 0/4 PASSED, 0 SKIPPED, 1 FAILED
No panics any more (The test still failed because lack of BPF trampoline which I am actively working on).
--- arch/loongarch/net/bpf_jit.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-)
arch/loongarch/net/bpf_jit.c +2 -8
@@ -844,14 +844,8 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx, bool ext }break ;case BPF_DW : -if (is_signed_imm12 (off)) { -emit_insn (ctx, ldd, dst, src, off); - }else if (is_signed_imm14 (off)) { -emit_insn (ctx, ldptrd, dst, src, off); - }else { -move_imm (ctx, t1, off, is32); -emit_insn (ctx, ldxd, dst, src, t1); - } +move_imm (ctx, t1, off, is32); +emit_insn (ctx, ldxd, dst, src, t1);break ; }break ;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 142/194 LoongArch: BPF: Dont sign extend function return value
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hengqi Chen <[email protected]>
[ Upstream commit 5d47ec2e6f4c64e30e392cfe9532df98c9beb106 ]
The cls_redirect test triggers a kernel panic like:
# ./test_progs -t cls_redirect Can't find bpf_testmod.ko kernel module: -2 WARNING! Selftests relying on bpf_testmod.ko will be skipped. [ 30.938489] CPU 3 Unable to handle kernel paging request at virtual address fffffffffd814de0, era == ffff800002009fb8, ra == ffff800002009f9c [ 30.939331] Oops[#1]: [ 30.939513] CPU: 3 PID: 1260 Comm: test_progs Not tainted 6.7.0-rc2-loong-devel-g2f56bb0d2327 #35 a896aca3f4164f09cc346f89f2e09832e07be5f6 [ 30.939732] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 [ 30.939901] pc ffff800002009fb8 ra ffff800002009f9c tp 9000000104da4000 sp 9000000104da7ab0 [ 30.940038] a0 fffffffffd814de0 a1 9000000104da7a68 a2 0000000000000000 a3 9000000104da7c10 [ 30.940183] a4 9000000104da7c14 a5 0000000000000002 a6 0000000000000021 a7 00005555904d7f90 [ 30.940321] t0 0000000000000110 t1 0000000000000000 t2 fffffffffd814de0 t3 0004c4b400000000 [ 30.940456] t4 ffffffffffffffff t5 00000000c3f63600 t6 0000000000000000 t7 0000000000000000 [ 30.940590] t8 000000000006d803 u0 0000000000000020 s9 9000000104da7b10 s0 900000010504c200 [ 30.940727] s1 fffffffffd814de0 s2 900000010504c200 s3 9000000104da7c10 s4 9000000104da7ad0 [ 30.940866] s5 0000000000000000 s6 90000000030e65bc s7 9000000104da7b44 s8 90000000044f6fc0 [ 30.941015] ra: ffff800002009f9c bpf_prog_846803e5ae81417f_cls_redirect+0xa0/0x590 [ 30.941535] ERA: ffff800002009fb8 bpf_prog_846803e5ae81417f_cls_redirect+0xbc/0x590 [ 30.941696] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 30.942224] PRMD: 00000004 (PPLV0 +PIE -PWE) [ 30.942330] EUEN: 00000003 (+FPE +SXE -ASXE -BTE) [ 30.942453] ECFG: 00071c1c (LIE=2-4,10-12 VS=7) [ 30.942612] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [ 30.942764] BADV: fffffffffd814de0 [ 30.942854] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) [ 30.942974] Modules linked in: [ 30.943078] Process test_progs (pid: 1260, threadinfo=00000000ce303226, task=000000007d10bb76) [ 30.943306] Stack : 900000010a064000 90000000044f6fc0 9000000104da7b48 0000000000000000 [ 30.943495] 0000000000000000 9000000104da7c14 9000000104da7c10 900000010504c200 [ 30.943626] 0000000000000001 ffff80001b88c000 9000000104da7b70 90000000030e6668 [ 30.943785] 0000000000000000 9000000104da7b58 ffff80001b88c048 9000000003d05000 [ 30.943936] 900000000303ac88 0000000000000000 0000000000000000 9000000104da7b70 [ 30.944091] 0000000000000000 0000000000000001 0000000731eeab00 0000000000000000 [ 30.944245] ffff80001b88c000 0000000000000000 0000000000000000 54b99959429f83b8 [ 30.944402] ffff80001b88c000 90000000044f6fc0 9000000101d70000 ffff80001b88c000 [ 30.944538] 000000000000005a 900000010504c200 900000010a064000 900000010a067000 [ 30.944697] 9000000104da7d88 0000000000000000 9000000003d05000 90000000030e794c [ 30.944852] ... [ 30.944924] Call Trace: [ 30.945120] [<ffff800002009fb8>] bpf_prog_846803e5ae81417f_cls_redirect+0xbc/0x590 [ 30.945650] [<90000000030e6668>] bpf_test_run+0x1ec/0x2f8 [ 30.945958] [<90000000030e794c>] bpf_prog_test_run_skb+0x31c/0x684 [ 30.946065] [<90000000026d4f68>] __sys_bpf+0x678/0x2724 [ 30.946159] [<90000000026d7288>] sys_bpf+0x20/0x2c [ 30.946253] [<90000000032dd224>] do_syscall+0x7c/0x94 [ 30.946343] [<9000000002541c5c>] handle_syscall+0xbc/0x158 [ 30.946492] [ 30.946549] Code: 0015030e 5c0009c0 5001d000 <28c00304> 02c00484 29c00304 00150009 2a42d2e4 0280200d [ 30.946793] [ 30.946971] ---[ end trace 0000000000000000 ]--- [ 32.093225] Kernel panic - not syncing: Fatal exception in interrupt [ 32.093526] Kernel relocated by 0x2320000 [ 32.093630] .text @ 0x9000000002520000 [ 32.093725] .data @ 0x9000000003400000 [ 32.093792] .bss @ 0x9000000004413200 [ 34.971998] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
This is because we signed-extend function return values. When subprog mode is enabled, we have:
cls_redirect()
-> get_global_metrics() returns pcpu ptr 0xfffffefffc00b480
The pointer returned is later signed-extended to 0xfffffffffc00b480 at BPF_JMP | BPF_EXIT. During BPF prog run, this triggers unhandled page fault and a kernel panic.
Drop the unnecessary signed-extension on return values like other architectures do.
With this change, we have:
# ./test_progs -t cls_redirect Can't find bpf_testmod.ko kernel module: -2 WARNING! Selftests relying on bpf_testmod.ko will be skipped. #51/1 cls_redirect/cls_redirect_inlined:OK #51/2 cls_redirect/IPv4 TCP accept unknown (no hops, flags: SYN):OK #51/3 cls_redirect/IPv6 TCP accept unknown (no hops, flags: SYN):OK #51/4 cls_redirect/IPv4 TCP accept unknown (no hops, flags: ACK):OK #51/5 cls_redirect/IPv6 TCP accept unknown (no hops, flags: ACK):OK #51/6 cls_redirect/IPv4 TCP forward unknown (one hop, flags: ACK):OK #51/7 cls_redirect/IPv6 TCP forward unknown (one hop, flags: ACK):OK #51/8 cls_redirect/IPv4 TCP accept known (one hop, flags: ACK):OK #51/9 cls_redirect/IPv6 TCP accept known (one hop, flags: ACK):OK #51/10 cls_redirect/IPv4 UDP accept unknown (no hops, flags: none):OK #51/11 cls_redirect/IPv6 UDP accept unknown (no hops, flags: none):OK #51/12 cls_redirect/IPv4 UDP forward unknown (one hop, flags: none):OK #51/13 cls_redirect/IPv6 UDP forward unknown (one hop, flags: none):OK #51/14 cls_redirect/IPv4 UDP accept known (one hop, flags: none):OK #51/15 cls_redirect/IPv6 UDP accept known (one hop, flags: none):OK #51/16 cls_redirect/cls_redirect_subprogs:OK #51/17 cls_redirect/IPv4 TCP accept unknown (no hops, flags: SYN):OK #51/18 cls_redirect/IPv6 TCP accept unknown (no hops, flags: SYN):OK #51/19 cls_redirect/IPv4 TCP accept unknown (no hops, flags: ACK):OK #51/20 cls_redirect/IPv6 TCP accept unknown (no hops, flags: ACK):OK #51/21 cls_redirect/IPv4 TCP forward unknown (one hop, flags: ACK):OK #51/22 cls_redirect/IPv6 TCP forward unknown (one hop, flags: ACK):OK #51/23 cls_redirect/IPv4 TCP accept known (one hop, flags: ACK):OK #51/24 cls_redirect/IPv6 TCP accept known (one hop, flags: ACK):OK #51/25 cls_redirect/IPv4 UDP accept unknown (no hops, flags: none):OK #51/26 cls_redirect/IPv6 UDP accept unknown (no hops, flags: none):OK #51/27 cls_redirect/IPv4 UDP forward unknown (one hop, flags: none):OK #51/28 cls_redirect/IPv6 UDP forward unknown (one hop, flags: none):OK #51/29 cls_redirect/IPv4 UDP accept known (one hop, flags: none):OK #51/30 cls_redirect/IPv6 UDP accept known (one hop, flags: none):OK #51/31 cls_redirect/cls_redirect_dynptr:OK #51/32 cls_redirect/IPv4 TCP accept unknown (no hops, flags: SYN):OK #51/33 cls_redirect/IPv6 TCP accept unknown (no hops, flags: SYN):OK #51/34 cls_redirect/IPv4 TCP accept unknown (no hops, flags: ACK):OK #51/35 cls_redirect/IPv6 TCP accept unknown (no hops, flags: ACK):OK #51/36 cls_redirect/IPv4 TCP forward unknown (one hop, flags: ACK):OK #51/37 cls_redirect/IPv6 TCP forward unknown (one hop, flags: ACK):OK #51/38 cls_redirect/IPv4 TCP accept known (one hop, flags: ACK):OK #51/39 cls_redirect/IPv6 TCP accept known (one hop, flags: ACK):OK #51/40 cls_redirect/IPv4 UDP accept unknown (no hops, flags: none):OK #51/41 cls_redirect/IPv6 UDP accept unknown (no hops, flags: none):OK #51/42 cls_redirect/IPv4 UDP forward unknown (one hop, flags: none):OK #51/43 cls_redirect/IPv6 UDP forward unknown (one hop, flags: none):OK #51/44 cls_redirect/IPv4 UDP accept known (one hop, flags: none):OK #51/45 cls_redirect/IPv6 UDP accept known (one hop, flags: none):OK #51 cls_redirect:OK Summary: 1/45 PASSED, 0 SKIPPED, 0 FAILED
--- arch/loongarch/net/bpf_jit.c | 2 -- 1 file changed, 2 deletions(-)
arch/loongarch/net/bpf_jit.c +0 -2
@@ -796,8 +796,6 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx, bool ext/* function return */ case BPF_JMP |BPF_EXIT : -emit_sext_32 (ctx, regmap[BPF_REG_0 ], true); -if (i == ctx->prog->len -1 )break ;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 143/194 ring-buffer: Force absolute timestamp on discard of event
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt (Google) <[email protected]>
[ Upstream commit b2dd797543cfa6580eac8408dd67fa02164d9e56 ]
There's a race where if an event is discarded from the ring buffer and an interrupt were to happen at that time and insert an event, the time stamp is still used from the discarded event as an offset. This can screw up the timings.
If the event is going to be discarded, set the "before_stamp" to zero. When a new event comes in, it compares the "before_stamp" with the "write_stamp" and if they are not equal, it will insert an absolute timestamp. This will prevent the timings from getting out of sync due to the discarded event.
--- kernel/trace/ring_buffer.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-)
kernel/trace/ring_buffer.c +8 -11
@@ -3025,22 +3025,19 @@ rb_try_to_discard(struct ring_buffer_per_cpu *cpu_buffer,local_read (&bpage->write) & ~RB_WRITE_MASK ;unsigned long event_length =rb_event_length (event); +/* +* For the before_stamp to be different than the write_stamp +* to make sure that the next event adds an absolute +* value and does not rely on the saved write stamp, which +* is now going to be bogus. +*/ +rb_time_set (&cpu_buffer->before_stamp,0 ); +/* Something came in, can't discard */ if (!rb_time_cmpxchg (&cpu_buffer->write_stamp, write_stamp, write_stamp - delta))return 0 ; -/* -* It's possible that the event time delta is zero -* (has the same time stamp as the previous event) -* in which case write_stamp and before_stamp could -* be the same. In such a case, force before_stamp -* to be different than write_stamp. It doesn't -* matter what it is, as long as its different. -*/ -if (!delta) -rb_time_set (&cpu_buffer->before_stamp,0 ); -/* * If an event were to come in now, it would see that the * write_stamp and the before_stamp are different, and assume
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 144/194 tracing: Set actual size after ring buffer resize
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zheng Yejian <[email protected]>
[ Upstream commit 6d98a0f2ac3c021d21be66fa34e992137cd25bcb ]
Currently we can resize trace ringbuffer by writing a value into file 'buffer_size_kb', then by reading the file, we get the value that is usually what we wrote. However, this value may be not actual size of trace ring buffer because of the round up when doing resize in kernel, and the actual size would be more useful.
Stable-dep-of: d78ab792705c ("tracing: Stop current tracer when resizing buffer")
--- kernel/trace/trace.c | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-)
kernel/trace/trace.c +11 -8
@@ -6215,6 +6215,15 @@ static void set_buffer_entries(struct array_buffer *buf, unsigned long val)per_cpu_ptr (buf->data, cpu)->entries = val; } +static void update_buffer_entries (struct array_buffer *buf,int cpu) +{ +if (cpu ==RING_BUFFER_ALL_CPUS ) { +set_buffer_entries (buf,ring_buffer_size (buf->buffer,0 )); + }else { +per_cpu_ptr (buf->data, cpu)->entries =ring_buffer_size (buf->buffer, cpu); + } +} +#ifdef CONFIG_TRACER_MAX_TRACE /* resize @tr's buffer to the size of @size_tr's entries */ static int resize_buffer_duplicate_size(struct array_buffer *trace_buf,
@@ -6292,18 +6301,12 @@ static int __tracing_resize_ring_buffer(struct trace_array *tr,return ret; } -if (cpu ==RING_BUFFER_ALL_CPUS ) -set_buffer_entries (&tr->max_buffer, size); -else -per_cpu_ptr (tr->max_buffer.data, cpu)->entries = size; +update_buffer_entries (&tr->max_buffer, cpu); out:#endif /* CONFIG_TRACER_MAX_TRACE */ -if (cpu ==RING_BUFFER_ALL_CPUS ) -set_buffer_entries (&tr->array_buffer, size); -else -per_cpu_ptr (tr->array_buffer.data, cpu)->entries = size; +update_buffer_entries (&tr->array_buffer, cpu);return ret; }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 145/194 tracing: Stop current tracer when resizing buffer
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt (Google) <[email protected]>
[ Upstream commit d78ab792705c7be1b91243b2544d1a79406a2ad7 ]
When the ring buffer is being resized, it can cause side effects to the running tracer. For instance, there's a race with irqsoff tracer that swaps individual per cpu buffers between the main buffer and the snapshot buffer. The resize operation modifies the main buffer and then the snapshot buffer. If a swap happens in between those two operations it will break the tracer.
Simply stop the running tracer before resizing the buffers and enable it again when finished.
--- kernel/trace/trace.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
kernel/trace/trace.c +7 -3
@@ -6268,9 +6268,12 @@ static int __tracing_resize_ring_buffer(struct trace_array *tr,if (!tr->array_buffer.buffer)return 0 ; +/* Do not allow tracing while resizng ring buffer */ +tracing_stop_tr (tr); + ret =ring_buffer_resize (tr->array_buffer.buffer, size, cpu);if (ret <0 ) -return ret; + goto out_start;#ifdef CONFIG_TRACER_MAX_TRACE if (!tr->current_trace->use_max_tr)
@@ -6298,7 +6301,7 @@ static int __tracing_resize_ring_buffer(struct trace_array *tr,WARN_ON (1 ); tracing_disabled =1 ; } -return ret; + goto out_start; }update_buffer_entries (&tr->max_buffer, cpu);
@@ -6307,7 +6310,8 @@ static int __tracing_resize_ring_buffer(struct trace_array *tr,#endif /* CONFIG_TRACER_MAX_TRACE */ update_buffer_entries (&tr->array_buffer, cpu); - + out_start: +tracing_start_tr (tr);return ret; }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 146/194 parisc: Reduce size of the bug_table on 64-bit kernel by half
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Helge Deller <[email protected]>
[ Upstream commit 43266838515d30dc0c45d5c7e6e7edacee6cce92 ]
Enable GENERIC_BUG_RELATIVE_POINTERS which will store 32-bit relative offsets to the bug address and the source file name instead of 64-bit absolute addresses. This effectively reduces the size of the bug_table[] array by half on 64-bit kernels.
Stable-dep-of: 487635756198 ("parisc: Fix asm operand number out of range build error in bug table")
--- arch/parisc/Kconfig | 7 +++++-- arch/parisc/include/asm/bug.h | 34 +++++++++++++++++----------------- 2 files changed, 22 insertions(+), 19 deletions(-)
arch/parisc/Kconfig +5 -2
@@ -105,9 +105,12 @@ config ARCH_HAS_ILOG2_U64 default n config GENERIC_BUG - bool - default y + def_bool y depends on BUG + select GENERIC_BUG_RELATIVE_POINTERS if 64BIT + +config GENERIC_BUG_RELATIVE_POINTERS + bool config GENERIC_HWEIGHT bool
arch/parisc/include/asm/bug.h +17 -17
@@ -17,26 +17,27 @@#define PARISC_BUG_BREAK_ASM "break 0x1f, 0x1fff"#define PARISC_BUG_BREAK_INSN 0x03ffe01f/* PARISC_BUG_BREAK_ASM */ -#if defined(CONFIG_64BIT ) -#define ASM_WORD_INSN ".dword\t" +#ifdef CONFIG_GENERIC_BUG_RELATIVE_POINTERS +# define __BUG_REL (val) ".word " __stringify(val) " - ."#else -#define ASM_WORD_INSN ".word\t" +# define __BUG_REL (val) ".word " __stringify(val)#endif +#ifdef CONFIG_DEBUG_BUGVERBOSE #define BUG () \ do { \ asm volatile("\n" \ "1:\t" PARISC_BUG_BREAK_ASM "\n" \ "\t.pushsection __bug_table,\"a\"\n" \ - "\t.align %4\n" \ - "2:\t" ASM_WORD_INSN "1b, %c0\n" \ + "\t.align 4\n" \ + "2:\t" __BUG_REL(1b) "\n" \ + "\t" __BUG_REL(%c0) "\n" \ "\t.short %1, %2\n" \ - "\t.blockz %3-2*%4-2*2\n" \ + "\t.blockz %3-2*4-2*2\n" \ "\t.popsection" \ : : "i" (__FILE__), "i" (__LINE__), \ - "i" (0), "i" (sizeof(struct bug_entry)), \ - "i" (sizeof(long)) ); \ + "i" (0), "i" (sizeof(struct bug_entry)) ); \ unreachable(); \ } while(0)
@@ -54,15 +55,15 @@ asmvolatile ("\n" \"1:\t" PARISC_BUG_BREAK_ASM "\n" \"\t.pushsection __bug_table,\"a\"\n" \ -"\t.align %4\n" \ -"2:\t" ASM_WORD_INSN "1b, %c0\n" \ +"\t.align 4\n" \ + "2:\t" __BUG_REL(1b) "\n" \ + "\t" __BUG_REL(%c0) "\n" \"\t.short %1, %2\n" \ -"\t.blockz %3-2*%4-2*2\n" \ +"\t.blockz %3-2*4-2*2\n" \"\t.popsection" \ : : "i" (__FILE__), "i" (__LINE__), \"i" (BUGFLAG_WARNING |(flags)), \ -"i" (sizeof (struct bug_entry )), \ -"i" (sizeof (long )) ); \ + "i" (sizeof(struct bug_entry)) ); \ } while(0) #else#define __WARN_FLAGS (flags) \
@@ -71,13 +72,12 @@"1:\t" PARISC_BUG_BREAK_ASM "\n" \"\t.pushsection __bug_table,\"a\"\n" \"\t.align %2\n" \ -"2:\t" ASM_WORD_INSN "1b\n" \ + "2:\t" __BUG_REL(1b) "\n" \"\t.short %0\n" \ -"\t.blockz %1-%2-2\n" \ +"\t.blockz %1-4-2\n" \"\t.popsection" \ : : "i" (BUGFLAG_WARNING|(flags)), \ -"i" (sizeof (struct bug_entry )), \ - "i" (sizeof(long)) ); \ + "i" (sizeof(struct bug_entry)) ); \ } while(0)#endif
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 147/194 parisc: Fix asm operand number out of range build error in bug table
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Helge Deller <[email protected]>
[ Upstream commit 487635756198cad563feb47539c6a37ea57f1dae ]
Build is broken if CONFIG_DEBUG_BUGVERBOSE=n.
Fix it be using the correct asm operand number.
--- arch/parisc/include/asm/bug.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/parisc/include/asm/bug.h +1 -1
@@ -71,7 +71,7 @@ asmvolatile ("\n" \"1:\t" PARISC_BUG_BREAK_ASM "\n" \"\t.pushsection __bug_table,\"a\"\n" \ -"\t.align %2\n" \ +"\t.align 4\n" \ "2:\t" __BUG_REL(1b) "\n" \"\t.short %0\n" \"\t.blockz %1-4-2\n" \
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 148/194 arm64: dts: mediatek: add missing space before {
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <[email protected]>
[ Upstream commit a9c740c57f977deb41bc53c02d0dae3d0e2f191a ]
Add missing whitespace between node name/label and opening {.
Stable-dep-of: 8980c30141d3 ("arm64: dts: mt8183: kukui: Fix underscores in node names")
--- arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 48 +++++++++---------- .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 12 ++--- .../boot/dts/mediatek/mt8183-pumpkin.dts | 12 ++--- 3 files changed, 36 insertions(+), 36 deletions(-)
arch/arm64/boot/dts/mediatek/mt8183-evb.dts +24 -24
@@ -139,8 +139,8 @@ &mmc1 { }; &pio { - i2c_pins_0: i2c0{ - pins_i2c{ + i2c_pins_0: i2c0 { + pins_i2c { pinmux = <PINMUX_GPIO82__FUNC_SDA0>, <PINMUX_GPIO83__FUNC_SCL0>; mediatek,pull-up-adv = <3>;
@@ -148,8 +148,8 @@ pins_i2c{ }; }; - i2c_pins_1: i2c1{ - pins_i2c{ + i2c_pins_1: i2c1 { + pins_i2c { pinmux = <PINMUX_GPIO81__FUNC_SDA1>, <PINMUX_GPIO84__FUNC_SCL1>; mediatek,pull-up-adv = <3>;
@@ -157,8 +157,8 @@ pins_i2c{ }; }; - i2c_pins_2: i2c2{ - pins_i2c{ + i2c_pins_2: i2c2 { + pins_i2c { pinmux = <PINMUX_GPIO103__FUNC_SCL2>, <PINMUX_GPIO104__FUNC_SDA2>; mediatek,pull-up-adv = <3>;
@@ -166,8 +166,8 @@ pins_i2c{ }; }; - i2c_pins_3: i2c3{ - pins_i2c{ + i2c_pins_3: i2c3 { + pins_i2c { pinmux = <PINMUX_GPIO50__FUNC_SCL3>, <PINMUX_GPIO51__FUNC_SDA3>; mediatek,pull-up-adv = <3>;
@@ -175,8 +175,8 @@ pins_i2c{ }; }; - i2c_pins_4: i2c4{ - pins_i2c{ + i2c_pins_4: i2c4 { + pins_i2c { pinmux = <PINMUX_GPIO105__FUNC_SCL4>, <PINMUX_GPIO106__FUNC_SDA4>; mediatek,pull-up-adv = <3>;
@@ -184,8 +184,8 @@ pins_i2c{ }; }; - i2c_pins_5: i2c5{ - pins_i2c{ + i2c_pins_5: i2c5 { + pins_i2c { pinmux = <PINMUX_GPIO48__FUNC_SCL5>, <PINMUX_GPIO49__FUNC_SDA5>; mediatek,pull-up-adv = <3>;
@@ -193,8 +193,8 @@ pins_i2c{ }; }; - spi_pins_0: spi0{ - pins_spi{ + spi_pins_0: spi0 { + pins_spi { pinmux = <PINMUX_GPIO85__FUNC_SPI0_MI>, <PINMUX_GPIO86__FUNC_SPI0_CSB>, <PINMUX_GPIO87__FUNC_SPI0_MO>,
@@ -308,8 +308,8 @@ pins_clk { }; }; - spi_pins_1: spi1{ - pins_spi{ + spi_pins_1: spi1 { + pins_spi { pinmux = <PINMUX_GPIO161__FUNC_SPI1_A_MI>, <PINMUX_GPIO162__FUNC_SPI1_A_CSB>, <PINMUX_GPIO163__FUNC_SPI1_A_MO>,
@@ -318,8 +318,8 @@ pins_spi{ }; }; - spi_pins_2: spi2{ - pins_spi{ + spi_pins_2: spi2 { + pins_spi { pinmux = <PINMUX_GPIO0__FUNC_SPI2_CSB>, <PINMUX_GPIO1__FUNC_SPI2_MO>, <PINMUX_GPIO2__FUNC_SPI2_CLK>,
@@ -328,8 +328,8 @@ pins_spi{ }; }; - spi_pins_3: spi3{ - pins_spi{ + spi_pins_3: spi3 { + pins_spi { pinmux = <PINMUX_GPIO21__FUNC_SPI3_MI>, <PINMUX_GPIO22__FUNC_SPI3_CSB>, <PINMUX_GPIO23__FUNC_SPI3_MO>,
@@ -338,8 +338,8 @@ pins_spi{ }; }; - spi_pins_4: spi4{ - pins_spi{ + spi_pins_4: spi4 { + pins_spi { pinmux = <PINMUX_GPIO17__FUNC_SPI4_MI>, <PINMUX_GPIO18__FUNC_SPI4_CSB>, <PINMUX_GPIO19__FUNC_SPI4_MO>,
@@ -348,8 +348,8 @@ pins_spi{ }; }; - spi_pins_5: spi5{ - pins_spi{ + spi_pins_5: spi5 { + pins_spi { pinmux = <PINMUX_GPIO13__FUNC_SPI5_MI>, <PINMUX_GPIO14__FUNC_SPI5_CSB>, <PINMUX_GPIO15__FUNC_SPI5_MO>,
arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi +6 -6
@@ -683,7 +683,7 @@ pins_scp_uart { }; spi0_pins: spi0 { - pins_spi{ + pins_spi { pinmux = <PINMUX_GPIO85__FUNC_SPI0_MI>, <PINMUX_GPIO86__FUNC_GPIO86>, <PINMUX_GPIO87__FUNC_SPI0_MO>,
@@ -693,7 +693,7 @@ pins_spi{ }; spi1_pins: spi1 { - pins_spi{ + pins_spi { pinmux = <PINMUX_GPIO161__FUNC_SPI1_A_MI>, <PINMUX_GPIO162__FUNC_SPI1_A_CSB>, <PINMUX_GPIO163__FUNC_SPI1_A_MO>,
@@ -703,7 +703,7 @@ pins_spi{ }; spi2_pins: spi2 { - pins_spi{ + pins_spi { pinmux = <PINMUX_GPIO0__FUNC_SPI2_CSB>, <PINMUX_GPIO1__FUNC_SPI2_MO>, <PINMUX_GPIO2__FUNC_SPI2_CLK>;
@@ -716,7 +716,7 @@ pins_spi_mi { }; spi3_pins: spi3 { - pins_spi{ + pins_spi { pinmux = <PINMUX_GPIO21__FUNC_SPI3_MI>, <PINMUX_GPIO22__FUNC_SPI3_CSB>, <PINMUX_GPIO23__FUNC_SPI3_MO>,
@@ -726,7 +726,7 @@ pins_spi{ }; spi4_pins: spi4 { - pins_spi{ + pins_spi { pinmux = <PINMUX_GPIO17__FUNC_SPI4_MI>, <PINMUX_GPIO18__FUNC_SPI4_CSB>, <PINMUX_GPIO19__FUNC_SPI4_MO>,
@@ -736,7 +736,7 @@ pins_spi{ }; spi5_pins: spi5 { - pins_spi{ + pins_spi { pinmux = <PINMUX_GPIO13__FUNC_SPI5_MI>, <PINMUX_GPIO14__FUNC_SPI5_CSB>, <PINMUX_GPIO15__FUNC_SPI5_MO>,
arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts +6 -6
@@ -178,7 +178,7 @@ &mmc1 { &pio { i2c_pins_0: i2c0 { - pins_i2c{ + pins_i2c { pinmux = <PINMUX_GPIO82__FUNC_SDA0>, <PINMUX_GPIO83__FUNC_SCL0>; mediatek,pull-up-adv = <3>;
@@ -187,7 +187,7 @@ pins_i2c{ }; i2c_pins_1: i2c1 { - pins_i2c{ + pins_i2c { pinmux = <PINMUX_GPIO81__FUNC_SDA1>, <PINMUX_GPIO84__FUNC_SCL1>; mediatek,pull-up-adv = <3>;
@@ -196,7 +196,7 @@ pins_i2c{ }; i2c_pins_2: i2c2 { - pins_i2c{ + pins_i2c { pinmux = <PINMUX_GPIO103__FUNC_SCL2>, <PINMUX_GPIO104__FUNC_SDA2>; mediatek,pull-up-adv = <3>;
@@ -205,7 +205,7 @@ pins_i2c{ }; i2c_pins_3: i2c3 { - pins_i2c{ + pins_i2c { pinmux = <PINMUX_GPIO50__FUNC_SCL3>, <PINMUX_GPIO51__FUNC_SDA3>; mediatek,pull-up-adv = <3>;
@@ -214,7 +214,7 @@ pins_i2c{ }; i2c_pins_4: i2c4 { - pins_i2c{ + pins_i2c { pinmux = <PINMUX_GPIO105__FUNC_SCL4>, <PINMUX_GPIO106__FUNC_SDA4>; mediatek,pull-up-adv = <3>;
@@ -223,7 +223,7 @@ pins_i2c{ }; i2c_pins_5: i2c5 { - pins_i2c{ + pins_i2c { pinmux = <PINMUX_GPIO48__FUNC_SCL5>, <PINMUX_GPIO49__FUNC_SDA5>; mediatek,pull-up-adv = <3>;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 149/194 arm64: dts: mt8183: kukui: Fix underscores in node names
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hsin-Yi Wang <[email protected]>
[ Upstream commit 8980c30141d3986beab815d85762b9c67196ed72 ]
Replace underscores with hyphens in pinctrl node names both for consistency and to adhere to the bindings.
--- .../dts/mediatek/mt8183-kukui-jacuzzi.dtsi | 6 +- .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 94 +++++++++---------- 2 files changed, 50 insertions(+), 50 deletions(-)
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi +3 -3
@@ -439,20 +439,20 @@ pins2 { }; touchscreen_pins: touchscreen-pins { - touch_int_odl { + touch-int-odl { pinmux = <PINMUX_GPIO155__FUNC_GPIO155>; input-enable; bias-pull-up; }; - touch_rst_l { + touch-rst-l { pinmux = <PINMUX_GPIO156__FUNC_GPIO156>; output-high; }; }; trackpad_pins: trackpad-pins { - trackpad_int { + trackpad-int { pinmux = <PINMUX_GPIO7__FUNC_GPIO7>; input-enable; bias-disable; /* pulled externally */
arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi +47 -47
344 lines not on this page · raw message
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 150/194 perf: Fix perf_event_validate_size()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Zijlstra <[email protected]>
[ Upstream commit 382c27f4ed28f803b1f1473ac2d8db0afc795a1b ]
Budimir noted that perf_event_validate_size() only checks the size of the newly added event, even though the sizes of all existing events can also change due to not all events having the same read_format.
When we attach the new event, perf_group_attach(), we do re-compute the size for all events.
--- kernel/events/core.c | 61 +++++++++++++++++++++++++++----------------- 1 file changed, 38 insertions(+), 23 deletions(-)
kernel/events/core.c +38 -23
@@ -1812,31 +1812,34 @@ static inline void perf_event__state_init(struct perf_event *event)PERF_EVENT_STATE_INACTIVE ; } -static void __perf_event_read_size (struct perf_event *event,int nr_siblings) +static int __perf_event_read_size (u64 read_format,int nr_siblings) {int entry =sizeof (u64);/* value */ int size =0 ;int nr =1 ; -if (event->attr.read_format &PERF_FORMAT_TOTAL_TIME_ENABLED ) +if (read_format &PERF_FORMAT_TOTAL_TIME_ENABLED ) size +=sizeof (u64); -if (event->attr.read_format &PERF_FORMAT_TOTAL_TIME_RUNNING ) +if (read_format &PERF_FORMAT_TOTAL_TIME_RUNNING ) size +=sizeof (u64); -if (event->attr.read_format &PERF_FORMAT_ID ) +if (read_format &PERF_FORMAT_ID ) entry +=sizeof (u64); -if (event->attr.read_format &PERF_FORMAT_LOST ) +if (read_format &PERF_FORMAT_LOST ) entry +=sizeof (u64); -if (event->attr.read_format &PERF_FORMAT_GROUP ) { +if (read_format &PERF_FORMAT_GROUP ) { nr += nr_siblings; size +=sizeof (u64); } - size += entry * nr; - event->read_size = size; +/* +* Since perf_event_validate_size() limits this to 16k and inhibits +* adding more siblings, this will never overflow. +*/ +return size + nr * entry; }static void __perf_event_header_size (struct perf_event *event,u64 sample_type)
@@ -1886,8 +1889,9 @@ static void __perf_event_header_size(struct perf_event *event, u64 sample_type)*/ static void perf_event__header_size (struct perf_event *event) { -__perf_event_read_size (event, - event->group_leader->nr_siblings); + event->read_size = +__perf_event_read_size (event->attr.read_format, + event->group_leader->nr_siblings);__perf_event_header_size (event, event->attr.sample_type); }
@@ -1918,24 +1922,35 @@ static void perf_event__id_header_size(struct perf_event *event) event->id_header_size = size; } +/* +* Check that adding an event to the group does not result in anybody +* overflowing the 64k event limit imposed by the output buffer. +* +* Specifically, check that the read_size for the event does not exceed 16k, +* read_size being the one term that grows with groups size. Since read_size +* depends on per-event read_format, also (re)check the existing events. +* +* This leaves 48k for the constant size fields and things like callchains, +* branch stacks and register sets. +*/ static bool perf_event_validate_size (struct perf_event *event) { -/* -* The values computed here will be over-written when we actually -* attach the event. -*/ -__perf_event_read_size (event, event->group_leader->nr_siblings +1 ); -__perf_event_header_size (event, event->attr.sample_type & ~PERF_SAMPLE_READ ); -perf_event__id_header_size (event); +struct perf_event *sibling, *group_leader = event->group_leader; -/* -* Sum the lot; should not exceed the 64k limit we have on records. -* Conservative limit to allow for callchains and other variable fields. -*/ -if (event->read_size + event->header_size + - event->id_header_size +sizeof (struct perf_event_header ) >=16 *1024 ) +if (__perf_event_read_size (event->attr.read_format, + group_leader->nr_siblings +1 ) >16 *1024 )return false; +if (__perf_event_read_size (group_leader->attr.read_format, + group_leader->nr_siblings +1 ) >16 *1024 ) +return false; + +for_each_sibling_event (sibling, group_leader) { +if (__perf_event_read_size (sibling->attr.read_format, + group_leader->nr_siblings +1 ) >16 *1024 ) +return false; + } +return true; }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 151/194 x86/sev: Fix kernel crash due to late update to read-only ghcb_version
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ashwin Dayanand Kamat <[email protected]>
[ Upstream commit 27d25348d42161837be08fc63b04a2559d2e781c ]
A write-access violation page fault kernel crash was observed while running cpuhotplug LTP testcases on SEV-ES enabled systems. The crash was observed during hotplug, after the CPU was offlined and the process was migrated to different CPU. setup_ghcb() is called again which tries to update ghcb_version in sev_es_negotiate_protocol(). Ideally this is a read_only variable which is initialised during booting.
Trying to write it results in a pagefault:
BUG: unable to handle page fault for address: ffffffffba556e70 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation [ ...] Call Trace: <TASK> ? __die_body.cold+0x1a/0x1f ? __die+0x2a/0x35 ? page_fault_oops+0x10c/0x270 ? setup_ghcb+0x71/0x100 ? __x86_return_thunk+0x5/0x6 ? search_exception_tables+0x60/0x70 ? __x86_return_thunk+0x5/0x6 ? fixup_exception+0x27/0x320 ? kernelmode_fixup_or_oops+0xa2/0x120 ? __bad_area_nosemaphore+0x16a/0x1b0 ? kernel_exc_vmm_communication+0x60/0xb0 ? bad_area_nosemaphore+0x16/0x20 ? do_kern_addr_fault+0x7a/0x90 ? exc_page_fault+0xbd/0x160 ? asm_exc_page_fault+0x27/0x30 ? setup_ghcb+0x71/0x100 ? setup_ghcb+0xe/0x100 cpu_init_exception_handling+0x1b9/0x1f0
The fix is to call sev_es_negotiate_protocol() only in the BSP boot phase, and it only needs to be done once in any case.
[ mingo: Refined the changelog. ]
--- arch/x86/kernel/sev.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
arch/x86/kernel/sev.c +7 -4
@@ -1279,10 +1279,6 @@ void setup_ghcb(void)if (!cc_platform_has (CC_ATTR_GUEST_STATE_ENCRYPT ))return ; -/* First make sure the hypervisor talks a supported protocol. */ -if (!sev_es_negotiate_protocol ()) -sev_es_terminate (SEV_TERM_SET_GEN ,GHCB_SEV_ES_GEN_REQ ); -/* * Check whether the runtime #VC exception handler is active. It uses * the per-CPU GHCB page which is set up by sev_es_init_vc_handling().
@@ -1297,6 +1293,13 @@ void setup_ghcb(void)return ; } +/* +* Make sure the hypervisor talks a supported protocol. +* This gets called only in the BSP boot phase. +*/ +if (!sev_es_negotiate_protocol ()) +sev_es_terminate (SEV_TERM_SET_GEN ,GHCB_SEV_ES_GEN_REQ ); +/* * Clear the boot_ghcb. The first exception comes in before the bss * section is cleared.
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 152/194 gpiolib: sysfs: Fix error handling on failed export
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Boerge Struempfel <[email protected]>
[ Upstream commit 95dd1e34ff5bbee93a28ff3947eceaf6de811b1a ]
If gpio_set_transitory() fails, we should free the GPIO again. Most notably, the flag FLAG_REQUESTED has previously been set in gpiod_request_commit(), and should be reset on failure.
To my knowledge, this does not affect any current users, since the gpio_set_transitory() mainly returns 0 and -ENOTSUPP, which is converted to 0. However the gpio_set_transitory() function calles the .set_config() function of the corresponding GPIO chip and there are some GPIO drivers in which some (unlikely) branches return other values like -EPROBE_DEFER, and -EINVAL. In these cases, the above mentioned FLAG_REQUESTED would not be reset, which results in the pin being blocked until the next reboot.
--- drivers/gpio/gpiolib-sysfs.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)
drivers/gpio/gpiolib-sysfs.c +9 -6
@@ -463,14 +463,17 @@ static ssize_t export_store(struct class *class, goto done; status =gpiod_set_transitory (desc, false); -if (!status) { - status =gpiod_export (desc, true); -if (status <0 ) -gpiod_free (desc); -else -set_bit (FLAG_SYSFS , &desc->flags); +if (status) { +gpiod_free (desc); + goto done; } + status =gpiod_export (desc, true); +if (status <0 ) +gpiod_free (desc); +else +set_bit (FLAG_SYSFS , &desc->flags); + done:if (status)pr_debug ("%s: status %d\n" , __func__, status);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 153/194 drm/amdgpu: fix memory overflow in the IB test
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tim Huang <[email protected]>
[ Upstream commit 6b0b7789a7a5f3e69185449f891beea58e563f9b ]
Fix a memory overflow issue in the gfx IB test for some ASICs. At least 20 bytes are needed for the IB test packet.
v2: correct code indentation errors. (Christian)
--- drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 4 ++-- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-)
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c +1 -1
@@ -397,7 +397,7 @@ static int gfx_v11_0_ring_test_ib(struct amdgpu_ring *ring, long timeout) adev->wb.wb[index] =cpu_to_le32 (0xCAFEDEAD ); cpu_ptr = &adev->wb.wb[index]; - r =amdgpu_ib_get (adev,NULL ,16 ,AMDGPU_IB_POOL_DIRECT , &ib); + r =amdgpu_ib_get (adev,NULL ,20 ,AMDGPU_IB_POOL_DIRECT , &ib);if (r) {DRM_ERROR ("amdgpu: failed to get ib (%ld).\n" , r); goto err1;
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c +2 -2
@@ -883,8 +883,8 @@ static int gfx_v8_0_ring_test_ib(struct amdgpu_ring *ring, long timeout) gpu_addr = adev->wb.gpu_addr + (index *4 ); adev->wb.wb[index] =cpu_to_le32 (0xCAFEDEAD );memset (&ib,0 ,sizeof (ib)); - r =amdgpu_ib_get (adev,NULL ,16 , -AMDGPU_IB_POOL_DIRECT , &ib); + + r =amdgpu_ib_get (adev,NULL ,20 ,AMDGPU_IB_POOL_DIRECT , &ib);if (r) goto err1;
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c +2 -2
@@ -1034,8 +1034,8 @@ static int gfx_v9_0_ring_test_ib(struct amdgpu_ring *ring, long timeout) gpu_addr = adev->wb.gpu_addr + (index *4 ); adev->wb.wb[index] =cpu_to_le32 (0xCAFEDEAD );memset (&ib,0 ,sizeof (ib)); - r =amdgpu_ib_get (adev,NULL ,16 , -AMDGPU_IB_POOL_DIRECT , &ib); + + r =amdgpu_ib_get (adev,NULL ,20 ,AMDGPU_IB_POOL_DIRECT , &ib);if (r) goto err1;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 154/194 drm/amd/amdgpu: Fix warnings in amdgpu/amdgpu_display.c
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinivasan Shanmugam <[email protected]>
[ Upstream commit 93125cb704919f572c01e02ef64923caff1c3164 ]
Fixes the below checkpatch.pl warnings:
WARNING: Block comments use * on subsequent lines
WARNING: Block comments use a trailing */ on a separate line
WARNING: suspect code indent for conditional statements (8, 12)
WARNING: braces {} are not necessary for single statement blocks
Stable-dep-of: c6df7f313794 ("drm/amdgpu: correct the amdgpu runtime dereference usage count")
--- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 42 ++++++++++++--------- 1 file changed, 25 insertions(+), 17 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c +25 -17
@@ -90,7 +90,7 @@ static void amdgpu_display_flip_work_func(struct work_struct *__work)struct drm_crtc *crtc = &amdgpu_crtc->base;unsigned long flags; -unsigned i; +unsigned int i;int vpos, hpos;for (i =0 ; i < work->shared_count; ++i)
@@ -167,7 +167,7 @@ int amdgpu_display_crtc_page_flip_target(struct drm_crtc *crtc,u64 tiling_flags;int i, r; - work =kzalloc (sizeof *work,GFP_KERNEL ); + work =kzalloc (sizeof (*work),GFP_KERNEL );if (work ==NULL )return -ENOMEM ;
@@ -298,13 +298,15 @@ int amdgpu_display_crtc_set_config(struct drm_mode_set *set, adev =drm_to_adev (dev);/* if we have active crtcs and we don't have a power ref, -take the current one */ +* take the current one +*/ if (active && !adev->have_disp_power_ref) { adev->have_disp_power_ref = true;return ret; }/* if we have no active crtcs, then drop the power ref -we got before */ +* we got before +*/ if (!active && adev->have_disp_power_ref) {pm_runtime_put_autosuspend (dev->dev); adev->have_disp_power_ref = false;
@@ -473,11 +475,10 @@ bool amdgpu_display_ddc_probe(struct amdgpu_connector *amdgpu_connector,if (amdgpu_connector->router.ddc_valid)amdgpu_i2c_router_select_ddc_port (amdgpu_connector); -if (use_aux) { +if (use_aux) ret =i2c_transfer (&amdgpu_connector->ddc_bus->aux.ddc, msgs,2 ); - }else { +else ret =i2c_transfer (&amdgpu_connector->ddc_bus->adapter, msgs,2 ); - }if (ret !=2 )/* Couldn't find an accessible DDC on this connector */
@@ -486,10 +487,12 @@ bool amdgpu_display_ddc_probe(struct amdgpu_connector *amdgpu_connector,* EDID header starts with: * 0x00,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0x00. * Only the first 6 bytes must be valid as -* drm_edid_block_valid() can fix the last 2 bytes */ +* drm_edid_block_valid() can fix the last 2 bytes +*/ if (drm_edid_header_is_valid (buf) <6 ) {/* Couldn't find an accessible EDID on this -* connector */ +* connector +*/ return false; }return true;
@@ -1204,8 +1207,10 @@ amdgpu_display_user_framebuffer_create(struct drm_device *dev, obj =drm_gem_object_lookup (file_priv, mode_cmd->handles[0 ]);if (obj ==NULL ) { -drm_dbg_kms (dev,"No GEM object associated to handle 0x%08X, " -"can't create framebuffer\n" , mode_cmd->handles[0 ]); +drm_dbg_kms (dev, +"No GEM object associated to handle 0x%08X, can't create framebuffer\n" , + mode_cmd->handles[0 ]); +return ERR_PTR (-ENOENT ); }
@@ -1398,6 +1403,7 @@ bool amdgpu_display_crtc_scaling_mode_fixup(struct drm_crtc *crtc, }if (amdgpu_crtc->rmx_type !=RMX_OFF ) {fixed20_12 a, b; + a.full =dfixed_const (src_v); b.full =dfixed_const (dst_v); amdgpu_crtc->vsc.full =dfixed_div (a, b);
@@ -1417,7 +1423,7 @@ bool amdgpu_display_crtc_scaling_mode_fixup(struct drm_crtc *crtc,* * \param dev Device to query. * \param pipe Crtc to query. -* \param flags Flags from caller (DRM_CALLED_FROM_VBLIRQ or 0). +* \param flags from caller (DRM_CALLED_FROM_VBLIRQ or 0). * For driver internal use only also supports these flags: * * USE_REAL_VBLANKSTART to use the real start of vblank instead
@@ -1493,8 +1499,8 @@ int amdgpu_display_get_crtc_scanoutpos(struct drm_device *dev,/* Called from driver internal vblank counter query code? */ if (flags &GET_DISTANCE_TO_VBLANKSTART ) { -/* Caller wants distance from real vbl_start in *hpos */ - *hpos = *vpos - vbl_start; +/* Caller wants distance from real vbl_start in *hpos */ + *hpos = *vpos - vbl_start; }/* Fudge vblank to start a few scanlines earlier to handle the
@@ -1516,7 +1522,7 @@ int amdgpu_display_get_crtc_scanoutpos(struct drm_device *dev,/* In vblank? */ if (in_vbl) - ret |=DRM_SCANOUTPOS_IN_VBLANK ; + ret |=DRM_SCANOUTPOS_IN_VBLANK ;/* Called from driver internal vblank counter query code? */ if (flags &GET_DISTANCE_TO_VBLANKSTART ) {
@@ -1622,6 +1628,7 @@ int amdgpu_display_suspend_helper(struct amdgpu_device *adev)if (amdgpu_crtc->cursor_bo && !adev->enable_virtual_display) {struct amdgpu_bo *aobj =gem_to_amdgpu_bo (amdgpu_crtc->cursor_bo); + r =amdgpu_bo_reserve (aobj, true);if (r ==0 ) {amdgpu_bo_unpin (aobj);
@@ -1629,9 +1636,9 @@ int amdgpu_display_suspend_helper(struct amdgpu_device *adev) } } -if (fb ==NULL || fb->obj[0 ] ==NULL ) { +if (!fb || !fb->obj[0 ])continue ; - } + robj =gem_to_amdgpu_bo (fb->obj[0 ]);if (!amdgpu_display_robj_is_fb (adev, robj)) { r =amdgpu_bo_reserve (robj, true);
@@ -1658,6 +1665,7 @@ int amdgpu_display_resume_helper(struct amdgpu_device *adev)if (amdgpu_crtc->cursor_bo && !adev->enable_virtual_display) {struct amdgpu_bo *aobj =gem_to_amdgpu_bo (amdgpu_crtc->cursor_bo); + r =amdgpu_bo_reserve (aobj, true);if (r ==0 ) { r =amdgpu_bo_pin (aobj,AMDGPU_GEM_DOMAIN_VRAM );
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 155/194 drm/amdgpu: correct the amdgpu runtime dereference usage count
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Prike Liang <[email protected]>
[ Upstream commit c6df7f313794c3ad41a49b9a7c95da369db607f3 ]
Fix the amdgpu runpm dereference usage count.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c +3 -6
@@ -304,14 +304,11 @@ int amdgpu_display_crtc_set_config(struct drm_mode_set *set, adev->have_disp_power_ref = true;return ret; } -/* if we have no active crtcs, then drop the power ref -* we got before +/* if we have no active crtcs, then go to +* drop the power ref we got before */ -if (!active && adev->have_disp_power_ref) { -pm_runtime_put_autosuspend (dev->dev); +if (!active && adev->have_disp_power_ref) adev->have_disp_power_ref = false; - } - out:/* drop the power reference we got coming in here */ pm_runtime_put_autosuspend (dev->dev);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 156/194 drm/amdgpu: Update ras eeprom support for smu v13_0_0 and v13_0_10
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Candice Li <[email protected]>
[ Upstream commit bc22f8ec464af9e14263c3ed6a1c2be86618c804 ]
Enable RAS EEPROM support for smu v13_0_0 and v13_0_10.
Stable-dep-of: e0409021e34a ("drm/amdgpu: Update EEPROM I2C address for smu v13_0_0")
--- drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c +10 -0
@@ -90,6 +90,16 @@static bool __is_ras_eeprom_supported (struct amdgpu_device *adev) { +if (adev->asic_type ==CHIP_IP_DISCOVERY ) { +switch (adev->ip_versions[MP1_HWIP ][0 ]) { +case IP_VERSION (13 ,0 ,0 ): +case IP_VERSION (13 ,0 ,10 ): +return true; +default : +return false; + } + } +return adev->asic_type ==CHIP_VEGA20 || adev->asic_type ==CHIP_ARCTURUS || adev->asic_type == CHIP_SIENNA_CICHLID ||
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 157/194 drm/amdgpu: Add EEPROM I2C address support for ip discovery
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Candice Li <[email protected]>
[ Upstream commit c9bdc6c3cf39df6db9c611d05fc512b1276b1cc8 ]
1. Update EEPROM_I2C_MADDR_SMU_13_0_0 to EEPROM_I2C_MADDR_54H
2. Add EEPROM I2C address support for smu v13_0_0 and v13_0_10.
Stable-dep-of: e0409021e34a ("drm/amdgpu: Update EEPROM I2C address for smu v13_0_0")
--- .../gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 20 +++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c +18 -2
@@ -38,7 +38,7 @@#define EEPROM_I2C_MADDR_ARCTURUS_D342 0x0#define EEPROM_I2C_MADDR_SIENNA_CICHLID 0x0#define EEPROM_I2C_MADDR_ALDEBARAN 0x0 -#define EEPROM_I2C_MADDR_SMU_13_0_0 (0x54UL << 16) +#define EEPROM_I2C_MADDR_54H (0x54UL << 16)/* * The 2 macros bellow represent the actual size in bytes that
@@ -124,6 +124,19 @@ static bool __get_eeprom_i2c_addr_arct(struct amdgpu_device *adev,return true; } +static bool __get_eeprom_i2c_addr_ip_discovery (struct amdgpu_device *adev, +struct amdgpu_ras_eeprom_control *control) +{ +switch (adev->ip_versions[MP1_HWIP ][0 ]) { +case IP_VERSION (13 ,0 ,0 ): +case IP_VERSION (13 ,0 ,10 ): + control->i2c_address =EEPROM_I2C_MADDR_54H ; +return true; +default : +return false; + } +} +static bool __get_eeprom_i2c_addr (struct amdgpu_device *adev,struct amdgpu_ras_eeprom_control *control) {
@@ -163,13 +176,16 @@ static bool __get_eeprom_i2c_addr(struct amdgpu_device *adev, control->i2c_address =EEPROM_I2C_MADDR_ALDEBARAN ;break ; +case CHIP_IP_DISCOVERY : +return __get_eeprom_i2c_addr_ip_discovery (adev, control); +default :return false; }switch (adev->ip_versions[MP1_HWIP ][0 ]) {case IP_VERSION (13 ,0 ,0 ): - control->i2c_address =EEPROM_I2C_MADDR_SMU_13_0_0 ; + control->i2c_address =EEPROM_I2C_MADDR_54H ;break ;default :
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 158/194 drm/amdgpu: Remove redundant I2C EEPROM address
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luben Tuikov <[email protected]>
[ Upstream commit da858deab88eb561f2196bc99b6dbd2320e56456 ]
Remove redundant EEPROM_I2C_MADDR_54H address, since we already have it represented (ARCTURUS), and since we don't include the I2C device type identifier in EEPROM memory addresses, i.e. that high up in the device abstraction--we only use EEPROM memory addresses, as memory is continuously represented by EEPROM device(s) on the I2C bus.
Add a comment describing what these memory addresses are, how they come about and how they're usually extracted from the device address byte.
Stable-dep-of: e0409021e34a ("drm/amdgpu: Update EEPROM I2C address for smu v13_0_0")
--- drivers/gpu/drm/amd/amdgpu/amdgpu_eeprom.c | 2 ++ .../gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 24 ++++++++++++++++--- 2 files changed, 23 insertions(+), 3 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_eeprom.c +2 -0
@@ -79,6 +79,8 @@* That is, for an I2C EEPROM driver everything is controlled by * the "eeprom_addr". * +* See also top of amdgpu_ras_eeprom.c. +* * P.S. If you need to write, lock and read the Identification Page, * (M24M02-DR device only, which we do not use), change the "7" to * "0xF" in the macro below, and let the client set bit 20 to 1 in
drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c +21 -3
@@ -33,12 +33,30 @@#include "amdgpu_reset.h" +/* These are memory addresses as would be seen by one or more EEPROM +* chips strung on the I2C bus, usually by manipulating pins 1-3 of a +* set of EEPROM devices. They form a continuous memory space. +* +* The I2C device address includes the device type identifier, 1010b, +* which is a reserved value and indicates that this is an I2C EEPROM +* device. It also includes the top 3 bits of the 19 bit EEPROM memory +* address, namely bits 18, 17, and 16. This makes up the 7 bit +* address sent on the I2C bus with bit 0 being the direction bit, +* which is not represented here, and sent by the hardware directly. +* +* For instance, +* 50h = 1010000b => device type identifier 1010b, bits 18:16 = 000b, address 0. +* 54h = 1010100b => --"--, bits 18:16 = 100b, address 40000h. +* 56h = 1010110b => --"--, bits 18:16 = 110b, address 60000h. +* Depending on the size of the I2C EEPROM device(s), bits 18:16 may +* address memory in a device or a device on the I2C bus, depending on +* the status of pins 1-3. See top of amdgpu_eeprom.c. +*/ #define EEPROM_I2C_MADDR_VEGA20 0x0#define EEPROM_I2C_MADDR_ARCTURUS 0x40000#define EEPROM_I2C_MADDR_ARCTURUS_D342 0x0#define EEPROM_I2C_MADDR_SIENNA_CICHLID 0x0#define EEPROM_I2C_MADDR_ALDEBARAN 0x0 -#define EEPROM_I2C_MADDR_54H (0x54UL << 16)/* * The 2 macros bellow represent the actual size in bytes that
@@ -130,7 +148,7 @@ static bool __get_eeprom_i2c_addr_ip_discovery(struct amdgpu_device *adev,switch (adev->ip_versions[MP1_HWIP ][0 ]) {case IP_VERSION (13 ,0 ,0 ):case IP_VERSION (13 ,0 ,10 ): - control->i2c_address =EEPROM_I2C_MADDR_54H ; + control->i2c_address =EEPROM_I2C_MADDR_ARCTURUS ;return true;default :return false;
@@ -185,7 +203,7 @@ static bool __get_eeprom_i2c_addr(struct amdgpu_device *adev,switch (adev->ip_versions[MP1_HWIP ][0 ]) {case IP_VERSION (13 ,0 ,0 ): - control->i2c_address =EEPROM_I2C_MADDR_54H ; + control->i2c_address =EEPROM_I2C_MADDR_ARCTURUS ;break ;default :
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 159/194 drm/amdgpu: Decouple RAS EEPROM addresses from chips
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luben Tuikov <[email protected]>
[ Upstream commit 3b8164f8084ff7888ed24970efa230ff5d36eda8 ]
Abstract RAS I2C EEPROM addresses from chip names, and set their macro definition names to the address they set, not the chip they attach to. Since most chips either use I2C EEPROM address 0 or 40000h for the RAS table start offset, this leaves us with only two macro definitions as opposed to five, and removes the redundancy of four.
Stable-dep-of: e0409021e34a ("drm/amdgpu: Update EEPROM I2C address for smu v13_0_0")
--- .../gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 23 +++++++++---------- 1 file changed, 11 insertions(+), 12 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c +11 -12
@@ -51,12 +51,11 @@* Depending on the size of the I2C EEPROM device(s), bits 18:16 may * address memory in a device or a device on the I2C bus, depending on * the status of pins 1-3. See top of amdgpu_eeprom.c. +* +* The RAS table lives either at address 0 or address 40000h of EEPROM. */ -#define EEPROM_I2C_MADDR_VEGA20 0x0 -#define EEPROM_I2C_MADDR_ARCTURUS 0x40000 -#define EEPROM_I2C_MADDR_ARCTURUS_D342 0x0 -#define EEPROM_I2C_MADDR_SIENNA_CICHLID 0x0 -#define EEPROM_I2C_MADDR_ALDEBARAN 0x0 +#define EEPROM_I2C_MADDR_0 0x0 +#define EEPROM_I2C_MADDR_4 0x40000/* * The 2 macros bellow represent the actual size in bytes that
@@ -135,9 +134,9 @@ static bool __get_eeprom_i2c_addr_arct(struct amdgpu_device *adev,if (strnstr (atom_ctx->vbios_version,"D342" ,sizeof (atom_ctx->vbios_version))) - control->i2c_address =EEPROM_I2C_MADDR_ARCTURUS_D342 ; + control->i2c_address =EEPROM_I2C_MADDR_0 ;else - control->i2c_address =EEPROM_I2C_MADDR_ARCTURUS ; + control->i2c_address =EEPROM_I2C_MADDR_4 ;return true; }
@@ -148,7 +147,7 @@ static bool __get_eeprom_i2c_addr_ip_discovery(struct amdgpu_device *adev,switch (adev->ip_versions[MP1_HWIP ][0 ]) {case IP_VERSION (13 ,0 ,0 ):case IP_VERSION (13 ,0 ,10 ): - control->i2c_address =EEPROM_I2C_MADDR_ARCTURUS ; + control->i2c_address =EEPROM_I2C_MADDR_4 ;return true;default :return false;
@@ -180,18 +179,18 @@ static bool __get_eeprom_i2c_addr(struct amdgpu_device *adev,switch (adev->asic_type) {case CHIP_VEGA20 : - control->i2c_address =EEPROM_I2C_MADDR_VEGA20 ; + control->i2c_address =EEPROM_I2C_MADDR_0 ;break ;case CHIP_ARCTURUS :return __get_eeprom_i2c_addr_arct (adev, control);case CHIP_SIENNA_CICHLID : - control->i2c_address =EEPROM_I2C_MADDR_SIENNA_CICHLID ; + control->i2c_address =EEPROM_I2C_MADDR_0 ;break ;case CHIP_ALDEBARAN : - control->i2c_address =EEPROM_I2C_MADDR_ALDEBARAN ; + control->i2c_address =EEPROM_I2C_MADDR_0 ;break ;case CHIP_IP_DISCOVERY :
@@ -203,7 +202,7 @@ static bool __get_eeprom_i2c_addr(struct amdgpu_device *adev,switch (adev->ip_versions[MP1_HWIP ][0 ]) {case IP_VERSION (13 ,0 ,0 ): - control->i2c_address =EEPROM_I2C_MADDR_ARCTURUS ; + control->i2c_address =EEPROM_I2C_MADDR_4 ;break ;default :
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 160/194 drm/amdgpu: Add support for RAS table at 0x40000
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luben Tuikov <[email protected]>
[ Upstream commit 64a3dbb06ad88d89a0958ccafc4f01611657f641 ]
Add support for RAS table at I2C EEPROM address of 0x40000, since on some ASICs it is not at 0, but at 0x40000.
Stable-dep-of: e0409021e34a ("drm/amdgpu: Update EEPROM I2C address for smu v13_0_0")
--- drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c +6 -1
@@ -157,6 +157,7 @@ static bool __get_eeprom_i2c_addr_ip_discovery(struct amdgpu_device *adev,static bool __get_eeprom_i2c_addr (struct amdgpu_device *adev,struct amdgpu_ras_eeprom_control *control) { +struct atom_context *atom_ctx = adev->mode_info.atom_context;u8 i2c_addr;if (!control)
@@ -190,7 +191,11 @@ static bool __get_eeprom_i2c_addr(struct amdgpu_device *adev,break ;case CHIP_ALDEBARAN : - control->i2c_address =EEPROM_I2C_MADDR_0 ; +if (strnstr (atom_ctx->vbios_version,"D673" , +sizeof (atom_ctx->vbios_version))) + control->i2c_address =EEPROM_I2C_MADDR_4 ; +else + control->i2c_address =EEPROM_I2C_MADDR_0 ;break ;case CHIP_IP_DISCOVERY :
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 161/194 drm/amdgpu: Remove second moot switch to set EEPROM I2C address
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luben Tuikov <[email protected]>
[ Upstream commit 1bb745d7596d2b368fd9afb90473f3581495e39d ]
Remove second switch since it already has its own function and case in the first switch. This also avoids requalifying the EEPROM I2C address for VEGA20, SIENNA CICHLID, and ALDEBARAN, as those have been set by the first switch and shouldn't match SMU v13.0.x.
Stable-dep-of: e0409021e34a ("drm/amdgpu: Update EEPROM I2C address for smu v13_0_0")
--- drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 9 --------- 1 file changed, 9 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c +0 -9
@@ -205,15 +205,6 @@ static bool __get_eeprom_i2c_addr(struct amdgpu_device *adev,return false; } -switch (adev->ip_versions[MP1_HWIP ][0 ]) { -case IP_VERSION (13 ,0 ,0 ): - control->i2c_address =EEPROM_I2C_MADDR_4 ; -break ; - -default : -break ; - } -return true; }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 162/194 drm/amdgpu: Return from switch early for EEPROM I2C address
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luben Tuikov <[email protected]>
[ Upstream commit 8782007b5f5795f118c5167f46d8c8142abcc92f ]
As soon as control->i2c_address is set, return; remove the "break;" from the switch--it is unnecessary. This mimics what happens when for some cases in the switch, we call helper functions with "return <helper function>".
Remove final function "return true;" to indicate that the switch is final and terminal, and that there should be no code after the switch.
Stable-dep-of: e0409021e34a ("drm/amdgpu: Update EEPROM I2C address for smu v13_0_0")
--- drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c +3 -5
@@ -181,14 +181,14 @@ static bool __get_eeprom_i2c_addr(struct amdgpu_device *adev,switch (adev->asic_type) {case CHIP_VEGA20 : control->i2c_address =EEPROM_I2C_MADDR_0 ; -break ; +return true;case CHIP_ARCTURUS :return __get_eeprom_i2c_addr_arct (adev, control);case CHIP_SIENNA_CICHLID : control->i2c_address =EEPROM_I2C_MADDR_0 ; -break ; +return true;case CHIP_ALDEBARAN : if (strnstr(atom_ctx->vbios_version, "D673",
@@ -196,7 +196,7 @@ static bool __get_eeprom_i2c_addr(struct amdgpu_device *adev, control->i2c_address =EEPROM_I2C_MADDR_4 ; else control->i2c_address = EEPROM_I2C_MADDR_0; -break ; +return true;case CHIP_IP_DISCOVERY :return __get_eeprom_i2c_addr_ip_discovery (adev, control);
@@ -204,8 +204,6 @@ static bool __get_eeprom_i2c_addr(struct amdgpu_device *adev,default :return false; } - -return true; } static void
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 163/194 drm/amdgpu: simplify amdgpu_ras_eeprom.c
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
[ Upstream commit 6246059a19d4cd32ef1af42a6ab016b779cd68c4 ]
All chips that support RAS also support IP discovery, so use the IP versions rather than a mix of IP versions and asic types. Checking the validity of the atom_ctx pointer is not required as the vbios is already fetched at this point.
v2: add comments to id asic types based on feedback from Luben
Stable-dep-of: e0409021e34a ("drm/amdgpu: Update EEPROM I2C address for smu v13_0_0")
--- .../gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 72 ++++++------------- 1 file changed, 20 insertions(+), 52 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c +20 -52
@@ -106,48 +106,13 @@#define to_amdgpu_device (x) (container_of(x, struct amdgpu_ras, eeprom_control))->adevstatic bool __is_ras_eeprom_supported (struct amdgpu_device *adev) -{ -if (adev->asic_type ==CHIP_IP_DISCOVERY ) { -switch (adev->ip_versions[MP1_HWIP ][0 ]) { -case IP_VERSION (13 ,0 ,0 ): -case IP_VERSION (13 ,0 ,10 ): -return true; -default : -return false; - } - } - -return adev->asic_type ==CHIP_VEGA20 || - adev->asic_type ==CHIP_ARCTURUS || - adev->asic_type ==CHIP_SIENNA_CICHLID || - adev->asic_type ==CHIP_ALDEBARAN ; -} - -static bool __get_eeprom_i2c_addr_arct (struct amdgpu_device *adev, -struct amdgpu_ras_eeprom_control *control) -{ -struct atom_context *atom_ctx = adev->mode_info.atom_context; - -if (!control || !atom_ctx) -return false; - -if (strnstr (atom_ctx->vbios_version, -"D342" , -sizeof (atom_ctx->vbios_version))) - control->i2c_address =EEPROM_I2C_MADDR_0 ; -else - control->i2c_address =EEPROM_I2C_MADDR_4 ; - -return true; -} - -static bool __get_eeprom_i2c_addr_ip_discovery (struct amdgpu_device *adev, -struct amdgpu_ras_eeprom_control *control) {switch (adev->ip_versions[MP1_HWIP ][0 ]) { +case IP_VERSION (11 ,0 ,2 ):/* VEGA20 and ARCTURUS */ +case IP_VERSION (11 ,0 ,7 ):/* Sienna cichlid */ case IP_VERSION (13 ,0 ,0 ): +case IP_VERSION (13 ,0 ,2 ):/* Aldebaran */ case IP_VERSION (13 ,0 ,10 ): - control->i2c_address =EEPROM_I2C_MADDR_4 ;return true;default :return false;
@@ -178,29 +143,32 @@ static bool __get_eeprom_i2c_addr(struct amdgpu_device *adev,return true; } -switch (adev->asic_type) { -case CHIP_VEGA20 : - control->i2c_address =EEPROM_I2C_MADDR_0 ; +switch (adev->ip_versions[MP1_HWIP ][0 ]) { +case IP_VERSION (11 ,0 ,2 ): +/* VEGA20 and ARCTURUS */ +if (adev->asic_type ==CHIP_VEGA20 ) + control->i2c_address =EEPROM_I2C_MADDR_0 ; +else if (strnstr (atom_ctx->vbios_version, +"D342" , +sizeof (atom_ctx->vbios_version))) + control->i2c_address =EEPROM_I2C_MADDR_0 ; +else + control->i2c_address =EEPROM_I2C_MADDR_4 ;return true; - -case CHIP_ARCTURUS : -return __get_eeprom_i2c_addr_arct (adev, control); - -case CHIP_SIENNA_CICHLID : +case IP_VERSION (11 ,0 ,7 ): control->i2c_address =EEPROM_I2C_MADDR_0 ;return true; - -case CHIP_ALDEBARAN : +case IP_VERSION (13 ,0 ,2 ):if (strnstr (atom_ctx->vbios_version,"D673" ,sizeof (atom_ctx->vbios_version))) control->i2c_address =EEPROM_I2C_MADDR_4 ;else control->i2c_address =EEPROM_I2C_MADDR_0 ;return true; - -case CHIP_IP_DISCOVERY : -return __get_eeprom_i2c_addr_ip_discovery (adev, control); - +case IP_VERSION (13 ,0 ,0 ): +case IP_VERSION (13 ,0 ,10 ): + control->i2c_address =EEPROM_I2C_MADDR_4 ; +return true;default :return false; }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 164/194 drm/amdgpu: Add I2C EEPROM support on smu v13_0_6
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Candice Li <[email protected]>
[ Upstream commit b81fde0dfe402e864ef1ac506eba756c89f1ad32 ]
Support I2C EEPROM on smu v13_0_6.
v2: Move IP_VERSION(13, 0, 6) ahead of IP_VERSION(13, 0, 10).
Stable-dep-of: e0409021e34a ("drm/amdgpu: Update EEPROM I2C address for smu v13_0_0")
--- drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c +2 -0
@@ -112,6 +112,7 @@ static bool __is_ras_eeprom_supported(struct amdgpu_device *adev)case IP_VERSION (11 ,0 ,7 ):/* Sienna cichlid */ case IP_VERSION (13 ,0 ,0 ):case IP_VERSION (13 ,0 ,2 ):/* Aldebaran */ +case IP_VERSION (13 ,0 ,6 ):case IP_VERSION (13 ,0 ,10 ):return true;default :
@@ -166,6 +167,7 @@ static bool __get_eeprom_i2c_addr(struct amdgpu_device *adev, control->i2c_address =EEPROM_I2C_MADDR_0 ;return true;case IP_VERSION (13 ,0 ,0 ): +case IP_VERSION (13 ,0 ,6 ):case IP_VERSION (13 ,0 ,10 ): control->i2c_address =EEPROM_I2C_MADDR_4 ;return true;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 165/194 drm/amdgpu: Update EEPROM I2C address for smu v13_0_0
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Candice Li <[email protected]>
[ Upstream commit e0409021e34af50e7b6f31635c8d21583d7c43dd ]
Check smu v13_0_0 SKU type to select EEPROM I2C address.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c +6 -0
@@ -167,6 +167,12 @@ static bool __get_eeprom_i2c_addr(struct amdgpu_device *adev, control->i2c_address =EEPROM_I2C_MADDR_0 ;return true;case IP_VERSION (13 ,0 ,0 ): +if (strnstr (atom_ctx->vbios_pn,"D707" , +sizeof (atom_ctx->vbios_pn))) + control->i2c_address =EEPROM_I2C_MADDR_0 ; +else + control->i2c_address =EEPROM_I2C_MADDR_4 ; +return true;case IP_VERSION (13 ,0 ,6 ):case IP_VERSION (13 ,0 ,10 ): control->i2c_address =EEPROM_I2C_MADDR_4 ;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 166/194 usb: gadget: f_hid: fix report descriptor allocation
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Konstantin Aladyshev <[email protected]>
commit 61890dc28f7d9e9aac8a9471302613824c22fae4 upstream.
The commit 89ff3dfac604 ("usb: gadget: f_hid: fix f_hidg lifetime vs cdev") has introduced a bug that leads to hid device corruption after the replug operation.
Reverse device managed memory allocation for the report descriptor to fix the issue.
Tested:
This change was tested on the AMD EthanolX CRB server with the BMC based on the OpenBMC distribution. The BMC provides KVM functionality via the USB gadget device:
- before: KVM page refresh results in a broken USB device,
- after: KVM page refresh works without any issues.
--- drivers/usb/gadget/function/f_hid.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/usb/gadget/function/f_hid.c +4 -3
@@ -88,6 +88,7 @@ static void hidg_release(struct device * { struct f_hidg *hidg = container_of(dev, struct f_hidg, dev); +kfree (hidg->report_desc);kfree (hidg->set_report_buf);kfree (hidg); }
@@ -1287,9 +1288,9 @@ static struct usb_function *hidg_alloc(s hidg->report_length = opts->report_length; hidg->report_desc_length = opts->report_desc_length;if (opts->report_desc) { - hidg->report_desc =devm_kmemdup (&hidg->dev, opts->report_desc, - opts->report_desc_length, -GFP_KERNEL ); + hidg->report_desc =kmemdup (opts->report_desc, + opts->report_desc_length, +GFP_KERNEL );if (!hidg->report_desc) {put_device (&hidg->dev); --opts->refcnt;
Greg Kroah-Hartman
maintainerPATCH 167/194 serial: 8250_dw: Add ACPI ID for Granite Rapids-D UART
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Shevchenko <[email protected]>
commit e92fad024929c79460403acf946bc9c09ce5c3a9 upstream.
Granite Rapids-D has an additional UART that is enumerated via ACPI. Add ACPI ID for it.
--- drivers/tty/serial/8250/8250_dw.c | 1 + 1 file changed, 1 insertion(+)
drivers/tty/serial/8250/8250_dw.c +1 -0
@@ -795,6 +795,7 @@ static const struct acpi_device_id dw825 { "INT33C5", (kernel_ulong_t)&dw8250_dw_apb }, { "INT3434", (kernel_ulong_t)&dw8250_dw_apb }, { "INT3435", (kernel_ulong_t)&dw8250_dw_apb }, + { "INTC10EE", (kernel_ulong_t)&dw8250_dw_apb }, { }, };MODULE_DEVICE_TABLE (acpi, dw8250_acpi_match);
Greg Kroah-Hartman
maintainerPATCH 168/194 parport: Add support for Brainboxes IX/UC/PX parallel cards
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Cameron Williams <[email protected]>
commit 1a031f6edc460e9562098bdedc3918da07c30a6e upstream.
Adds support for Intashield IX-500/IX-550, UC-146/UC-157, PX-146/PX-157, PX-203 and PX-475 (LPT port)
--- drivers/parport/parport_pc.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
drivers/parport/parport_pc.c +21 -0
@@ -2614,6 +2614,8 @@ enum parport_pc_pci_cards { netmos_9865, quatech_sppxp100, wch_ch382l, + brainboxes_uc146, + brainboxes_px203, };
@@ -2678,6 +2680,8 @@ static struct parport_pc_pci { /* netmos_9865 */ { 1, { { 0, -1 }, } }, /* quatech_sppxp100 */ { 1, { { 0, 1 }, } }, /* wch_ch382l */ { 1, { { 2, -1 }, } }, + /* brainboxes_uc146 */ { 1, { { 3, -1 }, } }, + /* brainboxes_px203 */ { 1, { { 0, -1 }, } }, }; static const struct pci_device_id parport_pc_pci_tbl[] = {
@@ -2771,6 +2775,23 @@ static const struct pci_device_id parpor PCI_ANY_ID, PCI_ANY_ID, 0, 0, quatech_sppxp100 }, /* WCH CH382L PCI-E single parallel port card */ { 0x1c00, 0x3050, 0x1c00, 0x3050, 0, 0, wch_ch382l }, +/* Brainboxes IX-500/550 */ + { PCI_VENDOR_ID_INTASHIELD, 0x402a, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, oxsemi_pcie_pport }, +/* Brainboxes UC-146/UC-157 */ + { PCI_VENDOR_ID_INTASHIELD, 0x0be1, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, brainboxes_uc146 }, + { PCI_VENDOR_ID_INTASHIELD, 0x0be2, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, brainboxes_uc146 }, +/* Brainboxes PX-146/PX-257 */ + { PCI_VENDOR_ID_INTASHIELD, 0x401c, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, oxsemi_pcie_pport }, +/* Brainboxes PX-203 */ + { PCI_VENDOR_ID_INTASHIELD, 0x4007, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, brainboxes_px203 }, +/* Brainboxes PX-475 */ + { PCI_VENDOR_ID_INTASHIELD, 0x401f, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, oxsemi_pcie_pport }, { 0, } /* terminate list */ };MODULE_DEVICE_TABLE (pci, parport_pc_pci_tbl);
Greg Kroah-Hartman
maintainerPATCH 169/194 cifs: Fix non-availability of dedup breaking generic/304
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
commit 691a41d8da4b34fe72f09393505f55f28a8f34ec upstream.
Deduplication isn't supported on cifs, but cifs doesn't reject it, instead treating it as extent duplication/cloning. This can cause generic/304 to go silly and run for hours on end.
Fix cifs to indicate EOPNOTSUPP if REMAP_FILE_DEDUP is set in ->remap_file_range().
Note that it's unclear whether or not commit b073a08016a1 is meant to cause cifs to return an error if REMAP_FILE_DEDUP.
--- fs/smb/client/cifsfs.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
fs/smb/client/cifsfs.c +3 -1
@@ -1203,7 +1203,9 @@ static loff_t cifs_remap_file_range(struunsigned int xid;int rc; -if (remap_flags & ~(REMAP_FILE_DEDUP |REMAP_FILE_ADVISORY )) +if (remap_flags &REMAP_FILE_DEDUP ) +return -EOPNOTSUPP ; +if (remap_flags & ~REMAP_FILE_ADVISORY )return -EINVAL ;cifs_dbg (FYI ,"clone range\n" );
Greg Kroah-Hartman
maintainerPATCH 170/194 Revert "xhci: Loosen RPM as default policy to cover for AMD xHC 1.1"
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Nyman <[email protected]>
commit 24be0b3c40594a14b65141ced486ae327398faf8 upstream.
This reverts commit 4baf1218150985ee3ab0a27220456a1f027ea0ac.
Enabling runtime pm as default for all AMD xHC 1.1 controllers caused regression. An initial attempt to fix those was done in commit a5d6264b638e ("xhci: Enable RPM on controllers that support low-power states") but new issues are still seen.
Revert this to get those AMD xHC 1.1 systems working
This patch went to stable an needs to be reverted from there as well.
--- drivers/usb/host/xhci-pci.c | 2 -- 1 file changed, 2 deletions(-)
drivers/usb/host/xhci-pci.c +0 -2
@@ -348,8 +348,6 @@ static void xhci_pci_quirks(struct devic/* xHC spec requires PCI devices to support D3hot and D3cold */ if (xhci->hci_version >=0x120 ) xhci->quirks |=XHCI_DEFAULT_PM_RUNTIME_ALLOW ; -else if (pdev->vendor ==PCI_VENDOR_ID_AMD && xhci->hci_version >=0x110 ) - xhci->quirks |=XHCI_DEFAULT_PM_RUNTIME_ALLOW ;if (xhci->quirks &XHCI_RESET_ON_RESUME ) xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
Greg Kroah-Hartman
maintainerPATCH 171/194 smb: client: fix potential NULL deref in parse_dfs_referrals()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paulo Alcantara <[email protected]>
commit 92414333eb375ed64f4ae92d34d579e826936480 upstream.
If server returned no data for FSCTL_DFS_GET_REFERRALS, @dfs_rsp will remain NULL and then parse_dfs_referrals() will dereference it.
Fix this by returning -EIO when no output data is returned.
Besides, we can't fix it in SMB2_ioctl() as some FSCTLs are allowed to return no data as per MS-SMB2 2.2.32.
--- fs/smb/client/smb2ops.c | 2 ++ 1 file changed, 2 insertions(+)
fs/smb/client/smb2ops.c +2 -0
@@ -2834,6 +2834,8 @@ smb2_get_dfs_refer(const unsigned int xiusleep_range (512 ,2048 ); }while (++retry_count <5 ); +if (!rc && !dfs_rsp) + rc = -EIO ;if (rc) {if (!is_retryable_error (rc) && rc != -ENOENT && rc != -EOPNOTSUPP )cifs_tcon_dbg (VFS ,"%s: ioctl error: rc=%d\n" , __func__, rc);
Greg Kroah-Hartman
maintainerPATCH 172/194 usb: typec: class: fix typec_altmode_put_partner to put plugs
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: RD Babiera <[email protected]>
commit b17b7fe6dd5c6ff74b38b0758ca799cdbb79e26e upstream.
When typec_altmode_put_partner is called by a plug altmode upon release, the port altmode the plug belongs to will not remove its reference to the plug. The check to see if the altmode being released evaluates against the released altmode's partner instead of the calling altmode itself, so change adev in typec_altmode_put_partner to properly refer to the altmode being released.
typec_altmode_set_partner is not run for port altmodes, so also add a check in typec_altmode_release to prevent typec_altmode_put_partner() calls on port altmode release.
--- drivers/usb/typec/class.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/usb/typec/class.c +3 -2
@@ -267,7 +267,7 @@ static void typec_altmode_put_partner(stif (!partner)return ; - adev = &partner->adev; + adev = &altmode->adev;if (is_typec_plug (adev->dev.parent)) {struct typec_plug *plug =to_typec_plug (adev->dev.parent);
@@ -497,7 +497,8 @@ static void typec_altmode_release(struct {struct altmode *alt =to_altmode (to_typec_altmode (dev)); -typec_altmode_put_partner (alt); +if (!is_typec_port (dev->parent)) +typec_altmode_put_partner (alt);altmode_id_remove (alt->adev.dev.parent, alt->id);kfree (alt);
Greg Kroah-Hartman
maintainerPATCH 173/194 ARM: PL011: Fix DMA support
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
commit 58ac1b3799799069d53f5bf95c093f2fe8dd3cc5 upstream.
Since there is no guarantee that the memory returned by dma_alloc_coherent() is associated with a 'struct page', using the architecture specific phys_to_page() is wrong, but using virt_to_page() would be as well.
Stop using sg lists altogether and just use the *_single() functions instead. This also simplifies the code a bit since the scatterlists in this driver always have only one entry anyway.
https://lore.kernel.org/lkml/[email protected]/
Use consistent names for dma buffers
gc: Add a commit log from the initial thread:
https://lore.kernel.org/lkml/[email protected]/
Use consistent names for dma buffers
--- drivers/tty/serial/amba-pl011.c | 112 +++++++++++++++++++--------------------- 1 file changed, 54 insertions(+), 58 deletions(-)
drivers/tty/serial/amba-pl011.c +54 -58
@@ -218,17 +218,18 @@ static struct vendor_data vendor_st = {/* Deals with DMA transactions */ -struct pl011_sgbuf { -struct scatterlist sg; -char *buf; +struct pl011_dmabuf { +dma_addr_t dma; +size_t len; +char *buf; };struct pl011_dmarx_data {struct dma_chan *chan;struct completion complete;bool use_buf_b; -struct pl011_sgbuf sgbuf_a; -struct pl011_sgbuf sgbuf_b; +struct pl011_dmabuf dbuf_a; +struct pl011_dmabuf dbuf_b;dma_cookie_t cookie;bool running;struct timer_list timer;
@@ -241,7 +242,8 @@ struct pl011_dmarx_data {struct pl011_dmatx_data {struct dma_chan *chan; -struct scatterlist sg; +dma_addr_t dma; +size_t len;char *buf;bool queued; };
@@ -365,32 +367,24 @@ static int pl011_fifo_to_tty(struct uart#define PL011_DMA_BUFFER_SIZE PAGE_SIZE -static int pl011_sgbuf_init (struct dma_chan *chan,struct pl011_sgbuf *sg, +static int pl011_dmabuf_init (struct dma_chan *chan,struct pl011_dmabuf *db,enum dma_data_direction dir) { -dma_addr_t dma_addr; - - sg->buf =dma_alloc_coherent (chan->device->dev, -PL011_DMA_BUFFER_SIZE , &dma_addr,GFP_KERNEL ); -if (!sg->buf) + db->buf =dma_alloc_coherent (chan->device->dev,PL011_DMA_BUFFER_SIZE , + &db->dma,GFP_KERNEL ); +if (!db->buf)return -ENOMEM ; - -sg_init_table (&sg->sg,1 ); -sg_set_page (&sg->sg,phys_to_page (dma_addr), -PL011_DMA_BUFFER_SIZE ,offset_in_page (dma_addr)); -sg_dma_address (&sg->sg) = dma_addr; -sg_dma_len (&sg->sg) =PL011_DMA_BUFFER_SIZE ; + db->len =PL011_DMA_BUFFER_SIZE ;return 0 ; } -static void pl011_sgbuf_free (struct dma_chan *chan,struct pl011_sgbuf *sg, +static void pl011_dmabuf_free (struct dma_chan *chan,struct pl011_dmabuf *db,enum dma_data_direction dir) { -if (sg->buf) { +if (db->buf) {dma_free_coherent (chan->device->dev, -PL011_DMA_BUFFER_SIZE , sg->buf, -sg_dma_address (&sg->sg)); +PL011_DMA_BUFFER_SIZE , db->buf, db->dma); } }
@@ -551,8 +545,8 @@ static void pl011_dma_tx_callback(void *spin_lock_irqsave (&uap->port.lock, flags);if (uap->dmatx.queued) -dma_unmap_sg (dmatx->chan->device->dev, &dmatx->sg,1 , -DMA_TO_DEVICE ); +dma_unmap_single (dmatx->chan->device->dev, dmatx->dma, + dmatx->len,DMA_TO_DEVICE ); dmacr = uap->dmacr; uap->dmacr = dmacr & ~UART011_TXDMAE ;
@@ -638,18 +632,19 @@ static int pl011_dma_tx_refill(struct uamemcpy (&dmatx->buf[first], &xmit->buf[0 ], second); } - dmatx->sg.length = count; - -if (dma_map_sg (dma_dev->dev, &dmatx->sg,1 ,DMA_TO_DEVICE ) !=1 ) { + dmatx->len = count; + dmatx->dma =dma_map_single (dma_dev->dev, dmatx->buf, count, +DMA_TO_DEVICE ); +if (dmatx->dma ==DMA_MAPPING_ERROR ) { uap->dmatx.queued = false;dev_dbg (uap->port.dev,"unable to map TX DMA\n" );return -EBUSY ; } - desc =dmaengine_prep_slave_sg (chan, &dmatx->sg,1 ,DMA_MEM_TO_DEV , + desc =dmaengine_prep_slave_single (chan, dmatx->dma, dmatx->len,DMA_MEM_TO_DEV ,DMA_PREP_INTERRUPT |DMA_CTRL_ACK );if (!desc) { -dma_unmap_sg (dma_dev->dev, &dmatx->sg,1 ,DMA_TO_DEVICE ); +dma_unmap_single (dma_dev->dev, dmatx->dma, dmatx->len,DMA_TO_DEVICE ); uap->dmatx.queued = false;/* * If DMA cannot be used right now, we complete this
@@ -813,8 +808,8 @@ __acquires(&uap->port.lock)dmaengine_terminate_async (uap->dmatx.chan);if (uap->dmatx.queued) { -dma_unmap_sg (uap->dmatx.chan->device->dev, &uap->dmatx.sg,1 , -DMA_TO_DEVICE ); +dma_unmap_single (uap->dmatx.chan->device->dev, uap->dmatx.dma, + uap->dmatx.len,DMA_TO_DEVICE ); uap->dmatx.queued = false; uap->dmacr &= ~UART011_TXDMAE ;pl011_write (uap->dmacr, uap,REG_DMACR );
@@ -828,15 +823,15 @@ static int pl011_dma_rx_trigger_dma(strustruct dma_chan *rxchan = uap->dmarx.chan;struct pl011_dmarx_data *dmarx = &uap->dmarx;struct dma_async_tx_descriptor *desc; -struct pl011_sgbuf *sgbuf; +struct pl011_dmabuf *dbuf;if (!rxchan)return -EIO ;/* Start the RX DMA job */ - sgbuf = uap->dmarx.use_buf_b ? - &uap->dmarx.sgbuf_b : &uap->dmarx.sgbuf_a; - desc =dmaengine_prep_slave_sg (rxchan, &sgbuf->sg,1 , + dbuf = uap->dmarx.use_buf_b ? + &uap->dmarx.dbuf_b : &uap->dmarx.dbuf_a; + desc =dmaengine_prep_slave_single (rxchan, dbuf->dma, dbuf->len,DMA_DEV_TO_MEM ,DMA_PREP_INTERRUPT |DMA_CTRL_ACK );/*
@@ -876,8 +871,8 @@ static void pl011_dma_rx_chars(struct ua bool readfifo) {struct tty_port *port = &uap->port.state->port; -struct pl011_sgbuf *sgbuf = use_buf_b ? - &uap->dmarx.sgbuf_b : &uap->dmarx.sgbuf_a; +struct pl011_dmabuf *dbuf = use_buf_b ? + &uap->dmarx.dbuf_b : &uap->dmarx.dbuf_a;int dma_count =0 ;u32 fifotaken =0 ;/* only used for vdbg() */
@@ -886,7 +881,7 @@ static void pl011_dma_rx_chars(struct uaif (uap->dmarx.poll_rate) {/* The data can be taken by polling */ - dmataken = sgbuf->sg.length - dmarx->last_residue; + dmataken = dbuf->len - dmarx->last_residue;/* Recalculate the pending size */ if (pending >= dmataken) pending -= dmataken;
@@ -900,7 +895,7 @@ static void pl011_dma_rx_chars(struct ua* Note that tty_insert_flip_buf() tries to take as many chars * as it can. */ - dma_count =tty_insert_flip_string (port, sgbuf->buf + dmataken, + dma_count =tty_insert_flip_string (port, dbuf->buf + dmataken, pending); uap->port.icount.rx += dma_count;
@@ -911,7 +906,7 @@ static void pl011_dma_rx_chars(struct ua/* Reset the last_residue for Rx DMA poll */ if (uap->dmarx.poll_rate) - dmarx->last_residue = sgbuf->sg.length; + dmarx->last_residue = dbuf->len;/* * Only continue with trying to read the FIFO if all DMA chars have
@@ -946,8 +941,8 @@ static void pl011_dma_rx_irq(struct uart {struct pl011_dmarx_data *dmarx = &uap->dmarx;struct dma_chan *rxchan = dmarx->chan; -struct pl011_sgbuf *sgbuf = dmarx->use_buf_b ? - &dmarx->sgbuf_b : &dmarx->sgbuf_a; +struct pl011_dmabuf *dbuf = dmarx->use_buf_b ? + &dmarx->dbuf_b : &dmarx->dbuf_a;size_t pending;struct dma_tx_state state;enum dma_status dmastat;
@@ -969,7 +964,7 @@ static void pl011_dma_rx_irq(struct uartpl011_write (uap->dmacr, uap,REG_DMACR ); uap->dmarx.running = false; - pending = sgbuf->sg.length - state.residue; + pending = dbuf->len - state.residue;BUG_ON (pending >PL011_DMA_BUFFER_SIZE );/* Then we terminate the transfer - we now know our residue */ dmaengine_terminate_all (rxchan);
@@ -996,8 +991,8 @@ static void pl011_dma_rx_callback(void *struct pl011_dmarx_data *dmarx = &uap->dmarx;struct dma_chan *rxchan = dmarx->chan;bool lastbuf = dmarx->use_buf_b; -struct pl011_sgbuf *sgbuf = dmarx->use_buf_b ? - &dmarx->sgbuf_b : &dmarx->sgbuf_a; +struct pl011_dmabuf *dbuf = dmarx->use_buf_b ? + &dmarx->dbuf_b : &dmarx->dbuf_a;size_t pending;struct dma_tx_state state;int ret;
@@ -1015,7 +1010,7 @@ static void pl011_dma_rx_callback(void ** the DMA irq handler. So we check the residue here. */ rxchan->device->device_tx_status (rxchan, dmarx->cookie, &state); - pending = sgbuf->sg.length - state.residue; + pending = dbuf->len - state.residue;BUG_ON (pending >PL011_DMA_BUFFER_SIZE );/* Then we terminate the transfer - we now know our residue */ dmaengine_terminate_all (rxchan);
@@ -1067,16 +1062,16 @@ static void pl011_dma_rx_poll(struct timunsigned long flags;unsigned int dmataken =0 ;unsigned int size =0 ; -struct pl011_sgbuf *sgbuf; +struct pl011_dmabuf *dbuf;int dma_count;struct dma_tx_state state; - sgbuf = dmarx->use_buf_b ? &uap->dmarx.sgbuf_b : &uap->dmarx.sgbuf_a; + dbuf = dmarx->use_buf_b ? &uap->dmarx.dbuf_b : &uap->dmarx.dbuf_a; rxchan->device->device_tx_status (rxchan, dmarx->cookie, &state);if (likely (state.residue < dmarx->last_residue)) { - dmataken = sgbuf->sg.length - dmarx->last_residue; + dmataken = dbuf->len - dmarx->last_residue; size = dmarx->last_residue - state.residue; - dma_count =tty_insert_flip_string (port, sgbuf->buf + dmataken, + dma_count =tty_insert_flip_string (port, dbuf->buf + dmataken, size);if (dma_count == size) dmarx->last_residue = state.residue;
@@ -1123,7 +1118,7 @@ static void pl011_dma_startup(struct uarreturn ; } -sg_init_one (&uap->dmatx.sg, uap->dmatx.buf,PL011_DMA_BUFFER_SIZE ); + uap->dmatx.len =PL011_DMA_BUFFER_SIZE ;/* The DMA buffer is now the FIFO the TTY subsystem can use */ uap->port.fifosize =PL011_DMA_BUFFER_SIZE ;
@@ -1133,7 +1128,7 @@ static void pl011_dma_startup(struct uar goto skip_rx;/* Allocate and map DMA RX buffers */ - ret =pl011_sgbuf_init (uap->dmarx.chan, &uap->dmarx.sgbuf_a, + ret =pl011_dmabuf_init (uap->dmarx.chan, &uap->dmarx.dbuf_a,DMA_FROM_DEVICE );if (ret) { dev_err(uap->port.dev, "failed to init DMA %s: %d\n",
@@ -1141,12 +1136,12 @@ static void pl011_dma_startup(struct uar goto skip_rx; } - ret =pl011_sgbuf_init (uap->dmarx.chan, &uap->dmarx.sgbuf_b, + ret =pl011_dmabuf_init (uap->dmarx.chan, &uap->dmarx.dbuf_b,DMA_FROM_DEVICE );if (ret) {dev_err (uap->port.dev,"failed to init DMA %s: %d\n" ,"RX buffer B" , ret); -pl011_sgbuf_free (uap->dmarx.chan, &uap->dmarx.sgbuf_a, +pl011_dmabuf_free (uap->dmarx.chan, &uap->dmarx.dbuf_a,DMA_FROM_DEVICE ); goto skip_rx; }
@@ -1200,8 +1195,9 @@ static void pl011_dma_shutdown(struct ua/* In theory, this should already be done by pl011_dma_flush_buffer */ dmaengine_terminate_all (uap->dmatx.chan);if (uap->dmatx.queued) { -dma_unmap_sg (uap->dmatx.chan->device->dev, &uap->dmatx.sg,1 , -DMA_TO_DEVICE ); +dma_unmap_single (uap->dmatx.chan->device->dev, + uap->dmatx.dma, uap->dmatx.len, +DMA_TO_DEVICE ); uap->dmatx.queued = false; }
@@ -1212,8 +1208,8 @@ static void pl011_dma_shutdown(struct uaif (uap->using_rx_dma) {dmaengine_terminate_all (uap->dmarx.chan);/* Clean up the RX DMA */ -pl011_sgbuf_free (uap->dmarx.chan, &uap->dmarx.sgbuf_a,DMA_FROM_DEVICE ); -pl011_sgbuf_free (uap->dmarx.chan, &uap->dmarx.sgbuf_b,DMA_FROM_DEVICE ); +pl011_dmabuf_free (uap->dmarx.chan, &uap->dmarx.dbuf_a,DMA_FROM_DEVICE ); +pl011_dmabuf_free (uap->dmarx.chan, &uap->dmarx.dbuf_b,DMA_FROM_DEVICE );if (uap->dmarx.poll_rate)del_timer_sync (&uap->dmarx.timer); uap->using_rx_dma = false;
Greg Kroah-Hartman
maintainerPATCH 174/194 serial: sc16is7xx: address RX timeout interrupt errata
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Mack <[email protected]>
commit 08ce9a1b72e38cf44c300a44ac5858533eb3c860 upstream.
This device has a silicon bug that makes it report a timeout interrupt but no data in the FIFO.
The datasheet states the following in the errata section 18.1.4:
"If the host reads the receive FIFO at the same time as a time-out interrupt condition happens, the host might read 0xCC (time-out) in the Interrupt Indication Register (IIR), but bit 0 of the Line Status Register (LSR) is not set (means there is no data in the receive FIFO)."
The errata description seems to indicate it concerns only polled mode of operation when reading bit 0 of the LSR register. However, tests have shown and NXP has confirmed that the RXLVL register also yields 0 when the bug is triggered, and hence the IRQ driven implementation in this driver is equally affected.
This bug has hit us on production units and when it does, sc16is7xx_irq() would spin forever because sc16is7xx_port_irq() keeps seeing an interrupt in the IIR register that is not cleared because the driver does not call into sc16is7xx_handle_rx() unless the RXLVL register reports at least one byte in the FIFO.
Fix this by always reading one byte from the FIFO when this condition is detected in order to clear the interrupt. This approach was confirmed to be correct by NXP through their support channels.
Tested by: Hugo Villeneuve <[email protected]>
--- drivers/tty/serial/sc16is7xx.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
drivers/tty/serial/sc16is7xx.c +12 -0
@@ -769,6 +769,18 @@ static bool sc16is7xx_port_irq(struct sccase SC16IS7XX_IIR_RTOI_SRC :case SC16IS7XX_IIR_XOFFI_SRC : rxlen =sc16is7xx_port_read (port,SC16IS7XX_RXLVL_REG ); + +/* +* There is a silicon bug that makes the chip report a +* time-out interrupt but no data in the FIFO. This is +* described in errata section 18.1.4. +* +* When this happens, read one byte from the FIFO to +* clear the interrupt. +*/ +if (iir ==SC16IS7XX_IIR_RTOI_SRC && !rxlen) + rxlen =1 ; +if (rxlen)sc16is7xx_handle_rx (port, rxlen, iir);break ;
Greg Kroah-Hartman
maintainerPATCH 175/194 serial: 8250: 8250_omap: Clear UART_HAS_RHR_IT_DIS bit
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ronald Wahl <[email protected]>
commit 8973ab7a2441b286218f4a5c4c33680e2f139996 upstream.
This fixes commit 439c7183e5b9 ("serial: 8250: 8250_omap: Disable RX interrupt after DMA enable") which unfortunately set the UART_HAS_RHR_IT_DIS bit in the UART_OMAP_IER2 register and never cleared it.
--- drivers/tty/serial/8250/8250_omap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/tty/serial/8250/8250_omap.c +2 -2
@@ -825,7 +825,7 @@ static void __dma_rx_do_complete(structif (priv->habit &UART_HAS_RHR_IT_DIS ) { reg =serial_in (p,UART_OMAP_IER2 ); reg &= ~UART_OMAP_IER2_RHR_IT_DIS ; -serial_out (p,UART_OMAP_IER2 ,UART_OMAP_IER2_RHR_IT_DIS ); +serial_out (p,UART_OMAP_IER2 , reg); }dmaengine_tx_status (rxchan, cookie, &state);
@@ -967,7 +967,7 @@ static int omap_8250_rx_dma(struct uart_if (priv->habit &UART_HAS_RHR_IT_DIS ) { reg =serial_in (p,UART_OMAP_IER2 ); reg |=UART_OMAP_IER2_RHR_IT_DIS ; -serial_out (p,UART_OMAP_IER2 ,UART_OMAP_IER2_RHR_IT_DIS ); +serial_out (p,UART_OMAP_IER2 , reg); }dma_async_issue_pending (dma->rxchan);
Greg Kroah-Hartman
maintainerPATCH 176/194 serial: 8250: 8250_omap: Do not start RX DMA on THRI interrupt
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ronald Wahl <[email protected]>
commit c6bb057418876cdfdd29a6f7b8cef54539ee8811 upstream.
Starting RX DMA on THRI interrupt is too early because TX may not have finished yet.
This change is inspired by commit 90b8596ac460 ("serial: 8250: Prevent starting up DMA Rx on THRI interrupt") and fixes DMA issues I had with an AM62 SoC that is using the 8250 OMAP variant.
--- drivers/tty/serial/8250/8250_omap.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/tty/serial/8250/8250_omap.c +6 -4
@@ -1186,10 +1186,12 @@ static int omap_8250_dma_handle_irq(stru status =serial_port_in (port,UART_LSR ); -if (priv->habit &UART_HAS_EFR2 ) -am654_8250_handle_rx_dma (up, iir, status); -else - status =omap_8250_handle_rx_dma (up, iir, status); +if ((iir &0x3f ) !=UART_IIR_THRI ) { +if (priv->habit &UART_HAS_EFR2 ) +am654_8250_handle_rx_dma (up, iir, status); +else + status =omap_8250_handle_rx_dma (up, iir, status); + }serial8250_modem_status (up);if (status &UART_LSR_THRE && up->dma->tx_err) {
Greg Kroah-Hartman
maintainerPATCH 177/194 serial: 8250_omap: Add earlycon support for the AM654 UART controller
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ronald Wahl <[email protected]>
commit 8e42c301ce64e0dcca547626eb486877d502d336 upstream.
Currently there is no support for earlycon on the AM654 UART controller. This commit adds it.
--- drivers/tty/serial/8250/8250_early.c | 1 + 1 file changed, 1 insertion(+)
drivers/tty/serial/8250/8250_early.c +1 -0
@@ -197,6 +197,7 @@ static int __init early_omap8250_setup(sOF_EARLYCON_DECLARE (omap8250,"ti,omap2-uart" , early_omap8250_setup);OF_EARLYCON_DECLARE (omap8250,"ti,omap3-uart" , early_omap8250_setup);OF_EARLYCON_DECLARE (omap8250,"ti,omap4-uart" , early_omap8250_setup); +OF_EARLYCON_DECLARE (omap8250,"ti,am654-uart" , early_omap8250_setup);#endif
Greg Kroah-Hartman
maintainerPATCH 178/194 devcoredump: Send uevent once devcd is ready
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mukesh Ojha <[email protected]>
commit af54d778a03853801d681c98c0c2a6c316ef9ca7 upstream.
dev_coredumpm() creates a devcoredump device and adds it to the core kernel framework which eventually end up sending uevent to the user space and later creates a symbolic link to the failed device. An application running in userspace may be interested in this symbolic link to get the name of the failed device.
In a issue scenario, once uevent sent to the user space it start reading '/sys/class/devcoredump/devcdX/failing_device' to get the actual name of the device which might not been created and it is in its path of creation.
To fix this, suppress sending uevent till the failing device symbolic link gets created and send uevent once symbolic link is created successfully.
--- drivers/base/devcoredump.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/base/devcoredump.c +3 -0
@@ -363,6 +363,7 @@ void dev_coredumpm(struct device *dev, s devcd->devcd_dev.class = &devcd_class;mutex_lock (&devcd->mutex); +dev_set_uevent_suppress (&devcd->devcd_dev, true);if (device_add (&devcd->devcd_dev)) goto put_device;
@@ -377,6 +378,8 @@ void dev_coredumpm(struct device *dev, s "devcoredump"))dev_warn (dev,"devcoredump create_link failed\n" ); +dev_set_uevent_suppress (&devcd->devcd_dev, false); +kobject_uevent (&devcd->devcd_dev.kobj,KOBJ_ADD );INIT_DELAYED_WORK (&devcd->del_wk, devcd_del);schedule_delayed_work (&devcd->del_wk,DEVCD_TIMEOUT );mutex_unlock (&devcd->mutex);
Greg Kroah-Hartman
maintainerPATCH 179/194 x86/CPU/AMD: Check vendor in the AMD microcode callback
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Borislav Petkov (AMD) <[email protected]>
commit 9b8493dc43044376716d789d07699f17d538a7c4 upstream.
Commit in Fixes added an AMD-specific microcode callback. However, it didn't check the CPU vendor the kernel runs on explicitly.
The only reason the Zenbleed check in it didn't run on other x86 vendors hardware was pure coincidental luck:
if (!cpu_has_amd_erratum(c, amd_zenbleed))
return;
gives true on other vendors because they don't have those families and models.
However, with the removal of the cpu_has_amd_erratum() in
05f5f73936fa ("x86/CPU/AMD: Drop now unused CPU erratum checking function")
that coincidental condition is gone, leading to the zenbleed check getting executed on other vendors too.
Add the explicit vendor check for the whole callback as it should've been done in the first place.
--- arch/x86/kernel/cpu/amd.c | 3 +++ 1 file changed, 3 insertions(+)
arch/x86/kernel/cpu/amd.c +3 -0
@@ -1291,6 +1291,9 @@ static void zenbleed_check_cpu(void *unuvoid amd_check_microcode (void ) { +if (boot_cpu_data.x86_vendor !=X86_VENDOR_AMD ) +return ; +on_each_cpu (zenbleed_check_cpu,NULL ,1 ); }
Greg Kroah-Hartman
maintainerPATCH 180/194 USB: gadget: core: adjust uevent timing on gadget unbind
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roy Luo <[email protected]>
commit 73ea73affe8622bdf292de898da869d441da6a9d upstream.
The KOBJ_CHANGE uevent is sent before gadget unbind is actually executed, resulting in inaccurate uevent emitted at incorrect timing (the uevent would have USB_UDC_DRIVER variable set while it would soon be removed).
Move the KOBJ_CHANGE uevent to the end of the unbind function so that uevent is sent only after the change has been made.
--- drivers/usb/gadget/udc/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/usb/gadget/udc/core.c +2 -2
@@ -1608,8 +1608,6 @@ static void gadget_unbind_driver(structdev_dbg (&udc->dev,"unbinding gadget driver [%s]\n" , driver->function); -kobject_uevent (&udc->dev.kobj,KOBJ_CHANGE ); - udc->allow_connect = false;cancel_work_sync (&udc->vbus_work);mutex_lock (&udc->connect_lock);
@@ -1629,6 +1627,8 @@ static void gadget_unbind_driver(struct driver->is_bound = false; udc->driver =NULL ;mutex_unlock (&udc_lock); + +kobject_uevent (&udc->dev.kobj,KOBJ_CHANGE ); }/* ------------------------------------------------------------------------- */
Greg Kroah-Hartman
maintainerPATCH 181/194 cifs: Fix flushing, invalidation and file size with copy_file_range()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
commit 7b2404a886f8b91250c31855d287e632123e1746 upstream.
Fix a number of issues in the cifs filesystem implementation of the copy_file_range() syscall in cifs_file_copychunk_range().
Firstly, the invalidation of the destination range is handled incorrectly:
We shouldn't just invalidate the whole file as dirty data in the file may get lost and we can't just call truncate_inode_pages_range() to invalidate the destination range as that will erase parts of a partial folio at each end whilst invalidating and discarding all the folios in the middle. We need to force all the folios covering the range to be reloaded, but we mustn't lose dirty data in them that's not in the destination range.
Further, we shouldn't simply round out the range to PAGE_SIZE at each end as cifs should move to support multipage folios.
Secondly, there's an issue whereby a write may have extended the file locally, but not have been written back yet. This can leaves the local idea of the EOF at a later point than the server's EOF. If a copy request is issued, this will fail on the server with STATUS_INVALID_VIEW_SIZE (which gets translated to -EIO locally) if the copy source extends past the server's EOF.
Fix this by:
(0) Flush the source region (already done). The flush does nothing and the EOF isn't moved if the source region has no dirty data.
(1) Move the EOF to the end of the source region if it isn't already at least at this point. If we can't do this, for instance if the server doesn't support it, just flush the entire source file.
(2) Find the folio (if present) at each end of the range, flushing it and increasing the region-to-be-invalidated to cover those in their entirety.
(3) Fully discard all the folios covering the range as we want them to be reloaded.
(4) Then perform the copy.
Thirdly, set i_size after doing the copychunk_range operation as this value may be used by various things internally. stat() hides the issue because setting ->time to 0 causes cifs_getatr() to revalidate the attributes.
These were causing the generic/075 xfstest to fail.
--- fs/smb/client/cifsfs.c | 102 +++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 99 insertions(+), 3 deletions(-)
fs/smb/client/cifsfs.c +99 -3
@@ -1191,6 +1191,72 @@ const struct inode_operations cifs_symli .listxattr = cifs_listxattr, }; +/* +* Advance the EOF marker to after the source range. +*/ +static int cifs_precopy_set_eof (struct inode *src_inode,struct cifsInodeInfo *src_cifsi, +struct cifs_tcon *src_tcon, +unsigned int xid,loff_t src_end) +{ +struct cifsFileInfo *writeable_srcfile; +int rc = -EINVAL ; + + writeable_srcfile =find_writable_file (src_cifsi,FIND_WR_FSUID_ONLY ); +if (writeable_srcfile) { +if (src_tcon->ses->server->ops->set_file_size) + rc = src_tcon->ses->server->ops->set_file_size ( + xid, src_tcon, writeable_srcfile, + src_inode->i_size, true/* no need to set sparse */ ); +else + rc = -ENOSYS ; +cifsFileInfo_put (writeable_srcfile); +cifs_dbg (FYI ,"SetFSize for copychunk rc = %d\n" , rc); + } + +if (rc <0 ) + goto set_failed; + +netfs_resize_file (&src_cifsi->netfs, src_end); +fscache_resize_cookie (cifs_inode_cookie (src_inode), src_end); +return 0 ; + +set_failed: +return filemap_write_and_wait (src_inode->i_mapping); +} + +/* +* Flush out either the folio that overlaps the beginning of a range in which +* pos resides or the folio that overlaps the end of a range unless that folio +* is entirely within the range we're going to invalidate. We extend the flush +* bounds to encompass the folio. +*/ +static int cifs_flush_folio (struct inode *inode,loff_t pos,loff_t *_fstart,loff_t *_fend, +bool first) +{ +struct folio *folio; +unsigned long long fpos, fend; +pgoff_t index = pos /PAGE_SIZE ; +size_t size; +int rc =0 ; + + folio =filemap_get_folio (inode->i_mapping, index); +if (IS_ERR (folio)) +return 0 ; + + size =folio_size (folio); + fpos =folio_pos (folio); + fend = fpos + size -1 ; + *_fstart = min_t(unsigned long long, *_fstart, fpos); + *_fend = max_t(unsigned long long, *_fend, fend); +if ((first && pos == fpos) || (!first && pos == fend)) + goto out; + + rc =filemap_write_and_wait_range (inode->i_mapping, fpos, fend); +out: +folio_put (folio); +return rc; +} +static loff_t cifs_remap_file_range (struct file *src_file,loff_t off,struct file *dst_file,loff_t destoff,loff_t len,unsigned int remap_flags)
@@ -1260,10 +1326,12 @@ ssize_t cifs_file_copychunk_range(unsign {struct inode *src_inode =file_inode (src_file);struct inode *target_inode =file_inode (dst_file); +struct cifsInodeInfo *src_cifsi =CIFS_I (src_inode);struct cifsFileInfo *smb_file_src;struct cifsFileInfo *smb_file_target;struct cifs_tcon *src_tcon;struct cifs_tcon *target_tcon; +unsigned long long destend, fstart, fend;ssize_t rc;cifs_dbg (FYI ,"copychunk range\n" );
@@ -1303,13 +1371,41 @@ ssize_t cifs_file_copychunk_range(unsignif (rc) goto unlock; -/* should we flush first and last page first */ -truncate_inode_pages (&target_inode->i_data,0 ); +/* The server-side copy will fail if the source crosses the EOF marker. +* Advance the EOF marker after the flush above to the end of the range +* if it's short of that. +*/ +if (src_cifsi->server_eof < off + len) { + rc =cifs_precopy_set_eof (src_inode, src_cifsi, src_tcon, xid, off + len); +if (rc <0 ) + goto unlock; + } + + destend = destoff + len -1 ; + +/* Flush the folios at either end of the destination range to prevent +* accidental loss of dirty data outside of the range. +*/ + fstart = destoff; + fend = destend; + + rc =cifs_flush_folio (target_inode, destoff, &fstart, &fend, true); +if (rc) + goto unlock; + rc =cifs_flush_folio (target_inode, destend, &fstart, &fend, false); +if (rc) + goto unlock; + +/* Discard all the folios that overlap the destination region. */ +truncate_inode_pages_range (&target_inode->i_data, fstart, fend); rc =file_modified (dst_file); -if (!rc) +if (!rc) { rc = target_tcon->ses->server->ops->copychunk_range (xid, smb_file_src, smb_file_target, off, len, destoff); +if (rc >0 && destoff + rc >i_size_read (target_inode)) +truncate_setsize (target_inode, destoff + rc); + }file_accessed (src_file);
Greg Kroah-Hartman
maintainerPATCH 182/194 cifs: Fix flushing, invalidation and file size with FICLONE
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
commit c54fc3a4f375663f2361a9cbb2955fb4ef912879 upstream.
Fix a number of issues in the cifs filesystem implementation of the FICLONE ioctl in cifs_remap_file_range(). This is analogous to the previously fixed bug in cifs_file_copychunk_range() and can share the helper functions.
Firstly, the invalidation of the destination range is handled incorrectly:
We shouldn't just invalidate the whole file as dirty data in the file may get lost and we can't just call truncate_inode_pages_range() to invalidate the destination range as that will erase parts of a partial folio at each end whilst invalidating and discarding all the folios in the middle. We need to force all the folios covering the range to be reloaded, but we mustn't lose dirty data in them that's not in the destination range.
Further, we shouldn't simply round out the range to PAGE_SIZE at each end as cifs should move to support multipage folios.
Secondly, there's an issue whereby a write may have extended the file locally, but not have been written back yet. This can leaves the local idea of the EOF at a later point than the server's EOF. If a clone request is issued, this will fail on the server with STATUS_INVALID_VIEW_SIZE (which gets translated to -EIO locally) if the clone source extends past the server's EOF.
Fix this by:
(0) Flush the source region (already done). The flush does nothing and the EOF isn't moved if the source region has no dirty data.
(1) Move the EOF to the end of the source region if it isn't already at least at this point. If we can't do this, for instance if the server doesn't support it, just flush the entire source file.
(2) Find the folio (if present) at each end of the range, flushing it and increasing the region-to-be-invalidated to cover those in their entirety.
(3) Fully discard all the folios covering the range as we want them to be reloaded.
(4) Then perform the extent duplication.
Thirdly, set i_size after doing the duplicate_extents operation as this value may be used by various things internally. stat() hides the issue because setting ->time to 0 causes cifs_getatr() to revalidate the attributes.
These were causing the cifs/001 xfstest to fail.
--- fs/smb/client/cifsfs.c | 68 +++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 57 insertions(+), 11 deletions(-)
fs/smb/client/cifsfs.c +57 -11
@@ -1263,9 +1263,12 @@ static loff_t cifs_remap_file_range(stru {struct inode *src_inode =file_inode (src_file);struct inode *target_inode =file_inode (dst_file); +struct cifsInodeInfo *src_cifsi =CIFS_I (src_inode); +struct cifsInodeInfo *target_cifsi =CIFS_I (target_inode);struct cifsFileInfo *smb_file_src = src_file->private_data; -struct cifsFileInfo *smb_file_target; -struct cifs_tcon *target_tcon; +struct cifsFileInfo *smb_file_target = dst_file->private_data; +struct cifs_tcon *target_tcon, *src_tcon; +unsigned long long destend, fstart, fend, new_size;unsigned int xid;int rc;
@@ -1278,13 +1281,13 @@ static loff_t cifs_remap_file_range(stru xid =get_xid (); -if (!src_file->private_data || !dst_file->private_data) { +if (!smb_file_src || !smb_file_target) { rc = -EBADF ;cifs_dbg (VFS ,"missing cifsFileInfo on copy range src file\n" ); goto out; } - smb_file_target = dst_file->private_data; + src_tcon =tlink_tcon (smb_file_src->tlink); target_tcon =tlink_tcon (smb_file_target->tlink);/*
@@ -1297,20 +1300,63 @@ static loff_t cifs_remap_file_range(struif (len ==0 ) len = src_inode->i_size - off; -cifs_dbg (FYI ,"about to flush pages\n" ); -/* should we flush first and last page first */ -truncate_inode_pages_range (&target_inode->i_data, destoff, -PAGE_ALIGN (destoff + len)-1 ); +cifs_dbg (FYI ,"clone range\n" ); + +/* Flush the source buffer */ + rc =filemap_write_and_wait_range (src_inode->i_mapping, off, + off + len -1 ); +if (rc) + goto unlock; + +/* The server-side copy will fail if the source crosses the EOF marker. +* Advance the EOF marker after the flush above to the end of the range +* if it's short of that. +*/ +if (src_cifsi->netfs.remote_i_size < off + len) { + rc =cifs_precopy_set_eof (src_inode, src_cifsi, src_tcon, xid, off + len); +if (rc <0 ) + goto unlock; + } + + new_size = destoff + len; + destend = destoff + len -1 ; -if (target_tcon->ses->server->ops->duplicate_extents) +/* Flush the folios at either end of the destination range to prevent +* accidental loss of dirty data outside of the range. +*/ + fstart = destoff; + fend = destend; + + rc =cifs_flush_folio (target_inode, destoff, &fstart, &fend, true); +if (rc) + goto unlock; + rc =cifs_flush_folio (target_inode, destend, &fstart, &fend, false); +if (rc) + goto unlock; + +/* Discard all the folios that overlap the destination region. */ +cifs_dbg (FYI ,"about to discard pages %llx-%llx\n" , fstart, fend); +truncate_inode_pages_range (&target_inode->i_data, fstart, fend); + +fscache_invalidate (cifs_inode_cookie (target_inode),NULL , +i_size_read (target_inode),0 ); + + rc = -EOPNOTSUPP ; +if (target_tcon->ses->server->ops->duplicate_extents) { rc = target_tcon->ses->server->ops->duplicate_extents (xid, smb_file_src, smb_file_target, off, len, destoff); -else - rc = -EOPNOTSUPP ; +if (rc ==0 && new_size >i_size_read (target_inode)) { +truncate_setsize (target_inode, new_size); +netfs_resize_file (&target_cifsi->netfs, new_size); +fscache_resize_cookie (cifs_inode_cookie (target_inode), + new_size); + } + }/* force revalidate of size and timestamps of target file now that target is updated on the server */ CIFS_I (target_inode)->time =0 ; +unlock:/* although unlocking in the reverse order from locking is not strictly necessary here it is a little cleaner to be consistent */ unlock_two_nondirectories (src_inode, target_inode);
Greg Kroah-Hartman
maintainerPATCH 183/194 MIPS: kernel: Clear FPU states when setting up kernel threads
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Bogendoerfer <[email protected]>
commit a58a173444a68412bb08849bd81c679395f20ca0 upstream.
io_uring sets up the io worker kernel thread via a syscall out of an user space prrocess. This process might have used FPU and since copy_thread() didn't clear FPU states for kernel threads a BUG() is triggered for using FPU inside kernel. Move code around to always clear FPU state for user and kernel threads.
--- arch/mips/kernel/process.c | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-)
arch/mips/kernel/process.c +13 -12
@@ -121,6 +121,19 @@ int copy_thread(struct task_struct *p, c/* Put the stack after the struct pt_regs. */ childksp = (unsigned long ) childregs; p->thread.cp0_status = (read_c0_status () & ~(ST0_CU2 |ST0_CU1 )) |ST0_KERNEL_CUMASK ; + +/* +* New tasks lose permission to use the fpu. This accelerates context +* switching for most programs since they don't use the fpu. +*/ +clear_tsk_thread_flag (p,TIF_USEDFPU ); +clear_tsk_thread_flag (p,TIF_USEDMSA ); +clear_tsk_thread_flag (p,TIF_MSA_CTX_LIVE ); + +#ifdef CONFIG_MIPS_MT_FPAFF +clear_tsk_thread_flag (p,TIF_FPUBOUND ); +#endif /* CONFIG_MIPS_MT_FPAFF */ +if (unlikely (args->fn)) {/* kernel thread */ unsigned long status = p->thread.cp0_status;
@@ -149,20 +162,8 @@ int copy_thread(struct task_struct *p, c p->thread.reg29 = (unsigned long ) childregs; p->thread.reg31 = (unsigned long ) ret_from_fork; -/* -* New tasks lose permission to use the fpu. This accelerates context -* switching for most programs since they don't use the fpu. -*/ childregs->cp0_status &= ~(ST0_CU2 |ST0_CU1 ); -clear_tsk_thread_flag (p,TIF_USEDFPU ); -clear_tsk_thread_flag (p,TIF_USEDMSA ); -clear_tsk_thread_flag (p,TIF_MSA_CTX_LIVE ); - -#ifdef CONFIG_MIPS_MT_FPAFF -clear_tsk_thread_flag (p,TIF_FPUBOUND ); -#endif /* CONFIG_MIPS_MT_FPAFF */ -#ifdef CONFIG_MIPS_FP_SUPPORT atomic_set (&p->thread.bd_emu_frame,BD_EMUFRAME_NONE );#endif
Greg Kroah-Hartman
maintainerPATCH 184/194 KVM: s390/mm: Properly reset no-dat
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Claudio Imbrenda <[email protected]>
commit 27072b8e18a73ffeffb1c140939023915a35134b upstream.
When the CMMA state needs to be reset, the no-dat bit also needs to be reset. Failure to do so could cause issues in the guest, since the guest expects the bit to be cleared after a reset.
Message-ID: <[email protected]>
--- arch/s390/mm/pgtable.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/s390/mm/pgtable.c +1 -1
@@ -731,7 +731,7 @@ void ptep_zap_unused(struct mm_struct *mpte_clear (mm, addr, ptep); }if (reset) -pgste_val (pgste) &= ~_PGSTE_GPS_USAGE_MASK; +pgste_val (pgste) &= ~(_PGSTE_GPS_USAGE_MASK | _PGSTE_GPS_NODAT);pgste_set_unlock (ptep, pgste);preempt_enable (); }
Greg Kroah-Hartman
maintainerPATCH 185/194 KVM: SVM: Update EFER software model on CR0 trap for SEV-ES
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Christopherson <[email protected]>
commit 4cdf351d3630a640ab6a05721ef055b9df62277f upstream.
In general, activating long mode involves setting the EFER_LME bit in the EFER register and then enabling the X86_CR0_PG bit in the CR0 register. At this point, the EFER_LMA bit will be set automatically by hardware.
In the case of SVM/SEV guests where writes to CR0 are intercepted, it's necessary for the host to set EFER_LMA on behalf of the guest since hardware does not see the actual CR0 write.
In the case of SEV-ES guests where writes to CR0 are trapped instead of intercepted, the hardware *does* see/record the write to CR0 before exiting and passing the value on to the host, so as part of enabling SEV-ES support commit f1c6366e3043 ("KVM: SVM: Add required changes to support intercepts under SEV-ES") dropped special handling of the EFER_LMA bit with the understanding that it would be set automatically.
However, since the guest never explicitly sets the EFER_LMA bit, the host never becomes aware that it has been set. This becomes problematic when userspace tries to get/set the EFER values via KVM_GET_SREGS/KVM_SET_SREGS, since the EFER contents tracked by the host will be missing the EFER_LMA bit, and when userspace attempts to pass the EFER value back via KVM_SET_SREGS it will fail a sanity check that asserts that EFER_LMA should always be set when X86_CR0_PG and EFER_LME are set.
Fix this by always inferring the value of EFER_LMA based on X86_CR0_PG and EFER_LME, regardless of whether or not SEV-ES is enabled.
Message-Id: <[email protected]>
[A two year old patch that was revived after we noticed the failure in
KVM_SET_SREGS and a similar patch was posted by Michael Roth. This is Sean's patch, but with Michael's more complete commit message. - Paolo]
--- arch/x86/kvm/svm/svm.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
arch/x86/kvm/svm/svm.c +5 -3
@@ -1786,15 +1786,17 @@ void svm_set_cr0(struct kvm_vcpu *vcpu,bool old_paging =is_paging (vcpu);#ifdef CONFIG_X86_64 -if (vcpu->arch.efer &EFER_LME && !vcpu->arch.guest_state_protected) { +if (vcpu->arch.efer &EFER_LME ) {if (!is_paging (vcpu) && (cr0 &X86_CR0_PG )) { vcpu->arch.efer |=EFER_LMA ; - svm->vmcb->save.efer |=EFER_LMA |EFER_LME ; +if (!vcpu->arch.guest_state_protected) + svm->vmcb->save.efer |=EFER_LMA |EFER_LME ; }if (is_paging (vcpu) && !(cr0 &X86_CR0_PG )) { vcpu->arch.efer &= ~EFER_LMA ; - svm->vmcb->save.efer &= ~(EFER_LMA |EFER_LME ); +if (!vcpu->arch.guest_state_protected) + svm->vmcb->save.efer &= ~(EFER_LMA |EFER_LME ); } }#endif
Greg Kroah-Hartman
maintainerPATCH 186/194 MIPS: Loongson64: Reserve vgabios memory on boot
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiaxun Yang <[email protected]>
commit 8f7aa77a463f47c9e00592d02747a9fcf2271543 upstream.
vgabios is passed from firmware to kernel on Loongson64 systems. Sane firmware will keep this pointer in reserved memory space passed from the firmware but insane firmware keeps it in low memory before kernel entry that is not reserved.
Previously kernel won't try to allocate memory from low memory before kernel entry on boot, but after converting to memblock it will do that.
Fix by resversing those memory on early boot.
--- arch/mips/loongson64/init.c | 5 +++++ 1 file changed, 5 insertions(+)
arch/mips/loongson64/init.c +5 -0
@@ -88,6 +88,11 @@ void __init szmem(unsigned int node)break ; } } + +/* Reserve vgabios if it comes from firmware */ +if (loongson_sysconf.vgabios_addr) +memblock_reserve (virt_to_phys ((void *)loongson_sysconf.vgabios_addr), +SZ_256K ); }#ifndef CONFIG_NUMA
Greg Kroah-Hartman
maintainerPATCH 187/194 MIPS: Loongson64: Handle more memory types passed from firmware
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiaxun Yang <[email protected]>
commit c7206e7bd214ebb3ca6fa474a4423662327d9beb upstream.
There are many types of revsered memory passed from firmware that should be reserved in memblock, and UMA memory passed from firmware that should be added to system memory for system to use.
Also for memblock there is no need to align those space into page, which actually cause problems.
Handle them properly to prevent memory corruption on some systems.
--- arch/mips/include/asm/mach-loongson64/boot_param.h | 6 ++- arch/mips/loongson64/init.c | 42 +++++++++++++-------- 2 files changed, 31 insertions(+), 17 deletions(-)
arch/mips/include/asm/mach-loongson64/boot_param.h +5 -1
@@ -14,7 +14,11 @@#define ADAPTER_ROM 8#define ACPI_TABLE 9#define SMBIOS_TABLE 10 -#define MAX_MEMORY_TYPE 11 +#define UMA_VIDEO_RAM 11 +#define VUMA_VIDEO_RAM 12 +#define MAX_MEMORY_TYPE 13 + +#define MEM_SIZE_IS_IN_BYTES (1 << 31)#define LOONGSON3_BOOT_MEM_MAP_MAX 128struct efi_memory_map_loongson {
arch/mips/loongson64/init.c +26 -16
61 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 188/194 MIPS: Loongson64: Enable DMA noncoherent support
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiaxun Yang <[email protected]>
commit edc0378eee00200a5bedf1bb9f00ad390e0d1bd4 upstream.
There are some Loongson64 systems come with broken coherent DMA support, firmware will set a bit in boot_param and pass nocoherentio in cmdline.
However nonconherent support was missed out when spin off Loongson-2EF form Loongson64, and that boot_param change never made itself into upstream.
Support DMA noncoherent properly to get those systems working.
--- arch/mips/Kconfig | 2 ++ arch/mips/include/asm/mach-loongson64/boot_param.h | 3 ++- arch/mips/loongson64/env.c | 10 +++++++++- 3 files changed, 13 insertions(+), 2 deletions(-)
arch/mips/Kconfig +2 -0
@@ -483,6 +483,7 @@ config MACH_LOONGSON2EF config MACH_LOONGSON64 bool "Loongson 64-bit family of machines" + select ARCH_DMA_DEFAULT_COHERENT select ARCH_SPARSEMEM_ENABLE select ARCH_MIGHT_HAVE_PC_PARPORT select ARCH_MIGHT_HAVE_PC_SERIO
@@ -1304,6 +1305,7 @@ config CPU_LOONGSON64 select CPU_SUPPORTS_MSA select CPU_DIEI_BROKEN if !LOONGSON3_ENHANCEMENT select CPU_MIPSR2_IRQ_VI + select DMA_NONCOHERENT select WEAK_ORDERING select WEAK_REORDERING_BEYOND_LLSC select MIPS_ASID_BITS_VARIABLE
arch/mips/include/asm/mach-loongson64/boot_param.h +2 -1
@@ -121,7 +121,8 @@ struct irq_source_routing_table {u64 pci_io_start_addr;u64 pci_io_end_addr;u64 pci_config_addr; -u32 dma_mask_bits; +u16 dma_mask_bits; +u16 dma_noncoherent; } __packed;struct interface_info {
arch/mips/loongson64/env.c +9 -1
@@ -13,6 +13,8 @@* Copyright (C) 2009 Lemote Inc. * Author: Wu Zhangjin, [email protected] */ + +#include <linux/dma-map-ops.h> #include <linux/export.h> #include <linux/pci_ids.h> #include <asm/bootinfo.h>
@@ -147,8 +149,14 @@ void __init prom_lefi_init_env(void) loongson_sysconf.dma_mask_bits = eirq_source->dma_mask_bits;if (loongson_sysconf.dma_mask_bits <32 || - loongson_sysconf.dma_mask_bits >64 ) + loongson_sysconf.dma_mask_bits >64 ) { loongson_sysconf.dma_mask_bits =32 ; + dma_default_coherent = true; + }else { + dma_default_coherent = !eirq_source->dma_noncoherent; + } + +pr_info ("Firmware: Coherent DMA: %s\n" , dma_default_coherent ?"on" :"off" ); loongson_sysconf.restart_addr = boot_p->reset_system.ResetWarm; loongson_sysconf.poweroff_addr = boot_p->reset_system.Shutdown;
Greg Kroah-Hartman
maintainerPATCH 189/194 netfilter: nft_set_pipapo: skip inactive elements during set walk
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Westphal <[email protected]>
commit 317eb9685095678f2c9f5a8189de698c5354316a upstream.
Otherwise set elements can be deactivated twice which will cause a crash.
--- net/netfilter/nft_set_pipapo.c | 3 +++ 1 file changed, 3 insertions(+)
net/netfilter/nft_set_pipapo.c +3 -0
@@ -2042,6 +2042,9 @@ static void nft_pipapo_walk(const struct e = f->mt[r].e; +if (!nft_set_elem_active (&e->ext, iter->genmask)) + goto cont; + elem.priv = e; iter->err = iter->fn (ctx, set, iter, &elem);
Greg Kroah-Hartman
maintainerPATCH 190/194 riscv: Kconfig: Add select ARM_AMBA to SOC_STARFIVE
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jia Jie Ho <[email protected]>
commit 78a03b9f8e6b317f7c65738a3fc60e1e85106a64 upstream.
Selects ARM_AMBA platform support for StarFive SoCs required by spi and crypto dma engine.
--- arch/riscv/Kconfig.socs | 1 + 1 file changed, 1 insertion(+)
arch/riscv/Kconfig.socs +1 -0
@@ -23,6 +23,7 @@ config SOC_STARFIVE select PINCTRL select RESET_CONTROLLER select SIFIVE_PLIC + select ARM_AMBA help This enables support for StarFive SoC platform hardware.
Greg Kroah-Hartman
maintainerPATCH 191/194 drm/i915/display: Drop check for doublescan mode in modevalid
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ankit Nautiyal <[email protected]>
[ Upstream commit 9d04eb20bc71a383b4d4e383b0b7fac8d38a2e34 ]
Since the DP/HDMI connector do not set connector->doublescan_allowed, the doublescan modes will get automatically filtered during drm_helper_probe_single_connector_modes().
Therefore check for double scan modes is not required and is dropped from modevalid functions for both DP and HDMI.
Stable-dep-of: 20c2dbff342a ("drm/i915: Skip some timing checks on BXT/GLK DSI transcoders")
--- drivers/gpu/drm/i915/display/intel_dp.c | 3 --- drivers/gpu/drm/i915/display/intel_hdmi.c | 3 --- 2 files changed, 6 deletions(-)
drivers/gpu/drm/i915/display/intel_dp.c +0 -3
@@ -973,9 +973,6 @@ intel_dp_mode_valid(struct drm_connector *_connector,enum drm_mode_status status;bool dsc = false, bigjoiner = false; -if (mode->flags &DRM_MODE_FLAG_DBLSCAN ) -return MODE_NO_DBLESCAN ; -if (mode->flags &DRM_MODE_FLAG_DBLCLK )return MODE_H_ILLEGAL ;
drivers/gpu/drm/i915/display/intel_hdmi.c +0 -3
@@ -1987,9 +1987,6 @@ intel_hdmi_mode_valid(struct drm_connector *connector,bool has_hdmi_sink =intel_has_hdmi_sink (hdmi, connector->state);bool ycbcr_420_only; -if (mode->flags &DRM_MODE_FLAG_DBLSCAN ) -return MODE_NO_DBLESCAN ; -if ((mode->flags &DRM_MODE_FLAG_3D_MASK ) ==DRM_MODE_FLAG_3D_FRAME_PACKING ) clock *=2 ;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 192/194 drm/i915/lvds: Use REG_BIT() & co.
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ville Syrjälä <[email protected]>
[ Upstream commit 9dd56e979cb69f5cd904574c852b620777a2f69f ]
Use REG_BIT() & co. for the LVDS port register.
Stable-dep-of: 20c2dbff342a ("drm/i915: Skip some timing checks on BXT/GLK DSI transcoders")
--- drivers/gpu/drm/i915/display/intel_lvds.c | 4 +- drivers/gpu/drm/i915/i915_reg.h | 46 +++++++++++------------ 2 files changed, 24 insertions(+), 26 deletions(-)
drivers/gpu/drm/i915/display/intel_lvds.c +2 -2
@@ -92,9 +92,9 @@ bool intel_lvds_port_enabled(struct drm_i915_private *dev_priv,/* asserts want to know the pipe even if the port is disabled */ if (HAS_PCH_CPT (dev_priv)) - *pipe = (val &LVDS_PIPE_SEL_MASK_CPT ) >>LVDS_PIPE_SEL_SHIFT_CPT ; + *pipe =REG_FIELD_GET (LVDS_PIPE_SEL_MASK_CPT , val);else - *pipe = (val &LVDS_PIPE_SEL_MASK ) >>LVDS_PIPE_SEL_SHIFT ; + *pipe =REG_FIELD_GET (LVDS_PIPE_SEL_MASK , val);return val &LVDS_PORT_EN ; }
drivers/gpu/drm/i915/i915_reg.h +22 -24
81 lines not on this page · raw message
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 193/194 drm/i915/sdvo: stop caching has_hdmi_monitor in struct intel_sdvo
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jani Nikula <[email protected]>
[ Upstream commit f2f9c8cb6421429ef166d6404426693212d0ca07 ]
Use the information stored in display info.
Stable-dep-of: 20c2dbff342a ("drm/i915: Skip some timing checks on BXT/GLK DSI transcoders")
--- drivers/gpu/drm/i915/display/intel_sdvo.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
drivers/gpu/drm/i915/display/intel_sdvo.c +7 -7
@@ -115,7 +115,6 @@ struct intel_sdvo {enum port port; -bool has_hdmi_monitor;bool has_hdmi_audio;/* DDC bus used by this SDVO encoder */
@@ -1278,10 +1277,13 @@ static void i9xx_adjust_sdvo_tv_clock(struct intel_crtc_state *pipe_config) pipe_config->clock_set = true; } -static bool intel_has_hdmi_sink (struct intel_sdvo *sdvo, +static bool intel_has_hdmi_sink (struct intel_sdvo_connector *intel_sdvo_connector,const struct drm_connector_state *conn_state) { -return sdvo->has_hdmi_monitor && +struct drm_connector *connector = conn_state->connector; + +return intel_sdvo_connector->is_hdmi && + connector->display_info.is_hdmi &&READ_ONCE (to_intel_digital_connector_state (conn_state)->force_audio) !=HDMI_AUDIO_OFF_DVI ; }
@@ -1360,7 +1362,7 @@ static int intel_sdvo_compute_config(struct intel_encoder *encoder, pipe_config->pixel_multiplier =intel_sdvo_get_pixel_multiplier (adjusted_mode); - pipe_config->has_hdmi_sink =intel_has_hdmi_sink (intel_sdvo, conn_state); + pipe_config->has_hdmi_sink =intel_has_hdmi_sink (intel_sdvo_connector, conn_state);if (pipe_config->has_hdmi_sink) {if (intel_sdvo_state->base.force_audio ==HDMI_AUDIO_AUTO )
@@ -1875,7 +1877,7 @@ intel_sdvo_mode_valid(struct drm_connector *connector,struct intel_sdvo_connector *intel_sdvo_connector =to_intel_sdvo_connector (connector);int max_dotclk =to_i915 (connector->dev)->max_dotclk_freq; -bool has_hdmi_sink =intel_has_hdmi_sink (intel_sdvo, connector->state); +bool has_hdmi_sink =intel_has_hdmi_sink (intel_sdvo_connector, connector->state);int clock = mode->clock;if (mode->flags &DRM_MODE_FLAG_DBLSCAN )
@@ -2064,7 +2066,6 @@ intel_sdvo_tmds_sink_detect(struct drm_connector *connector)if (edid->input &DRM_EDID_INPUT_DIGITAL ) { status = connector_status_connected;if (intel_sdvo_connector->is_hdmi) { - intel_sdvo->has_hdmi_monitor =drm_detect_hdmi_monitor (edid); intel_sdvo->has_hdmi_audio =drm_detect_monitor_audio (edid); } }else
@@ -2116,7 +2117,6 @@ intel_sdvo_detect(struct drm_connector *connector, bool force) intel_sdvo->attached_output = response; - intel_sdvo->has_hdmi_monitor = false; intel_sdvo->has_hdmi_audio = false;if ((intel_sdvo_connector->output_flag & response) ==0 )
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 194/194 drm/i915: Skip some timing checks on BXT/GLK DSI transcoders
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ville Syrjälä <[email protected]>
[ Upstream commit 20c2dbff342aec13bf93c2f6c951da198916a455 ]
Apparently some BXT/GLK systems have DSI panels whose timings don't agree with the normal cpu transcoder hblank>=32 limitation. This is perhaps fine as there are no specific hblank/etc. limits listed for the BXT/GLK DSI transcoders.
Move those checks out from the global intel_mode_valid() into into connector specific .mode_valid() hooks, skipping BXT/GLK DSI connectors. We'll leave the basic [hv]display/[hv]total checks in intel_mode_valid() as those seem like sensible upper limits regardless of the transcoder used.
--- drivers/gpu/drm/i915/display/icl_dsi.c | 7 +++++++ drivers/gpu/drm/i915/display/intel_crt.c | 5 +++++ drivers/gpu/drm/i915/display/intel_display.c | 10 ++++++++++ drivers/gpu/drm/i915/display/intel_display.h | 3 +++ drivers/gpu/drm/i915/display/intel_dp.c | 4 ++++ drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 ++++ drivers/gpu/drm/i915/display/intel_dvo.c | 6 ++++++ drivers/gpu/drm/i915/display/intel_hdmi.c | 4 ++++ drivers/gpu/drm/i915/display/intel_lvds.c | 5 +++++ drivers/gpu/drm/i915/display/intel_sdvo.c | 8 +++++++- drivers/gpu/drm/i915/display/intel_tv.c | 8 +++++++- drivers/gpu/drm/i915/display/vlv_dsi.c | 18 +++++++++++++++++- 12 files changed, 79 insertions(+), 3 deletions(-)
drivers/gpu/drm/i915/display/icl_dsi.c +7 -0
@@ -1500,6 +1500,13 @@ static void gen11_dsi_post_disable(struct intel_atomic_state *state,static enum drm_mode_status gen11_dsi_mode_valid (struct drm_connector *connector,struct drm_display_mode *mode) { +struct drm_i915_private *i915 =to_i915 (connector->dev); +enum drm_mode_status status; + + status =intel_cpu_transcoder_mode_valid (i915, mode); +if (status !=MODE_OK ) +return status; +/* FIXME: DSC? */ return intel_dsi_mode_valid (connector, mode); }
drivers/gpu/drm/i915/display/intel_crt.c +5 -0
@@ -343,8 +343,13 @@ intel_crt_mode_valid(struct drm_connector *connector,struct drm_device *dev = connector->dev;struct drm_i915_private *dev_priv =to_i915 (dev);int max_dotclk = dev_priv->max_dotclk_freq; +enum drm_mode_status status;int max_clock; + status =intel_cpu_transcoder_mode_valid (dev_priv, mode); +if (status !=MODE_OK ) +return status; +if (mode->flags &DRM_MODE_FLAG_DBLSCAN )return MODE_NO_DBLESCAN ;
drivers/gpu/drm/i915/display/intel_display.c +10 -0
@@ -8229,6 +8229,16 @@ intel_mode_valid(struct drm_device *dev, mode->vtotal > vtotal_max)return MODE_V_ILLEGAL ; +return MODE_OK ; +} + +enum drm_mode_status intel_cpu_transcoder_mode_valid (struct drm_i915_private *dev_priv, +const struct drm_display_mode *mode) +{ +/* +* Additional transcoder timing limits, +* excluding BXT/GLK DSI transcoders. +*/ if (DISPLAY_VER (dev_priv) >=5 ) {if (mode->hdisplay <64 || mode->htotal - mode->hdisplay <32 )
drivers/gpu/drm/i915/display/intel_display.h +3 -0
@@ -554,6 +554,9 @@ enum drm_mode_status intel_mode_valid_max_plane_size(struct drm_i915_private *dev_priv, const struct drm_display_mode *mode, bool bigjoiner); +enum drm_mode_status +intel_cpu_transcoder_mode_valid (struct drm_i915_private *i915, +const struct drm_display_mode *mode);enum phy intel_port_to_phy (struct drm_i915_private *i915,enum port port);bool is_trans_port_sync_mode (const struct intel_crtc_state *state);bool intel_crtc_is_bigjoiner_slave (const struct intel_crtc_state *crtc_state);
drivers/gpu/drm/i915/display/intel_dp.c +4 -0
@@ -973,6 +973,10 @@ intel_dp_mode_valid(struct drm_connector *_connector,enum drm_mode_status status;bool dsc = false, bigjoiner = false; + status =intel_cpu_transcoder_mode_valid (dev_priv, mode); +if (status !=MODE_OK ) +return status; +if (mode->flags &DRM_MODE_FLAG_DBLCLK )return MODE_H_ILLEGAL ;
drivers/gpu/drm/i915/display/intel_dp_mst.c +4 -0
@@ -703,6 +703,10 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector *connector,return 0 ; } + *status =intel_cpu_transcoder_mode_valid (dev_priv, mode); +if (*status !=MODE_OK ) +return 0 ; +if (mode->flags &DRM_MODE_FLAG_DBLSCAN ) { *status =MODE_NO_DBLESCAN ;return 0 ;
drivers/gpu/drm/i915/display/intel_dvo.c +6 -0
@@ -225,10 +225,16 @@ intel_dvo_mode_valid(struct drm_connector *connector, {struct intel_connector *intel_connector =to_intel_connector (connector);struct intel_dvo *intel_dvo =intel_attached_dvo (intel_connector); +struct drm_i915_private *i915 =to_i915 (intel_connector->base.dev);const struct drm_display_mode *fixed_mode =intel_panel_fixed_mode (intel_connector, mode);int max_dotclk =to_i915 (connector->dev)->max_dotclk_freq;int target_clock = mode->clock; +enum drm_mode_status status; + + status =intel_cpu_transcoder_mode_valid (i915, mode); +if (status !=MODE_OK ) +return status;if (mode->flags &DRM_MODE_FLAG_DBLSCAN )return MODE_NO_DBLESCAN ;
drivers/gpu/drm/i915/display/intel_hdmi.c +4 -0
@@ -1987,6 +1987,10 @@ intel_hdmi_mode_valid(struct drm_connector *connector,bool has_hdmi_sink =intel_has_hdmi_sink (hdmi, connector->state);bool ycbcr_420_only; + status =intel_cpu_transcoder_mode_valid (dev_priv, mode); +if (status !=MODE_OK ) +return status; +if ((mode->flags &DRM_MODE_FLAG_3D_MASK ) ==DRM_MODE_FLAG_3D_FRAME_PACKING ) clock *=2 ;
drivers/gpu/drm/i915/display/intel_lvds.c +5 -0
@@ -389,11 +389,16 @@ intel_lvds_mode_valid(struct drm_connector *connector, struct drm_display_mode *mode) {struct intel_connector *intel_connector =to_intel_connector (connector); +struct drm_i915_private *i915 =to_i915 (intel_connector->base.dev);const struct drm_display_mode *fixed_mode =intel_panel_fixed_mode (intel_connector, mode);int max_pixclk =to_i915 (connector->dev)->max_dotclk_freq;enum drm_mode_status status; + status =intel_cpu_transcoder_mode_valid (i915, mode); +if (status !=MODE_OK ) +return status; +if (mode->flags &DRM_MODE_FLAG_DBLSCAN )return MODE_NO_DBLESCAN ;
drivers/gpu/drm/i915/display/intel_sdvo.c +7 -1
@@ -1873,13 +1873,19 @@ static enum drm_mode_status intel_sdvo_mode_valid(struct drm_connector *connector, struct drm_display_mode *mode) { + struct drm_i915_private *i915 = to_i915(connector->dev);struct intel_sdvo *intel_sdvo =intel_attached_sdvo (to_intel_connector (connector));struct intel_sdvo_connector *intel_sdvo_connector =to_intel_sdvo_connector (connector); -int max_dotclk =to_i915 (connector->dev)->max_dotclk_freq;bool has_hdmi_sink =intel_has_hdmi_sink (intel_sdvo_connector, connector->state); +int max_dotclk = i915->max_dotclk_freq; +enum drm_mode_status status;int clock = mode->clock; + status =intel_cpu_transcoder_mode_valid (i915, mode); +if (status !=MODE_OK ) +return status; +if (mode->flags &DRM_MODE_FLAG_DBLSCAN )return MODE_NO_DBLESCAN ;
drivers/gpu/drm/i915/display/intel_tv.c +7 -1
@@ -956,8 +956,14 @@ static enum drm_mode_status intel_tv_mode_valid(struct drm_connector *connector, struct drm_display_mode *mode) { + struct drm_i915_private *i915 = to_i915(connector->dev);const struct tv_mode *tv_mode =intel_tv_mode_find (connector->state); -int max_dotclk =to_i915 (connector->dev)->max_dotclk_freq; +int max_dotclk = i915->max_dotclk_freq; +enum drm_mode_status status; + + status =intel_cpu_transcoder_mode_valid (i915, mode); +if (status !=MODE_OK ) +return status;if (mode->flags &DRM_MODE_FLAG_DBLSCAN )return MODE_NO_DBLESCAN ;
drivers/gpu/drm/i915/display/vlv_dsi.c +17 -1
@@ -1627,9 +1627,25 @@ static const struct drm_encoder_funcs intel_dsi_funcs = { .destroy = intel_dsi_encoder_destroy, }; +static enum drm_mode_status vlv_dsi_mode_valid (struct drm_connector *connector, +struct drm_display_mode *mode) +{ +struct drm_i915_private *i915 =to_i915 (connector->dev); + +if (IS_VALLEYVIEW (i915) ||IS_CHERRYVIEW (i915)) { +enum drm_mode_status status; + + status =intel_cpu_transcoder_mode_valid (i915, mode); +if (status !=MODE_OK ) +return status; + } + +return intel_dsi_mode_valid (connector, mode); +} +static const struct drm_connector_helper_funcs intel_dsi_connector_helper_funcs = { .get_modes = intel_dsi_get_modes, - .mode_valid = intel_dsi_mode_valid, + .mode_valid = vlv_dsi_mode_valid, .atomic_check = intel_digital_connector_atomic_check, };
Signature · 1 line
2.42.0
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.68 release. There are 194 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 13 Dec 2023 18:19:59 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.68-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.68 release. There are 194 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 13 Dec 2023 18:19:59 +0000. Anything received after that time might be too late.
No regressions found on WSL (x86 and arm64).
Built, booted, and reviewed dmesg.
Thank you.
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.68 release. There are 194 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 13 Dec 2023 18:19:59 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.68-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 6.1.68-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-6.1.y
* git commit: 807435a379b45e6eec975857b7daf5ac2b3fbf93
* git describe: v6.1.67-195-g807435a379b4
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.67-195-g807435a379b4
## Test Regressions (compared to v6.1.66)
## Metric Regressions (compared to v6.1.66)
## Test Fixes (compared to v6.1.66)
## Metric Fixes (compared to v6.1.66)
## Test result summary
total: 136008, pass: 114767, fail: 2850, skip: 18250, xfail: 141
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 151 total, 150 passed, 1 failed
* arm64: 52 total, 52 passed, 0 failed
* i386: 38 total, 38 passed, 0 failed
* mips: 26 total, 26 passed, 0 failed
* parisc: 4 total, 4 passed, 0 failed
* powerpc: 35 total, 35 passed, 0 failed
* riscv: 15 total, 15 passed, 0 failed
* s390: 16 total, 16 passed, 0 failed
* sh: 10 total, 10 passed, 0 failed
* sparc: 8 total, 8 passed, 0 failed
* x86_64: 46 total, 46 passed, 0 failed
## Test suites summary
* boot
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-exec
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-filesystems-epoll
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-user_events
* kselftest-vDSO
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* libgpiod
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance
* v4l2-complianciance
--
Linaro LKFT
https://lkft.linaro.org
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.68 release. There are 194 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Cheers,
Conor.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.68 release. There are 194 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 13 Dec 2023 18:19:59 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.68-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.68 release. There are 194 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 13 Dec 2023 18:19:59 +0000. Anything received after that time might be too late.
Build results:
total: 157 pass: 157 fail: 0 Qemu test results: total: 545 pass: 545 fail: 0
Guenter
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 6.1.68 release. There are 194 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.1.y
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
RTL8152_INACCESSIBLE was Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
In reply to Greg Kroah-HartmanHi!
Quoted 12 lines
This is the start of the stable review cycle for the 6.1.68 release. There are 194 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Douglas Anderson <[email protected]>
r8152: Add RTL8152_INACCESSIBLE to r8153_aldps_en()Douglas Anderson <[email protected]>
r8152: Add RTL8152_INACCESSIBLE to r8153_pre_firmware_1()
Quoted 8 lines
Douglas Anderson <[email protected]>
r8152: Add RTL8152_INACCESSIBLE to r8156b_wait_loading_flash()Douglas Anderson <[email protected]>
r8152: AddRTL8152_INACCESSIBLEchecks to more loopsDouglas Anderson <[email protected]>
r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLE
Central patch that actually fixes something is:
commit d9962b0d42029bcb40fe3c38bce06d1870fa4df4
Author: Douglas Anderson <[email protected]> Date: Fri Oct 20 14:06:59 2023 -0700
r8152: Block future register access if register access fails
...but we don't have that in 6.1. So we should not need the rest, either.
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Re: RTL8152_INACCESSIBLE was Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
Quoted 25 lines · Pavel Machek
Hi!
Quoted 12 lines
This is the start of the stable review cycle for the 6.1.68 release. There are 194 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Douglas Anderson <[email protected]>
r8152: Add RTL8152_INACCESSIBLE to r8153_aldps_en()Douglas Anderson <[email protected]>
r8152: Add RTL8152_INACCESSIBLE to r8153_pre_firmware_1()Quoted 8 lines
Douglas Anderson <[email protected]>
r8152: Add RTL8152_INACCESSIBLE to r8156b_wait_loading_flash()Douglas Anderson <[email protected]>
r8152: AddRTL8152_INACCESSIBLEchecks to more loopsDouglas Anderson <[email protected]>
r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLECentral patch that actually fixes something is:
Quoted 9 lines
commit
d9962b0d42029bcb40fe3c38bce06d1870fa4df4Author: Douglas Anderson <[email protected]> Date: Fri Oct 20 14:06:59 2023 -0700r8152: Block future register access if register access fails
...but we don't have that in 6.1. So we should not need the rest, either.
Also, the missing patch is fixed subsequently by another patch, so it can not be added on its own.
Guenter
Re: RTL8152_INACCESSIBLE was Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
Hi!
Quoted 27 lines
Quoted 27 lines
Quoted 12 lines
This is the start of the stable review cycle for the 6.1.68 release. There are 194 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Douglas Anderson <[email protected]>
r8152: Add RTL8152_INACCESSIBLE to r8153_aldps_en()Douglas Anderson <[email protected]>
r8152: Add RTL8152_INACCESSIBLE to r8153_pre_firmware_1()Quoted 8 lines
Douglas Anderson <[email protected]>
r8152: Add RTL8152_INACCESSIBLE to r8156b_wait_loading_flash()Douglas Anderson <[email protected]>
r8152: AddRTL8152_INACCESSIBLEchecks to more loopsDouglas Anderson <[email protected]>
r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLECentral patch that actually fixes something is:
commit
d9962b0d42029bcb40fe3c38bce06d1870fa4df4Author: Douglas Anderson <[email protected]> Date: Fri Oct 20 14:06:59 2023 -0700
Quoted 8 lines
Quoted 5 lines
r8152: Block future register access if register access fails
...but we don't have that in 6.1. So we should not need the rest, either.
Also, the missing patch is fixed subsequently by another patch, so it can not be added on its own.
For the record I'm trying to advocate "drop all patches listed as they don't fix the bug", not "add more", as this does not meet stable criteria.
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Greg Kroah-Hartman
maintainerRe: RTL8152_INACCESSIBLE was Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
Quoted 35 lines · Pavel Machek
Hi!
Quoted 33 lines
Quoted 32 lines
Quoted 12 lines
This is the start of the stable review cycle for the 6.1.68 release. There are 194 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Douglas Anderson <[email protected]>
r8152: Add RTL8152_INACCESSIBLE to r8153_aldps_en()Douglas Anderson <[email protected]>
r8152: Add RTL8152_INACCESSIBLE to r8153_pre_firmware_1()Quoted 8 lines
Douglas Anderson <[email protected]>
r8152: Add RTL8152_INACCESSIBLE to r8156b_wait_loading_flash()Douglas Anderson <[email protected]>
r8152: AddRTL8152_INACCESSIBLEchecks to more loopsDouglas Anderson <[email protected]>
r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLECentral patch that actually fixes something is:
commit
d9962b0d42029bcb40fe3c38bce06d1870fa4df4Author: Douglas Anderson <[email protected]> Date: Fri Oct 20 14:06:59 2023 -0700r8152: Block future register access if register access fails
...but we don't have that in 6.1. So we should not need the rest, either.
Quoted 6 lines
Quoted 2 lines
Also, the missing patch is fixed subsequently by another patch, so it can not be added on its own.
For the record I'm trying to advocate "drop all patches listed as they don't fix the bug", not "add more", as this does not meet stable criteria.
But the original commit here does say it fixes a bug, see the text of the commits listed above. So perhaps someone got this all wrong when they wrote the original commits that got merged into 6.7-rc? Otherwise this seems like they are sane to keep for now, unless the original author says they should be dropped, or someone who can test this driver says something went wrong.
thanks,
greg k-h
Re: RTL8152_INACCESSIBLE was Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
Hi,
Quoted 44 lines · Greg Kroah-Hartman
Quoted 35 lines · Pavel Machek
Hi!
Quoted 33 lines
Quoted 32 lines
Quoted 12 lines
This is the start of the stable review cycle for the 6.1.68 release. There are 194 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Douglas Anderson <[email protected]>
r8152: Add RTL8152_INACCESSIBLE to r8153_aldps_en()Douglas Anderson <[email protected]>
r8152: Add RTL8152_INACCESSIBLE to r8153_pre_firmware_1()Quoted 8 lines
Douglas Anderson <[email protected]>
r8152: Add RTL8152_INACCESSIBLE to r8156b_wait_loading_flash()Douglas Anderson <[email protected]>
r8152: AddRTL8152_INACCESSIBLEchecks to more loopsDouglas Anderson <[email protected]>
r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLECentral patch that actually fixes something is:
commit
d9962b0d42029bcb40fe3c38bce06d1870fa4df4Author: Douglas Anderson <[email protected]> Date: Fri Oct 20 14:06:59 2023 -0700r8152: Block future register access if register access fails
...but we don't have that in 6.1. So we should not need the rest, either.
Quoted 6 lines
Quoted 2 lines
Also, the missing patch is fixed subsequently by another patch, so it can not be added on its own.
For the record I'm trying to advocate "drop all patches listed as they don't fix the bug", not "add more", as this does not meet stable criteria.
Quoted 6 lines
But the original commit here does say it fixes a bug, see the text of the commits listed above. So perhaps someone got this all wrong when they wrote the original commits that got merged into 6.7-rc? Otherwise this seems like they are sane to keep for now, unless the original author says they should be dropped, or someone who can test this driver says something went wrong.
Right. The patches that "add RTL8152_INACCESSIBLE" to more loops are bugfixes, but they're not terribly important ones to backport. While they technically make sense even on older kernels and could conceivably make the older kernels unload the r8152 driver a little faster when a device is unplugged, it's not a big deal. On the first version of the recent patches I didn't even add a "Fixes" tag for them but I was asked to during the review process.
The "add RTL8152_INACCESSIBLE" patches become more important with commit d9962b0d4202 ("r8152: Block future register access if register access fails"). Once you have that it's possible to end up in the "INACCESSIBLE" situation in response to normal (ish) error handling and thus you want it to be faster.
Based on our experience in ChromeOS, commit d9962b0d4202 ("r8152:
Block future register access if register access fails") is a pretty important fix and I would say it should be backported to stable. Certainly we've backported it to our kernels in ChromeOS. In our case we made things easier on ourselves by backporting pretty much all patches to the r8152 driver.
-Doug
Greg Kroah-Hartman
maintainerRe: RTL8152_INACCESSIBLE was Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
Quoted 69 lines · Doug Anderson
Hi,
Quoted 44 lines · Greg Kroah-Hartman
Quoted 35 lines · Pavel Machek
Hi!
Quoted 33 lines
Quoted 32 lines
Quoted 12 lines
This is the start of the stable review cycle for the 6.1.68 release. There are 194 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Douglas Anderson <[email protected]>
r8152: Add RTL8152_INACCESSIBLE to r8153_aldps_en()Douglas Anderson <[email protected]>
r8152: Add RTL8152_INACCESSIBLE to r8153_pre_firmware_1()Quoted 8 lines
Douglas Anderson <[email protected]>
r8152: Add RTL8152_INACCESSIBLE to r8156b_wait_loading_flash()Douglas Anderson <[email protected]>
r8152: AddRTL8152_INACCESSIBLEchecks to more loopsDouglas Anderson <[email protected]>
r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLECentral patch that actually fixes something is:
commit
d9962b0d42029bcb40fe3c38bce06d1870fa4df4Author: Douglas Anderson <[email protected]> Date: Fri Oct 20 14:06:59 2023 -0700r8152: Block future register access if register access fails
...but we don't have that in 6.1. So we should not need the rest, either.
Quoted 6 lines
Quoted 2 lines
Also, the missing patch is fixed subsequently by another patch, so it can not be added on its own.
For the record I'm trying to advocate "drop all patches listed as they don't fix the bug", not "add more", as this does not meet stable criteria.
Quoted 6 lines
But the original commit here does say it fixes a bug, see the text of the commits listed above. So perhaps someone got this all wrong when they wrote the original commits that got merged into 6.7-rc? Otherwise this seems like they are sane to keep for now, unless the original author says they should be dropped, or someone who can test this driver says something went wrong.
Right. The patches that "add
RTL8152_INACCESSIBLE" to more loops are bugfixes, but they're not terribly important ones to backport. While they technically make sense even on older kernels and could conceivably make the older kernels unload the r8152 driver a little faster when a device is unplugged, it's not a big deal. On the first version of the recent patches I didn't even add a "Fixes" tag for them but I was asked to during the review process.The "add
RTL8152_INACCESSIBLE" patches become more important with commitd9962b0d4202("r8152: Block future register access if register access fails"). Once you have that it's possible to end up in the "INACCESSIBLE" situation in response to normal (ish) error handling and thus you want it to be faster.
Quoted 6 lines
Based on our experience in ChromeOS, commit
d9962b0d4202("r8152:
Block future register access if register access fails") is a pretty important fix and I would say it should be backported to stable. Certainly we've backported it to our kernels in ChromeOS. In our case we made things easier on ourselves by backporting pretty much all patches to the r8152 driver.
Ok, as lots of fixes seem to be needed here, do you have a list of the git ids that we should backport to bring this up to a workable state like you have in your tree?
thanks,
greg k-h
Re: RTL8152_INACCESSIBLE was Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
Hi,
Quoted 78 lines · Greg Kroah-Hartman
Quoted 69 lines · Doug Anderson
Hi,
Quoted 44 lines · Greg Kroah-Hartman
Quoted 35 lines · Pavel Machek
Hi!
Quoted 33 lines
Quoted 32 lines
Quoted 12 lines
This is the start of the stable review cycle for the 6.1.68 release. There are 194 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Douglas Anderson <[email protected]>
r8152: Add RTL8152_INACCESSIBLE to r8153_aldps_en()Douglas Anderson <[email protected]>
r8152: Add RTL8152_INACCESSIBLE to r8153_pre_firmware_1()Quoted 8 lines
Douglas Anderson <[email protected]>
r8152: Add RTL8152_INACCESSIBLE to r8156b_wait_loading_flash()Douglas Anderson <[email protected]>
r8152: AddRTL8152_INACCESSIBLEchecks to more loopsDouglas Anderson <[email protected]>
r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLECentral patch that actually fixes something is:
commit
d9962b0d42029bcb40fe3c38bce06d1870fa4df4Author: Douglas Anderson <[email protected]> Date: Fri Oct 20 14:06:59 2023 -0700r8152: Block future register access if register access fails
...but we don't have that in 6.1. So we should not need the rest, either.
Quoted 6 lines
Quoted 2 lines
Also, the missing patch is fixed subsequently by another patch, so it can not be added on its own.
For the record I'm trying to advocate "drop all patches listed as they don't fix the bug", not "add more", as this does not meet stable criteria.
Quoted 6 lines
But the original commit here does say it fixes a bug, see the text of the commits listed above. So perhaps someone got this all wrong when they wrote the original commits that got merged into 6.7-rc? Otherwise this seems like they are sane to keep for now, unless the original author says they should be dropped, or someone who can test this driver says something went wrong.
Right. The patches that "add
RTL8152_INACCESSIBLE" to more loops are bugfixes, but they're not terribly important ones to backport. While they technically make sense even on older kernels and could conceivably make the older kernels unload the r8152 driver a little faster when a device is unplugged, it's not a big deal. On the first version of the recent patches I didn't even add a "Fixes" tag for them but I was asked to during the review process.The "add
RTL8152_INACCESSIBLE" patches become more important with commitd9962b0d4202("r8152: Block future register access if register access fails"). Once you have that it's possible to end up in the "INACCESSIBLE" situation in response to normal (ish) error handling and thus you want it to be faster.Quoted 6 lines
Based on our experience in ChromeOS, commit
d9962b0d4202("r8152:
Block future register access if register access fails") is a pretty important fix and I would say it should be backported to stable. Certainly we've backported it to our kernels in ChromeOS. In our case we made things easier on ourselves by backporting pretty much all patches to the r8152 driver.
Quoted 3 lines
Ok, as lots of fixes seem to be needed here, do you have a list of the git ids that we should backport to bring this up to a workable state like you have in your tree?
The ones that were relevant to commit d9962b0d4202 ("r8152: Block future register access if register access fails") were these, which is basically the two series that I landed recently.:
79321a793945 r8152: Add RTL8152_INACCESSIBLE to r8153_aldps_en() 8c53a7bd7065 r8152: Add RTL8152_INACCESSIBLE to r8153_pre_firmware_1() 8a67b47fced9 r8152: Add RTL8152_INACCESSIBLE to r8156b_wait_loading_flash() 32a574c7e268 r8152: Add RTL8152_INACCESSIBLE checks to more loops e62adaeecdc6 r8152: Hold the rtnl_lock for all of reset
d9962b0d4202 r8152: Block future register access if register access fails 715f67f33af4 r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLE bc65cc42af73 r8152: Check for unplug in r8153b_ups_en() / r8153c_ups_en() dc90ba37a8c3 r8152: Check for unplug in rtl_phy_patch_request() b8d35024d405 r8152: Release firmware if we have an error in probe bb8adff9123e r8152: Cancel hw_phy_work if we have an error in probe 5dd176895269 r8152: Run the unload routine if we have errors during probe a5feba71ec9c r8152: Increase USB control msg timeout to 5000ms as per spec
The problem, of course, is that picking commit d9962b0d4202 ("r8152:
Block future register access if register access fails") causes conflicts with other changes that have happened to this driver. On ChromeOS we generally resolve things like this by just picking the extra patches. We already had quite a few backports to the ChromeOS kernel trees, so I can't say it would be the same for stable branches. On ChromeOS 5.15 you can see the picks that were needed at:
If you click "SHOW ALL (17)" then you can see the patches that I uploaded together to get things resolved on our ChromeOS 5.15 branch. There are also links to our 6.1, 5.10, and 5.4 branches.
One note is that as part of taking these extra patches we ended up getting commit ec51fbd1b8a2 ("r8152: add USB device driver for config selection") which caused a regression. That's where the following recent changes that landed in your tree came from:
aa4f2b3e418e r8152: Choose our USB config with choose_configuration() rather than probe()a87b8e3be926 usb: core: Allow subclassed USB drivers to override usb_choose_configuration()c2d95fcff0f0 usb: core: Don't force USB generic_subclass drivers to define probe()
...and where the (pending) extra patch came from:
https://lore.kernel.org/r/20231211073237.v3.1.If27eb3bf7812f91ab83810f232292f032f4203e0@changeid
("usb: core: Fix crash w/ usb_choose_configuration() if no driver")
-Doug
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.68 release. There are 194 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 13 Dec 2023 18:19:59 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.68-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.68 release. There are 194 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 13 Dec 2023 18:19:59 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.68-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.1:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
116 tests: 116 pass, 0 failLinux version: 6.1.68-rc1-g807435a379b4
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Jon
Hello,
Quoted 5 lines · On 2023-12-11T19:19:50+01:00 Greg Kroah-Hartman <[email protected]>…
This is the start of the stable review cycle for the 6.1.68 release. There are 194 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 8 lines
Responses should be made by Wed, 13 Dec 2023 18:19:59 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.68-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.
This rc kernel passes DAMON functionality test[1] on my test machine. Attaching the test results summary below. Please note that I retrieved the kernel from linux-stable-rc tree[2].
[1] https://github.com/awslabs/damon-tests/tree/next/corr
[2] 807435a379b4 ("Linux 6.1.68-rc1")
Thanks,
SJ
[...]
---
ok 1 selftests: damon: debugfs_attrs.sh
ok 2 selftests: damon: debugfs_schemes.sh
ok 3 selftests: damon: debugfs_target_ids.sh
ok 4 selftests: damon: debugfs_empty_targets.sh
ok 5 selftests: damon: debugfs_huge_count_read_write.sh
ok 6 selftests: damon: debugfs_duplicate_context_creation.sh
ok 7 selftests: damon: sysfs.sh
ok 1 selftests: damon-tests: kunit.sh
ok 2 selftests: damon-tests: huge_count_read_write.sh
ok 3 selftests: damon-tests: buffer_overflow.sh
ok 4 selftests: damon-tests: rm_contexts.sh
ok 5 selftests: damon-tests: record_null_deref.sh
ok 6 selftests: damon-tests: dbgfs_target_ids_read_before_terminate_race.sh ok 7 selftests: damon-tests: dbgfs_target_ids_pid_leak.sh
ok 8 selftests: damon-tests: damo_tests.sh
ok 9 selftests: damon-tests: masim-record.sh
ok 10 selftests: damon-tests: build_i386.sh
ok 11 selftests: damon-tests: build_arm64.sh
ok 12 selftests: damon-tests: build_i386_idle_flag.sh
ok 13 selftests: damon-tests: build_i386_highpte.sh
ok 14 selftests: damon-tests: build_nomemcg.sh
[33m
[92mPASS [39m