Dinh Nguyen [Thu, 21 May 2026 02:54:57 +0000 (21:54 -0500)]
firmware: stratix10-rsu: Fix NULL deref on rsu_send_msg() timeout in probe
rsu_send_msg() can return -ETIMEDOUT when
wait_for_completion_interruptible_timeout() fires while the SMC call is still
pending. In stratix10_rsu_probe(), the error paths for COMMAND_RSU_DCMF_VERSION,
COMMAND_RSU_DCMF_STATUS, COMMAND_RSU_MAX_RETRY and COMMAND_RSU_GET_SPT_TABLE
call stratix10_svc_free_channel() - which sets chan->scl to NULL - but then
fall through and queue the next request on the same channel. The next svc
kthread that runs will dereference pdata->chan->scl in its receive callback
path, triggering a NULL pointer dereference identical to the one fixed by
commit c45f7263100c ("firmware: stratix10-rsu: Fix NULL pointer dereference
when RSU is disabled") for the COMMAND_RSU_STATUS path.
Apply the same cleanup pattern to the remaining failure paths: remove the
async client, free the channel, and return early so no further messages are
queued on a channel whose scl has been cleared.
While at it, clean up stratix10_rsu_probe() in two ways without changing
behavior:
- Drop redundant zero-initialization of fields already cleared by
devm_kzalloc(): client.receive_cb, status.* and spt0/1_address
(INVALID_SPT_ADDRESS is 0x0).
- Replace five identical 3-line error-cleanup blocks
(stratix10_svc_remove_async_client() + stratix10_svc_free_channel() +
return ret) with goto labels (remove_async_client, free_channel),
matching the standard kernel resource-unwinding pattern and making it
easier to extend the probe sequence without forgetting matching
cleanup.
Also move init_completion() next to mutex_init() so sync-primitive
initialization is grouped before anything that could trigger a
callback.
Fixes: 15847537b623 ("firmware: stratix10-rsu: Migrate RSU driver to use stratix10 asynchronous framework.") Cc: stable@kernel.org Assisted-by: Claude:claude-4.7-opus-high Cursor Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
v2: Add a minor clean-up of the function stratix10_rsu_probe() to have a
centralize exit for all the rsu_send_async_msg() and rsu_send_msg().
firmware: stratix10-svc: Don't fail probe when async ops unsupported
When the ATF version is too old to support SIP SVC v3 asynchronous
operations (e.g. ATF 2.5), stratix10_svc_async_init() returns
-EOPNOTSUPP. The probe function currently treats any non-zero return
as fatal and aborts, logging:
stratix10-svc firmware:svc: Intel Service Layer Driver: ATF version \
is not compatible for async operation
stratix10-svc firmware:svc: probe with driver stratix10-svc failed \
with error -95
This prevents the SVC driver from loading entirely, causing all
dependent client drivers (hwmon, RSU, FCS) to also fail to probe even
though they can operate correctly via the synchronous V1 SMC path.
Fix this by treating -EOPNOTSUPP from stratix10_svc_async_init() as a
non-fatal degraded condition. The driver loads in sync-only mode and
logs:
stratix10-svc firmware:svc: Intel Service Layer Driver Initialized \
(sync-only mode)
Fixes: bcb9f4f07061 ("firmware: stratix10-svc: Add support for async communication") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Amirul Asyraf Mohamad Jamian <muhammad.amirul.asyraf.mohamad.jamian@altera.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
firmware: stratix10-svc: Return -EOPNOTSUPP when ATF async unsupported
Add a 'supported' flag to struct stratix10_async_ctrl to indicate
whether the secure firmware supports SIP SVC v3 asynchronous
communication. When the ATF version check in stratix10_svc_async_init()
fails, set supported=false and return -EOPNOTSUPP instead of -EINVAL.
This allows callers to distinguish between "async not supported by this
ATF version" (-EOPNOTSUPP) and "programming error / bad argument"
(-EINVAL), and take appropriate action (e.g. fall back to synchronous
V1 SMC path) rather than treating both as fatal.
Also update stratix10_svc_add_async_client() to return -EOPNOTSUPP
immediately when async is not supported, rather than -EINVAL from the
!actrl->initialized check, so client drivers receive a consistent and
meaningful error code.
This patch is a prerequisite for the following fix and must be applied
together with it to correctly restore functionality on old ATF versions.
Fixes: bcb9f4f07061 ("firmware: stratix10-svc: Add support for async communication") Cc: stable@vger.kernel.org Suggested-by: Anders Hedlund <anders.hedlund@windriver.com> Signed-off-by: Mahesh Rao <mahesh.rao@altera.com> Signed-off-by: Muhammad Amirul Asyraf Mohamad Jamian <muhammad.amirul.asyraf.mohamad.jamian@altera.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Chen Ni [Fri, 22 May 2026 01:57:34 +0000 (09:57 +0800)]
media: ti: j721e-csi2rx: Fix error handling for media_entity_remote_source_pad_unique()
The media_entity_remote_source_pad_unique() function returns an error
pointer on failure, not NULL. Fix the check to use IS_ERR() and return
PTR_ERR() to correctly handle allocation failures.
Fixes: 982135c0eac6 ("media: ti: j721e-csi2rx: add a subdev for the core device") Fixes: 3ed9c0a1fdba ("media: ti: j721e-csi2rx: add multistream support") Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
media: ti: j721e-csi2rx: Minor cleanup of loop variables
Replace open-coded `i--; for (; i >= 0; i--)` patterns with the
idiomatic `while (i--)` in the error unwind paths of
csi_async_notifier_complete() and ti_csi2rx_probe().
Also scope loop variables directly in the for statement instead of
declaring them at the top of the function in ti_csi2rx_suspend(),
ti_csi2rx_resume() and ti_csi2rx_remove(). Change the type to
unsigned int in the first two to match csi->num_ctx.
Signed-off-by: Rishikesh Donadkar <r-donadkar@ti.com> Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Miguel Vadillo [Wed, 27 May 2026 17:05:30 +0000 (10:05 -0700)]
media: pci: intel: Add CVS support for IPU bridge driver
CVS is located between IPU device and sensors and is available in
existing commercial platforms from multiple OEMs. The connection
information between them in firmware is not enough to build a V4L2
connection graph. This patch parses the connection properties from the
SSDB buffer in DSDT and builds the connection using software nodes.
From the IPU bridge point of view, CVS is just like IVSC.
Signed-off-by: Miguel Vadillo <miguel.vadillo@intel.com> Tested-by: Mehdi Djait <mehdi.djait@linux.intel.com> # Dell XPS 13 9350 + IPU7 Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Add driver for Intel Computer Vision Sensing (CVS) devices found on
Intel Luna Lake (LNL), Panther Lake (PTL), and Arrow Lake (ARL)
platforms.
The CVS device acts as a V4L2 sub-device bridge that manages CSI-2
link ownership between the host (Linux) and firmware for camera
sensors. It provides:
- Query the device status via sysfs interface
- CSI-2 link ownership arbitration between host and CVS firmware
- MIPI CSI-2 configuration management
- Privacy LED control coordination
- Power management integration with runtime PM
The driver consists of two main components:
core.c: Core driver with probe, command transport, and power management
v4l2.c: V4L2 sub-device and media framework integration
Hardware Interface:
- I2C for command/control communication with device firmware
- GPIO signals for ownership handshaking (request/response)
- Optional reset and wake interrupt for full-capability variants
- Integration with Intel IPU via ipu_bridge
The driver supports two hardware capability levels:
- Light capability: Basic GPIO-based ownership (2 GPIOs)
- Full capability: Enhanced with reset control and wake IRQ (4 GPIOs)
Device-specific quirks are handled via a quirk table to accommodate
variations across different CVS implementations (Lattice, Synaptics).
In addition to I2C-based operation, the driver supports platform
device instantiation for systems where CVS is exposed without I2C
transport, falling back to GPIO-only ownership control.
The CVS driver integrates with the IPU bridge for automatic device
discovery via ACPI on supported platforms.
PCI device IDs for Intel IPU7 (0x645d, shared by MTL and LNL) and
IPU7.5 (0xb05d, shared by ARL and PTL) are included in the
driver-local icvs_pci_tbl lookup table, enabling CVS to locate these
IPU variants without modifying the shared ipu6-pci-table header.
A PM runtime device link is established between IPU (consumer) and CVS
(supplier) so that the PM framework automatically resumes CVS before
IPU begins streaming, triggering cvs_runtime_resume() to claim CSI-2
link ownership. Ownership is released via cvs_runtime_suspend() after
the autosuspend delay.
Signed-off-by: Miguel Vadillo <miguel.vadillo@intel.com> Tested-by: Mehdi Djait <mehdi.djait@linux.intel.com> # Dell XPS 13 9350 + IPU7 Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Mark Brown [Thu, 28 May 2026 18:12:52 +0000 (19:12 +0100)]
ASoC: Intel: catpt: Error handling and debug improvements
Cezary Rojewski <cezary.rojewski@intel.com> says:
Outcome of a long debug to solve one, long-standing bug ocurring very
rarely on Haswell/Broadwell machines during the boot procedure of the
AudioDSP firmware. Clever/unfortunate user can increase the
reproduction rare to 100%.
The bug: an exception occurring early during FW boot (firmware side, not
the software one) leaves the firmware hanging and the existing software
code is incappable of recognizing such problem. The only solution a
user currently has is: rmmod and then modprobe the driver.
Recently, together with Krzysztof from the firmware team decided to take
it up and clear the dashboard.
The exception handling takes just a few lines of code (all part of the
first patch), everything else that this patchset is composed of improves
the debugability and logging. If anything similar pops up, the
developers can see what's going on.
Cezary Rojewski [Thu, 28 May 2026 08:34:42 +0000 (10:34 +0200)]
ASoC: Intel: catpt: Complete coredump handling
An exception may occur during the firmware booting procedure. In such
case the firmware sends COREDUMP_REQUESTS and expects the driver to dump
relevant information and finish with the COREDUMP_RELEASE write.
To distinguish such situation from generic timeout, always signal
fw_ready completion when a coredump request is received and translate
it to -EREMOTEIO in catpt_boot_firmware().
The "FW READY" print makes the success clearly visible even when
the event-traces are not enabled.
Since commit fe49fd940e22 ("KVM: arm64: Move VTCR_EL2 into struct s2_mmu"),
@arch is no longer required to obtain the per-kvm_s2_mmu vtcr and can be
removed from __load_stage2().
Timur Tabi [Thu, 30 Apr 2026 22:38:37 +0000 (17:38 -0500)]
drm/nouveau/gsp: require GSP-RM for GA100 support
Nouveau supports Turing and Ampere GPUs with or without GSP-RM.
Support without GSP-RM is mostly academic, since GSP-RM is
needed to run the GPU at full clocks. It is also the default
mode for these GPUs.
GA100 is a special case, however. The current code has some support
for running GA100 without GSP-RM, but several features are missing.
More importantly, some required firmware images like ucode_ahesasc.bin
are not available and would need to be provided by Nvidia.
To prevent Nouveau from even trying to boot on GA100 without GSP-RM,
remove the non-GSP fallback option in the ga100_gsps[] array.
Timur Tabi [Thu, 30 Apr 2026 22:38:36 +0000 (17:38 -0500)]
drm/nouveau/bios: skip the IFR header if present
The GPU's ROM may begin with an Init-from-ROM (IFR) header that precedes
the PCI Expansion ROM images (VBIOS). When present, the PROM shadow
method must parse this header to determine the offset where the PCI ROM
images actually begin, and adjust all subsequent reads accordingly.
On most GPUs this is not needed because either the PRAMIN shadow method
(which reads from VRAM via the display engine) succeeds first, or the IFR
microcode has already applied the ROM offset so that PROM reads
transparently skip the header. However, on GA100 neither of these
applies: GA100 has no display engine (so PRAMIN is unavailable), and the
IFR offset is not applied to PROM reads on this GPU.
Timur Tabi [Thu, 30 Apr 2026 22:38:35 +0000 (17:38 -0500)]
drm/nouveau/bios: specify correct display fuse register for Ampere and Ada
The NV_FUSE_STATUS_OPT_DISPLAY register is used to determine whether
the GPU has display hardware. The current code that normally reads
this register is instead hard-coded to check for GA100 vs later GPUs.
Since this function is called only on pre-Hopper GPUs, and this
if-statement applies only to GA100 and later, the check works
because GA100 is the only non-display Ampere and Ada GPU.
However, there actually is a register that can be read, so we should
use it.
Fixes: a34632482f1e ("drm/nouveau/bios/ga10[024]: initial support") Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260430223838.2530778-8-ttabi@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Timur Tabi [Thu, 30 Apr 2026 22:38:34 +0000 (17:38 -0500)]
drm/nouveau: GA100 has an FRTS region size of zero
When booting with GSP-RM, the FRTS data region normally needs to be
allocated. However, on GA100, this region is not used and so its
size needs to be set to zero.
The truth is that GA100 is just special, and the simplest way to
determine the proper FRTS data region size is to check for this
GPU specifically.
Timur Tabi [Thu, 30 Apr 2026 22:38:32 +0000 (17:38 -0500)]
drm/nouveau/gsp: read MMU_LOCK to fix WPR placement on GA100
On GA100, the row remapper hardware reserves a small amount of DRAM at
the end of framebuffer for spare rows used to repair memory errors at
runtime. When an uncorrectable ECC error is detected in a DRAM row,
the row remapper redirects accesses to a spare row, transparently
repairing the fault.
The LOCAL_MEMORY_RANGE register (0x100ce0) reports the GPU's FB address
range, but its encoding rounds to 1GB boundaries. On GA100, VBIOS
originally rounded this value down, which could lose up to ~1GB of
usable FB. As a workaround, newer VBIOS instead rounds up to the next
1GB boundary and programs MMU_LOCK (registers 0x1fa82c/0x1fa830) to
mark the gap between the actual usable FB and the rounded-up range as
reserved.
OpenRM's kgspCalculateFbLayout_TU102() handles this by reading the
MMU_LOCK registers and computing the WPR top boundary as:
Without this, the WPR region is placed at the top of LOCAL_MEMORY_RANGE,
which overlaps the reserved region. The booter firmware detects this
and rejects the WPR layout.
Add ga100_gsp_mmu_lock_lo() to read the MMU_LOCK range and clamp
gsp->fb.bios.addr accordingly, mirroring OpenRM's behavior.
This is a GA100-only issue. GA102 and later add the
NV_USABLE_FB_SIZE_IN_MB register which reports the correct usable FB
size directly, eliminating the need for the MMU_LOCK workaround.
The VGA workspace offset is one input into this calculation, not the
direct source of gspFwWprEnd. vbiosReservedOffset is the effective
top boundary for WPR2 placement, and it may be lower than the VGA
workspace when VBIOS has locked a region via MMU_LOCK.
In Nouveau, gsp->fb.bios.addr is the equivalent of vbiosReservedOffset,
while gsp->fb.bios.vga_workspace.addr corresponds to the raw VGA
workspace location. The original code assigned vga_workspace.addr to
gspFwWprEnd, which produced the correct result only because bios.addr
was always set equal to vga_workspace.addr and never adjusted.
Use gsp->fb.bios.addr for gspFwWprEnd to correctly mirror OpenRM's
layout logic, so that future adjustments to bios.addr (such as clamping
it to an MMU_LOCK boundary) are properly reflected in the WPR metadata
passed to the booter.
Timur Tabi [Thu, 30 Apr 2026 22:38:30 +0000 (17:38 -0500)]
drm/nouveau/gsp: add SEC2 to GA100 chip table
The booter-load and booter-unload firmware run on the SEC2 falcon.
During tu102_gsp_oneinit(), the booter constructor needs device->sec2
to access the SEC2 falcon.
Without the .sec2 entry, device->sec2 is NULL and this dereference
crashes during GSP-RM boot.
scripts: modpost: detect and report truncated buf_printf() output
buf_printf() uses a fixed-size stack buffer. vsnprintf() returns the
number of bytes that *would* have been written to that buffer, which can
be larger than the size of said buffer if the formatted string is too
long.
The problem is that whenever this happens buf_printf() currently passes
this length, unchecked, to buf_write(), which silently reads past the
stack buffer and copies invalid data into the output buffer.
Fix this by detecting vsnprintf() failures and truncations before
appending to the output buffer, and report a fatal error instead of
producing corrupt symbol names.
Yafang Shao [Tue, 26 May 2026 06:27:32 +0000 (14:27 +0800)]
kbuild: rpm-pkg: append %{?dist} macro to Release tag
Add support for the %{?dist} macro in the kernel.spec file. This enables
building and releasing kernel RPMs with a custom distribution suffix
(e.g., via rpmbuild's --define option) to better match production
environment tracking.
Hongling Zeng [Thu, 28 May 2026 06:24:50 +0000 (14:24 +0800)]
nouveau/gsp/rm: cleanup WARN_ON(IS_ERR_OR_NULL)
Replace WARN_ON(IS_ERR_OR_NULL()) with WARN_ON(IS_ERR()) in various
GSP-RM files. The underlying functions return error pointers, so
checking for NULL is redundant.
This affects:
- r535_bar_bar2_update_pde() in bar.c
Hongling Zeng [Thu, 28 May 2026 06:24:49 +0000 (14:24 +0800)]
nouveau/gsp/rm: cleanup IS_ERR_OR_NULL in core implementation
Clean up IS_ERR_OR_NULL() checks in the core RPC and alloc
implementation files. The underlying functions return error pointers,
so IS_ERR() is sufficient.
This affects:
- r535_gsp_rpc_rm_free() in alloc.c
- r535_gsp_rpc_rm_alloc_push() in alloc.c
- r535_gsp_msgq_recv() in rpc.c
Zhan Xusheng [Tue, 26 May 2026 02:21:06 +0000 (10:21 +0800)]
timers/migration: Update stale @online doc to @available
Commit 8312cab5ff47 ("timers/migration: Rename 'online' bit to
'available'") renamed the 'online' field of struct tmigr_cpu to
'available'. The kernel doc comment above the struct still describes the
old field name.
Update it to reflect the actual field name and use the 'available' wording
in the description.
Lee Jones [Wed, 27 May 2026 16:05:26 +0000 (17:05 +0100)]
HID: wacom: Fix OOB write in wacom_hid_set_device_mode()
wacom_hid_set_device_mode() currently assumes that the HID_DG_INPUTMODE
usage is always located in the first field (field[0]) of the feature report.
However, a device can specify HID_DG_INPUTMODE in a different field.
If HID_DG_INPUTMODE is in a field other than the first one and the first
field has a report_count smaller than the usage_index of HID_DG_INPUTMODE,
this leads to an out-of-bounds write to r->field[0]->value.
Fix this by storing the field index of HID_DG_INPUTMODE in 'struct
hid_data' during feature mapping. In wacom_hid_set_device_mode(), use
this stored field index to access the correct field and add bounds
checks to ensure both the field index and the value index are within
valid ranges before writing.
Cc: stable@vger.kernel.org Fixes: 5ae6e89f7409 ("HID: wacom: implement the finger part of the HID generic handling") Tested-by: Ping Cheng <ping.cheng@wacom.com> Reviewed-by: Ping Cheng <ping.cheng@wacom.com> Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Ren Tamura [Thu, 28 May 2026 04:28:39 +0000 (13:28 +0900)]
cgroup: pair max limit READ_ONCE() with WRITE_ONCE()
cgroup.max.descendants and cgroup.max.depth are shown through seq_file.
Their show callbacks read cgrp->max_descendants and cgrp->max_depth with
READ_ONCE(), respectively.
The corresponding write callbacks update the same scalar fields while
holding the cgroup lock, but the seq_file show path does not serialize
against those stores. This leaves the lockless show-side loads annotated
with READ_ONCE(), while the corresponding stores remain plain stores.
Use WRITE_ONCE() for the updates so the intended lockless access is marked
consistently on both sides. This does not change locking, ordering, or
user-visible semantics.
Jinjie Ruan [Wed, 6 May 2026 17:52:05 +0000 (13:52 -0400)]
arch/riscv: Add bitrev.h file to support rev8 and brev8
The RISC-V Bit-manipulation Extension for Cryptography (Zbkb) provides
the 'brev8' instruction, which reverses the bits within each byte.
Combined with the 'rev8' instruction (from Zbb or Zbkb), which reverses
the byte order of a register, we can efficiently implement 16-bit,
32-bit, and (on RV64) 64-bit bit reversal.
This is significantly faster than the default software table-lookup
implementation in lib/bitrev.c, as it replaces memory accesses and
multiple arithmetic operations with just two or three hardware
instructions.
Select HAVE_ARCH_BITREVERSE as well as GENERIC_BITREVERSE,
and provide <asm/bitrev.h> to utilize these instructions when
the Zbkb extension is available at runtime via the alternatives
mechanism.
[Yury: select the options conditionally on BITREVERSE]
Yury Norov [Wed, 6 May 2026 17:52:03 +0000 (13:52 -0400)]
lib/bitrev: Introduce GENERIC_BITREVERSE
The generic bit reversal implementation is controlled by
!HAVE_ARCH_BITREVERSE. This makes it difficult for architectures to
provide a hardware-accelerated implementation while being able to
fall back to the generic version if needed.
This patch adds GENERIC_BITREVERSE, so bitreverse API is controlled by
BITREVERSE, GENERIC_BITREVERSE and HAVE_ARCH_BITREVERSE options. The
relationship between them is described as follows:
- BITREVERSE is selected by user code; it's required to generate the API;
- Architectures may select HAVE_ARCH_BITREVERSE and provide an arch
implementation in arch/$(ARCH)/include/asm/bitrev.h.
- if HAVE_ARCH_BITREVERSE isn't set, BITREVERSE selects GENERIC_BITREVERSE;
- if GENERIC_BITREVERSE is set and HAVE_ARCH_BITREVERSE is not, the kernel
provides generic implementation only, and wires bitrevXX() to it.
- if HAVE_ARCH_BITREVERSE is set and GENERIC_BITREVERSE is not, the arch
code provides __arch_bitrevXX(), and it is wired to bitrevXX();
- if both GENERIC_BITREVERSE and HAVE_ARCH_BITREVERSE are selected, the kernel
generates generic___bitrev(), but wires bitrev() to the __arch_bitrev().
The last option allows architectures to use generic___bitrev() as a
fallback option.
Drivers and core code should never select GENERIC_BITREVERSE or
HAVE_ARCH_BITREVERSE explicitly.
Architectures that require generic bitreverse API as a fallback should
explicitly enable GENERIC_BITREVERSE together with HAVE_ARCH_BITREVERSE.
Yury Norov [Wed, 6 May 2026 17:52:02 +0000 (13:52 -0400)]
arch: select HAVE_ARCH_BITREVERSE conditionally on BITREVERSE
Architectures may have bit reversal instructions, but if the API not
needed, the corresponding option should not be selected because it may
lead to generating the unneeded code.
Yury Norov [Thu, 21 May 2026 16:03:45 +0000 (12:03 -0400)]
bitmap: fix find helper documentation
find_nth_and_bit() and find_nth_and_andnot_bit() may return a value
greater than @size when the requested bit does not exist, matching
find_nth_bit(). Document that correctly. All current users are safe
against the '>=' vs '==' conditions.
Also fix the for_each_clear_bitrange_from() parameter descriptions so
they describe clear ranges instead of set ranges.
Keith Busch [Thu, 28 May 2026 01:00:40 +0000 (18:00 -0700)]
block: export passthrough stats enabled
A user can enable io accounting for passthrough requests, so export the
helper that checks if the request should be tracked. This will enable
stacking drivers to to report iostats for passthrough workloads. Since
the stacking request_queue may not be the one providing the request, the
API has to add a parameter for the caller to specify which one to check.
Mikko Perttunen [Tue, 21 Apr 2026 04:02:37 +0000 (13:02 +0900)]
drm/tegra: Fix iommu_map_sgtable() return value check
Commit "iommu: return full error code from iommu_map_sg[_atomic]()"
changed iommu_map_sgtable() to return an ssize_t and negative values
in error cases, rather than a size_t and a zero.
Update tegra_bo_iommu_map() to correctly check for errors from
iommu_map_sgtable.
Mikko Perttunen [Tue, 21 Apr 2026 04:02:36 +0000 (13:02 +0900)]
gpu: host1x: Fix iommu_map_sgtable() return value check
Commit "iommu: return full error code from iommu_map_sg[_atomic]()"
changed iommu_map_sgtable() to return an ssize_t and negative values
in error cases, rather than a size_t and a zero.
pin_job() also was incorrectly assigning to 'int', which could cause
overflows into negative values.
Update pin_job() to correctly check for errors from iommu_map_sgtable.
The drivers/gpu/host1x/context_bus.c does not include any declaration of
host1x_context_device_bus_type, and after including "context.h" it also
showed that there are two definitions in the kernel because the extern
declaration was missing the const qualifier.
Include linux/host1x_context_bus.h and drop the wrong declaration from
context.h. While at it, also predeclare struct host1x_memory_context.
Fixes the following sparse warning:
drivers/gpu/host1x/context_bus.c:9:23: warning: symbol 'host1x_context_device_bus_type' was not declared. Should it be static?
Felix Gu [Tue, 27 Jan 2026 16:43:10 +0000 (00:43 +0800)]
drm/tegra: dc: Fix device node reference leak in tegra_dc_has_output()
The of_for_each_phandle() macro increments the reference count of the
device node it iterates over. If the loop exits early, the reference must
be released manually.
In tegra_dc_has_output(), the function returns true immediately when a
match is found, failing to release the current node's reference.
Fix this by adding a call to of_node_put() before returning from the loop.
Without the cmu, nvdisplay will display colors that are notably darker
than intended. The vendor bootloader and the downstream display driver
enable the cmu and sets a sRGB table. Loading that table here results in
the intended colors.
Co-developed-by: Kurt Kiefer <kekiefer@gmail.com> Signed-off-by: Kurt Kiefer <kekiefer@gmail.com> Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Tested-by: Jasper Korten <jja2000@gmail.com> Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com> Tested-by: Mikko Perttunen <mperttunen@nvidia.com> # Jetson AGX Xavier Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260407-tegra-drm-cmu-v4-1-2fe95f305afd@gmail.com
Guangshuo Li [Mon, 13 Apr 2026 14:15:26 +0000 (22:15 +0800)]
gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error path
After device_initialize(), the embedded struct device in struct
host1x_device should be released through the device core with
put_device().
In host1x_device_add(), if host1x_device_parse_dt() fails, the current
error path frees the object directly with kfree(device). That bypasses
the normal device lifetime handling and leaks the reference held on the
embedded struct device.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fix this by using put_device() in the host1x_device_parse_dt() failure
path.
Fixes: f4c5cf88fbd50 ("gpu: host1x: Provide a proper struct bus_type") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Acked-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260413141526.2961841-1-lgs201920130244@gmail.com
drm/tegra: Make tegra_fb_alloc() an internal interface
Fbdev framebuffer allocation now goes through the regular ioctl call
chain. This makes tegra_fb_alloc() an internal helper function. Declare
it as static.
Replace the internal DRM framebuffer with a DRM client buffer. The
client buffer allocates the DRM framebuffer on a file and also uses
GEM object handles via the regular ADDFB2 interfaces.
Using client-buffer interfaces unifies framebuffer allocation for
DRM clients in user space and tegra's internal fbdev emulation. It
also simplifies the clean-up side of the fbdev emulation.
drm/tegra: fbdev: Calculate buffer geometry with format helpers
Replace the geometry and size calculation in tegra's fbdev emulation
with DRM format helpers. This consists of a 4CC lookup from the fbdev
parameters, format lookup, pitch calculation and size calculation.
Then allocate the GEM buffer object for the framebuffer memory from
the calculated size.
Set up mode_cmd with the calculated values just before allocating the
framebuffer. This code will later be replaced with a DRM client buffer.
Set framebuffer size fields in struct fb_info from the size stored in
the GEM buffer object instead of what has been requested. The requested
size is an estimate, while the buffer size is the exact value rounded
to the correct alignment.
drm/tegra: fbdev: Remove offset into framebuffer memory
The screen_buffer field in struct fb_info contains the kernel address
of the first byte of framebuffer memory. Do not add the display offset.
This offset only describes scrolling during scanout.
Randy Dunlap [Mon, 27 Apr 2026 18:44:54 +0000 (11:44 -0700)]
drm/tegra: tegra_drm.h: fix all uapi kernel-doc warnings
Add 2 struct member descriptions and convert #define macro constants
comments to kernel-doc comments to eliminate all kernel-doc warnings:
Warning: include/uapi/drm/tegra_drm.h:353 struct member 'cmdbuf' not
described in 'drm_tegra_reloc'
Warning: include/uapi/drm/tegra_drm.h:353 struct member 'target' not
described in 'drm_tegra_reloc'
Warning: include/uapi/drm/tegra_drm.h:780 This comment starts with '/**',
but isn't a kernel-doc comment.
* Specify that bit 39 of the patched-in address should be set to switch
Warning: include/uapi/drm/tegra_drm.h:832 This comment starts with '/**',
but isn't a kernel-doc comment.
* Execute `words` words of Host1x opcodes specified in the
`gather_data_ptr`
Warning: include/uapi/drm/tegra_drm.h:837 This comment starts with '/**',
but isn't a kernel-doc comment.
* Wait for a syncpoint to reach a value before continuing with further
Warning: include/uapi/drm/tegra_drm.h:842 This comment starts with '/**',
but isn't a kernel-doc comment.
* Wait for a syncpoint to reach a value before continuing with further
Randy Dunlap [Mon, 27 Apr 2026 18:44:42 +0000 (11:44 -0700)]
drm/tegra: dp: fix kernel-doc warnings in dp.h
Use correct kernel-doc format and add missing nested struct entries to
eliminate kernel-doc warnings:
Warning: drivers/gpu/drm/tegra/dp.h:28 Incorrect use of kernel-doc format:
* tps3_supported:
Warning: drivers/gpu/drm/tegra/dp.h:54 struct member 'tps3_supported'
not described in 'drm_dp_link_caps'
dp.h:73: warning: Function parameter or struct member 'apply_training'
not described in 'drm_dp_link_ops'
dp.h:73: warning: Function parameter or struct member 'configure'
not described in 'drm_dp_link_ops'
dp.h:160: warning: Excess struct member 'cr' description in 'drm_dp_link'
shayderrr [Sun, 17 May 2026 17:04:56 +0000 (12:04 -0500)]
host1x: bus: Fix missing ops null check in error teardown
In host1x_device_init(), the error teardown paths do not check
client->ops before dereferencing it, unlike the forward init paths
which correctly guard with 'client->ops &&'. This can result in a
NULL pointer dereference if client->ops is NULL.
Fix by adding the missing client->ops check in both the teardown
and teardown_late labels.
The helper drm_simple_encoder_init() is a trivial wrapper around
drm_encoder_init() that only provides a static drm_encoder_funcs with
.destroy set to drm_encoder_cleanup(). Open-code the initialization
with a driver-specific instance of drm_encoder_funcs and remove the
dependency on drm_simple_kms_helper.
Suggested-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Souradipto Das <souradiptodas6@gmail.com>
[treding@nvidia.com: fix issues flagged by checkpatch] Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260513100501.6468-1-souradiptodas6@gmail.com
Tanmay Patil [Thu, 14 May 2026 10:31:53 +0000 (10:31 +0000)]
gpu: host1x: Skip redundant HW state update
When the fence list is empty, host1x_intr_update_hw_state()
falls through to host1x_intr_disable_syncpt_intr()
which does two MMIO writes to disable the syncpoint
interrupt and clear its status.
The ISR has already disabled and acked the interrupt
before calling host1x_intr_handle_interrupt(), making
these two writes redundant. Skip the update_hw_state()
call if no fences remain.
Measured Syncpoint wait latency (50000 samples):
Average latency: 10.6 us -> 9.4 us
99.99 pct latency: 51.90 us -> 36.58 us
Tanmay Patil [Thu, 14 May 2026 10:31:52 +0000 (10:31 +0000)]
gpu: host1x: Skip redundant syncpoint loads in host1x_syncpt_wait()
In host1x_syncpt_wait(), the hardware syncpoint value was loaded
initially for expiry check, and then loaded a second time to
populate the caller's value pointer. Reuse a single load for
both purposes.
After dma_fence_wait_timeout(), the previous code reloaded the syncpoint
value for the expiry check, which is only required in the timeout case.
On success (i.e., return value > 0, or return value == 0 with zero
jiffies remaining), the ISR has already cached the value before
signaling the fence. The value pointer can therefore be populated using
the cached value using host1x_syncpt_read_min() without MMIO access.
Only the timeout path requires a fresh load, move host1x_syncpt_load()
under that path.
Measured Syncpoint wait latency (50000 samples):
Average latency: 12.2 us -> 10.6 us
99.99 pct latency: 62.96 us -> 51.90 us
Mikko Perttunen [Fri, 15 May 2026 02:34:51 +0000 (11:34 +0900)]
gpu: host1x: Allow entries in BO caches to be freed
When a buffer object is pinned via host1x_bo_pin() with a cache, the
resulting mapping is kept in the cache so it can be reused on subsequent
pins. Each mapping held a reference to the underlying host1x_bo (taken
in tegra_bo_pin / gather_bo_pin), so as long as a mapping was cached,
the bo itself could not be freed.
However, the only way to remove the cached mapping was through the free
path of the buffer object. This meant that if a bo got cached, it could
never get freed again.
Resolve the circularity by holding a weak reference to the bo from the
cache side. This is done by having the .pin callbacks not bump the bo's
refcount -- instead the common Host1x bo code does so, except for the
cache reference.
Also move the remove-cache-mapping-on-free code into a common function
inside Host1x code. This is only called from the TegraDRM GEM buffers
since those are the only ones that can be cached at the moment.
Ion Agorria [Sun, 17 May 2026 09:14:50 +0000 (12:14 +0300)]
drm/tegra: gr2d/gr3d: Contain PM in the gr*d_probe/gr*d_remove
The current power management configuration causes GR2G/GR3D to malfunction
after resume. Reconfigure all PM actions to be handled within the GR*D
probe and remove operations to address this.
Fixes: 62fa0a985e2c ("drm/tegra: Enable runtime PM during probe") Acked-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Ion Agorria <ion@agorria.com> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260517091450.46728-3-clamor95@gmail.com
Svyatoslav Ryhel [Sun, 17 May 2026 09:14:49 +0000 (12:14 +0300)]
drm/tegra: gr2d/gr3d: Initialize address register map before HOST1X client is registered
The host1x_client_register() function is called just prior to register map
initialization loop, making the device available to userspace. This may
result in userspace attempting to submits a job before the register map is
initialized. Address this by moving register initialization before host1x
client registration.
In cs_amp_devm_get_dell_ssidex() remove an unnecessary special case check
on -ENOENT that just returned -ENOENT. The other branch of the if()
statement returned the error, which would of course return -ENOENT if the
error was -ENOENT and so do exactly the same as the first branch.
The whole if statement is identical to just returning the original pointer
if it is an error value.
drm/panthor: Reduce padding in gems debugfs for refcount
The "gems" debugfs file is getting a little too wide for comfort. While
a lot of this is unavoidable due to the theoretical upper limits of
numbers here (e.g. size needs to be 16 chars because 2**48-1 in decimal
is 15 digits, plus one space for separation), the refcount column has a
decent 5 characters to be saved, as it can only ever contain a 10-digit
decimal number.
Reduce the refcount column's width to 11, which fulfils this requirement
with an additional space for separation.
David Carlier [Sat, 23 May 2026 18:14:46 +0000 (19:14 +0100)]
dma-buf: fix UAF in dma_buf_fd() tracepoint
Once FD_ADD() returns, the fd is live in the file descriptor table
and a thread sharing that table can close() it before DMA_BUF_TRACE()
runs. The close drops the last reference, __fput() frees the dma_buf,
and the tracepoint then dereferences dmabuf to take dmabuf->name_lock
-- slab-use-after-free.
Split FD_ADD() back into get_unused_fd_flags() + fd_install() and
emit the tracepoint between them. While the fdtable slot is reserved
with a NULL file pointer, a racing close() returns -EBADF without
entering __fput(), so the dma_buf stays alive across the trace. Same
approach as commit 2d76319c4cbb ("dma-buf: fix UAF in dma_buf_put()
tracepoint").
This undoes the FD_ADD() conversion done in commit 34dfce523c90
("dma: convert dma_buf_fd() to FD_ADD()"); FD_ADD() has no place to
hook the tracepoint safely.
Reported-by: syzbot+7f4987d0afb97dd090cb@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7f4987d0afb97dd090cb Fixes: 281a22631423 ("dma-buf: add some tracepoints to debug.") Cc: stable@vger.kernel.org # 7.0.x Signed-off-by: David Carlier <devnexen@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patch.msgid.link/20260523181446.69525-1-devnexen@gmail.com
regmap: reject volatile update_bits() in cache-only mode
Prevent _regmap_update_bits() from accessing hardware when the register
map is in cache-only mode.
Unlike regmap_raw_read() and _regmap_read(), the volatile
_regmap_update_bits() fast path bypasses the cache_only check. This can
result in unexpected hardware accesses while the device is suspended.
Return -EBUSY to ensure behavior is consistent with other cache-only
access paths.
drm/panthor: Implement evicted status for GEM objects
For fdinfo to be able to fill its evicted counter with data, panthor
needs to keep track of whether a GEM object has ever been reclaimed.
Just checking whether the pages are resident isn't enough, as newly
allocated objects also won't be resident.
Do this with a new atomic_t member on panthor_gem_object. It's increased
when an object gets evicted by the shrinker, and saturates at INT_MAX.
This means that once an object has been evicted at least once, its
reclaim counter will never return to 0.
Due to this, it's possible to distinguish evicted non-resident pages
from newly allocated non-resident pages by checking whether
reclaimed_count is != 0
Also add a new column and status flag to the panthor gems debugfs: the
column is the number of times an object has been evicted, whereas the
flag indicates whether it currently is evicted.
Runyu Xiao [Wed, 27 May 2026 17:22:03 +0000 (01:22 +0800)]
io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item
commit 10dc95939817 ("io_uring/io-wq: check IO_WQ_BIT_EXIT inside work
run loop") fixed the obvious case where io_worker_handle_work() took one
exit-bit snapshot before draining pending work, but the fix stops one
level too early.
io_worker_handle_work() now re-checks IO_WQ_BIT_EXIT in its outer work
run loop, yet it still snapshots that bit once before processing a whole
dependent linked-work chain. If io_wq_exit_start() sets IO_WQ_BIT_EXIT
after the first linked item has started, the remaining linked items can
still reuse stale do_kill = false, skip IO_WQ_WORK_CANCEL, and continue
running after exit has begun.
Move the check further inside, so it covers linked items too. Note: this
is a syzbot special as it loves setting up tons of slow linked work on
weird devices like msr that take forever to read, and immediately close
the ring. Exit then takes a long time.
liyouhong [Thu, 28 May 2026 02:49:36 +0000 (10:49 +0800)]
io_uring/kbuf: align legacy buffer add limit with MAX_BIDS_PER_BGID
io_provide_buffers_prep() accepts nbufs up to MAX_BIDS_PER_BGID, but
io_add_buffers() stops when bl->nbufs reaches USHRT_MAX. This makes the
effective add limit one lower than the validated limit.
Use MAX_BIDS_PER_BGID in the add-side boundary check so validation and
execution use the same limit, and update the comment to refer to the
actual limit constant.
Add a helper that sets bi_status and call bio_endio() as that is a very
common pattern and convert the core block code over to it.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Md Haris Iqbal <haris.iqbal@linux.dev> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Hannes Reinecke <hare@kernel.org> Link: https://patch.msgid.link/20260528084632.2505277-1-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
The macros are impossible to follow due to the lack of visual type
information and all the braces. Replace them with inline helpers to
improve on that. Because the calling conventions are a bit problematic
with a lot of passing structures by value, all the helpers are marked
as __always_inline so that they are force inlined.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Ming Lei <tom.leiming@gmail.com> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: Keith Busch <kbusch@kernel.org> Link: https://patch.msgid.link/20260527151043.2349900-4-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
Clang recently added support for -Wattribute-alias [1], which results in
the same warnings that necessitated commit bee20031772a ("disable
-Wattribute-alias warning for SYSCALL_DEFINEx()") for GCC.
kernel/time/itimer.c:325:1: error: alias and aliasee have different types 'long (unsigned int)' and 'long (typeof (__builtin_choose_expr((__builtin_types_compatible_p(typeof ((unsigned int)0), typeof (0LL)) || __builtin_types_compatible_p(typeof ((unsigned int)0), typeof (0ULL))), 0LL, 0L)))' (aka 'long (long)') [-Werror,-Wattribute-alias]
325 | SYSCALL_DEFINE1(alarm, unsigned int, seconds)
| ^
include/linux/syscalls.h:225:36: note: expanded from macro 'SYSCALL_DEFINE1'
225 | #define SYSCALL_DEFINE1(name, ...) SYSCALL_DEFINEx(1, _##name, __VA_ARGS__)
| ^
include/linux/syscalls.h:236:2: note: expanded from macro 'SYSCALL_DEFINEx'
236 | __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
| ^
include/linux/syscalls.h:251:18: note: expanded from macro '__SYSCALL_DEFINEx'
251 | __attribute__((alias(__stringify(__se_sys##name)))); \
| ^
kernel/time/itimer.c:325:1: note: aliasee is declared here
include/linux/syscalls.h:225:36: note: expanded from macro 'SYSCALL_DEFINE1'
225 | #define SYSCALL_DEFINE1(name, ...) SYSCALL_DEFINEx(1, _##name, __VA_ARGS__)
| ^
include/linux/syscalls.h:236:2: note: expanded from macro 'SYSCALL_DEFINEx'
236 | __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
| ^
include/linux/syscalls.h:255:18: note: expanded from macro '__SYSCALL_DEFINEx'
255 | asmlinkage long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
| ^
<scratch space>:16:1: note: expanded from here
16 | __se_sys_alarm
| ^
Disable the warnings in the same way for clang-23 and newer. Disable the
warning about unknown warning options to avoid breaking the build for
versions of clang-23 that do not have -Wattribute-alias, such as ones
deployed by vendors like Android or CI systems or when bisecting LLVM
between llvmorg-23-init and release/23.x.
Arnd Bergmann [Thu, 28 May 2026 13:31:47 +0000 (15:31 +0200)]
Merge tag 'qcomtee-fix-for-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee into arm/fixes
QCOMTEE fix for v7.1
Adding a missing va_end in early return qcomtee_object_user_init()
* tag 'qcomtee-fix-for-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee:
tee: qcomtee: add missing va_end in early return qcomtee_object_user_init()
Arnd Bergmann [Thu, 28 May 2026 13:28:19 +0000 (15:28 +0200)]
Merge tag 'optee-fix-for-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee into arm/fixes
OP-TEE fix for v7.1
Prevent possible use after free in supplicant communication.
* tag 'optee-fix-for-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee:
tee: optee: prevent use-after-free when the client exits before the supplicant
Marco Scardovi [Tue, 26 May 2026 17:02:46 +0000 (19:02 +0200)]
gpio: rockchip: teardown bugs and resource leaks
Address several teardown issues and resource leaks in the driver's remove
path and error handling:
1. Debounce clock reference leak: The debounce clock (bank->db_clk) is
obtained using of_clk_get() which increments the clock's reference
count, but clk_put() is never called. Register a devm action to
cleanly release it on unbind. Note that of_clk_get(..., 1) remains
necessary over devm_clk_get() because the DT binding does not define
clock-names, precluding name-based lookup.
2. Unregistered chained IRQ handler: The chained IRQ handler is not
disconnected in remove(). If a stray interrupt fires after the driver
is removed, the kernel attempts to execute a stale handler, leading
to a panic. Fix this by clearing the handler in remove().
3. IRQ domain leak: The linear IRQ domain and its generic chips are
allocated manually during probe but never removed. Remove the IRQ
domain during driver teardown to free the associated generic chips
and mappings.
Fixes: 936ee2675eee ("gpio/rockchip: add driver for rockchip gpio") Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Marco Scardovi <scardracs@disroot.org> Link: https://patch.msgid.link/20260526171050.12785-3-scardracs@disroot.org
[Bartosz: don't emit an error message on devres allocation failure] Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Marco Scardovi [Tue, 26 May 2026 17:02:45 +0000 (19:02 +0200)]
gpio: rockchip: convert bank->clk to devm_clk_get_enabled()
The bank->clk was previously obtained via of_clk_get() and manually
prepared/enabled. However, it was missing a corresponding clk_put() in
both the error paths and the remove function, leading to a reference leak.
Convert the allocation to devm_clk_get_enabled(), which also properly
propagates failures from clk_prepare_enable() that were previously ignored.
The GPIO bank device uses the same OF node as the previous of_clk_get()
call, so devm_clk_get_enabled(dev, NULL) correctly resolves the same
clock provider entry.
Fix the reference leak and simplify the code by removing the manual
clk_disable_unprepare() calls in the probe error paths and in the
remove function.
Fixes: 936ee2675eee ("gpio/rockchip: add driver for rockchip gpio") Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Marco Scardovi <scardracs@disroot.org> Link: https://patch.msgid.link/20260526171050.12785-2-scardracs@disroot.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Dan Carpenter [Mon, 25 May 2026 07:15:16 +0000 (10:15 +0300)]
gpio: virtuser: Fix uninitialized data bug in gpio_virtuser_direction_do_write()
If *ppos is non-zero (user-space write split over multiple calls to
write()) then simple_write_to_buffer() won't initialize the start of the
buffer. Really, non-zero values for *ppos aren't going to work at all.
Check for that and return -EINVAL at the start of the function.
Fixes: 91581c4b3f29 ("gpio: virtuser: new virtual testing driver for the GPIO API") Signed-off-by: Dan Carpenter <error27@gmail.com> Link: https://patch.msgid.link/ahP3BJWWy-m_qI0X@stanley.mountain Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
gpio: shared: fix lockdep false positive by removing unneeded lock
By the time gpio_device_teardown_shared() is called, the parent device
is gone from the global list of GPIO devices and all outstanding SRCU
read-side critical sections have completed. That means that no
concurrent gpio_find_and_request() can call
gpio_shared_add_proxy_lookup() for this device at this time. There's
also no risk of the parent device being re-bound to the driver before
the unbinding completes (including the child devices).
Lockdep produces a false-positive report about a possible circular
dependency as it doesn't know the ordering guarantee. Not taking the
ref->lock in gpio_device_teardown_shared() silences it and is safe to do.
gpio: shared: fix deadlock on shared proxy's parent removal
Commit 710abda58055 ("gpio: shared: call gpio_chip::of_xlate() if set")
used the mutex embedded in struct gpio_shared_entry to protect the
offset field which now can be modified after assignment. The critical
section however is too wide and introduced a potential deadlock on the
removal of the shared GPIO proxy's parent.
Make the critical section shorter - only protect the offset when it's
being read.
While at it: mention the fact that the entry lock is now also used to
protect against concurrent access to the offset field in the structure's
documentation.
gpio: adnp: fix flow control regression caused by scoped_guard()
scoped_guard() is implemented as a for loop. Using it to protect code
using the continue statement changes the flow as we now only break out
of the hidden loop inside scoped_guard(), not the original for loop. Use
a regular code block instead.
Fixes: c7fe19ed3973 ("gpio: adnp: use lock guards for the I2C lock") Reported-by: David Lechner <dlechner@baylibre.com> Closes: https://lore.kernel.org/all/cde2abb2-4cc8-4fc9-b34a-0c5d2b95779f@baylibre.com/ Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260522073527.9812-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
gpio: shared: undo the vote of the proxy on GPIO free
When the user of a shared GPIO managed by gpio-shared-proxy calls
gpiod_put() to release it, we never undo the potential "vote" for
driving the shared line "high". In the free() callback, check if this
proxy voted for "high" and - if so - decrease the number of votes and
potentially revert the value to low if this is the last user.
Arnd Bergmann [Thu, 28 May 2026 13:20:29 +0000 (15:20 +0200)]
Merge tag 'tee-fixes-for-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee into arm/fixes
TEE fixes for v7.1
Fixing:
- params_from_user() cleanup in error path in tee_ioctl_supp_recv()
- possible tee_shm leak in error path in register_shm_helper()
- padding in struct tee_ioctl_object_invoke_arg
* tag 'tee-fixes-for-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee:
tee: fix params_from_user() error path in tee_ioctl_supp_recv
tee: shm: fix shm leak in register_shm_helper()
tee: fix tee_ioctl_object_invoke_arg padding
Li RongQing [Thu, 28 May 2026 12:40:43 +0000 (08:40 -0400)]
KVM: x86: Use fls() instead of ffs() for rmaps histogram bucketing
The kvm_mmu_rmaps_stat_show() function implements a logarithmic histogram
to collect statistics on the distribution of pte_list_count sizes. However,
it currently uses ffs() (Find First Set), which looks for the least
significant set bit.
Using ffs() leads to severe statistical distortion for any count that is
not a power of two. For example, if a rmap has a pte_list_count of 6
(binary 0110), ffs(6) returns 2, forcing this entry to be erroneously
counted towards the bucket representing a count of 2. In contrast, it
conceptually belongs to the bucket spanning the 4 to 7 range.
Replace ffs() with fls() (Find Last Set) to correctly identify the most
significant set bit (effectively computing floor(log2(count)) + 1). This Ensure
that intermediate counts are correctly categorized into their appropriate
power-of-two order-of-magnitude buckets rather than being severely
under-reported.
Claudiu Beznea [Fri, 22 May 2026 10:57:17 +0000 (13:57 +0300)]
pinctrl: renesas: rzv2m: Use -ENOTSUPP instead of -EOPNOTSUPP
The pinctrl and GPIO core code make exceptions for the -ENOTSUPP error
code. One such example is gpio_set_config_with_argument_optional(), which
returns success when gpio_set_config_with_argument() returns -ENOTSUPP, but
reports failure for all other error codes.
Returning -EOPNOTSUPP from the pinctrl driver on the unsupported pinctrl
operation may lead to boot failures when pinctrl drivers implements
struct gpio_chip::set_config, the system uses GPIO hogs, and the
struct gpio_chip::set_config implementation returns -EOPNOTSUPP for the
unsupported operations.
Currently, the driver does not implement struct gpio_chip::set_config().
To avoid future failures, return -ENOTSUPP from
rzv2m_pinctrl_pinconf_set().
rzv2m_pinctrl_pinconf_group_get() is used when dumping pinctrl
configuration. pinconf_generic_dump_one(), which calls it, makes
exceptions for the -EINVAL and -ENOTSUPP error codes. The documentation
for struct pinconf_ops::pin_config_group_get states that it "should
return -ENOTSUPP and -EINVAL using the same rules as pin_config_get()".
The documentation for struct pinconf_ops::pin_config_get states:
"get the config of a certain pin, if the requested config is not available
on this controller this should return -ENOTSUPP and if it is available but
disabled it should return -EINVAL".
Return -ENOTSUPP for the unsupported pinctrl operation.
Li RongQing [Thu, 28 May 2026 03:15:45 +0000 (23:15 -0400)]
KVM: x86: Fix wrong return value type in guest_cpuid_has()
The function guest_cpuid_has() is declared with a return type of 'bool'.
However, when kvm_find_cpuid_entry_index() fails to locate a valid CPUID
entry, the code incorrectly returns 'NULL' instead of 'false'.
projects / thirdparty / linux.git / log
