]> git.ipfire.org Git - thirdparty/linux.git/log
thirdparty/linux.git
6 days agoBluetooth: Remove unneeded crypto kconfig selections
Eric Biggers [Tue, 21 Apr 2026 23:09:16 +0000 (16:09 -0700)] 
Bluetooth: Remove unneeded crypto kconfig selections

Remove several kconfig selections that are no longer needed:

  - CRYPTO_SKCIPHER and CRYPTO_ECB have been unneeded since
    commit a4770e1117f1 ("Bluetooth: Switch SMP to
    crypto_cipher_encrypt_one()") in 2016.

  - CRYPTO_SHA256 has been unneeded since
    commit e7b02296fb40 ("Bluetooth: Remove BT_HS") in 2024.

Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
6 days agoBluetooth: btusb: Add Realtek RTL8922AE VID/PID 0bda/d923
Chen Zhang [Fri, 24 Apr 2026 12:25:22 +0000 (20:25 +0800)] 
Bluetooth: btusb: Add Realtek RTL8922AE VID/PID 0bda/d923

Add the vendor/product ID (0x0bda, 0xd923) to usb_device_id table for
Realtek RTL8922AE.

The device info from /sys/kernel/debug/usb/devices as below.

T:  Bus=10 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
D:  Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0bda ProdID=d923 Rev= 0.00
S:  Manufacturer=Realtek
S:  Product=Bluetooth Radio
S:  SerialNumber=00E04C885A01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms

Signed-off-by: Chen Zhang <zhangchen01@kylinos.cn>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
6 days agoBluetooth: btusb: Add Realtek RTL8922AE VID/PID 0bda/d922
Chen Zhang [Fri, 24 Apr 2026 12:09:28 +0000 (20:09 +0800)] 
Bluetooth: btusb: Add Realtek RTL8922AE VID/PID 0bda/d922

Add the vendor/product ID (0x0bda, 0xd922) to usb_device_id table for
Realtek RTL8922AE.

The device info from /sys/kernel/debug/usb/devices as below.

T:  Bus=10 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
D:  Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0bda ProdID=d922 Rev= 0.00
S:  Manufacturer=Realtek
S:  Product=Bluetooth Radio
S:  SerialNumber=00E04C885A01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms

Signed-off-by: Chen Zhang <zhangchen01@kylinos.cn>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
6 days agoBluetooth: btusb: Add Mercusys MA530 for Realtek RTL8761BUV
Hrvoje Nuic [Wed, 22 Apr 2026 21:26:47 +0000 (23:26 +0200)] 
Bluetooth: btusb: Add Mercusys MA530 for Realtek RTL8761BUV

Add the USB ID for the Mercusys MA530 Bluetooth adapter. The device uses
a Realtek RTL8761BUV controller and works with the existing Realtek setup
path.

The device reports vendor ID 0x2c4e and product ID 0x0115, and loads the
rtl_bt/rtl8761bu_fw.bin firmware successfully with this quirk.

Signed-off-by: Hrvoje Nuic <hrvoje.nuic@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
6 days agoBluetooth: 6lowpan: fix cyclic locking warning on netdev unregister
Pauli Virtanen [Sat, 11 Apr 2026 18:15:09 +0000 (21:15 +0300)] 
Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister

6lowpan.c has theoretically conflicting lock orderings, which lockdep
complains about:

    a) rtnl_lock > hdev->workqueue

    from 6lowpan.c:delete_netdev -> rtnl_lock -> device_del
    -> put_device(parent) -> hci_release_dev -> destroy_workqueue

    b) hdev->workqueue > l2cap_conn->lock > chan->lock > rtnl_lock

    from hci_rx_work -> 6lowpan.c:chan_ready_cb
    -> lowpan_register_netdev, ifup -> rtnl_lock

Actual deadlock appears not possible, as hci_rx_work is disabled and
l2cap_conn flushed already on hdev unregister. Hence, do minimal thing
to make lockdep happy by breaking chain a) by holding hdev refcount
until after netdev put in 6lowpan.c.

Fixes the lockdep complaint:
WARNING: possible circular locking dependency detected.
kworker/0:1/11 is trying to acquire lock:
ffff8880023b3940 ((wq_completion)hci0#2){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x8b/0x130
but task is already holding lock:
ffffffff95e4f9c0 (rtnl_mutex){+.+.}-{4:4}, at: lowpan_unregister_netdev+0xd/0x30
Workqueue: events delete_netdev

Signed-off-by: Pauli Virtanen <pav@iki.fi>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
6 days agoBluetooth: btmtk: add event filter to filter specific event
Chris Lu [Thu, 16 Apr 2026 11:16:07 +0000 (19:16 +0800)] 
Bluetooth: btmtk: add event filter to filter specific event

Add an event filter to filter event with specific opcode to prevent BT
stack from receiving unexpected event.

Event with opcode 0xfc5d is generated when MediaTek's Bluetooth enable
firmware logs and is not expected to be sent to userspace.

Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
6 days agoBluetooth: btusb: MT7925: Add VID/PID 0e8d/8c38
Chris Lu [Tue, 7 Apr 2026 06:51:10 +0000 (14:51 +0800)] 
Bluetooth: btusb: MT7925: Add VID/PID 0e8d/8c38

Add VID 0e8d & PID 8c38 for MediaTek MT7925 USB Bluetooth chip.

The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.

T:  Bus=06 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0e8d ProdID=8c38 Rev= 1.00
S:  Manufacturer=MediaTek Inc.
S:  Product=Wireless_Device
S:  SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A:  FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
I:  If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=8a(I) Atr=03(Int.) MxPS=  64 Ivl=125us
E:  Ad=0a(O) Atr=03(Int.) MxPS=  64 Ivl=125us
I:* If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E:  Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us

Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
6 days agoBluetooth: btusb: MT7922: Add VID/PID 0e8d/223c
Chris Lu [Tue, 7 Apr 2026 06:50:53 +0000 (14:50 +0800)] 
Bluetooth: btusb: MT7922: Add VID/PID 0e8d/223c

Add VID 0e8d & PID 223c for MediaTek MT7922 USB Bluetooth chip.

The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.

T:  Bus=07 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0e8d ProdID=223c Rev= 1.00
S:  Manufacturer=MediaTek Inc.
S:  Product=Wireless_Device
S:  SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A:  FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
I:  If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=8a(I) Atr=03(Int.) MxPS=  64 Ivl=125us
E:  Ad=0a(O) Atr=03(Int.) MxPS=  64 Ivl=125us
I:* If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E:  Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us

Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
6 days agoBluetooth: btintel_pcie: Support Product level reset
Chandrashekar Devegowda [Mon, 13 Apr 2026 04:20:40 +0000 (09:50 +0530)] 
Bluetooth: btintel_pcie: Support Product level reset

When driver encounters a TOP exception, ACPI methods will be called
for Product level reset since Wifi and BT share the same TOP. BT driver
will first reprobe the wifi driver and then reprobe BT.

Signed-off-by: Chandrashekar Devegowda <chandrashekar.devegowda@intel.com>
Signed-off-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
6 days agonfc: nxp-nci: Add ISO15693 support
Carl Lee [Tue, 12 May 2026 09:55:11 +0000 (17:55 +0800)] 
nfc: nxp-nci: Add ISO15693 support

NXP NCI controllers such as PN7150 support ISO15693 Type 5
tags, but the driver does not currently advertise this protocol.

Add NFC_PROTO_ISO15693_MASK so that ISO15693 tags can be
detected through the Linux NFC stack.

Signed-off-by: Carl Lee <carl.lee@amd.com>
Link: https://patch.msgid.link/20260512-nfc-nxp-nci-add-iso15693-support-v1-1-3394e5b9dba9@amd.com
Signed-off-by: David Heidelberg <david@ixit.cz>
6 days agonfc: nci: uart: Constify struct tty_ldisc_ops
Christophe JAILLET [Sun, 10 May 2026 20:12:52 +0000 (22:12 +0200)] 
nfc: nci: uart: Constify struct tty_ldisc_ops

'struct tty_ldisc_ops' is not modified in this driver.

Constifying this structure moves some data to a read-only section, so
increases overall security, especially when the structure holds some
function pointers.

On a x86_64, with allmodconfig:
Before:
======
   text    data     bss     dec     hex filename
  11454    3352     256   15062    3ad6 net/nfc/nci/uart.o

After:
=====
   text    data     bss     dec     hex filename
  11646    3160     256   15062    3ad6 net/nfc/nci/uart.o

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://patch.msgid.link/c756755a72cdfde2877a18ddee01eaa4f633c220.1778443960.git.christophe.jaillet@wanadoo.fr
Signed-off-by: David Heidelberg <david@ixit.cz>
6 days agonfc: trf7970a: fix comment typos
Miles Krause [Fri, 1 May 2026 00:35:45 +0000 (20:35 -0400)] 
nfc: trf7970a: fix comment typos

Fix a few spelling mistakes in comments.

Signed-off-by: Miles Krause <mileskrause5200@gmail.com>
Link: https://patch.msgid.link/20260501003548.6838-1-mileskrause5200@gmail.com
Signed-off-by: David Heidelberg <david@ixit.cz>
6 days agoMerge tag 's390-7.1-5' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Linus Torvalds [Thu, 11 Jun 2026 17:30:37 +0000 (10:30 -0700)] 
Merge tag 's390-7.1-5' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux

Pull s390 fix from Alexander Gordeev:

 - s390 selects GENERIC_LOCKBREAK when PREEMPT is enabled to tackle an
   old compile error that no longer exists. Since recently PREEMPT is
   always enabled, this LOCKBREAK config causes massive performance
   regressions.

   Remove GENERIC_LOCKBREAK from s390 Kconfig to fix the degradation.

* tag 's390-7.1-5' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390: Remove GENERIC_LOCKBREAK Kconfig option

6 days agoMerge tag 'net-7.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Linus Torvalds [Thu, 11 Jun 2026 17:17:49 +0000 (10:17 -0700)] 
Merge tag 'net-7.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

Pull networking fixes from Paolo Abeni:
 "Including fixes from IPsec and netfilter.

  This is relatively small, mostly because we are a bit behind our PW
  queue. I'm not aware of any pending regression.

  Current release - regressions:

   - netfilter: nf_tables_offload: drop device refcount on error

  Previous releases - regressions:

   - core: add pskb_may_pull() to skb_gro_receive_list()

   - xfrm: iptfs: preserve shared-frag marker in iptfs_consume_frags()

   - ipv6: fix a potential NPD in cleanup_prefix_route()

   - ipv4: fix use-after-free caused by the fqdir_pre_exit() flush

   - eth:
      - bnxt_en: fix NULL pointer dereference
      - emac: fix use-after-free during device removal
      - octeontx2-af: fix memory leak in rvu_setup_hw_resources()
      - tun: zero the whole vnet header in tun_put_user()
      - sit: reload inner IPv6 header after GSO offloads

  Previous releases - always broken:

   - core: fix double-free in netdev_nl_bind_rx_doit()

   - netfilter: nf_log: validate MAC header was set before dumping it

   - xfrm: iptfs: fix ABBA deadlock in iptfs_destroy_state()

   - tcp: restrict SO_ATTACH_FILTER to priv users

   - mctp: usb: fix race between urb completion and rx_retry
     cancellation

   - eth:
      - mlx5: fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list
      - mvpp2: sync RX data at the hardware packet offset"

* tag 'net-7.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (64 commits)
  octeontx2-af: fix IP fragment flag corruption on custom KPU profile load
  ipv6: Fix a potential NPD in cleanup_prefix_route()
  net: txgbe: initialize PHY interface to 0
  net: txgbe: distinguish module types by checking identifier
  net: txgbe: initialize module info buffer
  net: mvpp2: build skb from XDP-adjusted data on XDP_PASS
  net: mvpp2: refill RX buffers before XDP or skb use
  net: mvpp2: limit XDP frame size to the RX buffer
  net: mvpp2: sync RX data at the hardware packet offset
  netfilter: nft_meta_bridge: fix stale stack leak via IIFHWADDR register
  netfilter: nft_fib: fix stale stack leak via the OIFNAME register
  netfilter: nft_exthdr: fix register tracking for F_PRESENT flag
  netfilter: nf_log: validate MAC header was set before dumping it
  netfilter: x_tables: avoid leaking percpu counter pointers
  netfilter: nf_conntrack: destroy stale expectfn expectations on unregister
  netfilter: nf_tables_offload: drop device refcount on error
  netfilter: revalidate bridge ports
  rds: mark snapshot pages dirty in rds_info_getsockopt()
  ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()
  ptp: ocp: fix resource freeing order
  ...

6 days agoMerge tag 'pmdomain-v7.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh...
Linus Torvalds [Thu, 11 Jun 2026 16:54:51 +0000 (09:54 -0700)] 
Merge tag 'pmdomain-v7.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm

Pull pmdomain fixes from Ulf Hansson:

 - imx: Fix OF node refcount

 - ti: Fix wakeup configuration for parent devices of wakeup sources

* tag 'pmdomain-v7.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm:
  pmdomain: imx: fix OF node refcount
  pmdomain: ti_sci: add wakeup constraint to parent devices of wakeup source

6 days agoaccel/amdxdna: Fix mm_struct reference leak in aie2_populate_range()
Lizhi Hou [Wed, 10 Jun 2026 15:11:27 +0000 (08:11 -0700)] 
accel/amdxdna: Fix mm_struct reference leak in aie2_populate_range()

aie2_populate_range() jumps back to the again label without calling
mmput(mm), leaking a reference to the mm_struct.

Add the missing mmput() before jumping to again.

Fixes: e486147c912f ("accel/amdxdna: Add BO import and export")
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260610151127.2994185-1-lizhi.hou@amd.com
6 days agoMerge branch 'thermal-testing'
Rafael J. Wysocki [Thu, 11 Jun 2026 16:21:22 +0000 (18:21 +0200)] 
Merge branch 'thermal-testing'

Merge thermal control testing facility updates for 7.2:

 - Replace sscanf() with kstrtoul() or kstrtoint() in several places in
   the thermal testing code (Ovidiu Panait)

 - Make the thermal testing facility reject missing command arguments to
   avoid NULL pointer dereferences (Samuel Moelius)

* thermal-testing:
  thermal: sysfs: Replace sscanf() with kstrtoul()
  thermal: testing: Replace sscanf() with kstrtoint()
  thermal: testing: reject missing command arguments

6 days agoMerge tag 'gpio-fixes-for-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git...
Linus Torvalds [Thu, 11 Jun 2026 16:15:57 +0000 (09:15 -0700)] 
Merge tag 'gpio-fixes-for-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux

Pull gpio fixes from Bartosz Golaszewski:

 - fix NULL pointer dereference in gpio-mvebu

 - fix runtime PM leak in remove path in gpio-zynq

 - reject invalid module params in gpio-mockup

 - fix generic IRQ chip leak in remove parh in gpio-rockchip

 - fix resource leaks in GPIO chip cleanup path on hog failure

 - fix a regression in how GPIO hogging code handles multiple GPIO chips
   reusing the same OF node

* tag 'gpio-fixes-for-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
  gpiolib: handle gpio-hogs only once
  gpio: fix cleanup path on hog failure
  gpio: rockchip: fix generic IRQ chip leak on remove
  gpio: mockup: reject invalid gpio_mockup_ranges widths
  gpio: zynq: fix runtime PM leak on remove
  gpio: mvebu: fix NULL pointer dereference in suspend/resume

6 days agoMerge back earlier thermal control material for 7.2
Rafael J. Wysocki [Thu, 11 Jun 2026 16:15:26 +0000 (18:15 +0200)] 
Merge back earlier thermal control material for 7.2

6 days agos390/process: Fix kernel thread function pointer type
Heiko Carstens [Mon, 8 Jun 2026 14:19:08 +0000 (16:19 +0200)] 
s390/process: Fix kernel thread function pointer type

In case of a kernel thread __ret_from_fork() calls the specified function
indirectly. Fix the kernel thread function pointer, since kernel threads
return an int instead of void.

Fixes: 56e62a737028 ("s390: convert to generic entry")
Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
6 days agoASoC: SDCA: fix NULL pointer dereference in sdca_dev_unregister_functions
Kean Ren [Thu, 11 Jun 2026 02:37:57 +0000 (10:37 +0800)] 
ASoC: SDCA: fix NULL pointer dereference in sdca_dev_unregister_functions

sdca_dev_unregister_functions() iterates over all SDCA function
descriptors and calls sdca_dev_unregister() on each func_dev without
checking for NULL. When a function registration has failed partway
through, or the device cleanup races with probe deferral, func_dev
entries may be NULL, leading to a kernel oops:

  BUG: kernel NULL pointer dereference, address: 0000000000000040
  RIP: 0010:device_del+0x1e/0x3e0
  Call Trace:
   sdca_dev_unregister_functions+0x37/0x60 [snd_soc_sdca]
   release_nodes+0x35/0xb0
   devres_release_all+0x90/0x100
   device_unbind_cleanup+0xe/0x80
   device_release_driver_internal+0x1c1/0x200
   bus_remove_device+0xc6/0x130
   device_del+0x161/0x3e0
   device_unregister+0x17/0x60
   sdw_delete_slave+0xb6/0xd0 [soundwire_bus]
   sdw_bus_master_delete+0x1e/0x50 [soundwire_bus]
   ...
   sof_probe_work+0x19/0x30 [snd_sof]

This was observed on a Lenovo ThinkPad X1 Carbon G14 (Panther Lake)
with the SOF audio driver probe failing due to missing Panther Lake
firmware, causing the subsequent cleanup of SoundWire devices to
trigger the crash.

Fix this with three changes:

1) Add a NULL guard in sdca_dev_unregister() so that callers do not
   need to pre-validate the pointer (defense in depth).

2) In sdca_dev_unregister_functions(), skip NULL func_dev entries
   and clear func_dev to NULL after unregistration, making the
   function idempotent and safe against double-invocation.

3) In sdca_dev_register_functions(), roll back all previously
   registered functions when a later one fails, so the function
   array is never left in a partially-populated state.

Fixes: 4496d1c65bad ("ASoC: SDCA: add function devices")
Signed-off-by: Kean Ren <rh_king@163.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260611023757.1553960-1-rh_king@163.com
Signed-off-by: Mark Brown <broonie@kernel.org>
6 days agodma-buf: move system_cc_shared heap under separate Kconfig
Arnd Bergmann [Wed, 10 Jun 2026 14:23:29 +0000 (19:53 +0530)] 
dma-buf: move system_cc_shared heap under separate Kconfig

While system heap and system_cc_shared heap share a lot of code
and hence the same source file, their users have different needs.

system heap users need it to be a loadable module, while
system_cc_shared heap users don't.

Building as a loadable module breaks system_cc_shared heap on
powerpc and s390 due to un-exported set_memory_encrypted /
set_memory_decrypted functions.

Fix these by reorganising code to put the system_cc_shared heap
under a new Kconfig symbol, which allows either building both
into the kernel, or leave encryption up to the consumers of the
system heap.

Fixes: fd55edff8a0a ("dma-buf: heaps: system: Turn the heap into a module")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
  [sumits: updated DMABUF_HEAPS_CC_SYSTEM to DMABUF_HEAPS_SYSTEM_CC_SHARED]
Reviewed-by: T.J. Mercier <tjmercier@google.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Link: https://patch.msgid.link/20260610142329.3836808-1-sumit.semwal@linaro.org
6 days agodt-bindings: display/lvds-codec: add ti,sn65lvds93
Hugo Villeneuve [Thu, 5 Mar 2026 18:06:29 +0000 (13:06 -0500)] 
dt-bindings: display/lvds-codec: add ti,sn65lvds93

Add compatible string for TI SN65LVDS93. Similar to
SN65LVDS83 but with an industrial temperature range.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
6 days agoASoC: cs35l56: Fix possible uninitialized value in cs35l56_spi_system_reset()
Richard Fitzgerald [Thu, 11 Jun 2026 13:22:21 +0000 (14:22 +0100)] 
ASoC: cs35l56: Fix possible uninitialized value in cs35l56_spi_system_reset()

In cs35l56_spi_system_reset() initialize val to zero before using it in
the read_poll_timeout(). This prevents testing an uninitialized value if
the regmap_read_bypassed() returns an error.

Read errors are intentionally ignored during this loop because the
device is resetting (though SPI can't really detect that so shouldn't
fail because of that, it's safer to ignore errors and keep polling).
Because of this, val must be initialized to something in case the first
read fails. The polling loop is looking for a non-zero value, so
initializing val to 0 will ensure that the loop continues until a valid
state is read from the device or it times out.

Fixes: 769c1b79295c ("ASoC: cs35l56: Prevent races when soft-resetting using SPI control")
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260611132221.1100497-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
6 days agoASoC: sdw_utils: Add missed component_name strings for TI amps
Baojun Xu [Thu, 11 Jun 2026 12:53:59 +0000 (20:53 +0800)] 
ASoC: sdw_utils: Add missed component_name strings for TI amps

Added component_name for UCM.

Signed-off-by: Baojun Xu <baojun.xu@ti.com>
Link: https://patch.msgid.link/20260611125359.19839-1-baojun.xu@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
6 days agoARM: 9476/1: mm: fix kexec and hibernation with CONFIG_CPU_TTBR0_PAN
Florian Fainelli [Mon, 25 May 2026 16:38:17 +0000 (17:38 +0100)] 
ARM: 9476/1: mm: fix kexec and hibernation with CONFIG_CPU_TTBR0_PAN

Commit 7af5b901e847 ("ARM: 9358/2: Implement PAN for LPAE by TTBR0
page table walks disablement") implemented PAN for LPAE kernels by
setting TTBCR.EPD0 on every kernel entry, disabling TTBR0 page-table
walks while running in kernel mode. The commit correctly updated
cpu_suspend() in arch/arm/kernel/suspend.c, but missed two other code
paths that switch the CPU to the identity mapping before jumping to
low-PA (TTBR0-range) physical addresses:

1. setup_mm_for_reboot() in arch/arm/mm/idmap.c, used by the kexec
   reboot path. With TTBCR.EPD0 still set, the subsequent branch to
   the identity-mapped cpu_v7_reset causes a PrefetchAbort because the
   TTBR0 page-table walk needed to resolve the identity-mapped address
   is disabled. This manifests as a hard hang or "bad PC value" panic
   on LPAE kernels booted on CPUs that strictly enforce EPD0 for
   instruction fetch (e.g. Cortex-A53 in AArch32 mode) while the same
   image may accidentally work on Cortex-A15 due to microarchitectural
   differences in EPD0 enforcement.

2. arch_restore_image() in arch/arm/kernel/hibernate.c, which calls
   cpu_switch_mm(idmap_pgd, &init_mm) directly without going through
   setup_mm_for_reboot(), leaving TTBCR.EPD0 set while the identity
   mapping is active.

Fix both sites by calling uaccess_save_and_enable() before switching
to the identity mapping, mirroring what the original commit did for
cpu_suspend().

Assisted-by: Cursor:claude-sonnet-4.6
Fixes: 7af5b901e847 ("ARM: 9358/2: Implement PAN for LPAE by TTBR0 page table walks disablement")
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
6 days agoARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow
Karl Mehltretter [Sun, 24 May 2026 05:52:35 +0000 (06:52 +0100)] 
ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow

Commit 44e9a3bb76e5 ("ARM: 9430/1: entry: Do a dummy read from
VMAP shadow") added a dummy read from the KASAN VMAP stack shadow in
__switch_to(). The read uses ldr, but the KASAN shadow address is
byte-granular and is not guaranteed to be word aligned.

ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and
CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to()
with an alignment exception before reaching init.

Use ldrb for the dummy shadow access. The code only needs to fault in the
shadow mapping if the stack shadow is missing, so a byte load is sufficient
and matches the granularity of KASAN shadow memory.

Fixes: 44e9a3bb76e5 ("ARM: 9430/1: entry: Do a dummy read from VMAP shadow")
Cc: stable@vger.kernel.org # v6.13+
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
6 days agoARM: 9474/1: io: avoid KASAN instrumentation of raw halfword I/O
Karl Mehltretter [Sun, 24 May 2026 05:52:36 +0000 (06:52 +0100)] 
ARM: 9474/1: io: avoid KASAN instrumentation of raw halfword I/O

For CPUs before ARMv6, __raw_readw() and __raw_writew() are implemented
as C volatile halfword accesses so the compiler can generate an access
sequence that is safe for those machines. With KASAN enabled, those C
accesses are instrumented as normal memory accesses.

That is not valid for MMIO. On ARM926/VersatilePB with KASAN enabled,
PL011 probing traps in __asan_store2() while registering the UART, because
the instrumented writew() tries to check KASAN shadow for an MMIO address.

Keep the existing volatile halfword access, but move the ARMv5 definitions
into __no_kasan_or_inline functions so raw MMIO halfword accesses are not
instrumented by KASAN. The ARMv6-and-newer inline assembly path is
unchanged.

Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM")
Cc: stable@vger.kernel.org # v5.11+
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
6 days agospi: xilinx: let transfers timeout in case of no IRQ
Vadim Fedorenko [Wed, 10 Jun 2026 22:28:43 +0000 (22:28 +0000)] 
spi: xilinx: let transfers timeout in case of no IRQ

In case of failed HW the driver may not see an interrupt and will stuck
in waiting forever. We can avoid such situation by timing out of
transfers if the interrupt is not seen in a reasonable time.

This problem can be found on unload of ptp_ocp driver for TimeCard which
uses Xilinx SPI AXI and SPI-NOR flash memory. During tear-down process
spi-nor drivers send soft reset command which is not triggering an
interrupt stalling the unload process completely.

Signed-off-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Acked-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/20260610222843.782337-1-vadim.fedorenko@linux.dev
Signed-off-by: Mark Brown <broonie@kernel.org>
6 days agoarm64: dts: allwinner: a523: Add missing GPIO interrupt
Andre Przywara [Fri, 27 Mar 2026 11:30:06 +0000 (11:30 +0000)] 
arm64: dts: allwinner: a523: Add missing GPIO interrupt

Even though the Allwinner A523 SoC implements 10 GPIO banks, it has
actually registers for 11 IRQ banks, and even an interrupt assigned to
the first, non-implemented IRQ bank.
Add that first interrupt to the list of GPIO interrupts, to correct the
association between IRQs and GPIO banks.

This fixes GPIO IRQ operation on boards with A523 SoCs, as seen by
broken SD card detect functionality, for instance.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Fixes: 35ac96f79664 ("arm64: dts: allwinner: Add Allwinner A523 .dtsi file")
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20260327113006.3135663-4-andre.przywara@arm.com
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
6 days agonet: sched: avoid printing uninitialized link speed
Jakub Kicinski [Tue, 9 Jun 2026 18:33:53 +0000 (11:33 -0700)] 
net: sched: avoid printing uninitialized link speed

sch_cbs and sch_taprio print ecmd.base.speed, even if
netif_get_link_ksettings() failed. When netif_get_link_ksettings()
fails the ecmd may not be initialized.

Use the always-initialized speed variable instead.
The semantics change slightly because UNKNOWN will
never be printed, but that doesn't seem important
enough to complicate the code for.

This is a _dbg() print, anyway.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260609183353.1109641-1-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agoiommu/apple-dart: correct CONFIG_PCIE_APPLE macro name in comment
Ethan Nelson-Moore [Tue, 9 Jun 2026 19:56:04 +0000 (12:56 -0700)] 
iommu/apple-dart: correct CONFIG_PCIE_APPLE macro name in comment

A comment in drivers/iommu/apple-dart.c incorrectly refers to
CONFIG_PCI_APPLE instead of CONFIG_PCIE_APPLE. Correct it.

Discovered while searching for CONFIG_* symbols referenced in code but
not defined in any Kconfig file.

Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Reviewed-by: Sven Peter <sven@kernel.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
6 days agodrm/xe: fix job timeout recovery for unstarted jobs and kernel queues
Rodrigo Vivi [Wed, 10 Jun 2026 15:25:49 +0000 (11:25 -0400)] 
drm/xe: fix job timeout recovery for unstarted jobs and kernel queues

A job that GuC never scheduled (never started) indicates a GuC
scheduling failure; previously such jobs were silently errored out
instead of triggering a GT reset to recover. Trigger a GT reset and
resubmit them, but only when the queue was not already killed or banned:
an unstarted job on an already banned queue is the ban working as
intended and must neither clear the ban nor kick off a reset, otherwise
a banned userspace queue could be resurrected and spam GT resets.

Kernel queues are always recovered this way and wedge the device once
recovery attempts are exhausted, since kernel work must not silently
fail. A started job that times out on a userspace VM bind queue stays
banned rather than being reset and retried.

The queue is banned early in the timeout handler to signal the G2H
scheduling-done handler so it wakes the disable-scheduling waiter;
without it the waiter sleeps the full 5s timeout. When a reset is
warranted the ban is cleared before rearming so that
guc_exec_queue_start() can resubmit jobs after the GT reset - a
still-banned queue would block resubmission and cause an infinite TDR
loop. The already-banned case is gated out before this point via
skip_timeout_check, so it is unaffected.

v2: (Himal) Do it for any queue type, not just kernel/migration
v3: - (Sashiko and Sanjay): don't clear the ban / GT reset for already
      killed/banned queues on unstarted-job timeout
    - Update commit message
    - (Matt) Add Fixes tag

Fixes: fe05cee4d953 ("drm/xe: Don't short circuit TDR on jobs not started")
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Sanjay Yadav <sanjay.kumar.yadav@intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Assisted-by: GitHub-Copilot:claude-sonnet-4.6
Assisted-by: GitHub-Copilot:claude-opus-4.8
Tested-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com>
Reviewed-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Link: https://patch.msgid.link/20260610152548.404575-3-rodrigo.vivi@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
(cherry picked from commit b1107d085e7e8ed15ba6f80c102528a9c8a6cb0e)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
6 days agodrm/xe: fix refcount leak in xe_range_fence_insert()
Wentao Liang [Wed, 10 Jun 2026 17:27:05 +0000 (10:27 -0700)] 
drm/xe: fix refcount leak in xe_range_fence_insert()

xe_range_fence_insert() acquires a reference on fence via
dma_fence_get() and stores it in rfence->fence.  It then calls
dma_fence_add_callback() and handles two cases: when the callback
is successfully registered (err == 0) the fence is transferred to
the tree for later cleanup; when the fence is already signaled
(err == -ENOENT) it manually drops the extra reference with
dma_fence_put(fence).

However, dma_fence_add_callback() can fail with other errors
(e.g. -EINVAL) and in that case the code falls through to the free:
label without releasing the acquired reference, leaking it.

Fix the leak by adding an else branch that calls dma_fence_put()
before jumping to free: for any error other than -ENOENT.

Fixes: 845f64bdbfc9 ("drm/xe: Introduce a range-fence utility")
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260610172705.3450560-1-matthew.brost@intel.com
(cherry picked from commit 98c4a4201290823c2c5c7ba21692bd9a64b61021)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
6 days agoip6_tunnel: do not use dst6_mtu() in ip4ip6_err() and ip6erspan_tunnel_xmit()
Eric Dumazet [Tue, 9 Jun 2026 09:13:37 +0000 (09:13 +0000)] 
ip6_tunnel: do not use dst6_mtu() in ip4ip6_err() and ip6erspan_tunnel_xmit()

This is a minor performance / conceptual fix.

1) ip6erspan_tunnel_xmit()

  ERSPAN tunnel can mirror both IPv4 and IPv6 traffic, skb
  (the packet being mirrored) can be an IPv4 packet,
  and thus dst can be an IPv4 destination entry

  Use dst_mtu() which contains generic logic for both families.

2) ip4ip6_err()

  skb2 has been prepared as an IPv4 packet, and its destination
  is an IPv4 route.

  dst6_mtu() is optimized for IPv6 destinations and uses INDIRECT_CALL_1
  to call ip6_mtu() directly if the ops match.

  We should use dst4_mtu() instead.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260609091337.2672441-1-edumazet@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agoMerge branches 'acpi-processor', 'acpi-cppc' and 'acpi-pci'
Rafael J. Wysocki [Thu, 11 Jun 2026 13:34:30 +0000 (15:34 +0200)] 
Merge branches 'acpi-processor', 'acpi-cppc' and 'acpi-pci'

Merge an ACPI processor driver update, two ACPI CPPC library updates
and ACPI PCI/CXL support updates for 7.2-rc1:

 - Add cpuidle driver check in acpi_processor_register_idle_driver() to
   avoid evaluating _CST unnecessarily (Tony W Wang-oc)

 - Suppress UBSAN warning caused by field misuse during PCC-based
   register access in the ACPI CPPC library (Jeremy Linton)

 - Add support for CPPC v4 to the ACPI CPPC library (Sumit Gupta)

 - Update the ACPI device enumeration code to honor _DEP for ACPI0016
   PCI/CXL host bridges and make the ACPI PCI root driver clear _DEP
   dependencies for PCI roots that have become operational (Chen Pei)

* acpi-processor:
  ACPI: processor: Add cpuidle driver check in acpi_processor_register_idle_driver()

* acpi-cppc:
  ACPI: CPPC: Suppress UBSAN warning caused by field misuse
  ACPI: CPPC: Add support for CPPC v4

* acpi-pci:
  ACPI: scan: Honor _DEP for ACPI0016 PCI/CXL host bridge
  ACPI: PCI: Clear _DEP dependencies after PCI root bridge attach

6 days agoMerge branch 'acpi-button'
Rafael J. Wysocki [Thu, 11 Jun 2026 13:30:25 +0000 (15:30 +0200)] 
Merge branch 'acpi-button'

Merge ACPI button driver updates for 7.2-rc1:

 - Clean up lid handling in the ACPI button driver and
   acpi_button_probe(), reorganize installing and removing event
   handlers in that driver and switch it over to using devres-based
   resource management during probe (Rafael Wysocki)

* acpi-button:
  ACPI: button: Switch over to devres-based resource management
  ACPI: button: Reorganize installing and removing event handlers
  ACPI: button: Use string literals for generating netlink messages
  ACPI: button: Clean up adding and removing lid procfs interface
  ACPI: button: Merge two switch () statements in acpi_button_probe()
  ACPI: button: Drop redundant variable from acpi_button_probe()
  ACPI: button: Rework device verification during probe
  ACPI: button: Use local pointer to platform device dev field in probe
  ACPI: button: Eliminate redundant conditional statement
  ACPI: button: Change return type of two functions to void
  ACPI: button: Eliminate ternary operator from acpi_lid_evaluate_state()
  ACPI: button: Use bool for representing boolean values
  ACPI: button: Improve warning message regarding lid state
  ACPI: button: Pass ACPI handle to acpi_lid_evaluate_state()
  ACPI: button: Fix lid_device value leak past driver removal

6 days agoMerge branch 'acpi-driver'
Rafael J. Wysocki [Thu, 11 Jun 2026 13:17:57 +0000 (15:17 +0200)] 
Merge branch 'acpi-driver'

Merge updates of core ACPI device drivers for 7.2-rc1:

 - Fix multiple issues related to probe, removal and missing NVDIMM
   device notifications in the ACPI NFIT driver (Rafael Wysocki)

 - Add support for devres-based management of ACPI notify handlers to
   the ACPI core (Rafael Wysocki)

 - Switch multiple core ACPI device drivers (including the ACPI PAD,
   ACPI video bus, ACPI HED, ACPI thermal zone, ACPI AC, ACPI battery,
   and ACPI NFIT drivers) over to using devres-based resource management
   during probe (Rafael Wysocki)

 - Replace mutex_lock/unlock() with guard()/scoped_guard() in the ACPI
   PMIC driver (Maxwell Doose)

 - Fix message kref handling in the dead device path of the ACPI IPMI
   address space handler (Yuho Choi)

 - Use sysfs_emit() in idlecpus_show() in the ACPI processor aggregator
   device (PAD) driver (Yury Norov)

 - Clean up device_id_scheme initialization in the ACPI video bus driver
   (Jean-Ralph Aviles)

* acpi-driver: (26 commits)
  ACPI: IPMI: Fix message kref handling on dead device
  ACPI: NFIT: core: Fix possible deadlock and missing notifications
  ACPI: NFIT: core: Eliminate redundant local variable
  ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup
  ACPI: NFIT: core: Fix possible NULL pointer dereference
  ACPI: bus: Clean up devm_acpi_install_notify_handler()
  ACPI: PAD: Use sysfs_emit() in idlecpus_show()
  ACPI: video: Do not initialise device_id_scheme directly
  ACPI: video: Switch over to devres-based resource management
  ACPI: video: Use devm for video->entry and backlight cleanup
  ACPI: video: Use devm action for freeing video devices
  ACPI: video: Use devm action for video bus object cleanup
  ACPI: video: Rearrange probe and remove code
  ACPI: video: Reduce the number of auxiliary device dereferences
  ACPI: PAD: Switch over to devres-based resource management
  ACPI: PAD: Fix teardown ordering in acpi_pad_remove()
  ACPI: PAD: Pass struct device pointer to acpi_pad_notify()
  ACPI: PAD: Rearrange acpi_pad_notify()
  ACPI: thermal: Switch over to devres-based resource management
  ACPI: HED: Switch over to devres-based resource management
  ...

6 days agoMerge branch 'acpica'
Rafael J. Wysocki [Thu, 11 Jun 2026 12:57:55 +0000 (14:57 +0200)] 
Merge branch 'acpica'

Merge ACPICA updates for 7.2-rc1 including the following changes:

 - Add support for the Legacy Virtual Register (LVR) field in I2C serial
   bus resource descriptors to ACPICA (Akhil R)

 - Fix multiple issues related to bounds checks, input validation,
   use-after-free, and integer overflow checks in the AML interpreter
   in ACPICA (ikaros)

 - Update the copyright year to 2026 in ACPICA files and make minor
   changes related to ACPI 6.6 support (Pawel Chmielewski)

 - Remove spurious precision from format used to dump parse trees in
   ACPICA (David Laight)

 - Add modern standby DSM GUIDs to ACPICA header files (Daniel Schaefer)

 - Fix FADT 32/64X length mismatch warning in ACPICA (Abdelkader Boudih)

 - Update D3hot/cold device power states definitions in ACPICA header
   files (Aymeric Wibo)

 - Fix NULL pointer dereference in acpi_ns_custom_package() (Weiming
   Shi)

 - Update ACPICA version to 20260408 (Saket Dumbre)

* acpica: (27 commits)
  ACPICA: add boundary checks in two places
  ACPICA: Add package limit checks in parser functions
  ACPICA: Update version to 20260408
  ACPICA: Update the copyright year to 2026
  ACPICA: Remove spurious precision from format used to dump parse trees
  ACPICA: Enhance OEM ID and Table ID validation in acpi_ex_load_table_op()
  ACPICA: Fix NULL pointer dereference in acpi_ns_custom_package()
  ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources()
  ACPICA: Add validation for node in acpi_ns_build_normalized_path()
  ACPICA: validate handler object type in two places
  ACPICA: Improve argument parsing in acpi_ps_get_next_simple_arg()
  ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op)
  ACPICA: Prevent adding invalid references
  ACPICA: add boundary checks in acpi_ps_get_next_field()
  ACPICA: validate byte_count in acpi_ps_get_next_package_length()
  ACPICA: Fix use-after-free in acpi_ds_terminate_control_method()
  ACPICA: fix I2C LVR item count in the conversion table
  ACPICA: Mention the LVR bits
  ACPICA: Change LVR to 8 bit value
  ACPICA: Fetch LVR I2C resource descriptor
  ...

6 days agolocking: Add contended_release tracepoint to sleepable locks
Dmitry Ilvokhin [Thu, 4 Jun 2026 07:15:07 +0000 (07:15 +0000)] 
locking: Add contended_release tracepoint to sleepable locks

Add the contended_release trace event. This tracepoint fires on the
holder side when a contended lock is released, complementing the
existing contention_begin/contention_end tracepoints which fire on the
waiter side.

This enables correlating lock hold time under contention with waiter
events by lock address.

Add trace_contended_release()/trace_call__contended_release() calls to
the slowpath unlock paths of sleepable locks: mutex, rtmutex, semaphore,
rwsem, percpu-rwsem, and RT-specific rwbase locks.

Where possible, trace_contended_release() fires before the lock is
released and before the waiter is woken. For some lock types, the
tracepoint fires after the release but before the wake. Making the
placement consistent across all lock types is not worth the added
complexity.

For reader/writer locks, the tracepoint fires for every reader releasing
while a writer is waiting, not only for the last reader.

Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Paul E. McKenney <paulmck@kernel.org>
Acked-by: Usama Arif <usama.arif@linux.dev>
Link: https://patch.msgid.link/02f4f6c5ce6761e7f6587cf0ff2289d962ecddd4.1780506267.git.d@ilvokhin.com
6 days agolocking/percpu-rwsem: Extract __percpu_up_read()
Dmitry Ilvokhin [Thu, 4 Jun 2026 07:15:06 +0000 (07:15 +0000)] 
locking/percpu-rwsem: Extract __percpu_up_read()

Move the percpu_up_read() slowpath out of the inline function into a new
__percpu_up_read() to avoid binary size increase from adding a
tracepoint to an inlined function.

Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Usama Arif <usama.arif@linux.dev>
Link: https://patch.msgid.link/3dd2a1b9ab4f469e1892766cb63f41d6b0f53d29.1780506267.git.d@ilvokhin.com
6 days agotracing/lock: Remove unnecessary linux/sched.h include
Dmitry Ilvokhin [Thu, 4 Jun 2026 07:15:05 +0000 (07:15 +0000)] 
tracing/lock: Remove unnecessary linux/sched.h include

None of the trace events in lock.h reference anything from
linux/sched.h. Remove the unnecessary include.

Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Usama Arif <usama.arif@linux.dev>
Link: https://patch.msgid.link/85e14a0685c1d46c3e80de2dc01358a48169b263.1780506267.git.d@ilvokhin.com
6 days agofutex: Optimize futex hash bucket access patterns
Peter Zijlstra [Wed, 10 Jun 2026 21:20:09 +0000 (23:20 +0200)] 
futex: Optimize futex hash bucket access patterns

Breno reported significant c2c HITM in a futex hash heavy workload.

It turns out that the hash bucket to private hash table reverse pointer
(futex_hash_bucket::priv) was to blame. Notably when the hash buckets are
heavily contended, the: 'fph = bh->priv;' load in futex_hash() will typically
miss and consequently become quite expensive.

Since this load in particular is quite superfluous, removing it is fairly
straight forward. However, removing it does not in fact achieve anything much.
The pain moves to the next user, notably: futex_hash_put().

Therefore rework the whole private hash refcounting to avoid needing this back
pointer (and removing it). Instead of passing around 'struct futex_hash_bucket
*hb', pass around a new structure that contains it and the related 'struct
futex_private_hash *fph' pointer in tandem.

Funnily this turns out to remove more code than it adds and significantly
improves futex hash performance (as measured by 'perf bench futex hash'):

SKL dual socket 112 threads:

  Baseline        Patched
  shared (16k)    1571857         1641435         + 4.4%
  autosize (512)   646390          903371         +39.7%
  -b 256           464395          587014         +26.4%
  -b 512           715687          995943         +39.2%
  -b 1024          995085         1396328         +40.3%
  -b 2048         1293114         1668395         +29.0%
  -b 4096         2124438         2240228         + 5.5%

Zen3 dual socket 256 threads:

                  Baseline        Patched
  shared  (16k)   1275840         1381279         + 8.2%
  autosize (512)  1252745         1482179         +18.3%
  -b 256           856274          955455         +11.5%
  -b 512          1267490         1544010         +21.8%
  -b 1024         1424013         1625424         +14.1%
  -b 2048         1505181         1669342         +10.9%
  -b 4096         1465993         1688932         +15.2%

AMD EPYC 9D64 (Zen4, single socket) 176 threads:

                       Baseline       Patched      Delta
  shared (16k)         1,230,599      1,368,655    +11.2%
  autosize (1024)      1,285,440      1,556,946    +21.1%
  -b 256               1,341,471      1,520,303    +13.3%
  -b 512               1,438,330      1,599,319    +11.2%
  -b 1024              1,443,772      1,622,493    +12.4%
  -b 2048              1,472,108      1,643,975    +11.7%
  -b 4096              1,333,098      1,570,897    +17.8%

Reported-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Breno Leitao <leitao@debian.org>
Tested-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20260610135510.GB1430057@noisy.programming.kicks-ass.net
6 days agosched/fair: Fix newidle vs core-sched
Aaron Lu [Wed, 3 Jun 2026 09:51:08 +0000 (17:51 +0800)] 
sched/fair: Fix newidle vs core-sched

While testing Prateek's throttle series, I noticed a panic issue when
coresched is enabled and bisected to this patch.

I fed the panic log and this patch to an agent and its analysis looks
correct to me(cpu56 and cpu57 are siblings in a VM):

       cpu57 (holds core-wide lock)

     pick_next_task() [core scheduling]
     for_each_cpu_wrap(i, smt_mask, 57):
       i=57: pick_task(rq_57)
             pick_task_fair(rq_57)
             -> picks task A
       rq_57->core_pick = task A
       // task_rq(A) == rq_57

       i=56: pick_task(rq_56)
             pick_task_fair(rq_56)
             cfs_rq->nr_queued == 0
             goto idle
             sched_balance_newidle(rq_56)
             raw_spin_rq_unlock(rq_56)
             // core-wide lock released
             newidle_balance() pulls
               task A: rq_57 -> rq_56
             // task_rq(A) == rq_56 now
             raw_spin_rq_lock(rq_56)
             // core-wide lock re-acquired
             return > 0
             goto again
             pick_task_fair(rq_56)
             -> picks task A
       rq_56->core_pick = task A

     // first loop done
     // rq_57->core_pick is still task A (set before lock release)
     // but task_rq(A) == rq_56 now
     next = rq_57->core_pick  // = task A

     put_prev_set_next_task(rq_57, prev, task A)
     __set_next_task_fair(rq_57, task A)
     hrtick_start_fair(rq_57, task A)
     WARN_ON_ONCE(task_rq(task A) != rq_57)
     // task_rq(A) == rq_56

IOW: by allowing pick_task_fair() to do newidle_balance and not returning
RETRY_TASK, it can end up selecting the same task on two CPUs. Restore the
previous state by never doing newidle when core scheduling is enabled.

Tested-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: "Aaron Lu" <ziqianlu@bytedance.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20260603095108.GA1684319@bytedance.com
6 days agohwmon: (pmbus/lm25066) Fix PMBus coefficients for LM5064/5066/5066i
Potin Lai [Thu, 11 Jun 2026 05:46:18 +0000 (13:46 +0800)] 
hwmon: (pmbus/lm25066) Fix PMBus coefficients for LM5064/5066/5066i

Swap the high setting and low setting coefficients in the lm25066_coeff
table for LM5064, LM5066, and LM5066i. The coefficients were previously
mapped incorrectly, resulting in inverted current and power scaling.

Additionally, dynamically assign the exponent (R) registers inside the
probe's LM25066_DEV_SETUP_CL check. This ensures that the proper
exponent is applied (e.g., for LM25056, high setting power exponent
is -4, but low setting power exponent is -3).

Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
Link: https://lore.kernel.org/r/20260611-lm25066-driver-fix-v3-1-9d7d4b4e253d@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
6 days agoocteontx2-af: fix IP fragment flag corruption on custom KPU profile load
Kiran Kumar K [Mon, 8 Jun 2026 09:54:55 +0000 (15:24 +0530)] 
octeontx2-af: fix IP fragment flag corruption on custom KPU profile load

npc_cn20k_apply_custom_kpu() overwrites KPU profile entries with custom
firmware values and then calls npc_cn20k_update_action_entries_n_flags()
over all entries.  Since the same function already ran during default
profile initialisation, entries not overridden by the custom firmware
get their flags translated twice, corrupting the CN20K-specific values.

Fix this by extracting the per-entry translation into a helper
npc_cn20k_translate_action_flags() and calling it as each custom entry
is loaded, removing the redundant batch call at the end.

Fixes: ef992a0f12e8 ("octeontx2-af: npc: cn20k: MKEX profile support")
Cc: Suman Ghosh <sumang@marvell.com>
Signed-off-by: Kiran Kumar K <kirankumark@marvell.com>
Signed-off-by: Nitin Shetty J <nshettyj@marvell.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260608095455.1499203-1-nshettyj@marvell.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agoMerge branch 'net-shaper-follow-ups-to-recent-fixes'
Paolo Abeni [Thu, 11 Jun 2026 10:55:25 +0000 (12:55 +0200)] 
Merge branch 'net-shaper-follow-ups-to-recent-fixes'

Jakub Kicinski says:

====================
net: shaper: follow ups to recent fixes

As discussed previously on the patch set with real fixes the xa_locking
in shapers is a little confusing, remove it.
Link: https://lore.kernel.org/20260506000628.1501691-2-kuba@kernel.org
The remaining three patches are an attempt to silence AI reviewers,
I believe Sashiko was complaining about these non-issues. Not adding
Reported tags since these are false positives.
====================

Link: https://patch.msgid.link/20260609183224.1108521-1-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agonet: shaper: add a note that we expect cap dumps to be tiny
Jakub Kicinski [Tue, 9 Jun 2026 18:32:24 +0000 (11:32 -0700)] 
net: shaper: add a note that we expect cap dumps to be tiny

Various AI scan tools may complain that we don't support resuming
the cap dump. This is true, but the cap dumps are tiny.
net_shaper_nl_cap_pre_dumpit() sets up the dump for just
one device, so the size of the dump scales with NET_SHAPER_SCOPE_MAX (3).

We don't expect them to ever need more than a 4kB page.
Document this.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260609183224.1108521-5-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agonet: shaper: add a comment why we don't need kfree_rcu() in flush
Jakub Kicinski [Tue, 9 Jun 2026 18:32:23 +0000 (11:32 -0700)] 
net: shaper: add a comment why we don't need kfree_rcu() in flush

We keep getting misguided patches to fix the flush.
Add a comment.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260609183224.1108521-4-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agonet: shaper: drop unnecessary kfree_rcu in pre_insert
Jakub Kicinski [Tue, 9 Jun 2026 18:32:22 +0000 (11:32 -0700)] 
net: shaper: drop unnecessary kfree_rcu in pre_insert

If we fail to insert a node into the XArray in net_shaper_pre_insert()
we can free it directly - it was never visible to the RCU readers.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260609183224.1108521-3-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agonet: shaper: drop redundant xa_lock() bracketing
Jakub Kicinski [Tue, 9 Jun 2026 18:32:21 +0000 (11:32 -0700)] 
net: shaper: drop redundant xa_lock() bracketing

The shaper insertion and update code takes xa_lock() explicitly.
Paolo explained that the locking was purely to avoid re-taking
the lock in loops. But it may be mis-read as if it was expecting
readers to be fenced off by xa_lock. Readers of XArray are purely
under RCU. Remove explicit taking of xa_lock().

All writers to hierarchy->shapers are serialized by the netdev
instance lock (or run after netdev is made inaccessible to readers).

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260609183224.1108521-2-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agoMerge tag 'nf-26-06-10' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf
Paolo Abeni [Thu, 11 Jun 2026 10:29:59 +0000 (12:29 +0200)] 
Merge tag 'nf-26-06-10' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf

Pablo Neira Ayuso says:

====================
Netfilter fixes for net

The following patchset contains Netfilter fixes for net:

1) Revalidate bridge ports, add missing NULL checks to fetch the bridge
   device by the port. From Florian Westphal.

2) Fix netdevice refcount leak in the error path of nft_fwd hardware
   offload function, also from Florian.

3) Unregister helper expectfn callback on conntrack helper module
   removal, otherwise dangling pointer remains in place,
   from Weiming Shi.

4) Fix possible pointer infoleak in getsockopt() IPT_SO_GET_ENTRIES,
   From Kyle Zeng.

5) Validate that device MAC header is present before nf_syslog
   accesses it. From Xiang Mei.

6-8) Three patches to address a possible infoleak of stale stack
     data in three nf_tables expressions, due to mismatch in the
     _init() and _eval() function which is possible since 14fb07130c7d.
     From Davide Ornaghi and Florian Westphal.

netfilter pull request 26-06-10

* tag 'nf-26-06-10' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf:
  netfilter: nft_meta_bridge: fix stale stack leak via IIFHWADDR register
  netfilter: nft_fib: fix stale stack leak via the OIFNAME register
  netfilter: nft_exthdr: fix register tracking for F_PRESENT flag
  netfilter: nf_log: validate MAC header was set before dumping it
  netfilter: x_tables: avoid leaking percpu counter pointers
  netfilter: nf_conntrack: destroy stale expectfn expectations on unregister
  netfilter: nf_tables_offload: drop device refcount on error
  netfilter: revalidate bridge ports
====================

Link: https://patch.msgid.link/20260610161629.214092-1-pablo@netfilter.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agoASoC: loongson: Fix invalid position error in ls_pcm_pointer
Li Jun [Thu, 11 Jun 2026 01:00:45 +0000 (09:00 +0800)] 
ASoC: loongson: Fix invalid position error in ls_pcm_pointer

The "invalid position" error occurred when the DMA position descriptor
returned an invalid address value (e.g., pos = -1048838144). This happened
because the `bytes_to_frames()` function returns a signed value, but when
`addr < runtime->dma_addr`, the subtraction produces a negative result that
gets interpreted as a large unsigned integer in comparisons.
when the addr is abnormal, for example,the DMA controller is abnormal in
hardware,x=0 should not be a point(x == runtime->buffer_size),but a range,
which includes the addr address being less than runtime ->dma1-adr, and
the addr exceeding the DMA address range.the value of pos should not better
a negative,return 0, maybe better.

[   32.834431][ 2]  soc-audio soc-audio: invalid position: , pos = -1048838144
[   32.845019][ 2]  soc-audio soc-audio: invalid position: , pos = -1048838144
[   32.855588][ 2]  soc-audio soc-audio: invalid position: , pos = -1048838144
[   32.866145][ 2]  soc-audio soc-audio: invalid position: , pos = -1048838144
[   32.995394][ 2]  soc-audio soc-audio: invalid position: , pos = -1048838144
[   33.006025][ 2]  soc-audio soc-audio: invalid position: , pos = -1048838144
[   33.016748][ 2]  soc-audio soc-audio: invalid position: , pos = -1048838144

Signed-off-by: Li Jun <lijun01@kylinos.cn>
[Remove XRUN reporting I'd mistakenly avised adding on prior review -- broonie]
Link: https://patch.msgid.link/20260611010045.3668574-1-lijun01@kylinos.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
6 days agoMerge branch 'net-rds-convert-rds-to-getsockopt_iter'
Paolo Abeni [Thu, 11 Jun 2026 10:19:07 +0000 (12:19 +0200)] 
Merge branch 'net-rds-convert-rds-to-getsockopt_iter'

Breno Leitao says:

====================
net: rds: convert rds to getsockopt_iter

This series continues the conversion of the remaining proto_ops getsockopt
callbacks to the new getsockopt_iter callback introduced in commit
67fab22a7adc ("net: add getsockopt_iter callback to proto_ops"), this time
for RDS.

RDS is a little more involved than the protocols converted so far, because
the RDS_INFO_* options snapshot kernel state directly into the destination
buffer: the info producers memcpy into the pages under a spinlock via
kmap_atomic() and so must not fault.

The conversion preserves that model â€” it obtains the same page array and
starting offset from opt->iter_out with iov_iter_extract_pages(),
preallocating the array so the iterator fills it in place, and leaves
the rds_info_iterator / rds_info_copy machinery and all producer
callbacks unchanged; kernel (ITER_KVEC) buffers remain unsupported on
the RDS_INFO path, as before.

I've vibe-coded a kselftest exercising both the simple options and the
RDS_INFO_* snapshot path, feel free to drop it in case this is not
useful.

Signed-off-by: Breno Leitao <leitao@debian.org>
====================

Link: https://patch.msgid.link/20260608-getsock_more-v3-0-706ecf2ea332@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agords: convert to getsockopt_iter
Breno Leitao [Mon, 8 Jun 2026 09:44:58 +0000 (02:44 -0700)] 
rds: convert to getsockopt_iter

Convert RDS socket's getsockopt implementation to use the new
getsockopt_iter callback with sockopt_t.

Key changes:
- Replace (char __user *optval, int __user *optlen) with sockopt_t *opt
- Use opt->optlen for buffer length (input) and returned size (output)
- Use copy_to_iter() instead of put_user()/copy_to_user()

The RDS_INFO_* snapshot path in rds_info_getsockopt() used to pin the
userspace buffer with pin_user_pages_fast() on the raw optval address;
the info producers then memcpy into those pages under a spinlock via
kmap_atomic() and so must not fault. Obtain the same page array and
starting offset from opt->iter_out with iov_iter_extract_pages(), which
pins for write because iter_out is ITER_DEST.

The page array is preallocated here (sized with iov_iter_npages()) and
passed in, so iov_iter_extract_pages() fills it in place rather than
allocating one for us; RDS therefore keeps ownership of the array on
every return path and frees it itself. The rds_info_iterator /
rds_info_copy machinery and all producer callbacks are unchanged.

Kernel buffers (ITER_KVEC) are not page-backed in a way the info
producers can use, so the RDS_INFO path returns -EOPNOTSUPP for them;
this matches the previous behaviour, where a kernel-buffer getsockopt
hit the WARN_ONCE() path in do_sock_getsockopt() and returned
-EOPNOTSUPP. The simple RDS_RECVERR and SO_RDS_TRANSPORT options keep
working for kernel buffers via copy_to_iter().

Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Allison Henderson <achender@kernel.org>
Link: https://patch.msgid.link/20260608-getsock_more-v3-2-706ecf2ea332@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agoselftests: net: rds: add getsockopt() conversion test
Breno Leitao [Mon, 8 Jun 2026 09:44:57 +0000 (02:44 -0700)] 
selftests: net: rds: add getsockopt() conversion test

Add a kselftest that exercises the RDS getsockopt() paths converted to
the getsockopt_iter() / sockopt_t callback:

- RDS_RECVERR and SO_RDS_TRANSPORT, which return their int value through
  copy_to_iter() and report the written length in opt->optlen.

- RDS_INFO_*, which obtains the userspace buffer pages with
  iov_iter_extract_pages() (including a non-zero starting page offset)
  and lets the info producers copy the snapshot in under a spinlock.

Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Allison Henderson <achender@kernel.org>
Link: https://patch.msgid.link/20260608-getsock_more-v3-1-706ecf2ea332@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agoMerge tag 'ipsec-2026-06-10' of git://git.kernel.org/pub/scm/linux/kernel/git/klasser...
Paolo Abeni [Thu, 11 Jun 2026 10:00:49 +0000 (12:00 +0200)] 
Merge tag 'ipsec-2026-06-10' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec

Steffen Klassert says:

====================
pull request (net): ipsec 2026-06-10

1) xfrm: iptfs: preserve shared-frag marker in iptfs_consume_frags()
   Propagate SKBFL_SHARED_FRAG when paged fragments are moved between
   skbs so ESP can decide whether in-place crypto is safe.

2) xfrm: iptfs: fix use-after-free on first_skb in __input_process_payload
   Replace the unlocked read of xtfs->ra_newskb with a local flag so a
   concurrent reassembly can no longer free first_skb between
   spin_unlock and the post-loop check.

3) xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx()
   Prune the inexact bin under xfrm_policy_lock so a concurrent
   xfrm_hash_rebuild() can no longer free it before xfrm_policy_kill()
   dereferences it.

4) xfrm: iptfs: fix ABBA deadlock in iptfs_destroy_state()
   Move hrtimer_cancel() for the output and drop timers ahead of their
   spinlocks, breaking the softirq/lock cycle that could deadlock
   against the timer callbacks on SMP.

5) xfrm: espintcp: do not reuse an in-progress partial send
   Fail a new send when espintcp_push_msgs() returns with emsg->len
   still set, so a blocking caller can no longer overwrite ctx->partial
   while a previous transfer still owns it.

6) esp: fix page frag reference leak on skb_to_sgvec failure
   Add a flag to esp_ssg_unref() to unconditionally unref the source
   scatterlist, releasing the old page references that are otherwise
   leaked when the second skb_to_sgvec() in esp_output_tail() fails.

Please pull or let me know if there are problems.

ipsec-2026-06-10

* tag 'ipsec-2026-06-10' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec:
  esp: fix page frag reference leak on skb_to_sgvec failure
  xfrm: espintcp: do not reuse an in-progress partial send
  xfrm: iptfs: fix ABBA deadlock in iptfs_destroy_state()
  xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx()
  xfrm: iptfs: fix use-after-free on first_skb in __input_process_payload
  xfrm: iptfs: preserve shared-frag marker in iptfs_consume_frags()
====================

Link: https://patch.msgid.link/20260610140800.2562818-1-steffen.klassert@secunet.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agoipv6: Fix a potential NPD in cleanup_prefix_route()
Ido Schimmel [Tue, 9 Jun 2026 14:54:48 +0000 (17:54 +0300)] 
ipv6: Fix a potential NPD in cleanup_prefix_route()

addrconf_get_prefix_route() can return the fib6_null_entry sentinel
entry which has a NULL fib6_table pointer. Therefore, before setting the
route's expiration time, check that we are not working with this entry,
as otherwise a NPD will be triggered [1].

Note that the other callers of addrconf_get_prefix_route() are not
susceptible to this bug:

1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF |
   RTF_PREFIX_RT' flags which are not set on fib6_null_entry.

2. modify_prefix_route(): Fixed by commit a747e02430df ("ipv6: avoid
   possible NULL deref in modify_prefix_route()").

3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for
   fib6_null_entry and returns an error.

[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
[...]
Call Trace:
<TASK>
__kasan_check_byte (mm/kasan/common.c:573)
lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1))
_raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1))
cleanup_prefix_route (net/ipv6/addrconf.c:1280)
ipv6_del_addr (net/ipv6/addrconf.c:1342)
inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119)
inet6_rtm_deladdr (net/ipv6/addrconf.c:4812)
rtnetlink_rcv_msg (net/core/rtnetlink.c:6997)
netlink_rcv_skb (net/netlink/af_netlink.c:2555)
netlink_unicast (net/netlink/af_netlink.c:1344)
netlink_sendmsg (net/netlink/af_netlink.c:1899)
__sock_sendmsg (net/socket.c:802 (discriminator 4))
____sys_sendmsg (net/socket.c:2698)
___sys_sendmsg (net/socket.c:2752)
__sys_sendmsg (net/socket.c:2784)
do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)

Fixes: 5eb902b8e719 ("net/ipv6: Remove expired routes with a separated list of routes.")
Reported-by: Ji'an Zhou <eilaimemedsnaimel@gmail.com>
Reviewed-by: David Ahern <dahern@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260609145448.768318-1-idosch@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agoMerge branch 'selftests-drv-net-so_txtime-trivial-fixes'
Paolo Abeni [Thu, 11 Jun 2026 09:39:14 +0000 (11:39 +0200)] 
Merge branch 'selftests-drv-net-so_txtime-trivial-fixes'

Jakub Kicinski says:

====================
selftests: drv-net: so_txtime: trivial fixes

I noticed that so_txtime is only passing on NIPA setups which are
looped within a single host. The cross-machine cases just flat out
fail. The initial bug is obvious - the test does not deploy the binary.
But even with that I think more work would be needed to sync the
time / adjust the expectations for a dual-machine test.

Willem promised to follow up on the fundamental issues with 2-host
setups :)

v1: https://lore.kernel.org/20260608173305.372987-1-kuba@kernel.org
====================

Link: https://patch.msgid.link/20260609180803.1093428-1-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agoselftests: drv-net: so_txtime: check IP versions
Jakub Kicinski [Tue, 9 Jun 2026 18:08:03 +0000 (11:08 -0700)] 
selftests: drv-net: so_txtime: check IP versions

This test needs more work, and it fails in non-obvious way
when IPv4 connectivity is not available:

  # Exception| CMD[remote]: /tmp/vjquwblf/gukinuzqso_txtime -4 -c mono -t 1780939014114542914 -S None -D None a,0 -r
  # Exception|   EXIT: -15

Explicitly check for IPv4 support to make the future triage
less painful.

Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260609180803.1093428-3-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agoselftests: drv-net: so_txtime: remember to deploy the binaries
Jakub Kicinski [Tue, 9 Jun 2026 18:08:02 +0000 (11:08 -0700)] 
selftests: drv-net: so_txtime: remember to deploy the binaries

The test seems to be written with a single-host loopback
in mind. We need to deploy the binary to remote before
we run it. This is just fixing an obvious issue, but
more work will be needed to make the dual-host setup
work reliably. Most of the runs still fail with:

  FAIL: start time already passed

Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260609180803.1093428-2-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agoMerge branch 'net-txgbe-fix-module-identification'
Paolo Abeni [Thu, 11 Jun 2026 08:55:15 +0000 (10:55 +0200)] 
Merge branch 'net-txgbe-fix-module-identification'

Jiawen Wu says:

====================
net: txgbe: fix module identification

For AML devices, there are some issues where the wrong module
indentified then configure PHY failed.

The module info buffers should be initialized to 0 before the firmware
returns information. And DECLARE_PHY_INTERFACE_MASK() does not guarantee
zeroed contents, so explicitly clear the temporary interface masks before
setting supported interfaces.

Rework txgbe_identify_module() to validate module identifiers through
explicit type checks instead of relying on transceiver_type heuristics.
When using the SFP module, transceiver_type could be a random value,
because it was read from an invalid register.
====================

Link: https://patch.msgid.link/20260608070842.36504-1-jiawenwu@trustnetic.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agonet: txgbe: initialize PHY interface to 0
Jiawen Wu [Mon, 8 Jun 2026 07:08:42 +0000 (15:08 +0800)] 
net: txgbe: initialize PHY interface to 0

DECLARE_PHY_INTERFACE_MASK() does not guarantee zeroed contents. Add a
new macro DECLARE_PHY_INTERFACE_MASK_ZERO(), make the stack variable to
be zeroed before setting supported interfaces.

Fixes: 57d39faed4c9 ("net: txgbe: improve functions of AML 40G devices")
Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
Link: https://patch.msgid.link/20260608070842.36504-4-jiawenwu@trustnetic.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agonet: txgbe: distinguish module types by checking identifier
Jiawen Wu [Mon, 8 Jun 2026 07:08:41 +0000 (15:08 +0800)] 
net: txgbe: distinguish module types by checking identifier

Rework txgbe_identify_module() to validate module identifiers through
explicit type checks instead of relying on transceiver_type heuristics.
When using the SFP module, transceiver_type could be a random value,
because it was read from an invalid register.

Fixes: 57d39faed4c9 ("net: txgbe: improve functions of AML 40G devices")
Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
Link: https://patch.msgid.link/20260608070842.36504-3-jiawenwu@trustnetic.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agonet: txgbe: initialize module info buffer
Jiawen Wu [Mon, 8 Jun 2026 07:08:40 +0000 (15:08 +0800)] 
net: txgbe: initialize module info buffer

The module info buffer should be initialized to 0 before the firmware
returns information. Otherwise, there is a risk that the buffer field
not filled by the firmware is random value.

Fixes: 343929799ace ("net: txgbe: Support to handle GPIO IRQs for AML devices")
Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
Link: https://patch.msgid.link/20260608070842.36504-2-jiawenwu@trustnetic.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agogpio: nomadik: remove dead DB8540 code from <gpio/gpio-nomadik.h>
Ethan Nelson-Moore [Wed, 10 Jun 2026 20:50:07 +0000 (13:50 -0700)] 
gpio: nomadik: remove dead DB8540 code from <gpio/gpio-nomadik.h>

DB8540 support was removed in commit b6d09f780761 ("pinctrl: nomadik:
Drop U8540/9540 support"), but a couple small pieces of related code
remained in <gpio/gpio-nomadik.h>. Remove them.

Discovered while searching for CONFIG_* symbols referenced in code but
not defined in any Kconfig file.

Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260610205007.44881-1-enelsonmoore@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
6 days agox86/cpu: Make CONFIG_X86_CX8 unconditional
Ingo Molnar [Mon, 27 Apr 2026 06:11:18 +0000 (08:11 +0200)] 
x86/cpu: Make CONFIG_X86_CX8 unconditional

I.e. from now on it's a boot time requirement for the CPU to support it.

( This was preceded by the removal of all non-CX8 platform build
  options, so it should have no functional effects in theory. )

Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Ahmed S . Darwish <darwi@linutronix.de>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: H . Peter Anvin <hpa@zytor.com>
Cc: John Ogness <john.ogness@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20250425084216.3913608-14-mingo@kernel.org
6 days agox86/cpu: Remove unused !CONFIG_X86_TSC code
Ingo Molnar [Mon, 27 Apr 2026 06:07:02 +0000 (08:07 +0200)] 
x86/cpu: Remove unused !CONFIG_X86_TSC code

Now that the Kconfig space always enables CONFIG_X86_TSC (on x86),
remove !CONFIG_X86_TSC code from the x86 arch code.

We still keep the Kconfig option to catch any eventual code still
pending in maintainer or non-mainline trees, plus some drivers
have raw TSC timestamping hacks that use CONFIG_X86_TSC.

It's also still possible to disable TSC support runtime.

Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Ahmed S . Darwish <darwi@linutronix.de>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: H . Peter Anvin <hpa@zytor.com>
Cc: John Ogness <john.ogness@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20250425084216.3913608-13-mingo@kernel.org
6 days agom68k: stmark2: enable DACs outputs
Angelo Dureghello [Wed, 10 Jun 2026 20:35:13 +0000 (22:35 +0200)] 
m68k: stmark2: enable DACs outputs

Enabled DAC0 and DAC1 outpus disabling shared ADC inputs on ADC3 and ADC7.

Reviewed-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
6 days agom68k: stmark2: add mcf5441x DAC platform devices
Angelo Dureghello [Wed, 10 Jun 2026 20:35:12 +0000 (22:35 +0200)] 
m68k: stmark2: add mcf5441x DAC platform devices

Add mcf5441x DAC platform devices.

Reviewed-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
6 days agom68k: stmark2: use ioport.h macros for resources
Angelo Dureghello [Wed, 10 Jun 2026 20:35:11 +0000 (22:35 +0200)] 
m68k: stmark2: use ioport.h macros for resources

Change resource declaration using DEFINE_RES_*() macros.
DEFINE_DMA_RES() is for a single dma channel, not a range, so used twice.

Also, some drivers assume IRQ resources are from index 1, so just to stay
uniform, moved IRQ resource at index 1.

Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
6 days agom68k: mcf5441x: add CCR MISCCR2 bitfields
Angelo Dureghello [Wed, 10 Jun 2026 20:35:10 +0000 (22:35 +0200)] 
m68k: mcf5441x: add CCR MISCCR2 bitfields

Add CCR MISCCR2 register bitfields.

Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
6 days agom68k: mcf5441x: add CCM registers
Angelo Dureghello [Wed, 10 Jun 2026 20:35:09 +0000 (22:35 +0200)] 
m68k: mcf5441x: add CCM registers

Add CCM module register offsets.

Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
6 days agom68k: add DAC modules base addresses
Angelo Dureghello [Wed, 10 Jun 2026 20:35:08 +0000 (22:35 +0200)] 
m68k: add DAC modules base addresses

Add DAC controller 0 and 1 base addresses.

Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
6 days agom68k: mcf5441x: add clock for DAC channel 1
Angelo Dureghello [Wed, 10 Jun 2026 20:35:07 +0000 (22:35 +0200)] 
m68k: mcf5441x: add clock for DAC channel 1

Add missing clock for mcf5441x DAC channel 1.

Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
6 days agom68k: mcf5441x: fix clocks numbering
Angelo Dureghello [Wed, 10 Jun 2026 20:35:06 +0000 (22:35 +0200)] 
m68k: mcf5441x: fix clocks numbering

Fix clocks numbering, set correct values for eport and DAC,
as per RM Rev 5, 05/2018, table 9.5.

Fixes: bea8bcb12da09 ("m68knommu: Add support for the Coldfire m5441x.")
Fixes: 007f84ede6e3e ("m68k: coldfire: remove private clk_get/clk_put")
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
6 days agoMerge branch 'net-mvpp2-fix-xdp-rx-buffer-handling'
Paolo Abeni [Thu, 11 Jun 2026 07:57:33 +0000 (09:57 +0200)] 
Merge branch 'net-mvpp2-fix-xdp-rx-buffer-handling'

Til Kaiser says:

====================
net: mvpp2: fix XDP RX buffer handling

This is v5 of the earlier XDP_PASS fix. The XDP_PASS change is
retained, and the series also fixes related RX/XDP buffer handling
issues found during review.

Tested with tools/testing/selftests/drivers/net/xdp.py on mvpp2
hardware.
====================

Link: https://patch.msgid.link/20260607134943.21996-1-mail@tk154.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agonet: mvpp2: build skb from XDP-adjusted data on XDP_PASS
Til Kaiser [Sun, 7 Jun 2026 13:49:43 +0000 (15:49 +0200)] 
net: mvpp2: build skb from XDP-adjusted data on XDP_PASS

When an XDP program uses bpf_xdp_adjust_head() or bpf_xdp_adjust_tail()
and then returns XDP_PASS, mvpp2 still builds the skb from fixed offsets
derived from the original RX descriptor. Packet geometry changes made by
the XDP program are therefore discarded before the skb reaches the stack.

Update rx_offset and rx_bytes from xdp.data and xdp.data_end for
XDP_PASS. This makes skb_reserve() and skb_put() reflect the packet seen
by XDP, and makes RX byte accounting for XDP_PASS follow the length of the
skb passed to the network stack.

Keep a separate rx_sync_size for page-pool recycling on skb allocation
failure, which must stay tied to the received buffer range.

Non-PASS verdicts continue to account the descriptor length because no skb
is passed up in those cases.

Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support")
Signed-off-by: Til Kaiser <mail@tk154.de>
Link: https://patch.msgid.link/20260607134943.21996-5-mail@tk154.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agonet: mvpp2: refill RX buffers before XDP or skb use
Til Kaiser [Sun, 7 Jun 2026 13:49:42 +0000 (15:49 +0200)] 
net: mvpp2: refill RX buffers before XDP or skb use

The RX error path returns the current descriptor buffer to the hardware
BM pool. That is only valid while the driver still owns the buffer.

mvpp2_rx_refill() can fail after the current buffer has been handed to
XDP or attached to an skb. In those cases mvpp2_run_xdp() may have
recycled, redirected, or queued the page for XDP_TX, and an skb free also
retires the data buffer. Returning such a buffer to BM lets hardware DMA
into memory that is no longer owned by the RX ring.

Refill the BM pool before handing the current buffer to XDP or to the
skb. If the allocation fails there, drop the packet and return the
still-owned current buffer to BM, preserving the pool depth. Once the
refill succeeds, later local drops retire/free the current buffer instead
of returning it to BM.

Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support")
Fixes: d6526926de73 ("net: mvpp2: fix memory leak in mvpp2_rx")
Signed-off-by: Til Kaiser <mail@tk154.de>
Link: https://patch.msgid.link/20260607134943.21996-4-mail@tk154.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agonet: mvpp2: limit XDP frame size to the RX buffer
Til Kaiser [Sun, 7 Jun 2026 13:49:41 +0000 (15:49 +0200)] 
net: mvpp2: limit XDP frame size to the RX buffer

mvpp2 has short and long BM pools, and short pool buffers can be smaller
than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with
PAGE_SIZE as frame size.

XDP helpers use frame_sz to validate tail growth and to derive the hard
end of the data area. Advertising PAGE_SIZE for short buffers can let
bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting
memory or later tripping skb tailroom checks.

Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches
the actual buffer backing the packet.

Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support")
Signed-off-by: Til Kaiser <mail@tk154.de>
Link: https://patch.msgid.link/20260607134943.21996-3-mail@tk154.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agonet: mvpp2: sync RX data at the hardware packet offset
Til Kaiser [Sun, 7 Jun 2026 13:49:40 +0000 (15:49 +0200)] 
net: mvpp2: sync RX data at the hardware packet offset

mvpp2 programs the RX queue packet offset, so hardware writes received
data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at
dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the
unused headroom and misses the same number of bytes at the packet tail.

On non-coherent DMA systems this can leave the CPU reading stale cache
contents for the end of the received frame.

Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range
offset so the sync covers the Marvell header and packet data actually
written by hardware.

Fixes: e1921168bbd4 ("mvpp2: sync only the received frame")
Signed-off-by: Til Kaiser <mail@tk154.de>
Link: https://patch.msgid.link/20260607134943.21996-2-mail@tk154.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 days agokbuild: rust: clean `zerocopy-derive` in `mrproper`
Miguel Ojeda [Wed, 10 Jun 2026 14:30:25 +0000 (16:30 +0200)] 
kbuild: rust: clean `zerocopy-derive` in `mrproper`

Just like for the other two Rust proc macros, remove the artifacts in
`mrproper`.

This should have been part of commit 506054980429 ("rust: zerocopy-derive:
enable support in kbuild").

Link: https://patch.msgid.link/20260610143025.368801-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
6 days agoALSA: usb-audio: Use the new helper for shutdown refcount
Takashi Iwai [Wed, 10 Jun 2026 15:45:35 +0000 (17:45 +0200)] 
ALSA: usb-audio: Use the new helper for shutdown refcount

Replace the open-code for managing the shutdown refcount with the new
helpers.
Only a code cleanup, no functional changes.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260610154538.51076-6-tiwai@suse.de
6 days agoALSA: aloop: Use the new helper for stop-count refcount
Takashi Iwai [Wed, 10 Jun 2026 15:45:34 +0000 (17:45 +0200)] 
ALSA: aloop: Use the new helper for stop-count refcount

Replace the open-code for managing the stop-count refcount with the
new helpers.
Only a code cleanup, no functional changes.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260610154538.51076-5-tiwai@suse.de
6 days agoALSA: hda: Use the new helper for PCM instance refcount
Takashi Iwai [Wed, 10 Jun 2026 15:45:33 +0000 (17:45 +0200)] 
ALSA: hda: Use the new helper for PCM instance refcount

HD-audio core driver has some open-code for managing the refcount for
PCM instances, and it can be replaced gracefully with the new helpers.
Only a code cleanup, no functional changes.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260610154538.51076-4-tiwai@suse.de
6 days agoALSA: core: Use the new helper for the power refcount
Takashi Iwai [Wed, 10 Jun 2026 15:45:32 +0000 (17:45 +0200)] 
ALSA: core: Use the new helper for the power refcount

Replace the open code for managing the power refcount in the snd_card
object with the new helper functions.
Only a code cleanup, no functional changes.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260610154538.51076-3-tiwai@suse.de
6 days agoALSA: Add simple refcount helper functions
Takashi Iwai [Wed, 10 Jun 2026 15:45:31 +0000 (17:45 +0200)] 
ALSA: Add simple refcount helper functions

There are many open-code to manage the same pattern for refcount +
wakeup sync at closing.  Let's provide the common helper functions to
replace the open-code.

- The recount is kept in struct snd_refcount, where it's initialized
by snd_refcount_init().
- The user can simply reference or unreference via snd_refcount_get()
and snd_refcount_put() functions
- The user can wait for the all usages gone by snd_refcount_sync()

Note that here we use atomic_t instead of refcount_t since the current
users allow reusing the refcount after sync again.  The design of
refcount_t prevents exactly this behavior, so it doesn't fit.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260610154538.51076-2-tiwai@suse.de
6 days agocrypto: xilinx-trng - Replace crypto_drbg_ctr_df() with HMAC-SHA512
Eric Biggers [Sun, 31 May 2026 19:17:37 +0000 (12:17 -0700)] 
crypto: xilinx-trng - Replace crypto_drbg_ctr_df() with HMAC-SHA512

This code is just trying to condition 48 bytes of random data.  This can
be done easily using HKDF-SHA512-Extract, saving 300 lines of code.

This commit also fixes forward security (in this particular case) by
clearing the entropy from memory after it's used.

Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
6 days agocrypto: xilinx-trng - Fix return value of xtrng_hwrng_trng_read()
Eric Biggers [Sun, 31 May 2026 19:17:36 +0000 (12:17 -0700)] 
crypto: xilinx-trng - Fix return value of xtrng_hwrng_trng_read()

Implementations of hwrng::read are expected to return the number of
bytes generated.  Update xtrng_hwrng_trng_read() to match that.

Fixes: 8979744aca80 ("crypto: xilinx - Add TRNG driver for Versal")
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
6 days agocrypto: xilinx-trng - Remove crypto_rng interface
Eric Biggers [Sun, 31 May 2026 19:17:35 +0000 (12:17 -0700)] 
crypto: xilinx-trng - Remove crypto_rng interface

Implementing the crypto_rng interface has no purpose, as it isn't used
in practice.  It's being removed from other drivers too.  Just remove
it.  This leaves hwrng, which is actually used.

Tagging with 'Cc stable' due to the bugs that this removes:

  - xtrng_trng_generate() sometimes returned success even when it didn't
    fill in all the bytes.

  - It was possible for xtrng_trng_generate() and
    xtrng_hwrng_trng_read() to run concurrently and interfere with each
    other, as the locking code in xtrng_hwrng_trng_read() was broken.

Fixes: 8979744aca80 ("crypto: xilinx - Add TRNG driver for Versal")
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
6 days agocrypto: exynos-rng - Remove exynos-rng driver
Eric Biggers [Sun, 31 May 2026 17:59:31 +0000 (10:59 -0700)] 
crypto: exynos-rng - Remove exynos-rng driver

This driver has no purpose.  It doesn't feed into the Linux RNG, nor
does it implement the hwrng interface.  It is accessible only via the
"rng" algorithm type of AF_ALG, which isn't used in practice.  Everyone
uses either the Linux RNG, or rarely /dev/hwrng.

Moreover, this is a PRNG whose only source of entropy is the 160-bit
seed the user passes in.  So this can be used only by a user who already
has a source of cryptographically secure random numbers, such as
/dev/random.  Which they can, and do, just use in the first place.

Just remove this driver.  There's no need to keep useless code around.

Note that the other crypto_rng drivers in drivers/crypto/ are similarly
unused and are being removed too.  This commit just handles exynos-rng.

Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
6 days agohwrng: hisi-trng - Move hisi-trng into drivers/char/hw_random/
Eric Biggers [Sat, 30 May 2026 20:26:24 +0000 (13:26 -0700)] 
hwrng: hisi-trng - Move hisi-trng into drivers/char/hw_random/

Since this file just implements a hwrng driver, move it into
drivers/char/hw_random/.  Rename the kconfig option accordingly as well.

Note that this moves the file back to its original location.

Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
6 days agocrypto: hisi-trng - Remove crypto_rng interface
Eric Biggers [Sat, 30 May 2026 20:26:23 +0000 (13:26 -0700)] 
crypto: hisi-trng - Remove crypto_rng interface

drivers/crypto/hisilicon/trng/trng.c exposes the same hardware through
two completely separate interfaces, crypto_rng and hwrng.  However, the
implementation of this is buggy because it permits generation operations
from these interfaces to run concurrently with each other, accessing the
same registers.  That is, hisi_trng_generate() synchronizes with itself
but not with hisi_trng_read().  This results in potential repetition of
output from the RNG, output of non-random values, etc.

Fortunately, there's actually no point in hardware RNG drivers
implementing the crypto_rng interface.  It's not actually used by
anything besides the "rng" algorithm type of AF_ALG, which in turn is
not actually used in practice.  Other crypto_rng hardware drivers are
likewise being phased out, leaving just the hwrng support.

Thus, remove it to simplify the code and avoid conflict (and confusion)
with the hwrng interface which is the one that actually matters.

Fixes: e4d9d10ef4be ("crypto: hisilicon/trng - add support for PRNG")
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
6 days agocrypto: loongson - Remove broken and unused loongson-rng
Eric Biggers [Fri, 29 May 2026 23:32:08 +0000 (16:32 -0700)] 
crypto: loongson - Remove broken and unused loongson-rng

The loongson-rng rng_alg has several vulnerabilities, including not
providing forward security, and a use-after-free bug due to the use of
wait_for_completion_interruptible().

Meanwhile, the rng_alg framework doesn't really have any purpose in the
first place other than to access the software algorithms crypto/drbg.c
and crypto/jitterentropy.c.  Hardware-specific rng_algs have no
in-kernel user, and unlike hwrng there's no feed into the actual Linux
RNG.  As such, there's really no point to this code.  There are of
course other rng_alg drivers that are similarly unused, but they're
similarly in the process of being phased out, e.g.
https://lore.kernel.org/r/20260529193648.18172-1-ebiggers@kernel.org and
https://lore.kernel.org/r/20260529220430.34135-1-ebiggers@kernel.org

Given that, there's no point in fixing forward these vulnerabilities,
and it makes much more sense to simply roll back the addition of this
driver.  If this platform provides TRNG (not PRNG) functionality, it
could make sense to add a hwrng driver, but it would be quite different.

Link: https://lore.kernel.org/linux-crypto/20260525145939.GC2018@quark/
Fixes: 766b2d724c8d ("crypto: loongson - add Loongson RNG driver support")
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
6 days agocrypto: crypto4xx - Remove insecure and unused rng_alg
Eric Biggers [Fri, 29 May 2026 22:04:30 +0000 (15:04 -0700)] 
crypto: crypto4xx - Remove insecure and unused rng_alg

Remove crypto4xx_rng, as it is insecure and unused:

- It has only a 64-bit security strength, which is highly inadequate.
  This can be seen by the fact that crypto4xx_hw_init() seeds it with
  only 64 bits of entropy, and the fact that the original commit
  mentions that it implements ANSI X9.17 Annex C.

  Another issue was that this driver didn't implement the crypto_rng API
  correctly, as crypto4xx_prng_generate() didn't return 0 on success.

- No user of this code is known.  It's usable only theoretically via the
  "rng" algorithm type of AF_ALG.  But userspace actually just uses the
  actual Linux RNG (/dev/random etc) instead.  And rng_algs don't
  contribute entropy to the actual Linux RNG either.  (This may have
  been confused with hwrng, which does contribute entropy.)

Fixes: d072bfa48853 ("crypto: crypto4xx - add prng crypto support")
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Acked-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
6 days agocrypto: qat - validate RSA CRT component lengths
Giovanni Cabiddu [Thu, 28 May 2026 15:57:44 +0000 (16:57 +0100)] 
crypto: qat - validate RSA CRT component lengths

The generic RSA key parser (rsa_helper.c) bounds each CRT component (p,
q, dp, dq, qinv) by the modulus size n_sz, but qat_rsa_setkey_crt()
allocates half-size DMA buffers (key_sz / 2) and right-aligns each
component with:

    memcpy(dst + half_key_sz - len, src, len)

When a CRT component is larger than half_key_sz the subtraction
underflows and memcpy writes past the DMA buffer, causing memory
corruption.

Add a len > half_key_sz check next to the existing !len check for each
of the five CRT components so the driver falls back to the non-CRT path
instead of writing out of bounds.

Fixes: 879f77e9071f ("crypto: qat - Add RSA CRT mode")
Cc: stable@vger.kernel.org
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Ahsan Atta <ahsan.atta@intel.com>
Reviewed-by: Laurent M Coquerel <laurent.m.coquerel@intel.com>
Tested-by: Laurent M Coquerel <laurent.m.coquerel@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
6 days agohwmon: (gpd-fan) Reject EC PWM value 0 as invalid
Pei Xiao [Thu, 11 Jun 2026 00:44:14 +0000 (08:44 +0800)] 
hwmon: (gpd-fan) Reject EC PWM value 0 as invalid

The EC firmware is expected to return values in [1, pwm_max]. A read of 0
is illegal and would cause underflow in the conversion formula. Explicitly
check for 0 and return -EIO.

Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
Link: https://lore.kernel.org/r/1c2ffa0d832ae3a74f6d4ffa7cc7b7e6cced69e3.1781138459.git.xiaopei01@kylinos.cn
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
6 days agoselftests/bpf: Cover tail-call cgroup storage prog-array checks
Lin Ma [Wed, 10 Jun 2026 10:55:39 +0000 (12:55 +0200)] 
selftests/bpf: Cover tail-call cgroup storage prog-array checks

Add tail-call selftests for prog-array ownership when cgroup storage
is in use. Verify that loading succeeds when callers and callees reuse
the owner's cgroup storage map, and that loading fails for a different
storage map and for the A(storage) -> B(no storage) -> C(storage)
bridge case addressed in the previous commit.

Also verify that a storage-less leaf program which cannot perform tail
calls itself is still allowed to join a storage-owned prog array, while
a storage-less tail-caller is rejected also at map update time.

  # LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t tailcalls
  [...]
  #475/25  tailcalls/tailcall_freplace:OK
  #475/26  tailcalls/tailcall_bpf2bpf_freplace:OK
  #475/27  tailcalls/tailcall_failure:OK
  #475/28  tailcalls/reject_tail_call_spin_lock:OK
  #475/29  tailcalls/reject_tail_call_rcu_lock:OK
  #475/30  tailcalls/reject_tail_call_preempt_lock:OK
  #475/31  tailcalls/reject_tail_call_ref:OK
  #475/32  tailcalls/tailcall_sleepable:OK
  #475/33  tailcalls/tailcall_cgrp_storage:OK
  #475/34  tailcalls/tailcall_cgrp_storage_diff_storage:OK
  #475/35  tailcalls/tailcall_cgrp_storage_no_storage:OK
  #475/36  tailcalls/tailcall_cgrp_storage_no_storage_leaf:OK
  #475/37  tailcalls/tailcall_cgrp_storage_no_storage_bridge:OK
  #475     tailcalls:OK
  Summary: 1/37 PASSED, 0 SKIPPED, 0 FAILED

Signed-off-by: Lin Ma <malin89@huawei.com>
Signed-off-by: Rongzhen Cui <cuirongzhen@huawei.com>
Signed-off-by: Jingguo Tan <tanjingguo@huawei.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20260610105539.705887-2-daniel@iogearbox.net
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
6 days agobpf: Tighten cgroup storage cookie checks for prog arrays
Daniel Borkmann [Wed, 10 Jun 2026 10:55:38 +0000 (12:55 +0200)] 
bpf: Tighten cgroup storage cookie checks for prog arrays

The fix in commit abad3d0bad72 ("bpf: Fix oob access in cgroup local
storage") is still incomplete. The prog-array compatibility check
treats a program with no cgroup storage as compatible with any stored
storage cookie. This allows a storage-less program to bridge a tail
call chain between an entry program and a storage-using callee even
though cgroup local storage at runtime still follows the caller's
context, that is, A -> B(no storage) -> C(storage) path.

Requiring exact cookie equality would break the legitimate case of a
storage-less leaf program being tail called from a storage-using one.
Instead, only accept a zero storage cookie if the program cannot
perform tail calls itself. This keeps A -> B(no storage) working
while rejecting the A -> B(no storage) -> C(storage) bridge.

Fixes: abad3d0bad72 ("bpf: Fix oob access in cgroup local storage")
Reported-by: Lin Ma <malin89@huawei.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20260610105539.705887-1-daniel@iogearbox.net
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
6 days agoi2c: mxs: add missing kernel-doc for struct mxs_i2c_dev members
Rosen Penev [Wed, 3 Jun 2026 03:11:35 +0000 (20:11 -0700)] 
i2c: mxs: add missing kernel-doc for struct mxs_i2c_dev members

Add kernel-doc documentation for the struct members that were previously
undocumented. This fixes warnings when building with W=1 and ensures
the struct is fully documented per kernel-doc conventions.

Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20260603031135.289302-1-rosenp@gmail.com