| Age | Commit message (Collapse) | Author |
|---|
|
Handle the DSC pixel throughput quirk, limiting the compressed link-bpp
value for Synaptics Panamera branch devices, working around a
blank/unstable output issue observed on docking stations containing
these branch devices, when using a mode with a high pixel clock and a
high compressed link-bpp value.
For now use the same mode clock limit for RGB/YUV444 and YUV422/420
output modes. This may result in limiting the link-bpp value for a
YUV422/420 output mode already at a lower than required mode clock.
v2: Apply the quirk only when DSC is enabled.
v3 (Ville):
- Move adjustment of link-bpp within the already existing is_dsc
if branch.
- Add TODO comment to move the HW revision check as well to the
DRM core quirk table.
v4:
- Fix incorrect fxp_q4_from_int(INT_MAX) vs. INT_MAX return value
from dsc_throughput_quirk_max_bpp_x16().
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reported-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reported-and-tested-by: Swati Sharma <swati2.sharma@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250930182450.563016-7-imre.deak@intel.com
|
|
Read out the branch devices' maximum overall DSC pixel throughput and
line width and verify the mode's corresponding pixel clock and hactive
period against these.
v2: Use drm helpers to query the throughput/line-width caps. (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reported-and-tested-by: Swati Sharma <swati2.sharma@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250930182450.563016-6-imre.deak@intel.com
|
|
Pass the DPCD sink/branch device descriptor along with the
is_branch/sink flag to intel_dp_get_dsc_sink_cap(). These will be used
by a follow up change to read out the branch device's DSC overall
throughput/line width capabilities and to detect a throughput/link-bpp
quirk.
Reported-and-tested-by: Swati Sharma <swati2.sharma@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250930182450.563016-5-imre.deak@intel.com
|
|
Use the DSC sink device's actual per-slice peak throughput to calculate
the minimum number of required DSC slices, falling back to the
hard-coded throughput values (as suggested by the DP Standard) if the
device's reported throughput value is 0.
For now use the minimum of the two throughput values, which is ok,
potentially resulting in a higher than required minimum slice count.
This doesn't change the current way of using the same minimum throughput
value regardless of the RGB/YUV output format used.
While at it add a TODO comment for MST tiled displays to calculate the
slice count for these based on the total pixel rate of all the tiles.
v2: Use drm helpers to query the throughput caps. (Ville)
v3: Add TODO comment to account for MST tiled displays. (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reported-and-tested-by: Swati Sharma <swati2.sharma@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250930182450.563016-4-imre.deak@intel.com
|
|
Add helpers to query the DP DSC sink device's per-slice throughput as
well as a DSC branch device's overall throughput and line-width
capabilities.
v2 (Ville):
- Rename pixel_clock to peak_pixel_rate, document what the value means
in case of MST tiled displays.
- Fix name of drm_dp_dsc_branch_max_slice_throughput() to
drm_dp_dsc_sink_max_slice_throughput().
v3:
- Fix the DSC branch device minimum valid line width value from 2560
to 5120 pixels.
- Fix drm_dp_dsc_sink_max_slice_throughput()'s pixel_clock parameter
name to peak_pixel_rate in header file.
- Add handling for throughput mode 0 granular delta, defined by DP
Standard v2.1a.
v4:
- Remove the default switch case in
drm_dp_dsc_sink_max_slice_throughput(), which is unreachable in the
current code. (Ville)
Cc: dri-devel@lists.freedesktop.org
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reported-and-tested-by: Swati Sharma <swati2.sharma@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250930182450.563016-3-imre.deak@intel.com
|
|
Some Synaptics MST branch devices have a problem decompressing a stream
with a compressed link-bpp higher than 12, if the pixel clock is higher
than ~50 % of the maximum throughput capability reported by the branch
device. The screen remains blank, or for some - mostly black content -
gets enabled, but may stil have jitter artifacts.
At least the following docking stations are affected, based on testing
both with any Intel devices or the UCD-500 reference device as a source:
- DELL WD19DCS, DELL WD19TB3, DELL WD22TB4
- ThinkPad 40AN
- HP G2
At least the following docking stations are free from this problem,
based on tests with a source/sink/mode etc. configuration matching the
test cases used above:
- DELL Dual Charge HD22Q, DELL WD25TB5
- ThinkPad 40B0
- Anker 565
All the affected devices have an older version of the Synaptics MST
branch device (Panamera), whereas all the non-affected docking stations
have a newer branch device (at least Synaptics Panamera with a higher HW
revision number and Synaptics Cayenne models). Add the required quirk
entries accordingly. The quirk will be handled by the i915/xe drivers in
a follow-up change.
The latest firmware version of the Synaptics branch device for all the
affected devices tested above is 5.7 (as reported at DPCD address
0x50a/0x50b). For the DELL devices this corresponds to the latest
01.00.14.01.A03 firmware package version of the docking station.
v2:
- Document the DP_DPCD_QUIRK_DSC_THROUGHPUT_BPP_LIMIT enum.
- Describe the quirk in more detail in the dpcd_quirk_list.
v3:
- s/Panarema/Panamera in the commit log.
Cc: dri-devel@lists.freedesktop.org
Reported-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reported-and-tested-by: Swati Sharma <swati2.sharma@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250930182450.563016-2-imre.deak@intel.com
|
|
Add documentation for Xe Execution Queues and add xe_exec_queue.rst
file.
v2: Add info about how Execution queue interfaces
with other components in the driver (Matt Brost)
Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20251002044319.450181-2-niranjana.vishwanathapura@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/melver/linux
Pull Kernel Concurrency Sanitizer (KCSAN) update from Marco Elver:
- Replace deprecated strcpy() with strscpy()
* tag 'kcsan-20250929-v6.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/melver/linux:
kcsan: test: Replace deprecated strcpy() with strscpy()
|
|
The ns_bpf_qdisc selftest triggers a kernel panic:
Oops[#1]:
CPU 0 Unable to handle kernel paging request at virtual address 0000000000741d58, era == 90000000851b5ac0, ra == 90000000851b5aa4
CPU: 0 UID: 0 PID: 449 Comm: test_progs Tainted: G OE 6.16.0+ #3 PREEMPT(full)
Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
pc 90000000851b5ac0 ra 90000000851b5aa4 tp 90000001076b8000 sp 90000001076bb600
a0 0000000000741ce8 a1 0000000000000001 a2 90000001076bb5c0 a3 0000000000000008
a4 90000001004c4620 a5 9000000100741ce8 a6 0000000000000000 a7 0100000000000000
t0 0000000000000010 t1 0000000000000000 t2 9000000104d24d30 t3 0000000000000001
t4 4f2317da8a7e08c4 t5 fffffefffc002f00 t6 90000001004c4620 t7 ffffffffc61c5b3d
t8 0000000000000000 u0 0000000000000001 s9 0000000000000050 s0 90000001075bc800
s1 0000000000000040 s2 900000010597c400 s3 0000000000000008 s4 90000001075bc880
s5 90000001075bc8f0 s6 0000000000000000 s7 0000000000741ce8 s8 0000000000000000
ra: 90000000851b5aa4 __qdisc_run+0xac/0x8d8
ERA: 90000000851b5ac0 __qdisc_run+0xc8/0x8d8
CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
PRMD: 00000004 (PPLV0 +PIE -PWE)
EUEN: 00000007 (+FPE +SXE +ASXE -BTE)
ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
BADV: 0000000000741d58
PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE)]
Process test_progs (pid: 449, threadinfo=000000009af02b3a, task=00000000e9ba4956)
Stack : 0000000000000000 90000001075bc8ac 90000000869524a8 9000000100741ce8
90000001075bc800 9000000100415300 90000001075bc8ac 0000000000000000
900000010597c400 900000008694a000 0000000000000000 9000000105b59000
90000001075bc800 9000000100741ce8 0000000000000050 900000008513000c
9000000086936000 0000000100094d4c fffffff400676208 0000000000000000
9000000105b59000 900000008694a000 9000000086bf0dc0 9000000105b59000
9000000086bf0d68 9000000085147010 90000001075be788 0000000000000000
9000000086bf0f98 0000000000000001 0000000000000010 9000000006015840
0000000000000000 9000000086be6c40 0000000000000000 0000000000000000
0000000000000000 4f2317da8a7e08c4 0000000000000101 4f2317da8a7e08c4
...
Call Trace:
[<90000000851b5ac0>] __qdisc_run+0xc8/0x8d8
[<9000000085130008>] __dev_queue_xmit+0x578/0x10f0
[<90000000853701c0>] ip6_finish_output2+0x2f0/0x950
[<9000000085374bc8>] ip6_finish_output+0x2b8/0x448
[<9000000085370b24>] ip6_xmit+0x304/0x858
[<90000000853c4438>] inet6_csk_xmit+0x100/0x170
[<90000000852b32f0>] __tcp_transmit_skb+0x490/0xdd0
[<90000000852b47fc>] tcp_connect+0xbcc/0x1168
[<90000000853b9088>] tcp_v6_connect+0x580/0x8a0
[<90000000852e7738>] __inet_stream_connect+0x170/0x480
[<90000000852e7a98>] inet_stream_connect+0x50/0x88
[<90000000850f2814>] __sys_connect+0xe4/0x110
[<90000000850f2858>] sys_connect+0x18/0x28
[<9000000085520c94>] do_syscall+0x94/0x1a0
[<9000000083df1fb8>] handle_syscall+0xb8/0x158
Code: 4001ad80 2400873f 2400832d <240073cc> 001137ff 001133ff 6407b41f 001503cc 0280041d
---[ end trace 0000000000000000 ]---
The bpf_fifo_dequeue prog returns a skb which is a pointer. The pointer
is treated as a 32bit value and sign extend to 64bit in epilogue. This
behavior is right for most bpf prog types but wrong for struct ops which
requires LoongArch ABI.
So let's sign extend struct ops return values according to the LoongArch
ABI ([1]) and return value spec in function model.
[1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
Cc: stable@vger.kernel.org
Fixes: 6abf17d690d8 ("LoongArch: BPF: Add struct ops support for trampoline")
Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
Bail out instead of trying to perform a bpf_arch_text_copy() if
__arch_prepare_bpf_trampoline() failed.
Cc: stable@vger.kernel.org
Tested-by: Vincent Li <vincent.mc.li@gmail.com>
Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
When attach fentry/fexit BPF programs, __arch_prepare_bpf_trampoline()
is called twice with different `struct bpf_tramp_image *im`:
bpf_trampoline_update()
-> arch_bpf_trampoline_size()
-> __arch_prepare_bpf_trampoline()
-> arch_prepare_bpf_trampoline()
-> __arch_prepare_bpf_trampoline()
Use move_imm() will emit unstable instruction sequences, so let's use
move_addr() instead to prevent subtle bugs.
(I observed this while debugging other issues with printk.)
Cc: stable@vger.kernel.org
Tested-by: Vincent Li <vincent.mc.li@gmail.com>
Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
Currently, arch_alloc_bpf_trampoline() use bpf_prog_pack_alloc() which
will pack multiple trampolines into a huge page. So, no need to assume
the trampoline size is page aligned.
Cc: stable@vger.kernel.org
Tested-by: Vincent Li <vincent.mc.li@gmail.com>
Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
The current implementation does not support struct argument. This causes
a oops when running bpf selftest:
$ ./test_progs -a tracing_struct
Oops[#1]:
CPU -1 Unable to handle kernel paging request at virtual address 0000000000000018, era == 9000000085bef268, ra == 90000000844f3938
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: 1-...0: (19 ticks this GP) idle=1094/1/0x4000000000000000 softirq=1380/1382 fqs=801
rcu: (detected by 0, t=5252 jiffies, g=1197, q=52 ncpus=4)
Sending NMI from CPU 0 to CPUs 1:
rcu: rcu_preempt kthread starved for 2495 jiffies! g1197 f0x0 RCU_GP_DOING_FQS(6) ->state=0x0 ->cpu=2
rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_preempt state:I stack:0 pid:15 tgid:15 ppid:2 task_flags:0x208040 flags:0x00000800
Stack : 9000000100423e80 0000000000000402 0000000000000010 90000001003b0680
9000000085d88000 0000000000000000 0000000000000040 9000000087159350
9000000085c2b9b0 0000000000000001 900000008704a000 0000000000000005
00000000ffff355b 00000000ffff355b 0000000000000000 0000000000000004
9000000085d90510 0000000000000000 0000000000000002 7b5d998f8281e86e
00000000ffff355c 7b5d998f8281e86e 000000000000003f 9000000087159350
900000008715bf98 0000000000000005 9000000087036000 900000008704a000
9000000100407c98 90000001003aff80 900000008715c4c0 9000000085c2b9b0
00000000ffff355b 9000000085c33d3c 00000000000000b4 0000000000000000
9000000007002150 00000000ffff355b 9000000084615480 0000000007000002
...
Call Trace:
[<9000000085c2a868>] __schedule+0x410/0x1520
[<9000000085c2b9ac>] schedule+0x34/0x190
[<9000000085c33d38>] schedule_timeout+0x98/0x140
[<90000000845e9120>] rcu_gp_fqs_loop+0x5f8/0x868
[<90000000845ed538>] rcu_gp_kthread+0x260/0x2e0
[<900000008454e8a4>] kthread+0x144/0x238
[<9000000085c26b60>] ret_from_kernel_thread+0x28/0xc8
[<90000000844f20e4>] ret_from_kernel_thread_asm+0xc/0x88
rcu: Stack dump where RCU GP kthread last ran:
Sending NMI from CPU 0 to CPUs 2:
NMI backtrace for cpu 2 skipped: idling at idle_exit+0x0/0x4
Reject it for now.
Cc: stable@vger.kernel.org
Fixes: f9b6b41f0cf3 ("LoongArch: BPF: Add basic bpf trampoline support")
Tested-by: Vincent Li <vincent.mc.li@gmail.com>
Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
The current implementation of bpf_arch_text_poke() requires 5 nops
at patch site which is not applicable for kernel/module functions.
Because LoongArch reserves ONLY 2 nops at the function entry. With
CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS=y, this can be done by ftrace
instead.
See the following commit for details:
* commit b91e014f078e ("bpf: Make BPF trampoline use register_ftrace_direct() API")
* commit 9cdc3b6a299c ("LoongArch: ftrace: Add direct call support")
Cc: stable@vger.kernel.org
Tested-by: Vincent Li <vincent.mc.li@gmail.com>
Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
The bpf_flush_icache() is called by bpf_arch_text_copy() already. So
remove it. This has been done in arm64 and riscv.
Cc: stable@vger.kernel.org
Tested-by: Vincent Li <vincent.mc.li@gmail.com>
Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
The check for (BPF_TRAMP_F_ORIG_STACK | BPF_TRAMP_F_SHARE_IPMODIFY) is
duplicated in __arch_prepare_bpf_trampoline(). Remove it.
While at it, make sure stack_size and nargs are initialized once.
Cc: stable@vger.kernel.org
Tested-by: Vincent Li <vincent.mc.li@gmail.com>
Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
In __arch_prepare_bpf_trampoline(), retval_off is meaningful only when
save_ret is not 0, so the current logic is correct. But it may cause a
build warning:
arch/loongarch/net/bpf_jit.c:1547 __arch_prepare_bpf_trampoline() error: uninitialized symbol 'retval_off'.
So initialize retval_off unconditionally to fix it.
Cc: stable@vger.kernel.org
Fixes: f9b6b41f0cf3 ("LoongArch: BPF: Add basic bpf trampoline support")
Closes: https://lore.kernel.org/r/202508191020.PBBh07cK-lkp@intel.com/
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
For 8-bit and 16-bit sign-extention mov instructions, it can use the
native instructions ext.w.b and ext.w.h directly, no need to use the
temporary t1 register, just remove the redundant operations.
Here are the test results:
# modprobe test_bpf test_range=81,84
# dmesg -t | tail -5
test_bpf: #81 ALU_MOVSX | BPF_B jited:1 5 PASS
test_bpf: #82 ALU_MOVSX | BPF_H jited:1 5 PASS
test_bpf: #83 ALU64_MOVSX | BPF_B jited:1 5 PASS
test_bpf: #84 ALU64_MOVSX | BPF_H jited:1 5 PASS
test_bpf: Summary: 4 PASSED, 0 FAILED, [4/4 JIT'ed]
Acked-by: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
The atomic instructions sc.q, llacq.{w/d}, screl.{w/d} were newly added
in the LoongArch Reference Manual v1.10, it is necessary to handle them
in insns_not_supported() to avoid putting a breakpoint in the middle of
a ll/sc atomic sequence, otherwise it will loop forever for kprobes and
uprobes.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
Attempt VMA lock-based page fault handling first, and fall back to the
existing mmap_lock-based handling if that fails.
The "ebizzy -mTRp" test on Loongson-3A6000 shows that PER_VMA_LOCK can
improve the benchmark by about 17.9% (97837.7 to 115430.8).
This is the LoongArch variant of "x86/mm: try VMA lock-based page fault
handling first".
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
Automatically disable kaslr when the kernel loads from kexec_file.
kexec_file loads the secondary kernel image to a non-linked address,
inherently providing KASLR-like randomization.
However, on LoongArch where System RAM may be non-contiguous, enabling
KASLR for the second kernel may relocate it to an invalid memory region
and cause a boot failure. Thus, we disable KASLR when "kexec_file" is
detected in the command line.
To ensure compatibility with older kernels loaded via kexec_file, this
patch should be backported to stable branches.
Cc: stable@vger.kernel.org
Signed-off-by: Youling Tang <tangyouling@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
Enabling crash dump (kdump) includes:
- Prepare contents of ELF header of a core dump file, /proc/vmcore,
using crash_prepare_elf64_headers().
- Add "mem=size@start" parameter to the command line and pass it to the
capture kernel. Limit the runtime memory area of the captured kernel
to avoid disrupting the production kernel's runtime state.
- Add "elfcorehdr=size@start" parameter to the cmdline.
The basic usage for kdump (add the cmdline parameter crashkernel=512M
to grub.cfg for production kernel):
1) Load capture kernel image (vmlinux.efi or vmlinux can both be used):
# kexec -s -p vmlinuz.efi --initrd=initrd.img --reuse-cmdline
2) Do something to crash, like:
# echo c > /proc/sysrq-trigger
Signed-off-by: Youling Tang <tangyouling@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
This patch creates kexec_elf_ops to load ELF binary file for
kexec_file_load() syscall.
However, for `kbuf->memsz` and `kbuf->buf_min`, special handling is
required, and the generic `kexec_elf_load()` cannot be used directly.
$ readelf -l vmlinux
...
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000010000 0x9000000000200000 0x9000000000200000
0x0000000002747a00 0x000000000287a0d8 RWE 0x10000
NOTE 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 R 0x8
phdr->p_paddr should have been a physical address, but it is a virtual
address on the current LoongArch. This will cause kexec_file to fail
when loading the kernel and need to be converted to a physical address.
From the above MemSiz, it can be seen that 0x287a0d8 isn't page aligned.
Although kexec_add_buffer() will perform PAGE_SIZE alignment on kbuf->
memsz, there is still a stampeding in the loaded kernel space and initrd
space. The initrd resolution failed when starting the second kernel.
It can be known from the link script vmlinux.lds.S that,
BSS_SECTION(0, SZ_64K, 8)
. = ALIGN(PECOFF_SEGMENT_ALIGN);
It needs to be aligned according to SZ_64K, so that after alignment, its
size is consistent with _kernel_asize.
The basic usage (vmlinux):
1) Load second kernel image:
# kexec -s -l vmlinux --initrd=initrd.img --reuse-cmdline
2) Startup second kernel:
# kexec -e
Signed-off-by: Youling Tang <tangyouling@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
This patch creates kexec_efi_ops to load EFI binary file for
kexec_file_load() syscall.
The efi_kexec_load() as two parts:
- the first part loads the kernel image (vmlinuz.efi or vmlinux.efi)
- the second part loads other segments (e.g: initrd, cmdline, etc)
Currently, pez (vmlinuz.efi) and pei (vmlinux.efi) format images are
supported.
The basic usage (vmlinuz.efi or vmlinux.efi):
1) Load second kernel image:
# kexec -s -l vmlinuz.efi --initrd=initrd.img --reuse-cmdline
2) Startup second kernel:
# kexec -e
Signed-off-by: Youling Tang <tangyouling@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
Add some preparatory infrastructure:
- Add command line processing.
- Add support for loading other segments.
- Other minor modifications.
This initrd will be passed to the second kernel via the command line
'initrd=start,size'.
The 'kexec_file' command line parameter indicates that the kernel is
loaded via kexec_file.
Signed-off-by: Youling Tang <tangyouling@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
Define a dedicated image header structure for LoongArch architecture to
standardize kernel loading in bootloaders (primarily for kexec_file).
This header includes critical metadata, such as PE/DOS signature, kernel
entry points, kernel image size and load address offset, etc.
Signed-off-by: Youling Tang <tangyouling@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
For power saving or debugging purpose, we usually want to limit the SIMD
(LSX/LASX) usage on a rich feature platform. So allow specify SIMD width
via kernel parameters "simd=".
Allowed values of "simd=" are any integers, and recommended values are:
0: Disable all SIMD features;
128: Enable at most 128bit SIMD features;
256: Enable at most 256bit SIMD features;
-1(default): Enable as many as possible SIMD features automatically.
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
Init acpi_gbl_use_global_lock to false, in order to void error messages
during boot phase:
ACPI Error: Could not enable GlobalLock event (20240827/evxfevnt-182)
ACPI Error: No response from Global Lock hardware, disabling lock (20240827/evglock-59)
Fixes: 628c3bb40e9a8cefc0a6 ("LoongArch: Add boot and setup routines")
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
Commit b15212824a01 ("LoongArch: Make LTO case independent in Makefile")
moves "KBUILD_LDFLAGS += -mllvm --loongarch-annotate-tablejump" out of
CONFIG_CC_HAS_ANNOTATE_TABLEJUMP, which breaks the build for LLVM-18, as
'--loongarch-annotate-tablejump' is unimplemented there:
ld.lld: error: -mllvm: ld.lld: Unknown command line argument '--loongarch-annotate-tablejump'.
Call ld-option to detect '--loongarch-annotate-tablejump' before use, so
as to fix the build error.
Fixes: b15212824a01 ("LoongArch: Make LTO case independent in Makefile")
Reported-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org> # build
Suggested-by: WANG Rui <wangrui@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
Currently, when compiling with GCC, there is no "break 7" instruction
for zero division due to using the option -mno-check-zero-division, but
the compiler still generates "break 0" instruction for zero division.
Here is a simple example:
$ cat test.c
int div(int a)
{
return a / 0;
}
$ gcc -O2 -S test.c -o test.s
GCC generates "break 0" on LoongArch and "ud2" on x86, objtool decodes
"ud2" as INSN_BUG for x86, so decode "break 0" as INSN_BUG can fix the
objtool warnings for LoongArch, but this is not the intention.
When decoding "break 0" as INSN_TRAP in the previous commit, the aim is
to handle "break 0" as a trap. The generated "break 0" for zero division
by GCC is not proper, it should generate a break instruction with proper
bug type, so add the GCC option -fno-isolate-erroneous-paths-dereference
to avoid generating the unexpected "break 0" instruction for now.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/r/202509200413.7uihAxJ5-lkp@intel.com/
Fixes: baad7830ee9a ("objtool/LoongArch: Mark types based on break immediate code")
Suggested-by: WANG Rui <wangrui@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
When platform firmware supplies error information to the OS, e.g., via the
ACPI APEI GHES mechanism, it may identify an error source device that
doesn't advertise an AER Capability and therefore dev->aer_info, which
contains AER stats and ratelimiting data, is NULL.
pci_dev_aer_stats_incr() already checks dev->aer_info for NULL, but
aer_ratelimit() did not, leading to NULL pointer dereferences like this one
from the URL below:
{1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 0
{1}[Hardware Error]: event severity: corrected
{1}[Hardware Error]: device_id: 0000:00:00.0
{1}[Hardware Error]: vendor_id: 0x8086, device_id: 0x2020
{1}[Hardware Error]: aer_cor_status: 0x00001000, aer_cor_mask: 0x00002000
BUG: kernel NULL pointer dereference, address: 0000000000000264
RIP: 0010:___ratelimit+0xc/0x1b0
pci_print_aer+0x141/0x360
aer_recover_work_func+0xb5/0x130
[8086:2020] is an Intel "Sky Lake-E DMI3 Registers" device that claims to
be a Root Port but does not advertise an AER Capability.
Add a NULL check in aer_ratelimit() to avoid the NULL pointer dereference.
Note that this also prevents ratelimiting these events from GHES.
Fixes: a57f2bfb4a5863 ("PCI/AER: Ratelimit correctable and non-fatal error logging")
Link: https://lore.kernel.org/r/buduna6darbvwfg3aogl5kimyxkggu3n4romnmq6sozut6axeu@clnx7sfsy457/
Signed-off-by: Breno Leitao <leitao@debian.org>
[bhelgaas: add crash details to commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20250929-aer_crash_2-v1-1-68ec4f81c356@debian.org
|
|
LoongArch architecture changes for 6.18 need acpica changes to handle
global lock initialization, so merge 'acpi-6.18-rc1' to create a base.
|
|
In S3 and above sleep states, the device can loose power regardless of
d3cold.allowed flag. Bring up I2C controller explicitly in system PM
path to ensure its normal operation after losing power.
v2: Cover S3 and above states (Rodrigo)
Fixes: 0ea07b69517a ("drm/xe/pm: Wire up suspend/resume for I2C controller")
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250918103200.2952576-1-raag.jadav@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Initialize the uval variable to 0 in xe_late_bind_fw_num_fans() to fix
a potential use of uninitialized variable warning and ensure predictable
behavior.
The variable is passed by reference to xe_pcode_read() which should
populate it on success, but initializing it to 0 provides a safe
default value and follows kernel coding best practices.
v2:
- uval = 0 which serves as both a safe default and the fallback
value when the pcode read operation fails.
v3:
- Handle MMIO failure (Rodrigo)
- The function should probably return the error and make the uval as
pointer-argument, like the pcode_read.
- Change the caller of this function to propagate the error
upwards if mmio failed.
Fixes: 45832bf9c10f3 ("drm/xe/xe_late_bind_fw: Initialize late binding firmware")
Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
Link: https://lore.kernel.org/r/20251002005648.3185636-1-mallesh.koujalagi@intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
buffer time
Instead of constraining the ALSA buffer time to be double of the firmware
host buffer size, it is better to set it for the period time.
This will implicitly constrain the buffer time to a safe value
(num_periods is at least 2) and prohibits applications to set smaller
period size than what will be covered by the initial DMA burst.
Fixes: fe76d2e75a6d ("ASoC: SOF: Intel: hda-pcm: Use dsp_max_burst_size_in_ms to place constraint")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20251002135752.2430-4-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
For ChainDMA the firmware allocates 5ms host buffer instead of the standard
4ms which should be taken into account when setting the constraint on the
buffer size.
Fixes: 842bb8b62cc6 ("ASoC: SOF: ipc4-topology: Save the DMA maximum burst size for PCMs")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20251002135752.2430-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The firmware has changed the minimum host buffer size from 2 periods to
4 periods (1 period is 1ms) which was missed by the kernel side.
Adjust the SOF_IPC4_MIN_DMA_BUFFER_SIZE to 4 ms to align with firmware.
Link: https://github.com/thesofproject/sof/commit/f0a14a3f410735db18a79eb7a5f40dc49fdee7a7
Fixes: 594c1bb9ff73 ("ASoC: SOF: ipc4-topology: Do not parse the DMA_BUFFER_SIZE token")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20251002135752.2430-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Translate .../scsi/sd-parameters.rst into Chinese.
Add sd-parameters into .../scsi/index.rst.
Update the translation through commit d835971b2b89
("scsi: docs: convert sd-parameters.txt to ReST")
Signed-off-by: doubled <doubled@leap-io-kernel.com>
Signed-off-by: Alex Shi <alexs@kernel.org>
|
|
Translate .../scsi/link_power_management_policy.rst into Chinese.
Add link_power_management_policy into .../scsi/index.rst.
Update the translation through commit cbbc70a8cde7
("scsi: docs: convert link_power_management_policy.txt to ReST")
Signed-off-by: doubled <doubled@leap-io-kernel.com>
Signed-off-by: Alex Shi <alexs@kernel.org>
|
|
Translate .../scsi/scsi-parameters.rst into Chinese.
Add scsi-parameters into .../scsi/index.rst.
Update the translation through commit bdb39c9509e6
("Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi")
Signed-off-by: doubled <doubled@leap-io-kernel.com>
Signed-off-by: Alex Shi <alexs@kernel.org>
|
|
Translate .../scsi/scsi_eh.rst into Chinese.
Add scsi_eh into .../scsi/index.rst.
Update the translation through commit a9dcee18a220
("scsi: documentation: scsi_eh: updates for EH changes")
Signed-off-by: doubled <doubled@leap-io-kernel.com>
Signed-off-by: Alex Shi <alexs@kernel.org>
|
|
Translate .../scsi/scsi_mid_low_api.rst into Chinese.
Add scsi_mid_low_api into .../scsi/index.rst.
Update the translation through commit 73349697fd99
("scsi: docs: Clean up some style in scsi_mid_low_api")
Signed-off-by: doubled <doubled@leap-io-kernel.com>
Signed-off-by: Alex Shi <alexs@kernel.org>
|
|
Translate .../scsi/scsi.rst into Chinese.
Add scsi into .../scsi/index.rst.
Update the translation through commit c4e672ac8c49
("scsi: docs: introduction: Multiple cleanups")
Signed-off-by: doubled <doubled@leap-io-kernel.com>
Signed-off-by: Alex Shi <alexs@kernel.org>
|
|
Translate .../scsi/index.rst into Chinese and
update subsystem-apis.rst translation
Update the translation through commit 682b07d2ff54
("scsi: docs: Organize the SCSI documentation")
Signed-off-by: doubled <doubled@leap-io-kernel.com>
Signed-off-by: Alex Shi <alexs@kernel.org>
|
|
Update the translated rust/index.rst with new contents,
and add a reference label in rust/general-information.rst so
that index.rst can link to it properly.
Fixes in rust/index.rst:
- Fixed broken quick-start.rst cross-reference
Update the translation through commit d0b343605f1b
("kernel-docs: Add new section for Rust learning materials")
Signed-off-by: Ben Guo <benx.guo@gmail.com>
Reviewed-by: Yanteng Si <si.yanteng@linux.dev>
Signed-off-by: Alex Shi <alexs@kernel.org>
|
|
Translate .../security/SCTP.rst into Chinese.
Update the translation through commit da51bbcdbace
("Docs: typos/spelling")
Signed-off-by: Shuo Zhao <zhaoshuo@cqsoftware.com.cn>
Reviewed-by: Yanteng Si <si.yanteng@linux.dev>
Signed-off-by: Alex Shi <alexs@kernel.org>
|
|
libtracefs isn't used by perf but not having it installed causes build
warnings.
Given the library isn't used, there is no need for the configuration or
warnings so remove.
Signed-off-by: Ian Rogers <irogers@google.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20250929170600.59000-1-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
and versal-net
When the binding for the Cadence spi controller was written, a dedicated
compatible was added for the zynq device. Later when zynqmp and
versal-net, which also use this spi controller IP, were added they did
not receive soc-specific compatibles. Add them now, with a fallback to
the existing compatible for the r1p6 version of the IP so that there
will be no functional change. Retain the r1p6 in the string, to match
what was done for zynq.
Disallow the cdns,spi-r1p6 compatible in isolation to "encourage" people
to actually add soc-specific compatible strings in the future.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/20251001-basics-grafting-a1a214ef65ac@spud
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Assumption that chain DMA module starts the link DMA when 1ms of
data is available from host is not correct. Instead the firmware
chain DMA module fills the link DMA with initial buffer of zeroes
and the host and link DMAs are started at the same time.
This results in a small error in delay calculation. This can become a
more severe problem if host DMA has delays that exceed 1ms. This results
in negative delay to be calculated and bogus values reported to
applications. This can confuse some applications like
alsa_conformance_test.
Fix the issue by correctly calculating the firmware chain DMA
preamble size and initializing the start offset to this value.
Cc: stable@vger.kernel.org
Fixes: a1d203d390e0 ("ASoC: SOF: ipc4-pcm: Enable delay reporting for ChainDMA streams")
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20251002074719.2084-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
When the sampling rates going in (host) and out (dai) from the DSP
are different, the IPC4 delay reporting does not work correctly.
Add support for this case by scaling the all raw position values to
a common timebase before calculating real-time delay for the PCM.
Cc: stable@vger.kernel.org
Fixes: 0ea06680dfcb ("ASoC: SOF: ipc4-pcm: Correct the delay calculation")
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20251002074719.2084-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
