iio: adc: ti-ads7950: switch to using devm_regulator_get_enable_read_voltage()
The regulator is enabled for the entire time the driver is bound to the
device, and we only need to access it to fetch voltage, which can be
done at probe time.
Switch to using devm_regulator_get_enable_read_voltage() which
simplifies probing and unbinding code.
Suggested-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Tested-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Improve the ltc2309_chip_info structure with better type safety and
memory efficiency:
- Add __counted_by_ptr() annotation to the channels pointer, linking
it to num_channels for improved bounds checking and kernel hardening
- Reorder structure fields to minimize padding:
* Place read_delay_us before num_channels
* This reduces struct size and eliminates internal gaps
- Reorder field initialization to match the structure definition order
The __counted_by_ptr() attribute enables compile-time and runtime
verification that array accesses to channels[] stay within the bounds
specified by num_channels, improving memory safety.
Signed-off-by: Carlos Jones Jr <carlosjr.jones@analog.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Carlos Jones Jr [Tue, 31 Mar 2026 01:24:56 +0000 (09:24 +0800)]
iio: adc: ltc2309: add read delay for ltc2305
The LTC2305 requires a minimum 1.6μs delay between the I2C write
operation (channel selection) and the subsequent read operation to
allow the chip to process the command and prepare the result. While
not explicitly documented in the datasheet, this timing requirement
was identified by the hardware designer as necessary for reliable
operation.
Add a read_delay_us field to both the ltc2309_chip_info and ltc2309
device structures to support chip-specific timing requirements. Use
fsleep() to implement the delay when non-zero, with LTC2305 set to
2μs (1.6μs requirement rounded up). LTC2309 does not require
additional delay beyond inherent I2C bus timing.
This extends the existing LTC2305 support added in
(commit 8625d418d24b ("iio: adc: ltc2309: add support for ltc2305"))
with the missing inter-transaction delay.
Signed-off-by: Carlos Jones Jr <carlosjr.jones@analog.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Francesco Lavra [Tue, 24 Mar 2026 08:48:07 +0000 (09:48 +0100)]
iio: imu: st_lsm6dsx: Add support for rotation sensor
Some IMU chips in the LSM6DSX family have sensor fusion features that
combine data from the accelerometer and gyroscope. One of these features
generates rotation vector data and makes it available in the hardware
FIFO as a quaternion (more specifically, the X, Y and Z components of the
quaternion vector, expressed as 16-bit half-precision floating-point
numbers).
Add support for a new sensor instance that allows receiving sensor fusion
data, by defining a new struct st_lsm6dsx_fusion_settings (which contains
chip-specific details for the sensor fusion functionality), and adding this
struct as a new field in struct st_lsm6dsx_settings. In st_lsm6dsx_core.c,
populate this new struct for the LSM6DSV and LSM6DSV16X chips, and add the
logic to initialize an additional IIO device if this struct is populated
for the hardware type being probed.
Note: a new IIO device is being defined (as opposed to adding channels to
an existing device) because the rate at which sensor fusion data is
generated may not match the data rate from any of the existing devices.
Tested on LSM6DSV16X.
Signed-off-by: Francesco Lavra <flavra@baylibre.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Francesco Lavra [Tue, 24 Mar 2026 08:47:59 +0000 (09:47 +0100)]
iio: ABI: Add quaternion axis modifier
This modifier applies to the IIO_ROT channel type, and indicates a data
representation that specifies the {x, y, z} components of the normalized
quaternion vector.
Signed-off-by: Francesco Lavra <flavra@baylibre.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Francesco Lavra [Tue, 24 Mar 2026 08:47:53 +0000 (09:47 +0100)]
iio: ABI: Add support for floating-point numbers in buffer scan elements
In the data storage description of a scan element, the first character
after the colon can have the values 's' and 'u' to specify signed and
unsigned integers, respectively.
Add 'f' as an allowed value to specify floating-point numbers formatted
according to the IEEE 754 standard.
Signed-off-by: Francesco Lavra <flavra@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Francesco Lavra [Tue, 24 Mar 2026 08:47:40 +0000 (09:47 +0100)]
iio: Replace 'sign' field with union in struct iio_scan_type
This field is used to differentiate between signed and unsigned integers.
A following commit will extend its use in order to add support for non-
integer scan elements; therefore, replace it with a union that contains a
more generic 'format' field. This union will be dropped when all drivers
are changed to use the format field.
Opportunistically replace character literals with symbolic constants that
represent the set of allowed values for the format field.
Signed-off-by: Francesco Lavra <flavra@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Francesco Lavra [Tue, 24 Mar 2026 08:47:33 +0000 (09:47 +0100)]
iio: imu: st_lsm6dsx: Fix check for invalid samples from FIFO
The DRDY_MASK feature implemented in sensor chips marks gyroscope and
accelerometer invalid samples (i.e. samples that have been acquired during
the settling time of sensor filters) with the special values 0x7FFFh,
0x7FFE, and 0x7FFD.
The driver checks FIFO samples against these special values in order to
discard invalid samples; however, it does the check regardless of the type
of samples being processed, whereas this feature is specific to gyroscope
and accelerometer data. This could cause valid samples to be discarded.
Fix the above check so that it takes into account the type of samples being
processed. To avoid casting to __le16 * when checking sample values, clean
up the type representation for data read from the FIFO.
Fixes: 960506ed2c69 ("iio: imu: st_lsm6dsx: enable drdy-mask if available") Signed-off-by: Francesco Lavra <flavra@baylibre.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Andy Shevchenko [Thu, 19 Feb 2026 14:39:36 +0000 (15:39 +0100)]
iio: adc: ad7191: Don't check for specific errors when parsing properties
Instead of checking for the specific error codes (that can be considered
a layering violation to some extent) check for the property existence first
and then either parse it, or apply a default value.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
David Lechner [Sun, 1 Mar 2026 23:46:48 +0000 (17:46 -0600)]
iio: orientation: hid-sensor-rotation: use ext_scan_type
Make use of ext_scan_type to handle the dynamic realbits size of the
quaternion data. This lets us implement it using static data rather than
having to duplicate the channel info for each driver instance.
Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
David Lechner [Sat, 14 Mar 2026 21:38:25 +0000 (16:38 -0500)]
iio: imu: bno055: add explicit scan buf layout
Move the scan buf.chans array into a union along with a struct that
gives the layout of the buffer with all channels enabled.
Although not technically required in this case, if there had been a
different number of items before the quaternion, there could have been
a subtle bug with the special alignment needed for the quaternion
channel data and the array would have been too small.
Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
David Lechner [Sun, 8 Mar 2026 01:44:13 +0000 (19:44 -0600)]
iio: buffer: fix timestamp alignment when quaternion in scan
Fix timestamp alignment when a scan buffer contains an element larger
than sizeof(int64_t). Currently s32 quaternions are the only such
element, and the one driver that has this (hid-sensor-rotation) has a
workaround in place already so this change does not affect it.
Previously, we assumed that the timestamp would always be 8-byte aligned
relative to the end of the scan buffer, but in the case of a scan buffer
a 16-byte quaternion vector, scan_bytes == 32, but the timestamp needs
to be placed at offset 16, not 24.
ts_offset is now a value in bytes so we have to change how the array
access is done.
Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
David Lechner [Sun, 8 Mar 2026 01:44:12 +0000 (19:44 -0600)]
iio: buffer: ensure repeat alignment is a power of two
Use roundup_pow_of_two() in the calculation of iio_storage_bytes_for_si()
when scan_type->repeat > 1 to ensure that the size is a power of two.
storagebits is always going to be a power of two bytes, so we only need
to apply this to the repeat factor. The storage size is also used for
alignment, and we want to ensure that all alignments are a power of two.
The only repeat in use in the kernel currently is for quaternions, which
have a repeat of 4, so this does not change the result for existing
users.
Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
David Lechner [Sun, 8 Mar 2026 01:44:11 +0000 (19:44 -0600)]
iio: buffer: cache timestamp offset in scan buffer
Cache the offset (in bytes) for the timestamp element in a scan buffer.
This will be used later to ensure proper alignment of the timestamp
element in the scan buffer.
The new field could not be placed in struct iio_dev_opaque because we
will need to access it in a static inline function later, so we make it
__private instead. It is only intended to be used by core IIO code.
Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
David Lechner [Sun, 8 Mar 2026 01:44:10 +0000 (19:44 -0600)]
iio: buffer: check return value of iio_compute_scan_bytes()
Check return value of iio_compute_scan_bytes() as it can return an
error.
The result is moved to an output parameter while we are touching this
as we will need to add a second output parameter in a later change.
The return type of iio_buffer_update_bytes_per_datum() also had to be
changed to propagate the error.
Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Change the drm_err to drm_dbg_kms when we fail to read the FEC
capability. This is mainly because this is called from intel_dp_detect.
Which ends up in race more frequently in case of MST scenarios,
when we are disabling streams but the downstream Dock still sends
signals which causes intel_dp_detect to be invoked which has DPCD
reads. These pass until the Transcoder and DPLL go down causing
AUX to go down too. At this point AUX Timeouts are expected and not
an issue. But this drm_err gets flagged in CI causing noise even
for passing scenarios.
The da node block header (xfs_da3_node_hdr) contains a __pad32 field
that should always be zero. Add a check for this during directory and
attribute btree scrubbing.
Since old kernels may have written non-zero padding without issues, flag
this as an optimization opportunity (preen) rather than corruption.
Signed-off-by: Yuto Ohnuki <ytohnuki@amazon.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs: fix memory leak for data allocated by xfs_zone_gc_data_alloc()
In xfs_zone_gc_mount(), on error, a struct xfs_zone_gc_data allocated
with xfs_zone_gc_data_alloc() is freed with kfree(), however, this
doesn't free the underlying folios or the rmap_irecs.
Use xfs_zone_gc_data_free() to correctly free this memory.
Fixes: 080d01c41d44 ("xfs: implement zoned garbage collection") Cc: stable@vger.kernel.org # v6.15 Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs: fix memory leak on error in xfs_alloc_zone_info()
Currently, the 0th index of the zi_used_bucket_bitmap array is not freed
on error due to the pre-decrement then evaluate semantic of the while
loop used in xfs_alloc_zone_info(). Fix it by allowing for the i == 0
case to be covered.
Fixes: 080d01c41d44 ("xfs: implement zoned garbage collection") Cc: stable@vger.kernel.org # v6.15 Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs: check directory data block header padding in scrub
Add the missing scrub check for the pad field in directory data block
headers. Old kernels may have written non-zero padding without issue,
and the write path now self-heals stale padding on modification. Flag
non-zero padding as an optimization opportunity (preen) rather than
corruption.
Add xchk_fblock_set_preen helper for reporting file fork block issues
that could be optimized. The trace event xchk_fblock_preen already
exists.
Signed-off-by: Yuto Ohnuki <ytohnuki@amazon.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs: zero directory data block padding on write verification
Old kernels did not zero the pad field in xfs_dir3_data_hdr when
initializing directory data blocks, so existing filesystems may have
non-zero padding on disk.
Zero the pad field in xfs_dir3_data_write_verify alongside the existing
LSN and checksum updates. The pad field is pure alignment padding with
no runtime meaning, so zeroing it during write verification is safe and
has no additional I/O cost. This lets filesystems gradually self-heal
stale non-zero padding as directories are modified, without requiring an
explicit repair pass.
Suggested-by: Dave Chinner <dgc@kernel.org> Signed-off-by: Yuto Ohnuki <ytohnuki@amazon.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs: zero entire directory data block header region at init
xfs_dir3_data_init currently zeroes only the xfs_dir3_blk_hdr portion of
the directory data block header, then manually initializes the bestfree
entries in a loop. This leaves the pad field in xfs_dir3_data_hdr
uninitialized and requires explicit zeroing of each bestfree slot.
Zero the entire header region (geo->data_entry_offset bytes)
unconditionally before setting individual fields. This covers all
current and future header fields, all padding (implicit and explicit),
and the bestfree array, so the manual zeroing loop for bestfree can be
removed.
Suggested-by: Dave Chinner <dgc@kernel.org> Signed-off-by: Yuto Ohnuki <ytohnuki@amazon.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs: remove the meaningless XFS_ALLOC_FLAG_FREEING
In xfs_refcount_finish_one(), there's no need to pass
XFS_ALLOC_FLAG_FREEING to xfs_alloc_read_agf().
So remove it.
Signed-off-by: Jinliang Zheng <alexjlzheng@tencent.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
Til Kaiser [Mon, 13 Apr 2026 13:52:34 +0000 (15:52 +0200)]
pinctrl: qcom: ipq4019: mark gpio as a GPIO pin function
The qcom pinctrl core supports marking functions that represent GPIO mode
via PINCTRL_GPIO_PINFUNCTION(), so that strict pinmuxing does not reject
GPIO requests for pins that are muxed to the GPIO function.
ipq4019 still describes its gpio function with QCA_PIN_FUNCTION(gpio),
so it is not treated as a GPIO pin function. As a result, GPIO consumers
can still conflict with pinctrl states that select the "gpio" function.
Add a QCA_GPIO_PIN_FUNCTION() helper and use it for the ipq4019 gpio
function, matching how the msm-based qcom drivers handle this.
This allows ipq4019 to keep the GPIO-related pin configuration in DTS
without tripping over strict pinmux ownership checks.
Fixes: cc85cb96e2e4 ("pinctrl: qcom: make the pinmuxing strict") Signed-off-by: Til Kaiser <mail@tk154.de> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
Using the kernel's preferred types eliminates a source of friction for many
contributors, as the majority of KVM selftests contributions come from kernel
developers. The kernel names are also shorter, which allows for more concise
code, and in any many cases eliminates newlines thanks to shorter types and
parameter names.
Rename variables and parameters as well as types, e.g. gpa instead of paddr,
to again align with the kernel, and in a few cases to remove ambiguity, e.g.
where paddr is used to refer to a _host_ physical address.
Paolo Bonzini [Mon, 27 Apr 2026 08:24:34 +0000 (04:24 -0400)]
Merge tag 'kvmarm-fixes-7.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD
KVM/arm64 fixes for 7.1, take #1
- Allow tracing for non-pKVM, which was accidentally disabled when
the series was merged
- Rationalise the way the pKVM hypercall ranges are defined by using
the same mechanism as already used for the vcpu_sysreg enum
- Enforce that SMCCC function numbers relayed by the pKVM proxy are
actually compliant with the specification
- Fix a couple of feature to idreg mappings which resulted in the
wrong sanitisation being applied
- Fix the GICD_IIDR revision number field that could never been
written correctly by userspace
- Make kvm_vcpu_initialized() correctly use its parameter instead
of relying on the surrounding context
- Enforce correct ordering in __pkvm_init_vcpu(), plugging a
potential pin leak at the same time
- Move __pkvm_init_finalise() to a less dangerous spot, avoiding
future problems
- Restore functional userspace irqchip support after a four year
breakage (last functional kernel was 5.18...). This is obviously
ripe for garbage collection.
KVM: selftests: Add check_steal_time_uapi() implementation for LoongArch
Define check_steal_time_uapi() for LoongArch so that the steal_time test
builds. Note, while LoongArch's steal_time_init() has some funky asserts,
none of the code is uniquely verifying KVM's uAPI.
Cc: Jiakai Xu <xujiakai2025@iscas.ac.cn> Cc: Jiakai Xu <jiakaiPeanut@gmail.com> Cc: Andrew Jones <andrew.jones@oss.qualcomm.com> Cc: Anup Patel <anup@brainfault.org> Cc: Tianrui Zhao <zhaotianrui@loongson.cn> Cc: Bibo Mao <maobibo@loongson.cn> Cc: Huacai Chen <chenhuacai@kernel.org> Fixes: 40351ed924dd ("KVM: selftests: Refactor UAPI tests into dedicated function") Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260420192644.3892050-1-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
gpio: ep93xx: use handle_bad_irq() as default IRQ handler
Replace the temporary fallback handle_simple_irq with handle_bad_irq
now that the driver operates with a proper hierarchical IRQ setup.
This ensures unexpected or unmapped interrupts are clearly flagged
instead of being silently handled.
mm/slab: return NULL early from kmalloc_nolock() in NMI on UP
On UP kernels (!CONFIG_SMP), spin_trylock() is a no-op that
unconditionally succeeds even when the lock is already held. As a
result, kmalloc_nolock() called from NMI context can re-enter the slab
allocator and acquire n->list_lock that the interrupted context is
already holding, corrupting slab state.
With CONFIG_DEBUG_SPINLOCK on UP, the following BUG is triggered with
the slub_kunit test module:
BUG: spinlock trylock failure on UP on CPU#0, kunit_try_catch/243
[...]
Call Trace:
<NMI>
dump_stack_lvl+0x3f/0x60
do_raw_spin_trylock+0x41/0x50
_raw_spin_trylock+0x24/0x50
get_from_partial_node+0x120/0x4d0
___slab_alloc+0x8a/0x4c0
kmalloc_nolock_noprof+0x164/0x310
[...]
</NMI>
Fix this by returning NULL early when invoked from NMI on a UP kernel.
mm/page_alloc: return NULL early from alloc_frozen_pages_nolock() in NMI on UP
On UP kernels (!CONFIG_SMP), spin_trylock() is a no-op that
unconditionally succeeds even when the lock is already held. As a
result, alloc_frozen_pages_nolock() called from NMI context can
re-enter rmqueue() and acquire the zone lock that the interrupted
context is already holding, corrupting the freelists.
With CONFIG_DEBUG_SPINLOCK on UP, the following BUG is triggered with
the slub_kunit test module:
BUG: spinlock trylock failure on UP on CPU#0, kunit_try_catch/243
[...]
Call Trace:
<NMI>
dump_stack_lvl+0x3f/0x60
do_raw_spin_trylock+0x41/0x50
_raw_spin_trylock+0x24/0x50
rmqueue.isra.0+0x2a9/0xa70
get_page_from_freelist+0xeb/0x450
alloc_frozen_pages_nolock_noprof+0x111/0x1e0
allocate_slab+0x42a/0x500
___slab_alloc+0xa7/0x4c0
kmalloc_nolock_noprof+0x164/0x310
[...]
</NMI>
Fix this by returning NULL early when invoked from NMI on a UP kernel.
tools/nolibc: make __nolibc_enosys() a compile time error
Functions which are known at compile-time to result in ENOSYS can be
surprising to the user. For example using old UAPI headers might mean
that stat() will always fail although the kernel would have the system
call available at runtime. Nowadays __nolibc_enosys() should never be
called for normal applications.
Switch the silent ENOSYS return into a compile-time error, so the user
is aware about the issue. Prefer the 'error' attribute as it provides
the best diagnostics. If the users defines NOLIBC_COMPILE_TIME_ENOSYS
the old, silent fallback is kept.
Also add a test which validates that the error can be optimized away.
Add the wide-used alloca() function. As it is highly machine and
compiler dependent, just defer to the compiler builtin. This has
been available since GCC 4 and clang 3.
Wenmeng Liu [Fri, 13 Mar 2026 10:13:04 +0000 (18:13 +0800)]
media: qcom: camss: Add missing clocks for VFE lite on sa8775p
Add missing required clocks (cpas_ahb and camnoc_axi) for VFE lite
instances on sa8775p platform. These clocks are necessary for proper
VFE lite operation:
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com> Fixes: e7b59e1d06fb ("media: qcom: camss: Add support for VFE 690") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue <bod@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Wenmeng Liu [Fri, 13 Mar 2026 10:13:03 +0000 (18:13 +0800)]
media: qcom: camss: Fix csid clock configuration for sa8775p
Fix the mismatch between clock list and clock rate table for CSID lite
instances. The current implementation has 5 clocks defined but only 2
are actually needed (vfe_lite_csid and vfe_lite_cphy_rx), while the
clock rate table doesn't match this configuration.
Update both clock list and rate table to maintain consistency:
- Remove unused clocks: cpas_vfe_lite, vfe_lite_ahb, vfe_lite
- Update clock rate table to match the remaining two clocks
Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Fixes: ed03e99de0fa ("media: qcom: camss: Add support for CSID 690") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue <bod@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Dmitry Baryshkov [Fri, 27 Mar 2026 20:19:55 +0000 (22:19 +0200)]
media: qcom: iris: increase H265D_MAX_SLICE to fix H.265 decoding on SC7280
Follow the commit bfe1326573ff ("venus: Fix for H265 decoding failure.")
and increase H265D_MAX_SLICE following firmware requirements on that
platform. Otherwise decoding of the H.265 streams fails with the
"insufficient scratch_1 buffer size" from the firmware.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
[bod: Fixed commit log withthe => with the] Fixes: e1f5d32608ec ("media: iris: Add internal buffer calculation for HEVC and VP9 decoders") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue <bod@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Vishnu Reddy [Thu, 5 Mar 2026 13:28:31 +0000 (18:58 +0530)]
media: iris: fix use-after-free of fmt_src during MBPF check
During concurrency testing, multiple instances can run in parallel, and
each instance uses its own inst->lock while the core->lock protects the
list of active instances. The race happens because these locks cover
different scopes, inst->lock protects only the internals of a single
instance, while the Macro Blocks Per Frame (MBPF) checker walks the
core list under core->lock and reads fields like fmt_src->width and
fmt_src->height. At the same time, iris_close() may free fmt_src and
fmt_dst under inst->lock while the instance is still present in the core
list. This allows a situation where the MBPF checker, still iterating
through the core list, reaches an instance whose fmt_src was already
freed by another thread and ends up dereferencing a dangling pointer,
resulting in a use-after-free. This happens because the MBPF checker
assumes that any instance in the core list is fully valid, but the
freeing of fmt_src and fmt_dst without removing the instance from the
core list is not correct.
The correct ordering is to defer freeing fmt_src and fmt_dst until after
the instance has been removed from the core list and all teardown under
the core lock has completed, ensuring that no dangling pointers are ever
exposed during MBPF checks.
Vikash Garodia [Fri, 13 Mar 2026 13:19:36 +0000 (18:49 +0530)]
media: iris: switch to hardware mode after firmware boot
Currently the driver switches the vcodec GDSC to hardware (HW) mode
before firmware load and boot sequence. GDSC can be powered off, keeping
in hw mode, thereby the vcodec registers programmed in TrustZone (TZ)
carry default (reset) values.
Move the transition to HW mode after firmware load and boot sequence.
The bug was exposed with driver configuring different stream ids to
different devices via iommu-map. With registers carrying reset values,
VPU would not generate desired stream-id, thereby leading to SMMU fault.
For vpu4, when GDSC is switched to HW mode, there is a need to perform
the reset operation. Without reset, there are occasional issues of
register corruption observed. Hence the vpu GDSC switch also involves
the reset.
Dikshita Agarwal [Mon, 16 Feb 2026 07:07:42 +0000 (12:37 +0530)]
media: iris: Fix use-after-free in iris_release_internal_buffers()
The recent change in commit 1dabf00ee206 ("media: iris: gen1: Destroy
internal buffers after FW releases") introduced a regression where
session_release_buf() may free the buffer. The caller,
iris_release_internal_buffers(), continued to access `buffer` after the
call, leading to a potential use-after-free.
Fix this by setting BUF_ATTR_PENDING_RELEASE before calling
session_release_buf(), and reverting the flag if the call fails. This
ensures no dereference occurs after potential freeing.
Arnd Bergmann [Thu, 5 Feb 2026 14:56:19 +0000 (15:56 +0100)]
media: iris: fix QCOM_MDT_LOADER dependency
When build-testined with CONFIG_QCOM_MDT_LOADER=m and VIDEO_QCOM_IRIS=y,
the kernel fails to link:
x86_64-linux-ld: drivers/media/platform/qcom/iris/iris_firmware.o: in function `iris_fw_load':
iris_firmware.c:(.text+0xb0): undefined reference to `qcom_mdt_get_size'
iris_firmware.c:(.text+0xfd): undefined reference to `qcom_mdt_load'
The problem is the conditional 'select' statement. Change this to
make the driver built-in here regardless of CONFIG_ARCH_QCOM.
Arnd Bergmann [Mon, 30 Mar 2026 11:08:21 +0000 (12:08 +0100)]
media: venus: fix QCOM_MDT_LOADER dependency
When build-testined with CONFIG_QCOM_MDT_LOADER=m and VIDEO_QCOM_VENUS=y,
the kernel fails to link:
x86_64-linux-ld: drivers/media/platform/qcom/venus/firmware.o: in function `venus_boot':
firmware.c:(.text+0x1e3): undefined reference to `qcom_mdt_get_size'
firmware.c:(.text+0x25a): undefined reference to `qcom_mdt_load'
firmware.c:(.text+0x272): undefined reference to `qcom_mdt_load_no_init'
The problem is the conditional 'select' statement. Change this to
make the driver built-in here regardless of CONFIG_ARCH_QCOM,
same as for the similar IRIS driver.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Fixes: 0399b696f7f4 ("media: venus: fix compile-test build on non-qcom ARM platform") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue <bod@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Konrad Dybcio [Mon, 13 Apr 2026 09:02:43 +0000 (11:02 +0200)]
thunderbolt: debugfs: Don't stop reading SB registers if just one fails
The GEN4 TxFFE register is not part of the USB4 v1.0 specification, so
understandably some pre-USB4v2 retimers (like the Parade PS8830) don't
seem to implement it.
The immediate idea to counter this would be to introduce a version
check for that specific register, but on a second thought, the current
flow only returns a quiet -EIO if there's any failures, without hinting
at what the actual problem is.
To take care of both of these issues, simply print an error line for
each SB register read that fails and go on with attempting to read the
others.
Note that this is not quite in-spec behavior ("The SB Register Space
registers shall have the structure and fields described in Table 4-17.
Registers not listed in Table 4-20 are undefined and shall not be
used."), but it's the easiest fix that shouldn't have real-world bad
side effects.
Fixes: 6d241fa00159 ("thunderbolt: Add sideband register access to debugfs") Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Input: xpad - fix out-of-bounds access for Share button
xpadone_process_packet() receives len directly from urb->actual_length
and uses it to index the share-button byte at data[len - 18] or
data[len - 26]. Since both len and data[0] are under the device's
control, a broken controller can send a GIP_CMD_INPUT packet with
actual_length < 18 (e.g. 5 bytes) and reach this code path, causing
accesses beyond the actual array.
Fix this by calculating the offset and checking bounds against the
packet length.
Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Fixes: 4ef46367073b ("Input: xpad - fix Share button on Xbox One controllers") Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Sandie Cao [Tue, 21 Apr 2026 06:43:06 +0000 (14:43 +0800)]
riscv: dts: spacemit: add DeepComputing FML13V05 board device tree
The FML13V05 board from DeepComputing incorporates a SpacemiT K3 RISC-V
SoC.It is a mainboard designed for the Framework Laptop 13 Chassis,
which has (Framework) SKU FRANHQ0001.
The FML13V05 board features:
- SpacemiT K3 RISC-V SoC
- LPDDR5 16GB or 32GB
- eMMC 32GB ~128GB (Optional)
- UFS 3.1 256G (Optional)
- QSPI Flash
- MicroSD Slot
- PCIe-based Wi-Fi
- 4 USB-C Ports
- Port 1: PD 3.0 (65W Max), USB 3.2 Gen 1
- Port 2: PD 3.0 (65W Max), USB 3.2 Gen 1, DP 1.4 (4K@60Hz)
- Port 3 & 4: USB 3.2 Gen 1
This minimal device tree enables booting into a serial console with UART
output.
Document the compatible string for the Deepcomputing fml13v05.
It's based on the SpacemiT K3 RISC-V SoC and is designed for the Framework
Laptop 13 Chassis, which has (Framework) SKU FRANHQ0001.
Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Sandie Cao <sandie.cao@deepcomputing.io> Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Reviewed-by: Yixun Lan <dlan@kernel.org> Link: https://lore.kernel.org/r/20260421064200.1582367-1-sandie.cao@deepcomputing.io Signed-off-by: Yixun Lan <dlan@kernel.org>
Input: usbtouchscreen - clamp NEXIO data_len/x_len to URB buffer size
nexio_read_data() pulls data_len and x_len from a packed __be16 header
in the device's interrupt packet and then walks packet->data[0..x_len)
and packet->data[x_len..data_len) comparing each byte against a
threshold.
Both fields are 16-bit on the wire (max 65535). The existing
adjustments shave at most 0x100 / 0x80 off, so the loop bound can still
reach roughly 0xfeff. The URB transfer buffer for NEXIO is rept_size
(1024) bytes from usb_alloc_coherent(), with the first 7 occupied by the
packed header — so packet->data[] has 1017 valid bytes. read_data()
callbacks are not given urb->actual_length, and nothing else bounds the
walk.
A device that lies about its length can get a ~64 KiB out-of-bounds read
past the coherent DMA allocation. The first index whose byte exceeds
NEXIO_THRESHOLD lands in begin_x / begin_y and from there into the
reported touch coordinates, so adjacent kernel memory contents leak to
userspace as ABS_X / ABS_Y events. Far enough out, the read can also
hit an unmapped page and fault.
Fix this all by clamping data_len to the buffer's data[] capacity and
x_len to data_len.
====================
Introduce arena library and runtime
Add a new subdirectory to tools/testing/selftests/bpf called libarena,
along with programs useful for writing arena-based BPF code. This
patchset adds the following:
1) libarena, a subdirectory where arena BPF code that is generally useful
to BPF arena programs can be easily added and tested.
2) An ASAN runtime for BPF arena programs. BPF arenas allow for accessing
memory after it has been freed or if it is out of bounds, making it more
difficult to triage bugs combined to regular BPF. Use LLVM's recently added
support for address-space based sanitization to selectively sanitize just
the arena accesses.
3) A buddy memory allocator that can be reused by BPF programs to handle
memory allocation/deletion. The allocator uses the ASAN runtime to add
address sanitization if requested.
The patch includes testing for the new allocators and ASAN features that
can be built from the top directory using "make libarena_test" and
"make libarena_test_asan". The generated binaries reside in libarena/.
The patch also adds test-progs-based selftests to the codebase for the
libarena code, so the new tests are run by ./test_progs.
The patchset has the following stucture:
1-3: Create basic libarena scaffolding and refactor existing headers.
4-5: Add the ASAN runtime and associated scaffolding.
6-8: Add the new buddy memory allocator along with selftests.
Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com>
HISTORY
=======
v8->v9 (https://lore.kernel.org/bpf/20260421165037.4736-1-emil@etsalapatis.com)
- Added Matt's Acked-by for Patch 1
- Replaced open coded fls with __builtin based calculation (Matt)
- Add comment explaining the reasoning behind the zero variable (Matt)
- Remove the self-contained runner and present selftests as examples (Kumar).
The reasoning is that including selftests with the library is not
effective because the library will be sync'ed outside the tree
infrequently, so it would be ineffective in catching issues before
they land.
- Adjust syscall API for clarity and forward compatibility (Matt)
- Reset asan_validate state after failed check (Sashiko)
- Fix printf format specifier (Sashiko)
- Rename syscall to be generic arena_info (Matt)
- Namespace libarena headers by moving them to their own directory
- Rename selftest_helpers to libarena/userspace.h to reflect it is not
just for selftests.
v7->v8 (https://lore.kernel.org/bpf/20260412174546.18684-1-emil@etsalapatis.com)
- Duplicate READ_ONCE/WRITE_ONCE instead of moving it to
bpf_experimental.h to keep libarena self-contained (Kumar)
- Add libarena_asan test to test_progs and conditionally compile it if
suppported (Kumar)
- Add stderr parsing for buddy tests when run under test_progs (Kumar)
- Move all arena-related headers into libarena and add its include/
subdirectory in the standard include path (Kumar)
- Remove silent-by-default ASAN, add help message on test_libarena
explaining that -v emits the messages (Kumar)
- Add run_prog_args as a libarena helper
- Add explanation on the use of __weak for the spinlock qnodes
v6->v7 (https://lore.kernel.org/bpf/20260412011857.3387-1-emil@etsalapatis.com)
- Modify patch 1 to allow operations between PTR_TO_ARENA src_reg
and dst_reg of any type. Adjust selftests accordingly (Alexei)
- Remove unnecessary include in patch 5 (Song)
- Removed unused definitions/assignments in patches 8/9, update patch
descriptions
v5->v6 (https://lore.kernel.org/bpf/20260410163041.8063-1-emil@etsalapatis.com)
- Fix subreg_def management for SCALAR += PTR_TO_ARENA operations (AI)
- Add more selftests for the SCALAR += PTR_TO_ARENA patch (Sashiko)
- Adjust fls() operation to be in line with the kernel version (Sashiko)
- Address Sashiko selftests and debugging nits
- Add ASAN loadN and storeN _noabort variants and associated BTF anchor
- Remove unnecessary bit freeing of buddies during block splitting
v4->v5 (https://lore.kernel.org/bpf/20260407045730.13359-1-emil@etsalapatis.com)
Omitting various nits and fixups.
- Properly adjust subreg_def for scalar += ptr_to_arena calls (Sashiko)
- Remove extraneous definition from prog_tests/arena_spin_lock.c (Song)
- Trim extraneous comments from ASAN and buddy (Alexei)
- Remove asan_dummy call and replace with function pointer array (Alexei)
- Remove usersapi.h header and merge it into common.h (Alexei)
- Replace ASAN macros with function calls (Alexei)
- Embed buddy lock into the struct and move the buddy allocator to __arena_global
(Alexei)
- Add commenting for buddy allocator constants (Alexei)
- Add default buddy allocator directly in common.bpf.c, so that the user does
not need to define it.
- Expand test harnesses to dynamically find individual selftests. Now the
selftests also reports each test individually (e.g., 5 entries for the
buddy allocator instead of 1). This brings them to par with the rest of
the test_progs.
v3->v4 (https://lore.kernel.org/bpf/20260403042720.18862-1-emil@etsalapatis.com)
- Add Acks by Song to patches 1-4.
- Expand the verifier's handling of scalar/arena operations to
include all 3-operand operations in Patch 1 (Alexei)
- Add additional tests for arena/arena (allowed) and arena/pointer (not allowed)
operations in Patch 2
- Remove ASAN version of the library from default compilation since it requires
LLVM 22 and up (CI)
- Rework buddy allocator locking for clarity and add comments
- Fix From: email to be consistent with SOB
- Address (most) Sashiko comments
v2->v3 (https://lore.kernel.org/bpf/20260127181610.86376-1-emil@etsalapatis.com)
Nonexhaustive due to significant patch rework.
- Do not duplicate WRITE_ONCE macro (Mykyta, Kumar)
- Add SPDX headers (Alexei)
- Remove bump/stack allocators (Alexei)
- Integrate testing with test_progs (Kumar)
- Add short description of ASAN algorithm at the top of the file (Alexei)
- Added missing format string argument (AI)
- Fix outdated selftests prog name check (AI)
- Fixed stack allocation check for segment creation (AI)
- Fix errors in non-ASAN bump allocator selftests (AI)
- Propagate error value from individual selftests in selftest.c
- Removed embedded metadata from bump allocator as it was needlessly
complicating its behavior
====================
Emil Tsalapatis [Sun, 26 Apr 2026 19:03:38 +0000 (15:03 -0400)]
selftests/bpf: Reuse stderr parsing for libarena ASAN tests
Add code to directly test the output of libarena ASAN tests.
The code reuses testing infrastructure originally for BPF streams
to verify that ASAN emits call stacks when the selftests trigger
a memory error.
Since stderr() testing uses logic from test_progs, it is only
available on the test_progs-based selftest runner. The standalone
runner still uses internal ASAN state to verify access errors are
triaged as expected.
Emil Tsalapatis [Sun, 26 Apr 2026 19:03:37 +0000 (15:03 -0400)]
selftests/bpf: Add selftests for libarena buddy allocator
Introduce selftests for the buddy allocator with and without
ASAN. Add the libarena selftests both to the libarena test
runner and to test_progs, so that they are a) available when
libarena is pulled as a standalone library, and b) exercised
along with all other test programs in this directory.
ASAN for libarena requires LLVM 22. Add logic in the top-level
selftests Makefile to only compile the ASAN variant if the
compiler supports it, otherwise skip the test.
Emil Tsalapatis [Sun, 26 Apr 2026 19:03:36 +0000 (15:03 -0400)]
selftests/bpf: Add buddy allocator for libarena
Add a byte-oriented buddy allocator for libarena. The buddy
allocator provides an alloc/free interface for small arena allocations
ranging from 16 bytes to 512 KiB. Lower allocations values are rounded
up to 16 bytes. The buddy allocator does not handle larger allocations
that can instead use the existing bpf_arena_{alloc, free}_pages() kfunc.
Emil Tsalapatis [Sun, 26 Apr 2026 19:03:35 +0000 (15:03 -0400)]
selftests/bpf: Add ASAN support for libarena selftests
Expand the arena library selftest infrastructure to support
address sanitization. Add the compiler flags necessary to
compile the library under ASAN when supported.
Emil Tsalapatis [Sun, 26 Apr 2026 19:03:34 +0000 (15:03 -0400)]
selftests/bpf: Add arena ASAN runtime to libarena
Add an address sanitizer (ASAN) runtime to the arena library. The
ASAN runtime implements the functions injected into BPF binaries
by LLVM sanitization when ASAN is enabled during compilation.
The runtime also includes functions called explicitly by memory
allocation code to mark memory as poisoned/unpoisoned to ASAN.
This code is a no-op when sanitization is turned off.
Emil Tsalapatis [Sun, 26 Apr 2026 19:03:33 +0000 (15:03 -0400)]
selftests/bpf: Move arena-related headers into libarena
The BPF selftest headers include functionality that is
specific to arenas and is required by libarena. Keep libarena
self-contained by moving all functionality into its include/
directory. Also add libarena/include to the standard include
paths for the selftests to make the moved headers easy to
access by existing selftests.
Some functionality is required by libarena but not strictly
arena-related. We still move it to the libarena/include path,
which is an upgrade from directly accessing them from the
selftests/bpf directory using relative paths.
A new bpf_may_goto.h file is split off of bpf_experimental.h.
bpf_arena_spin_lock.h and bpf_arena_common.h are moved to
libarena/include. bpf_atomic.h is also moved to libarena
because it is necessary for arena spinlocks.
For bpf_arena_spin_lock.h, mark the spinlock state array as __weak
to define the spinlock state array in the header while also
being compatible with multi-compilation unit programs. While
we're at it, we remove unnecessary definitions from existing
test programs.
Emil Tsalapatis [Sun, 26 Apr 2026 19:03:32 +0000 (15:03 -0400)]
selftests/bpf: Add basic libarena scaffolding
Add initial code and a Makefile for an arena-based BPF library. Modules
can be added just by including the source file in the library's src/
subdirectory. Future commits will introduce the library code itself.
The code includes workarounds that are removed in subsequent patches
that ensure bisectability.
Emil Tsalapatis [Sun, 26 Apr 2026 19:03:31 +0000 (15:03 -0400)]
selftests/bpf: Add ifdef guard for WRITE_ONCE macro in bpf_atomic.h
The WRITE_ONCE macro is identically defined both in bpf_atomic.h
and in bpf_arena_common.h. However, the bpf_atomic.h definition has no
ifdef guard. If bpf_atomic.h is included after bpf_arena.common.h,
compilation fails because of the duplicate definition.
Guard the definiton in bpf_atomic.h with and ifdef to let programs
include the two headers in any order. Duplicating the definition is
the simplest solution out of all the alternatives:
- Keeping one of the two existing definitions is not possible because
both BPF atomics and arena programs need the macro, and the two features
are independent. Using one should not require the header for the other.
- Factoring out the definition into a new header that only includes it
is more churn than just duplicating it.
- Factoring out the definition into bpf_experimental.h requires all
users of WRITE_ONCE to include the header. However, the arena library
introduced in subsequent commits must be self-contained, while
bpf_experimental.h is in the base selftests/bpf directory.
Both headers are moved to the arena library in a subsequent patch.
nfsd: fix GET_DIR_DELEGATION when VFS leases are disabled
When leases are disabled on the server, running xfstest generic/309 leads
to an error because GET_DIR_DELEGATION returns EINVAL.
nfsd_get_dir_deleg() can fail in several ways: like memory allocation and
unable to get a lease because either leases are disable or it's already
held. Currently only the condition "already held" is translated to
returning directory-delegation-is-unavailable error. However, other failure
conditions are likely temporary and thus should result in the same kind
of error.
Fixes: 8b99f6a8c116 ("nfsd: wire up GET_DIR_DELEGATION handling") Cc: stable@vger.kernel.org Signed-off-by: Olga Kornievskaia <okorniev@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
The nouveau mailing list has some issues (e.g. with stripping Cc entries
from replies when using notmuch + b4 based workflows).
Besides that, having a separate mailing list for nova also helps to
better distinguish nova from nouveau and makes it easier to track
nova-specific discussions.
Replace the nouveau mailing list with the new nova-gpu@lists.linux.dev
mailing list for both nova-core and nova-drm, and remove the patchwork
entries, since those are bound to the nouveau mailing list and not used
by nova anyway.
====================
selftests/bpf: Use local types for kfunc declarations
The xdp_flowtable and test_tunnel_kern selftests were previously
rewritten to compile with CONFIG_NF_FLOW_TABLE=m and CONFIG_NET_FOU=m.
While the compilation issues were resolved, the tests fail at
runtime. In test_tunnel_kern.c, struct bpf_fou_encap___local is
defined with the correct fields but the kfunc declarations still
reference the forward-declared struct bpf_fou_encap. Similarly,
xdp_flowtable.c uses a forward-declared struct flow_offload_tuple_rhash
as the return type for bpf_xdp_flow_lookup(). Clang emits these forward
declarations as BTF FWD types, which fail to resolve against the
module-defined STRUCT types at run time:
libbpf: extern (func ksym) 'bpf_xdp_flow_lookup': func_proto [51] incompatible with nf_flow_table [128640]
libbpf: extern (func ksym) 'bpf_skb_get_fou_encap': func_proto [79] incompatible with fou [135045]
This patch updates both selftests to use ___local type suffixes
for kernel struct type, replacing the forward declarations.
struct flow_offload_tuple_rhash___local is defined without fields
because the test only uses the returned pointer for a null check.
This avoids needing to locally define its nested types,
struct rhash_head and struct flow_offload_tuple.
I understand that fixing selftests for specific config options is
generally not a priority, but since these tests were already
rewritten to support these configs, they should work correctly
with them.
Fixes: d17f9b370df6 ("selftests/bpf: Fix compilation failure when CONFIG_NET_FOU!=y") Fixes: eeb23b54e447 ("selftests/bpf: fix compilation failure when CONFIG_NF_FLOW_TABLE=m") Signed-off-by: Gregory Bell <grbell@redhat.com>
change log:
[0] https://lore.kernel.org/all/cover.1776280396.git.grbell@redhat.com/
- Add BPF_NO_KFUNC_PROTOTYPES macro to test_tunnel_kern.c so the test compiles
when CONFIG_NET_FOU=y. Without it the function prototypes conflict with vmlinux.h
====================
Gregory Bell [Fri, 17 Apr 2026 15:41:22 +0000 (11:41 -0400)]
selftests/bpf: Use local type for bpf_fou_encap in test_tunnel_kern
Replace the forward-declared struct bpf_fou_encap with the existing
bpf_fou_encap___local type in the bpf_skb_set_fou_encap and
bpf_skb_get_fou_encap declarations. This removes the need for
the forward declaration and the explicit casts at each call.
Gregory Bell [Fri, 17 Apr 2026 15:41:21 +0000 (11:41 -0400)]
selftests/bpf: Use local type for flow_offload_tuple_rhash in xdp_flowtable
Define flow_offload_tuple_rhash___local and use it in place of the
forward-declared kernel type for the bpf_xdp_flow_lookup kfunc return
type and tuplehash variable. This is consistent with how
bpf_flowtable_opts___local is already handled in the same file and
avoids relying on a forward declaration of the struct.
This series adds support for the TI TAS675x (TAS6754, TAS67524)
quad-channel automotive Class-D amplifiers. The devices have an
integrated DSP and load diagnostics, and are controlled over I2C.
Patch 1 adds the dt-binding, patch 2 the codec driver, patch 3 the
ALSA mixer controls documentation, and patch 4 adds the MAINTAINERS
entry.
Tested on AM62D-EVM with a TAS67CD-AEC daughter card. For setup &
test procedures, refer to the GitHub repository.
The TAS675x (TAS6754, TAS67524) are quad-channel, digital-input
Class-D amplifiers with an integrated DSP, controlled over I2C.
They support I2S and TDM serial audio interfaces.
The Tegra210 ADX and AMX drivers both keep their "Byte Map N" ALSA
control state as a byte-packed u32 map[] array along with a separate
byte_mask[] bitmap. This is because the control range exposed to
userspace is [0, 256], where 256 is the "disabled" sentinel and
does not fit in a byte, so the two arrays have to be cross-checked
on every get()/put().
This series stores each slot as a u16 holding the user-visible
value directly, turning get_byte_map() into a direct return and
put_byte_map() into a compare-and-store. The hardware-facing packed
RAM word and the IN_BYTE_EN / OUT_BYTE_EN enable masks are computed
on the fly inside each write_map_ram() callback, which is the only
place that needs to know the hardware layout. The byte_mask[] field
is kept in the driver struct but allocated dynamically in probe()
using devm_kcalloc() with soc_data->byte_mask_size, and zeroed +
recomputed on each write_map_ram() call.
There is no userspace-visible ABI change. Control declarations,
ranges, initial values and handling of out-of-range writes is
preserved by treating values outside [0, 255] as disabled (256),
matching previous behavior. As a side effect each patch also fixes
a latent bug in put_byte_map() where an enabled-to-enabled value
change was not persisted.
The packed RAM word construction is also updated to ensure the shift
operates on a u32 value, avoiding potential undefined behavior due
to signed integer promotion.
Addresses TODO comments left in tegra210_{adx,amx}_get_byte_map().
The byte-map controls ("Byte Map N") already expose a value range of
[0, 256] to userspace via SOC_SINGLE_EXT(), where 256 is the
"disabled" sentinel. The driver stored this state as a byte-packed
u32 map[] array plus a separate byte_mask[] bitmap tracking which
slots were enabled, because 256 does not fit in a byte. As a result
get_byte_map() had to consult byte_mask[] to decide whether to
report the stored byte or 256, and put_byte_map() had to keep the
two arrays in sync on every write.
Store each slot as a u16 holding the control value directly
(0..255 enabled, 256 disabled). This is the native representation
for what userspace already sees, so get_byte_map() becomes a direct
return and put_byte_map() becomes a compare-and-store. The
hardware-facing packed RAM word and the OUT_BYTE_EN mask are now
derived on the fly inside tegra210_amx_write_map_ram() from the
slot array, which is the only place that needs to know about the
hardware layout.
The byte_mask buffer is allocated in probe() using devm_kcalloc()
with soc_data->byte_mask_size, so it scales to any SoC variant
without depending on chip-specific constants. It is zeroed and
recomputed each time write_map_ram() is called.
A new TEGRA_AMX_SLOTS_PER_WORD constant replaces the literal '4'
used for byte slots per RAM word, and BITS_PER_BYTE /
BITS_PER_TYPE() from <linux/bits.h> replace the literal '8' and
'32' shifts.
Slots are initialised to 256 in probe() so the default reported
value stays "disabled", matching previous behaviour. Values written
from userspace that fall outside [0, 255] are clamped to 256
("disabled") exactly as before -- no userspace-visible change.
As a side effect this also fixes a latent bug in the previous
put_byte_map(): because it compared the enable mask rather than the
stored byte, changing a slot from one enabled value to another
enabled value (e.g. 42 -> 99) would early-return without persisting
the new value, and the next CFG_RAM flush would still program the
old byte. The new implementation compares the stored value itself,
so this case is now handled correctly.
Addresses TODO left in tegra210_amx_get_byte_map().
The byte-map controls ("Byte Map N") already expose a value range of
[0, 256] to userspace via SOC_SINGLE_EXT(), where 256 is the
"disabled" sentinel. The driver stored this state as a byte-packed
u32 map[] array plus a separate byte_mask[] bitmap tracking which
slots were enabled, because 256 does not fit in a byte. As a result
get_byte_map() had to consult byte_mask[] to decide whether to
report the stored byte or 256, and put_byte_map() had to keep the
two arrays in sync on every write.
Store each slot as a u16 holding the control value directly
(0..255 enabled, 256 disabled). This is the native representation
for what userspace already sees, so get_byte_map() becomes a direct
return and put_byte_map() becomes a compare-and-store. The
hardware-facing packed RAM word and the IN_BYTE_EN mask are now
derived on the fly inside tegra210_adx_write_map_ram() from the
slot array, which is the only place that needs to know about the
hardware layout.
The byte_mask buffer is allocated in probe() using devm_kcalloc()
with soc_data->byte_mask_size, so it scales to any SoC variant
without depending on chip-specific constants. It is zeroed and
recomputed each time write_map_ram() is called.
A new TEGRA_ADX_SLOTS_PER_WORD constant replaces the literal '4'
used for byte slots per RAM word, and BITS_PER_BYTE /
BITS_PER_TYPE() from <linux/bits.h> replace the literal '8' and
'32' shifts.
Slots are initialised to 256 in probe() so the default reported
value stays "disabled", matching previous behaviour. Values written
from userspace that fall outside [0, 255] are clamped to 256
("disabled") exactly as before -- no userspace-visible change.
As a side effect this also fixes a latent bug in the previous
put_byte_map(): because it compared the enable mask rather than the
stored byte, changing a slot from one enabled value to another
enabled value (e.g. 42 -> 99) would early-return without persisting
the new value, and the next CFG_RAM flush would still program the
old byte. The new implementation compares the stored value itself,
so this case is now handled correctly.
Addresses TODO left in tegra210_adx_get_byte_map().
Felix Gu [Thu, 16 Apr 2026 16:27:54 +0000 (00:27 +0800)]
spi: atcspi200: fix use-after-free when driver unbind
DMA resource is initialized after SPI controller registration. So
when driver unbind, this can trigger a use-after-free when DMA is
torn down while the controller is still alive and triggers DMA transfers.
projects / thirdparty / linux.git / log
