summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-04-27arm64: dts: qcom: Add the Nothing Phone (3a)Alexander Koskovich
Add a devicetree for the Nothing Phone (3a) smartphone, which is based on the Milos/SM7635 SoC. Supported functionality as of this initial submission: * Camera flash/torch LED * Debug UART * Glyph LEDs (AW20036) * PMIC-GLINK (Charger, Fuel gauge, USB-C mode switching) * Assistant Key, Power Button, Volume Keys * Regulators (PM7550, PM8550VS, PMR735B) * Remoteprocs (ADSP, CDSP, MPSS, WPSS) * USB (USB2 + FSA4480) Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Alexander Koskovich <akoskovich@pm.me> Link: https://lore.kernel.org/r/20260323-asteroids-v2-3-1a35fa9e178a@pm.me Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-27dt-bindings: arm: qcom: Add the Nothing Phone (3a)Alexander Koskovich
Document the Milos-based Nothing Phone (3a) smartphone. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Alexander Koskovich <akoskovich@pm.me> Link: https://lore.kernel.org/r/20260323-asteroids-v2-2-1a35fa9e178a@pm.me Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-27arm64: dts: qcom: milos: Reduce rmtfs_mem size to 2.5MiBAlexander Koskovich
The rmtfs_mem region is currently sized at 6MiB but the default for milos downstream is 2.5MiB. This causes remoteproc crashes on devices that expect the smaller size: modem_ac.c:281:Access Control Error: Could not protect the region specified:Start:e1f00000 End:e2180000, PID:1 Reduce the default to 2.5MiB to match the QCOM downstream config, and override the size for FP6. Fixes: d9d59d105f98 ("arm64: dts: qcom: Add initial Milos dtsi") Reviewed-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Alexander Koskovich <akoskovich@pm.me> Link: https://lore.kernel.org/r/20260323-asteroids-v2-1-1a35fa9e178a@pm.me Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-27arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllersAbel Vesa
According to internal documentation, the corners specific for each rate from the DP link clock are: - LOWSVS_D1 -> 19.2 MHz - LOWSVS -> 270 MHz - SVS -> 540 MHz (594 MHz in case of DP3) - SVS_L1 -> 594 MHz - NOM -> 810 MHz - NOM_L1 -> 810 MHz - TURBO -> 810 MHz So fix all tables for each of the four controllers according to the documentation, but since DP0 through DP2 have the same entries in their tables, lets drop the DP1 and DP2 and have all of them share the DP0 table instead. However keep a separate table for the DP3 as it is different for the SVS, compared to the rest of the controllers. The 19.2 MHz @ LOWSVS_D1 isn't needed as it's not an actual working frequency and the controller will never select it. So remove it. Cc: stable@vger.kernel.org # v6.9+ Fixes: 1940c25eaa63 ("arm64: dts: qcom: x1e80100: Add display nodes") Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260323-hamoa-fix-dp3-opp-table-v3-1-a823776bd1b0@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-27arm64: dts: qcom: sm6125-xiaomi-laurel-sprout: Enable MDSS and add panelYedaya Katsman
Enable the MDSS nodes and add supplies and bindings for the Samsung S6E8FCO DSI controller for the M1906F9 panel. The ldo and iovcc gpio pins boot up with a current of 16 mA, but they work fine with 2mA, so I used that. mdss_dsi0_phy is powered by VDD_MX, see power-domains in sm6125.dtsi Co-developed-by: Kamil Gołda <kamil.golda@protonmail.com> Signed-off-by: Kamil Gołda <kamil.golda@protonmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Yedaya Katsman <yedaya.ka@gmail.com> Link: https://lore.kernel.org/r/20260314-panel-patches-v4-3-1ecbb2c0c3c8@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-27riscv: dts: microchip: fix icicle i2c pinctrl configurationConor Dooley
Unfortunately, an erratum with engineering sample that I was not aware of was exposed by adding pinctrl configuration to the icicle kit. When routed to MSS IOs, i2c signals are never anything other than tied low. Being an FPGA, a Libero workaround for this problem was created, that involves routing i2c signals to the FPGA fabric when the MSS IO option is selected in the configurator and then back to the intended pin using the debug "fabric test" capability. This is invisible to user facing information in the tooling and not mentioned in reference designs documentation. It manifests solely in the .xml output from the MSS configuration that the HSS firmware uses to configure the device, which Linux now overwrites using the pinctrl information. As a result, I never noticed this. My original submission had the engineering sample configuration, but I modified it on application after I was told it didn't work, not realising that the report came from a colleague with a production device, where the erratum was fixed and the workaround not automatically implemented by Libero when creating a design. Move this part of the pinctrl configuration out of the shared portion of the icicle device trees, into the portions that are specific to engineering sample and production devices so that the different settings for i2c pins can be dealt with. Although the reference design only has this workaround in place for i2c1, as i2c0 is genuinely fabric routed, move it too since the erratum affects both controllers. Link: https://ww1.microchip.com/downloads/aemDocuments/documents/FPGA/ProductDocuments/Errata/polarfiresoc/microsemi_polarfire_soc_fpga_egineering_samples_errata_er0219_v1.pdf [3.3] Fixes: 123f4276b521a ("riscv: dts: microchip: add pinctrl nodes for mpfs/icicle kit") Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2026-04-27riscv: dts: starfive: jh7110: Drop CAMSS nodeJai Luthra
The starfive-camss driver and bindings were dropped, as they were no longer being worked upon for destaging. Drop the relevant node as well to avoid the following build warning: "failed to match any schema with compatible: ['starfive,jh7110-camss']" Reported-by: Conor Dooley <conor@kernel.org> Closes: https://lore.kernel.org/all/20260420-very-cartel-645595ffd1c7@spud/ Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com> Reviewed-by: Changhuang Liang <changhuang.liang@starfivetech.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2026-04-27x86/bug: Put HAVE_ARCH_BUG_FORMAT_ARGS WARN definitions inside __ASSEMBLER__Sean Christopherson
Extend the !assembly #ifdef guarding x86's custom WARN helpers to cover the WARN macros themselves, as they aren't assembly friendly. This helps make it clear that things like __WARN_validate_printf() don't need a dummy definition for assembly code. No functional change intended. Suggested-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20260423145419.459988-3-seanjc@google.com
2026-04-27x86/bug: Add printf() validation to HAVE_ARCH_BUG_FORMAT_ARGS WARNsSean Christopherson
Add explicit printf() validation for x86-64's newfangled WARN implementation, as most (all?) compilers fail to detect basic formatting issues without the annotation. E.g. even goofs like printing a u64 as a string aren't detected: WARN_ONCE(1, "Bad message, %s", vcpu->arch.last_guest_tsc); 32-bit x86 doesn't support HAVE_ARCH_BUG_FORMAT_ARGS and uses generic implementations that provide printf() validation. This means there's now a big blind spot is code that is strictly x86-64. Inconveniently, new features are also frequently x86-64-only. Fix the blind 64-bit blind spot. [ dhansen: changelog tweaks to flesh out the 64-bit-only details ] Fixes: 5b472b6e5bd9 ("x86_64/bug: Implement __WARN_printf()") Fixes: 11bb4944f014 ("x86/bug: Implement WARN_ONCE()") Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://lore.kernel.org/all/adc1IrD8uqWdaOKv@yzhao56-desk.sh.intel.com Link: https://patch.msgid.link/20260423145419.459988-2-seanjc@google.com
2026-04-27drm/tyr: Add DOORBELL_BLOCK registersDeborah Brouwer
DOORBELL_BLOCK_n[0-63] is an array of GPU control register pages. Each block is memory-mappable and contains a single DOORBELL register used to trigger actions in the GPU. Add definitions for the DOORBELL_BLOCK registers using the register! macro so they can be used by future Tyr interfaces. Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260409-b4-tyr-use-register-macro-v5-v5-6-8abfff8a0204@collabora.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-04-27drm/tyr: Remove custom register structDeborah Brouwer
Now that Tyr uses the register! macro, it no longer needs to define a custom register struct or read/write functions, so delete them. Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Co-developed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260409-b4-tyr-use-register-macro-v5-v5-5-8abfff8a0204@collabora.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-04-27drm/tyr: Use register! macro for MMU_CONTROLDeborah Brouwer
Define the MMU_CONTROL register block with the kernel's register! macro and replace the existing hand-written MMU register definitions with typed register and field accessors. This adds typed definitions for the MMU IRQ registers and the per-address space MMU_AS_CONTROL registers, including TRANSTAB, MEMATTR, LOCKADDR, COMMAND, FAULTSTATUS, STATUS, and TRANSCFG. It also introduces typed enums for MMU commands, fault types, access types, address space modes, memory attributes, and related MMU configuration fields. For logical 64-bit MMU registers that are exposed as split 32-bit MMIO registers, define both the typed 64-bit view and explicit low/high 32-bit registers so the register layout remains documented without relying on native 64-bit MMIO accesses. This reduces open-coded bit manipulation, keeps MMU register layout knowledge in one place, and makes the definitions easier to read and maintain. Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Co-developed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260409-b4-tyr-use-register-macro-v5-v5-4-8abfff8a0204@collabora.com [aliceryhl: reformat long comment] Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-04-27drm/tyr: Use register! macro for JOB_CONTROLDeborah Brouwer
Define the JOB_CONTROL register block with the kernel's register! macro and replace the existing hand-written JOB IRQ register definitions with typed register and field accessors. This adds typed definitions for the raw status, clear, mask, and status registers, including the per-CSG interrupt bits and the global interface interrupt bit. This reduces open-coded bit manipulation, keeps the JOB_CONTROL register layout in one place, and makes the definitions easier to read and maintain. Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Co-developed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260409-b4-tyr-use-register-macro-v5-v5-3-8abfff8a0204@collabora.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-04-27drm/tyr: Print GPU_ID without filteringDeborah Brouwer
Currently, Tyr prints just the upper 16 bits of the GPU_ID in the hex id field, namely ARCH_MAJOR, ARCH_MINOR, ARCH_REV, and PRODUCT_MAJOR. The VERSION_* fields are already printed separately as "major", "minor", and "status". Print the full 32-bit GPU_ID register instead of shifting it, so the hex id reflects the complete register contents. Before this change: mali-g610 id 0xa867 major 0x0 minor 0x0 status 0x5 After this change: mali-g610 GPU_ID 0xa8670005 major 0x0 minor 0x0 status 0x5 Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260409-b4-tyr-use-register-macro-v5-v5-2-8abfff8a0204@collabora.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-04-27drm/tyr: Use register! macro for GPU_CONTROLDaniel Almeida
Define the GPU_CONTROL register block with the kernel's register! macro and switch the current GPU control paths over to the new typed register definitions. This replaces manual register constants, bit masks, shifts, and the hand-written GpuId parsing code with typed register and field accessors. It also adds helpers for combining split 64-bit registers and uses the new definitions in reset, L2 power-on, and GPU info readout/logging paths. This reduces open-coded bit manipulation making the code easier to read and maintain. Acked-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Co-developed-by: Deborah Brouwer <deborah.brouwer@collabora.com> Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260409-b4-tyr-use-register-macro-v5-v5-1-8abfff8a0204@collabora.com [aliceryhl: reformat long comment] Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-04-27gpu: nova-core: simplify and_then with condition to filterEliot Courtney
This code is more simply expressed using Option::filter instead of the and_then with conditional. This fixes the following warning with latest nightly Rust clippy build: warning: manual implementation of `Option::filter` --> drivers/gpu/nova-core/firmware.rs:391:14 | 391 | .and_then(|hdr| { | ______________^ 392 | | if hdr.bin_magic == BIN_MAGIC { 393 | | Some(hdr) 394 | | } else { ... | 397 | | }) | |______________^ help: try: `filter(|hdr| hdr.bin_magic == BIN_MAGIC)` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#manual_filter = note: `-D clippy::manual-filter` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::manual_filter)]` Cc: stable@vger.kernel.org Fixes: d6cb7319e64e ("gpu: nova-core: firmware: add support for common firmware header") Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260423-fix-filter-v1-1-b3b197c65daf@nvidia.com [aliceryhl: add Fixes: tag and quote the warning it fixes] Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-04-27dt-bindings: net: bluetooth: qualcomm: Fix WCN6855 regulator namesKonrad Dybcio
Commit 5f4f954bba12 ("dt-bindings: bluetooth: bring the HW description closer to reality for wcn6855") changed the vddrfa1p7-supply to 1p8 for whatever reason. The schematics footprint for this chip definitely says 7 on the input leg and the driver still expects 1p7. Bring it back. Fixes: 5f4f954bba12 ("dt-bindings: bluetooth: bring the HW description closer to reality for wcn6855") Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260225-topic-wcn6855_pmu_dtbdings-v3-1-576ec5c4e631@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-27selftests/nolibc: test large file supportThomas Weißschuh
Make sure nolibc correctly handles large files. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260418-nolibc-largefile-v1-7-b91f0775bac3@weissschuh.net
2026-04-27tools/nolibc: open files with O_LARGEFILEThomas Weißschuh
nolibc can natively handle large files. Tell this to the kernel by always using O_LARGEFILE when opening files. This is also how other libcs do it. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260418-nolibc-largefile-v1-6-b91f0775bac3@weissschuh.net
2026-04-27tools/nolibc: handle 64-bit system call arguments on MIPS N32Thomas Weißschuh
The N32 system call ABI expects 64-bit values directly in registers. This does not work on nolibc currently, as a 'long' is only 32 bits wide. Switch the system call wrappers to use 'long long' instead which can handle 64-bit values on N32. As on N64 'long' and 'long long' are the same, this does not change the behavior there. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260418-nolibc-largefile-v1-5-b91f0775bac3@weissschuh.net
2026-04-27tools/nolibc: handle 64-bit system call arguments on x32Thomas Weißschuh
The x32 system call ABI expects 64-bit values directly in registers. This does not work on nolibc currently, as a 'long' is only 32 bits wide. Switch the system call wrappers to use 'long long' instead which can handle 64-bit values on x32. As on x86_64 'long' and 'long long' are the same, this does not change the behavior there. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260418-nolibc-largefile-v1-4-b91f0775bac3@weissschuh.net
2026-04-27tools/nolibc: cast pointers returned from system calls through integersThomas Weißschuh
Currently all system call wrappers return 'long' integers which can be directly cast to 'void *' if the returned value is actually a pointer. An upcoming change will change the system call wrappers to sometimes return 'long long' which can not be cast to a pointer directly. Add explicit cast through 'long' to prepare for this. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260418-nolibc-largefile-v1-3-b91f0775bac3@weissschuh.net
2026-04-27tools/nolibc: add __nolibc_arg_to_reg()Thomas Weißschuh
In the architecture specific system call glue, all arguments are currently casted to 'long' to fit into registers. This works for pointers as 'long' has the same size as pointers. However the system call registers for X32 and MIPS N32 need to be 'long long' to work correctly for 64-bit values expected by the system call ABI. Casting a pointer to a 'long long' will produce a compiler warning while casting 64-bit integers to 'long' will truncate those. Add a helper which can be used to correctly cast both pointers and integers into 'long long' registers. Cast the pointers through 'unsigned' to avoid any sign extensions. Both builtins have been available since at least GCC 3 and clang 3. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260418-nolibc-largefile-v1-2-b91f0775bac3@weissschuh.net
2026-04-27docs: cgroup: fix typo 'protetion' -> 'protection'Petr Vaněk
Fix a small typo in the description of the memory_hugetlb_accounting mount option. Signed-off-by: Petr Vaněk <arkamar@atlas.cz> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-04-27tools/nolibc: also handle _llseek system callThomas Weißschuh
On some architectures the llseek system call contains a leading underscore. Treat it the same way as llseek and prefer it over the plain lseek system call as is necessary for 64-bit offset handling. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260418-nolibc-largefile-v1-1-b91f0775bac3@weissschuh.net
2026-04-27tools/nolibc: add creat()Thomas Weißschuh
creat() is a simple wrapper around open(). Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260419-nolibc-open-mode-v1-2-8dc5a960daa7@weissschuh.net
2026-04-27selftests/nolibc: drop unnecessary 'mode' argument to open()Thomas Weißschuh
The mode is unnecessary here, drop it. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260419-nolibc-open-mode-v1-1-8dc5a960daa7@weissschuh.net
2026-04-27remoteproc: Dead code cleanup in Kconfig for STM32_RPROCJulian Braha
There is already an 'if REMOTEPROC' condition wrapping this config option, making the 'depends on REMOTEPROC' statement a duplicate dependency (dead code). I propose leaving the outer 'if REMOTEPROC...endif' and removing the individual 'depends on REMOTEPROC' statement. This dead code was found by kconfirm, a static analysis tool for Kconfig. Signed-off-by: Julian Braha <julianbraha@gmail.com> Acked-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20260417221337.286313-1-julianbraha@gmail.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-04-27bpf: Remove obsolete WARN_ON callJiri Olsa
The WARN_ON call in bpf_trampoline_update could never hit, because we direct the code path with (total == 0) to out label, which effectively skips the WARN_ON call. The WARN_ON made sense back then when it checked tr->selector, but now with total being set just inside the function it's useless. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Acked-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/r/20260424153905.354922-2-jolsa@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-27bpf: Export cnum_umin/umax() helpers for netronome driverAlan Maguire
ERROR: modpost: "cnum64_umin" [drivers/net/ethernet/netronome/nfp/nfp.ko] undefined! ERROR: modpost: "cnum64_umax" [drivers/net/ethernet/netronome/nfp/nfp.ko] undefined! Export symbols for these references. Reported-by: Kaitao Cheng <pilgrimtao@gmail.com> Fixes: bbc631085503 ("bpf: replace min/max fields with struct cnum{32,64}") Signed-off-by: Alan Maguire <alan.maguire@oracle.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20260427112205.1346733-1-alan.maguire@oracle.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-27tools/nolibc: Don't use stack protector before setting it upDaniel Palmer
The stack protector is configured in _start_c() so we shouldn't use it before then. Add __nolibc_no_stack_protector to _start_c() to avoid the compiler generating stack protector code for _start_c() and thus using it before its configured. Signed-off-by: Daniel Palmer <daniel@thingy.jp> Link: https://patch.msgid.link/20260425111315.3191461-3-daniel@thingy.jp Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
2026-04-27Merge branch 'bpf-range_within-must-check-cnum-ranges-instead-of-min-max-pairs'Alexei Starovoitov
Eduard Zingerman says: ==================== bpf: range_within() must check cnum ranges instead of min/max pairs This is a follow-up for series [1]. is_state_visited() should check cnum's subset relations using cnum-based operations, not min/max projections. See patch #1 for detailed explanation and patch #2 for an example of buggy program accepted by verifier w/o this fix. Updated veristat performance numbers compared to master before [1] merge follow. Measurements done for the same set of selftests/ sched_ext/meta/cilium programs as in [1]. Net increase: 98K insn 88 programs Net decrease: -282K insn 52 programs Raw stats filtered as -f insns_pct>1 -f !insns<10000: ========= selftests: master vs experiment ========= File Program Insns (A) Insns (B) Insns (DIFF) ---- ------- --------- --------- ------------ Total progs: 4665 total_insns diff min: -0.44% total_insns diff max: 52.94% total_insns abs max old: 837,487 total_insns abs max new: 837,487 -5 .. 0 %: 8 0 .. 5 %: 4652 5 .. 15 %: 1 40 .. 50 %: 3 50 .. 55 %: 1 ========= scx: master vs experiment ========= File Program Insns (A) Insns (B) Insns (DIFF) ----------------- --------------- --------- --------- ---------------- scx_layered.bpf.o layered_enqueue 13718 14402 +684 (+4.99%) scx_rusty.bpf.o rusty_enqueue 39842 22053 -17789 (-44.65%) scx_rusty.bpf.o rusty_stopping 37738 19949 -17789 (-47.14%) scx_wd40.bpf.o wd40_stopping 37729 19880 -17849 (-47.31%) Total progs: 376 total_insns diff min: -47.31% total_insns diff max: 19.61% total_insns abs max old: 233,669 total_insns abs max new: 233,696 -50 .. -40 %: 3 -5 .. 0 %: 3 0 .. 5 %: 367 5 .. 15 %: 2 15 .. 20 %: 1 ========= meta: master vs experiment ========= File Program Insns (A) Insns (B) Insns (DIFF) -------------------------------------- ------------------- --------- --------- ---------------- <sandbox> test_file_open 88771 104160 +15389 (+17.34%) <profiler> on_perf_event 48056 54544 +6488 (+13.50%) <profiler> on_tracepoint_event 48059 54547 +6488 (+13.50%) <profiler> on_perf_event 48056 54544 +6488 (+13.50%) <profiler> on_tracepoint_event 48059 54547 +6488 (+13.50%) <profiler> on_alloc 50445 56933 +6488 (+12.86%) <profiler> on_free 50251 56739 +6488 (+12.91%) <profiler> on_perf_event 48056 54544 +6488 (+13.50%) <profiler> on_tracepoint_event 48059 54547 +6488 (+13.50%) <profiler> future_iter_resume 50114 56602 +6488 (+12.95%) <profiler> on_py_event 50042 56530 +6488 (+12.97%) scx_layered_bpf_skel_genskel-bpf.bpf.o layered_enqueue 13287 13963 +676 (+5.09%) scx_layered_bpf_skel_genskel-bpf.bpf.o layered_enqueue 13269 13945 +676 (+5.09%) scx_layered_bpf_skel_genskel-bpf.bpf.o layered_enqueue 13269 13945 +676 (+5.09%) <firewall> ..._egress 222327 164648 -57679 (-25.94%) <firewall> ..._tc_eg 222839 164772 -58067 (-26.06%) <firewall> ..._egress 222327 164648 -57679 (-25.94%) <firewall> ..._tc_eg 222839 164772 -58067 (-26.06%) Total progs: 1540 total_insns diff min: -26.06% total_insns diff max: 37.25% total_insns abs max old: 666,036 total_insns abs max new: 666,036 -30 .. -20 %: 4 -5 .. 0 %: 10 0 .. 5 %: 1494 5 .. 10 %: 10 10 .. 15 %: 13 15 .. 25 %: 5 35 .. 40 %: 4 ========= cilium: master vs experiment ========= File Program Insns (A) Insns (B) Insns (DIFF) --------------- --------------------------------- --------- --------- --------------- bpf_host.o tail_handle_ipv4_cont_from_host 20962 26024 +5062 (+24.15%) bpf_host.o tail_handle_ipv6_cont_from_host 17036 18672 +1636 (+9.60%) bpf_host.o tail_nodeport_nat_ingress_ipv4 20080 19858 -222 (-1.11%) bpf_lxc.o tail_nodeport_nat_ingress_ipv4 10697 10510 -187 (-1.75%) bpf_overlay.o tail_handle_inter_cluster_revsnat 11099 10857 -242 (-2.18%) bpf_overlay.o tail_nodeport_nat_ingress_ipv4 11951 11768 -183 (-1.53%) bpf_wireguard.o tail_nodeport_nat_ingress_ipv4 11993 11811 -182 (-1.52%) Total progs: 134 total_insns diff min: -3.32% total_insns diff max: 24.15% total_insns abs max old: 152,012 total_insns abs max new: 152,012 -5 .. 0 %: 12 0 .. 5 %: 120 5 .. 15 %: 1 20 .. 25 %: 1 [1] https://lore.kernel.org/bpf/fd376f47b9512daf669a87b23573f614ec146385.camel@gmail.com/T/ --- ==================== Link: https://patch.msgid.link/20260425-cnum-range-within-v1-0-2fdca70cb09d@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-27selftests/bpf: a test for proper cnums compare in is_state_visited()Eduard Zingerman
Test case demonstrating a bug in cnum comparison logic fixed by previous commit. A pruning point is reached with r6 in two states: 1. 32-bit range of [0x7FFFFFF0, U32_MAX] ∪ [0, 0x10] 2. 32-bit range of [0x100, 0x200] At pruning point the buggy is_state_visited() logic would assume that would assume range (2) to be a subset of (1) and fail to explore the path performing division by zero. Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20260425-cnum-range-within-v1-2-2fdca70cb09d@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-27bpf: range_within() must check cnum ranges instead of min/max pairsEduard Zingerman
states.c:range_within() must be updated to properly check if cnum-based range in an old state is a superset of a range in the cur state. Currently it makes the decision using min/max accessors: reg_umin(old) <= reg_umin(cur) <= reg_umax(old) This is wrong for cnums that cross both UT_MAX/0 and ST_MAX/ST_MIN boundaries. Consider cnum32{base=0x7FFFFFF0, size=0x80000020}, which represents values [0x7FFFFFF0, ..., U32_MAX, 0, ..., 0x10]. Its projections are u32_min/max=0/U32_MAX, s32_min/max=S32_MIN/MAX. A register with range [0x100, 0x200] (which lies entirely in the gap of the wrapping range) would pass the min/max check despite having no overlap with the actual cnum arc. This commit replaces min/max comparison with cnum{32,64}_is_subset() operation. The operation implementation is verified using cbmc model checker in [1]. [1] https://github.com/eddyz87/cnum-verif/ Fixes: bbc631085503 ("bpf: replace min/max fields with struct cnum{32,64}") Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20260425-cnum-range-within-v1-1-2fdca70cb09d@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-27selftests: harness: Restore order of test functionsThomas Weißschuh
The recent addition of explicit constructor orders for fixture tests broke the ordering of those relative to non-fixture tests and the reverse-constructor-order detection. Restore the ordering of the test functions relative to each other by using the same explicit test order for all test registrations and __constructor_order_first(). Rename the constant, as it is not specific to TEST_F() anymore. Link: https://lore.kernel.org/r/20260422-kselftests-harness-order-v2-1-93ea980ea3ac@linutronix.de Fixes: 6be268151426 ("selftests/harness: order TEST_F and XFAIL_ADD constructors") Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Kees Cook <kees@kernel.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-04-27selftests: kselftest: fix wrong test number in ksft_exit_skipSarthak Sharma
ksft_exit_skip() increments ksft_xskip before printing the KTAP result. As a result, ksft_test_num() already includes the skipped test. Adding 1 to ksft_test_num() increments the printed test number again, producing an incorrect test number and wrong KTAP output. Drop the extra increment and print ksft_test_num() directly. Link: https://lore.kernel.org/r/20260427112447.147985-1-sarthak.sharma@arm.com Fixes: b85d387c9b09 ("kselftest: fix TAP output for skipped tests") Signed-off-by: Sarthak Sharma <sarthak.sharma@arm.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-04-27serial: qcom: Unify user-visible "Qualcomm" nameKrzysztof Kozlowski
Various names for Qualcomm as a company are used in user-visible config options: QCOM, Qualcomm and Qualcomm Technologies. Switch to unified "Qualcomm" so it will be easier for users to identify the options when for example running menuconfig. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260427070052.18097-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-27usb: udc: pxa: remove unused platform_dataArnd Bergmann
None of the remaining boards put useful data into the platform_data structures, so effectively this only works with DT based probing. Remove all code that references this data, to stop using the legacy gpiolib interfaces. The pxa27x version already supports gpio descriptors, while the pxa25x version now does it the same way. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260427143300.2887692-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-27USB: qcom: Unify user-visible "Qualcomm" nameKrzysztof Kozlowski
Various names for Qualcomm as a company are used in user-visible config options: QCOM, Qualcomm and Qualcomm Technologies. Switch to unified "Qualcomm" so it will be easier for users to identify the options when for example running menuconfig. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260427070044.17974-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-27usb: typec: intel_pmc_mux: combine kzalloc + kcallocRosen Penev
A flexible array member can be used to combine allocations and simplify handling slightly. Add __counted_by for extra runtime analysis. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260425014201.439251-1-rosenp@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-27usb: typec: mux: ps883x: Power the retimer off when not in useKonrad Dybcio
When there's nothing going through the retimer, there's no reason to keep it online. Put it in reset when possible to save power. Also, remove the register cache-compare optimization as it makes little sense now that the chip resets during almost all transitions and tracking the validity of that cache becomes a headache. Suggested-by: Jack Pham <jack.pham@oss.qualcomm.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Tested-by: Anthony Ruhier <aruhier@mailbox.org> Link: https://patch.msgid.link/20260420-topic-ps883x_unused_reset-v1-1-7aabf7004d2a@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-27tools/nolibc: Rename __no_stack_protector to __nolibc_no_stack_protectorDaniel Palmer
To avoid polluting the namespace rename __no_stack_protector to __nolibc_no_stack_protector so its now within the nolibc umbrella. Suggested-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Daniel Palmer <daniel@thingy.jp> Link: https://patch.msgid.link/20260425111315.3191461-2-daniel@thingy.jp Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
2026-04-27tools/nolibc: avoid call to wcslen() in _start_c() inserted by clangThomas Weißschuh
Clang may convert the loop to find _auxv into a call to wcslen() which is missing on nolibc. -fsanitize needs to be disabled for this to happen. Use the same pattern as in the nolibc strlen() implementation to avoid the function call generation. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260418-nolibc-wcslen-v1-1-671271b8ea63@weissschuh.net
2026-04-27accel/amdxdna: Add configuring low and medium power modeNishad Saraf
Add support for POWER_MODE_LOW and POWER_MODE_MEDIUM. Signed-off-by: Nishad Saraf <nishads@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260424040824.2253607-2-lizhi.hou@amd.com
2026-04-27accel/amdxdna: Set the system efficiency factor to 2Nishad Saraf
The system efficiency factor is used for QoS calculation. Change it to 2 to account for the efficiency overhead. Signed-off-by: Nishad Saraf <nishads@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260424040824.2253607-3-lizhi.hou@amd.com
2026-04-27accel/amdxdna: Set default DPM level based on QoS for temporal-only modeLizhi Hou
The QoS request provided when creating a hardware context is currently ignored when operating in temporal-only mode. Change this to use resource allocation through xrs_allocate_resource(), which sets the default DPM level according to the QoS request. When multiple hardware contexts are active, track their required DPM levels and set the default DPM level to the highest among them. Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260424040824.2253607-1-lizhi.hou@amd.com
2026-04-27usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctlGreg Kroah-Hartman
Just like in a previous problem in this driver, usblp_ctrl_msg() will collapse the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. Ideally that short command should be detected and error out, but many printers are known to send "incorrect" responses back so we can't just do that. statusbuf is kmalloc(8) at probe time and never filled before the first LPGETSTATUS ioctl. usblp_read_status() requests 1 byte. If a malicious printer responds with zero bytes, *statusbuf is one byte of stale kmalloc heap, sign-extended into the local int status, which the LPGETSTATUS path then copy_to_user()s directly to the ioctl caller. Fix this all by just zapping out the memory buffer when allocated at probe time. If a later call does a short read, the data will be identical to what the device sent it the last time, so there is no "leak" of information happening. Cc: Pete Zaitcev <zaitcev@redhat.com> Assisted-by: gkh_clanker_t1000 Cc: stable <stable@kernel.org> Link: https://patch.msgid.link/2026042011-shredder-savage-48c6@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-27usb: usblp: fix heap leak in IEEE 1284 device ID via short responseGreg Kroah-Hartman
usblp_ctrl_msg() collapses the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. A broken printer can complete the GET_DEVICE_ID control transfer short and the driver has no way to know. usblp_cache_device_id_string() reads the 2-byte big-endian length prefix from the response and trusts it (clamped only to the buffer bounds). The buffer is kmalloc(1024) at probe time. A device that sends exactly two bytes (e.g. 0x03 0xFF, claiming a 1023-byte ID) leaves device_id_string[2..1022] holding stale kmalloc heap. That stale data is then exposed: - via the ieee1284_id sysfs attribute (sprintf("%s", buf+2), truncated at the first NUL in the stale heap), and - via the IOCNR_GET_DEVICE_ID ioctl, which copy_to_user()s the full claimed length regardless of NULs, up to 1021 bytes of uninitialized heap, with the leak size chosen by the device. Fix this up by just zapping the buffer with zeros before each request sent to the device. Cc: Pete Zaitcev <zaitcev@redhat.com> Assisted-by: gkh_clanker_t1000 Cc: stable <stable@kernel.org> Link: https://patch.msgid.link/2026042002-unicorn-greedily-3c63@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-27usb: dwc3: Move GUID programming after PHY initializationSelvarasu Ganesan
The Linux Version Code is currently written to the GUID register before PHY initialization. Certain PHY implementations (such as Synopsys eUSB PHY performing link_sw_reset) clear the GUID register to its default value during initialization, causing the kernel version information to be lost. Move the GUID register programming to occur after PHY initialization completes to ensure the Linux version information persists. Fixes: fa0ea13e9f1c ("usb: dwc3: core: write LINUX_VERSION_CODE to our GUID register") Cc: stable <stable@kernel.org> Reported-by: Pritam Manohar Sutar <pritam.sutar@samsung.com> Signed-off-by: Selvarasu Ganesan <selvarasu.g@samsung.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://patch.msgid.link/20260417063314.2359-1-selvarasu.g@samsung.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-27usb: typec: tcpm: fix debug accessory mode detection for sink portsXu Yang
The port in debug accessory mode can be either a source or sink. The previous tcpm_port_is_debug() function only checked for source port. Commit 8db73e6a42b6 ("usb: typec: tcpm: allow sink (ufp) to toggle into accessory mode debug") changed the detection logic to support both roles, but left some logic in _tcpm_cc_change() unchanged, This causes the state machine to transition to an incorrect state when operating as a sink in debug accessory mode. Log as below: [ 978.637541] CC1: 0 -> 5, CC2: 0 -> 5 [state TOGGLING, polarity 0, connected] [ 978.637567] state change TOGGLING -> SRC_ATTACH_WAIT [rev1 NONE_AMS] [ 978.637596] pending state change SRC_ATTACH_WAIT -> DEBUG_ACC_ATTACHED @ 180 ms [rev1 NONE_AMS] [ 978.647098] CC1: 5 -> 0, CC2: 5 -> 5 [state SRC_ATTACH_WAIT, polarity 0, connected] [ 978.647115] state change SRC_ATTACH_WAIT -> SRC_ATTACH_WAIT [rev1 NONE_AMS] It should go to SNK_ATTACH_WAIT instead of SRC_ATTACH_WAIT state. To fix this, add tcpm_port_is_debug_source() and tcpm_port_is_debug_sink() helper to explicitly identify the power mode in debug accessory mode. Update the state transition logic in _tcpm_cc_change() to ensure the state machine transitions comply with Type-C specification. Also update the logic in run_state_machine() to keep consistency. Fixes: 8db73e6a42b6 ("usb: typec: tcpm: allow sink (ufp) to toggle into accessory mode debug") Cc: stable <stable@kernel.org> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Amit Sunil Dhamne <amitsd@google.com> Link: https://patch.msgid.link/20260424074009.2979266-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-13 07:58:18 +0000