The SMMU is enabled and transactions going through it are cache
coherent. Add the dma-coherent property to the XGMAC nodes to prevent
redundant cache flush/invalidate operations and potential stale data
issues.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
The SMMU is disabled in socfpga_agilex5.dtsi. The SoC uses a different
memory-mapped base address for its peripherals, which requires the SMMU
to be active so that the Secure Device Manager (SDM) can correctly
access those regions through address translation.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Replace the sole hexadecimal interrupt number by a decimal number, for
consistency with all other interrupt numbers.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Extend the gmac0 interrupt list to support 8 TX and 8 RX per-channel
interrupts in addition to the combined macirq, enabling per-channel
interrupt handling for improved DMA performance.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
dma_fence_dedup_array() returns 1 when called with num_fences == 0:
the for-loop body never executes, j stays at 0, and the final
`return ++j` yields 1. This contradicts both the kernel-doc ("Return:
Number of unique fences remaining in the array") and the natural
expectation that 0 input gives 0 output.
The caller __dma_fence_unwrap_merge() bails out via the
`if (count == 0 || count == 1)` fast path and so is save.
But amdgpu_userq_wait_*() could reach the dedup call with a zero local
count and dereference an uninitialized fence slot in the array.
Make the contract match the documentation by returning 0 early. This
also skips an unnecessary sort() call on an empty array.
Cc: stable@vger.kernel.org
Signed-off-by: Baineng Shou <shoubaineng@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Fixes: 575ec9b0c2 ("dma-fence: Add helper to sort and deduplicate dma_fence arrays")
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20260629031346.3875683-1-shoubaineng@gmail.com
The commit mentioned in the fixes tag below introduced a mechanism
through which fence producers can fully decouple from fence consumers.
This, desirable, mechanism is based on the fence's signaled-bit as the
"decoupling point".
A sophisticated interaction between RCU and atomic instructions attempts
to ensure that fence consumers can still interact with fence producers
through the dma_fence_ops (callback pointers into the producer).
This is the desired behavior: to check for decoupling, the signaled-bit
is first checked. If it's not yet signaled, RCU ensures that the ops
pointer cannot yet be NULL.
Hereby, dma_fence_signal_timestamp_locked() first sets the signaled-bit,
and then sets the ops pointer to NULL. Readers first load the ops
pointer, and then check through the signaled-bit whether the pointer can
legally be accessed.
These set and load operations could occur out of order on weakly ordered
platforms. This problem can be solved very elegantly by using the ops
pointer itself as the synchronization point. The pointer is either NULL,
or cannot become NULL while it is being used thanks to RCU.
Replace the signaled-bit check in dma_fence_timeline_name() and
dma_fence_driver_name().
Cc: stable@vger.kernel.org
Fixes: f4cc3ab824 ("dma-buf: protected fence ops by RCU v8")
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/r/20260629075636.2513214-2-phasta@kernel.org
Signed-off-by: Christian König <christian.koenig@amd.com>
Commit 48478b9f79 ("arm64/mm: Enable batched TLB flush in
unmap_hotplug_range") inadvertently introduced redundant TLB
invalidation when clearing a block entry, resulting in unnecessary
broadcast invalidation on CPUs without support for range-based
invalidation.
Re-introduce the old behaviour, along with some expanded comments to
help people working in this area next time around.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: David Hildenbrand <david@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Closes: https://lore.kernel.org/all/b0d5836032ce3135bfc473f6bff791306d086925.camel@decadent.org.uk/
Fixes: 48478b9f79 ("arm64/mm: Enable batched TLB flush in unmap_hotplug_range()")
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
[will: Reword comments and commit message]
Signed-off-by: Will Deacon <will@kernel.org>
Starting with Rust 1.98.0 (expected 2026-08-20), Rust is introducing a
couple new lints, `invalid_runtime_symbol_definitions` (deny-by-default)
and `suspicious_runtime_symbol_definitions` (warn-by-default), which check
the signature of items whose symbol name is a runtime symbol expected by
`core`.
Our build hits the second one, i.e. the warning:
error: suspicious definition of the runtime `strlen` symbol used by the standard library
--> rust/bindings/bindings_generated.rs:20018:5
|
20018 | pub fn strlen(s: *const ffi::c_char) -> usize;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: expected `unsafe extern "C" fn(*const i8) -> usize`
found `unsafe extern "C" fn(*const u8) -> usize`
= help: either fix the signature or remove any attributes like `#[unsafe(no_mangle)]`, `#[unsafe(export_name = "strlen")]`, or `#[link_name = "strlen"]`
= help: allow this lint if the signature is compatible
= note: `-D suspicious-runtime-symbol-definitions` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(suspicious_runtime_symbol_definitions)]`
error: suspicious definition of the runtime `strlen` symbol used by the standard library
--> rust/uapi/uapi_generated.rs:14236:5
|
14236 | pub fn strlen(s: *const ffi::c_char) -> usize;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: expected `unsafe extern "C" fn(*const i8) -> usize`
found `unsafe extern "C" fn(*const u8) -> usize`
= help: either fix the signature or remove any attributes like `#[unsafe(no_mangle)]`, `#[unsafe(export_name = "strlen")]`, or `#[link_name = "strlen"]`
= help: allow this lint if the signature is compatible
= note: `-D suspicious-runtime-symbol-definitions` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(suspicious_runtime_symbol_definitions)]`
Thus `allow` the lint in `bindings` and `uapi`.
A more targeted alternative to avoid `allow`ing it would be to pass
`--blocklist-function strlen` to `bindgen`, but we would perhaps need
to adjust if other C headers end up adding more (or Rust checking more).
Since it is just the less critical one that we hit, and since eventually
this should be properly fixed by getting upstream Rust to provide a flag
like GCC/Clang's `-funsigned-char` [2][3], just `allow` it for now.
Cc: Urgau <urgau@numericable.fr>
Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Link: https://github.com/rust-lang/rust/pull/155521 [1]
Link: https://github.com/rust-lang/rust/issues/138446 [2]
Link: https://github.com/Rust-for-Linux/linux/issues/355 [3]
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Link: https://patch.msgid.link/20260615143225.471756-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
The C1-Pro SME DVMSync workaround currently samples mm_cpumask() from
arch_tlbbatch_add_pending(). It requires a DSB after every batched TLBI
so that the mask read is ordered after the hardware DVMSync, defeating
much of the reclaim batching benefit.
Introduce the sme_active_cpus mask tracking which CPUs run in user-space
with SME enabled and use it for batch flushing instead of accumulating
the mm_cpumask() of the unmapped pages.
Fixes: 0baba94a97 ("arm64: errata: Work around early CME DVMSync acknowledgement")
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Tested-by: Joshua Liu <josliu@google.com>
Signed-off-by: Will Deacon <will@kernel.org>
On arm64, when booting with `maxcpus` greater than the number of present
CPUs (e.g., QEMU -smp cpus=4,maxcpus=8), some CPUs are marked as 'present'
but have not yet been registered via register_cpu(). Consequently,
the per-cpu device objects for these CPUs are not yet initialized.
In cpuhp_smt_enable(), the code iterates over all present CPUs. Calling
_cpu_up() for these unregistered CPUs eventually leads to
sysfs_create_group() being called with a NULL kobject (or a kobject
without a directory), triggering the following warning in
fs/sysfs/group.c:
WARNING: fs/sysfs/group.c:137 at internal_create_group+0x41c/0x4bc, CPU#2: sh/181
[...]
Call trace:
internal_create_group+0x41c/0x4bc (P)
sysfs_create_group+0x18/0x24
topology_add_dev+0x1c/0x28
cpuhp_invoke_callback+0x104/0x20c
__cpuhp_invoke_callback_range+0x94/0x11c
_cpu_up+0x200/0x37c
When booting with ACPI, arm64 smp_prepare_cpus() currently sets all
enumerated CPUs as "present" regardless of their status in the MADT. This
causes issues with SMT hotplug control. For instance, with QEMU's
"-smp 4,maxcpus=8" configuration, the MADT GICC entries are populated as
follows:
1. The first four CPUs: `Enabled` set but `Online Capable` not set.
2. The remaining four CPUs: `Online Capable` set but `Enabled` not set
to support potential hot-plugging.
Fix this by:
1. When booting with ACPI, checking the ACPI_MADT_ENABLED flag in the GICC
entry before calling set_cpu_present() during SMP initialization.
2. Properly managing the present mask in acpi_map_cpu() and
acpi_unmap_cpu() to support actual CPU hotplug events, This aligns with
other architectures like x86 and LoongArch.
3. Update the arm64 CPU hotplug documentation to no longer state that all
online-capable vCPUs are marked as present by the kernel at boot time.
This ensures that only physically available or explicitly enabled CPUs
are in the present mask, keeping the SMT control logic consistent with
the actual hardware state.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Yicong Yang <yangyicong@hisilicon.com>
Cc: stable@vger.kernel.org
Link: https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#gic-cpu-interface-gicc-structure
Fixes: eed4583bcf ("arm64: Kconfig: Enable HOTPLUG_SMT")
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Will Deacon <will@kernel.org>
Sashiko review pointed out the following issue[1].
Commit eba4675008 ("arm64: arch_register_cpu() variant to check if
an ACPI handle is now available.") introduced architectural safety
blocks inside arch_unregister_cpu(). If a hot-unplug operation is
determined to be a physical hardware removal (where _STA evaluates to
!ACPI_STA_DEVICE_PRESENT), or if firmware evaluation fails, it aborts
the unregistration transaction early to protect unreadied arm64
infrastructure.
However, returning early from arch_unregister_cpu() causes a catastrophic
state tearing because the generic ACPI layer (acpi_processor_post_eject())
unconditionally continues its cleanup flow. This leaves the stale sysfs
device leaked in the memory, deadlocking any subsequent hot-add attempts
on the same CPU.
Fix it by simplifying arch_unregister_cpu() to always proceed with
the unregistration, as a pr_err_once() warning is sufficient to make
it more visible for currently not supported physical CPU removal.
Also remove the redundant NULL check on acpi_handle as it cannot be
NULL when calling arch_unregister_cpu().
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: stable@vger.kernel.org
Link: https://sashiko.dev/#/patchset/20260520022023.126670-1-ruanjinjie@huawei.com [1]
Fixes: eba4675008 ("arm64: arch_register_cpu() variant to check if an ACPI handle is now available.")
Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Currently if an HDMI cable is connected while the system is suspended,
the HDMI audio jack status stays off after resume.
This is due to the jack state not being synced by the HDA HDMI codec
device's runtime resume, as that never happens if the device was runtime
suspended before the system suspended, or by the acomp notification
triggered from the DRM side if that happens before the HDA HDMI codec
device has resumed.
To fix this, if snd_hda_hdmi_acomp_pin_eld_notify() gets called before
the HDA HDMI codec device has resumed, mark it to be forcefully runtime
resumed at the next PM complete time.
Do this using a separate acomp_requested_resume flag that can be
temporarily set without overwriting forced_resume for drivers that
always want to force resume.
Assisted-by: Copilot:claude-sonnet-4.6
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Link: https://patch.msgid.link/20260626-hda-force-resume-eld-notify-v1-1-a92cb01393e0@collabora.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
guard() is more concise and ensures that lock is released at the end of
the scope.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/aZarCgDvMUta4Viq@google.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
The Pioneer DJ DJM-S11, a professional 2-port DJ mixer, is currently not
recognized as an audio interface and therefore not usable on Linux. This
patch enables its full audio functionality.
Like other mixers in the Pioneer DJ DJM family, the DJM-S11 uses
vendor-specific USB class descriptors (0xff) and requires custom mixer
quirks to expose the hardware's input capture routing and volume
controls.
Add the USB vendor and product ID (2b73:0037) to quirks-table.h, mapping
the control interface (Interface 0) to trigger the standard mixer quirks,
and establishing the audio formats for the playback and capture streams.
Control interface 3 is likely related to the touchscreen which is
capable to display waveforms, etc. This functionality is not supported.
In mixer_quirks.c, add the DSP routing options for the DJM-S11. This
creates the ALSA kcontrols for selecting the capture sources (Phono,
Line, Post-fader, etc.) and initializes the default DSP state during
the device probe.
Note that the DJM-S11's capture endpoint clock is strictly slaved to
its playback endpoint. Capturing audio (e.g., timecode vinyl DVS input)
physically requires an active playback stream on the output channels
to feed the master word clock back to the capture stage. Userspace
audio servers (such as PipeWire or JACK) should be configured in
full-duplex mode or have automatic node suspension disabled to maintain
the clock line and prevent I/O errors during capture.
Signed-off-by: Federico Beffa <beffa@fbengineering.ch>
Link: https://patch.msgid.link/20260625115340.823184-1-beffa@fbengineering.ch
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On the Razer Blade 16 (2025) (Realtek ALC298, PCI SSID 1a58:300e) the
internal speakers are driven through an external smart amplifier whose
crossover, voicing and protection live in a DSP reached over a vendor
coef mailbox on NID 0x20. Both speaker pins are fed from one DAC
through a mixer and the amplifier does the crossover. The BIOS leaves
the tweeter pin (NID 0x14) disabled (default config 0x411111f0), so the
tweeters are not exposed and the amplifier is never programmed for this
machine under Linux.
Add a fixup for the machine that:
- re-exposes the tweeter pin (NID 0x14) as an internal speaker in the
same association (2) as the woofer (NID 0x17), so the controls come
out as "Speaker"/"Bass Speaker", with auto-mute on headphone
insertion;
- pins every output to a fixed converter via preferred_dacs so the
routing does not depend on the generic parser's DAC-allocation
heuristics: both speaker pins share DAC 0x03 (the only converter
that drives the woofer on this machine) through the mixer, while the
headphone (NID 0x21) keeps DAC 0x02. Without a fixed assignment the
parser brings up only one speaker pin and leaves the other silent;
- wakes the external amp, programs its DSP over the NID-0x20 mailbox
at init (boot and resume) and parks it; it is woken again for
playback and parked afterwards from a pcm_playback_hook, like the
existing Samsung and LG Gram amplifier fixups.
The DSP sequence was obtained by capturing the Windows driver's HD-audio
traffic via QEMU/VFIO passthrough of the controller and reducing it to
the NID-0x20 writes this machine needs; everything else the parser
rebuilds. The captured tables are large, so the programming and
the fixup live in a separate file under
sound/hda/codecs/helpers/ that the codec driver includes.
Signed-off-by: Christopher Höner <christopher-hoener@web.de>
Link: https://patch.msgid.link/20260623191436.6605-1-christopher-hoener@web.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When a device gets disconnected, the driver waits until the all opened
file descriptors are closed before releasing the device. Although PCM
core emits an error to any further syscalls (except for close), some
applications don't notice the disconnected state because they mainly
access only via mmap, and it may block the device release
unnecessarily too long.
This patch is an attempt to improve the behavior by adding the
notification of the PCM disconnected state at mmap data faulting.
When the device is disconnected, it now returns VM_FAULT_SIGBUS, so
that the application can notice the invalid PCM state.
Reported-and-tested-by: Ai Chao <aichao@kylinos.cn>
Link: https://lore.kernel.org/20260615132657.2097213-1-aichao@kylinos.cn>
Link: https://patch.msgid.link/20260619150035.1560937-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
usb_audio_probe() can create USB-audio component resources before the
first interface is recorded in chip->num_interfaces. If a later probe
step fails, the error path drops chip->active and frees the card directly
when no interfaces have been registered.
Normal disconnect first releases USB-audio components in a fixed order
before the card is freed. The first-interface probe error path skipped
that sequence, so partially initialized PCM, endpoint, MIDI, media, or
mixer resources could be left for the card private_free path without their
disconnect handling having run.
Move the existing normal-disconnect component release sequence into a
helper and call it from the zero-interface probe error path before
snd_card_free(). Keep the normal disconnect ordering unchanged: PCM
streams, endpoint resources, MIDI 1.0 resources, MIDI 2.0 resources, media
device cleanup, then mixer resources.
Assisted-by: Codex:gpt-5.5
Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
Link: https://patch.msgid.link/20260618170026.192212-1-zzzccc427@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Enable the bcm4330-bt device for manta boards on serial0.
Also adds the necessary pin definitions and interrupt handling for
wakeup.
Co-developed-by: Alexandre Marquet <tb@a-marquet.fr>
Signed-off-by: Alexandre Marquet <tb@a-marquet.fr>
Signed-off-by: Lukas Timmermann <linux@timmermann.space>
Link: https://patch.msgid.link/20260614-manta-bluetooth-v2-1-52de06cabf9d@timmermann.space
[krzk: Fixed invalid Co-developed-by for Lukas Timmermann]
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
In capture_urb_complete(), usb_anchor_urb() is called on every
completion callback, but the URB is already anchored from the
initial submission in tascam_trigger_start(). Each redundant call
corrupts the anchor's doubly-linked list and inflates the URB
refcount. When usb_kill_anchored_urbs() traverses the list during
stream stop / suspend / disconnect, the corrupted list leads to
use-after-free.
Remove the redundant usb_anchor_urb() from the resubmit path.
Cc: stable@vger.kernel.org
Fixes: c1bb0c13e4 ("ALSA: usb-audio: us144mkii: Implement audio capture and decoding")
Signed-off-by: WenTao Liang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20260627042949.61767-1-vulab@iscas.ac.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
While the GCC and Clang compilers already define __ASSEMBLER__
automatically when compiling assembly code, __ASSEMBLY__ is a
macro that only gets defined by the Makefiles in the kernel.
This can be very confusing when switching between userspace
and kernelspace coding, or when dealing with uapi headers that
rather should use __ASSEMBLER__ instead. So let's standardize now
on the __ASSEMBLER__ macro that is provided by the compilers.
This is a completely mechanical patch (done with a simple "sed -i"
statement).
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://patch.msgid.link/20260619125827.215977-1-thuth@redhat.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Add the syscon-hsi0 node to control PCIe PHY power, PLL settings,
and device direction (RC/EP mode) on ExynosAutov920.
Signed-off-by: Sanghoon Bae <sh86.bae@samsung.com>
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Link: https://patch.msgid.link/20260610050326.2903402-3-sh86.bae@samsung.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Add hsi0 compatible on samsung,exynos-sysreg
To support ExynosAutov920 PCIe settings:
- PCIe PHY power control
- PLL settings for PCIe
- PCIe device direction (RC/EP)
Signed-off-by: Sanghoon Bae <sh86.bae@samsung.com>
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260610050326.2903402-2-sh86.bae@samsung.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
exynos_get_pmu_regmap() obtains a device_node via of_find_matching_node()
and passes it to exynos_get_pmu_regmap_by_phandle(np, NULL). With
propname == NULL the callee uses np directly and does not drop a
reference, so the reference taken by of_find_matching_node() is leaked on
every call -- including on each -EPROBE_DEFER retry of the only in-tree
caller, exynos_retention_init() in the Exynos pinctrl driver.
Annotate np with the __free(device_node) cleanup attribute so the
reference is released when the function returns.
Found by static analysis tool CodeQL.
Fixes: 76640b84bd ("soc: samsung: pmu: Provide global function to get PMU regmap")
Signed-off-by: Weigang He <geoffreyhe2@gmail.com>
Link: https://patch.msgid.link/20260609143852.1783558-1-geoffreyhe2@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
FFA_FEATURES reports the minimum size and alignment boundary required
for RXTX_MAP. In FF-A v1.2 and later it can also report a maximum buffer
size, with zero meaning that no maximum is enforced.
The driver only used the minimum value and then rounded it up to PAGE_SIZE
before invoking RXTX_MAP after commit 83210251fd ("firmware: arm_ffa:
Use the correct buffer size during RXTX_MAP"). On systems where PAGE_SIZE
is larger than the advertised minimum, this can exceed a non-zero maximum
reported by firmware. Older implementations do not advertise a maximum and
may also reject the rounded-up size.
Decode the maximum size and clamp the page-aligned minimum to it when it
is present. If no maximum is advertised and RXTX_MAP rejects the rounded
size with INVALID_PARAMETERS, retry with the advertised minimum size.
Record drv_info->rxtx_bufsz only after RXTX_MAP succeeds so it reflects
the size registered with firmware.
While there, also update RXTX_MAP_MIN_BUFSZ() to use FIELD_GET() for
consistency.
Fixes: 83210251fd ("firmware: arm_ffa: Use the correct buffer size during RXTX_MAP")
Suggested-by: Sudeep Holla <sudeep.holla@kernel.org>
Signed-off-by: Seth Forshee <sforshee@nvidia.com>
Link: https://patch.msgid.link/20260602-b4-ffa-rxtx-map-fixes-v2-1-7cb06508da84@nvidia.com
(sudeep.holla: Minor rewording subject and commit message)
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
If the port is closed while throttled, the read urb is never resubmitted
and the port will not receive any further data until the device is
reconnected (or the driver is rebound).
Clear the throttle flags and submit the urb if needed when opening the
port.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
The Ingenic USB PHY provider is now built from phy-ingenic-usb.o under
`CONFIG_PHY_INGENIC_USB`.
The Ingenic defconfigs below still enable the stale `CONFIG_JZ4770_PHY`
symbol. That symbol no longer carries the provider object, so the
defconfigs lose the intended USB PHY provider after olddefconfig.
Use `CONFIG_PHY_INGENIC_USB` instead.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Since the commit 91840be8f7 ("irq_work: Fix use-after-free in
irq_work_single() on PREEMPT_RT"), we observed the performance of
execve() is significantly impacted on MIPS.
While we are unsure how that commit caused the impact or how to improve
it (or even if it can be improved at all), implementing IRQ work with
self-IPI seems able to mitigate the impaction.
Perhaps this can/should be implemented for other MIPS architecture
processors as well, but we don't have the enough knowledge of them, nor
access to the hardware. So only implement it for loongson64 here.
Link: https://lore.kernel.org/6be1cdd5f91dd7418a32ff372a6f3ae259b19195.camel@xry111.site/
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
If a device has less physical memory than the highmem threshold
bootmem_init() doesn't set highstart_pfn. This results in highmem_init()
wrongly disabling the entire memory range if the cpu doesn't support
highmem. Add a check that highstart_pfn is non zero before removing the
highmem block.
Fixes: f171b55f14 ("mips: fix HIGHMEM initialization")
Signed-off-by: Kyle Hendry <kylehendrydev@gmail.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Add an of_device_id table and hook it into the i2c driver so the
ds2482/ds2484 can be matched and auto-probed from Device Tree.
This allows automatic module loading when instantiated via DT.
Signed-off-by: Kryštof Černý <cleverline1mc@gmail.com>
Link: https://patch.msgid.link/20260612-w1-of-autoload-v1-1-74e8a17626e6@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
The vDSO needs to have a unique build id in a similar manner
to the kernel and modules. Use the build salt macro.
Signed-off-by: Bastian Blank <waldi@debian.org>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Make nova-core a build dependency of nova-drm, so its crate metadata is
available and up-to-date when the latter is built.
This is intended to be a workaround until the build system supports Rust
cross-crate dependencies natively.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260622-nova-exports-v5-4-6191773fc977@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Emit nova-core's crate metadata (libnova_core.rmeta) so that nova-drm
can import nova-core's types and functions at compile time.
This is intended to be a workaround until the build system supports Rust
cross-crate dependencies natively.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260622-nova-exports-v5-3-6191773fc977@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Export nova-core's Rust symbols so nova-drm can resolve references to it
when loaded as a module.
This is done by generating declarations and EXPORT_SYMBOL_RUST_GPL()
calls for Rust symbols referenced by nova-drm, and compiling them into
the module as `nova_core_exports.o`.
`nova_core_exports.o` declares every Rust symbol as `extern int`.
Running `gendwarfksyms` on it would compute CRCs from those placeholder
types instead of the real Rust ones, so make MODVERSIONS use this shim
only for the export list, and derive CRCs from `nova_core.o`.
This patch is intended to be a workaround until the build system
supports Rust cross-crate dependencies natively.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260622-nova-exports-v5-2-6191773fc977@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
A dependency between nova-core and nova-drm is about to be introduced,
which requires nova-core to be built first. As this is not easily doable
from separate directories, move both build targets to the first common
parent, `drivers/gpu/Makefile`.
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260622-nova-exports-v5-1-6191773fc977@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Switch RTC platform device registration from platform_device_register()
to platform_add_devices() so as to make sure any failure will result in
automatic device unregistration.
Fixes: fae67ad431 ("arch/mips/dec: switch DECstation systems to rtc-cmos")
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
lg_g15_data is allocated with devm and holds a work item. The report
handlers schedule that work straight from device input.
lg_g15_event() and lg_g15_v2_event() do it on the backlight cycle key,
and lg_g510_leds_event() does it too. The worker dereferences the
lg_g15_data back through container_of.
The driver had no remove callback and never cancelled the work. So if a
report scheduled the work and the keyboard was then unplugged, devres
freed lg_g15_data while the work was still pending or running, and the
worker touched freed memory. This is a use-after-free. It is reachable
as a race on device unplug.
Add a remove callback that cancels the work before devres frees the
state. g15->work is only initialized for the models that schedule it
(G15, G15 v2, G510). The G13 and Z-10 leave it zeroed, so guard the
cancel on g15->work.func to avoid cancelling a work that was never set
up. The g15 NULL test mirrors the one already in lg_g15_raw_event().
Fixes: 97b741aba9 ("HID: lg-g15: Add keyboard and LCD backlight control")
Cc: stable@vger.kernel.org
Suggested-by: Hans de Goede <hansg@kernel.org>
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Commit b6a5791285 ("HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT
related user initiated OOB write") added validation for the DJ short
output report, but the error path dereferences rep->field[0] even when
rep->maxfield is zero.
Commit 8b9a097eb2 ("HID: logitech-dj: fix wrong detection of bad
DJ_SHORT output report") made the check conditional on rep being present,
but a crafted descriptor can still create report ID 0x20 with only padding
output items. hid-core registers the report, ignores the padding field,
and leaves rep->maxfield as zero.
In that case the validation enters the rep->maxfield < 1 branch and then
dereferences rep->field[0]->report_count while printing the error message,
causing a NULL pointer dereference during probe. This is reproducible with
uhid by emulating a Logitech receiver with a padding-only DJ short output
report:
BUG: KASAN: null-ptr-deref in logi_dj_probe+0xb1/0x754 [hid_logitech_dj]
Read of size 4 at addr 0000000000000028 by task kworker/4:1/129
...
Call Trace:
logi_dj_probe+0xb1/0x754 [hid_logitech_dj]
hid_device_probe+0x329/0x3f0 [hid]
really_probe+0x162/0x570
__device_attach+0x137/0x2c0
bus_probe_device+0x38/0xc0
device_add+0xa56/0xce0
hid_add_device+0x19c/0x280 [hid]
uhid_device_add_worker+0x2c/0xb0 [uhid]
Reject the zero-field report before printing the field report_count.
Fixes: b6a5791285 ("HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB write")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Replace sequences of of_machine_is_compatible() calls by single calls to
the of_machine_compatible_match() helper, to simplify the code, and to
reduce code size.
Note that this does have a slight performance impact on matching
platforms: while the C sequences terminated evaluation after a match,
(internal) of_device_compatible_match() calculates a matching score, and
thus always checks against all passed compatible values.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/2230eb28da9b8d8bdee4e4fd7e19dc8f074531bc.1780499233.git.geert+renesas@glider.be
Drive kone_keep_values_up_to_date() with a crafted switch-profile event;
an out-of-range value reads past profiles[] (KASAN slab-out-of-bounds on
an unpatched tree). A benign control with an in-range value exercises the
same path. The test object is sized to end at profiles[] so the over-read
lands in the KASAN redzone.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
kone_keep_values_up_to_date() and kone_profile_activated() use an
8-bit, device-supplied profile value as an index into the 5-element
kone->profiles[] array without a range check. A malicious USB device
claiming the Roccat Kone id can send a switch-profile event (or a
startup_profile read at probe) with an out-of-range value and make the
driver read out of bounds; the result is exposed via the actual_dpi
sysfs attribute.
Reject out-of-range indices in both paths.
This was found with static analysis and confirmed with the KUnit test
added in the following patch (KASAN: slab-out-of-bounds).
Fixes: 14bf62cde7 ("HID: add driver for Roccat Kone gaming mouse")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Using devm_kasprintf() makes the code less error-prone.
Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
The sony_worker enum only had a single member, so removing it simplifies
sony_schedule_work().
Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
This replaces the spin_lock_irqsave() and spin_unlock_irqrestore() calls
with the RAII guard() and scoped_guard().
Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
This commit changes the way sony_raw_event() works by adding a function
pointer to a raw_event() handler in the sc struct instead of manually
checking the quirk in order to call the right function, this simplifies
the sony_raw_event() function alongside making the raw_event() handlers
more self-contained, thus making the code more readable.
The raw_event() handler should be configured using the new
sony_init_raw_event_handler() function in sony_input_configured(), where
we already check for quirks and apply device specific workarounds.
Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
When a caller passes a size of 0 to hid_report_raw_event() for a
numbered report, the function originally called hid_get_report() before
performing any size validation.
Inside hid_get_report(), if the report is numbered (report_enum->numbered
is true), it unconditionally dereferences data[0] to extract the report ID.
With a size of 0, this results in an out-of-bounds read or kernel panic.
Fix this by moving the numbered report size validation check before the
call to hid_get_report(), ensuring that size is at least 1 before
dereferencing the data pointer.
Fixes: 2c85c61d13 ("HID: pass the buffer size to hid_report_raw_event")
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
