]> git.ipfire.org Git - thirdparty/linux.git/log
thirdparty/linux.git
6 weeks agodrm/crc: Fix typo in doc for drm_crtc_crc
Eduardo Vasconcelos [Fri, 24 Apr 2026 18:36:29 +0000 (15:36 -0300)] 
drm/crc: Fix typo in doc for drm_crtc_crc

Fix a typo in the documentation for struct drm_crtc_crc
("occured." -> "occurred").

Signed-off-by: Eduardo Vasconcelos <eduardo@eduardovasconcelos.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260424183630.3764-1-eduardo@eduardovasconcelos.com
6 weeks agox86/boot: Get rid of kstrtoull()
Borislav Petkov (AMD) [Mon, 4 May 2026 12:26:13 +0000 (14:26 +0200)] 
x86/boot: Get rid of kstrtoull()

Fold the '+' check in the single-underscore-prefixed version
_kstrtoull() and remove the function. The arch/x86/boot/ namespace
prefixes everything copied from kernel proper with "boot_" so that
namespace clashes can be avoided.

No functional changes.

Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
6 weeks agox86/boot/compressed: Use boot_kstrtoul() for hugepages= parsing
Thorsten Blum [Thu, 9 Apr 2026 16:15:59 +0000 (18:15 +0200)] 
x86/boot/compressed: Use boot_kstrtoul() for hugepages= parsing

Replace simple_strtoull() with boot_kstrtoul() for parsing the hugepages= boot
parameter.

Unlike simple_strtoull(), boot_kstrtoul() performs strict validation and
returns an error on invalid inputs instead of silently accepting partial
input. Use boot_kstrtoul() to reject and warn about invalid hugepages= values.

boot_kstrtoul() also converts the input directly to an unsigned long and
avoids implicit casting as max_gb_huge_pages *is* an unsigned long.

  [ bp: Massage commit message. ]

Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260409161600.152012-2-thorsten.blum@linux.dev
6 weeks agodrm/vmwgfx: Convert to DRM vblank timers
Thomas Zimmermann [Mon, 27 Apr 2026 15:00:40 +0000 (17:00 +0200)] 
drm/vmwgfx: Convert to DRM vblank timers

Replace vmwgfx's vblank timer with DRM's common implementation. The
timer handling is almost identical with a few additional bug fixes in
the common code.

Replace most of vmwgfx's vmw_vkms_get_vblank_timestamp() with the
shared helper drm_crtc_vblank_get_vblank_timeout(). The common helper
also works in the presence of delayed vblank timeouts that modify the
vblank counter concurrently.

Set the timeout handler to vmw_vkms_handle_vblank_timeout(). In addition
to handling vblank events, this function also controls CRC generation.

Remove all the hrtimer-related code from vmwgfx. DRM vblank timers
provides this.

v2:
- only cancel vblank timer in CRTC cleanup if vkms_enabled (Zack)

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Zack Rusin <zack.rusin@broadcom.com>
Link: https://patch.msgid.link/20260427150250.699768-4-tzimmermann@suse.de
6 weeks agodrm/vmwgfx: Move vblank handling into separate helper
Thomas Zimmermann [Mon, 27 Apr 2026 15:00:39 +0000 (17:00 +0200)] 
drm/vmwgfx: Move vblank handling into separate helper

Decouple vblank handling from the underlying hrtimer. This will be
helpful for replacing vmwgfx's vblank timer with DRM's common
implementation.

The new helper vmw_vkms_handle_vblank_timeout() can later be used as
callback for DRM's handle_vblank call as-is. The helper also keeps the
current semantics for restarting the timer. It returns true to restart
the next vblank timeout even if it could not acquire vmwgfx's vblank
lock.

The remaining code in vmw_vkms_vblank_simulate() will be replaced by
the DRM implementation in a later patch.

v2:
- clarify return-value semantics in commit message (Zack)

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Zack Rusin <zack.rusin@broadcom.com>
Link: https://patch.msgid.link/20260427150250.699768-3-tzimmermann@suse.de
6 weeks agodrm/vmwgfx: Determine lock-waiting timeout from vblank state
Thomas Zimmermann [Mon, 27 Apr 2026 15:00:38 +0000 (17:00 +0200)] 
drm/vmwgfx: Determine lock-waiting timeout from vblank state

Use the calculated duration of a frame as stored in the vblank state
for the lock-waiting timeout. Decouples the waiting from the details
of the vblank implementation. Both values should be equal.

This will be helpful for replacing vmwgfx's vblank timer with DRM's
common implementation.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Zack Rusin <zack.rusin@broadcom.com>
Link: https://patch.msgid.link/20260427150250.699768-2-tzimmermann@suse.de
6 weeks agodrm: verisilicon: fill plane's vs_format in atomic_check
Icenowy Zheng [Tue, 31 Mar 2026 06:01:26 +0000 (14:01 +0800)] 
drm: verisilicon: fill plane's vs_format in atomic_check

Move the conversion from drm_format to vs_format to atomic_check, which
is before the point of no return and can properly bail out.

Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260331060126.1291966-5-zhengxingda@iscas.ac.cn
6 weeks agodrm: verisilicon: call atomic helper's plane state check even if no CRTC
Icenowy Zheng [Tue, 31 Mar 2026 06:01:25 +0000 (14:01 +0800)] 
drm: verisilicon: call atomic helper's plane state check even if no CRTC

The `drm_atomic_helper_check_plane_state()` helper function needs to be
called even if the plane is bound to no CRTCs.

Remove the early return in the primary plane's atomic_check, and use
NULL for crtc_state in this situation.

Fixes: dbf21777caa8 ("drm: verisilicon: add a driver for Verisilicon display controllers")
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260331060126.1291966-4-zhengxingda@iscas.ac.cn
6 weeks agodrm: verisilicon: subclass drm_plane_state
Icenowy Zheng [Tue, 31 Mar 2026 06:01:24 +0000 (14:01 +0800)] 
drm: verisilicon: subclass drm_plane_state

Create a subclass of drm_plane_state to store hardware-specific state
information (e.g. hardware plane format settings) in the future.

Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260331060126.1291966-3-zhengxingda@iscas.ac.cn
6 weeks agodrm: verisilicon: make vs_format conversion function return int
Icenowy Zheng [Tue, 31 Mar 2026 06:01:23 +0000 (14:01 +0800)] 
drm: verisilicon: make vs_format conversion function return int

This is for further proper invalid drm_format handling before committing
the plane state change.

The return value is not yet checked yet, and will be checked in
atomic_check in the future.

Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260331060126.1291966-2-zhengxingda@iscas.ac.cn
6 weeks agoALSA: jack: use scnprintf to improve parse_mask_bits
Thorsten Blum [Sun, 3 May 2026 10:11:02 +0000 (12:11 +0200)] 
ALSA: jack: use scnprintf to improve parse_mask_bits

Use the return value of scnprintf() to keep track of the current string
length and also replace strlcat() with scnprintf(). Return the string
length directly instead of calling strlen(buf).

Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Link: https://patch.msgid.link/20260503101102.298782-2-thorsten.blum@linux.dev
Signed-off-by: Takashi Iwai <tiwai@suse.de>
6 weeks agoALSA: pcmtest: Return -EFAULT on pattern read copy failure
Cássio Gabriel [Fri, 1 May 2026 17:45:14 +0000 (14:45 -0300)] 
ALSA: pcmtest: Return -EFAULT on pattern read copy failure

pattern_write() reports -EFAULT when copy_from_user() fails, but
pattern_read() converts copy_to_user() failures into a zero-length read.
That makes a userspace buffer fault look like EOF instead of reporting the
actual error.

Return -EFAULT from pattern_read() when copying the pattern data to
userspace fails, and update the file offset only after a successful copy.

Fixes: 315a3d57c64c ("ALSA: Implement the new Virtual PCM Test Driver")
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Link: https://patch.msgid.link/20260501-alsa-pcmtest-pattern-read-efault-v1-1-53e1e8c11dda@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
6 weeks agoALSA: seq: oss/rw: allocate evrec with main struct
Rosen Penev [Thu, 30 Apr 2026 21:04:13 +0000 (14:04 -0700)] 
ALSA: seq: oss/rw: allocate evrec with main struct

Use a flexible array member to simplify allocation slightly.

Add the header as flexible array members require full definitions.

Remove null check and just kfree. The former is not needed.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260430210413.31185-1-rosenp@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
6 weeks agoi2c: stub: Reject I2C block transfers with invalid length
Weiming Shi [Tue, 14 Apr 2026 17:23:39 +0000 (01:23 +0800)] 
i2c: stub: Reject I2C block transfers with invalid length

The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0]
as the transfer length. The existing check only clamps it to avoid
overrunning the chip->words[256] register array, but does not validate
it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union
i2c_smbus_data.block buffer (34 bytes total). The driver is a
development/test tool (CONFIG_I2C_STUB=m, not built by default)
that must be loaded with a chip_addr= parameter.

A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl
with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing
stub_xfer() to read or write past the end of the union
i2c_smbus_data.block buffer:

 BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223)
 Read of size 1 at addr ffff88800abcfd92 by task exploit/81
 Call Trace:
  <TASK>
  stub_xfer (drivers/i2c/i2c-stub.c:223)
  __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593)
  i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536)
  i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391)
  i2cdev_ioctl (drivers/i2c/i2c-dev.c:478)
  __x64_sys_ioctl (fs/ioctl.c:583)
  do_syscall_64 (arch/x86/entry/syscall_64.c:94)
  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
  </TASK>

The bug exists because i2c-stub implements .smbus_xfer directly,
bypassing the I2C_SMBUS_BLOCK_MAX validation in
i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same
function correctly validates against I2C_SMBUS_BLOCK_MAX, but the
I2C_SMBUS_I2C_BLOCK_DATA case does not.

Fix by rejecting transfers with data->block[0] == 0 or
data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with
both the I2C_SMBUS_BLOCK_DATA case in the same function and the
I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().

Fixes: 4710317891e4 ("i2c-stub: Implement I2C block support")
Reported-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
6 weeks agoALSA: Consistently define pci_device_ids using named initializers
Uwe Kleine-König (The Capable Hub) [Thu, 30 Apr 2026 13:52:53 +0000 (15:52 +0200)] 
ALSA: Consistently define pci_device_ids using named initializers

... and PCI device helpers.

The various struct pci_device_id arrays were initialized mostly by list
expressions, some of them using the PCI_DEVICE macros. This isn't easily
readable if you're not into PCI. Using named initializers is more
explicit and thus easier to parse. Also use PCI_DEVICE* helper macros to
assign .vendor, .device, .subvendor and .subdevice where appropriate and
skip explicit assignments of 0 (which the compiler takes care of).

The secret plan is to make struct pci_device_id::driver_data an
anonymous union (similar to
https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/)
and that requires named initializers. But it's also a nice cleanup on
its own.

This change doesn't introduce changes to the compiled pci_device_id
array. Tested on x86 and arm64.

Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Link: https://patch.msgid.link/20260430135255.279393-2-u.kleine-koenig@baylibre.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
6 weeks agox86/efi: Fix graceful fault handling after FPU softirq changes
Ivan Hu [Thu, 30 Apr 2026 07:41:07 +0000 (15:41 +0800)] 
x86/efi: Fix graceful fault handling after FPU softirq changes

Since commit d02198550423 ("x86/fpu: Improve crypto performance by
making kernel-mode FPU reliably usable in softirqs"), kernel_fpu_begin()
calls fpregs_lock() which uses local_bh_disable() instead of the
previous preempt_disable(). This sets SOFTIRQ_OFFSET in preempt_count
during the entire EFI runtime service call, causing in_interrupt() to
return true in normal task context.

The graceful page fault handler efi_crash_gracefully_on_page_fault()
uses in_interrupt() to bail out for faults in real interrupt context.
With SOFTIRQ_OFFSET now set, the handler always bails out, leaving EFI
firmware page faults unhandled. This escalates to die() which also sees
in_interrupt() as true and calls panic("Fatal exception in interrupt"),
resulting in a hard system freeze. On systems with buggy firmware that
triggers page faults during EFI runtime calls (e.g., accessing unmapped
memory in GetTime()), this causes an unrecoverable hang instead of the
expected graceful EFI_ABORTED recovery.

Fix by replacing in_interrupt() with !in_task(). This preserves the
original intent of bailing for interrupts or NMI faults, while no longer
falsely triggering from the FPU code path's local_bh_disable().

Fixes: d02198550423 ("x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs")
Cc: <stable@vger.kernel.org>
Signed-off-by: Ivan Hu <ivan.hu@canonical.com>
[ardb: Sashiko spotted that using 'in_hardirq() || in_nmi()' leaves a
       window where a softirq may be taken before fpregs_lock() is
       called, but after efi_rts_work.efi_rts_id has been assigned,
       and any page faults occurring in that window will then be
       misidentified as having been caused by the firmware. Instead,
       use !in_task(), which incorporates in_serving_softirq(). ]
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
6 weeks agodrm/bridge: lontium-lt8912b: Do not generate HFP
Max Krummenacher [Mon, 28 Jul 2025 15:00:50 +0000 (17:00 +0200)] 
drm/bridge: lontium-lt8912b: Do not generate HFP

The datasheet of lontium-lt8912b doesn't require blanking during
the HFP period. Thus use LP during HFP.

Tested with a samsung-dsim (i.MX8 MM) and a tc358768 DPI to DSI bridge
as the DSI host.

Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20250728150059.2642055-1-max.oss.09@gmail.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
6 weeks agodrm/bridge: ti-sn65dsi83: add test pattern generation support
Luca Ceresoli [Thu, 16 Apr 2026 13:59:55 +0000 (15:59 +0200)] 
drm/bridge: ti-sn65dsi83: add test pattern generation support

Generation of a test pattern output is a useful tool for panel bringup and
debugging, and very simple to support with this chip.

The value of REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW needs to be divided by two
for the test pattern to work in dual LVDS mode. While not clearly stated in
the datasheet, this is needed according to the DSI Tuner [0] output. And
some dual-LVDS panels refuse to show any picture without this division by
two.

[0] https://www.ti.com/tool/DSI-TUNER

Reviewed-by: Louis Chauvet <louis.chauvet@boootlin.com>
Link: https://patch.msgid.link/20260416-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v3-1-143886aebc6b@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
6 weeks agoi2c: Compare the return value of gpiod_get_direction against GPIO_LINE_DIRECTION_OUT
Nikola Z. Ivanov [Wed, 15 Apr 2026 20:50:21 +0000 (23:50 +0300)] 
i2c: Compare the return value of gpiod_get_direction against GPIO_LINE_DIRECTION_OUT

The GPIO_LINE_DIRECTION_* definitions have just recently been exposed to
gpio consumers.h by breaking them out in a separate defs.h file.

Use this to validate the gpio direction instead of the hard-coded literal.

Signed-off-by: Nikola Z. Ivanov <zlatistiv@gmail.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
6 weeks agomedia: dt-bindings: media: renesas,vsp1: Document RZ/G3E
Tommaso Merciai [Wed, 8 Apr 2026 10:37:01 +0000 (12:37 +0200)] 
media: dt-bindings: media: renesas,vsp1: Document RZ/G3E

The VSPD block on the RZ/G3E SoC is identical to the one found on the
RZ/G2L SoC.

No driver changes are required, as `renesas,r9a07g044-vsp2` will be used
as a fallback compatible string on the RZ/G3E SoC.

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Link: https://patch.msgid.link/c1e2eb36af01e0cddd8050ba70847c3a0821c91e.1775636898.git.tommaso.merciai.xr@bp.renesas.com
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
6 weeks agomedia: dt-bindings: media: renesas,fcp: Document RZ/G3E SoC
Tommaso Merciai [Wed, 8 Apr 2026 10:37:02 +0000 (12:37 +0200)] 
media: dt-bindings: media: renesas,fcp: Document RZ/G3E SoC

The FCPVD block on the RZ/G3E SoC is identical to the one found on the
RZ/G2L SoC.

No driver changes are required, as `renesas,fcpv` will be used as a
fallback compatible string on the RZ/G3E SoC.

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Link: https://patch.msgid.link/5aaf561a66c24639477a99d3861ca969a81673f0.1775636898.git.tommaso.merciai.xr@bp.renesas.com
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
6 weeks agomedia: dt-bindings: media: renesas,vsp1: Document RZ/G3L VSPD
Biju Das [Mon, 30 Mar 2026 10:56:29 +0000 (11:56 +0100)] 
media: dt-bindings: media: renesas,vsp1: Document RZ/G3L VSPD

The VSPD block on the RZ/G3L SoC is identical to the one found on the
RZ/G2L SoC. Document RZ/G3L VSPD.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Link: https://patch.msgid.link/20260330105637.130189-1-biju.das.jz@bp.renesas.com
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
6 weeks agomedia: dt-bindings: media: renesas,fcp: Document RZ/G3L FCPVD IP
Biju Das [Mon, 30 Mar 2026 11:00:10 +0000 (12:00 +0100)] 
media: dt-bindings: media: renesas,fcp: Document RZ/G3L FCPVD IP

The FCPVD block on the RZ/G3L SoC is identical to the one found on the
RZ/G2L SoC. Document RZ/G3L FCPVD IP.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Link: https://patch.msgid.link/20260330110012.131273-1-biju.das.jz@bp.renesas.com
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
6 weeks agodrm/ipv3: add CONFIG_OF dependency for DRM_OF_DISPLAY_MODE_BRIDGE
Arnd Bergmann [Wed, 29 Apr 2026 14:00:11 +0000 (16:00 +0200)] 
drm/ipv3: add CONFIG_OF dependency for DRM_OF_DISPLAY_MODE_BRIDGE

Without this, not all dependencies are met here.

  Depends on [n]: HAS_IOMEM [=y] && DRM [=y] && DRM_BRIDGE [=y] && OF [=n]
  Selected by [y]:
  - DRM_IMX_PARALLEL_DISPLAY [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_IMX [=y]
  - DRM_IMX_LDB [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_IMX [=y] && COMMON_CLK [=y]

Fixes: ba2db93cf3d5 ("drm/bridge: Move legacy bridge driver out of imx directory for multi-platform use")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Damon Ding <damon.ding@rock-chips.com>
Link: https://patch.msgid.link/20260429140024.192432-1-arnd@kernel.org
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
6 weeks agosoc: renesas: Add R-Car X5H PRR support
Wolfram Sang [Thu, 2 Apr 2026 11:27:07 +0000 (13:27 +0200)] 
soc: renesas: Add R-Car X5H PRR support

On R-Car X5H, PRR is inside the MFIS memory block, so we need to access
it similar to e.g. RZ/G2L.

Suggested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260402112709.13002-4-wsa+renesas@sang-engineering.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
6 weeks agosoc: renesas: Add Renesas R-Car MFIS driver
Wolfram Sang [Thu, 2 Apr 2026 11:27:06 +0000 (13:27 +0200)] 
soc: renesas: Add Renesas R-Car MFIS driver

Renesas R-Car MFIS offers multiple features but most importantly
mailboxes and hwspinlocks. Because they share a common register space
and a common register unprotection mechanism, a single driver was chosen
to handle all dependencies. (MFD and auxiliary bus have been tried as
well, but they failed because of circular dependencies.)

In this first step, the driver implements common register access and a
mailbox controller. hwspinlock support will be added incrementally, once
the subsystem allows out-of-directory drivers.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260402112709.13002-3-wsa+renesas@sang-engineering.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
6 weeks agoparisc: Fix IRQ leak in LASI driver
Hongling Zeng [Sun, 3 May 2026 04:17:44 +0000 (12:17 +0800)] 
parisc: Fix IRQ leak in LASI driver

When request_irq() succeeds but gsc_common_setup() fails later,
the IRQ is never released. Fix this by adding proper error handling
with goto labels to ensure resources are released in LIFO order.

Detected by Smatch:
  drivers/parisc/lasi.c:216 lasi_init_chip() warn: 'lasi->gsc_irq.irq'
from request_irq() not released on lines: 207.

Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <error27@gmail.com>
Closes: https://lore.kernel.org/r/202604180957.4QdAIxP6-lkp@intel.com/
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Cc: stable@vger.kernel.org
Signed-off-by: Helge Deller <deller@gmx.de>
6 weeks agoMerge tag 'renesas-r8a78000-dt-binding-defs-tag1' into renesas-drivers-for-v7.2
Geert Uytterhoeven [Mon, 4 May 2026 09:47:41 +0000 (11:47 +0200)] 
Merge tag 'renesas-r8a78000-dt-binding-defs-tag1' into renesas-drivers-for-v7.2

Renesas R-Car X5H MFIS DT Binding Definitions

DT bindings and binding definitions for the Renesas R-Car X5H (R8A78000)
Multifunctional Interface (MFIS), shared by driver and DT source files.

6 weeks agodt-bindings: soc: renesas: Document MFIS IP core
Wolfram Sang [Thu, 2 Apr 2026 11:27:05 +0000 (13:27 +0200)] 
dt-bindings: soc: renesas: Document MFIS IP core

Document the Renesas Multifunctional Interface (MFIS) as found on the
Renesas R-Car X5H (r8a78000) SoC. MFIS includes features like Mailbox/HW
Spinlock/Product Register/Error Injection/Error Detection and the likes.
Family-compatible values are not introduced here because MFIS is usually
very different per SoC.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260402112709.13002-2-wsa+renesas@sang-engineering.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
6 weeks agostaging: rtl8723bs: os_dep: avoid NULL pointer dereference in rtw_cbuf_alloc
Shyam Sunder Reddy Padira [Tue, 14 Apr 2026 07:13:06 +0000 (12:43 +0530)] 
staging: rtl8723bs: os_dep: avoid NULL pointer dereference in rtw_cbuf_alloc

The return value of kzalloc_flex() is used without
ensuring that the allocation succeeded, and the
pointer is dereferenced unconditionally.

Guard the access to the allocated structure to
avoid a potential NULL pointer dereference if the
allocation fails.

Fixes: 980cd426a257 ("staging: rtl8723bs: replace rtw_zmalloc() with kzalloc()")
Cc: stable <stable@kernel.org>
Signed-off-by: Shyam Sunder Reddy Padira <shyamsunderreddypadira@gmail.com>
Reviewed-by: Dan Carpenter <error27@gmail.com>
Link: https://patch.msgid.link/20260414071308.4781-2-shyamsunderreddypadira@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 weeks agoi2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl
Mingyu Wang [Mon, 27 Apr 2026 02:57:45 +0000 (10:57 +0800)] 
i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl

While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong
timeout value` warning was observed, accompanied by SMBus controller
state machine corruption.

The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of
10 ms. The user argument is checked against INT_MAX, but it is
subsequently multiplied by 10 before being passed to msecs_to_jiffies().

A malicious user can pass a large value (e.g., 429496729) that passes
the `arg > INT_MAX` check but overflows when multiplied by 10. This
results in a truncated 32-bit unsigned value that bypasses the
internal `(int)m < 0` check in `msecs_to_jiffies()`.

The truncated value is then assigned to `client->adapter->timeout`
(a signed 32-bit int), which is reinterpreted as a negative number.
When passed to wait_for_completion_timeout(), this negative value
undergoes sign extension to a 64-bit unsigned long, triggering the
`schedule_timeout` warning and causing premature returns. This leaves
the SMBus state machine in an unrecoverable state, constituting a
local Denial of Service (DoS).

Fix this by bounding the user argument to `INT_MAX / 10`.

Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
[wsa: move the comment as well]
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
6 weeks agostaging: vme_user: fix root device leak on init failure
Johan Hovold [Fri, 24 Apr 2026 10:49:10 +0000 (12:49 +0200)] 
staging: vme_user: fix root device leak on init failure

Make sure to deregister and free the root device in case module
initialisation fails.

Fixes: 658bcdae9c67 ("vme: Adding Fake VME driver")
Cc: stable@vger.kernel.org # 4.9
Cc: Martyn Welch <martyn@welchs.me.uk>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260424104910.2619349-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 weeks agodrm/i915/display: move display funcs under modeset sub-struct
Jani Nikula [Thu, 30 Apr 2026 08:28:52 +0000 (11:28 +0300)] 
drm/i915/display: move display funcs under modeset sub-struct

Move generic crtc-ish modeset related functions under a new modeset
sub-struct of struct intel_display. Rename struct intel_display_funcs to
intel_modeset_funcs to make it a little bit more specific. Remove the
funcs sub-struct.

The funcs sub-struct of struct intel_display seems unnecessary. Instead
of display->funcs.FEATURE, prefer display->FEATURE.funcs.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patch.msgid.link/7849de3a5c9755639c179917c6a298de9ac832c0.1777537663.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
6 weeks agodrm/i915/display: move cdclk funcs under cdclk sub-struct
Jani Nikula [Thu, 30 Apr 2026 08:28:51 +0000 (11:28 +0300)] 
drm/i915/display: move cdclk funcs under cdclk sub-struct

Move cdclk related functions under cdclk sub-struct of struct
intel_display.

The funcs sub-struct of struct intel_display seems unnecessary. Instead
of display->funcs.FEATURE, prefer display->FEATURE.funcs.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patch.msgid.link/a3cadca7cfd03486404af497fa62efb8e2d2adcd.1777537663.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
6 weeks agodrm/i915/display: move dpll funcs under dpll sub-struct
Jani Nikula [Thu, 30 Apr 2026 08:28:50 +0000 (11:28 +0300)] 
drm/i915/display: move dpll funcs under dpll sub-struct

Move dpll related functions under dpll sub-struct of struct
intel_display.

The funcs sub-struct of struct intel_display seems unnecessary. Instead
of display->funcs.FEATURE, prefer display->FEATURE.funcs.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patch.msgid.link/02efd924d7efdf42655f5c9bfd0f79a6df5fe2b4.1777537663.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
6 weeks agodrm/i915/display: move hotplug irq funcs under hotplug sub-struct
Jani Nikula [Thu, 30 Apr 2026 08:28:49 +0000 (11:28 +0300)] 
drm/i915/display: move hotplug irq funcs under hotplug sub-struct

Move hotplug irq related functions under hotplug sub-struct of struct
intel_display.

The funcs sub-struct of struct intel_display seems unnecessary. Instead
of display->funcs.FEATURE, prefer display->FEATURE.funcs.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patch.msgid.link/9419cff5038d60a6c95c247b83f54b6559067e0d.1777537663.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
6 weeks agodrm/i915/display: move watermark funcs under wm sub-struct
Jani Nikula [Thu, 30 Apr 2026 08:28:48 +0000 (11:28 +0300)] 
drm/i915/display: move watermark funcs under wm sub-struct

Move watermark related functions under wm sub-struct of struct
intel_display.

The funcs sub-struct of struct intel_display seems unnecessary. Instead
of display->funcs.FEATURE, prefer display->FEATURE.funcs.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patch.msgid.link/6b74ab66692dce20b2a6a8cb8cfdef222b2983ca.1777537663.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
6 weeks agodrm/i915/display: move fdi funcs under fdi sub-struct
Jani Nikula [Thu, 30 Apr 2026 08:28:47 +0000 (11:28 +0300)] 
drm/i915/display: move fdi funcs under fdi sub-struct

Move fdi related functions under fdi sub-struct of struct intel_display.

The funcs sub-struct of struct intel_display seems unnecessary. Instead
of display->funcs.FEATURE, prefer display->FEATURE.funcs.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patch.msgid.link/c48bad63ec94259773d05ef056268b02e119d635.1777537663.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
6 weeks agodrm/i915/display: move color funcs under color sub-struct
Jani Nikula [Thu, 30 Apr 2026 08:28:46 +0000 (11:28 +0300)] 
drm/i915/display: move color funcs under color sub-struct

Move color related functions under color sub-struct of struct
intel_display.

The funcs sub-struct of struct intel_display seems unnecessary. Instead
of display->funcs.FEATURE, prefer display->FEATURE.funcs.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patch.msgid.link/77cc5dd365f3346c4cbbe7a5d883bca413138c94.1777537663.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
6 weeks agodrm/i915/display: move audio funcs under audio sub-struct
Jani Nikula [Thu, 30 Apr 2026 08:28:45 +0000 (11:28 +0300)] 
drm/i915/display: move audio funcs under audio sub-struct

Move audio related functions under audio sub-struct of struct
intel_display.

The funcs sub-struct of struct intel_display seems unnecessary. Instead
of display->funcs.FEATURE, prefer display->FEATURE.funcs.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patch.msgid.link/60d626286b77c2faa9ff0518855dd083906b24be.1777537663.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
6 weeks agox86/entry: Zap the #VC entry user and kernel macros
Borislav Petkov (AMD) [Mon, 20 Apr 2026 16:43:52 +0000 (18:43 +0200)] 
x86/entry: Zap the #VC entry user and kernel macros

Drop the separate kernel and user macros in favor of calling a single #VC
C handler which multiplexes between the kernel and user #VC entry points
by looking at CS's RPL.

Zap unused DEFINE_IDTENTRY_VC while at it.

There should be no functionality change resulting from this - just code
simplification.

Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Nikunj A. Dadhania <nikunj@amd.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Joerg Roedel <joerg.roedel@amd.com>
Tested-by: Nikunj A. Dadhania <nikunj@amd.com>
Link: https://patch.msgid.link/20260420164352.32129-1-bp@kernel.org
6 weeks agoi2c: acpi: Add ELAN0678 to i2c_acpi_force_100khz_device_ids
Niels Franke [Sat, 18 Apr 2026 05:37:19 +0000 (07:37 +0200)] 
i2c: acpi: Add ELAN0678 to i2c_acpi_force_100khz_device_ids

The ELAN0678 touchpad (04F3:3195) found in the Lenovo ThinkPad X13
exhibits excessive smoothing when the I2C bus runs at 400KHz, making
the touchpad feel sluggish when plugged into AC power. This is the
same issue previously fixed for ELAN06FA.

The device's ACPI table (Lenovo TP-R22) specifies 0x00061A80 (400KHz)
for the I2cSerialBusV2 descriptor. Forcing the bus to 100KHz eliminates
the sluggish behavior.

Signed-off-by: Niels Franke <nielsfranke@gmail.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
[wsa: kept the sorting]
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
6 weeks agofbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free
Rajat Gupta [Mon, 4 May 2026 03:51:10 +0000 (20:51 -0700)] 
fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free

dlfb_ops_mmap() uses remap_pfn_range() to map vmalloc framebuffer pages
to userspace but sets no vm_ops on the VMA. This means the kernel cannot
track active mmaps. When dlfb_realloc_framebuffer() replaces the backing
buffer via FBIOPUT_VSCREENINFO, existing mmap PTEs are not invalidated.
On USB disconnect, dlfb_ops_destroy() calls vfree() on the old pages
while userspace PTEs still reference them, resulting in a use-after-free:
the process retains read/write access to freed kernel pages.

Add vm_operations_struct with open/close callbacks that maintain an
atomic mmap_count on struct dlfb_data. In dlfb_realloc_framebuffer(),
check mmap_count and return -EBUSY if the buffer is currently mapped,
preventing buffer replacement while userspace holds stale PTEs.

Tested with PoC using dummy_hcd + raw_gadget USB device emulation.

Signed-off-by: Rajat Gupta <rajgupt@qti.qualcomm.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
Signed-off-by: Helge Deller <deller@gmx.de>
6 weeks agodt-bindings: i2c: apple,i2c: Add t8122 compatible
Janne Grunau [Fri, 20 Mar 2026 12:23:24 +0000 (13:23 +0100)] 
dt-bindings: i2c: apple,i2c: Add t8122 compatible

The i2c block on the Apple silicon t8122 (M3) SoC is compatible with the
existing driver. Add "apple,t8122-i2c" as SoC specific compatible under
"apple,t8103-i2c" used by the deriver.

Signed-off-by: Janne Grunau <j@jannau.net>
Acked-by: Andi Shyti <andi.shyti@kernel.org>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
6 weeks agoiommu/amd: Fix precedence order in set_dte_passthrough()
Weinan Liu [Thu, 30 Apr 2026 23:28:51 +0000 (23:28 +0000)] 
iommu/amd: Fix precedence order in set_dte_passthrough()

Bitwise OR | operator has a higher precedence than the ternary ?:
operatior. It will be incorrectly evaluated as:

new->data[1] |= (FIELD_PREP(...) | dev_data->ats_enabled) ? DTE_FLAG_IOTLB : 0;

Wrap the conditional operation in parentheses to enforce the
correct evaluation order.

Fixes: 93eee2a49c1b ("iommu/amd: Refactor logic to program the host page table in DTE")
Signed-off-by: Weinan Liu <wnliu@google.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
6 weeks agoMerge tag 'drm-xe-next-2026-04-30' of https://gitlab.freedesktop.org/drm/xe/kernel...
Dave Airlie [Mon, 4 May 2026 08:20:49 +0000 (18:20 +1000)] 
Merge tag 'drm-xe-next-2026-04-30' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-next

UAPI Changes:

- Debugfs multi-LRC engine info (Xin Wang, 2 commits)
  Expose multi-LRC engine classes in the debugfs engine info output
  and improve the output readability.

- drm/drm_ras: Add clear-error-counter netlink command to drm_ras

Cross-subsystem Changes:

Core Changes:

- drm/gpusvm: Reject VMAs with VM_IO or VM_PFNMAP when creating SVM ranges
- drm/i915/display: switch to including common step file directly

Driver Changes:

- Engine initialization cleanup (Matt Roper, 10 commits)
  Clean up engine initialization code inherited from i915 by moving
  hardware programming (CCS enablement, HWSTAM, GFX_MODE, BLIT_CCTL,
  STOP_RING) into the RTP infrastructure.  This makes the programming
  visible and verifiable via debugfs, and applies consistently across
  both normal and execlist init paths.  Also fixes the name/definition
  of GFX_MODE, marks BCS engines as belonging to the GT forcewake
  domain, and drops the now-unused xe_hw_engine_mmio_write32() helper.

- PF fair scheduling auto-provisioning (Michal Wajdeczko, 13 commits)
  Fix several corner cases in SR-IOV PF scheduling policy provisioning,
  then auto-provision PF and all VFs with 16ms execution-quantum and
  preemption-timeout defaults.  This prevents a VF from monopolizing
  the GPU by submitting workloads without gaps, without requiring the
  user to configure sysfs manually.

- System Controller support for CRI/Xe3p (Anoop Vijay + Raag Jadav, 10 commits)
  Add xe_sysctrl infrastructure for communicating with the System
  Controller firmware entity on CRI/Xe3p discrete GPU platforms via a
  mailbox interface.  Includes type definitions, register definitions,
  mailbox communication, initialization, power management, interrupt
  handling, and event dispatch.  Builds on this to add initial RAS
  correctable error handling, using sysctrl interrupts to receive
  threshold-crossed events.

- PXP state machine fixes (Daniele Ceraolo Spurio, 4 commits)
  Fix PXP state machine handling: reject PXP sessions on PTL platforms
  with older GSC firmware that does not support it, fix the restart
  flag not being cleared after jumping back in pxp_start, remove
  incorrect handling of an impossible state during suspend, and clean
  up termination status on failure.

- Reset/wedge/unload corner case fixes (Zhanjun Dong + Matthew Brost, 5 commits)
  Fix memory leaks and fence signal failures that occurred during GPU
  reset, device wedging, and driver unload by forcefully tearing down
  remaining exec queues in GuC submit fini, always killing queues in
  pause/abort, and triggering queue cleanup when not in wedged mode 2.
  Also ensures GuC CT state transitions via STOP before DISABLED.

- Wedge path memory allocation fixes (Matthew Brost, 3 commits)
  Avoid GFP_KERNEL allocations in xe_device_declare_wedged(), which
  runs in the DMA-fence signaling path.  Also drops the
  guc_submit_wedged_fini devm registration from xe_guc_submit_wedge()
  to clean up the wedge shutdown sequence.

- PAT type cleanup and invalid index hardening (Xin Wang, 3 commits)
  Standardize pat_index fields to u16 across the driver, default
  XE_CACHE_NONE_COMPRESSION to XE_PAT_INVALID_IDX (matching
  WB_COMPRESSION), and introduce xe_cache_pat_idx() — a macro helper
  that validates cache_mode bounds and asserts on invalid PAT indices
  before returning the index.

- Reject unsafe PAT indices for CPU cached memory (Jia Yao, 2 commits)
  Reject incoherent (coh_none) PAT indices for CPU cached memory in
  both the madvise ioctl and vm_bind with CPU_ADDR_MIRROR flag, closing
  a security gap where the GPU could bypass CPU caches and observe
  stale or sensitive data.

- OA improvements for CRI device memory (Ashutosh Dixit, 3 commits)
  Move OA buffer access to the xe_map layer to support both system and
  device memory (required for CRI), switch OA buffer mmap to use
  drm_gem_mmap_obj, and implement workaround Wa_14026633728.

- xe_drm.h documentation fixes (Shuicheng Lin, 6 commits)
  Fix multiple documentation issues in the xe_drm.h UAPI header:
  typos, spelling errors, grammar, wrong names and references,
  kernel-doc cross-reference syntax, and broken code examples.

- kernel-doc syntax fixes in xe headers (Shuicheng Lin, 4 commits)
  Fix kernel-doc syntax issues across xe header files: missing '@'
  prefixes on member tags, stale/mismatched member tags, comment
  syntax errors, and type/parameter name mismatches in references.

- Buffer object and DMA-buf resource leak fixes (Shuicheng Lin, 4 commits)
  Fix resource leaks on error paths: DMA-buf attachment leak in
  xe_gem_prime_import(), BO leak in xe_dma_buf_init_obj() on
  allocation failure, and BO leaks in xe_bo_init_locked() on GGTT
  flag validation and unaligned size validation failures.

- Include guard cleanup (Shuicheng Lin, 5 commits)
  Fix and standardize include guards across xe header files: normalize
  double-underscore guards to single, add missing leading/trailing
  underscores, add missing _H suffixes, and add guards to previously
  unprotected headers.

- VF CCS memory pool (Satyanarayana K V P, 2 commits)
  Switch VF CCS read/write operations from the DRM sub-allocator to
  DRM mm, fixing allocation failures in fence-disabled mode where
  the sub-allocator's hole cursor assumption breaks.  Also introduces
  a general BO-backed memory pool with shadow support using drm_mm.

- i915/xe step definition unification (Jani Nikula, 3 commits)
  Complete the migration to the shared intel_step header: switch xe
  from its own xe_step enum to the shared intel_step naming and
  definitions, and update i915 display code to include the common
  step header directly.

- Xe3p GT tuning fixes (3 commits)
  Three Xe3p GT tuning corrections: fix the register offset for
  GAMSTLB_CTRL, stop applying the CCCHKNREG1 tuning from Xe3p onward
  (no longer needed), and mark ROW_CHICKEN5 as a masked register.

- Forcewake cleanup in GT and GuC PC (Raag Jadav, 3 commits)
  Drop a redundant forcewake reference in xe_gt, reorder forcewake
  usage in xe_guc_pc_fini_hw() to avoid a redundant hold, and convert
  xe_guc_pc_stop() to void since it can no longer fail.

- SVM garbage collector fix on close (Matthew Brost, 2 commits)
  Disable the SVM garbage collector work item when an SVM is closed
  to prevent use-after-free when the GC fires after the SVM is freed.

- Admin-only PF mode (Satyanarayana K V P, 2 commits)
  Derive an "admin-only PF" mode flag from xe_device state instead of
  using a local flag, and restrict device query responses when running
  in admin-only PF mode to avoid exposing internal state.

- Enable hwmon energy attributes and accepted power limit for CRI (2 commits)
  Enable energy consumption hwmon attributes for the CRI platform and
  add support for reading the accepted (sustained) power limit via
  hwmon.

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com>
Link: https://patch.msgid.link/afNSeZJHC3X2m3-N@fedora
6 weeks agoi2c: stm32f7: reinit_completion() per transfer not per msg
Marek Vasut [Sat, 2 May 2026 15:31:54 +0000 (17:31 +0200)] 
i2c: stm32f7: reinit_completion() per transfer not per msg

Currently, the driver may repeatedly call reinit_completion() during
transfer which contains multiple messages, while another thread is
waiting for the completion.

This happens during transfer with more than 1 message, invoked via
stm32f7_i2c_xfer_core() -> stm32f7_i2c_xfer_msg(). After invoking the
stm32f7_i2c_xfer_msg() to start transfer, stm32f7_i2c_xfer_core()
calls wait_for_completion_timeout() to wait for completion of the
transfer of all messages. When the first message transfer completes,
the hard IRQ handler triggers, and detects transfer completion, which
leads to stm32f7_i2c_isr_event_thread() IRQ thread being started. The
stm32f7_i2c_isr_event_thread() calls stm32f7_i2c_xfer_msg() in case
there are more messages.

Without this change, the second and later stm32f7_i2c_xfer_msg() would
call reinit_completion() on the completion which is still being waited
for in stm32f7_i2c_xfer_core(). Fix this by moving the reinit_completion()
into stm32f7_i2c_xfer_core(), together with wait_for_completion_timeout().

Since stm32f7_i2c_xfer_core() now waits for completion of the entire
transfer, increase the default timeout. This fixes sporadic transfer
timeouts on STM32MP25xx during kernel boot.

Fixes: aeb068c57214 ("i2c: i2c-stm32f7: add driver")
Signed-off-by: Marek Vasut <marex@nabladev.com>
[wsa: reworded commit subject]
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
6 weeks agodt-bindings: i2c: amlogic: Add compatible for T7 SOC
Ronald Claveau [Fri, 24 Apr 2026 14:17:33 +0000 (16:17 +0200)] 
dt-bindings: i2c: amlogic: Add compatible for T7 SOC

Add the T7 SOC compatible which fallback to AXG compatible.

Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
6 weeks agoi2c: testunit: Replace system_long_wq with system_dfl_long_wq
Marco Crivellari [Thu, 30 Apr 2026 09:08:10 +0000 (11:08 +0200)] 
i2c: testunit: Replace system_long_wq with system_dfl_long_wq

Currently the code enqueue work items using {queue|mod}_delayed_work(),
using system_long_wq. This workqueue should be used when long works are
expected, but it is a per-cpu workqueue.

This is important because queue_delayed_work() queue the work using:

   queue_delayed_work_on(WORK_CPU_UNBOUND, ...);

Note that WORK_CPU_UNBOUND = NR_CPUS.

This would end up calling __queue_delayed_work() that does:

    if (housekeeping_enabled(HK_TYPE_TIMER)) {
    //      [....]
    } else {
            if (likely(cpu == WORK_CPU_UNBOUND))
                    add_timer_global(timer);
            else
                    add_timer_on(timer, cpu);
    }

So when cpu == WORK_CPU_UNBOUND the timer is global and is
not using a specific CPU. Later, when __queue_work() is called:

    if (req_cpu == WORK_CPU_UNBOUND) {
            if (wq->flags & WQ_UNBOUND)
                    cpu = wq_select_unbound_cpu(raw_smp_processor_id());
            else
                    cpu = raw_smp_processor_id();
    }

Because the wq is not unbound, it takes the CPU where the timer
fired and enqueue the work on that CPU.
The consequence of all of this is that the work can run anywhere,
depending on where the timer fired.

Recently, a new unbound workqueue specific for long running work has
been added:

    c116737e972e ("workqueue: Add system_dfl_long_wq for long unbound works")

So change system_long_wq with system_dfl_long_wq so that the work may
benefit from scheduler task placement.

Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
[wsa: remove FIXME as well]
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
6 weeks agogpiolib: move legacy interface into linux/gpio/legacy.h
Arnd Bergmann [Tue, 28 Apr 2026 15:45:07 +0000 (17:45 +0200)] 
gpiolib: move legacy interface into linux/gpio/legacy.h

Split the old contents from gpio.h for clarity. Ideally any driver
that still includes linux/gpio.h can now be ported over to use
either linux/gpio/legacy.h or linux/gpio/consumer.h, with the
original file getting removed once that is complete.

No functional changes intended for now.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20260428154522.2861492-1-arnd@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
6 weeks agogpio: altera: Use generic MMIO GPIO
Linus Walleij [Mon, 27 Apr 2026 08:47:59 +0000 (10:47 +0200)] 
gpio: altera: Use generic MMIO GPIO

If we use the generic GPIO lib for MMIO in the Altera driver
we do not only cut down on the code, we also get get/set_multiple
for free.

Keep the local raw spinlock instead of reusing the bgpio spinlock
because it makes the gpiochip and irqchip nicely orthogonal.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patch.msgid.link/20260427-gpio-mmio-more-v3-3-fe1882351424@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
6 weeks agogpio: altera: User gc helper variable
Linus Walleij [Mon, 27 Apr 2026 08:47:58 +0000 (10:47 +0200)] 
gpio: altera: User gc helper variable

Make the code easier to read by adding a local gpio_chip *gc
variable.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patch.msgid.link/20260427-gpio-mmio-more-v3-2-fe1882351424@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
6 weeks agogpio: devres: Use devres parent if undefined
Linus Walleij [Mon, 27 Apr 2026 08:47:57 +0000 (10:47 +0200)] 
gpio: devres: Use devres parent if undefined

If the user did not pass a parent in the struct gpio_chip
then use the device used for devres as parent.

This is quite intuitive and can help avoiding having to
assign parent explicitly in every driver using devres
to add the gpiochip.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patch.msgid.link/20260427-gpio-mmio-more-v3-1-fe1882351424@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
6 weeks agomedia: v4l2-common: Add YUV24 format info
Nas Chung [Wed, 15 Apr 2026 09:25:21 +0000 (18:25 +0900)] 
media: v4l2-common: Add YUV24 format info

The YUV24 format is missing an entry in the v4l2_format_info().
The YUV24 format is the packed YUV 4:4:4 formats with 8 bits
per component.

Fixes: 0376a51fbe5e ("media: v4l: Add packed YUV444 24bpp pixel format")
Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
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>
6 weeks agomedia: verisilicon: remove hantro_run declaration
Rouven Czerwinski [Fri, 10 Apr 2026 06:15:42 +0000 (08:15 +0200)] 
media: verisilicon: remove hantro_run declaration

The function hantro_run() is declared but never defined nor used, remove
the dangling declaration.

Signed-off-by: Rouven Czerwinski <rouven.czerwinski@linaro.org>
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>
6 weeks agomedia: cedrus: Fix failure to clean up hardware on probe failure
Samuel Holland [Mon, 6 Apr 2026 22:14:40 +0000 (01:14 +0300)] 
media: cedrus: Fix failure to clean up hardware on probe failure

If V4L2 device fails to register, then SRAM still be claimed and as a
result driver will not be able to probe again.

 cedrus 1c0e000.video-codec: Failed to claim SRAM
 cedrus 1c0e000.video-codec: Failed to probe hardware
 cedrus 1c0e000.video-codec: probe with driver cedrus failed with error -16

cedrus_hw_remove undoes everything that was previously done by
cedrus_hw_probe, such as disabling runtime power management and
releasing the claimed SRAM and reserved memory region.

Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver")
Acked-by: Paul Kocialkowski <paulk@sys-base.io>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
6 weeks agomedia: cedrus: Fix missing cleanup in error path
Samuel Holland [Mon, 6 Apr 2026 22:14:02 +0000 (01:14 +0300)] 
media: cedrus: Fix missing cleanup in error path

According to the documentation struct v4l2_fh has to be cleaned up with
v4l2_fh_exit() before being freed. [1]
Currently there is no actual bug here, when v4l2_fh_exit() isn't called.
v4l2_fh_exit() in this case only destroys internal mutex. But it may
change in the future, when v4l2_fh_init/v4l2_fh_exit will be enhanced.

1. https://docs.kernel.org/driver-api/media/v4l2-fh.html

Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver")
Cc: stable@vger.kernel.org
Acked-by: Paul Kocialkowski <paulk@sys-base.io>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
6 weeks agomedia: chips-media: wave5: Fix Reports from Kernel Lock Validator
Brandon Brnich [Thu, 2 Apr 2026 18:45:54 +0000 (13:45 -0500)] 
media: chips-media: wave5: Fix Reports from Kernel Lock Validator

handle_dynamic_resolution change requires that the state_lock be acquired
based on the lockdep_assert_held. However, the
handle_dynamic_resolution_change call in initialize_sequence does not
properly obtain the lock before calling.

Since the v4l2_ctrl_find and s_ctrl can sleep, they should not be called
while a lock is already held. Store off the fbc_buf_count then properly
update control once lock has been freed.

Signed-off-by: Brandon Brnich <b-brnich@ti.com>
Tested-by: Jackson Lee <jackson.lee@chipsnmedia.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
6 weeks agomedia: chips-media: wave5: Release m2m_ctx after Instance Removed from List
Brandon Brnich [Thu, 2 Apr 2026 18:45:53 +0000 (13:45 -0500)] 
media: chips-media: wave5: Release m2m_ctx after Instance Removed from List

Possible use after free if IRQ thread manages to obtain spinlock between
m2m_ctx release and wave5_release function removing stream instance from
list of active instances. The IRQ thread looks for the m2m_ctx which is
freed so null pointer dereference occurs.

Signed-off-by: Brandon Brnich <b-brnich@ti.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Tested-by: Jackson Lee <jackson.lee@chipsnmedia.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
6 weeks agomedia: rkvdec: vdpu383: Drop bitfields for the bitwriter
Detlev Casanova [Thu, 2 Apr 2026 14:06:39 +0000 (10:06 -0400)] 
media: rkvdec: vdpu383: Drop bitfields for the bitwriter

The VDPU383 support for hevc and h264 use structs with bitfields to
represent the SPS and PPS.

Because the fields are mostly unaligned and numerous, it brings compiler
issues, especially with clang.

To prevent that, switch to using the global bitwriter previously
introduced instead.

Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
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>
6 weeks agomedia: rkvdec: common: Drop bitfields for the bitwriter
Detlev Casanova [Thu, 2 Apr 2026 14:06:38 +0000 (10:06 -0400)] 
media: rkvdec: common: Drop bitfields for the bitwriter

Currently, the common code files for hevc and h264 use structs with
bitfields to represent the HW RPS buffer.

Because the bitfields are mostly unaligned and numerous, it brings compiler
issues, especially with clang.

To prevent that, switch to using the global bitwriter previously
introduced instead.

Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
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>
6 weeks agomedia: rkvdec: Use the global bitwriter instead of local one
Detlev Casanova [Thu, 2 Apr 2026 14:06:37 +0000 (10:06 -0400)] 
media: rkvdec: Use the global bitwriter instead of local one

Both rkvdec-h264.c and rkvdec-hevc.c use their own bitwriter
function and macros.

Move to using the global one introduced before.

Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
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>
6 weeks agomedia: rkvdec: Introduce a global bitwriter helper
Detlev Casanova [Thu, 2 Apr 2026 14:06:36 +0000 (10:06 -0400)] 
media: rkvdec: Introduce a global bitwriter helper

The use of structures with bitfields is good when the values are
somewhat aligned.
More mis-alignement means that compilers need to do more gymnastics
to edit the fields values.

Some cases have been reported with CLang on specific architectures
like armhf and hexagon, where the compiler would allocate a bigger
local stack than needed or even completely freeze during compilation.

Some fixes have been provided to ease the issues, but the real fix
here is to use a bitwriter instead of heavily unaligned bitfields.

This is a preparation commit to provide a global bitwriter interface
for the whole driver.

Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
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>
6 weeks agomedia: verisilicon: Export only needed pixels formats
Benjamin Gaignard [Tue, 24 Jun 2025 12:29:38 +0000 (14:29 +0200)] 
media: verisilicon: Export only needed pixels formats

Some pixel formats can only be produced if the decoder outputs
reference pictures directly. In some cases, such as AV1 film-grain,
the use of the post-processor is strictly required. In this case,
only enumerate the post-processor supported formats. The exception is
when V4L2_FMTDESC_FLAG_ENUM_ALL is set, in this case, we enumerate
everything regardless of the state.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Fixes: bcd4f091cf1e ("media: verisilicon: Use V4L2_FMTDESC_FLAG_ENUM_ALL flag")
Cc: stable@vger.kernel.org
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>
6 weeks agowifi: cw1200: Revert "Fix locking in error paths"
Bart Van Assche [Thu, 30 Apr 2026 17:44:15 +0000 (10:44 -0700)] 
wifi: cw1200: Revert "Fix locking in error paths"

Revert commit d98c24617a83 ("wifi: cw1200: Fix locking in error paths")
because it introduces a locking bug instead of fixing a locking bug.
cw1200_wow_resume() unlocks priv->conf_mutex. Hence, adding
mutex_unlock(&priv->conf_mutex) just after cw1200_wow_resume() is wrong.

Reported-by: Ben Hutchings <ben@decadent.org.uk>
Closes: https://lore.kernel.org/all/408661f69f263266b028713e1412ba36d457e63d.camel@decadent.org.uk/
Fixes: d98c24617a83 ("wifi: cw1200: Fix locking in error paths")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/20260430174418.1845431-1-bvanassche@acm.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
6 weeks agodrm/bridge: analogix_dp: Extract error pointer from correct variable
Ethan Tidmore [Wed, 29 Apr 2026 03:08:40 +0000 (22:08 -0500)] 
drm/bridge: analogix_dp: Extract error pointer from correct variable

In devm_drm_panel_bridge_add() error path the pointer error should be
extracted from dp->plat_data->next_bridge but instead it is extracted
from bridge, which is a valid pointer and not part of this error path.

Extract error pointer from correct variable.

Detected by Smatch:
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c:1489 analogix_dp_bind()
warn: passing a valid pointer to 'PTR_ERR'

Fixes: 1b86a69b61df4 ("drm/bridge: analogix_dp: Apply panel_bridge helper")
Signed-off-by: Ethan Tidmore <ethantidmore06@gmail.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Damon Ding <damon.ding@rock-chips.com>
Link: https://patch.msgid.link/20260429030840.704252-1-ethantidmore06@gmail.com
[Luca: add lkp report lines]
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202605032334.MuQfn1mP-lkp@intel.com/
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
6 weeks agowifi: mac80211: tests: mark HT check strict
Johannes Berg [Mon, 4 May 2026 06:54:27 +0000 (08:54 +0200)] 
wifi: mac80211: tests: mark HT check strict

The HT check now only applies in strict mode since APs
were found to be broken. Mark it as such.

Fixes: 711a9c018ad2 ("wifi: mac80211: skip ieee80211_verify_sta_ht_mcs_support check in non-strict mode")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
6 weeks agoMerge tag 'v7.1-rc2' into nolibc/for-next
Thomas Weißschuh [Mon, 4 May 2026 05:14:58 +0000 (07:14 +0200)] 
Merge tag 'v7.1-rc2' into nolibc/for-next

Pick up commit b0aa5e4b087b ("sh: Fix fallout from ZERO_PAGE
consolidation") to fix the sh4 selftests.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
6 weeks agomedia: chips-media: wave5: Add Support for Packed YUV422 Formats
Jackson Lee [Tue, 24 Mar 2026 05:04:00 +0000 (14:04 +0900)] 
media: chips-media: wave5: Add Support for Packed YUV422 Formats

Wave5 encoder is capable of reading in numerous raw pixel formats.
Expose these formats and properly configure encoder if selected.

Signed-off-by: Jackson Lee <jackson.lee@chipsnmedia.com>
Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Tested-by: Brandon Brnich <b-brnich@ti.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
6 weeks agomedia: chips-media: wave5: Support CBP profile
Jackson Lee [Tue, 24 Mar 2026 05:03:59 +0000 (14:03 +0900)] 
media: chips-media: wave5: Support CBP profile

Constrained Baseline Profile (CBP) and Baseline Profile (BP) have been
treated as the same.
Introduce the ability to differentiate between the two.

Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer")
Cc: stable@vger.kernel.org
Signed-off-by: Jackson Lee <jackson.lee@chipsnmedia.com>
Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
Tested-by: Brandon Brnich <b-brnich@ti.com>
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>
6 weeks agomedia: chips-media: wave5: Add support for background detection
Jackson Lee [Tue, 24 Mar 2026 05:03:58 +0000 (14:03 +0900)] 
media: chips-media: wave5: Add support for background detection

Implement V4L2_CID_MPEG_VIDEO_BACKGROUND_DETECTION in the Wave5 encoder
driver. When enabled, the hardware detects background regions in a frame
and uses fewer bits or skip mode to encode them, reducing bitrate for
streams with stationary scenes.

Signed-off-by: Jackson Lee <jackson.lee@chipsnmedia.com>
Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
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>
6 weeks agomedia: v4l2-controls: Add control for background detection
Jackson Lee [Tue, 24 Mar 2026 05:03:57 +0000 (14:03 +0900)] 
media: v4l2-controls: Add control for background detection

Add a generic V4L2 boolean control V4L2_CID_MPEG_VIDEO_BACKGROUND_DETECTION
that allows encoders to detect background regions in a frame and use fewer
bits or skip mode to encode them, potentially reducing bitrate for streams
with stationary scenes.

Signed-off-by: Jackson Lee <jackson.lee@chipsnmedia.com>
Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
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>
6 weeks agomedia: chips-media: wave5: Move src_buf Removal to finish_encode
Brandon Brnich [Fri, 20 Mar 2026 18:05:26 +0000 (13:05 -0500)] 
media: chips-media: wave5: Move src_buf Removal to finish_encode

During encoder processing, there is a case where the IRQ response could
return the buffer back to userspace via v4l2_m2m_buf_done call. In this
time, userspace could queue up this same buffer before start_encode removes
the index from the ready queue. This would then lead to a case where the
buffer in the ready queue could be a self loop due to the
WRITE_ONCE(prev->next, new) call in __list_add.

When __list_del is finally called, the loop is already made so nothing
points back to ready queue list head and pointers are poisoned.

A buffer should not be marked as DONE before the buffer is removed from
m2m ready queue. Move removal entirely to finish_encode.

Fixes: 9707a6254a8a6 ("media: chips-media: wave5: Add the v4l2 layer")
Cc: stable@vger.kernel.org
Signed-off-by: Brandon Brnich <b-brnich@ti.com>
Tested-by: Jackson Lee <jackson.lee@chipsnmedia.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
6 weeks agomedia: mtk-jpeg: cancel workqueue on release for supported platforms only
Louis-Alexis Eyraud [Wed, 1 Apr 2026 09:44:15 +0000 (11:44 +0200)] 
media: mtk-jpeg: cancel workqueue on release for supported platforms only

Since a recent fix the mtk_jpeg_release function cancels any pending
or running work present in the driver workqueue using
cancel_work_sync function.
Currently, only the multicore based variants use this workqueue and they
have the jpeg_worker platform data field initialized with a workqueue
callback function. For the others, this field value remain NULL by
default.
The cancel_work_sync function is unconditionally called in
mtk_jpeg_release function, even for the variants that do not use the
workqueue. This call generates a WARN_ON print in __flush_work because
the workqueue callback function presence check fails in __flush_work
function (used by cancel_work_sync).

So, to avoid these warnings, call cancel_work_sync only if a workqueue
callback is defined in platform data.

Fixes: 34c519feef3e ("media: mtk-jpeg: fix use-after-free in release path due to uncancelled work")
Cc: stable@vger.kernel.org
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
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>
6 weeks agodt-bindings: media: sun4i-a10-video-engine: Add interconnect properties
Chen-Yu Tsai [Thu, 25 Dec 2025 10:36:12 +0000 (18:36 +0800)] 
dt-bindings: media: sun4i-a10-video-engine: Add interconnect properties

The Allwinner video engine sits behind the MBUS that is represented as
an interconnect.

Make sure that the interconnect properties are valid in the binding.

Fixes: d41662e52a03 ("media: dt-bindings: media: allwinner,sun4i-a10-video-engine: Add R40 compatible")
Cc: stable@vger.kernel.org
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
6 weeks agomedia: cedrus: skip invalid H.264 reference list entries
Pengpeng Hou [Tue, 24 Mar 2026 08:08:56 +0000 (16:08 +0800)] 
media: cedrus: skip invalid H.264 reference list entries

Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the
stateless slice control and later uses their indices to look up
decode->dpb[] in _cedrus_write_ref_list().

Rejecting such controls in cedrus_try_ctrl() would break existing
userspace, since stateless H.264 reference lists may legitimately carry
out-of-range indices for missing references. Instead, guard the actual
DPB lookup in Cedrus and skip entries whose indices do not fit the fixed
V4L2_H264_NUM_DPB_ENTRIES array.

This keeps the fix local to the driver use site and avoids out-of-bounds
reads from malformed or unsupported reference list entries.

Fixes: e000e1fa4bdbd ("media: uapi: h264: Update reference lists")
Cc: stable@vger.kernel.org
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Tested-by: Chen-Yu Tsai <wens@kernel.org>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
6 weeks agomedia: v4l2-ctrls: validate HEVC active reference counts
Pengpeng Hou [Tue, 24 Mar 2026 03:13:26 +0000 (11:13 +0800)] 
media: v4l2-ctrls: validate HEVC active reference counts

HEVC slice parameters are shared stateless V4L2 controls, but the common
validation path does not verify the active L0/L1 reference counts before
driver-specific code consumes them.

The original report came from Cedrus, but the active count bounds are
not Cedrus-specific. Validate them in the common HEVC slice control path
so stateless HEVC drivers get the same basic guarantees as soon as the
control is queued.

Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may
use out-of-range sentinel values such as 0xff for missing references, and
some hardware can use that information for concealment. Keep this common
check limited to the active reference counts.

Fixes: d395a78db9eab ("media: hevc: Add decode params control")
Cc: stable@vger.kernel.org
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
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>
6 weeks agoDocumentation: media: Fix v4l2_vp9_segmentation
Fritz Koenig [Tue, 24 Mar 2026 21:00:06 +0000 (14:00 -0700)] 
Documentation: media: Fix v4l2_vp9_segmentation

feature_data is defined as __s16 in the header.

Signed-off-by: Fritz Koenig <frkoenig@chromium.org>
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>
6 weeks agomedia: rc: ttusbir: fix inverted error logic
Oliver Neukum [Fri, 10 Apr 2026 21:03:09 +0000 (23:03 +0200)] 
media: rc: ttusbir: fix inverted error logic

We have to report ENOMEM if no buffer is allocated.
Typo dropped a "!". Restore it.

Fixes: 50acaad3d202 ("media: rc: ttusbir: respect DMA coherency rules")
Cc: stable@vger.kernel.org
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
6 weeks agoio_uring/eventfd: reset deferred signal state
Yufan Chen [Sun, 3 May 2026 17:57:10 +0000 (01:57 +0800)] 
io_uring/eventfd: reset deferred signal state

Recursive eventfd wakeups must defer io_uring eventfd signaling because
eventfd_signal_mask() rejects reentry from eventfd wakeup handlers. The
io_ev_fd ops bit tracks an outstanding deferred signal so that the same
rcu_head is not queued twice.

That bit is only set today. Once the first deferred callback runs, later
recursive notifications still see the bit set and skip queueing another
deferred signal. This can leave new completions without a matching
eventfd wake after the first recursive deferral.

Clear the pending bit before issuing the deferred signal. If the wakeup
path recurses while the callback runs, a new signal can be queued for
the next RCU grace period while the current callback keeps its reference
until it returns.

Signed-off-by: Yufan Chen <ericterminal@gmail.com>
Fixes: 60b6c075e8eb ("io_uring/eventfd: move to more idiomatic RCU free usage")
Link: https://patch.msgid.link/20260503175710.37209-1-yufan.chen@linux.dev
Signed-off-by: Jens Axboe <axboe@kernel.dk>
6 weeks agoio_uring/napi: clear tracked NAPI entries on unregister
Yufan Chen [Sun, 3 May 2026 17:56:10 +0000 (01:56 +0800)] 
io_uring/napi: clear tracked NAPI entries on unregister

IORING_UNREGISTER_NAPI disables NAPI busy polling, but it currently
leaves any previously tracked NAPI IDs on the ring context. The normal
wait path only checks whether the list is empty before entering the busy
poll helper, so an unregistered ring can still observe stale entries and
run an unexpected busy poll pass.

Make unregister switch the context to inactive and free the tracked
entries. Do the same inactive transition while changing the tracking
strategy, and recheck the expected tracking mode under napi_lock before
inserting a newly learned NAPI ID. This prevents a racing poll path from
repopulating the list after unregister or reconfiguration.

Also make the busy poll dispatcher ignore inactive mode explicitly.

Signed-off-by: Yufan Chen <ericterminal@gmail.com>
Fixes: 6bf90bd8c58a ("io_uring/napi: add static napi tracking strategy")
Link: https://patch.msgid.link/20260503175610.35521-1-yufan.chen@linux.dev
Signed-off-by: Jens Axboe <axboe@kernel.dk>
6 weeks agodrm/i915/display: Avoid stale PIPE_SCANLINE values after crtc_enable
Suraj Kandpal [Wed, 29 Apr 2026 04:26:50 +0000 (09:56 +0530)] 
drm/i915/display: Avoid stale PIPE_SCANLINE values after crtc_enable

When a CRTC is moved to a different transcoder (e.g. on DP-MST stream
allocation), PIPE_SCANLINE and PIPE_FRMCNT can return values latched
from the previous transcoder/mode for up to one vblank period after
the new pipe is enabled. The vblank evasion code in
intel_pipe_update_start()/end() then samples a stale or boundary
scanline and the frame counter ticks during the critical section,
producing diagnostic errors of the form:

  [243.348405] xe 0000:00:02.0: [drm] *ERROR* Atomic update failure on
pipe B (start=300 end=301) time 61 us, min 2128, max 2161, scanline
start 1200, end 2165
  [248.536260] xe 0000:00:02.0: [drm] *ERROR* Atomic update failure on
pipe B (start=561 end=562) time 61 us, min 2128, max 2161, scanline
start 2162, end 2167

Here "scanline start 1200" is the vblank_start of a previously
programmed mode on a different transcoder, while "2162" is the current
mode's vblank_start sampled before any real frame has been emitted.
Both indicate a stale read rather than a real evasion miss.

Wait for one vblank after crtc_enable() to give the new transcoder a
chance to start producing live PIPE_SCANLINE/FRMCNT values before any
subsequent atomic commit enters the vblank evasion section. This adds
at most one frame of latency on modeset, which is invisible to users.

Reproduced with igt@kms_rotation_crc@sprite-rotation-180 on a DP-MST
sink; with this patch the failures no longer occur.

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Pranay Samala <pranay.samala@intel.com>
Link: https://patch.msgid.link/20260429042650.3335718-1-suraj.kandpal@intel.com
7 weeks agodrm/ttm: Fix GPU MM stats during pool shrinking
Matthew Brost [Sat, 2 May 2026 06:53:38 +0000 (23:53 -0700)] 
drm/ttm: Fix GPU MM stats during pool shrinking

TTM pool shrinking frees pages by calling __free_pages() directly,
which bypasses updates to NR_GPU_ACTIVE and leaves GPU MM accounting
out of sync.

Introduce a helper, __free_pages_gpu_account(), and use it for all page
frees in ttm_pool.c so GPU MM statistics are updated consistently.

Reported-by: Kenneth Crudup <kenny@panix.com>
Fixes: ae80122f3896 ("drm/ttm: use gpu mm stats to track gpu memory allocations. (v4)")
Cc: Christian Koenig <christian.koenig@amd.com>
Cc: Huang Rui <ray.huang@amd.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: David Airlie <airlied@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Tested-by: Kenneth Crudup <kenny@panix.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260502065338.2720646-1-matthew.brost@intel.com
7 weeks agoDocumentation: drm: Remove drm_atomic_state rename entry
Maxime Ripard [Mon, 27 Apr 2026 07:02:58 +0000 (09:02 +0200)] 
Documentation: drm: Remove drm_atomic_state rename entry

We just did that item so we can remove it.

Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260427-drm-drm-atomic-update-v4-2-c0e713bfdf25@kernel.org
7 weeks agodrm: Rename struct drm_atomic_state to drm_atomic_commit
Maxime Ripard [Mon, 27 Apr 2026 07:02:57 +0000 (09:02 +0200)] 
drm: Rename struct drm_atomic_state to drm_atomic_commit

The KMS framework uses two slightly different definitions for the state
concept. For a given object (plane, CRTC, encoder, etc., so
drm_$OBJECT_state), the state is the entire state of that object.
However, at the device level, drm_atomic_state refers to a state update
for a limited number of objects.

Thus, drm_atomic_state isn't the entire device state, but only the full
state of some objects in that device. This has been an endless source of
confusion and thus bugs.

We can rename the drm_atomic_state structure to drm_atomic_commit to
make it less confusing.

This patch was created using:

rg -l drm_atomic_state | \
xargs sed -i 's/drm_atomic_state/drm_atomic_commit/g; s/drm_atomic_commit_helper/drm_atomic_state_helper/g'
mv drivers/gpu/drm/tests/drm_atomic_state_test.c drivers/gpu/drm/tests/drm_atomic_commit_test.c

Acked-by: Simona Vetter <simona.vetter@ffwll.ch>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260427-drm-drm-atomic-update-v4-1-c0e713bfdf25@kernel.org
7 weeks agosmb: client: use kzalloc to zero-initialize security descriptor buffer
Bjoern Doebel [Thu, 30 Apr 2026 08:57:17 +0000 (08:57 +0000)] 
smb: client: use kzalloc to zero-initialize security descriptor buffer

Commit 62e7dd0a39c2d ("smb: common: change the data type of num_aces
to le16") split struct smb_acl's __le32 num_aces field into __le16
num_aces and __le16 reserved. The reserved field corresponds to Sbz2
in the MS-DTYP ACL wire format, which must be zero [1].

When building an ACL descriptor in build_sec_desc(), we are using a
kmalloc()'ed descriptor buffer and writing the fields explicitly using
le16() writes now. This never writes to the 2 byte reserved field,
leaving it as uninitialized heap data.

When the reserved field happens to contain non-zero slab garbage,
Samba rejects the security descriptor with "ndr_pull_security_descriptor
failed: Range Error", causing chmod to fail with EINVAL.

Change kmalloc() to kzalloc() to ensure the entire buffer is
zero-initialized.

Fixes: 62e7dd0a39c2d ("smb: common: change the data type of num_aces to le16")
Cc: stable@vger.kernel.org
Signed-off-by: Bjoern Doebel <doebel@amazon.de>
Assisted-by: Kiro:claude-opus-4.6
[1] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/20233ed8-a6c6-4097-aafa-dd545ed24428
Signed-off-by: Steve French <stfrench@microsoft.com>
7 weeks agocifs: abort open_cached_dir if we don't request leases
Shyam Prasad N [Tue, 28 Apr 2026 16:07:47 +0000 (21:37 +0530)] 
cifs: abort open_cached_dir if we don't request leases

It is possible that SMB2_open_init may not set lease context based
on the requested oplock level. This can happen when leases have been
temporarily or permanently disabled. When this happens, we will have
open_cached_dir making an open without lease context and the response
will anyway be rejected by open_cached_dir (thereby forcing a close to
discard this open). That's unnecessary two round-trips to the server.

This change adds a check before making the open request to the server
to make sure that SMB2_open_init did add the expected lease context
to the open in open_cached_dir.

Cc: <stable@vger.kernel.org>
Reviewed-by: Bharath SM <bharathsm@microsoft.com>
Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
7 weeks agoLoongArch: KVM: Move unconditional delay into timer clear scenery
Bibo Mao [Mon, 4 May 2026 01:00:48 +0000 (09:00 +0800)] 
LoongArch: KVM: Move unconditional delay into timer clear scenery

When timer interrupt arrives in guest kernel, guest kernel clears the
timer interrupt and program timer with the next incoming event.

During this stage, timer tick is -1 and timer interrupt status is
disabled in ESTAT register. KVM hypervisor need write zero with timer
tick register and wait timer interrupt injection from HW side, and
then clear timer interrupt.

So there is 2 cycle delay in KVM hypervisor to emulate such scenery,
and the delay is unnecessary if there is no need to clear the timer
interrupt.

Here move 2 cycle delay into timer clear scenery and add timer ESTAT
checking after delay, and set max timer expire value if timer interrupt
does not arrive still.

Cc: stable@vger.kernel.org
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
7 weeks agoLoongArch: KVM: Fix HW timer interrupt lost when inject interrupt by software
Bibo Mao [Mon, 4 May 2026 01:00:48 +0000 (09:00 +0800)] 
LoongArch: KVM: Fix HW timer interrupt lost when inject interrupt by software

With passthrough HW timer, timer interrupt is injected by HW. When
inject emulated CPU interrupt by software such SIP0/SIP1/IPI, HW timer
interrupt may be lost.

Here check whether there is timer tick value inversion before and after
injecting emulated CPU interrupt by software, timer enabling by reading
timer cfg register is skipped. If the timer tick value is detected with
changing, then timer should be enabled. And inject a timer interrupt by
software if there is.

Cc: <stable@vger.kernel.org>
Fixes: f45ad5b8aa93 ("LoongArch: KVM: Implement vcpu interrupt operations").
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
7 weeks agoLoongArch: KVM: Move AVEC interrupt injection into switch loop
Bibo Mao [Mon, 4 May 2026 01:00:48 +0000 (09:00 +0800)] 
LoongArch: KVM: Move AVEC interrupt injection into switch loop

When AVEC interrupt controller is emulated in user space, AVEC interrupt
is injected by software like SIP0/SIP1/TI/IPI interrupts. Here also move
the AVEC interrupt injection in switch loop.

Cc: stable@vger.kernel.org
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
7 weeks agoLoongArch: KVM: Use kvm_set_pte() in kvm_flush_pte()
Tao Cui [Mon, 4 May 2026 01:00:38 +0000 (09:00 +0800)] 
LoongArch: KVM: Use kvm_set_pte() in kvm_flush_pte()

kvm_flush_pte() is the only caller that directly assigns *pte instead
of using the kvm_set_pte() wrapper. Use the wrapper for consistency with
the rest of the file.

No functional change intended.

Cc: stable@vger.kernel.org
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
7 weeks agoLoongArch: KVM: Fix missing EMULATE_FAIL in kvm_emu_mmio_read()
Tao Cui [Mon, 4 May 2026 01:00:38 +0000 (09:00 +0800)] 
LoongArch: KVM: Fix missing EMULATE_FAIL in kvm_emu_mmio_read()

In the ldptr (0x24...0x27) opcode decoding path, the default case only
breaks out but without setting "ret" value to EMULATE_FAIL. This leaves
run->mmio.len uninitialized (stale from a previous MMIO operation) while
"ret" value remains EMULATE_DO_MMIO, causing the code to proceed with an
incorrect MMIO length.

Add "ret = EMULATE_FAIL" to match the other default branches in the same
function (e.g. the 0x28...0x2e and 0x38 cases).

Cc: stable@vger.kernel.org
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
7 weeks agoLoongArch: KVM: Cap KVM_CAP_NR_VCPUS by KVM_CAP_MAX_VCPUS
Qiang Ma [Mon, 4 May 2026 01:00:37 +0000 (09:00 +0800)] 
LoongArch: KVM: Cap KVM_CAP_NR_VCPUS by KVM_CAP_MAX_VCPUS

It doesn't make sense to return the recommended maximum number of vCPUs
which exceeds the maximum possible number of vCPUs.

Other architectures have already done this, such as commit 57a2e13ebdda
("KVM: MIPS: Cap KVM_CAP_NR_VCPUS by KVM_CAP_MAX_VCPUS")

Cc: stable@vger.kernel.org
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Qiang Ma <maqianga@uniontech.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
7 weeks agoLoongArch: KVM: Fix "unreliable stack" for kvm_exc_entry
Xianglai Li [Mon, 4 May 2026 01:00:37 +0000 (09:00 +0800)] 
LoongArch: KVM: Fix "unreliable stack" for kvm_exc_entry

Insert the appropriate UNWIND hint into the kvm_exc_entry assembly
function to guide the generation of correct ORC table entries, thereby
solving the timeout problem ("unreliable stack") while loading the
livepatch-sample module on a physical machine running virtual machines
with multiple vcpus.

Cc: stable@vger.kernel.org
Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
7 weeks agoLoongArch: KVM: Compile switch.S directly into the kernel
Xianglai Li [Mon, 4 May 2026 01:00:37 +0000 (09:00 +0800)] 
LoongArch: KVM: Compile switch.S directly into the kernel

If we directly compile the switch.S file into the kernel, the address of
the kvm_exc_entry function will definitely be within the DMW memory area.
Therefore, we will no longer need to perform a copy relocation of the
kvm_exc_entry.

So this patch compiles switch.S directly into the kernel, and then remove
the copy relocation execution logic for the kvm_exc_entry function.

Cc: stable@vger.kernel.org
Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
7 weeks agoLoongArch: vDSO: Drop custom __arch_vdso_hres_capable()
Thomas Weißschuh [Mon, 4 May 2026 01:00:20 +0000 (09:00 +0800)] 
LoongArch: vDSO: Drop custom __arch_vdso_hres_capable()

The custom definition is identical to the generic fallback one.

So remove it.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
7 weeks agoLoongArch: Fix potential ADE in loongson_gpu_fixup_dma_hang()
Wentao Guan [Mon, 4 May 2026 01:00:20 +0000 (09:00 +0800)] 
LoongArch: Fix potential ADE in loongson_gpu_fixup_dma_hang()

The switch case in loongson_gpu_fixup_dma_hang() may not DC2 or DC3, and
readl(crtc_reg) will access with random address, because the "device" is
from "base+PCI_DEVICE_ID", "base" is from "pdev->devfn+1". This is wrong
when my platform inserts a discrete GPU:

lspci -tv
-[0000:00]-+-00.0  Loongson Technology LLC Hyper Transport Bridge Controller
...
           +-06.0  Loongson Technology LLC LG100 GPU
           +-06.2  Loongson Technology LLC Device 7a37
...

Add a default switch case to fix the panic as below:

 Kernel ade access[#1]:
 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.136-loong64-desktop-hwe+ #4
 pc 90000000017e5534 ra 90000000017e54c0 tp 90000001002f8000 sp 90000001002fb6c0
 a0 80000efe00003100 a1 0000000000003100 a2 0000000000000000 a3 0000000000000002
 a4 90000001002fb6b4 a5 900000087cdb58fd a6 90000000027af000 a7 0000000000000001
 t0 00000000000085b9 t1 000000000000ffff t2 0000000000000000 t3 0000000000000000
 t4 fffffffffffffffd t5 00000000fffb6d9c t6 0000000000083b00 t7 00000000000070c0
 t8 900000087cdb4d94 u0 900000087cdb58fd s9 90000001002fb826 s0 90000000031c12c8
 s1 7fffffffffffff00 s2 90000000031c12d0 s3 0000000000002710 s4 0000000000000000
 s5 0000000000000000 s6 9000000100053000 s7 7fffffffffffff00 s8 90000000030d4000
    ra: 90000000017e54c0 loongson_gpu_fixup_dma_hang+0x40/0x210
   ERA: 90000000017e5534 loongson_gpu_fixup_dma_hang+0xb4/0x210
  CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
  PRMD: 00000004 (PPLV0 +PIE -PWE)
  EUEN: 00000000 (-FPE -SXE -ASXE -BTE)
  ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
 ESTAT: 00480000 [ADEM] (IS= ECode=8 EsubCode=1)
  BADV: 7fffffffffffff00
  PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV)
 Modules linked in:
 Process swapper/0 (pid: 1, threadinfo=(____ptrval____), task=(____ptrval____))
 Stack : 0000000000000006 90000001002fb778 90000001002fb704 0000000000000007
         0000000016a65700 90000000017e5690 000000000000ffff ffffffffffffffff
         900000000209f7c0 9000000100053000 900000000209f7a8 9000000000eebc08
         0000000000000000 0000000000000000 0000000000000006 90000001002fb778
         90000001000530b8 90000000027af000 0000000000000000 9000000100054000
         9000000100053000 9000000000ebb70c 9000000100004c00 9000000004000001
         90000001002fb7e4 bae765461f31cb12 0000000000000000 0000000000000000
         0000000000000006 90000000027af000 0000000000000030 90000000027af000
         900000087cd6f800 9000000100053000 0000000000000000 9000000000ebc560
         7a2500147cdaf720 bae765461f31cb12 0000000000000001 0000000000000030
         ...
 Call Trace:
 [<90000000017e5534>] loongson_gpu_fixup_dma_hang+0xb4/0x210
 [<9000000000eebc08>] pci_fixup_device+0x108/0x280
 [<9000000000ebb70c>] pci_setup_device+0x24c/0x690
 [<9000000000ebc560>] pci_scan_single_device+0xe0/0x140
 [<9000000000ebc684>] pci_scan_slot+0xc4/0x280
 [<9000000000ebdd00>] pci_scan_child_bus_extend+0x60/0x3f0
 [<9000000000f5bc94>] acpi_pci_root_create+0x2b4/0x420
 [<90000000017e5e74>] pci_acpi_scan_root+0x2d4/0x440
 [<9000000000f5b02c>] acpi_pci_root_add+0x21c/0x3a0
 [<9000000000f4ee54>] acpi_bus_attach+0x1a4/0x3c0
 [<90000000010e200c>] device_for_each_child+0x6c/0xe0
 [<9000000000f4bbf4>] acpi_dev_for_each_child+0x44/0x70
 [<9000000000f4ef40>] acpi_bus_attach+0x290/0x3c0
 [<90000000010e200c>] device_for_each_child+0x6c/0xe0
 [<9000000000f4bbf4>] acpi_dev_for_each_child+0x44/0x70
 [<9000000000f4ef40>] acpi_bus_attach+0x290/0x3c0
 [<9000000000f5211c>] acpi_bus_scan+0x6c/0x280
 [<900000000189c028>] acpi_scan_init+0x194/0x310
 [<900000000189bc6c>] acpi_init+0xcc/0x140
 [<9000000000220cdc>] do_one_initcall+0x4c/0x310
 [<90000000018618fc>] kernel_init_freeable+0x258/0x2d4
 [<900000000184326c>] kernel_init+0x28/0x13c
 [<9000000000222008>] ret_from_kernel_thread+0xc/0xa4

Cc: stable@vger.kernel.org
Fixes: 95db0c9f526d ("LoongArch: Workaround LS2K/LS7A GPU DMA hang bug")
Link: https://gist.github.com/opsiff/ebf2dac51b4013d22462f2124c55f807
Link: https://gist.github.com/opsiff/a62f2a73db0492b3c49bf223a339b133
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
7 weeks agoLoongArch: Use per-root-bridge PCIH flag to skip mem resource fixup
Huacai Chen [Mon, 4 May 2026 01:00:20 +0000 (09:00 +0800)] 
LoongArch: Use per-root-bridge PCIH flag to skip mem resource fixup

When firmware enables 64-bit PCI host bridge support, some root bridges
already provide valid 64-bit mem resource windows through ACPI.

In this case, the LoongArch-specific mem resource high-bits fixup in
acpi_prepare_root_resources() should not be applied unconditionally.
Otherwise, the kernel may override the native resource layout derived
from firmware, and later BAR assignment can fail to place device BARs
into the intended 64-bit address space correctly.

Add a per-root-bridge ACPI flag, PCIH, and evaluate it from the current
root bridge device scope. When PCIH is set, skip the mem resource high-
bits fixup path and let the kernel use the firmware-provided resource
description directly. When PCIH is absent or cleared, keep the existing
behavior and continue filling the high address bits from the host bridge
address.

This makes the behavior per-root-bridge configurable and avoids breaking
valid 64-bit BAR space allocation on bridges whose 64-bit windows have
already been fully described by firmware.

Cc: stable@vger.kernel.org
Suggested-by: Chao Li <lichao@loongson.cn>
Tested-by: Dongyan Qian <qiandongyan@loongson.cn>
Signed-off-by: Dongyan Qian <qiandongyan@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
7 weeks agoLoongArch: Fix SYM_SIGFUNC_START definition for 32BIT
Huacai Chen [Mon, 4 May 2026 01:00:01 +0000 (09:00 +0800)] 
LoongArch: Fix SYM_SIGFUNC_START definition for 32BIT

The SYM_SIGFUNC_START definition should match sigcontext that the length
of GPRs are 8 bytes for both 32BIT and 64BIT. So replace SZREG with 8 to
fix it.

Cc: stable@vger.kernel.org
Fixes: e4878c37f6679fde ("LoongArch: vDSO: Emit GNU_EH_FRAME correctly")
Suggested-by: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
7 weeks agoLoongArch: Specify -m32/-m64 explicitly for 32BIT/64BIT
Huacai Chen [Mon, 4 May 2026 01:00:01 +0000 (09:00 +0800)] 
LoongArch: Specify -m32/-m64 explicitly for 32BIT/64BIT

Clang/LLVM build needs -m32/-m64 to switch triple variants (i.e. the
--target=xxx parameter). Otherwise we get build errors for CONFIG_32BIT.

GCC doesn't support -m32/-m64 now, but maybe support in future, so use
cc-option to specify them.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202604232041.ESJDwVG4-lkp@intel.com/
Suggested-by: Nathan Chancellor <nathan@kernel.org
Tested-by: WANG Rui <wangrui@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>