summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-01-20selftests/bpf: update verifier test for default trusted pointer semanticsMatt Bobrowski
Replace the verifier test for default trusted pointer semantics, which previously relied on BPF kfunc bpf_get_root_mem_cgroup(), with a new test utilizing dedicated BPF kfuncs defined within the bpf_testmod. bpf_get_root_mem_cgroup() was modified such that it again relies on KF_ACQUIRE semantics, therefore no longer making it a suitable candidate to test BPF verifier default trusted pointer semantics against. Link: https://lore.kernel.org/bpf/20260113083949.2502978-2-mattbobrowski@google.com Signed-off-by: Matt Bobrowski <mattbobrowski@google.com> Link: https://lore.kernel.org/r/20260120091630.3420452-1-mattbobrowski@google.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-20tools/net/ynl: Makefile's install target now installs ynltoolMichel Lind
This tool is built by default, but was not being installed by default when running `make install`. Fix this by calling ynltool's install target. Signed-off-by: Michel Lind <michel@michel-slm.name> Link: https://patch.msgid.link/aWqr9gUT4hWZwwcI@mbp-m3-fedora.vm Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-20Merge branch 'bpf-fix-memory-access-flags-in-helper-prototypes'Alexei Starovoitov
Zesen Liu says: ==================== bpf: Fix memory access flags in helper prototypes This series adds missing memory access flags (MEM_RDONLY or MEM_WRITE) to several bpf helper function prototypes that use ARG_PTR_TO_MEM but lack the correct flag. It also adds a new check in verifier to ensure the flag is specified. Missing memory access flags in helper prototypes can lead to critical correctness issues when the verifier tries to perform code optimization. After commit 37cce22dbd51 ("bpf: verifier: Refactor helper access type tracking"), the verifier relies on the memory access flags, rather than treating all arguments in helper functions as potentially modifying the pointed-to memory. Using ARG_PTR_TO_MEM alone without flags does not make sense because: - If the helper does not change the argument, missing MEM_RDONLY causes the verifier to incorrectly reject a read-only buffer. - If the helper does change the argument, missing MEM_WRITE causes the verifier to incorrectly assume the memory is unchanged, leading to errors in code optimization. We have already seen several reports regarding this: - commit ac44dcc788b9 ("bpf: Fix verifier assumptions of bpf_d_path's output buffer") adds MEM_WRITE to bpf_d_path; - commit 2eb7648558a7 ("bpf: Specify access type of bpf_sysctl_get_name args") adds MEM_WRITE to bpf_sysctl_get_name. This series looks through all prototypes in the kernel and completes the flags. It also adds check_mem_arg_rw_flag_ok() and wires it into check_func_proto() to statically restrict ARG_PTR_TO_MEM from appearing without memory access flags. Changelog ========= v3: - Rebased to bpf-next to address check_func_proto() signature changes, as suggested by Eduard Zingerman. v2: - Add missing MEM_RDONLY flags to protos with ARG_PTR_TO_FIXED_SIZE_MEM. ==================== Link: https://patch.msgid.link/20260120-helper_proto-v3-0-27b0180b4e77@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-20bpf: Require ARG_PTR_TO_MEM with memory flagZesen Liu
Add check to ensure that ARG_PTR_TO_MEM is used with either MEM_WRITE or MEM_RDONLY. Using ARG_PTR_TO_MEM alone without flags does not make sense because: - If the helper does not change the argument, missing MEM_RDONLY causes the verifier to incorrectly reject a read-only buffer. - If the helper does change the argument, missing MEM_WRITE causes the verifier to incorrectly assume the memory is unchanged, leading to errors in code optimization. Co-developed-by: Shuran Liu <electronlsr@gmail.com> Signed-off-by: Shuran Liu <electronlsr@gmail.com> Co-developed-by: Peili Gao <gplhust955@gmail.com> Signed-off-by: Peili Gao <gplhust955@gmail.com> Co-developed-by: Haoran Ni <haoran.ni.cs@gmail.com> Signed-off-by: Haoran Ni <haoran.ni.cs@gmail.com> Signed-off-by: Zesen Liu <ftyghome@gmail.com> Reviewed-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20260120-helper_proto-v3-2-27b0180b4e77@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-20bpf: Fix memory access flags in helper prototypesZesen Liu
After commit 37cce22dbd51 ("bpf: verifier: Refactor helper access type tracking"), the verifier started relying on the access type flags in helper function prototypes to perform memory access optimizations. Currently, several helper functions utilizing ARG_PTR_TO_MEM lack the corresponding MEM_RDONLY or MEM_WRITE flags. This omission causes the verifier to incorrectly assume that the buffer contents are unchanged across the helper call. Consequently, the verifier may optimize away subsequent reads based on this wrong assumption, leading to correctness issues. For bpf_get_stack_proto_raw_tp, the original MEM_RDONLY was incorrect since the helper writes to the buffer. Change it to ARG_PTR_TO_UNINIT_MEM which correctly indicates write access to potentially uninitialized memory. Similar issues were recently addressed for specific helpers in commit ac44dcc788b9 ("bpf: Fix verifier assumptions of bpf_d_path's output buffer") and commit 2eb7648558a7 ("bpf: Specify access type of bpf_sysctl_get_name args"). Fix these prototypes by adding the correct memory access flags. Fixes: 37cce22dbd51 ("bpf: verifier: Refactor helper access type tracking") Co-developed-by: Shuran Liu <electronlsr@gmail.com> Signed-off-by: Shuran Liu <electronlsr@gmail.com> Co-developed-by: Peili Gao <gplhust955@gmail.com> Signed-off-by: Peili Gao <gplhust955@gmail.com> Co-developed-by: Haoran Ni <haoran.ni.cs@gmail.com> Signed-off-by: Haoran Ni <haoran.ni.cs@gmail.com> Signed-off-by: Zesen Liu <ftyghome@gmail.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20260120-helper_proto-v3-1-27b0180b4e77@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-21riscv: dts: spacemit: Disable ETH PHY sleep mode for OrangePiChukun Pan
On the SpacemiT K1 platform, the MAC can't read statistics when the PHY clock stops. Disable Link Down Power Saving Mode for the YT8531C PHY on OrangePi R2S and RV2 boards to avoid reading statistics timeout logs. Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Reviewed-by: Yixun Lan <dlan@kernel.org> Link: https://lore.kernel.org/r/20260120100001.1285624-2-amadeus@jmu.edu.cn Signed-off-by: Yixun Lan <dlan@kernel.org>
2026-01-20Merge branch 'bpf-add-range-tracking-for-bpf_div-and-bpf_mod'Alexei Starovoitov
Yazhou Tang says: ==================== bpf: Add range tracking for BPF_DIV and BPF_MOD From: Yazhou Tang <tangyazhou518@outlook.com> Add range tracking (interval analysis) for BPF_DIV and BPF_MOD when divisor is constant. Please see commit log of 1/2 for more details. Changes v4 => v5: 1. Rename helper functions `__reset_reg(32|64)_and_tnum` to `reset_reg(32|64)_and_tnum`. (Alexei) 2. Replace plain C division with `div64_u64` and `div64_s64` for 64-bit operations, ensuring compatibility with 32-bit architectures. (Alexei & kernel test robot) 3. Fixup an indent typo in selftest file `verifier_div_mod_bounds.c`. v4: https://lore.kernel.org/bpf/20260116103246.2477635-1-tangyazhou@zju.edu.cn/ Changes v3 => v4: 1. Remove verbose helper functions for "division by zero" handling. (Alexei) 2. Put all "reset" logic in one place for clarity, and add 2 helper function `__reset_reg64_and_tnum` and `__reset_reg32_and_tnum` to reduce code duplication. (Alexei) 3. Update all multi-line comments to follow the standard kernel style. (Alexei) 4. Add new test cases to cover strictly positive and strictly negative divisor scenarios in SDIV and SMOD analysis. (Alexei) 5. Fixup a typo in SDIV analysis functions. v3: https://lore.kernel.org/bpf/20260113103552.3435695-1-tangyazhou@zju.edu.cn/ Changes v2 => v3: 1. Fixup a bug in `adjust_scalar_min_max_vals` function that lead to incorrect range results. (Syzbot) 2. Remove tnum analysis logic. (Alexei) 3. Only handle "constant divisor" case. (Alexei) 4. Add BPF_MOD range analysis logic. 5. Update selftests accordingly. 6. Add detailed code comments and improve commit messages. (Yonghong) v2: https://lore.kernel.org/bpf/20251223091120.2413435-1-tangyazhou@zju.edu.cn/ Changes v1 => v2: 1. Fixed 2 bugs in sdiv32 analysis logic and corrected the associated selftest cases. (AI reviewer) 2. Renamed `tnum_bottom` to `tnum_empty` for better clarity, and updated commit message to explain its role in signed BPF_DIV analysis. v1: https://lore.kernel.org/bpf/tencent_717092CD734D050CCD93401CA624BB3C8307@qq.com/ https://lore.kernel.org/bpf/tencent_7C98FAECA40C98489ACF4515CE346F031509@qq.com/ ==================== Link: https://patch.msgid.link/20260119085458.182221-1-tangyazhou@zju.edu.cn Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-20selftests/bpf: Add tests for BPF_DIV and BPF_MOD range trackingYazhou Tang
Now BPF_DIV has range tracking support via interval analysis. This patch adds selftests to cover various cases of BPF_DIV and BPF_MOD operations when the divisor is a constant, also covering both signed and unsigned variants. This patch includes several types of tests in 32-bit and 64-bit variants: 1. For UDIV - positive divisor - zero divisor 2. For SDIV - positive divisor, positive dividend - positive divisor, negative dividend - positive divisor, mixed sign dividend - negative divisor, positive dividend - negative divisor, negative dividend - negative divisor, mixed sign dividend - zero divisor - overflow (SIGNED_MIN/-1), normal dividend - overflow (SIGNED_MIN/-1), constant dividend 3. For UMOD - positive divisor - positive divisor, small dividend - zero divisor 4. For SMOD - positive divisor, positive dividend - positive divisor, negative dividend - positive divisor, mixed sign dividend - positive divisor, mixed sign dividend, small dividend - negative divisor, positive dividend - negative divisor, negative dividend - negative divisor, mixed sign dividend - negative divisor, mixed sign dividend, small dividend - zero divisor - overflow (SIGNED_MIN/-1), normal dividend - overflow (SIGNED_MIN/-1), constant dividend Specifically, these selftests are based on dead code elimination: If the BPF verifier can precisely analyze the result of BPF_DIV/BPF_MOD instruction, it can prune the path that leads to an error (here we use invalid memory access as the error case), allowing the program to pass verification. Co-developed-by: Shenghao Yuan <shenghaoyuan0928@163.com> Signed-off-by: Shenghao Yuan <shenghaoyuan0928@163.com> Co-developed-by: Tianci Cao <ziye@zju.edu.cn> Signed-off-by: Tianci Cao <ziye@zju.edu.cn> Signed-off-by: Yazhou Tang <tangyazhou518@outlook.com> Link: https://lore.kernel.org/r/20260119085458.182221-3-tangyazhou@zju.edu.cn Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-20bpf: Add range tracking for BPF_DIV and BPF_MODYazhou Tang
This patch implements range tracking (interval analysis) for BPF_DIV and BPF_MOD operations when the divisor is a constant, covering both signed and unsigned variants. While LLVM typically optimizes integer division and modulo by constants into multiplication and shift sequences, this optimization is less effective for the BPF target when dealing with 64-bit arithmetic. Currently, the verifier does not track bounds for scalar division or modulo, treating the result as "unbounded". This leads to false positive rejections for safe code patterns. For example, the following code (compiled with -O2): ```c int test(struct pt_regs *ctx) { char buffer[6] = {1}; __u64 x = bpf_ktime_get_ns(); __u64 res = x % sizeof(buffer); char value = buffer[res]; bpf_printk("res = %llu, val = %d", res, value); return 0; } ``` Generates a raw `BPF_MOD64` instruction: ```asm ; __u64 res = x % sizeof(buffer); 1: 97 00 00 00 06 00 00 00 r0 %= 0x6 ; char value = buffer[res]; 2: 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0x0 ll 4: 0f 01 00 00 00 00 00 00 r1 += r0 5: 91 14 00 00 00 00 00 00 r4 = *(s8 *)(r1 + 0x0) ``` Without this patch, the verifier fails with "math between map_value pointer and register with unbounded min value is not allowed" because it cannot deduce that `r0` is within [0, 5]. According to the BPF instruction set[1], the instruction's offset field (`insn->off`) is used to distinguish between signed (`off == 1`) and unsigned division (`off == 0`). Moreover, we also follow the BPF division and modulo runtime behavior (semantics) to handle special cases, such as division by zero and signed division overflow. - UDIV: dst = (src != 0) ? (dst / src) : 0 - SDIV: dst = (src == 0) ? 0 : ((src == -1 && dst == LLONG_MIN) ? LLONG_MIN : (dst / src)) - UMOD: dst = (src != 0) ? (dst % src) : dst - SMOD: dst = (src == 0) ? dst : ((src == -1 && dst == LLONG_MIN) ? 0: (dst s% src)) Here is the overview of the changes made in this patch (See the code comments for more details and examples): 1. For BPF_DIV: Firstly check whether the divisor is zero. If so, set the destination register to zero (matching runtime behavior). For non-zero constant divisors: goto `scalar(32)?_min_max_(u|s)div` functions. - General cases: compute the new range by dividing max_dividend and min_dividend by the constant divisor. - Overflow case (SIGNED_MIN / -1) in signed division: mark the result as unbounded if the dividend is not a single number. 2. For BPF_MOD: Firstly check whether the divisor is zero. If so, leave the destination register unchanged (matching runtime behavior). For non-zero constant divisors: goto `scalar(32)?_min_max_(u|s)mod` functions. - General case: For signed modulo, the result's sign matches the dividend's sign. And the result's absolute value is strictly bounded by `min(abs(dividend), abs(divisor) - 1)`. - Special care is taken when the divisor is SIGNED_MIN. By casting to unsigned before negation and subtracting 1, we avoid signed overflow and correctly calculate the maximum possible magnitude (`res_max_abs` in the code). - "Small dividend" case: If the dividend is already within the possible result range (e.g., [-2, 5] % 10), the operation is an identity function, and the destination register remains unchanged. 3. In `scalar(32)?_min_max_(u|s)(div|mod)` functions: After updating current range, reset other ranges and tnum to unbounded/unknown. e.g., in `scalar_min_max_sdiv`, signed 64-bit range is updated. Then reset unsigned 64-bit range and 32-bit range to unbounded, and tnum to unknown. Exception: in BPF_MOD's "small dividend" case, since the result remains unchanged, we do not reset other ranges/tnum. 4. Also updated existing selftests based on the expected BPF_DIV and BPF_MOD behavior. [1] https://www.kernel.org/doc/Documentation/bpf/standardization/instruction-set.rst Co-developed-by: Shenghao Yuan <shenghaoyuan0928@163.com> Signed-off-by: Shenghao Yuan <shenghaoyuan0928@163.com> Co-developed-by: Tianci Cao <ziye@zju.edu.cn> Signed-off-by: Tianci Cao <ziye@zju.edu.cn> Signed-off-by: Yazhou Tang <tangyazhou518@outlook.com> Tested-by: syzbot@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20260119085458.182221-2-tangyazhou@zju.edu.cn Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-20Merge branch 'bpf-kernel-functions-with-kf_implicit_args'Alexei Starovoitov
Ihor Solodrai says: ==================== bpf: Kernel functions with KF_IMPLICIT_ARGS This series implements a generic "implicit arguments" feature for BPF kernel functions. For context see prior work [1][2]. A mechanism is created for kfuncs to have arguments that are not visible to the BPF programs, and are provided to the kernel function implementation by the verifier. This mechanism is then used in the kfuncs that have a parameter with __prog annotation [3], which is the current way of passing struct bpf_prog_aux pointer to kfuncs. The function with implicit arguments is defined by KF_IMPLICIT_ARGS flag in BTF_IDS_FLAGS set. In this series, only a pointer to struct bpf_prog_aux can be implicit, although it is simple to extend this to more types. The verifier handles a kfunc with KF_IMPLICIT_ARGS by resolving it to a different (actual) BTF prototype early in verification (patch #3). A <kfunc>_impl function generated in BTF for a kfunc with implicit args does not have a "bpf_kfunc" decl tag, and a kernel address. The verifier will reject a program trying to call such an _impl kfunc. The usage of <kfunc>_impl functions in BPF is only allowed for kfuncs with an explicit kernel (or kmodule) declaration, that is in "legacy" cases. As of this series, there are no legacy kernel functions, as all __prog users are migrated to KF_IMPLICIT_ARGS. However the implementation allows for legacy cases support in principle. The series removes the following BPF kernel functions: - bpf_stream_vprintk_impl - bpf_task_work_schedule_resume_impl - bpf_task_work_schedule_signal_impl - bpf_wq_set_callback_impl This will break existing BPF programs calling these functions (the verifier will not load them) on new kernels. To mitigate, BPF users are advised to use the following pattern [4]: if (xxx_impl) xxx_impl(..., NULL); else xxx(...); Which can be wrapped in a macro. The series consists of the following patches: - patches #1 and #2 are non-functional refactoring in kernel/bpf - patch #3 defines KF_IMPLICIT_ARGS flag and teaches the verifier about it - patches #4-#5 implement btf2btf transformation in resolve_btfids - patch #6 adds selftests specific to KF_IMPLICIT_ARGS feature - patches #7-#11 migrate the current users of __prog argument to KF_IMPLICIT_ARGS - patch #12 removes __prog arg suffix support from the kernel - patch #13 updates the docs [1] https://lore.kernel.org/bpf/20251029190113.3323406-1-ihor.solodrai@linux.dev/ [2] https://lore.kernel.org/bpf/20250924211716.1287715-1-ihor.solodrai@linux.dev/ [3] https://docs.kernel.org/bpf/kfuncs.html#prog-annotation [4] https://lore.kernel.org/bpf/CAEf4BzbgPfRm9BX=TsZm-TsHFAHcwhPY4vTt=9OT-uhWqf8tqw@mail.gmail.com/ --- v2->v3: - resolve_btfids: Use dynamic reallocation for btf2btf_context arrays (Andrii) - resolve_btfids: Add missing free() for btf2btf_context arrays (AI) - Other nits in resolve_btfids (Andrii, Eduard) v2: https://lore.kernel.org/bpf/20260116201700.864797-1-ihor.solodrai@linux.dev/ v1->v2: - Replace the following kernel functions with KF_IMPLICIT_ARGS version: - bpf_stream_vprintk_impl -> bpf_stream_vprintk - bpf_task_work_schedule_resume_impl -> bpf_task_work_schedule_resume - bpf_task_work_schedule_signal_impl -> bpf_task_work_schedule_signal - bpf_wq_set_callback_impl -> bpf_wq_set_callback_impl - Remove __prog arg suffix support from the verifier - Rework btf2btf implementation in resolve_btfids - Do distill base and sort before BTF_ids patching - Collect kfuncs based on BTF decl tags, before BTF_ids are patched - resolve_btfids: use dynamic memory for intermediate data (Andrii) - verifier: reset .subreg_def for caller saved registers on kfunc call (Eduard) - selftests/hid: remove Makefile changes (Benjamin) - selftests/bpf: Add a patch (#11) migrating struct_ops_assoc test to KF_IMPLICIT_ARGS - Various nits across the series (Alexei, Andrii, Eduard) v1: https://lore.kernel.org/bpf/20260109184852.1089786-1-ihor.solodrai@linux.dev/ --- ==================== Link: https://patch.msgid.link/20260120222638.3976562-1-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-20bpf,docs: Document KF_IMPLICIT_ARGS flagIhor Solodrai
Add a section explaining KF_IMPLICIT_ARGS kfunc flag. Remove __prog arg annotation, as it is no longer supported. Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://lore.kernel.org/r/20260120223027.3981805-1-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-20bpf: Remove __prog kfunc arg annotationIhor Solodrai
Now that all the __prog suffix users in the kernel tree migrated to KF_IMPLICIT_ARGS, remove it from the verifier. See prior discussion for context [1]. [1] https://lore.kernel.org/bpf/CAEf4BzbgPfRm9BX=TsZm-TsHFAHcwhPY4vTt=9OT-uhWqf8tqw@mail.gmail.com/ Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://lore.kernel.org/r/20260120222638.3976562-13-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-20selftests/bpf: Migrate struct_ops_assoc test to KF_IMPLICIT_ARGSIhor Solodrai
A test kfunc named bpf_kfunc_multi_st_ops_test_1_impl() is a user of __prog suffix. Subsequent patch removes __prog support in favor of KF_IMPLICIT_ARGS, so migrate this kfunc to use implicit argument. Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://lore.kernel.org/r/20260120222638.3976562-12-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-20bpf: Migrate bpf_stream_vprintk() to KF_IMPLICIT_ARGSIhor Solodrai
Implement bpf_stream_vprintk with an implicit bpf_prog_aux argument, and remote bpf_stream_vprintk_impl from the kernel. Update the selftests to use the new API with implicit argument. bpf_stream_vprintk macro is changed to use the new bpf_stream_vprintk kfunc, and the extern definition of bpf_stream_vprintk_impl is replaced accordingly. Reviewed-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://lore.kernel.org/r/20260120222638.3976562-11-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-20bpf: Migrate bpf_task_work_schedule_* kfuncs to KF_IMPLICIT_ARGSIhor Solodrai
Implement bpf_task_work_schedule_* with an implicit bpf_prog_aux argument, and remove corresponding _impl funcs from the kernel. Update special kfunc checks in the verifier accordingly. Update the selftests to use the new API with implicit argument. Reviewed-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://lore.kernel.org/r/20260120222638.3976562-10-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-20HID: Use bpf_wq_set_callback kernel functionIhor Solodrai
Remove extern declaration of bpf_wq_set_callback_impl() from hid_bpf_helpers.h and replace bpf_wq_set_callback macro with a corresponding new declaration. Tested with: # append tools/testing/selftests/hid/config and build the kernel $ make -C tools/testing/selftests/hid # in built kernel $ ./tools/testing/selftests/hid/hid_bpf -t test_multiply_events_wq TAP version 13 1..1 # Starting 1 tests from 1 test cases. # RUN hid_bpf.test_multiply_events_wq ... [ 2.575520] hid-generic 0003:0001:0A36.0001: hidraw0: USB HID v0.00 Device [test-uhid-device-138] on 138 # OK hid_bpf.test_multiply_events_wq ok 1 hid_bpf.test_multiply_events_wq # PASSED: 1 / 1 tests passed. # Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0 PASS Acked-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://lore.kernel.org/r/20260120222638.3976562-9-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-20bpf: Migrate bpf_wq_set_callback_impl() to KF_IMPLICIT_ARGSIhor Solodrai
Implement bpf_wq_set_callback() with an implicit bpf_prog_aux argument, and remove bpf_wq_set_callback_impl(). Update special kfunc checks in the verifier accordingly. Reviewed-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://lore.kernel.org/r/20260120222638.3976562-8-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-20selftests/bpf: Add tests for KF_IMPLICIT_ARGSIhor Solodrai
Add trivial end-to-end tests to validate that KF_IMPLICIT_ARGS flag is properly handled by both resolve_btfids and the verifier. Declare kfuncs in bpf_testmod. Check that bpf_prog_aux pointer is set in the kfunc implementation. Verify that calls with implicit args and a legacy case all work. Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://lore.kernel.org/r/20260120222638.3976562-7-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-20resolve_btfids: Support for KF_IMPLICIT_ARGSIhor Solodrai
Implement BTF modifications in resolve_btfids to support BPF kernel functions with implicit arguments. For a kfunc marked with KF_IMPLICIT_ARGS flag, a new function prototype is added to BTF that does not have implicit arguments. The kfunc's prototype is then updated to a new one in BTF. This prototype is the intended interface for the BPF programs. A <func_name>_impl function is added to BTF to make the original kfunc prototype searchable for the BPF verifier. If a <func_name>_impl function already exists in BTF, its interpreted as a legacy case, and this step is skipped. Whether an argument is implicit is determined by its type: currently only `struct bpf_prog_aux *` is supported. As a result, the BTF associated with kfunc is changed from __bpf_kfunc bpf_foo(int arg1, struct bpf_prog_aux *aux); into bpf_foo_impl(int arg1, struct bpf_prog_aux *aux); __bpf_kfunc bpf_foo(int arg1); For more context see previous discussions and patches [1][2]. [1] https://lore.kernel.org/dwarves/ba1650aa-fafd-49a8-bea4-bdddee7c38c9@linux.dev/ [2] https://lore.kernel.org/bpf/20251029190113.3323406-1-ihor.solodrai@linux.dev/ Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://lore.kernel.org/r/20260120222638.3976562-6-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-20resolve_btfids: Introduce finalize_btf() stepIhor Solodrai
Since recently [1][2] resolve_btfids executes final adjustments to the kernel/module BTF before it's embedded into the target binary. To keep the implementation simple, a clear and stable "pipeline" of how BTF data flows through resolve_btfids would be helpful. Some BTF modifications may change the ids of the types, so it is important to maintain correct order of operations with respect to .BTF_ids resolution too. This patch refactors the BTF handling to establish the following sequence: - load target ELF sections - load .BTF_ids symbols - this will be a dependency of btf2btf transformations in subsequent patches - load BTF and its base as is - (*) btf2btf transformations will happen here - finalize_btf(), introduced in this patch - does distill base and sort BTF - resolve and patch .BTF_ids This approach helps to avoid fixups in .BTF_ids data in case the ids change at any point of BTF processing, because symbol resolution happens on the finalized, ready to dump, BTF data. This also gives flexibility in BTF transformations, because they will happen on BTF that is not distilled and/or sorted yet, allowing to freely add, remove and modify BTF types. [1] https://lore.kernel.org/bpf/20251219181321.1283664-1-ihor.solodrai@linux.dev/ [2] https://lore.kernel.org/bpf/20260109130003.3313716-1-dolinux.peng@gmail.com/ Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://lore.kernel.org/r/20260120222638.3976562-5-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-20bpf: Verifier support for KF_IMPLICIT_ARGSIhor Solodrai
A kernel function bpf_foo marked with KF_IMPLICIT_ARGS flag is expected to have two associated types in BTF: * `bpf_foo` with a function prototype that omits implicit arguments * `bpf_foo_impl` with a function prototype that matches the kernel declaration of `bpf_foo`, but doesn't have a ksym associated with its name In order to support kfuncs with implicit arguments, the verifier has to know how to resolve a call of `bpf_foo` to the correct BTF function prototype and address. To implement this, in add_kfunc_call() kfunc flags are checked for KF_IMPLICIT_ARGS. For such kfuncs a BTF func prototype is adjusted to the one found for `bpf_foo_impl` (func_name + "_impl" suffix, by convention) function in BTF. This effectively changes the signature of the `bpf_foo` kfunc in the context of verification: from one without implicit args to the one with full argument list. The values of implicit arguments by design are provided by the verifier, and so they can only be of particular types. In this patch the only allowed implicit arg type is a pointer to struct bpf_prog_aux. In order for the verifier to correctly set an implicit bpf_prog_aux arg value at runtime, is_kfunc_arg_prog() is extended to check for the arg type. At a point when prog arg is determined in check_kfunc_args() the kfunc with implicit args already has a prototype with full argument list, so the existing value patch mechanism just works. If a new kfunc with KF_IMPLICIT_ARG is declared for an existing kfunc that uses a __prog argument (a legacy case), the prototype substitution works in exactly the same way, assuming the kfunc follows the _impl naming convention. The difference is only in how _impl prototype is added to the BTF, which is not the verifier's concern. See a subsequent resolve_btfids patch for details. __prog suffix is still supported at this point, but will be removed in a subsequent patch, after current users are moved to KF_IMPLICIT_ARGS. Introduction of KF_IMPLICIT_ARGS revealed an issue with zero-extension tracking, because an explicit rX = 0 in place of the verifier-supplied argument is now absent if the arg is implicit (the BPF prog doesn't pass a dummy NULL anymore). To mitigate this, reset the subreg_def of all caller saved registers in check_kfunc_call() [1]. [1] https://lore.kernel.org/bpf/b4a760ef828d40dac7ea6074d39452bb0dc82caa.camel@gmail.com/ Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://lore.kernel.org/r/20260120222638.3976562-4-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-20bpf: Introduce struct bpf_kfunc_metaIhor Solodrai
There is code duplication between add_kfunc_call() and fetch_kfunc_meta() collecting information about a kfunc from BTF. Introduce struct bpf_kfunc_meta to hold common kfunc BTF data and implement fetch_kfunc_meta() to fill it in, instead of struct bpf_kfunc_call_arg_meta directly. Then use these in add_kfunc_call() and (new) fetch_kfunc_arg_meta() functions, and fixup previous usages of fetch_kfunc_meta() to fetch_kfunc_arg_meta(). Besides the code dedup, this change enables add_kfunc_call() to access kfunc->flags. Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://lore.kernel.org/r/20260120222638.3976562-3-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-20bpf: Refactor btf_kfunc_id_set_containsIhor Solodrai
btf_kfunc_id_set_contains() is called by fetch_kfunc_meta() in the BPF verifier to get the kfunc flags stored in the .BTF_ids ELF section. If it returns NULL instead of a valid pointer, it's interpreted as an illegal kfunc usage failing the verification. There are two potential reasons for btf_kfunc_id_set_contains() to return NULL: 1. Provided kfunc BTF id is not present in relevant kfunc id sets. 2. The kfunc is not allowed, as determined by the program type specific filter [1]. The filter functions accept a pointer to `struct bpf_prog`, so they might implicitly depend on earlier stages of verification, when bpf_prog members are set. For example, bpf_qdisc_kfunc_filter() in linux/net/sched/bpf_qdisc.c inspects prog->aux->st_ops [2], which is initialized in: check_attach_btf_id() -> check_struct_ops_btf_id() So far this hasn't been an issue, because fetch_kfunc_meta() is the only caller of btf_kfunc_id_set_contains(). However in subsequent patches of this series it is necessary to inspect kfunc flags earlier in BPF verifier, in the add_kfunc_call(). To resolve this, refactor btf_kfunc_id_set_contains() into two interface functions: * btf_kfunc_flags() that simply returns pointer to kfunc_flags without applying the filters * btf_kfunc_is_allowed() that both checks for kfunc_flags existence (which is a requirement for a kfunc to be allowed) and applies the prog filters See [3] for the previous version of this patch. [1] https://lore.kernel.org/all/20230519225157.760788-7-aditi.ghag@isovalent.com/ [2] https://lore.kernel.org/all/20250409214606.2000194-4-ameryhung@gmail.com/ [3] https://lore.kernel.org/bpf/20251029190113.3323406-3-ihor.solodrai@linux.dev/ Reviewed-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://lore.kernel.org/r/20260120222638.3976562-2-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-21drm/msm/dp: Avoid division by zero in msm_dp_ctrl_config_msa()Nathan Chancellor
An (admittedly problematic) optimization change in LLVM 20 [1] turns known division by zero into the equivalent of __builtin_unreachable(), which invokes undefined behavior if it is encountered in a control flow graph, destroying code generation. When compile testing for x86_64, objtool flags an instance of this optimization triggering in msm_dp_ctrl_config_msa(), inlined into msm_dp_ctrl_on_stream(): drivers/gpu/drm/msm/msm.o: warning: objtool: msm_dp_ctrl_on_stream(): unexpected end of section .text.msm_dp_ctrl_on_stream The zero division happens if the else branch in the first if statement in msm_dp_ctrl_config_msa() is taken because pixel_div is initialized to zero and it is not possible for LLVM to eliminate the else branch since rate is still not known after inlining into msm_dp_ctrl_on_stream(). Transform the if statements into a switch statement with a default case with the existing error print and an early return to avoid the invalid division. Add a comment to note this helps the compiler, even though the case is known to be unreachable. With this, pixel_dev's default zero initialization can be dropped, as it is dead with this change. Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Link: https://github.com/llvm/llvm-project/commit/37932643abab699e8bb1def08b7eb4eae7ff1448 [1] Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202601081959.9UVJEOfP-lkp@intel.com/ Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/698355/ Link: https://lore.kernel.org/r/20260113-drm-msm-dp_ctrl-avoid-zero-div-v2-1-f1aa67bf6e8e@kernel.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-21drm/msm/dpu: try reserving the DSPP-less LM firstDmitry Baryshkov
On most of the platforms only some mixers have connected DSPP blocks. If DSPP is not required for the CRTC, try looking for the LM with no DSSP block, leaving DSPP-enabled LMs to CRTCs which actually require those. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/698773/ Link: https://lore.kernel.org/r/20260115-dpu-fix-dspp-v1-2-b73152c147b3@oss.qualcomm.com
2026-01-21drm/msm/dpu: correct error messages in RMDmitry Baryshkov
Some of error messages in RM reference block index, while other print the enum value (which is shifted by 1), not to mention that some of the messages are misleading. Reformat the messages, making them more clear and also always printing the hardware block name. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/698774/ Link: https://lore.kernel.org/r/20260115-dpu-fix-dspp-v1-1-b73152c147b3@oss.qualcomm.com
2026-01-21drm/msm/dpu: Add support for Kaanapali DPUYuanjie Yang
Add support for Display Processing Unit (DPU) version 13.0 on the Kaanapali platform. This version introduces changes to the SSPP sub-block structure. Add common block and rectangle blocks to accommodate these structural modifications for compatibility. Co-developed-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Yuanjie Yang <yuanjie.yang@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/698716/ Link: https://lore.kernel.org/r/20260115092749.533-13-yuanjie.yang@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-21drm/msm/dpu: Add Kaanapali WB supportYuanjie Yang
Add support for Kaanapali WB, which introduce register relocations, use the updated registeri definition to ensure compatibility. Co-developed-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Yuanjie Yang <yuanjie.yang@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/698715/ Link: https://lore.kernel.org/r/20260115092749.533-12-yuanjie.yang@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-21drm/msm/dpu: Add Kaanapali SSPP sub-block supportYuanjie Yang
Add support for Kaanapali platform SSPP sub-blocks, which introduce structural changes including register additions, removals, and relocations. Add the new common and rectangle blocks, and update register definitions and handling to ensure compatibility with DPU v13.0. Co-developed-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Signed-off-by: Yuanjie Yang <yuanjie.yang@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/698712/ Link: https://lore.kernel.org/r/20260115092749.533-11-yuanjie.yang@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-20nfc: MAINTAINERS: Orphan the NFC and look for new maintainersKrzysztof Kozlowski
NFC stack in Linux is in poor shape, with several bugs being discovered last years via fuzzing, not much new development happening and limited review and testing. It requires some more effort than drive-by reviews I have been offering last one or two years. I don't have much time nor business interests to keep looking at NFC, so let's drop me from the maintainers to clearly indicate that more hands are needed. Acked-by: Mark Greer <mgreer@animalcreek.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260118094822.10126-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-21drm/msm/dpu: Refactor SSPP to compatible DPU 13.0.0Yuanjie Yang
DPU version 13.0.0 introduces structural changes including register additions, removals, and relocations. Refactor SSPP-related code to be compatible with DPU 13.0.0 modifications. Co-developed-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Yuanjie Yang <yuanjie.yang@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/698710/ Link: https://lore.kernel.org/r/20260115092749.533-10-yuanjie.yang@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-21drm/msm/dpu: Add interrupt registers for DPU 13.0.0Yuanjie Yang
DPU version 13.0.0 introduces changes to the interrupt register layout. Update the driver to support these modifications for proper interrupt handling. Co-developed-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Yuanjie Yang <yuanjie.yang@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/698708/ Link: https://lore.kernel.org/r/20260115092749.533-9-yuanjie.yang@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-21drm/msm/dsi: Add support for KaanapaliYuanjie Yang
Add DSI Controller version 2.10.0 support for DSI on Qualcomm Kaanapali SoC. Co-developed-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Yuanjie Yang <yuanjie.yang@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/698707/ Link: https://lore.kernel.org/r/20260115092749.533-8-yuanjie.yang@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-21drm/msm/dsi/phy: Add support for KaanapaliYuanjie Yang
Add DSI PHY support for the Kaanapali platform, Kaanapali introduce addition of DSI2/DSI2_phy compared to SM8650. However, based on the HPG diagram, only DSI0_phy and DSI1_phy works. Co-developed-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Yuanjie Yang <yuanjie.yang@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/698705/ Link: https://lore.kernel.org/r/20260115092749.533-7-yuanjie.yang@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-21drm/msm/mdss: Add support for KaanapaliYuanjie Yang
Add mdss support for the Qualcomm Kaanapali platform. Co-developed-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Yuanjie Yang <yuanjie.yang@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/698703/ Link: https://lore.kernel.org/r/20260115092749.533-6-yuanjie.yang@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-21dt-bindings: display/msm: qcom, kaanapali-mdss: Add KaanapaliYuanjie Yang
Kaanapali introduces DPU 13.0.0 and DSI 2.10. Compared to SM8750, Kaanapali has significant register changes, making it incompatible with SM8750. So add MDSS/MDP display subsystem for Qualcomm Kaanapali. Co-developed-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Yuanjie Yang <yuanjie.yang@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/698700/ Link: https://lore.kernel.org/r/20260115092749.533-5-yuanjie.yang@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-21dt-bindings: display/msm: dsi-controller-main: Add KaanapaliYuanjie Yang
The DSI registers on the Kaanapali platform differ from those on SM8750. So add DSI for Kaanapali to compatible these changes. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Yuanjie Yang <yuanjie.yang@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/698698/ Link: https://lore.kernel.org/r/20260115092749.533-4-yuanjie.yang@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-21dt-bindings: display/msm: dsi-phy-7nm: Add Kaanapali DSI PHYYuanjie Yang
The DSI PHY registers on the Kaanapali platform differ from those on SM8750. So add DSI PHY for Kaanapali to compatible these changes. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Yuanjie Yang <yuanjie.yang@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/698696/ Link: https://lore.kernel.org/r/20260115092749.533-3-yuanjie.yang@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-21dt-bindings: display/msm: qcom, kaanapali-dpu: Add KaanapaliYuanjie Yang
Add DPU version 13.0 for Qualcomm Kaanapali Soc. The Kaanapali DPU and SM8750 have significant differences, including additions and removals of registers, as well as changes in register addresses. Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Yuanjie Yang <yuanjie.yang@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/698694/ Link: https://lore.kernel.org/r/20260115092749.533-2-yuanjie.yang@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-21drm/msm/dpu: fix SSPP_UBWC_STATIC_CTRL programming on UBWC 5.x+Dmitry Baryshkov
Code in dpu_hw_sspp_setup_format() doesn't handle UBWC versions bigger than 4.0. Replace switch-case with if-else checks, making sure that the register is initialized on UBWC 5.x (and later) hosts. Fixes: c2577fc1740d ("drm/msm/dpu: Add support for SM8750") Tested-by: Val Packett <val@packett.cool> # x1e80100-dell-latitude-7455 Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/699280/ Link: https://lore.kernel.org/r/20260119-msm-ubwc-fixes-v4-4-0987acc0427f@oss.qualcomm.com
2026-01-21drm/msm/dpu: program correct register for UBWC config on DPU 8.x+Dmitry Baryshkov
Since DPU 8.0 there is a separate register for the second rectangle, which needs to be programmed with the UBWC config if multirect is being used. Write pipe's UBWC configuration to the correct register. Fixes: 100d7ef6995d ("drm/msm/dpu: add support for SM8450") Tested-by: Val Packett <val@packett.cool> # x1e80100-dell-latitude-7455 Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/699277/ Link: https://lore.kernel.org/r/20260119-msm-ubwc-fixes-v4-3-0987acc0427f@oss.qualcomm.com
2026-01-21drm/msm/dpu: offset HBB values written to DPU by -13Dmitry Baryshkov
As in all other places, the Highest Bank Bit value should be programmed into the hardware with the offset of -13. Correct the value written into the register to prevent unpredictable results. Fixes: 227d4ce0b09e ("drm/msm: Offset MDSS HBB value by 13") Tested-by: Val Packett <val@packett.cool> # x1e80100-dell-latitude-7455 Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/699276/ Link: https://lore.kernel.org/r/20260119-msm-ubwc-fixes-v4-2-0987acc0427f@oss.qualcomm.com
2026-01-21drm/msm/mdss: correct HBB programmed on UBWC 5.x and 6.x devicesDmitry Baryshkov
As in the previous generations, on UBWC 5.x and 6.x devices the Highest Bank Bit value should be programmed into the hardware with the offset of -13. Correct the value written into the register to prevent unpredictable results. Fixes: 227d4ce0b09e ("drm/msm: Offset MDSS HBB value by 13") Tested-by: Val Packett <val@packett.cool> # x1e80100-dell-latitude-7455 Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/699274/ Link: https://lore.kernel.org/r/20260119-msm-ubwc-fixes-v4-1-0987acc0427f@oss.qualcomm.com
2026-01-20net: phy: intel-xway: fix OF node refcount leakageDaniel Golle
Automated review spotted am OF node reference count leakage when checking if the 'leds' child node exists. Call of_put_node() to correctly maintain the refcount. Link: https://netdev-ai.bots.linux.dev/ai-review.html?id=20f173ba-0c64-422b-a663-fea4b4ad01d0 Fixes: 1758af47b98c1 ("net: phy: intel-xway: add support for PHY LEDs") Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/e3275e1c1cdca7e6426bb9c11f33bd84b8d900c8.1768783208.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-20perf trace: Deal with compiler const checksArnaldo Carvalho de Melo
The strchr() function these days return const/non-const based on the arg it receives, and sometimes we need to use casts when we're dealing with variables that are used in code that needs to safely change the returned value and sometimes not (as it points to really const areas). Tweak one such case. Reviewed-by: Ian Rogers <irogers@google.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-01-20perf tests sw-clock: Mark the volatile tmp variable as __maybe_unusedArnaldo Carvalho de Melo
As it is just used to waste some cycles, not being used as all, to silence some compilers. Noticed with gcc version 16.0.1 20260115 on fedora 44: tests/sw-clock.c: In function '__test__sw_clock_freq': tests/sw-clock.c:31:22: error: variable 'tmp' set but not used [-Werror=unused-but-set-variable=] 31 | volatile int tmp = 0; | ^~~ Reviewed-by: Ian Rogers <irogers@google.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-01-20Merge branch 'mauro' into docs-mwJonathan Corbet
A combination of Mauro's -Werror work and my long-belated kernel-doc move.
2026-01-20jobserver: Split up the big try: blockJonathan Corbet
The parsing of jobserver options is done in a massive try: block that hides problems and (perhaps) bugs. Split up that block and make the logic explicit by moving the initial parsing of MAKEFLAGS out of that block. Add warnings in the places things can go wrong. Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2026-01-20Merge tag 'devicetree-fixes-for-6.19-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux Pull devicetree fixes from Rob Herring: - Fix a refcount leak in of_alias_scan() - Support descending into child nodes when populating nodes in /firmware * tag 'devicetree-fixes-for-6.19-3' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: of: fix reference count leak in of_alias_scan() of: platform: Use default match table for /firmware
2026-01-20docs: add a scripts/kernel-doc symbolic linkJonathan Corbet
Some folks evidently have muscle memory expecting kernel-doc to be under scripts/. Now that we have moved it to tools/docs, leave behind a symbolic link to reduce the global profanity count. Signed-off-by: Jonathan Corbet <corbet@lwn.net>
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-12 06:35:34 +0000