The Motorola Edge 30 is a smartphone released in 2022.
This commit has the following features working:
- Display (simplefb)
- Touchscreen
- Power and volume buttons
- Storage (UFS 3.1)
- Battery (ADSP battmgr)
- USB (Type-C, 2.0, dual-role)
- Wi-Fi and Bluetooth (WCN6750 hw1.0)
Signed-off-by: Val Packett <val@packett.cool> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260403054417.167917-2-val@packett.cool Signed-off-by: Bjorn Andersson <andersson@kernel.org>
arm64: dts: qcom: kaanapali: Add USB support for Kaanapali SoC
Add the base USB devicetree definitions for Kaanapali platform. The overall
chipset contains a single DWC3 USB3 controller (rev. 200a), SS QMP PHY
(rev. v8) and M31 eUSB2 PHY.
Add the generic "xiaomi,beryllium" compatible string after the
panel-specific one, so the compatible list follows the required
ordering from most specific to most generic.
This allows userspace to fall back to the generic Poco F1 compatible
when no panel-specific match is present. In particular, hexagonrpcd
relies on trying all compatible entries to derive the HexagonFS path,
and currently fails when the generic device string is missing.
This change modifies the DT ABI: systems describing the EBBG variant
will now also match on "xiaomi,beryllium", whereas previously only
the panel-specific compatible was exposed.
In practice, no upstream userspace distinguishes between Tianma and
EBBG panel variants. All known consumers rely only on the generic
device identification, and no panel-specific handling exists.
Therefore, enabling the generic fallback does not change effective
runtime behavior, but fixes userspace that depends on generic matching.
The previous state was incomplete, as it omitted the generic
device-compatible string required for proper fallback matching.
dt-bindings: arm: qcom: Document Xiaomi Poco F1 Tianma variant
Document the panel-specific compatible string for the Tianma variant
of the Xiaomi Poco F1:
- "xiaomi,beryllium-tianma"
and require the generic fallback compatible:
- "xiaomi,beryllium"
Update the binding to clarify that all panel variants must list the
variant-specific compatible first, followed by the generic device
compatible, in accordance with DT matching rules.
The previous binding documentation did not describe the Tianma variant
and did not clearly specify the required fallback compatible, which
resulted in inconsistent DTS implementations.
No functional differences are currently exposed between Tianma and EBBG
variants at the binding level; both rely on the same generic device
compatibility for software support.
Error types in EINJV2 use different bit positions for each flavor of
injection from legacy EINJ.
Two issues:
1) The address sanity checks in einj_error_inject() were skipped for
EINJV2 injections. Noted by sashiko[1]
2) __einj_error_trigger() failed to drop the entry of the target
physical address from the list of resources that need to be
requested.
Add a helper function that checks if an injection is to memory and use it
to solve each of these issues.
Note that the old test in __einj_error_trigger() checked that param2 was
not zero. This isn't needed because the sanity checks in einj_error_inject()
reject memory injections with param2 == 0.
Fixes: b47610296d17 ("ACPI: APEI: EINJ: Enable EINJv2 error injections") Reported-by: sashiko <sashiko@sashiko.dev> Reported-by: Herman Li <herman.li@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Tested-by: "Lai, Yi1" <yi1.lai@intel.com> Link: https://sashiko.dev/#/patchset/20260415163620.12957-1-tony.luck%40intel.com Reviewed-by: Jiaqi Yan <jiaqiyan@google.com> Reviewed-by: Zaid Alali <zaidal@os.amperecomputing.com> Link: https://patch.msgid.link/20260421150216.11666-3-tony.luck@intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Matt Roper [Tue, 21 Apr 2026 21:18:34 +0000 (14:18 -0700)]
drm/xe: Steer MCR for NODE/L3BANK according to L3 fusing on Xe2/Xe3
Although the bspec currently indicates that steered reads/writes to L3
register ranges are never terminated for physically present instances
(regardless of fusing) on Xe2, it turns out this is information is
incorrect. The hardware architects have also confirmed that the current
documentation is wrong (or that possibly the wording was intended to be
interpreted in a different way), but have not yet provided an official
spec update.
All of our driver's writes to registers in these ranges are done as
multicast, so steering is not actually important to proper driver
operation; the only impact of this documentation mistake is that on some
fused-down SKUs where the first L3 bank is absent we're not able to
properly read back the values that were written to those registers to
confirm that the writes were applied correctly (e.g., when using the
register-save-restore-check debugfs interface).
Since we don't have an official spec update yet, let's assume that
Xe2/Xe3 use the same fuse => steering logic as Xe3p. I.e., remove
L3BANK and NODE register ranges from the "INSTANCE0" steering group and
add handle them with dedicated handling according to the L3 fuses. From
testing on various fused-down platforms this does appear to give proper
steering and fix the failures reported by IGT's
igt@xe_debugfs@check-gt-reg-sr test.
Kamal Wadhwa [Mon, 6 Apr 2026 13:35:55 +0000 (19:05 +0530)]
arm64: dts: qcom: fix temp-alarm probe failure for PMH0104 on Glymur
The temp-alarm driver probe is failing for the pmh0104 PMICs on glymur.
[ 3.999713] spmi-temp-alarm c426000.spmi:pmic@8:temp-alarm@a00: error -ENODEV: failed to register sensor
[ 4.015066] spmi-temp-alarm c426000.spmi:pmic@9:temp-alarm@a00: error -ENODEV: failed to register sensor
[ 4.033908] spmi-temp-alarm c437000.spmi:pmic@b:temp-alarm@a00: error -ENODEV: failed to register sensor
This happens because thermal zone associated with the temp alarm was
defined under the thermal zones parent node which had a typo (used `_` in
place of `-`). Correct the typo to fix probe failure.
Add necessary properties for ports node in SDM845 DB845c Navigation
mezzanine overlay to fix W=1 DTC warning:
sdm845-db845c-navigation-mezzanine.dtso:19.10-24.5: Warning (unit_address_vs_reg): /fragment@0/__overlay__/ports/port@0: node has a unit name, but no reg or ranges property
Fixes: 30df676a31b7 ("arm64: dts: qcom: sdm845-db845c-navigation-mezzanine: Convert mezzanine riser to dtso") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: David Heidelberg <david@ixit.cz> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260405-dts-qcom-w-1-fixes-v2-5-1f2c7b74a93f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
GXCLKCTL (Graphics GX Clock Controller) is a block dedicated to managing
clocks for the GPU subsystem on GX power domain. The GX clock controller
driver manages only the GX GDSC and the rest of the resources of the
controller are managed by the firmware.
We can use the existing kaanapali driver for Milos as well since the
GX_CLKCTL_GX_GDSC supported by the Linux driver requires the same
configuration.
dt-bindings: clock: qcom: document the Milos GX clock controller
Qualcomm GX(graphics) is a clock controller which has PLLs, clocks and
Power domains (GDSC), but the requirement from the SW driver is to use
the GDSC power domain from the clock controller to recover the GPU
firmware in case of any failure/hangs. The rest of the resources of the
clock controller are being used by the firmware of GPU. This module
exposes the GDSC power domains which helps the recovery of Graphics
subsystem.
Milos can reuse the qcom,kaanapali-gxclkctl.h header due to similarity
of the hardware block, and also reuse of the Linux driver.
Richard Acayan [Tue, 31 Mar 2026 19:44:37 +0000 (15:44 -0400)]
arm64: dts: qcom: sdm670-google-sargo: add imx355 front camera
The Sony IMX355 is the front camera on the Pixel 3a, mounted in portrait
mode. It is connected to CSIPHY1 and CCI I2C1, and uses MCLK2. Add
support for it.
Co-developed-by: Robert Mader <robert.mader@collabora.com> Signed-off-by: Robert Mader <robert.mader@collabora.com> Signed-off-by: Richard Acayan <mailingradian@gmail.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260331194437.41041-4-mailingradian@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Richard Acayan [Tue, 31 Mar 2026 19:44:36 +0000 (15:44 -0400)]
arm64: dts: qcom: sdm670: add camera mclk pins
The camera subsystem is added for the SoC common devicetree, but the
mclk pins should also be common across the SoC. Add the mclk pins for
the cameras.
Richard Acayan [Tue, 31 Mar 2026 19:44:35 +0000 (15:44 -0400)]
arm64: dts: qcom: sdm670: label the camss ports instead of endpoints
Endpoints cannot be pre-defined since commit dcf6fb89e6f7 ("media: qcom:
camss: remove a check for unavailable CAMSS endpoint") was applied,
probing all endpoint nodes and requiring them to have a remote. There is
no sensible remote in the SoC devicetree because camera sensors are
board-specific.
The ports are meant to be extended by a board devicetree in order to
define fully configured endpoints and connect the ports to camera
sensors. For nodes that are only meaningful if extended, labels are
usually assigned. Label these ports so they can be extended directly.
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Richard Acayan <mailingradian@gmail.com> Link: https://lore.kernel.org/r/20260331194437.41041-2-mailingradian@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Merge branch '20260225-topic-wcn6855_pmu_dtbdings-v3-1-576ec5c4e631@oss.qualcomm.com' into arm64-for-7.2
Merge a change that drops the incorrectly added vddrfa1p8-supply to the
WCN6855 Bluetooth binding, so that it can go together with the
DeviceTree changes and avoid introducing new errors/warnings.
arm64: dts: qcom: milos: Reduce rmtfs_mem size to 2.5MiB
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.
Abel Vesa [Mon, 23 Mar 2026 10:01:12 +0000 (12:01 +0200)]
arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers
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.
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.
x86/bug: Put HAVE_ARCH_BUG_FORMAT_ARGS WARN definitions inside __ASSEMBLER__
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.
x86/bug: Add printf() validation to HAVE_ARCH_BUG_FORMAT_ARGS WARNs
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:
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 ]
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.
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>
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>
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
Daniel Almeida [Thu, 9 Apr 2026 17:51:24 +0000 (10:51 -0700)]
drm/tyr: Use register! macro for GPU_CONTROL
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>
Eliot Courtney [Thu, 23 Apr 2026 07:11:44 +0000 (16:11 +0900)]
gpu: nova-core: simplify and_then with condition to filter
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>
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>
Thomas Weißschuh [Sat, 18 Apr 2026 10:20:00 +0000 (12:20 +0200)]
tools/nolibc: handle 64-bit system call arguments on MIPS N32
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.
Thomas Weißschuh [Sat, 18 Apr 2026 10:19:59 +0000 (12:19 +0200)]
tools/nolibc: handle 64-bit system call arguments on x32
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.
Thomas Weißschuh [Sat, 18 Apr 2026 10:19:58 +0000 (12:19 +0200)]
tools/nolibc: cast pointers returned from system calls through integers
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.
Thomas Weißschuh [Sat, 18 Apr 2026 10:19:57 +0000 (12:19 +0200)]
tools/nolibc: add __nolibc_arg_to_reg()
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.
Thomas Weißschuh [Sat, 18 Apr 2026 10:19:56 +0000 (12:19 +0200)]
tools/nolibc: also handle _llseek system call
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.
remoteproc: Dead code cleanup in Kconfig for STM32_RPROC
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.
Jiri Olsa [Fri, 24 Apr 2026 15:39:05 +0000 (17:39 +0200)]
bpf: Remove obsolete WARN_ON call
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.
Daniel Palmer [Sat, 25 Apr 2026 11:13:15 +0000 (20:13 +0900)]
tools/nolibc: Don't use stack protector before setting it up
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.
====================
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 =========
Eduard Zingerman [Sat, 25 Apr 2026 22:48:24 +0000 (15:48 -0700)]
selftests/bpf: a test for proper cnums compare in is_state_visited()
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.
Eduard Zingerman [Sat, 25 Apr 2026 22:48:23 +0000 (15:48 -0700)]
bpf: range_within() must check cnum ranges instead of min/max pairs
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].
Thomas Weißschuh [Wed, 22 Apr 2026 12:32:33 +0000 (14:32 +0200)]
selftests: harness: Restore order of test functions
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.
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.
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.
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.
Konrad Dybcio [Mon, 20 Apr 2026 11:40:28 +0000 (13:40 +0200)]
usb: typec: mux: ps883x: Power the retimer off when not in use
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>
accel/amdxdna: Set default DPM level based on QoS for temporal-only mode
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.
usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl
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.
usb: usblp: fix heap leak in IEEE 1284 device ID via short response
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.
usb: dwc3: Move GUID programming after PHY initialization
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.
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:
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>
usb: typec: tcpm: reset internal port states on soft reset AMS
Reset internal port states (such as vdm_sm_running and
explicit_contract) on soft reset AMS as the port needs to negotiate a
new contract. The consequence of leaving the states in as-is cond are as
follows:
* port is in SRC power role and an explicit contract is negotiated
with the port partner (in sink role)
* port partner sends a Soft Reset AMS while VDM State Machine is
running
* port accepts the Soft Reset request and the port advertises src caps
* port partner sends a Request message but since the explicit_contract
and vdm_sm_running are true from previous negotiation, the port ends
up sending Soft Reset instead of Accept msg.
Felix Gu [Tue, 7 Apr 2026 13:21:22 +0000 (21:21 +0800)]
usb: ulpi: fix memory leak on ulpi_register() error paths
Commit 01af542392b5 ("usb: ulpi: fix double free in
ulpi_register_interface() error path") removed kfree(ulpi) from
ulpi_register_interface() to fix a double-free when device_register()
fails.
But when ulpi_of_register() or ulpi_read_id() fail before
device_register() is called, the ulpi allocation is leaked.
Add kfree(ulpi) on both error paths to properly clean up the allocation.
Fixes: 01af542392b5 ("usb: ulpi: fix double free in ulpi_register_interface() error path") Cc: stable <stable@kernel.org> Signed-off-by: Felix Gu <ustc.gu@gmail.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260407-ulpi-v1-1-f3fafe53f7b2@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Aaro Koskinen [Mon, 13 Apr 2026 18:49:12 +0000 (21:49 +0300)]
USB: omap_udc: DMA: Don't enable burst 4 mode
Commit 65111084c63d7 ("USB: more omap_udc updates (dma and omap1710)")
added setting for DMA burst 4 mode. But I think this should be undone for
two reasons:
- It breaks DMA on 15xx boards - transfers just silently stall.
- On newer OMAP1 boards, like Nokia 770 (omap1710), there is no measurable
performance impact when testing TCP throughput with g_ether with large
15000 byte MTU size.
It's also worth noting that when the original change was made, the
OMAP_DMA_DATA_BURST_4 handling in arch/arm/plat-omap/dma.c was broken, and
actually resulted in the same as the OMAP_DMA_DATA_BURST_DIS i.e. burst
disabled. This was fixed not until a couple kernel releases later in an
unrelated commit 1a8bfa1eb998a ("[ARM] 3142/1: OMAP 2/5: Update files
common to omap1 and omap2").
So based on this it seems there was never really a very good reason to
enable this burst mode in omap_udc, so remove it now to allow 15xx DMA
to work again (it provides 2x throughput compared to PIO mode).
Fixes: 65111084c63d ("[PATCH] USB: more omap_udc updates (dma and omap1710)") Cc: stable <stable@kernel.org> Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Link: https://patch.msgid.link/ad06qHLclWHeSGnV@darkstar.musicnaut.iki.fi Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chen-Yu Tsai [Tue, 24 Mar 2026 16:43:54 +0000 (00:43 +0800)]
soc: sunxi: sram: Add H616 SRAM regions
The Allwinner H616 has two switchable peripheral SRAM regions:
- The VE SRAM is a 2 MB dedicated SRAM for the Video Engine. CPU access
to this region is enabled by default. CPU access can be disabled,
after which reads will show the same stale value for all addresses,
while writes are ignored.
The mux value for this region is different from previous generations.
- The SRAM C region is an alias of the first 128 KB of VE SRAM, plus 64
KB of DE SRAM. The latter is otherwise unaccessible from the CPU. When
CPU access is disabled, the whole region reads as zero, while writes
are ignored.
The mux value for this region is the same as on the A64 and H6.
Add data for the VE SRAM. The register values were taken from the BSP
vendor kernel.
projects / thirdparty / linux.git / log
