David Matlack [Tue, 28 Apr 2026 23:27:06 +0000 (23:27 +0000)]
vfio: selftests: Allow builds when ARCH=x86
Allow builds when ARCH=x86 since the top-level Makefile can set ARCH=x86
even for 64-bit x86 builds.
Note that ARCH=x86 could also indicate a native build on a 32-bit x86
host. However, it doesn't seem like anyone is building selftests
natively on 32-bit x86 hosts these days since KVM selftests allow
ARCH=x86 and fail to compile on 32-bit x86.
If someone reports an issue on 32-bit native builds we can harden the
KVM and VFIO selftests to explicitly check 64-bit (see the discussion in
the Closes link below).
Fixes: a55d4bbbe644 ("vfio: selftests: only build tests on arm64 and x86_64") Reported-by: Jason Gunthorpe <jgg@nvidia.com> Closes: https://lore.kernel.org/kvm/20260427231217.GA1670652@nvidia.com/ Signed-off-by: David Matlack <dmatlack@google.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20260428232707.2139059-1-dmatlack@google.com Signed-off-by: Alex Williamson <alex@shazbot.org>
Jason Gunthorpe [Thu, 14 May 2026 16:04:44 +0000 (13:04 -0300)]
vfio: selftests: Fix out-of-tree build with make O=
The test programs are compiled via a static pattern rule that requires
intermediate .o files:
$(TEST_GEN_PROGS): %: %.o $(LIBVFIO_O)
After lib.mk prefixes TEST_GEN_PROGS with $(OUTPUT), this creates
dependencies on .o files in the output directory (e.g.
$(OUTPUT)/vfio_dma_mapping_test.o). However, there is no rule to compile
these .o files from the source directory .c files when OUTPUT differs
from the source directory.
Add an explicit chain of pattern rules:
$(OUTPUT)/% -> $(OUTPUT)/%.o -> %.c
Following the same pattern already used in libvfio.mk for the library
objects.
Fixes: 19faf6fd969c ("vfio: selftests: Add a helper library for VFIO selftests") Reviewed-by: David Matlack <dmatlack@google.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/0-v2-4ccc247e6aff+1d93-vfio_st_make_o_jgg@nvidia.com Signed-off-by: Alex Williamson <alex@shazbot.org>
Kexin Sun [Sat, 21 Mar 2026 11:00:11 +0000 (19:00 +0800)]
wifi: ath10k: update outdated comment for renamed ieee80211_tx_status()
The function ieee80211_tx_status() was renamed to
ieee80211_tx_status_skb() by commit 2703bc851399
("wifi: mac80211: rename ieee80211_tx_status() to
ieee80211_tx_status_skb()"). Update the stale reference
in ath10k_htt_tx_hl().
If there is an error during some initialization related to firmware,
the buffers dp->tx_ring[i].tx_status are released.
However this is released again when the device is unbinded (ath11k_pci),
and we get:
WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90
Call Trace:
free_large_kmalloc
ath11k_dp_free
ath11k_core_deinit
ath11k_pci_remove
...
The issue is always reproducible from a VM because the MSI addressing
initialization is failing.
In order to fix the issue, just set the buffers to NULL after releasing in
order to avoid the double free.
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Cc: stable@vger.kernel.org Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260420110130.509670-1-jtornosm@redhat.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Daniel Palmer [Wed, 20 May 2026 11:19:31 +0000 (20:19 +0900)]
tools/nolibc: getopt: Fix potential out of bounds access
Running clang-tidy on a program that uses getopt() from nolibc
this warning appears:
getopt.h:80:6: warning: Out of bound access to memory after the end of the string literal [clang-analyzer-security.ArrayBound]
80 | if (optstring[i] == ':') {
This looks like a very unlikely case that an argument
inside of argv is being changed between getopt() calls.
Adding a check for d becoming 0 in the guard after the loop
stops getopt() getting far enough to access beyond the end
of the array and seems to correct the issue.
Fixes: bae3cd708e8a ("tools/nolibc: add getopt()") Assisted-by: Claude:claude-4.6-sonnet # reproducer Signed-off-by: Daniel Palmer <daniel@thingy.jp> Link: https://patch.msgid.link/20260520111931.1027758-1-daniel@thingy.jp
[Thomas: clean up commit message a bit] Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Changelog:
v1: https://lore.kernel.org/all/20260519163632.2220753-1-puranjay@kernel.org/
Changes in v2:
- Drop patch 3 as it was fixing a situation that can never happen in practice.
- Replace | 1 logic in patch 1 with replacing ^ operator with +
Three bug fixes and one improvement for the XDP LB and batch-timing
benchmarks.
The cold_lru validation was failing a lot because batch_hash could
compute to zero when batch_gen matched the CPU id. Similarly,
pre-populated UDP LRU entries had atime=0 so they'd expire immediately
on any CPU that calibration didn't warm. Both are fixed in patches 1-2.
Patch 3 adds IQR outlier filtering to the timing stats to stabilize
scenarios with high stddev.
====================
Puranjay Mohan [Wed, 20 May 2026 13:33:32 +0000 (06:33 -0700)]
selftests/bpf: Filter timing outliers with IQR in batch-timing library
System noise (timer interrupts, scheduling) can inflate the reported
stddev. tcp-v4-syn showed stddev 37.86 ns without filtering vs
0.16 ns with filtering on the same run data.
Filter samples outside [Q1 - 1.5*IQR, Q3 + 1.5*IQR] before computing
statistics. Scenarios with genuinely wide distributions have large IQR
so the fences stay wide and the filter has minimal effect.
Puranjay Mohan [Wed, 20 May 2026 13:33:31 +0000 (06:33 -0700)]
selftests/bpf: Fix expired UDP LRU entries in XDP LB benchmark
populate_lru() zero-initializes atime:
struct real_pos_lru lru = { .pos = real_idx };
connection_table_lookup() treats UDP entries with
cur_time - atime > 30s as expired, so every pre-populated entry
expires immediately. Calibration masks this on the CPU it runs on,
but if validation migrates to another CPU:
The ldo_vcn33_[12]_wifi and ldo_vcn33_[12]_bt are just two regulator
outputs instead of four. The wifi and bt parts refer to separate enable
bits that are OR-ed together to affect the actual regulator output. The
separate bits allow the wifi and bt stacks to enable their power without
coordination between them. These have been deprecated in favor of proper
nodes matching the output.
Add proper ldo_vcn33_[12] regulators to replace the existing ones. The
enable status is synced to just one of the two enable bits, and the
other is forced off. This makes the handling in other bits simpler.
The existing *_(bt|wifi) regulators are converted to no-op regulators
that are fed from their new respective ldo_vcn33_[12] regulator. This
allows existing device trees to continue to work.
Chen-Yu Tsai [Thu, 14 May 2026 09:15:18 +0000 (17:15 +0800)]
regulator: mt6359: Add regulator supply names
The MT6359 regulator DT binding defines the supply names for the PMIC.
Add support for them by adding .supply_name field settings for each
regulator. The buck regulators each have their own supply. The name
of the supply is related to the name of the buck regulator. The LDOs
have shared supplies.
Add the supply name to the declaration of each regulator. At the moment
they are declared explicitly, but the buck regulator macro can be made
to derive both the match string and supply name from the base name once
the *_sshub regulators are figured out and removed. For context, the
*_sshub regulators are not separate regulators, but separate settings
for the same name regulators without the "_sshub" suffix.
The regulator descriptions and extended descriptions don't change at
runtime. The only reason they are not const is that the regulator
driver data is non-const.
Const-ify the descriptions and all references to them. For the driver
data, explicitly cast it to non-const void *.
vcn33_[12]_bt and vcn33_[12]_wifi refer to the same output. There are
two enable bits in the registers so that BT and WiFi drivers can toggle
them separately without any coordination. If either bit is set, then the
regulator output is enabled.
Deprecate the existing regulators, and add proper regulators matching
the outputs: vcn33_1 and vcn33_2.
Chen-Yu Tsai [Thu, 14 May 2026 09:15:15 +0000 (17:15 +0800)]
regulator: dt-bindings: mt6359: Drop regulator-name pattern restrictions
The name of the regulator should match what the board design specifies
for the power rail. There should be no limitations on what the name can
be, and they definitely don't always follow the PMIC's own names.
Drop the restrictions on regulator-name.
Fixes: 8771456635d5 ("dt-bindings: regulator: Add document for MT6359 regulator") Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://patch.msgid.link/20260514091520.2718987-3-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
Jens Axboe [Wed, 20 May 2026 16:02:58 +0000 (10:02 -0600)]
io_uring/timeout: splice timed out link in timeout handler
A previous commit deferred this to the task_work part of it, so it could
be protected by ->uring_lock. But that's actually not necessary here,
and in fact the head clearing is not enough to make that safe. For those
two reasons, just re-instate the local splicing.
Fixes: 49ae66eb8c27 ("io_uring: defer linked-timeout chain splice out of hrtimer context") Signed-off-by: Jens Axboe <axboe@kernel.dk>
Randy Dunlap [Sun, 3 May 2026 05:25:08 +0000 (22:25 -0700)]
bitops: use common function parameter names
Fix the function prototypes to use the common parameter name 'addr'
instead of 'p' (common to arch-specific implementations of these
functions).
This avoids the kernel-doc warnings:
Warning: include/asm-generic/bitops/lock.h:19 function parameter 'p'
not described in 'arch_test_and_set_bit_lock'
Warning: include/asm-generic/bitops/lock.h:41 function parameter 'p'
not described in 'arch_clear_bit_unlock'
Warning: include/asm-generic/bitops/lock.h:59 function parameter 'p'
not described in 'arch___clear_bit_unlock'
Fixes: 84c6591103db ("locking/atomics, asm-generic/bitops/lock.h: Rewrite using atomic_fetch_*()") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Yury Norov <yury.norov@gmail.com>
The EX_DATA register is laid out such that EX_DATA_IMM occupied MSB.
It's done to make sure that FIELD_GET() will sign-extend the IMM
field during extraction.
To enforce that, all EX_DATA masks are made signed integers. This
works, but relies on the particular implementation of FIELD_GET(),
i.e. masking then shifting, not vice versa; and the particular
placement of the fields in the register.
Switch to using the dedicated FIELD_GET_SIGNED(), and relax those
limitations.
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Yury Norov <ynorov@nvidia.com>
The bitfields are designed in assumption that fields contain unsigned
integer values, thus extracting the values from the field implies
zero-extending.
Some drivers need to sign-extend their fields, and currently do it like:
It compiles (on x86_64) into just a couple instructions: shl and sar.
When the mask includes MSB, the '<< __builtin_clzll(mask)' part becomes
a NOP, and the compiler only emits a single sar:
long long foo(long long reg)
{
10: f3 0f 1e fa endbr64
return FIELD_GET_SIGNED(GENMASK_ULL(63, 60), reg);
14: 48 89 f8 mov %rdi,%rax
17: 48 c1 f8 3c sar $0x3c,%rax
}
32-bit code generation is equally well. On arm32:
long long foo(long long reg)
{
return FIELD_GET_SIGNED(0x00f00000ULL, reg);
}
Linus Torvalds [Wed, 20 May 2026 15:15:30 +0000 (10:15 -0500)]
Merge tag 'rcu-fixes.v7.1-20260519a' of git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux
Pull RCU fixes from Boqun Feng:
"Fix a regression introduced by commit 61bbcfb50514 ("srcu: Push
srcu_node allocation to GP when non-preemptible").
SRCU may queue works on CPUs that are "possible" but never have been
online. In such a case, the work callbacks may not be executed until
the corresponding CPU gets online, and as the callbacks accumulates,
workqueue lockups will fire.
Fix this by avoiding queuing works on CPUs that have never been
online"
* tag 'rcu-fixes.v7.1-20260519a' of git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux:
srcu: Don't queue workqueue handlers to never-online CPUs
sysfs: clamp show() return value in sysfs_kf_read()
sysfs_kf_seq_show() defends against buggy show() callbacks that return
larger than PAGE_SIZE by clamping the value and printing a warning.
sysfs_kf_read(), the prealloc variant, has no such defense.
The only current in-tree user of __ATTR_PREALLOC is drivers/md/md.c,
whose show() callbacks are well-behaved, so this is hardening against
future drivers doing foolish things and out-of-tree code doing even more
foolish things.
Cc: NeilBrown <neil@brown.name> Cc: Tejun Heo <tj@kernel.org> Fixes: 2b75869bba67 ("sysfs/kernfs: allow attributes to request write buffer be pre-allocated.") Assisted-by: gregkh_clanker_t1000 Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/2026052000-drove-unicycle-d61b@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sysfs: don't remove existing directory on update failure
When sysfs_update_group() is called for a named group and create_files()
fails (e.g. -ENOMEM), internal_create_group() calls kernfs_remove(kn) on
the group directory. In the update path, kn was obtained via
kernfs_find_and_get() and refers to a directory that already existed
before this call. Removing it silently destroys a sysfs group that the
caller did not create.
Only remove the directory if we created it ourselves. On update failure
the directory remains as it is left empty by remove_files() inside
create_files(), but can be repopulated by a retry.
Cc: Rajat Jain <rajatja@google.com> Fixes: c855cf2759d2 ("sysfs: Fix internal_create_group() for named group updates") Cc: stable <stable@kernel.org> Assisted-by: gkh_clanker_t1000 Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/2026052003-uniquely-hastily-c093@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/virtio: use uninterruptible resv lock for plane updates
virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock
the framebuffer BO's dma_resv via virtio_gpu_array_lock_resv() and
ignore its return value. The function can fail with -EINTR from
dma_resv_lock_interruptible() (signal during lock wait) or with
-ENOMEM from dma_resv_reserve_fences() (fence slot allocation),
leaving the resv lock not held. The queue path then walks the object
array and calls dma_resv_add_fence(), which requires the lock held;
with lockdep enabled this trips dma_resv_assert_held():
Beyond the WARN, mutating the dma_resv fence list without the lock
races with concurrent readers/writers and can corrupt the list.
Both call sites run inside the .atomic_update plane callback, which
DRM atomic helpers do not allow to fail (by the time it runs, the
commit has been signed off to userspace and there is no clean
rollback path). Moving the lock acquisition to .prepare_fb was
rejected because the broader lock scope deadlocks against other BO
locking paths in the same atomic commit.
Introduce virtio_gpu_lock_one_resv_uninterruptible() that uses
dma_resv_lock() instead of dma_resv_lock_interruptible(). This
eliminates the -EINTR failure mode -- the realistic syzbot trigger
-- without extending the lock hold across the commit. The helper
locks a single BO and rejects nents > 1 with -EINVAL; both fix
sites lock exactly one BO.
Use it from virtio_gpu_cursor_plane_update() and
virtio_gpu_resource_flush(); check the return value to handle the
remaining -ENOMEM case from dma_resv_reserve_fences() by freeing
the objs and skipping the plane update for that frame. The
framebuffer BOs touched here are not shared with other contexts
and lock contention is expected to be brief, so the loss of
signal-interruptibility is acceptable.
Other callers of virtio_gpu_array_lock_resv() (the ioctl paths)
continue to use the interruptible variant.
The bug was reported by syzbot, triggered via fault injection
(fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the
-ENOMEM branch in dma_resv_reserve_fences().
eeprom: at24: Use named initializers for arrays of i2c_device_data
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.
The mentioned robustness is relevant for a planned change to struct
i2c_device_id that replaces .driver_data by an anonymous union.
This patch doesn't modify the compiled array, only its representation
in source form benefits. The former was confirmed with x86 and arm64
builds.
drm/virtio: use uninterruptible resv lock for plane updates
virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock
the framebuffer BO's dma_resv via virtio_gpu_array_lock_resv() and
ignore its return value. The function can fail with -EINTR from
dma_resv_lock_interruptible() (signal during lock wait) or with
-ENOMEM from dma_resv_reserve_fences() (fence slot allocation),
leaving the resv lock not held. The queue path then walks the object
array and calls dma_resv_add_fence(), which requires the lock held;
with lockdep enabled this trips dma_resv_assert_held():
Beyond the WARN, mutating the dma_resv fence list without the lock
races with concurrent readers/writers and can corrupt the list.
Both call sites run inside the .atomic_update plane callback, which
DRM atomic helpers do not allow to fail (by the time it runs, the
commit has been signed off to userspace and there is no clean
rollback path). Moving the lock acquisition to .prepare_fb was
rejected because the broader lock scope deadlocks against other BO
locking paths in the same atomic commit.
Introduce virtio_gpu_lock_one_resv_uninterruptible() that uses
dma_resv_lock() instead of dma_resv_lock_interruptible(). This
eliminates the -EINTR failure mode -- the realistic syzbot trigger
-- without extending the lock hold across the commit. The helper
locks a single BO and rejects nents > 1 with -EINVAL; both fix
sites lock exactly one BO.
Use it from virtio_gpu_cursor_plane_update() and
virtio_gpu_resource_flush(); check the return value to handle the
remaining -ENOMEM case from dma_resv_reserve_fences() by freeing
the objs and skipping the plane update for that frame. The
framebuffer BOs touched here are not shared with other contexts
and lock contention is expected to be brief, so the loss of
signal-interruptibility is acceptable.
Other callers of virtio_gpu_array_lock_resv() (the ioctl paths)
continue to use the interruptible variant.
The bug was reported by syzbot, triggered via fault injection
(fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the
-ENOMEM branch in dma_resv_reserve_fences().
drm/virtio: add VIRTGPU_PARAM_BLOB_ALIGNMENT to params
Add VIRTGPU_PARAM_BLOB_ALIGNMENT as a param that can be read with
VIRTGPU_GETPARAM by userspace applications running in the guest to
obtain the host's page size and find out the right alignment to be used
in shared memory allocations.
If VIRTIO_GPU_F_BLOB_ALIGNMENT has been negotiated, blob size must be
aligned to blob_alignment. Validate this in verify_blob() so that
invalid requests are rejected early.
Support VIRTIO_GPU_F_BLOB_ALIGNMENT, a feature that indicates the device
provides a valid blob_alignment field in its configuration, and that
both RESOURCE_CREATE_BLOB and RESOURCE_MAP_BLOB requests must be aligned
to that value.
Johan Hovold [Wed, 20 May 2026 14:27:00 +0000 (16:27 +0200)]
USB: serial: mct_u232: fix memory corruption with small endpoint
The driver overrides the maximum transfer size for a specific device
which only accepts 16 byte packets for its 32 byte bulk-out endpoint.
Make sure to never increase the maximum transfer size to prevent slab
corruption should a malicious device report a smaller endpoint max
packet size than expected.
Johan Hovold [Wed, 20 May 2026 14:26:22 +0000 (16:26 +0200)]
USB: serial: digi_acceleport: fix memory corruption with small endpoints
Add the missing bulk-out buffer size sanity checks to avoid
out-of-bounds memory accesses or slab corruption should a malicious
device report smaller buffers than expected.
Zhang Cen [Tue, 19 May 2026 11:11:50 +0000 (19:11 +0800)]
USB: serial: belkin_sa: validate interrupt status length
The Belkin interrupt callback treats interrupt data as a four-byte
status report and reads LSR/MSR fields at offsets 2 and 3. The
interrupt-in buffer length is derived from endpoint wMaxPacketSize, and
short interrupt transfers may complete successfully with a smaller
actual_length.
Check the completed interrupt packet length before parsing status
fields so short interrupt endpoints and short successful packets are
ignored instead of causing out-of-bounds or stale status-byte reads.
KASAN report as below:
BUG: KASAN: slab-out-of-bounds in belkin_sa_read_int_callback()
Read of size 1
Call trace:
belkin_sa_read_int_callback() (drivers/usb/serial/belkin_sa.c:202)
__usb_hcd_giveback_urb() (drivers/usb/core/hcd.c:1630)
dummy_timer() (?:?)
Rosen Penev [Tue, 19 May 2026 00:56:14 +0000 (17:56 -0700)]
spi: cadence-xspi: Add COMPILE_TEST support
The Cadence XSPI driver uses readq() and writeq(), which are not provided
directly by all 32-bit architectures. Include the generic non-atomic 64-bit
I/O accessor fallback for non-64-bit builds so the driver can build there.
Drop the 64BIT dependency at the same time. The driver only needs MMIO
and the SPI memory interface at build time, and the fallback accessors
cover the 32-bit compile-test case.
Hans Verkuil [Wed, 20 May 2026 07:22:41 +0000 (09:22 +0200)]
media: vivid: check for vb2_is_busy() when toggling caps
The vivid_update_format_cap/out() functions must only be called if the
capture/output queue are not busy. But for the controls that select
the CROP/COMPOSE/SCALE capability that is not checked.
Only when streaming starts will they be set to 'grabbed' and it is
impossible to change the control, but between REQBUFS and STREAMON you
are still allowed to set these controls. Since vivid_update_format_cap/out
will change the format, this can cause unexpected results.
Besides adding these checks, also add a WARN_ON in
vivid_update_format_cap/out() if the queue is busy.
I'm 90% certain that this is the cause of this syzbot bug:
Hans Verkuil [Wed, 20 May 2026 07:30:44 +0000 (09:30 +0200)]
media: vivid: add vivid_update_reduced_fps()
Don't call vivid_update_format_cap() when switching to/from reduced fps
for HDMI inputs: that will also reset the format, which is overkill for
this.
Make a new vivid_update_reduced_fps() function that just updates the
dev->timeperframe_vid_cap.
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Fixes: c79aa6aeadb0 ("[media] vivid-capture: add control for reduced frame rate") Cc: stable@vger.kernel.org Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
gpio: Initialize all i2c_device_id arrays using member names
The previously applied similar commit 553e26a45e0e ("gpio: Initialize
i2c_device_id arrays using member names") only handled i2c_device_id
arrays that also have an assignment for .driver_data.
For consistency also convert the entries without such an assignment.
Again this is a modification that has no influence on the generated
code, it's only more robust against changes to struct i2c_device_id and
easier to understand for a human.
While touching adnp_i2c_id[] drop the comma after the list terminator.
Rosen Penev [Tue, 19 May 2026 00:59:12 +0000 (17:59 -0700)]
gpio: en7523: allow COMPILE_TEST builds
The Airoha EN7523 GPIO driver uses generic platform, MMIO, and gpiolib
interfaces. Allow it to build with COMPILE_TEST so it gets coverage on
non-Airoha platforms.
Tested with:
make LLVM=1 ARCH=loongarch drivers/gpio/gpio-en7523.o
Rosen Penev [Tue, 19 May 2026 00:59:58 +0000 (17:59 -0700)]
gpio: xgene: allow COMPILE_TEST builds
The APM X-Gene GPIO driver uses generic platform, ACPI, MMIO, and gpiolib
interfaces. Allow it to build with COMPILE_TEST, matching the existing
coverage for the X-Gene standby GPIO driver.
Tested with:
make LLVM=1 ARCH=loongarch drivers/gpio/gpio-xgene.o
This is v3 to move card->pop_time to soc-dapm.
card->pop_time is used only on TI, and Janusz posted patch which will stop
using it. It was posted at 12 Apr 2026, and [1/2] is it as-is.
[2/2] will move card->pop_time to soc-dapm. We can use it via debugfs.
I have added [RFC] on Subject.
Card has pop_time which have used only from TI, and it is now stop using
it. This pop_time is used for debug, and can be access from debugfs.
Let's move it from Card to soc-dapm.c local.
This patch renames it as asoc/${card}/pop_time to asoc/dapm_pop_time.
This patch moves it from Card to soc-dapm.c, tidyup soc-dapm.c
accordingly, and remove card->pop_time from cx20442.c which is no longer
needed.
A flag is needed that tells the card driver if the codec has been
initialized successfully over the modem's line discipline. Initially,
codec->hw_write was used as the flag, but it was then dropped and the
flag function associated with card->pop_time, already managed by the
codec driver for diagnostic purposes. Since now the card->pop_time is
going to be killed, stop abusing foreign fields in favor of an own one.
Jai Luthra [Wed, 20 May 2026 12:00:22 +0000 (17:30 +0530)]
media: ti: j721e-csi2rx: Support system suspend using pm_notifier
As this device is the "orchestrator" for the rest of the media
pipeline, we need to stop all on-going streams before system suspend and
enable them back when the system wakes up from sleep.
Using .suspend/.resume callbacks does not work, as the order of those
callbacks amongst various devices in the camera pipeline like the sensor,
FPD serdes, CSI bridge etc. is impossible to enforce, even with
device links. For example, the Cadence CSI bridge is a child device of
this device, thus we cannot create a device link with the CSI bridge as
a provider and this device as consumer. This can lead to situations
where all the dependencies for the bridge have not yet resumed when we
request the subdev to start streaming again through the .resume callback
defined in this device.
Instead here we register a notifier callback with the PM framework
which is triggered when the system is fully functional. At this point we
can cleanly stop or start the streams, because we know all other devices
and their dependencies are functional. A downside of this approach is
that the userspace is also alive (not frozen yet, or just thawed), so
the suspend notifier might complete before the userspace has completed
all ioctls, like QBUF/DQBUF/STREAMON/STREAMOFF.
Tested-by: Rishikesh Donadkar <r-donadkar@ti.com> Reviewed-by: Rishikesh Donadkar <r-donadkar@ti.com> Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com> Signed-off-by: Rishikesh Donadkar <r-donadkar@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Jai Luthra [Wed, 20 May 2026 12:00:21 +0000 (17:30 +0530)]
media: ti: j721e-csi2rx: Support runtime suspend
Add support for runtime power-management to enable powering off the
shared power domain between Cadence CSI2RX and TI CSI2RX wrapper when
the device(s) are not in use.
When powering off the IP, the PSI-L endpoint loses the paired DMA
channels. Thus we have to release the DMA channels at runtime suspend
and request them again at resume.
Tested-by: Rishikesh Donadkar <r-donadkar@ti.com> Reviewed-by: Rishikesh Donadkar <r-donadkar@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com> Co-developed-by: Rishikesh Donadkar <r-donadkar@ti.com> Signed-off-by: Rishikesh Donadkar <r-donadkar@ti.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Changhuang Liang [Wed, 20 May 2026 12:00:20 +0000 (17:30 +0530)]
media: cadence: csi2rx: Support runtime PM
Use runtime power management hooks to save power when CSI-RX is not in
use. Also, shift to goto based error handling in
csi2rx_enable_streams() function
Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com> Tested-by: Rishikesh Donadkar <r-donadkar@ti.com> Reviewed-by: Rishikesh Donadkar <r-donadkar@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com> Signed-off-by: Rishikesh Donadkar <r-donadkar@ti.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
media: ti: j721e-csi2rx: Change the drain architecture for multistream
On buffer starvation the DMA is marked IDLE, and the stale data in the
internal FIFOs gets drained only on the next VIDIOC_QBUF call from the
userspace. This approach works fine for a single stream case.
But in multistream scenarios, buffer starvation for one stream can
block the shared HW FIFO of the CSI2RX IP. This can stall the pipeline
for all other streams, even if buffers are available for them.
This patch introduces a new architecture, that continuously drains data
from the shared HW FIFO into a small (32KiB) buffer if no buffers are made
available to the driver from the userspace. This ensures independence
between different streams, where a slower downstream element for one
camera does not block streaming for other cameras.
Additionally, after we drain for a stream, the next frame will be a
partial frame, as a portion of its data will have already been drained
before a valid buffer is queued by user space to the driver.
Return the partial frame to user space with VB2_BUF_STATE_ERROR.
Use wait for completion barrier to make sure the shared hardware FIFO
is cleared of the data at the end of stream after the source has stopped
sending data.
Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com> Reviewed-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com> Signed-off-by: Rishikesh Donadkar <r-donadkar@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Jai Luthra [Wed, 20 May 2026 12:00:17 +0000 (17:30 +0530)]
media: ti: j721e-csi2rx: add multistream support
Each CSI2 stream can be multiplexed into 32 independent streams, each
identified by its virtual channel number and data type. The incoming
data from these streams can be filtered on the basis of either the
virtual channel or the data type.
To capture this multiplexed stream, the application needs to tell
the driver how it wants to route the data. It needs to specify
which context should process which stream. This is done via the
new routing APIs.
Add ioctls to accept routing information from the application and save
that in the driver. This can be used when starting streaming on a
context to determine which route and consequently which virtual channel
it should process.
De-assert the pixel interface reset on first start_streaming() and assert
it on the last stop_streaming().
Jai Luthra [Wed, 20 May 2026 12:00:16 +0000 (17:30 +0530)]
media: cadence: csi2rx: add multistream support
Cadence CSI-2 bridge IP supports capturing multiple virtual "streams"
of data over the same physical interface using MIPI Virtual Channels.
While the hardware IP supports usecases where streams coming in the sink
pad can be broadcasted to multiple source pads, the driver will need
significant re-architecture to make that possible. The two users of this
IP in mainline linux are TI Shim and StarFive JH7110 CAMSS, and both
have only integrated the first source pad i.e stream0 of this IP. So for
now keep it simple and only allow 1-to-1 mapping of streams from sink to
source, without any broadcasting.
Signed-off-by: Jai Luthra <j-luthra@ti.com> Reviewed-by: Changhuang Liang <changhuang.liang@starfivetech.com> Reviewed-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Co-developed-by: Rishikesh Donadkar <r-donadkar@ti.com> Signed-off-by: Rishikesh Donadkar <r-donadkar@ti.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Jai Luthra [Wed, 20 May 2026 12:00:15 +0000 (17:30 +0530)]
media: ti: j721e-csi2rx: add support for processing virtual channels
Use get_frame_desc() to get the frame desc from the connected source,
and use the provided virtual channel and DT instead of defaults.
As we don't support multiple streams yet, we will just always use
stream 0. If the source doesn't support get_frame_desc(), fall back
to the previous method of always capturing virtual channel 0.
Reviewed-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com> Co-developed-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Jai Luthra <j-luthra@ti.com> Signed-off-by: Rishikesh Donadkar <r-donadkar@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Pratyush Yadav [Wed, 20 May 2026 12:00:13 +0000 (17:30 +0530)]
media: ti: j721e-csi2rx: get number of contexts from device tree
Different platforms that use this driver might have different number of
DMA channels allocated for CSI. So only as many DMA contexts can be used
as the number of DMA channels available. Get the number of channels
provided via device tree and only configure that many contexts, and
hence only that many pads.
Reviewed-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Co-developed-by: Jai Luthra <j-luthra@ti.com> Signed-off-by: Jai Luthra <j-luthra@ti.com> Signed-off-by: Rishikesh Donadkar <r-donadkar@ti.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
media: cadence: csi2rx: Move to .enable/disable_streams API
The enable_streams() API in v4l2 supports passing a bitmask to enable
each pad/stream combination individually on any media subdev. Use this
API instead of s_stream() API.
Implement the enable_stream and disable_stream hooks in place of the
stream-unaware s_stream hook.
Remove the lock that was used to serialize stream starts/stops which
is not required anymore since the v4l2-core serializes the
enable/disable_streams() calls for the subdev.
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Rishikesh Donadkar <r-donadkar@ti.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Jai Luthra [Wed, 20 May 2026 12:00:11 +0000 (17:30 +0530)]
media: ti: j721e-csi2rx: add a subdev for the core device
With single stream capture, it was simpler to use the video device as
the media entity representing the main TI CSI2RX device. Now with multi
stream capture coming into the picture, the model has shifted to each
video device having a link to the main device's subdev. The routing
would then be set on this subdev.
Add this subdev, link each context to this subdev's entity and link the
subdev's entity to the source. Also add an array of media pads. It will
have one sink pad and source pads equal to the number of contexts.
Support the new enable_stream()/disable_stream() APIs in the subdev
instead of s_stream() hook.
Reviewed-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com> Co-developed-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Jai Luthra <j-luthra@ti.com> Signed-off-by: Rishikesh Donadkar <r-donadkar@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Pratyush Yadav [Wed, 20 May 2026 12:00:10 +0000 (17:30 +0530)]
media: ti: j721e-csi2rx: allocate DMA channel based on context index
With multiple contexts, there needs to be a different DMA channel for
each context. Earlier, the DMA channel name was hard coded to "rx0" for
the sake of simplicity. Generate the DMA channel name based on its index
and get the channel corresponding to the context.
Pratyush Yadav [Wed, 20 May 2026 12:00:09 +0000 (17:30 +0530)]
media: ti: j721e-csi2rx: prepare SHIM code for multiple contexts
Currently the SHIM code to configure the context only touches the first
context. Add support for writing to the context's registers based on the
context index.
Jai Luthra [Wed, 20 May 2026 12:00:08 +0000 (17:30 +0530)]
media: ti: j721e-csi2rx: separate out device and context
The TI CSI2RX wrapper has two parts: the main device and the DMA
contexts. The driver was originally written with single camera capture
in mind, so only one DMA context was needed. For the sake of simplicity,
the context specific stuff was not modeled different to the main device.
To enable multiplexed stream capture, the contexts need to be separated
out from the main device. Create a struct ti_csi2rx_ctx that holds the
DMA context specific things. Separate out functions handling the device
and context related functionality.
Reviewed-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Co-developed-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Jai Luthra <j-luthra@ti.com> Signed-off-by: Rishikesh Donadkar <r-donadkar@ti.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Jai Luthra [Wed, 20 May 2026 12:00:07 +0000 (17:30 +0530)]
dt-bindings: media: ti,j721e-csi2rx-shim: Support 32 dma chans
The CSI2RX SHIM IP can support 32x DMA channels. These can be used to
split incoming "streams" of data on the CSI-RX port, distinguished by
MIPI Virtual Channel (or Data Type), into different locations in memory.
Actual number of DMA channels allocated to CSI-RX is dependent on the
usecase, and can be modified using the K3 Resource Partitioning tool [1].
So set the minimum channels as 1 and maximum as 32.
They require a PPC platform to compile but that's it.
Allow the Freescale PowerPC ASoC menu in PowerPC compile-test builds
and let the MPC5200 PSC I2S and AC97 drivers depend on PPC_BESTCOMM
directly. This keeps native platform builds unchanged while extending
compile-test coverage.
Guoniu Zhou [Tue, 19 May 2026 02:07:43 +0000 (10:07 +0800)]
media: synopsys: Add support for i.MX95
Add support for the i.MX95 MIPI CSI-2 receiver. The i.MX95 variant is
nearly identical to i.MX93, with the main difference being the use of
IDI (Image Data Interface) instead of IPI (Image Pixel Interface).
However, the IDI interface is transparent to software, requiring only
a different register map definition while sharing the same PHY control
functions with i.MX93.
Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
The i.MX95 CSI-2 controller is nearly identical to i.MX93, with the
main difference being the data output interface:
i.MX93 use IPI (Image Pixel Interface), which requires:
- Pixel clock input
- Software configuration through registers
i.MX95 uses IDI (Image Data Interface), which:
- Does not require pixel clock
- Is software transparent (no register configuration needed)
Due to these differences in register layout and initialization needs,
the two variants cannot share the same compatible string. The driver
needs to distinguish between them to handle the interface correctly.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Guoniu Zhou [Tue, 19 May 2026 02:07:41 +0000 (10:07 +0800)]
media: synopsys: Add PHY stopstate wait for i.MX93
Implement waiting for D-PHY lanes to enter stop state on i.MX93. This
ensures proper PHY initialization by verifying that the clock lane and
all active data lanes have entered the stop state before proceeding with
further operations.
Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Guoniu Zhou [Tue, 19 May 2026 02:07:40 +0000 (10:07 +0800)]
media: synopsys: Add support for multiple streams
The current driver only supports single stream operation. Add support
for multiple concurrent streams by tracking enabled streams with a
bitmask and only initializing the hardware once for the first stream.
This enables use cases such as surround view systems where multiple
camera streams need to be processed simultaneously through the same
CSI-2 receiver interface.
Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Guoniu Zhou [Tue, 19 May 2026 02:07:39 +0000 (10:07 +0800)]
media: synopsys: Add support for RAW16 Bayer formats
Add higher bit-depth raw image data support for the sensors, which supports
16-bit output.
Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Guoniu Zhou [Tue, 19 May 2026 02:07:38 +0000 (10:07 +0800)]
media: synopsys: Fix IPI using hardcoded datatype
The imx93_csi2rx_dphy_ipi_enable() function configures the IPI datatype
using csi2->formats->csi_dt, which is initialized during probe but never
updated in set_fmt(). This causes the IPI to always use the probe-time
default datatype, ignoring the actual media bus format negotiated at
runtime. When userspace requests a different format, the IPI hardware is
configured with the wrong datatype, resulting in incorrect image output.
Fix by updating csi2->formats in the set_fmt callback to reflect the
currently negotiated format, ensuring the IPI configuration matches the
runtime datatype.
Fixes: ec40b431f0ab ("media: synopsys: csi2rx: add i.MX93 support") Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Martin Hecht [Fri, 8 May 2026 09:59:03 +0000 (11:59 +0200)]
media: i2c: alvium: fix critical pointer access in alvium_ctrl_init
The current implementation of alvium_ctrl_init creates several controls in
function alvium_ctrl_init and uses the returned pointer without check. That
can cause write access over NULL-pointer for several controls. The reworked
code checks the pointers before adding flags.
Fixes: 0a7af872915e ("media: i2c: Add support for alvium camera") Cc: stable@vger.kernel.org Signed-off-by: Martin Hecht <mhecht73@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Jack Yu [Wed, 20 May 2026 05:32:43 +0000 (13:32 +0800)]
ASoC: rt722-sdca: Add a control to support CAE firmware update
Realtek CAE requires specific tuning parameters based on
the system vendor and SKU.
This patch adds a kcontrol to trigger the firmware loading process.
Zhang Cen [Wed, 20 May 2026 10:32:49 +0000 (18:32 +0800)]
ALSA: seq: Serialize UMP output teardown with event_input
seq_ump_process_event() borrows client->out_rfile.output without
synchronizing with the first-open and last-close transition in
seq_ump_client_open() and seq_ump_client_close().
The last output unuse can therefore drop opened[STR_OUT] to zero and
release the rawmidi file while an in-flight event_input callback is still
inside snd_rawmidi_kernel_write(). That leaves the rawmidi substream
runtime exposed to teardown before the write path has taken its own
buffer reference.
Add a per-client rwlock for the event_input-visible output file. Publish
a newly opened output file under the write side, and hold the read side
from the output lookup through snd_rawmidi_kernel_write(). The last
output close copies and clears the visible output file under the write
side, then drops the lock and releases the saved rawmidi file. Use
IRQ-safe rwlock guards because event_input can also be reached from
atomic sequencer delivery.
The buggy scenario involves two paths, with each column showing the
order within that path:
path A label: event_input path path B label: last unuse path
1. seq_ump_process_event() reads 1. seq_ump_client_close()
client->out_rfile.output. drops opened[STR_OUT] to zero.
2. snd_rawmidi_kernel_write1() 2. snd_rawmidi_kernel_release()
has not yet pinned runtime. closes the output file.
3. The writer continues using 3. close_substream() frees
the borrowed substream. substream->runtime.
This keeps the output substream and runtime alive for the full
event_input write while keeping rawmidi release outside the rwlock.
KASAN reproduced this as a slab-use-after-free in
snd_rawmidi_kernel_write1(), with allocation through
seq_ump_use()/snd_seq_port_connect() and free through
seq_ump_unuse()/snd_seq_port_disconnect().
staging: media: atomisp: replace msleep() with fsleep() in atomisp-gc2235.c
Replace msleep(5) with fsleep(5000) to avoid sleeping longer than
necessary. msleep() with values less than 20ms may sleep for up to
20ms due to timer granularity. fsleep() selects the appropriate sleep
function automatically.
Signed-off-by: Oskar Ray-Frayssinet <rayfraytech@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
staging: media: atomisp: fix map and vmap leaks in stat buffer allocation
There are memory leaks in
drivers/staging/media/atomisp/pci/atomisp_compat_css20.c.
In atomisp_css_allocate_stat_buffers(), s3a_map is allocated by
ia_css_isp_3a_statistics_map_allocate() and its backing memory is
mapped via hmm_vmap(). When dis_buf allocation fails, the error path
frees s3a_data but does not unmap or free s3a_map. Similarly, when
md_buf allocation fails, neither s3a_map nor dvs_map (and their hmm
vmaps) are freed.
Add the missing hmm_vunmap() and map free calls on both error paths,
matching the cleanup order used in atomisp_css_free_3a_buffer() and
atomisp_css_free_dis_buffer().
Signed-off-by: Huihui Huang <hhhuang@smu.edu.sg> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Timo Röhling [Tue, 15 Jul 2025 11:23:26 +0000 (13:23 +0200)]
media: atomisp: style fix for trailing statements
Fix checkpatch errors "ERROR: trailing statements should be on next line"
in drivers/staging/media/atomisp/pci/sh_css_params.c.
Signed-off-by: Timo Röhling <roehling@debian.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
LiangCheng Wang [Sat, 26 Jul 2025 07:53:14 +0000 (15:53 +0800)]
staging: media: atomisp: fix indentation in bh host files
Fix inconsistent tab/space usage and bring function definitions
into a single-line format, matching kernel coding style.
Signed-off-by: LiangCheng Wang <zaq14760@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
LiangCheng Wang [Sat, 26 Jul 2025 07:53:13 +0000 (15:53 +0800)]
staging: media: atomisp: use designated initializer in anr config
Improve readability by using designated initializer for
default_anr_config.
Signed-off-by: LiangCheng Wang <zaq14760@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
LiangCheng Wang [Sat, 26 Jul 2025 07:53:12 +0000 (15:53 +0800)]
staging: media: atomisp: fix indentation in anr files
Fix inconsistent tab/space usage and bring function definitions
into a single-line format, matching kernel coding style.
Signed-off-by: LiangCheng Wang <zaq14760@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
LiangCheng Wang [Sat, 26 Jul 2025 07:53:11 +0000 (15:53 +0800)]
staging: media: atomisp: improve kernel-doc for ia_css_aa_config
Move kernel-doc comment for strength field in
ia_css_aa_config from inline to structure-level comment
for better readability and tooling compatibility.
Signed-off-by: LiangCheng Wang <zaq14760@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Feng Ning [Sun, 12 Apr 2026 00:05:08 +0000 (00:05 +0000)]
staging: media: atomisp: use array3_size() for overflow-safe allocation
Replace open-coded width * height * sizeof() multiplications with
array3_size() to prevent integer overflow in buffer allocations.
The atomisp driver computes DVS, morphing table, shading table and
statistics buffer sizes using unchecked arithmetic. When dimensions
are attacker-controlled or simply large, the product can silently wrap,
causing kvmalloc() to allocate an undersized buffer.
array3_size() saturates to SIZE_MAX on overflow, so kvmalloc() returns
NULL instead of succeeding with too few bytes.
Signed-off-by: Feng Ning <feng@innora.ai> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Arnd Bergmann [Wed, 20 May 2026 10:19:01 +0000 (12:19 +0200)]
Merge tag 'renesas-drivers-for-v7.2-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/drivers
Renesas driver updates for v7.2
- Add Multifunctional Interface (MFIS) mailbox and product register
support for R-Car X5H,
- Miscellaneous fixes and improvements.
* tag 'renesas-drivers-for-v7.2-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
soc: renesas: Convert to of_machine_get_match()
soc: renesas: Add R-Car X5H PRR support
soc: renesas: Add Renesas R-Car MFIS driver
dt-bindings: soc: renesas: Document MFIS IP core
soc: renesas: r9a09g057-sys: Move common code to a helper
soc: renesas: r9a09g056-sys: Move common code to a helper
soc: renesas: r9a09g047-sys: Move common code to a helper
soc: renesas: r9a08g046-sysc: Move common code to a helper
soc: renesas: r9a08g045-sysc: Move common code to a helper
projects / thirdparty / kernel / linux.git / log
