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>
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
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: 5b472b6e5b ("x86_64/bug: Implement __WARN_printf()")
Fixes: 11bb4944f0 ("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
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>
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>
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
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>
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>
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: d6cb7319e6 ("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 5f4f954bba ("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: 5f4f954bba ("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>
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
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
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
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
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>
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
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>
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>
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>
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>
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: bbc6310855 ("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>
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: 6be2681514 ("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>
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: b85d387c9b ("kselftest: fix TAP output for skipped tests")
Signed-off-by: Sarthak Sharma <sarthak.sharma@arm.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
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>
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>
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>
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>
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>
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>
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
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
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
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>
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>
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: fa0ea13e9f ("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>
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 8db73e6a42 ("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: 8db73e6a42 ("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>
Commit 01af542392 ("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: 01af542392 ("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>
Commit 65111084c6 ("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 1a8bfa1eb9 ("[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: 65111084c6 ("[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>
The H616 SoC has a video engine, and two SRAM regions needed by it.
Add the SRAM regions to the dtsi file. The video engine will be added
in a separate change.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
[wens@kernel.org: Add VE SRAM region, commit message, and split into two]
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20260324164357.1607247-8-wens@kernel.org
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
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.
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20260324164357.1607247-7-wens@kernel.org
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
On the H616, the video engine needs to claim two SRAM regions.
Support claiming multiple regions per device.
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20260324164357.1607247-6-wens@kernel.org
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
