]> git.ipfire.org Git - thirdparty/kernel/linux.git/log
thirdparty/kernel/linux.git
4 weeks agomedia: rockchip: rga: change offset to dma_addresses
Sven Püschel [Wed, 20 May 2026 22:44:24 +0000 (00:44 +0200)] 
media: rockchip: rga: change offset to dma_addresses

Change the offset to dma_addresses, as the current naming is misleading.
The offset naming comes from the fact that it references the offset in
the mapped iommu address space. But from the hardware point of view this
is an address, as also pointed out by the register naming
(e.g. RGA_DST_Y_RGB_BASE_ADDR). Therefore also change the type to
dma_addr_t, as with an external iommu driver this would also be the
correct type.

This change is a preparation for the RGA3 support, which uses an external
iommu and therefore just gets an dma_addr_t for each buffer. The field
renaming allows to reuse the existing fields of rga_vb_buffer to store
these values.

Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
4 weeks agomedia: rockchip: rga: use card type to specify rga type
Sven Püschel [Wed, 20 May 2026 22:44:23 +0000 (00:44 +0200)] 
media: rockchip: rga: use card type to specify rga type

In preparation of the RGA3 support add a filed to the rga_hw struct
to specify the desired card type value. This allows the user to
differentiate the RGA2 and RGA3 video device nodes.

Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
4 weeks agomedia: rockchip: rga: check scaling factor
Sven Püschel [Wed, 20 May 2026 22:44:22 +0000 (00:44 +0200)] 
media: rockchip: rga: check scaling factor

Check the scaling factor to avoid potential problems. This is relevant
for the upcoming RGA3 support, as it can hang when the scaling factor
is exceeded.

The check is done at streamon when the other side is already streaming
to avoid incorrectly failing if the application configures the other
side after calling streamon. As try_fmt shouldn't be state aware,
it cannot be used to limit the format based on the scaling factor.
Therefore the check is done just before the actual streaming would be
started.

As the driver allows changing the rotation and selection while
streaming, add additional checks to ensure these changes
don't exceed the scaling factor.

Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
4 weeks agomedia: rockchip: rga: reuse cmdbuf contents
Sven Püschel [Wed, 20 May 2026 22:44:21 +0000 (00:44 +0200)] 
media: rockchip: rga: reuse cmdbuf contents

Reuse the command buffer contents instead of completely writing it
for every frame. Therefore we only need to replace the source and
destination addresses for each frame. This reduces the amount of CPU
and memory operations done in each frame. A new cmdbuf_dirty flag notes
if the cmdbuf has to be rewritten on the next frame.

The initial idea of initializing the cmdbuf on streamon broke the
ability to update controls while streaming (e.g. mirroring).

Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
4 weeks agomedia: rockchip: rga: align stride to 4 bytes
Sven Püschel [Wed, 20 May 2026 22:44:20 +0000 (00:44 +0200)] 
media: rockchip: rga: align stride to 4 bytes

Add an alignment setting to rga_hw to set the desired stride alignment.
As the RGA2 register for the stride counts in word units, the code
already divides the bytesperline value by 4 when writing it into the
register. Therefore fix the alignment to a multiple of 4 to avoid
potential off by one errors due from the division.

Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
4 weeks agomedia: rockchip: rga: move cmdbuf to rga_ctx
Sven Püschel [Wed, 20 May 2026 22:44:19 +0000 (00:44 +0200)] 
media: rockchip: rga: move cmdbuf to rga_ctx

Move the command buffer to the rga_ctx struct in preparation to reuse
an already prepared command buffer. This allows to split the command
buffer setup in a further commit to setup a template for the command
buffer at streamon and only update the buffer addresses in device_run
and trigger the command stream. No sync point is added, as one command
buffer should only be used for one conversion at a time.

Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
4 weeks agomedia: rockchip: rga: calculate x_div/y_div using v4l2_format_info
Sven Püschel [Wed, 20 May 2026 22:44:18 +0000 (00:44 +0200)] 
media: rockchip: rga: calculate x_div/y_div using v4l2_format_info

Calculate the x_div and y_div variables with the information from
v4l2_format_info instead of storing these in the rga_fmt struct.

Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
4 weeks agomedia: rockchip: rga: avoid odd frame sizes for YUV formats
Sven Püschel [Wed, 20 May 2026 22:44:17 +0000 (00:44 +0200)] 
media: rockchip: rga: avoid odd frame sizes for YUV formats

Avoid odd frame sizes for YUV formats, as they may cause undefined
behavior. This is done in preparation for the RGA3, which hangs when the
output format is set to 129x129 pixel YUV420 SP (NV12).

This requirement is documented explicitly for the RGA3 in  section 5.6.3
of the RK3588 TRM Part 2. For the RGA2 the RK3588 TRM Part 2
(section 6.1.2) and RK3568 TRM Part 2 (section 14.2) only mentions the
x/y offsets and stride aligning requirements. But the vendor driver for
the RGA2 also contains checks for the width and height to be aligned to
2 bytes.

Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
4 weeks agomedia: rockchip: rga: move hw specific parts to a dedicated struct
Sven Püschel [Wed, 20 May 2026 22:44:16 +0000 (00:44 +0200)] 
media: rockchip: rga: move hw specific parts to a dedicated struct

In preparation for the RGA3 unit, move RGA2 specific parts from rga.c
to rga-hw.c and create a struct to reference the RGA2 specific functions
and formats. This also allows to remove the rga-hw.h reference from the
include list of the rga driver.

Also document the command finish interrupt with a dedicated define.

Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
4 weeks agomedia: rockchip: rga: announce and sync colorimetry
Sven Püschel [Wed, 20 May 2026 22:44:15 +0000 (00:44 +0200)] 
media: rockchip: rga: announce and sync colorimetry

Announce the capability to adjust the quantization and ycbcr_enc on the
capture side and check if the SET_CSC flag is set when the colorimetry
is changed. Furthermore copy the colorimetry from the output to the
capture side to fix the currently failing v4l2-compliance tests, which
expect exactly this behavior.

Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
4 weeks agomedia: rockchip: rga: remove redundant rga_frame variables
Sven Püschel [Wed, 20 May 2026 22:44:14 +0000 (00:44 +0200)] 
media: rockchip: rga: remove redundant rga_frame variables

Remove the redundant rga_frame variables width, height and color space.
The value of these variables is already contained in the pix member
of rga_frame. The code also keeps these values in sync. Therefore drop
them in favor of the existing pix member.

Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
4 weeks agomedia: rockchip: rga: use stride for offset calculation
Sven Püschel [Wed, 20 May 2026 22:44:13 +0000 (00:44 +0200)] 
media: rockchip: rga: use stride for offset calculation

Use the stride instead of the width for the offset calculation. This
ensures that the bytesperline value doesn't need to match the width
value of the image.

Furthermore this patch removes the dependency on the uv_factor property
and instead reuses the v4l2_format_info to determine the correct
division factor.

Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
4 weeks agomedia: rockchip: rga: use clk_bulk api
Sven Püschel [Wed, 20 May 2026 22:44:12 +0000 (00:44 +0200)] 
media: rockchip: rga: use clk_bulk api

Use the clk_bulk API to avoid code duplication for each of the three
clocks.

Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
4 weeks agomedia: rockchip: rga: fix too small buffer size
Sven Püschel [Wed, 20 May 2026 22:44:11 +0000 (00:44 +0200)] 
media: rockchip: rga: fix too small buffer size

Fix the command buffer size being only a quarter of the actual size.
The RGA_CMDBUF_SIZE macro was potentially intended to specify the length
of the cmdbuf u32 array pointer. But as it's used to specify the size of
the allocation, which is counted in bytes. Therefore adjust the macro
size to bytes as it better matches the variable name and adjust it's
users accordingly.

As the command buffer is relatively small, it probably didn't caused
an issue due to being smaller than a single page.

Fixes: f7e7b48e6d79 ("[media] rockchip/rga: v4l2 m2m support")
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
4 weeks agomedia: v4l2-common: add v4l2_fill_pixfmt_mp_aligned helper
Sven Püschel [Wed, 20 May 2026 22:44:10 +0000 (00:44 +0200)] 
media: v4l2-common: add v4l2_fill_pixfmt_mp_aligned helper

Add a v4l2_fill_pixfmt_mp_aligned helper which allows the user to
specify a custom stride alignment in bytes. This is necessary for
hardware like the Rockchip RGA3, which requires the stride value to be
aligned to a 16 bytes boundary.

The code makes some assumptions about the v4l2 format to simplify the
calculation. They currently hold for all known v4l2 formats.

v4l2_format_plane_stride uses an unsigned int as argument type to avoid
the later multiplication from overflowing the u8 value. All other places
use u8, as no practical use cases for a larger alignment are known at
the moment.

Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
4 weeks agomedia: v4l2-common: add has_alpha to v4l2_format_info
Sven Püschel [Wed, 20 May 2026 22:44:09 +0000 (00:44 +0200)] 
media: v4l2-common: add has_alpha to v4l2_format_info

Add a has_alpha value to the v4l2_format_info struct to indicate if the
format contains an alpha component. This information can currently not
be queried in a generic way, but might be useful for potential drivers
to properly setup alpha blending to copy or set the alpha value.
The implementation is based on the drm_format_info implementation.

Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
4 weeks agomedia: v4l2-common: add missing 1 and 2 byte RGB formats to v4l2_format_info
Sven Püschel [Wed, 20 May 2026 22:44:08 +0000 (00:44 +0200)] 
media: v4l2-common: add missing 1 and 2 byte RGB formats to v4l2_format_info

Add all missing one and two byte RGB formats to v4l2_format_info. This
allows drivers to more consistently use v4l2_format_info, as it now
covers all currently defined RGB formats.

Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
4 weeks agomedia: v4l2-common: sort RGB formats in v4l2_format_info
Sven Püschel [Wed, 20 May 2026 22:44:07 +0000 (00:44 +0200)] 
media: v4l2-common: sort RGB formats in v4l2_format_info

Sort the RGB formats in v4l2_format_info to match the format definitions
in include/uapi/linux/videodev2.h . Also introduce the same sections to
partition the list of formats and align the format info in each section.

The alignment of the 1 or 2 bytes RGB formats contains an additional
space in preparation of adding the missing formats to the list, as for
V4L2_PIX_FMT_ARGB555X an additional space is necessary.

Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
4 weeks agomedia: dt-bindings: media: rockchip-rga: add rockchip,rk3588-rga3
Sven Püschel [Wed, 20 May 2026 22:44:06 +0000 (00:44 +0200)] 
media: dt-bindings: media: rockchip-rga: add rockchip,rk3588-rga3

Add a new compatible for the RGA3 (Raster Graphic Acceleration 3)
peripheral found on the RK3588 SoC. Also specify an iommu property,
as the RGA3 contains the generic rockchip iommu. While other versions
also have an iommu, it's usually specific to them.

The RK3588 contains one RGA2-Enhance core (also contained on the RK3399)
and two RGA3 cores. Both feature a similar functionality of scaling,
cropping and rotating of up to two input images into one output image.
Key differences of the RGA3 are:

- supports 10bit YUV output formats
- supports 8x8 tiles and FBCD as inputs and outputs
- supports BT2020 color space conversion
- max output resolution of (8192-64)x(8192-64)
- MMU can map up to 32G DDR RAM
- fully planar formats (3 planes) are not supported
- max scale up/down factor of 8 (RGA2 allows up to 16)

Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
4 weeks agoASoC: SOF: DSP core count handling updates
Mark Brown [Thu, 21 May 2026 10:25:24 +0000 (11:25 +0100)] 
ASoC: SOF: DSP core count handling updates

Peter Ujfalusi <peter.ujfalusi@linux.intel.com> says:

The series address developer facing issues regarding to how the DSP core
count is handled:
IPC4 code ignored the DISABLE_MULTICORE flag, fixed by the first patch.
The second patch does a validation of the core index from topology
against the number of DSP cores available on the booted device, which makes
generic development topologies usable among different DSP variants without
failure.

Link: https://patch.msgid.link/20260520135514.32720-1-peter.ujfalusi@linux.intel.com
4 weeks agoASoC: SOF: Validate and correct the core id against the number of cores of the DSP
Peter Ujfalusi [Wed, 20 May 2026 13:55:14 +0000 (16:55 +0300)] 
ASoC: SOF: Validate and correct the core id against the number of cores of the DSP

Generic development topologies can reference core id outside of the range
of the number of DSP cores the device might have.
Product families have different number of cores, for example:
Intel TGL has 4, TGL-H has 2, ADL has 4, ADL-S has 2, etc
The development topologies are tuned for the higher end devices and in this
case they will fail on DSP with less number of cores.

Override the out of range core id from topology to primary core and inform
the user about it.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://patch.msgid.link/20260520135514.32720-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 weeks agoASoC: SOF: ipc4-topology: Handle SOF_DBG_DISABLE_MULTICORE flag for pipelines
Peter Ujfalusi [Wed, 20 May 2026 13:55:13 +0000 (16:55 +0300)] 
ASoC: SOF: ipc4-topology: Handle SOF_DBG_DISABLE_MULTICORE flag for pipelines

SOF_DBG_DISABLE_MULTICORE is handled for swidgets in topology.c but the
pipeline's core is not changed to primary core if the flag is set.

Check the flag and if it is set, force the pipeline core to primary core.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://patch.msgid.link/20260520135514.32720-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 weeks agolkdtm/powerpc: add PPC_RADIX_TLBIEL test for radix MCE validation
Sayali Patil [Mon, 18 May 2026 06:56:05 +0000 (12:26 +0530)] 
lkdtm/powerpc: add PPC_RADIX_TLBIEL test for radix MCE validation

Add a new LKDTM trigger (PPC_RADIX_TLBIEL) that executes a process-scoped
radix TLBIEL instruction to exercise the radix MMU behaviour and
associated machine check exception (MCE) handling paths.

This provides a way to validate MCE handling in radix mode. Currently,
there is no dedicated LKDTM test that exercises this path or allows
triggering radix-specific machine check behaviour for validation.

The test is only enabled on ppc64 systems with radix MMU
support and If radix is not active, the trigger is skipped and reported as
XFAIL.

Co-developed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Sayali Patil <sayalip@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Michael Ellerman <mpe@kernel.org>
Link: https://patch.msgid.link/85c9b59217bcecb3c7af52e9d5b175266771d7de.1778975974.git.sayalip@linux.ibm.com
Signed-off-by: Kees Cook <kees@kernel.org>
4 weeks agolkdtm/powerpc: add isync after slbmte to enforce SLB update ordering
Sayali Patil [Mon, 18 May 2026 06:56:04 +0000 (12:26 +0530)] 
lkdtm/powerpc: add isync after slbmte to enforce SLB update ordering

The slbmte instruction modifies the Segment Lookaside Buffer, but without
a context synchronizing operation the CPU is not guaranteed to observe
the updated SLB state for subsequent instructions. This can result in
use of stale translation state when memory is accessed immediately after
SLB modifications.

Add isync after each slbmte in the PPC_SLB_MULTIHIT test to ensure proper
ordering of SLB updates before subsequent memory accesses.

This aligns with Power ISA context synchronization requirements for changes
in address translation state and improves the reliability of SLB multihit
injection tests in hash MMU mode.

Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Sayali Patil <sayalip@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Michael Ellerman <mpe@kernel.org>
Link: https://patch.msgid.link/2f8d430962a96a7498903b994f081deee4a4d97a.1778975974.git.sayalip@linux.ibm.com
Signed-off-by: Kees Cook <kees@kernel.org>
4 weeks agolkdtm: Add case to provoke a crash in EFI runtime services
Ard Biesheuvel [Fri, 1 May 2026 17:01:56 +0000 (19:01 +0200)] 
lkdtm: Add case to provoke a crash in EFI runtime services

Add a lkdtm test case that triggers a fault during the execution of a
EFI runtime service by passing a read-only variable as a by-ref argument
that the firmware is supposed to update.

This is useful for testing the graceful handling of faults/exception in
EFI platform firmware, which is implemented on x86 and arm64.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260501170156.2833364-2-ardb+git@google.com
Signed-off-by: Kees Cook <kees@kernel.org>
4 weeks agoMerge branch 'net-mlx5-prepare-eswitch-infrastructure-for-satellite-pf-support'
Paolo Abeni [Thu, 21 May 2026 10:12:04 +0000 (12:12 +0200)] 
Merge branch 'net-mlx5-prepare-eswitch-infrastructure-for-satellite-pf-support'

Tariq Toukan says:

====================
net/mlx5: Prepare eswitch infrastructure for satellite PF support

A satellite PF is a new SmartNIC configuration that adds another
physical function on the DPU that is not an eswitch manager and not a
page manager. The satellite PF can have its own SFs and can be passed
through to a VM on the DPU, providing an isolated function for users who
should not have access to the privileged ECPF. The ECPF handles the
satellite PF and the host PF in a similar way, using the same management
framework.

This series prepares the mlx5 eswitch command interface and vport
infrastructure for satellite PF support.

The first two patches abstract host PF data parsing behind a helper and
switch to the v1 response layout for query_esw_functions when supported,
so callers are insulated from layout differences.

The IPsec VF checks are tightened to use mlx5_eswitch_is_vf_vport()
instead of comparing against a specific vport number.

The remaining patches refactor SET_HCA_CAP and enable/disable_hca
command helpers to support vhca_id-based addressing, which is required
for managing functions that are not directly addressable by function_id.

A follow-up series will introduce satellite PF discovery and management
using this infrastructure.

V1:
https://lore.kernel.org/all/20260510053448.326823-1-tariqt@nvidia.com/
====================

Link: https://patch.msgid.link/20260518071356.345723-1-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
4 weeks agocache: sifive_ccache: Add StarFive JH7110 SoC support
Dominique Belhachemi [Thu, 30 Apr 2026 03:52:59 +0000 (03:52 +0000)] 
cache: sifive_ccache: Add StarFive JH7110 SoC support

This cache controller is also used on the StarFive JH7110 SoC. It does
not have the data-uncorrectable ECC quirk that JH7100 has, so only
QUIRK_NONSTANDARD_CACHE_OPS is set.

Signed-off-by: Dominique Belhachemi <domibel@debian.org>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
4 weeks agonet/mlx5: Generalize enable/disable HCA for any PF vport
Moshe Shemesh [Mon, 18 May 2026 07:13:56 +0000 (10:13 +0300)] 
net/mlx5: Generalize enable/disable HCA for any PF vport

Refactor the host-PF-specific mlx5_cmd_host_pf_enable/disable_hca()
into generic mlx5_cmd_pf_enable/disable_hca() that accept a vport
number. The new functions use vhca_id as function_id when supported.

Similarly, refactor the eswitch layer into generic static helpers
mlx5_esw_pf_enable/disable_hca() with thin wrappers for the host PF
case, in preparation for enable_hca on satellite PF vports.

Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260518071356.345723-9-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
4 weeks agonet/mlx5: Use vport helper for IPsec eswitch set caps
Moshe Shemesh [Mon, 18 May 2026 07:13:55 +0000 (10:13 +0300)] 
net/mlx5: Use vport helper for IPsec eswitch set caps

Use mlx5_vport_set_other_func_cap() and
mlx5_vport_set_other_func_general_cap() in the IPsec eswitch functions
instead of open-coding the SET_HCA_CAP command. This removes redundant
buffer allocation and boilerplate, and also enables vhca_id based
addressing when supported.

Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260518071356.345723-8-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
4 weeks agonet/mlx5: Refactor mlx5_set_msix_vec_count() SET_HCA_CAP
Moshe Shemesh [Mon, 18 May 2026 07:13:54 +0000 (10:13 +0300)] 
net/mlx5: Refactor mlx5_set_msix_vec_count() SET_HCA_CAP

Use mlx5_vport_set_other_func_general_cap() instead of open-coding the
SET_HCA_CAP command. This removes redundant buffer allocation and
ensures consistent use of vport-based function addressing.

mlx5_vport_set_other_func_general_cap() supports both function_id and
vhca_id based addressing, so this also enables SET_HCA_CAP for vhca_id
indexed functions which was not supported before.

Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260518071356.345723-7-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
4 weeks agonet/mlx5: Add mlx5_vport_set_other_func_general_cap macro
Moshe Shemesh [Mon, 18 May 2026 07:13:53 +0000 (10:13 +0300)] 
net/mlx5: Add mlx5_vport_set_other_func_general_cap macro

Add mlx5_vport_set_other_func_general_cap() convenience macro, symmetric
to the existing mlx5_vport_get_other_func_general_cap(), and use it in
mlx5_devlink_port_fn_roce_set().

No functional change in this patch.

Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260518071356.345723-6-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
4 weeks agonet/mlx5: Switch vport HCA cap helpers to kvzalloc
Moshe Shemesh [Mon, 18 May 2026 07:13:52 +0000 (10:13 +0300)] 
net/mlx5: Switch vport HCA cap helpers to kvzalloc

mlx5_vport_set_other_func_cap() and mlx5_vport_get_vhca_id() allocate
command buffers that embed the HCA capability union, exceeding 4KiB.
Use kvzalloc/kvfree so the allocation can fall back to vmalloc when
contiguous memory is scarce.

Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260518071356.345723-5-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
4 weeks agonet/mlx5: Use mlx5_eswitch_is_vf_vport() for IPsec VF checks
Moshe Shemesh [Mon, 18 May 2026 07:13:51 +0000 (10:13 +0300)] 
net/mlx5: Use mlx5_eswitch_is_vf_vport() for IPsec VF checks

IPsec eswitch offload operations and the enabled_ipsec_vf_count counter
are intended for VF vports only. Replace the MLX5_VPORT_HOST_PF checks
with mlx5_eswitch_is_vf_vport() to properly identify VF vports, as
preparation for adding another type of PF vports.

Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260518071356.345723-4-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
4 weeks agonet/mlx5: Use v1 response layout for query_esw_functions
Moshe Shemesh [Mon, 18 May 2026 07:13:50 +0000 (10:13 +0300)] 
net/mlx5: Use v1 response layout for query_esw_functions

Use the v1 response layout for the query_esw_functions command when
supported by the device. When query_host_net_function_v1 capability is
set, use MLX5_QUERY_ESW_FUNC_OP_MOD_LAYOUT_V1 to retrieve parameters
for multiple network functions, allocating the output buffer according
to query_host_net_function_num_max. Validate that firmware does not
return more entries than the allocated buffer.

The v1 layout reports vhca_state instead of the legacy host_pf_disabled
bit. PFs transition through ALLOCATED, ACTIVE, and IN_USE states (they
do not use TEARDOWN_REQUEST as SFs do). When the ECPF calls disable_hca,
firmware resets the PF and moves it to ALLOCATED. When the ECPF calls
enable_hca, the PF moves to ACTIVE, and once the PF driver enables it,
it reaches IN_USE. The PF is only fully operational in IN_USE, so
pf_disabled is derived as vhca_state != IN_USE, equivalent to the legacy
host_pf_disabled bit.

The mlx5_esw_get_host_pf_info() helper abstracts parsing the command
output in both legacy and new formats, so callers do not need to handle
the different layouts.

Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260518071356.345723-3-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
4 weeks agonet/mlx5: Use helper to parse host PF info
Moshe Shemesh [Mon, 18 May 2026 07:13:49 +0000 (10:13 +0300)] 
net/mlx5: Use helper to parse host PF info

Add a helper mlx5_esw_get_host_pf_info() to retrieve host PF data from
the query_esw_functions command output, so callers no longer need to
parse the layout to obtain the required information.

Convert all callers of mlx5_esw_query_functions() to use the new helper,
preparing for upcoming support of the new op_mod that returns data in
the network_function_params layout.

Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260518071356.345723-2-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
4 weeks agoMAINTAINERS: ASoC: Intel/SOF: Remove Ranjani Sridharan as maintainer
Peter Ujfalusi [Wed, 20 May 2026 14:00:01 +0000 (17:00 +0300)] 
MAINTAINERS: ASoC: Intel/SOF: Remove Ranjani Sridharan as maintainer

Ranjani no longer works on Intel/SOF audio drivers and her email address
now bounce due to her departure from Intel.

Unfortunately, she was not able to send the removal mail by herself.

Thanks for the years of work and dedication, Ranjani!

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Jyri Sarha <jyri.sarha@linux.intel.com>
Link: https://patch.msgid.link/20260520140001.1375-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 weeks agospi: dw-mmio: Add ACPI ID LECA0002 for LECARC SoCs
Thomas Lin [Thu, 21 May 2026 02:34:50 +0000 (10:34 +0800)] 
spi: dw-mmio: Add ACPI ID LECA0002 for LECARC SoCs

This ID requires a custom initialization function
dw_spi_hssi_no_dma_init() that sets dws->dws.ip to DW_HSSI_ID.

Signed-off-by: Thomas Lin <thomas_lin@lecomputing.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260521-lecarc-acpi-ids-v1-2-ae0ae90b2817@lecomputing.com
Signed-off-by: Mark Brown <broonie@kernel.org>
4 weeks agodrm/bridge: ite-it66121: Convert to DRM HDMI Audio Helper
Sen Wang [Wed, 18 Mar 2026 15:46:36 +0000 (10:46 -0500)] 
drm/bridge: ite-it66121: Convert to DRM HDMI Audio Helper

Convert the IT66121 HDMI bridge driver from manually registering an
hdmi-codec platform device to using the DRM HDMI Audio Helper framework
via DRM_BRIDGE_OP_HDMI_AUDIO instead.

The previous implementation manually allocated hdmi_codec_pdata,
registered the platform device, and implemented hdmi_codec_ops callbacks
including get_eld. The new approach sets DRM_BRIDGE_OP_HDMI_AUDIO on the
bridge, letting the framework handle the codec registration. This also
resolves some non-compliance issues with the current audio implementation,
such as HDMI audio advertising a non-functional capture stream to userspace.

The audio callbacks are converted from hdmi_codec_ops signatures to
drm_bridge_funcs hdmi_audio callbacks:
  - it66121_audio_hw_params   -> it66121_hdmi_audio_prepare
  - it66121_audio_startup     -> it66121_hdmi_audio_startup
  - it66121_audio_shutdown    -> it66121_hdmi_audio_shutdown
  - it66121_audio_mute        -> it66121_hdmi_audio_mute_stream

The it66121_audio_get_eld, it66121_audio_codec_ops, and
it66121_audio_codec_init functions are removed as the framework handles
these responsibilities.

Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Sen Wang <sen@ti.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://patch.msgid.link/20260318154636.3230454-1-sen@ti.com
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
4 weeks agogpio: aggregator: remove the software node when deactivating the aggregator
Bartosz Golaszewski [Wed, 20 May 2026 12:16:31 +0000 (14:16 +0200)] 
gpio: aggregator: remove the software node when deactivating the aggregator

The dynamic software node we create for the aggregator platform device
when using configfs is leaked when the device is deactivated. Destroy it
as the last step in the tear-down path.

Fixes: 86f162e73d2d ("gpio: aggregator: introduce basic configfs interface")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Closes: https://lore.kernel.org/all/CAMuHMdVZ=XUvJTGdDAjnkxgtw7Uvnn61iOy3XN_5XNZM2anctw@mail.gmail.com/
Link: https://patch.msgid.link/20260520121631.33976-1-bartosz.golaszewski@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
4 weeks agogpio: aggregator: fix a potential use-after-free
Bartosz Golaszewski [Wed, 20 May 2026 08:49:11 +0000 (10:49 +0200)] 
gpio: aggregator: fix a potential use-after-free

On error we free aggr->lookups->dev_id before removing the entry from
the lookup table. If a concurrent thread calls gpiod_find() before we
remove the entry, it could iterate over the list and call
gpiod_match_lookup_table() which unconditionally dereferences dev_id
when calling strcmp(). Reverse the order of cleanup.

Fixes: 86f162e73d2d ("gpio: aggregator: introduce basic configfs interface")
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260520084911.27938-1-bartosz.golaszewski@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
4 weeks agodt-bindings: soc: microchip: document irqmux on pic64gx
Conor Dooley [Tue, 7 Apr 2026 15:29:31 +0000 (16:29 +0100)] 
dt-bindings: soc: microchip: document irqmux on pic64gx

Being practically identical to PolarFire SoC, pic64gx has a irqmux
that's entirely compatible with that on mpfs.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
4 weeks agogpio: cdev: check if uAPI v2 config attributes are correctly zeroed
Bartosz Golaszewski [Thu, 21 May 2026 08:42:16 +0000 (10:42 +0200)] 
gpio: cdev: check if uAPI v2 config attributes are correctly zeroed

We check the padding of other uAPI v2 structures but not that of line
config attributes. For used attributes: check if their padding is
zeroed, for unused: check if the entire structure is zeroed.

Fixes: 3c0d9c635ae2 ("gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL")
Reviewed-by: Kent Gibson <warthog618@gmail.com>
Link: https://patch.msgid.link/20260521-gpio-cdev-attr-padding-check-v3-1-ec3bcbe2e358@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
4 weeks agoMerge branch 'net-stmmac-eic7700-fix-delay-calculation-and-initialization-ordering'
Paolo Abeni [Thu, 21 May 2026 09:58:18 +0000 (11:58 +0200)] 
Merge branch 'net-stmmac-eic7700-fix-delay-calculation-and-initialization-ordering'

Zhi Li says:

====================
net: stmmac: eic7700: fix delay calculation and initialization ordering

From: Zhi Li <lizhi2@eswincomputing.com>
====================

Link: https://patch.msgid.link/20260518021919.404-1-lizhi2@eswincomputing.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
4 weeks agonet: stmmac: eswin: validate RGMII delay values
Zhi Li [Mon, 18 May 2026 02:22:13 +0000 (10:22 +0800)] 
net: stmmac: eswin: validate RGMII delay values

Validate rx-internal-delay-ps and tx-internal-delay-ps against the
hardware capabilities of the EIC7700 MAC.

The programmable RGMII delay supports 20 ps steps and a maximum value of
2540 ps. The driver previously accepted arbitrary values and silently
truncated unsupported settings when converting them to hardware units.

As a result, invalid device tree values could lead to unexpected delay
programming and incorrect RGMII timing.

Reject delay values that are not multiples of 20 ps or exceed the
supported hardware range.

Fixes: ea77dbbdbc4e ("net: stmmac: add Eswin EIC7700 glue driver")
Signed-off-by: Zhi Li <lizhi2@eswincomputing.com>
Link: https://patch.msgid.link/20260518022214.507-1-lizhi2@eswincomputing.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
4 weeks agonet: stmmac: eswin: correct RGMII delay granularity to 20 ps
Zhi Li [Mon, 18 May 2026 02:21:52 +0000 (10:21 +0800)] 
net: stmmac: eswin: correct RGMII delay granularity to 20 ps

The EIC7700 MAC implements programmable RGMII delay adjustment with a
granularity of 20 ps per hardware step.

The driver previously converted rx-internal-delay-ps and
tx-internal-delay-ps values using a 100 ps step size, resulting in
incorrect delay programming.

Update the conversion to use the correct 20 ps granularity so the
programmed delay matches the values described in the device tree.

Fixes: ea77dbbdbc4e ("net: stmmac: add Eswin EIC7700 glue driver")
Signed-off-by: Zhi Li <lizhi2@eswincomputing.com>
Link: https://patch.msgid.link/20260518022156.484-1-lizhi2@eswincomputing.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
4 weeks agonet: stmmac: eswin: clear TXD and RXD delay registers during initialization
Zhi Li [Mon, 18 May 2026 02:21:37 +0000 (10:21 +0800)] 
net: stmmac: eswin: clear TXD and RXD delay registers during initialization

Clear the TXD and RXD delay control registers during EIC7700 DWMAC
initialization.

These registers may retain values programmed by the bootloader. If left
unchanged, residual delays can alter the effective RGMII timing seen by
the MAC and override the configuration described by the device tree.

This may violate the expected RGMII timing model and can cause link
instability or prevent the Ethernet controller from operating correctly.

Explicitly clearing these registers ensures that the MAC delay settings
are determined solely by the kernel configuration.

The corresponding register offsets are optional, and the registers are
only cleared when the offsets are provided in the device tree.

Fixes: ea77dbbdbc4e ("net: stmmac: add Eswin EIC7700 glue driver")
Signed-off-by: Zhi Li <lizhi2@eswincomputing.com>
Link: https://patch.msgid.link/20260518022137.464-1-lizhi2@eswincomputing.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
4 weeks agonet: stmmac: eswin: fix HSP CSR init ordering after clock enable
Zhi Li [Mon, 18 May 2026 02:20:55 +0000 (10:20 +0800)] 
net: stmmac: eswin: fix HSP CSR init ordering after clock enable

Fix the initialization ordering of the HSP CSR configuration in the
EIC7700 DWMAC glue driver.

The HSP CSR registers control MAC-side RGMII delay behavior and must
only be accessed after the corresponding clocks are enabled. The
previous implementation could trigger register access before clock
enablement, leading to undefined behavior depending on boot state.

Move the HSP CSR configuration into the post-clock-enable initialization
path to ensure all register accesses occur under valid clock domains.

This change ensures deterministic initialization and prevents
clock-dependent register access failures during probe or resume.

Fixes: ea77dbbdbc4e ("net: stmmac: add Eswin EIC7700 glue driver")
Signed-off-by: Zhi Li <lizhi2@eswincomputing.com>
Link: https://patch.msgid.link/20260518022055.444-1-lizhi2@eswincomputing.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
4 weeks agodt-bindings: ethernet: eswin: add optional TXD and RXD delay register offsets
Zhi Li [Mon, 18 May 2026 02:20:23 +0000 (10:20 +0800)] 
dt-bindings: ethernet: eswin: add optional TXD and RXD delay register offsets

Document two optional cells in eswin,hsp-sp-csr for the TXD and RXD
delay control register offsets.

These registers are used by the driver to clear any residual delay
configuration left by the bootloader, ensuring that MAC-side RGMII delay
settings are applied solely according to the kernel configuration.

Add a reference to the EIC7700X SoC Technical Reference Manual for
background information about the HSP CSR block.

Fixes: 888bd0eca93c ("dt-bindings: ethernet: eswin: Document for EIC7700 SoC")
Signed-off-by: Zhi Li <lizhi2@eswincomputing.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260518022023.427-1-lizhi2@eswincomputing.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
4 weeks agoirqchip/exynos-combiner: Switch to raw_spinlock
Marek Szyprowski [Wed, 20 May 2026 22:04:22 +0000 (00:04 +0200)] 
irqchip/exynos-combiner: Switch to raw_spinlock

The exynos-combiner driver uses a regular spinlock to protect access to
the combiner interrupt status register in combiner_handle_cascade_irq(),
which is invoked in hard interrupt context as a chained interrupt handler.

When PREEMPT_RT is enabled on ARM, regular spinlock is converted to a
sleeping lock (mutex-based), which must not be used in atomic context
such as hard interrupt handlers.

Switch the irq_controller_lock to raw_spinlock, which remains a true
non-sleeping spinlock even under PREEMPT_RT.

Fixes: a900e5d99718 ("ARM: exynos: move exynos4210-combiner to drivers/irqchip")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
4 weeks agoMerge branch 'bpf-extend-the-bpf_list-family-of-apis'
Alexei Starovoitov [Thu, 21 May 2026 09:47:46 +0000 (02:47 -0700)] 
Merge branch 'bpf-extend-the-bpf_list-family-of-apis'

Kaitao Cheng says:

====================
bpf: Extend the bpf_list family of APIs

In BPF, a list can only be used to implement a stack structure.
Due to an incomplete API set, only FIFO or LIFO operations are
supported. The patches enhance the BPF list API, making it more
list-like.

Five new kfuncs have been added:
bpf_list_del: remove a node from the list
bpf_list_add_impl: insert a node after a given list node
bpf_list_is_first: check if a node is the first in the list
bpf_list_is_last: check if a node is the last in the list
bpf_list_empty: check if the list is empty

And add test cases for the aforementioned kfuncs.

Changes in v11:
- Move [PATCH v10 7/8] earlier (Eduard Zingerman)
- Fix the synchronization issue in [PATCH v10 2/8] (Eduard Zingerman,
  Alexei Starovoitov)

Changes in v10:
- Remove the table-driven approach (Ihor Solodrai)
- Use the __nonown_allowed suffix for bpf_list_del/front/back
- Add test cases for __nonown_allowed

Changes in v9:
- Expand table-driven approach coverage (Emil Tsalapatis)
- Clear list node owner and unlink before drop (Emil Tsalapatis)
- Remove warnings caused by WARN_ON_ONCE() (Emil Tsalapatis)
- Introduce the __nonown_allowed suffix (Alexei Starovoitov)

Changes in v8:
- Use [patch v7 5/5] as the start of the patch series (Leon Hwang)
- Introduce double pointer prev_ptr in __bpf_list_del
  (Kumar Kartikeya Dwivedi)
- Extract refactored __bpf_list_del/add into separate patches (Leon Hwang)
- Allow bpf_list_front/back result as the prev argument of bpf_list_add
- Split test cases (Leon Hwang)

Changes in v7:
- Replace bpf_list_node_is_edge with bpf_list_is_first/is_last
- Reimplement __bpf_list_del and __bpf_list_add (Kumar Kartikeya Dwivedi)
- Simplify test cases (Mykyta Yatsenko)

Changes in v6:
- Merge [patch v5 (2,4,6)/6] into [patch v6 4/5] (Leon Hwang)
- If list_head was 0-initialized, init it
- refactor kfunc checks to table-driven approach (Leon Hwang)

Changes in v5:
- Fix bpf_obj leak on bpf_list_add_impl error

Changes in v4:
- [patch v3 1/6] Revert to version v1 (Alexei Starovoitov)
- Change the parameters of bpf_list_add_impl to (head, new, prev, ...)

Changes in v3:
- Add a new lock_rec member to struct bpf_reference_state for lock
  holding detection.
- Add test cases to verify that the verifier correctly restricts calls
  to bpf_list_del when the spin_lock is not held.

Changes in v2:
- Remove the head parameter from bpf_list_del (Alexei Starovoitov)
- Add bpf_list_add/is_first/is_last/empty to API and test cases
  (Alexei Starovoitov)

Link to v10:
https://lore.kernel.org/all/20260512055919.95716-1-kaitao.cheng@linux.dev/

Link to v9:
https://lore.kernel.org/all/20260329140506.9595-1-pilgrimtao@gmail.com/

Link to v8:
https://lore.kernel.org/all/20260316112843.78657-1-pilgrimtao@gmail.com/

Link to v7:
https://lore.kernel.org/all/20260308134614.29711-1-pilgrimtao@gmail.com/

Link to v6:
https://lore.kernel.org/all/20260304143459.78059-1-pilgrimtao@gmail.com/

Link to v5:
https://lore.kernel.org/all/20260304031606.43884-1-pilgrimtao@gmail.com/

Link to v4:
https://lore.kernel.org/all/20260303135219.33726-1-pilgrimtao@gmail.com/

Link to v3:
https://lore.kernel.org/all/20260302124028.82420-1-pilgrimtao@gmail.com/

Link to v2:
https://lore.kernel.org/all/20260225092651.94689-1-pilgrimtao@gmail.com/

Link to v1:
https://lore.kernel.org/all/20260209025250.55750-1-pilgrimtao@gmail.com/
====================

Link: https://patch.msgid.link/20260521032306.97118-1-kaitao.cheng@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
4 weeks agoselftests/bpf: Add test cases for bpf_list_del/add/is_first/is_last/empty
Kaitao Cheng [Thu, 21 May 2026 03:23:06 +0000 (11:23 +0800)] 
selftests/bpf: Add test cases for bpf_list_del/add/is_first/is_last/empty

Extend refcounted_kptr with tests for bpf_list_add (including prev from
bpf_list_front and bpf_refcount_acquire), bpf_list_del (including node
from bpf_list_front, bpf_rbtree_remove and bpf_refcount_acquire),
bpf_list_empty, bpf_list_is_first/last, and push_back on uninit head.

To verify the validity of bpf_list_del/add, the test also expects the
verifier to reject calls to bpf_list_del/add made without holding the
spin_lock.

Signed-off-by: Kaitao Cheng <chengkaitao@kylinos.cn>
Link: https://lore.kernel.org/r/20260521032306.97118-9-kaitao.cheng@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
4 weeks agobpf: add bpf_list_is_first/last/empty kfuncs
Kaitao Cheng [Thu, 21 May 2026 03:23:05 +0000 (11:23 +0800)] 
bpf: add bpf_list_is_first/last/empty kfuncs

Add three kfuncs for BPF linked list queries:
- bpf_list_is_first(head, node): true if node is the first in the list.
- bpf_list_is_last(head, node): true if node is the last in the list.
- bpf_list_empty(head): true if the list has no entries.

Currently, without these kfuncs, to implement the above functionality
it is necessary to first call bpf_list_pop_front/back to retrieve the
first or last node before checking whether the passed-in node was the
first or last one. After the check, the node had to be pushed back into
the list using bpf_list_push_front/back, which was very inefficient.

Now, with the bpf_list_is_first/last/empty kfuncs, we can directly
check whether a node is the first, last, or whether the list is empty,
without having to first retrieve the node.

Signed-off-by: Kaitao Cheng <chengkaitao@kylinos.cn>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Link: https://lore.kernel.org/r/20260521032306.97118-8-kaitao.cheng@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
4 weeks agobpf: Add bpf_list_add to insert node after a given list node
Kaitao Cheng [Thu, 21 May 2026 03:23:04 +0000 (11:23 +0800)] 
bpf: Add bpf_list_add to insert node after a given list node

Add a new kfunc bpf_list_add(head, new, prev, meta, off) that
inserts 'new' after 'prev' in the BPF linked list. Both must be in
the same list; 'prev' must already be in the list. The new node must
be an owning reference (e.g. from bpf_obj_new); the kfunc consumes
that reference and the node becomes non-owning once inserted.

We have added an additional parameter bpf_list_head *head to
bpf_list_add, as the verifier requires the head parameter to
check whether the lock is being held.

Returns 0 on success, -EINVAL if 'prev' is not in a list or 'new'
is already in a list (or duplicate insertion). On failure, the
kernel drops the passed-in node.

Signed-off-by: Kaitao Cheng <chengkaitao@kylinos.cn>
Reviewed-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260521032306.97118-7-kaitao.cheng@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
4 weeks agobpf: refactor __bpf_list_add to take insertion point via **prev_ptr
Kaitao Cheng [Thu, 21 May 2026 03:23:03 +0000 (11:23 +0800)] 
bpf: refactor __bpf_list_add to take insertion point via **prev_ptr

Refactor __bpf_list_add to accept (node, head, struct list_head **prev_ptr,
..) instead of (node, head, bool tail, ..). Load prev from *prev_ptr after
INIT_LIST_HEAD(h), so we never dereference an uninitialized h->prev when
head was 0-initialized (e.g. push_back passes &h->prev).

When prev is not the list head, validate that prev is in the list via
its owner.

Prepares for bpf_list_add(head, new, prev, ..) to insert after a given
list node.

Signed-off-by: Kaitao Cheng <chengkaitao@kylinos.cn>
Reviewed-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260521032306.97118-6-kaitao.cheng@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
4 weeks agobpf: Introduce the bpf_list_del kfunc.
Kaitao Cheng [Thu, 21 May 2026 03:23:02 +0000 (11:23 +0800)] 
bpf: Introduce the bpf_list_del kfunc.

Allow users to remove any node from a linked list.

We have added an additional parameter bpf_list_head *head to
bpf_list_del, as the verifier requires the head parameter to
check whether the lock is being held.

Signed-off-by: Kaitao Cheng <chengkaitao@kylinos.cn>
Reviewed-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260521032306.97118-5-kaitao.cheng@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
4 weeks agobpf: allow non-owning list-node args via __nonown_allowed
Kaitao Cheng [Thu, 21 May 2026 03:23:01 +0000 (11:23 +0800)] 
bpf: allow non-owning list-node args via __nonown_allowed

KF_ARG_PTR_TO_LIST_NODE normally requires an owning reference
(PTR_TO_BTF_ID | MEM_ALLOC with ref_obj_id). Introduce  the
__nonown_allowed annotation on selected list-node arguments so
non-owning references with ref_obj_id==0 are accepted as well.

This patch only adds the generic verifier support and documents the
annotation. Later patches in the series will apply it to bpf_list_add
/del(), and bpf_list_is_first/last(), allowing bpf_list_front/back()
results to be used as the insertion point, deletion target, or query
target for those kfuncs.

Verifier keeps existing owning-ref checks by default; only arguments
annotated with __nonown_allowed bypass MEM_ALLOC/ref_obj_id checks
and then follow the same list-node validation path.

Signed-off-by: Kaitao Cheng <chengkaitao@kylinos.cn>
Reviewed-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260521032306.97118-4-kaitao.cheng@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
4 weeks agobpf: clear list node owner and unlink before drop
Kaitao Cheng [Thu, 21 May 2026 03:23:00 +0000 (11:23 +0800)] 
bpf: clear list node owner and unlink before drop

The issue only becomes exposed once bpf_list_del() is available: callers
can pass an arbitrary bpf_list_head and bpf_list_node pair, including
nodes that are not actually linked to the supplied head, or nodes that
outlive their original head after refcount-based retention.  This was
not practically reachable for callers restricted to pop-style helpers
alone; bpf_list_del() widens the API surface.

A failure mode appears when bpf_list_head_free() runs while a program
still holds an independent refcount on a node (for example via
bpf_refcount_acquire()).  The list head value embedded in map memory can
go away while the node object survives.  If node->owner is left pointing
at the old head address until drop completes, that pointer becomes stale.
If a new bpf_list_head is later allocated at the same address and the
stale node is passed to bpf_list_del(), the owner comparison can succeed
even though the node is not really linked to the new head, and
list_del_init() will follow bogus next/prev pointers with the risk of
memory corruption.

When draining a bpf_list_head, mark each node owner with BPF_PTR_POISON
under the map spinlock while moving it to a private drain list, then
list_del_init() the node and clear owner to NULL before calling
__bpf_obj_drop_impl().  Concurrent readers therefore never observe a
node that appears linked to a head while its list_head is inconsistent,
and surviving refcounted nodes never retain a stale non-NULL owner.

Signed-off-by: Kaitao Cheng <chengkaitao@kylinos.cn>
Link: https://lore.kernel.org/r/20260521032306.97118-3-kaitao.cheng@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
4 weeks agobpf: refactor __bpf_list_del to take list node pointer
Kaitao Cheng [Thu, 21 May 2026 03:22:59 +0000 (11:22 +0800)] 
bpf: refactor __bpf_list_del to take list node pointer

Refactor __bpf_list_del to accept (head, struct list_head *n) instead of
(head, bool tail). The caller now passes the specific node to remove:
bpf_list_pop_front passes h->next, bpf_list_pop_back passes h->prev.

Prepares for introducing bpf_list_del(head, node) kfunc to remove an
arbitrary node when the user holds ownership.

Signed-off-by: Kaitao Cheng <chengkaitao@kylinos.cn>
Reviewed-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260521032306.97118-2-kaitao.cheng@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
4 weeks agodrm/msm/hdmi: Use the common TMDS char rate constants in 8998 PHY
Javier Martinez Canillas [Wed, 20 May 2026 14:43:44 +0000 (16:43 +0200)] 
drm/msm/hdmi: Use the common TMDS char rate constants in 8998 PHY

Replace the driver local defines with the shared constants defined in the
<linux/hdmi.h> header for the minimum and maximum TMDS character rates.

Suggested-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260520144424.1633354-9-javierm@redhat.com
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
4 weeks agodrm/msm/hdmi: Use the common TMDS char rate constants in 8996 PHY
Javier Martinez Canillas [Wed, 20 May 2026 14:43:43 +0000 (16:43 +0200)] 
drm/msm/hdmi: Use the common TMDS char rate constants in 8996 PHY

Replace the driver local defines with the shared constants defined in the
<linux/hdmi.h> header for the minimum and maximum TMDS character rates.

Suggested-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260520144424.1633354-8-javierm@redhat.com
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
4 weeks agodrm/sun4i: hdmi: Use the common TMDS char rate constant
Javier Martinez Canillas [Wed, 20 May 2026 14:43:42 +0000 (16:43 +0200)] 
drm/sun4i: hdmi: Use the common TMDS char rate constant

Replace the 165000000 magic number with the shared constant defined
in the <linux/hdmi.h> header.

The old comment referenced "HDMI <= 1.2" but 165 MHz is actually
the maximum TMDS character rate defined by the HDMI 1.0 spec.

Suggested-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260520144424.1633354-7-javierm@redhat.com
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
4 weeks agodrm/sti: hdmi: Use the common TMDS char rate constants
Javier Martinez Canillas [Wed, 20 May 2026 14:43:41 +0000 (16:43 +0200)] 
drm/sti: hdmi: Use the common TMDS char rate constants

Replace the 340000000 and 165000000 magic numbers with the shared
constants defined in the <linux/hdmi.h> header.

Suggested-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260520144424.1633354-6-javierm@redhat.com
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
4 weeks agodrm/bridge: inno-hdmi: Use the common TMDS char rate constant
Javier Martinez Canillas [Wed, 20 May 2026 14:43:40 +0000 (16:43 +0200)] 
drm/bridge: inno-hdmi: Use the common TMDS char rate constant

Replace the driver local INNO_HDMI_MIN_TMDS_CLOCK define with the shared
constant defined in the <linux/hdmi.h> header.

Suggested-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260520144424.1633354-5-javierm@redhat.com
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
4 weeks agodrm/bridge: dw-hdmi-qp: Use the common TMDS char rate constant
Javier Martinez Canillas [Wed, 20 May 2026 14:43:39 +0000 (16:43 +0200)] 
drm/bridge: dw-hdmi-qp: Use the common TMDS char rate constant

Replace the driver local HDMI14_MAX_TMDSCLK define with the shared
constant defined in the <linux/hdmi.h> header.

The local define incorrectly referenced HDMI 1.4, but the 340 MHz
maximum TMDS character rate was actually introduced in HDMI 1.3.

Suggested-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260520144424.1633354-4-javierm@redhat.com
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
4 weeks agodrm/bridge: dw-hdmi: Use the common TMDS char rate constant
Javier Martinez Canillas [Wed, 20 May 2026 14:43:38 +0000 (16:43 +0200)] 
drm/bridge: dw-hdmi: Use the common TMDS char rate constant

Replace the driver local HDMI14_MAX_TMDSCLK define with the shared
constant defined in the <linux/hdmi.h> header.

The local define incorrectly referenced HDMI 1.4, but the 340 MHz
maximum TMDS character rate was actually introduced in HDMI 1.3.

Suggested-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260520144424.1633354-3-javierm@redhat.com
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
4 weeks agovideo/hdmi: Add common TMDS character rate constants
Javier Martinez Canillas [Wed, 20 May 2026 14:43:37 +0000 (16:43 +0200)] 
video/hdmi: Add common TMDS character rate constants

Several DRM drivers already define their own constants for minimum and
maximum TMDS character rates.

By defining common rate constants in a shared header, drivers can just use
them instead of having driver local define macros or use magic numbers.

The values defined in the <linux/hdmi.h> header correspond to maximum TMDS
character rates defined by each HDMI specification version:

  - HDMI_TMDS_CHAR_RATE_MIN_HZ:     25 MHz (minimum for all versions)
  - HDMI_1_0_TMDS_CHAR_RATE_MAX_HZ: 165 MHz (HDMI 1.0 maximum)
  - HDMI_1_3_TMDS_CHAR_RATE_MAX_HZ: 340 MHz (HDMI 1.3 maximum)
  - HDMI_2_0_TMDS_CHAR_RATE_MAX_HZ: 600 MHz (HDMI 2.0 maximum)

Suggested-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260520144424.1633354-2-javierm@redhat.com
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
4 weeks agodrm/rockchip: dw_hdmi: avoid direct dereference of phy->dev.of_node
Vladimir Oltean [Tue, 5 May 2026 10:05:07 +0000 (13:05 +0300)] 
drm/rockchip: dw_hdmi: avoid direct dereference of phy->dev.of_node

The dw_hdmi-rockchip driver validates pixel clock rates against the
HDMI PHY's internal clock provider on certain SoCs like RK3328.
This is currently achieved by dereferencing hdmi->phy->dev.of_node
to obtain the provider node, which violates the Generic PHY API's
encapsulation (the goal is for struct phy to be an opaque pointer
with a hidden definition, to be interacted with only using API
functions or NULL pointer checks, for the case where optional variants
of phy_get() did not find a PHY).

Refactor dw_hdmi_rockchip_bind() to perform a manual phandle lookup
on the "hdmi" PHY index within the controller's DT node. This provides
a parallel path to the clock provider's OF node without relying on the
internal structure of the struct phy handle.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260505100523.1922388-16-vladimir.oltean@nxp.com
4 weeks agonet: skbuff: propagate shared-frag marker through frag-transfer helpers
Hyunwoo Kim [Fri, 15 May 2026 22:28:53 +0000 (07:28 +0900)] 
net: skbuff: propagate shared-frag marker through frag-transfer helpers

Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail
to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when
moving frags from source to destination.  __pskb_copy_fclone() defers
the rest of the shinfo metadata to skb_copy_header() after copying
frag descriptors, but that helper only carries over gso_{size,segs,
type} and never touches skb_shinfo()->flags; skb_shift() moves frag
descriptors directly and leaves flags untouched.  As a result, the
destination skb keeps a reference to the same externally-owned or
page-cache-backed pages while reporting skb_has_shared_frag() as
false.

The mismatch is harmful in any in-place writer that uses
skb_has_shared_frag() to decide whether shared pages must be detoured
through skb_cow_data().  ESP input is one such writer (esp4.c,
esp6.c), and a single nft 'dup to <local>' rule -- or any other
nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d
skb in esp_input() with the marker stripped, letting an unprivileged
user write into the page cache of a root-owned read-only file via
authencesn-ESN stray writes.

Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors
were actually moved from the source.  skb_copy() and skb_copy_expand()
share skb_copy_header() too but linearize all paged data into freshly
allocated head storage and emerge with nr_frags == 0, so
skb_has_shared_frag() returns false on its own; they need no change.

The same omission exists in skb_gro_receive() and skb_gro_receive_list().
The former moves the incoming skb's frag descriptors into the
accumulator's last sub-skb via two paths (a direct frag-move loop and
the head_frag + memcpy path); the latter chains the incoming skb whole
onto p's frag_list.  Downstream skb_segment() reads only
skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's
shinfo as the nskb -- both p and lp must carry the marker.

The same omission also exists in tcp_clone_payload(), which builds an
MTU probe skb by moving frag descriptors from skbs on sk_write_queue
into a freshly allocated nskb.  The helper falls into the same family
and warrants the same fix for consistency; no TCP TX-side in-place
writer is currently known to reach a user page through this gap, but
a future consumer depending on the marker would regress silently.

The same omission exists in skb_segment(): the per-iteration flag
merge takes only head_skb's flag, and the inner switch that rebinds
frag_skb to list_skb on head_skb-frags exhaustion does not fold the
new frag_skb's flag into nskb.  Fold frag_skb's flag at both sites
so segments drawing frags from frag_list members carry the marker.

Fixes: cef401de7be8 ("net: fix possible wrong checksum generation")
Fixes: f4c50a4034e6 ("xfrm: esp: avoid in-place decrypt on shared skb frags")
Suggested-by: Sabrina Dubroca <sd@queasysnail.net>
Suggested-by: Sultan Alsawaf <sultan@kerneltoast.com>
Suggested-by: Ben Hutchings <ben@decadent.org.uk>
Suggested-by: Lin Ma <malin89@huawei.com>
Suggested-by: Jingguo Tan <tanjingguo@huawei.com>
Suggested-by: Aaron Esau <aaron1esau@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
Tested-by: Rajat Gupta <rajat.gupta@oss.qualcomm.com>
Link: https://patch.msgid.link/ageeJfJHwgzmKXbh@v4bel
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
4 weeks agoMerge patch series "vfs: add O_EMPTYPATH to openat(2)/openat2(2)"
Christian Brauner [Mon, 11 May 2026 10:27:46 +0000 (12:27 +0200)] 
Merge patch series "vfs: add O_EMPTYPATH to openat(2)/openat2(2)"

Jori Koolstra <jkoolstra@xs4all.nl> says:

To get an operable version of an O_PATH file descriptor, it is possible
to use openat(fd, ".", O_DIRECTORY) for directories, but other files
currently require going through open("/proc/<pid>/fd/<nr>"), which
depends on a functioning procfs.

This patch adds the O_EMPTYPATH flag to openat(2)/openat2(2). If passed,
LOOKUP_EMPTY is set at path resolution time.

* patches from https://patch.msgid.link/20260424114611.1678641-1-jkoolstra@xs4all.nl:
  selftest: add tests for O_EMPTYPATH
  vfs: add O_EMPTYPATH to openat(2)/openat2(2)

Link: https://patch.msgid.link/20260424114611.1678641-1-jkoolstra@xs4all.nl
Signed-off-by: Christian Brauner <brauner@kernel.org>
4 weeks agoopenat2: introduce EFTYPE error code
Dorjoy Chowdhury [Sat, 28 Mar 2026 17:22:22 +0000 (23:22 +0600)] 
openat2: introduce EFTYPE error code

Introduce a new error code EFTYPE for wrong file type operations.
EFTYPE is already used in BSD systems like FreeBSD and macOS.

This will be used by the upcoming OPENAT2_REGULAR flag support to
return a specific error when a path doesn't refer to a regular file.

Signed-off-by: Dorjoy Chowdhury <dorjoychy111@gmail.com>
Link: https://patch.msgid.link/20260328172314.45807-2-dorjoychy111@gmail.com
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Aleksa Sarai <aleksa@amutable.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
4 weeks agoselftest: add tests for O_EMPTYPATH
Jori Koolstra [Fri, 24 Apr 2026 11:46:03 +0000 (13:46 +0200)] 
selftest: add tests for O_EMPTYPATH

Add tests for the new O_EMPTYPATH flag of openat(2)/openat2(2).

Also, the current openat2 tests include a helper header file that
defines the necessary structs and constants to use openat2(2), such as
struct open_how. This may result in conflicting definitions when the
system header openat2.h is present as well.

So add openat2.h generated by 'make headers' to the uapi header
files in ./tools/include and remove the helper file definitions of
the current openat2 selftests.

Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
Link: https://patch.msgid.link/20260424114611.1678641-3-jkoolstra@xs4all.nl
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
4 weeks agoMerge patch series "selftests: openat2: migrate to kselftest harness"
Christian Brauner [Thu, 9 Apr 2026 13:30:15 +0000 (15:30 +0200)] 
Merge patch series "selftests: openat2: migrate to kselftest harness"

Aleksa Sarai <aleksa@amutable.com> says:

These tests were written in the early days of selftests' TAP support,
the more modern kselftest harness is much easier to follow and maintain.
The actual contents of the tests are unchanged by this change.

* patches from https://patch.msgid.link/20260401-openat2-selftests-kunit-v2-0-ad153a07da0c@amutable.com:
  selftests: openat2: migrate to kselftest harness
  selftests: openat2: switch from custom ARRAY_LEN to ARRAY_SIZE
  selftests: openat2: move helpers to header
  selftests: move openat2 tests to selftests/filesystems/

Link: https://patch.msgid.link/20260401-openat2-selftests-kunit-v2-0-ad153a07da0c@amutable.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
4 weeks agovfs: add O_EMPTYPATH to openat(2)/openat2(2)
Jori Koolstra [Fri, 24 Apr 2026 11:46:02 +0000 (13:46 +0200)] 
vfs: add O_EMPTYPATH to openat(2)/openat2(2)

To get an operable version of an O_PATH file descriptor, it is possible
to use openat(fd, ".", O_DIRECTORY) for directories, but other files
currently require going through open("/proc/<pid>/fd/<nr>"), which
depends on a functioning procfs.

This patch adds the O_EMPTYPATH flag to openat(2)/openat2(2). If passed,
LOOKUP_EMPTY is set at path resolution time.

Note: This implies that you cannot rely anymore on disabling procfs from
being mounted (e.g. inside a container without procfs mounted and with
CAP_SYS_ADMIN dropped) to prevent O_PATH fds from being re-opened
read-write.

Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
Link: https://patch.msgid.link/20260424114611.1678641-2-jkoolstra@xs4all.nl
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
4 weeks agoselftests: openat2: migrate to kselftest harness
Aleksa Sarai [Wed, 1 Apr 2026 00:28:05 +0000 (11:28 +1100)] 
selftests: openat2: migrate to kselftest harness

These tests were written in the early days of selftests' TAP support,
the more modern kselftest harness is much easier to follow and maintain.
The actual contents of the tests are unchanged by this change. Most of
the diff involves switching from the E_* syscall wrappers we previously
used to ASSERT_EQ(fn(...), 0) in tests and helper functions.

The first pass of the migration was done using Claude, followed by a
manual rework and review.

Assisted-by: Claude:claude-4.6-opus
Signed-off-by: Aleksa Sarai <aleksa@amutable.com>
Link: https://patch.msgid.link/20260401-openat2-selftests-kunit-v2-4-ad153a07da0c@amutable.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
4 weeks agoselftests: openat2: switch from custom ARRAY_LEN to ARRAY_SIZE
Aleksa Sarai [Wed, 1 Apr 2026 00:28:04 +0000 (11:28 +1100)] 
selftests: openat2: switch from custom ARRAY_LEN to ARRAY_SIZE

For whatever reason, the original version of the tests used a custom
version of ARRAY_SIZE, but ARRAY_SIZE works just as well.

Signed-off-by: Aleksa Sarai <aleksa@amutable.com>
Link: https://patch.msgid.link/20260401-openat2-selftests-kunit-v2-3-ad153a07da0c@amutable.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
4 weeks agoselftests: openat2: move helpers to header
Aleksa Sarai [Wed, 1 Apr 2026 00:28:03 +0000 (11:28 +1100)] 
selftests: openat2: move helpers to header

This is a bit ugly, but in the next patch we will move to using
kselftest_harness.h -- which doesn't play well with being included in
multiple compilation units due to duplicate function definitions.

Not including kselftest_harness.h would let us avoid this patch, but the
helpers will need include kselftest_harness.h in order to switch to
TH_LOG.

Signed-off-by: Aleksa Sarai <aleksa@amutable.com>
Link: https://patch.msgid.link/20260401-openat2-selftests-kunit-v2-2-ad153a07da0c@amutable.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
4 weeks agoselftests: move openat2 tests to selftests/filesystems/
Aleksa Sarai [Wed, 1 Apr 2026 00:28:02 +0000 (11:28 +1100)] 
selftests: move openat2 tests to selftests/filesystems/

These tests really should've always belonged there, doubly so now that
they include a lot of other generic filesystem-related tests.

Suggested-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Aleksa Sarai <aleksa@amutable.com>
Link: https://patch.msgid.link/20260401-openat2-selftests-kunit-v2-1-ad153a07da0c@amutable.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
4 weeks agogpio: dwapb: Add ACPI ID LECA0001 for LECARC SoCs
Thomas Lin [Thu, 21 May 2026 02:34:49 +0000 (10:34 +0800)] 
gpio: dwapb: Add ACPI ID LECA0001 for LECARC SoCs

Add ACPI ID "LECA0001" for LECARC SoCs that use the DesignWare
GPIO controller with V1 register offsets.

Signed-off-by: Thomas Lin <thomas_lin@lecomputing.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260521-lecarc-acpi-ids-v1-1-ae0ae90b2817@lecomputing.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
4 weeks agoregmap-i2c: fix sparse warning in regmap_smbus_word_write_reg16
Nishanth Sampath Kumar [Wed, 20 May 2026 15:11:09 +0000 (08:11 -0700)] 
regmap-i2c: fix sparse warning in regmap_smbus_word_write_reg16

i2c_smbus_write_word_data() expects a plain u16, but cpu_to_le16()
returns __le16 (a sparse-restricted endian type), causing:

  drivers/base/regmap/regmap-i2c.c:340: sparse: incorrect type in
  argument 3 (different base types)
    expected unsigned short [usertype] value
    got restricted __le16 [usertype]

SMBus already defines byte ordering internally, so cpu_to_le16() is
wrong here. Replace it with a plain (u16) cast.

Fixes: bad4bd28abf4 ("regmap-i2c: add SMBus byte/word reg16 bus for adapters lacking I2C_FUNC_I2C")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202605161621.mY5zFh4D-lkp@intel.com/
Signed-off-by: Nishanth Sampath Kumar <nissampa@cisco.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
4 weeks agogpio: tegra186: Enable GTE for Tegra264
Suneel Garapati [Thu, 21 May 2026 01:20:30 +0000 (01:20 +0000)] 
gpio: tegra186: Enable GTE for Tegra264

Set has_gte flag to enable GTE for Tegra264 AON pins.

Signed-off-by: Suneel Garapati <suneelg@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260521012031.2003914-1-suneelg@nvidia.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
4 weeks agocomedi: comedi_test: fix check for valid scan_begin_src in waveform_ai_cmdtest()
Ian Abbott [Wed, 22 Apr 2026 16:21:19 +0000 (17:21 +0100)] 
comedi: comedi_test: fix check for valid scan_begin_src in waveform_ai_cmdtest()

Commit 783ddaebd397 ("staging: comedi: comedi_test: support
scan_begin_src == TRIG_FOLLOW") neglected to add a test that
`scan_begin_src` has only one bit set.  The allowed values are
`TRIG_FOLLOW` and `TRIG_TIMER`, but the code incorrectly also allows
`TRIG_FOLLOW | TRIG_TIMER`.  Add a call to
`comedi_check_trigger_is_unique()` to check that only one trigger source
bit is set.

Fixes: 783ddaebd397 ("staging: comedi: comedi_test: support scan_begin_src == TRIG_FOLLOW")
Cc: stable <stable@kernel.org>
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260422162138.36003-1-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
4 weeks agocomedi: comedi_test: Fix limiting of convert_arg in waveform_ai_cmdtest()
Ian Abbott [Wed, 22 Apr 2026 14:46:37 +0000 (15:46 +0100)] 
comedi: comedi_test: Fix limiting of convert_arg in waveform_ai_cmdtest()

The function checks and possibly modifies the description of an
asynchronous command to be run on the analog input subdevice of a comedi
device attached to the "comedi_test" driver, returning 0 if no
modifications were required, or a positive value that indicates which
step of the checking process it failed on.  Step 4 fixes up various
argument values for various trigger sources.

There are two bugs in the fixing up of the `convert_arg` value to keep
the `scan_begin_arg` value within the range of `unsigned int` when
`scan_begin_src` and `convert_src` both have the value `TRIG_TIMER`,
which indicates that the corresponding `_arg` values hold a time period
in nanoseconds.  The code also uses `scan_end_arg` which hold the number
of "conversions" within each "scan".  The goal is to end up with the
scan period being less than or equal to the convert period multiplied by
the number of conversions per scan.  It intends to do that by clamping
the `convert_arg` value to a maximum value of `UINT_MAX / scan_end_arg`
rounded down to a multiple of 1000 (`NSEC_PER_USEC`).

(The rounding from nanoseconds to microseconds is because the driver is
modelling a device that uses a 1 MHz clock for timing.  This is partly
because that is a more typical timing base for real hardware devices
driven by comedi, and partly because the driver used to use `struct
timeval` internally.)

The first bug is that the code checks if `scan_begin_arg == TRIG_TIMER`
when it should be checking if `scan_begin_src == TRIG_TIMER`.  The
bugged check will always fail because if `scan_begin_src == TRIG_TIMER`,
then `scan_begin_arg` will be at least 1000 (`NSEC_PER_USEC`), otherwise
`scan_begin_src == TRIG_FOLLOW` and `scan_begin_arg` will be 0.  (N.B
`TRIG_TIMER` is defined as `0x10`.)  The second bug is that is rounding
the maximum value down to a multiple of 1000000000 (`NSEC_PER_SEC`)
instead of 1000 (`NSEC_PER_USEC`), however this bug is not reached due
to the first bug.  This patch fixes both bugs.

Fixes: 783ddaebd397 ("staging: comedi: comedi_test: support scan_begin_src == TRIG_FOLLOW")
Fixes: 5afdcad2f818 ("staging: comedi: comedi_test: limit maximum convert_arg")
Cc: stable <stable@kernel.org>
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260422144637.27692-1-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
4 weeks agogpio: pca953x: propagate regulator_enable() error from resume
Stepan Ionichev [Wed, 20 May 2026 11:05:04 +0000 (16:05 +0500)] 
gpio: pca953x: propagate regulator_enable() error from resume

pca953x_resume() returns 0 when regulator_enable() fails, dropping
the real error code and masking the failure as a successful resume.
The caller then proceeds as if the chip is powered, while the
regulator is in fact disabled.

Return ret so PM core sees the actual failure.

Signed-off-by: Stepan Ionichev <sozdayvek@gmail.com>
Link: https://patch.msgid.link/20260520110504.13969-1-sozdayvek@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
4 weeks agoUSB: serial: option: add missing RSVD(5) flag for Rolling RW135R-GL
Wanquan Zhong [Wed, 20 May 2026 11:32:45 +0000 (19:32 +0800)] 
USB: serial: option: add missing RSVD(5) flag for Rolling RW135R-GL

The RW135R-GL entry added in commit 01e8d0f74222 ("USB: serial: option:
add support for Rolling Wireless RW135R-GL") was missing the
.driver_info = RSVD(5) flag used by other Rolling Wireless MBIM laptop
modules (e.g. RW135-GL and RW350-GL).

Without this flag, the option driver incorrectly binds to the reserved
ADB interface (If#5) in multi-interface USB modes, causing AT/MBIM
communication failures after mode switching. This matches the handling
of other Rolling Wireless MBIM devices.

- VID:PID 33f8:1003, RW135R-GL for laptop debug M.2 cards (with MBIM
  interface for Linux/Chrome OS)

  0x1003: mbim, diag, AT, pipe

  Here are the outputs of usb-devices:

T:  Bus=03 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#=  8 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=33f8 ProdID=1003 Rev= 5.15
S:  Manufacturer=Rolling Wireless S.a.r.l.
S:  Product=Rolling RW135R-GL Module
S:  SerialNumber=12345678
C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

- VID:PID 33f8:1003, RW135R-GL for laptop debug M.2 cards (with MBIM
  interface for Linux/Chrome OS)

  0x1003: mbim, diag, AT, ADB, pipe

  Here are the outputs of usb-devices:

T:  Bus=03 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#=  7 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=33f8 ProdID=1003 Rev= 5.15
S:  Manufacturer=Rolling Wireless S.a.r.l.
S:  Product=Rolling RW135R-GL Module
S:  SerialNumber=12345678
C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

- VID:PID 33f8:1003, RW135R-GL for laptop debug M.2 cards (with MBIM
  interface for Linux/Chrome OS)

  0x1003: mbim, pipe

  Here are the outputs of usb-devices:

T:  Bus=03 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#=  9 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=33f8 ProdID=1003 Rev= 5.15
S:  Manufacturer=Rolling Wireless S.a.r.l.
S:  Product=Rolling RW135R-GL Module
S:  SerialNumber=12345678
C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=500mA
A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Fixes: 01e8d0f74222 ("USB: serial: option: add support for Rolling Wireless RW135R-GL")
Signed-off-by: Wanquan Zhong <wanquan.zhong@fibocom.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
4 weeks agoUSB: serial: option: add MeiG SRM813Q
Jan Volckaert [Sun, 17 May 2026 15:32:37 +0000 (17:32 +0200)] 
USB: serial: option: add MeiG SRM813Q

Add support for the Qualcomm Technology Snapdragon X35-based MeiG
SRM813Q module.

The module can be put in different modes via AT commands to
enable/disable GPS functionality:

MODEM - PPP mode(2dee:4d63): AT+SER=1,1

If#= 0: RMNET
If#= 1: DIAG/ADB
If#= 2: MODEM
If#= 3: AT

P:  Vendor=2dee ProdID=4d63 Rev=05.15
S:  Manufacturer=MEIG
S:  Product=LTE-A Module
S:  SerialNumber=1bd51f0e
C:  #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms

NMEA mode(2dee:4d64): AT+SER=51,1

If#= 0: RMNET
If#= 1: DIAG/ADB
If#= 2: NMEA
If#= 3: AT

P:  Vendor=2dee ProdID=4d64 Rev=05.15
S:  Manufacturer=MEIG
S:  Product=LTE-A Module
S:  SerialNumber=1bd51f0e
C:  #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms

Signed-off-by: Jan Volckaert <janvolck@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
4 weeks agodcache: use kmalloc_flex() in __d_alloc
Thorsten Blum [Fri, 17 Apr 2026 09:42:40 +0000 (11:42 +0200)] 
dcache: use kmalloc_flex() in __d_alloc

Use kmalloc_flex() when allocating a new 'struct external_name' in
__d_alloc() to replace offsetof() and the open-coded size arithmetic,
and to keep the size type-safe.

Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Link: https://patch.msgid.link/20260417094238.551114-3-thorsten.blum@linux.dev
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Jori Koolstra <jkoolstra@xs4all.nl>
Signed-off-by: Christian Brauner <brauner@kernel.org>
4 weeks agovfs: remove always taken if-branch in find_next_fd()
Jori Koolstra [Mon, 20 Apr 2026 10:18:01 +0000 (12:18 +0200)] 
vfs: remove always taken if-branch in find_next_fd()

find_next_fd() finds the next free fd slot in the passed fdtable's
bitmap. It does so in two steps: first it checks whether the bitmap
has a free entry in the word containing start. If not, it looks at
second level bitmap that registers which words in the first level bitmap
are full and then looks at the first level bitmap at the first non-full
word.

In the current code the second level lookup is done by:

  bitbit = find_next_zero_bit(fdt->full_fds_bits, maxbit, bitbit) *
    BITS_PER_LONG;

where bitbit = start / BITS_PER_LONG. However, in the fast path (first
step) we already checked the word at bitbit, so we can skip that word bit
and start at bitbit+1. This also means that we can get rid of the branch

  if (bitbit > start)
    start = bitbit;

since if we set

  bitbit = find_next_zero_bit(fdt->full_fds_bits, maxbit, bitbit+1) *
    BITS_PER_LONG;

the reassigned bitbit can never be less than

  ((start/BITS_PER_LONG)+1) * BITS_PER_LONG > start

So the branch is always taken.

Obviously the reuse of the variable name bitbit (and the name itself) is
quite confusing, so change that as well.

Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
Link: https://patch.msgid.link/20260420101801.806785-1-jkoolstra@xs4all.nl
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
4 weeks agoiov_iter: use kmemdup_array for dup_iter to harden against overflow
Wang Haoran [Mon, 13 Apr 2026 06:06:55 +0000 (14:06 +0800)] 
iov_iter: use kmemdup_array for dup_iter to harden against overflow

While auditing the Linux 7.0-rc2 kernel, I identified a potential security
vulnerability in the iov_iter framework's memory allocation logic.

The dup_iter() function, which is exported via EXPORT_SYMBOL, currently
uses kmemdup() with a raw multiplication to allocate the duplicate iovec array:

new->iov = kmemdup(from->iov, nr_segs * sizeof(struct iovec), gfp);

The hazard here is that dup_iter() relies on a primitive multiplication without
any integrated overflow check. Since nr_segs is often derived from user-space
input, this line is vulnerable to integer overflow (on 32-bit systems or
via type narrowing), potentially leading to a small allocation followed by a
large out-of-bounds memory copy. Furthermore, it allows for unbounded memory
allocations, as the function lacks intrinsic knowledge of safe limits.

On the 7.0-rc2 branch, several high-impact callchains still rely on this
exported function:

drivers/usb/gadget/function/f_fs.c:
The ffs_epfile_read_iter() path demonstrates why relying on dup_iter() is
dangerous: it performs allocation based on user input before verifying driver
state. This confirms that dup_iter() must be hardened internally as it cannot
assume pre-validated input.

drivers/usb/gadget/legacy/inode.c:
The ep_read_iter() path illustrates how dup_iter()’s lack of boundary awareness
compounds resource risks. When combined with other allocations, it creates
a multiplier effect for kernel memory pressure.

This patch replaces kmemdup() with kmemdup_array(), which utilizes
check_mul_overflow() to ensure the allocation size is calculated safely,
hardening dup_iter() against malicious or malformed inputs from its callers

Signed-off-by: Wang Haoran <haoranwangsec@gmail.com>
Link: https://patch.msgid.link/20260413060655.1139141-1-haoranwangsec@gmail.com
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christian Brauner <brauner@kernel.org>
4 weeks agoMerge patch series "initramfs: test and improve cpio hex header validation"
Christian Brauner [Thu, 9 Apr 2026 13:34:28 +0000 (15:34 +0200)] 
Merge patch series "initramfs: test and improve cpio hex header validation"

David Disseldorp <ddiss@suse.de> says:

The series that introduced simple_strntoul() had passed into kernel
without proper review and hence reinvented a wheel that's not needed.
Here is the refactoring to show that. It can go via PRINTK or VFS
tree.

I have tested this on x86, but I believe the same result will be
on big-endian CPUs (I deduced that from how strtox() works).

I also run KUnit tests.

* patches from https://patch.msgid.link/20260331070519.5974-1-ddiss@suse.de:
  kstrtox: Drop extern keyword in the simple_strtox() declarations
  vsprintf: Revert "add simple_strntoul"
  initramfs: Refactor to use hex2bin() instead of custom approach
  initramfs: Sort headers alphabetically
  initramfs_test: test header fields with 0x hex prefix
  initramfs_test: add fill_cpio() inject_ox parameter

Link: https://patch.msgid.link/20260331070519.5974-1-ddiss@suse.de
Signed-off-by: Christian Brauner <brauner@kernel.org>
4 weeks agokstrtox: Drop extern keyword in the simple_strtox() declarations
Andy Shevchenko [Tue, 31 Mar 2026 06:57:36 +0000 (17:57 +1100)] 
kstrtox: Drop extern keyword in the simple_strtox() declarations

There is legacy 'extern' keyword for the exported simple_strtox()
function which are the artefact that can be removed. So drop it.

While at it, tweak the declaration to provide parameter names.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260331070519.5974-7-ddiss@suse.de
Reviewed-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
4 weeks agovsprintf: Revert "add simple_strntoul"
Andy Shevchenko [Tue, 31 Mar 2026 06:57:35 +0000 (17:57 +1100)] 
vsprintf: Revert "add simple_strntoul"

No users anymore and none should be in the first place.

This reverts commit fcc155008a20fa31b01569e105250490750f0687.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260331070519.5974-6-ddiss@suse.de
Acked-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Christian Brauner <brauner@kernel.org>
4 weeks agoinitramfs: Refactor to use hex2bin() instead of custom approach
Andy Shevchenko [Tue, 31 Mar 2026 06:57:34 +0000 (17:57 +1100)] 
initramfs: Refactor to use hex2bin() instead of custom approach

There is a simple_strntoul() function used solely as a shortcut
for hex2bin() with proper endianess conversions. Replace that
and drop the unneeded function in the next changes.

This implementation will abort if we fail to parse the cpio header,
instead of using potentially bogus header values.

Co-developed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260331070519.5974-5-ddiss@suse.de
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
4 weeks agoinitramfs: Sort headers alphabetically
Andy Shevchenko [Tue, 31 Mar 2026 06:57:33 +0000 (17:57 +1100)] 
initramfs: Sort headers alphabetically

Sorting headers alphabetically helps locating duplicates, and makes it
easier to figure out where to insert new headers.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260331070519.5974-4-ddiss@suse.de
Reviewed-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
4 weeks agoinitramfs_test: test header fields with 0x hex prefix
David Disseldorp [Tue, 31 Mar 2026 06:57:32 +0000 (17:57 +1100)] 
initramfs_test: test header fields with 0x hex prefix

cpio header fields are 8-byte hex strings, but one "interesting"
side-effect of our historic simple_str[n]toul() use means that a "0x"
(or "0X") prefixed header field will be successfully processed when
coupled alongside a 6-byte hex remainder string.

"0x" prefix support is contrary to the initramfs specification at
Documentation/driver-api/early-userspace/buffer-format.rst which states:

  The structure of the cpio_header is as follows (all fields contain
  hexadecimal ASCII numbers fully padded with '0' on the left to the
  full width of the field, for example, the integer 4780 is represented
  by the ASCII string "000012ac"):

Test for this corner case by injecting "0x" prefixes into the uid, gid
and namesize cpio header fields. Confirm that init_stat() returns
matching uid and gid values.

This test can be modified in future to expect unpack_to_rootfs() failure
when header validation is changed to properly follow the specification.

Add some missing struct kstat initializations to account for possible
init_stat() failures.

Signed-off-by: David Disseldorp <ddiss@suse.de>
Link: https://patch.msgid.link/20260331070519.5974-3-ddiss@suse.de
Reviewed-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
4 weeks agoinitramfs_test: add fill_cpio() inject_ox parameter
David Disseldorp [Tue, 31 Mar 2026 06:57:31 +0000 (17:57 +1100)] 
initramfs_test: add fill_cpio() inject_ox parameter

fill_cpio() uses sprintf() to write out the in-memory cpio archive from
an array of struct initramfs_test_cpio. This change allows callers to
modify the cpio sprintf() format string so that future tests can
intentionally corrupt the header with "0x" and "0X" prefixed fields.

Signed-off-by: David Disseldorp <ddiss@suse.de>
Link: https://patch.msgid.link/20260331070519.5974-2-ddiss@suse.de
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
4 weeks agosched_ext: Add cmask mask ops
Tejun Heo [Tue, 19 May 2026 07:53:11 +0000 (21:53 -1000)] 
sched_ext: Add cmask mask ops

Sub-sched cap code and other upcoming consumers need bulk cmask ops, both
mutating (and/or/copy/andnot) and predicate (subset/intersects/empty).

cmask_walk_op2() walks the intersection of two ranges word by word;
cmask_walk_op1() walks one range. Both are __always_inline and dispatched on
a compile-time-constant op enum, so each public entry collapses to a
specialized loop with the inner switch reduced to one arm.

Two-cmask ops only touch bits in the intersection of the two ranges; bits
outside are left unchanged. scx_cmask_or_racy() and scx_cmask_copy_racy()
mirror the locking forms but read @src word-by-word through data_race();
callers handle ordering with concurrent writers themselves.

v2: Add scx_cmask_empty().

Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Andrea Righi <arighi@nvidia.com>
4 weeks agosched_ext: Track bits[] storage size in struct scx_cmask
Tejun Heo [Tue, 19 May 2026 07:53:11 +0000 (21:53 -1000)] 
sched_ext: Track bits[] storage size in struct scx_cmask

scx_cmask carries @base and @nr_cids but not the bits[] allocation size, so
helpers reshaping the active range have no way to check it fits and later
kfuncs taking caller-provided storage can't validate it.

Add @alloc_words (u64 word count) annotated with __counted_by, and split the
bit-range API into three helpers:

- SCX_CMASK_DEFINE() / __SCX_CMASK_DEFINE() define an on-stack cmask, the
  latter taking an explicit capacity for oversized storage.
  SCX_CMASK_DEFINE_SHARD() is a thin wrapper that always reserves
  SCX_CID_SHARD_MAX_CPUS bits of storage.

- scx_cmask_init() / __scx_cmask_init() initialize a cmask, with the same
  tight-vs-explicit split.

- scx_cmask_reframe() reshapes the active range without resizing storage.

The BPF mirror (cmask_init / __cmask_init / cmask_reframe) gets the same
shape.

Add scx_cmask_clear() and scx_cmask_fill() to zero and set the
active-range bits respectively. scx_cpumask_to_cmask() uses
scx_cmask_clear(); scx_cmask_init() would otherwise re-write @alloc_words
on every call.

A later patch uses @alloc_words in scx_cmask_ref_shard() to refuse output
storage that can't hold the requested shard.

v2: Init per-CPU scx_set_cmask_scratch (was zero-init, emitted empty
    cmasks). Add nr_cids/alloc_cids check in BPF __cmask_init().
    (sashiko AI)
    Widen SCX_CMASK_NR_WORDS()/CMASK_NR_WORDS() to compute in u64 so that
    @nr_cids near U32_MAX no longer wraps to a small value and bypasses
    the bounds check in cmask_reframe(). (Andrea)

Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Andrea Righi <arighi@nvidia.com>
4 weeks agosched_ext: Rename scx_cmask.nr_bits to nr_cids
Tejun Heo [Tue, 19 May 2026 07:53:11 +0000 (21:53 -1000)] 
sched_ext: Rename scx_cmask.nr_bits to nr_cids

struct scx_cmask is a base-windowed bitmap over cid space. Each bit
represents one cid, so the count of active bits is the count of cids. The
sibling struct scx_cid_shard already uses nr_cids. Rename as a prep so the
following patches that grow the cmask API can use the consistent name.

v2: Also rename src->nr_bits / dst->nr_bits in
    cmask_copy_from_kernel(). (sashiko AI)

Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Andrea Righi <arighi@nvidia.com>
4 weeks agomedia: renesas: vsp1: Drop deprecated vsp1_du_setup_lif() function
Laurent Pinchart [Mon, 11 May 2026 23:56:35 +0000 (02:56 +0300)] 
media: renesas: vsp1: Drop deprecated vsp1_du_setup_lif() function

The vsp1_du_setup_lif() is deprecated and its last users are gone. Drop
it.

Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Link: https://patch.msgid.link/20260511235637.3468558-12-laurent.pinchart+renesas@ideasonboard.com
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
4 weeks agomedia: renesas: vsp1: Simplify iteration over format arrays
Laurent Pinchart [Mon, 11 May 2026 23:56:33 +0000 (02:56 +0300)] 
media: renesas: vsp1: Simplify iteration over format arrays

Introduce a vsp1_for_each_format() macro to iterate over format arrays,
to improve readability. No functional change intended.

Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Link: https://patch.msgid.link/20260511235637.3468558-10-laurent.pinchart+renesas@ideasonboard.com
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>