]> git.ipfire.org Git - thirdparty/linux.git/log
thirdparty/linux.git
5 days agoMerge tag 'asoc-fix-v7.1-rc7' of https://git.kernel.org/pub/scm/linux/kernel/git...
Takashi Iwai [Thu, 11 Jun 2026 19:29:47 +0000 (21:29 +0200)] 
Merge tag 'asoc-fix-v7.1-rc7' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v7.1

A few more fixes for this release, some smaller driver specific ones
plus a final quirk.

5 days agoMerge branches 'pm-cpuidle', 'pm-opp' and 'pm-qos'
Rafael J. Wysocki [Thu, 11 Jun 2026 19:20:57 +0000 (21:20 +0200)] 
Merge branches 'pm-cpuidle', 'pm-opp' and 'pm-qos'

Merge cpuidle updates, OPP (operating performance points) updates and a
PM QoS update for 7.2-rc1:

 - Allow the intel_idle driver to avoid exposing C-states that are
   redundant when PC6 is disabled (Artem Bityutskiy)

 - Fix memory leak and a potential race in the OPP core (Abdun Nihaal,
   Di Shen)

 - Mark Rust OPP methods as inline (Nicolás Antinori)

 - Fix misc device registration failure path in the PM QoS core (Yuho
   Choi)

* pm-cpuidle:
  intel_idle: Drop C-states redundant when PC6 is disabled
  intel_idle: Introduce a helper for checking PC6
  intel_idle: Add constants for MSR_PKG_CST_CONFIG_CONTROL

* pm-opp:
  opp: rust: mark OPP methods as inline
  OPP: of: Fix potential memory leak in opp_parse_supplies()
  OPP: Fix race between OPP addition and lookup

* pm-qos:
  PM: QoS: Fix misc device registration unwind

5 days agoMerge branch 'pm-cpufreq'
Rafael J. Wysocki [Thu, 11 Jun 2026 19:19:13 +0000 (21:19 +0200)] 
Merge branch 'pm-cpufreq'

Merge cpufreq updates for 7.2:

 - Fix a race between cpufreq suspend and CPU hotplug during system
   shutdown (Tianxiang Chen)

 - Avoid redundant target() calls for unchanged limits and fix a typo
   in a comment in the cpufreq core (Viresh Kumar)

 - Fix concurrency issues related to sysfs attributes access that affect
   cpufreq governors using the common governor code (Zhongqiu Han)

 - Simplify frequency limit handling in the conservative cpufreq
   governor (Lifeng Zheng)

 - Fix descriptions of the conservative governor freq_step tunable and
   the ondemand governor sampling_down_factor tunable in the cpufreq
   documentation (Pengjie Zhang)

 - Fix use-after-free and double free during _OSC evaluation in the PCC
   cpufreq driver (Yuho Choi)

 - Rework the handling of policy min and max frequency values in the
   cpufreq core to allow drivers to specify special initial values for
   the scaling_min_freq and scaling_max_freq sysfs attributes (Pierre
   Gondois)

 - Add cpufreq scaling support for Qualcomm Shikra SoC (Taniya Das,
   Imran Shaik).

 - Improve the warning message on HWP-disabled hybrid processors printed
   by the intel_pstate driver and sync policy->cur during CPU offline in
   it (Yohei Kojima, Fushuai Wang)

 - Drop cpufreq support for AMD Elan SC4* (Sean Young)

 - Minor fixes for cpufreq drivers (Krzysztof Kozlowski, Akashdeep Kaur,
   Hans Zhang, Guangshuo Li, Xueqin Luo)

 - Clean up dead dependencies on X86 in the cpufreq Kconfig (Julian
   Braha)

* pm-cpufreq: (25 commits)
  cpufreq: Use policy->min/max init as QoS request
  cpufreq: Remove driver default policy->min/max init
  cpufreq: Set default policy->min/max values for all drivers
  cpufreq: Extract cpufreq_policy_init_qos() function
  cpufreq: Documentation: fix conservative governor freq_step description
  cpufreq: ti: Add EPROBE_DEFER for K3 SoCs
  cpufreq: qcom: Add cpufreq scaling support for Qualcomm Shikra SoC
  dt-bindings: cpufreq: Document Qualcomm Shikra SoC EPSS
  cpufreq: governor: Fix stale prev_cpu_nice spike when enabling ignore_nice_load
  cpufreq: governor: Fix data races on per-CPU idle/nice baselines
  cpufreq: intel_pstate: Improve warning message on HWP-disabled hybrid CPUs
  cpufreq: elanfreq: Drop support for AMD Elan SC4*
  cpufreq: clean up dead dependencies on X86 in Kconfig
  cpufreq: conservative: Simplify frequency limit handling
  cpufreq: Avoid redundant target() calls for unchanged limits
  cpufreq: Fix typo in comment
  cpufreq: intel_pstate: Sync policy->cur during CPU offline
  cpufreq: Documentation: fix sampling_down_factor range
  cpufreq: Fix hotplug-suspend race during reboot
  cpufreq: pcc: fix use-after-free and double free in _OSC evaluation
  ...

5 days agoMAINTAINERS: Update address for David Heidelberg
David Heidelberg [Tue, 2 Jun 2026 17:48:46 +0000 (19:48 +0200)] 
MAINTAINERS: Update address for David Heidelberg

The +nfc postfix is not useful as I thought. Use the default email.

Signed-off-by: David Heidelberg <david@ixit.cz>
5 days agonfc: Use named initializers for struct i2c_device_id
Uwe Kleine-König (The Capable Hub) [Mon, 18 May 2026 13:33:11 +0000 (15:33 +0200)] 
nfc: Use named initializers for struct i2c_device_id

While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.

While touching all these arrays, unify usage of whitespace in the list
terminator.

This patch doesn't modify the compiled arrays, only their representation
in source form benefits. The former was confirmed with x86 and arm64
builds.

Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260518133311.644160-2-u.kleine-koenig@baylibre.com
Signed-off-by: David Heidelberg <david@ixit.cz>
5 days agonfc: nxp-nci: treat -ENXIO in IRQ thread as no data available
Carl Lee [Tue, 26 May 2026 01:50:29 +0000 (09:50 +0800)] 
nfc: nxp-nci: treat -ENXIO in IRQ thread as no data available

The I2C read operation in the IRQ thread may return -ENXIO
when the controller has not yet provided data after asserting IRQ.

IRQ assertion does not guarantee that data is immediately
available on the I2C bus. In such cases, the read request may
be NACKed, resulting in -ENXIO.

Treat this condition as "no data available yet" and log it at
debug level instead of reporting it as a read failure.

This avoids misleading error messages during normal operation.

Signed-off-by: Carl Lee <carl.lee@amd.com>
Link: https://patch.msgid.link/20260526-nfc-nxp-nci-treat-enxio-as-no-data-available-yet-v1-1-305bb11b9147@amd.com
Signed-off-by: David Heidelberg <david@ixit.cz>
5 days agoBluetooth: btintel_pcie: Separate coredump work from RX work
Ravindra [Wed, 10 Jun 2026 16:25:44 +0000 (21:55 +0530)] 
Bluetooth: btintel_pcie: Separate coredump work from RX work

Sharing a single workqueue between coredump processing and RX
delays evacuation of RX events while a coredump is in progress.
The firmware's RX buffers can overflow during that window, leading
to dropped events. The issue was observed in HID use cases where
HID reports arrive in bursts and quickly fill the RX path while a
coredump is being collected.

Move coredump processing to a dedicated ordered coredump_workqueue
with its own coredump_work, so coredumps run independently of RX.
All four coredump trigger sources (FW assert, HW exception, user
sysfs trigger, and resume-error detection) are switched to this new
workqueue. Ordering serialises concurrent triggers without blocking
RX.

Signed-off-by: Ravindra <ravindra@intel.com>
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()
Sergey Senozhatsky [Tue, 9 Jun 2026 12:10:06 +0000 (21:10 +0900)] 
Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()

Every once in a while we see a hung btmtksdio_flush() task:

 INFO: task kworker/u17:0:189 blocked for more than 122 seconds.
 __cancel_work_timer+0x3f4/0x460
 cancel_work_sync+0x1c/0x2c
 btmtksdio_flush+0x2c/0x40
 hci_dev_open_sync+0x10c4/0x2190
 [..]

It all boils down to incorrect time_is_before_jiffies() usage in
btmtksdio_txrx_work().  The btmtksdio_txrx_work() loop is expected
to be terminated if running for longer than 5*HZ.  However the
timeout check is twisted:  time_is_before_jiffies(old_jiffies + 5*HZ)
evaluates to true when old_jiffies + 5*HZ is in the past i.e. when a
timeout has occurred.  Using OR with time_is_before_jiffies(txrx_timeout)
means that:
- before the 5-second timeout: the condition is `int_status || false`,
  so it loops as long as there are pending interrupts.
- after the 5-second timeout: the condition becomes `int_status || true`,
  which is always true.

When the loop becomes infinite btmtksdio_txrx_work() loop never
terminates and never releases the SDIO host.

Fix loop termination condition to actually enforce a 5*HZ timeout.

Fixes: 26270bc189ea4 ("Bluetooth: btmtksdio: move interrupt service to work")
Cc: stable@vger.kernel.org
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Reviewed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: qca: Add BT FW build version to kernel log
Xiuzhuo Shang [Wed, 10 Jun 2026 06:42:32 +0000 (14:42 +0800)] 
Bluetooth: qca: Add BT FW build version to kernel log

Firmware version is critical for bug triage. Users reporting issues
typically share dmesg output rather than debugfs contents, requiring
extra communication rounds to collect this information. Log the FW
build version directly to the kernel log so it is immediately
available in bug reports.

Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Xiuzhuo Shang <xiuzhuo.shang@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: vhci: validate devcoredump state before side effects
Samuel Moelius [Mon, 8 Jun 2026 23:58:23 +0000 (23:58 +0000)] 
Bluetooth: vhci: validate devcoredump state before side effects

The VHCI force_devcoredump debugfs hook accepts a small test record from
userspace. It validates the requested terminal state only after
registering, initializing and appending a Bluetooth devcoredump.

As a result, an invalid state returns -EINVAL but still leaves queued
devcoredump work behind. With a non-zero timeout field, the rejected
write can still emit a devcoredump after the timeout expires.

Reject unsupported states before allocating the skb or changing the HCI
devcoredump state machine.

Fixes: ab4e4380d4e1 ("Bluetooth: Add vhci devcoredump support")
Assisted-by: Codex:gpt-5.5-cyber-preview
Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: L2CAP: validate connectionless PSM length
Samuel Moelius [Mon, 8 Jun 2026 23:57:05 +0000 (23:57 +0000)] 
Bluetooth: L2CAP: validate connectionless PSM length

Connectionless L2CAP frames carry a two-byte PSM at the start of the
payload.  l2cap_recv_frame() currently reads that PSM unconditionally
after validating only the outer L2CAP length.

A malformed connectionless frame with a zero- or one-byte payload can
therefore make the parser read beyond the advertised skb payload and use
tailroom bytes as part of the PSM.  A VHCI-backed QEMU reproducer
injected a one-byte connectionless payload and reached the unchecked
read.

Reject connectionless frames that cannot contain the PSM before reading
or pulling it.  This preserves all valid connectionless frames while
dropping only structurally incomplete packets.

Assisted-by: Codex:gpt-5.5-cyber-preview
Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: hci: validate codec capability element length
Samuel Moelius [Mon, 8 Jun 2026 23:56:28 +0000 (23:56 +0000)] 
Bluetooth: hci: validate codec capability element length

Read Local Codec Capabilities returns a sequence of capability elements.
Each element starts with a one-byte length followed by that many payload
bytes.

hci_read_codec_capabilities() checks that the skb contains the length
byte, but then validates only caps->len against the remaining skb
length.  A malformed controller response with one remaining byte and
caps->len set to one passes that check even though the element needs two
bytes.  The parser then records a two-byte capability and copies one
byte beyond the advertised response payload into the codec list.

Validate the full element size, including the length byte, before adding
it to the accumulated capability length.  This preserves all well-formed
capability elements and drops only truncated controller responses.

Fixes: 8961987f3f5f ("Bluetooth: Enumerate local supported codec and cache details")
Assisted-by: Codex:gpt-5.5-cyber-preview
Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref
Marco Elver [Fri, 5 Jun 2026 14:23:35 +0000 (16:23 +0200)] 
Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref

l2cap_chan_timeout() runs asynchronously and accesses chan->conn. If
the connection is torn down while the timer is running or pending,
chan->conn can be freed, leading to a use-after-free when the timer
worker attempts to lock conn->lock:

| BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 [inline]
| BUG: KASAN: slab-use-after-free in atomic_long_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:4456 [inline]
| BUG: KASAN: slab-use-after-free in __mutex_trylock_fast kernel/locking/mutex.c:161 [inline]
| BUG: KASAN: slab-use-after-free in mutex_lock+0x4f/0xa0 kernel/locking/mutex.c:318
| Write of size 8 at addr ffff8881298d9550 by task kworker/2:1/83
|
| CPU: 2 UID: 0 PID: 83 Comm: kworker/2:1 Not tainted 7.1.0-rc6-next-20260601-dirty #6 PREEMPT(full)
| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
| Workqueue: events l2cap_chan_timeout
| Call Trace:
|  <TASK>
|  instrument_atomic_read_write include/linux/instrumented.h:112 [inline]
|  atomic_long_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:4456 [inline]
|  __mutex_trylock_fast kernel/locking/mutex.c:161 [inline]
|  mutex_lock+0x4f/0xa0 kernel/locking/mutex.c:318
|  l2cap_chan_timeout+0x5d/0x1b0 net/bluetooth/l2cap_core.c:422
|  process_one_work kernel/workqueue.c:3326 [inline]
|  process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c:3409
|  worker_thread+0x8a9/0xcf0 kernel/workqueue.c:3490
|  kthread+0x346/0x430 kernel/kthread.c:436
|  ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c:158
|  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
|  </TASK>
|
| Allocated by task 320:
|  l2cap_conn_add+0xa7/0x820 net/bluetooth/l2cap_core.c:7075
|  l2cap_connect_cfm+0xdb/0xd70 net/bluetooth/l2cap_core.c:7452
|  hci_connect_cfm include/net/bluetooth/hci_core.h:2139 [inline]
|  hci_remote_features_evt+0x52f/0x9f0 net/bluetooth/hci_event.c:3760
|  hci_event_func net/bluetooth/hci_event.c:7796 [inline]
|  hci_event_packet+0x561/0xa70 net/bluetooth/hci_event.c:7847
|  hci_rx_work+0x370/0x890 net/bluetooth/hci_core.c:4040
|  process_one_work kernel/workqueue.c:3326 [inline]
|  process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c:3409
|  worker_thread+0x8a9/0xcf0 kernel/workqueue.c:3490
|  kthread+0x346/0x430 kernel/kthread.c:436
|  ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c:158
|  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
|
| Freed by task 322:
|  hci_disconn_cfm include/net/bluetooth/hci_core.h:2154 [inline]
|  hci_conn_hash_flush+0x101/0x1f0 net/bluetooth/hci_conn.c:2736
|  hci_dev_close_sync+0x889/0xde0 net/bluetooth/hci_sync.c:5405
|  hci_dev_do_close net/bluetooth/hci_core.c:502 [inline]
|  hci_unregister_dev+0x1f7/0x370 net/bluetooth/hci_core.c:2679
|  vhci_release+0x12a/0x180 drivers/bluetooth/hci_vhci.c:690
|  __fput+0x369/0x890 fs/file_table.c:510
|  task_work_run+0x160/0x1d0 kernel/task_work.c:233
|  get_signal+0xf5b/0x1120 kernel/signal.c:2810
|  arch_do_signal_or_restart+0x4d/0x600 arch/x86/kernel/signal.c:337
|  __exit_to_user_mode_loop kernel/entry/common.c:64 [inline]
|  exit_to_user_mode_loop+0x85/0x510 kernel/entry/common.c:98
|  do_syscall_64+0x263/0x3d0 arch/x86/entry/syscall_64.c:100
|  entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
| The buggy address belongs to the object at ffff8881298d9400
|  which belongs to the cache kmalloc-512 of size 512
| The buggy address is located 336 bytes inside of
|  freed 512-byte region [ffff8881298d9400ffff8881298d9600)

Fix it by having chan->conn hold a reference to l2cap_conn (via
l2cap_conn_get) when the channel is added to the connection, and
releasing it in the channel destructor. This ensures the l2cap_conn
remains alive as long as the channel exists.

A new FLAG_DEL channel flag is introduced to indicate that the channel
has been deleted from its connection. l2cap_chan_del() atomically sets
this flag using test_and_set_bit() instead of setting chan->conn to
NULL. All asynchronous workers (l2cap_chan_timeout, l2cap_ack_timeout,
l2cap_monitor_timeout, l2cap_retrans_timeout) and l2cap_chan_send()
check FLAG_DEL to determine whether the channel has been torn down,
rather than testing chan->conn for NULL.

Fixes: 8c8e620467a7 ("Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()")
Cc: <stable@vger.kernel.org>
Cc: Siwei Zhang <oss@fourdim.xyz>
Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Assisted-by: Gemini:gemini-3.1-pro-preview
Reported-by: https://sashiko.dev/#/patchset/20260521021249.3258069-1-oss%40fourdim.xyz
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: btintel_pcie: Load IOSF debug regs by controller variant
Sai Teja Aluvala [Sun, 7 Jun 2026 06:21:17 +0000 (11:51 +0530)] 
Bluetooth: btintel_pcie: Load IOSF debug regs by controller variant

Load the IOSF DBGC base address based on the controller hardware
variant when reading DRAM buffers during a trace dump. Scorpius
Peak family controllers (SCP/SCP2/SCP2F) use a different DBGC base
address (0xf0d5d500) than Blazar family controllers (BZRI/BZRIW,
0xf3800300).

Fixes: 07e6bddb54b4 ("Bluetooth: btintel_pcie: Add support for device coredump")
Signed-off-by: Sai Teja Aluvala <aluvala.sai.teja@intel.com>
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: btintel_pcie: Add 50 ms delay before MAC init on BlazarIW
Kiran K [Sat, 6 Jun 2026 00:36:37 +0000 (06:06 +0530)] 
Bluetooth: btintel_pcie: Add 50 ms delay before MAC init on BlazarIW

On BlazarIW, fast restart cycles fail because the D0 entry to MAC
init does not complete in time. As a result, MAC initialization
does not proceed and the controller fails to transition past the
ROM boot stage.

Add a 50 ms delay (worst case as per HW analysis) before doing MAC
init in btintel_pcie_enable_bt() so the shared hardware reset flow
has time to complete. The delay is gated on the BlazarIW PCI device
id 0x4D76 so other Intel BT PCIe controllers are unaffected.

Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: Add SPDX id lines to some source files
Tim Bird [Thu, 4 Jun 2026 17:06:33 +0000 (11:06 -0600)] 
Bluetooth: Add SPDX id lines to some source files

Many bluetooth source files are missing SPDX-License-Identifier
lines. Add appropriate IDs to these files, and remove other
license lines from the headers.

Leave the warranty disclaimer in files where the license ID is
GPL-2.0 but the wording of the disclaimer is slightly different
from that of the GPL v2 disclaimer.

It is not different enough to cause licensing conflicts, but is
kept to honor the original contributors' legal intent.

Signed-off-by: Tim Bird <tim.bird@sony.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: btintel_pcie: Add support for smart trigger dump
Kiran K [Wed, 3 Jun 2026 15:54:15 +0000 (21:24 +0530)] 
Bluetooth: btintel_pcie: Add support for smart trigger dump

Based on the debug configuration, firmware can raise MSI-X interrupt with
firmware trigger cause bit set on specific events like Disconnection,
Connection Timeout, Page Timeout etc.

Upon receiving an MSI-X interrupt with the firmware trigger cause bit
set, the driver performs the following actions:

1. Reads Device Memory: Retrieves data from the device memory,
   constructs an HCI diagnostic event, and sends it to the monitor. This
   event includes details about the trigger, such as connection timeout or
   page timeout.

2. Dumps Device Coredump: Generates a coredump containing firmware
   traces for further analysis.

The coredump can be retrieved using:

  $ cat /sys/class/devcoredump/devcd*/data > /tmp/btintel_coredump.bin

HCI traces:
= Vendor Diagnostic (len 12)
        a5 a5 a5 a5 01 03 00 23 00 01 00 00

Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: hci_h5: reset hci_uart::priv in the close() method
Sergey Shtylyov [Mon, 1 Jun 2026 20:21:30 +0000 (23:21 +0300)] 
Bluetooth: hci_h5: reset hci_uart::priv in the close() method

Unlike the other HCI UART drivers, the 3-wire UART driver doesn't reset
hci_uart::priv in its close() method -- this shouldn't pose a problem as
all the methods in *struct* hci_uart_proto should only be called after the
open() method that sets up hci_uart::priv properly. However, it seems wise
to be more consistent and provide for the *struct* hci_uart_proto methods
the same state that exists before the first open() method call (so that
they rather crash than dereference a stale hci_uart::priv pointer)...

Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.

Signed-off-by: Sergey Shtylyov <s.shtylyov@auroraos.dev>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: btusb: clean up probe error handling
Johan Hovold [Thu, 4 Jun 2026 06:37:40 +0000 (08:37 +0200)] 
Bluetooth: btusb: clean up probe error handling

Clean up probe error handling by using dedicated error labels with an
"err" prefix.

Note that the endpoint lookup helper returns -ENXIO when endpoints are
missing which is functionally equivalent to returning -ENODEV.

Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: btusb: fix wakeup irq devres lifetime
Johan Hovold [Thu, 4 Jun 2026 06:37:39 +0000 (08:37 +0200)] 
Bluetooth: btusb: fix wakeup irq devres lifetime

The OOB wakeup interrupt is device managed but its lifetime is
incorrectly tied to the child HCI device rather than the USB interface
to which the driver is bound.

This should not cause any trouble currently as the interrupt will be
disabled when the HCI device is deregistered on disconnect (but this was
not always the case, see [1]), and there should be no further references
if probe fails before registering it. But it is still technically wrong
as the reference counted HCI device could in theory remain after a probe
failure.

Explicitly free the interrupt on disconnect so that it is guaranteed to
be disabled before freeing the (non-managed) driver data (including if
disconnected while suspended).

[1] 699fb50d9903 ("drivers: base: Free devm resources when unregistering
                   a device")

Fixes: fd913ef7ce61 ("Bluetooth: btusb: Add out-of-band wakeup support")
Cc: Rajat Jain <rajatja@google.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: btusb: fix wakeup source leak on probe failure
Johan Hovold [Thu, 4 Jun 2026 06:37:38 +0000 (08:37 +0200)] 
Bluetooth: btusb: fix wakeup source leak on probe failure

Make sure to disable wakeup on probe failure to avoid leaking the wakeup
source.

Fixes: fd913ef7ce61 ("Bluetooth: btusb: Add out-of-band wakeup support")
Cc: stable@vger.kernel.org # 4.11
Cc: Rajat Jain <rajatja@google.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: btusb: fix use-after-free on marvell probe failure
Johan Hovold [Thu, 4 Jun 2026 06:37:37 +0000 (08:37 +0200)] 
Bluetooth: btusb: fix use-after-free on marvell probe failure

Make sure to stop any TX URBs submitted during Marvell OOB wakeup
configuration on later probe failures to avoid use-after-free in the
completion callback.

This issue was reported by Sashiko while reviewing a fix for a wakeup
source leak in the btusb probe errors paths.

Link: https://sashiko.dev/#/patchset/20260402092704.2346710-1-johan%40kernel.org
Fixes: a4ccc9e33d2f ("Bluetooth: btusb: Configure Marvell to use one of the pins for oob wakeup")
Cc: stable@vger.kernel.org # 4.11
Cc: Rajat Jain <rajatja@google.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: btusb: fix use-after-free on registration failure
Johan Hovold [Thu, 4 Jun 2026 06:37:36 +0000 (08:37 +0200)] 
Bluetooth: btusb: fix use-after-free on registration failure

Make sure to release the sibling interfaces in case controller
registration fails to avoid use-after-free and double-free when they are
eventually disconnected.

This issue was reported by Sashiko while reviewing a fix for a wakeup
source leak in the btusb probe errors paths.

Link: https://sashiko.dev/#/patchset/20260402092704.2346710-1-johan%40kernel.org
Fixes: 9bfa35fe422c ("[Bluetooth] Add SCO support to btusb driver")
Fixes: 9d08f50401ac ("Bluetooth: btusb: Add support for Broadcom LM_DIAG interface")
Cc: stable@vger.kernel.org # 2.6.27
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: btmtk: fix URB leak in alloc_mtk_intr_urb error path
Zhao Dongdong [Thu, 4 Jun 2026 11:46:40 +0000 (19:46 +0800)] 
Bluetooth: btmtk: fix URB leak in alloc_mtk_intr_urb error path

When btmtk_isopkt_pad() fails, the previously allocated URB is not freed,
leaking the urb structure. Add usb_free_urb() before returning the error.

Fixes: ceac1cb0259d ("Bluetooth: btusb: mediatek: add ISO data transmission functions")
Signed-off-by: Zhao Dongdong <zhaodongdong@kylinos.cn>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: hci_core: Fix UAF in hci_unregister_dev()
Jordan Walters [Wed, 3 Jun 2026 08:50:47 +0000 (04:50 -0400)] 
Bluetooth: hci_core: Fix UAF in hci_unregister_dev()

hci_unregister_dev() does not disable cmd_timer and ncmd_timer
before the hci_dev structure is freed. If a timeout fires
during device teardown, the callback dereferences freed memory
(including the hdev->reset function pointer), leading to a
use-after-free.

Add disable_delayed_work_sync() calls alongside the existing
disable_work_sync() calls to ensure both timers are fully
quiesced before teardown proceeds.

Fixes: 0d151a103775 ("Bluetooth: hci_core: cancel all works upon hci_unregister_dev()")
Signed-off-by: Jordan Walters <jaggyaur@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: hci_event: fix simultaneous discovery stuck in FINDING
Jiajia Liu [Tue, 2 Jun 2026 07:00:32 +0000 (15:00 +0800)] 
Bluetooth: hci_event: fix simultaneous discovery stuck in FINDING

When hci_inquiry_complete_evt is called between le_scan_disable and
le_set_scan_enable_complete and no remote name needs to be resolved,
the interleaved discovery with SIMULTANEOUS quirk gets stuck in
DISCOVERY_FINDING. le_set_scan_enable_complete does not check inquiry
state. No one sets DISCOVERY_STOPPED in this process.

Add state check in le_set_scan_enable_complete and change state if
the state is DISCOVERY_FINDING. Tested with AX201 (8087:0026) in Dell
Vostro 13. Discovering disabled MGMT Event below is reported when
running into the above condition.

 @ MGMT Command: Start Discovery (0x0023)    {0x0001} [hci0] 10885.970873
         Address type: 0x07
           BR/EDR
           LE Public
           LE Random
 ...
 < HCI Command: LE Set Extended Scan Enable    #38205 [hci0] 10886.131438
         Extended scan: Enabled (0x01)
         Filter duplicates: Enabled (0x01)
         Duration: 0 msec (0x0000)
         Period: 0.00 sec (0x0000)
 > HCI Event: Command Complete (0x0e) plen 4   #38206 [hci0] 10886.133295
       LE Set Extended Scan Enable (0x08|0x0042) ncmd 2
         Status: Success (0x00)
 @ MGMT Event: Discovering (0x0013) plen 2   {0x0001} [hci0] 10886.133414
         Address type: 0x07
           BR/EDR
           LE Public
           LE Random
         Discovery: Enabled (0x01)
 < HCI Command: Inquiry (0x01|0x0001) plen 5   #38207 [hci0] 10886.133528
         Access code: 0x9e8b33 (General Inquiry)
         Length: 10.24s (0x08)
         Num responses: 0
 > HCI Event: Command Status (0x0f) plen 4     #38208 [hci0] 10886.141333
       Inquiry (0x01|0x0001) ncmd 2
         Status: Success (0x00)
 ...
 < HCI Command: LE Set Extended Scan Enable    #38242 [hci0] 10896.381802
         Extended scan: Disabled (0x00)
         Filter duplicates: Disabled (0x00)
         Duration: 0 msec (0x0000)
         Period: 0.00 sec (0x0000)
 > HCI Event: Inquiry Complete (0x01) plen 1   #38243 [hci0] 10896.383419
         Status: Success (0x00)
 > HCI Event: Command Complete (0x0e) plen 4   #38244 [hci0] 10896.394378
       LE Set Extended Scan Enable (0x08|0x0042) ncmd 2
         Status: Success (0x00)
 @ MGMT Event: Device Found (0x0012) plen 22 {0x0001} [hci0] 10896.394497
         LE Address: 88:12:AC:92:43:69
         RSSI: -101 dBm (0x9b)
         Flags: 0x00000004
           Not Connectable
         Data length: 8
         Company: Xiaomi Inc. (911)
           Data[0]:
         16-bit Service UUIDs (complete): 1 entry
           Xiaomi Inc. (0xfdaa)
 @ MGMT Event: Discovering (0x0013) plen 2   {0x0001} [hci0] 10896.394506
         Address type: 0x07
           BR/EDR
           LE Public
           LE Random
         Discovery: Disabled (0x00)

Fixes: 8ffde2a73f2c ("Bluetooth: Convert le_scan_disable timeout to hci_sync")
Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: eir: Fix stack OOB write when prepending the Flags AD
Weiming Shi [Tue, 2 Jun 2026 17:06:21 +0000 (01:06 +0800)] 
Bluetooth: eir: Fix stack OOB write when prepending the Flags AD

eir_create_adv_data() builds the advertising data into a fixed-size
buffer ("size", 31 for the legacy path). It may prepend a 3-byte "Flags"
AD structure (LE_AD_NO_BREDR on an LE-only controller) and then copies
the per-instance data without checking that it still fits:

memcpy(ptr, adv->adv_data, adv->adv_data_len);

tlv_data_max_len() only reserves those 3 bytes when the user-supplied
flags carry a managed-flags bit, so an instance added with flags == 0 is
accepted with adv_data_len up to the full buffer. At advertise time the
flags are still prepended, and the memcpy() writes 3 + adv_data_len
bytes into the size-byte buffer:

  BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:301)
  Write of size 31 at addr ffff88800a547bdc by task kworker/u9:0/65
  Workqueue: hci0 hci_cmd_sync_work
   __asan_memcpy (mm/kasan/shadow.c:106)
   eir_create_adv_data (net/bluetooth/eir.c:301)
   hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1310)
   hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:1817)
   hci_cmd_sync_work (net/bluetooth/hci_sync.c:332)
  This frame has 1 object:
   [32, 64) 'cp'

The "Flags" structure is added by the kernel, not requested by
userspace, so only prepend it when it fits together with the instance
advertising data; when there is no room for both, drop the flags rather
than the user-provided data.

Reachable by a local user with CAP_NET_ADMIN owning an LE-only
controller on the legacy advertising path.

Fixes: b44133ff03be ("Bluetooth: Support the "discoverable" adv flag")
Reported-by: Xiang Mei <xmei5@asu.edu>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
Reported-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: btusb: Add support for TP-Link TL-UB250
Cris [Wed, 3 Jun 2026 03:58:18 +0000 (11:58 +0800)] 
Bluetooth: btusb: Add support for TP-Link TL-UB250

Add USB ID 2357:0607 for TP-Link TL-UB250.

This is a Realtek RTL8761BUV based Bluetooth adapter.

Without this entry the device is picked up by the generic Bluetooth USB
class match and exposes hci0, but the Realtek setup path is not used and
rtl8761bu firmware/config are not loaded.

The controller reports Realtek Semiconductor Corporation as the
manufacturer and LMP subversion 0x8761. With this entry added, btusb
loads rtl_bt/rtl8761bu_fw.bin and rtl_bt/rtl8761bu_config.bin
successfully.

Relevant part of /sys/kernel/debug/usb/devices:

T:  Bus=01 Lev=02 Prnt=06 Port=00 Cnt=01 Dev#=  9 Spd=12   MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=2357 ProdID=0607 Rev= 2.00
S:  Product=TP-Link TL-UB250 Adapter
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
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Use the same flags as the existing TP-Link 2357:0604 entry.

Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Cris <cxs1494089474@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
Rong Zhang [Tue, 2 Jun 2026 18:38:10 +0000 (02:38 +0800)] 
Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925

These NICs are often reported to lose their Bluetooth interfaces, i.e,
their USB interfaces suddenly become completely unresponsive, causing
the USB core to reset them, only to find that they are no longer
accessible. A power cycle is required to make the Bluetooth interfaces
recover.

After some investigations, I found that their USB autosuspend remote
wakeup capabilities are so broken that they are precisely the culprit
behind the issue:

  [27452.608056] hub 3-0:1.0: state 7 ports 5 chg 0000 evt 0020
  [27452.702018] usb 3-5: usb wakeup-resume
  [27452.716038] usb 3-5: Waited 0ms for CONNECT
  [27452.716642] usb 3-5: finish resume
  /* usbmon showed that the device was completely unresponsive to any
     URBs after the remote wakeup */
  [27457.836030] usb 3-5: retry with reset-resume
  [27457.956046] usb 3-5: reset high-speed USB device number 4 using xhci_hcd
  [27463.332047] usb 3-5: device descriptor read/64, error -110
  [27478.948117] usb 3-5: device descriptor read/64, error -110
  [27479.172430] usb 3-5: reset high-speed USB device number 4 using xhci_hcd
  [27484.332035] usb 3-5: device descriptor read/64, error -110
  [27499.940039] usb 3-5: device descriptor read/64, error -110
  [27500.164060] usb 3-5: reset high-speed USB device number 4 using xhci_hcd
  [27505.196142] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
  [27510.576045] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
  [27510.784038] usb 3-5: device not accepting address 4, error -62
  [27510.912215] usb 3-5: reset high-speed USB device number 4 using xhci_hcd
  [27515.948307] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
  [27521.324380] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
  [27521.525107] usb 3-5: device not accepting address 4, error -62
  [27521.525928] usb usb3-port5: logical disconnect
  [27521.525996] usb 3-5: gone after usb resume? status -19
  [27521.526230] usb 3-5: can't resume, status -19
  [27521.526434] usb usb3-port5: logical disconnect
  [27521.526469] usb usb3-port5: resume, status -19
  [27521.526493] usb usb3-port5: status 0503, change 0004, 480 Mb/s
  [27521.526528] usb 3-5: USB disconnect, device number 4
  [27521.526736] usb 3-5: unregistering device
  [27521.804029] usb 3-5: new high-speed USB device number 5 using xhci_hcd
  [27527.076067] usb 3-5: device descriptor read/64, error -110
  [27542.692027] usb 3-5: device descriptor read/64, error -110
  [27542.916047] usb 3-5: new high-speed USB device number 6 using xhci_hcd
  [27548.068043] usb 3-5: device descriptor read/64, error -110
  [27563.684073] usb 3-5: device descriptor read/64, error -110
  [27563.792133] usb usb3-port5: attempt power cycle
  [27563.924381] hub 3-0:1.0: port_wait_reset: err = -11
  [27563.925213] usb usb3-port5: not enabled, trying reset again...
  [27564.184398] usb 3-5: new high-speed USB device number 7 using xhci_hcd
  [27569.196322] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
  [27574.572040] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
  [27574.776053] usb 3-5: device not accepting address 7, error -62
  [27574.900165] usb 3-5: new high-speed USB device number 8 using xhci_hcd
  [27579.948039] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
  [27585.324331] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
  [27585.528040] usb 3-5: device not accepting address 8, error -62
  [27585.528389] usb usb3-port5: unable to enumerate USB device
  [27585.528424] hub 3-0:1.0: state 7 ports 5 chg 0000 evt 0020

To reproduce the issue, these conditions must be met:
- a noisy radio environment (cafe or office) to cause frequent remote
  wakeup events
- no Bluetooth device is connected, so autosuspend is not prohibited
- the Bluetooth interface is opened, so remote wakeup is enabled when
  the device runs into autosuspend

Then I can reproduce the issue within sereval hours each time.

Increasing TRSMRCY or setting USB_QUIRK_RESET doesn't help at all.

Since the remote wakeup capability is super broken, just disable it to
get rid of the troubles. The device can still be autosuspended when
the bluetooth interface is closed, which won't break the device as
remote wakeup is unneeded in this case.

Link: https://bbs.archlinux.org/viewtopic.php?id=308169
Link: https://bbs.bee-link.com/d/7694-gtr9-pro-ai-max-395-usb-issues
Signed-off-by: Rong Zhang <i@rong.moe>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: btusb: Add TP-Link UB600 for Realtek 8761BUV
Nils Helmig [Sat, 30 May 2026 12:39:34 +0000 (14:39 +0200)] 
Bluetooth: btusb: Add TP-Link UB600 for Realtek 8761BUV

Add the vendor/product ID (0x37ad, 0x0600) to usb_device_id table
for Realtek 8761BUV.

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

T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  4 Spd=12   MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=37ad ProdID=0600 Rev= 2.00
S:  Manufacturer=
S:  Product=TP-Link Bluetooth USB Adapter
S:  SerialNumber=ACA7F14FD2A5
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

Signed-off-by: Nils Helmig <nils.helmig@web.de>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: hci_qca: fix NULL pointer dereference in qca_dmp_hdr() for non-serdev...
Zijun Hu [Mon, 1 Jun 2026 11:30:56 +0000 (04:30 -0700)] 
Bluetooth: hci_qca: fix NULL pointer dereference in qca_dmp_hdr() for non-serdev device

hu->serdev is NULL for hci_uart attached via non-serdev paths, but
qca_dmp_hdr() unconditionally dereferences hu->serdev->dev.driver->name,
causing a NULL pointer dereference.

Fix by guarding the dereference with a NULL check and falling back to
"hci_ldisc_qca" for the non-serdev case.

Fixes: 06d3fdfcdf5c ("Bluetooth: hci_qca: Add qcom devcoredump support")
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: hci_qca: fix NULL pointer dereference in qca_setup() for non-serdev device
Zijun Hu [Mon, 1 Jun 2026 11:30:55 +0000 (04:30 -0700)] 
Bluetooth: hci_qca: fix NULL pointer dereference in qca_setup() for non-serdev device

hu->serdev is NULL for hci_uart attached via non-serdev paths, but
qca_setup() unconditionally calls serdev_device_get_drvdata(hu->serdev)
and dereferences the result, causing a NULL pointer dereference.

Fix by guarding the dereference with a NULL check, consistent with the
rest of qca_setup().

Fixes: 22d893eec0d5 ("Bluetooth: hci_qca: Refactor HFP hardware offload capability handling")
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: btusb: Add USB ID 2c4e:0128 for Mercusys MA60XNB
Zenm Chen [Mon, 25 May 2026 16:19:42 +0000 (00:19 +0800)] 
Bluetooth: btusb: Add USB ID 2c4e:0128 for Mercusys MA60XNB

Add USB ID 2c4e:0128 for Mercusys MA60XNB, an RTL8851BU-based
Wi-Fi + Bluetooth adapter.

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

T:  Bus=03 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#=  3 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=2c4e ProdID=0128 Rev= 0.00
S:  Manufacturer=Realtek
S:  Product=802.11ax WLAN Adapter
S:  SerialNumber=00e04c000001
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA
A:  FirstIf#= 0 IfCount= 2 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=1ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=82(I) 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=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
I:* If#= 2 Alt= 0 #EPs= 8 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtw89_8851bu
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Cc: stable@vger.kernel.org # 6.6.x
Signed-off-by: Zenm Chen <zenmchen@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: hci_sync: Add support for HCI_LE_Set_Host_Feature [v2]
Luiz Augusto von Dentz [Tue, 26 May 2026 16:43:42 +0000 (12:43 -0400)] 
Bluetooth: hci_sync: Add support for HCI_LE_Set_Host_Feature [v2]

This adds support for using HCI_LE_Set_Host_Feature [v2] instead of v1
if LL Extented Features is supported and the controller supports the
command.

Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: btmtk: remove extra copy in cmd array init
Jiajia Liu [Wed, 20 May 2026 02:15:00 +0000 (10:15 +0800)] 
Bluetooth: btmtk: remove extra copy in cmd array init

In btmtk_setup_firmware_79xx, the data length indicated by wmt_params.dlen
in the cmd buffer is MTK_SEC_MAP_NEED_SEND_SIZE + 1. Except for the first
byte, the remaining length is MTK_SEC_MAP_NEED_SEND_SIZE. memcpy copied one
more byte to cmd + 1 than the remaining length. Align the length passed to
memcpy to avoid exceeding current section map.

Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: btusb: Add support for Intel Lizard Peak 2 (0x8087:0x0040)
Ravindra [Tue, 12 May 2026 08:34:44 +0000 (14:04 +0530)] 
Bluetooth: btusb: Add support for Intel Lizard Peak 2 (0x8087:0x0040)

Device from /sys/kernel/debug/usb/devices:

T:  Bus=09 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=8087 ProdID=0040 Rev= 0.00
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 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: Ravindra <ravindra@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: btusb: MT7925: Add VID/PID 13d3/3609
luke-yj.chen [Tue, 12 May 2026 06:03:18 +0000 (14:03 +0800)] 
Bluetooth: btusb: MT7925: Add VID/PID 13d3/3609

Add VID 13d3 & PID 3609 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=13d3 ProdID=3609 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: luke-yj.chen <luke-yj.chen@mediatek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: SCO: convert to getsockopt_iter
Breno Leitao [Tue, 12 May 2026 11:12:21 +0000 (04:12 -0700)] 
Bluetooth: SCO: convert to getsockopt_iter

Convert SCO 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()
- Drop the open-coded ptr cursor in BT_CODEC; iter_out advances on
  every copy_to_iter() naturally
- Add linux/uio.h for copy_to_iter()

Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: L2CAP: convert to getsockopt_iter
Breno Leitao [Tue, 12 May 2026 11:12:20 +0000 (04:12 -0700)] 
Bluetooth: L2CAP: convert to getsockopt_iter

Convert L2CAP 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 *sopt
- Use sopt->optlen for buffer length (input)
- Use copy_to_iter() instead of put_user()/copy_to_user()
- Add linux/uio.h for copy_to_iter()

The sockopt_t parameter is named sopt rather than opt to avoid
collision with the existing local u32 opt used by L2CAP_LM. The same
naming is reused for the new u32 helper in l2cap_sock_getsockopt(),
with mtu and mval helpers covering the u16 and u8 cases.

Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: RFCOMM: convert to getsockopt_iter
Breno Leitao [Tue, 12 May 2026 11:12:19 +0000 (04:12 -0700)] 
Bluetooth: RFCOMM: convert to getsockopt_iter

Convert RFCOMM 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 *sopt
- Use sopt->optlen for buffer length (input)
- Use copy_to_iter() instead of put_user()/copy_to_user()
- Add linux/uio.h for copy_to_iter()

The sockopt_t parameter is named sopt rather than opt to avoid
collision with the existing local u32 opt used by RFCOMM_LM.

Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: ISO: convert to getsockopt_iter
Breno Leitao [Tue, 12 May 2026 11:12:18 +0000 (04:12 -0700)] 
Bluetooth: ISO: convert to getsockopt_iter

Convert ISO 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()
- Add linux/uio.h for copy_to_iter()

Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: hci_sock: convert to getsockopt_iter
Breno Leitao [Tue, 12 May 2026 11:12:17 +0000 (04:12 -0700)] 
Bluetooth: hci_sock: convert to getsockopt_iter

Convert HCI 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 *sopt
- Use sopt->optlen for buffer length (input)
- Use copy_to_iter() instead of put_user()/copy_to_user()
- Add linux/uio.h for copy_to_iter()

The sockopt_t parameter is named sopt rather than opt to avoid
collision with the existing local int opt used by HCI_DATA_DIR and
HCI_TIME_STAMP.

Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: hci_sock: write the full optval for getsockopt
Breno Leitao [Tue, 12 May 2026 11:12:16 +0000 (04:12 -0700)] 
Bluetooth: hci_sock: write the full optval for getsockopt

In hci_sock_getsockopt_old(), HCI_DATA_DIR and HCI_TIME_STAMP both store
their value into a local int and then call put_user(opt, optval). Because
optval is the function parameter typed char __user *, put_user sizes the
write from sizeof(*optval), so only the low byte of the int is copied to
userspace.

The matching setsockopt path reads sizeof(int) via copy_safe_from_sockptr,
so userspace passes a 4-byte buffer in both directions but previously got
back only one initialized byte on the read side.

Not sending this through 'net' tree given this bug is mostly invisble,
given opt is 0/1, and the last byte is being properly copied.

With this change, the upcoming translation to .getsockopt_iter becomes
mechanical.

FWIW: This behavior appeared in commit 1da177e4c3f4 ("Linux-2.6.12-rc2").

Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agobluetooth: remove all PCMCIA drivers
Ethan Nelson-Moore [Sun, 3 May 2026 03:31:21 +0000 (20:31 -0700)] 
bluetooth: remove all PCMCIA drivers

PCMCIA is almost completely obsolete (the last computers supporting it
natively were from ~2009), and the general consensus [1] seems to be
that support for it should be gradually removed from the kernel.

In 2023, an initial step of removing all the PCMCIA char drivers was
taken in commit 9b12f050c76f ("char: pcmcia: remove all the drivers"),
and that has not been reverted, so it seems logical to continue this
process by removing more low-hanging fruit.

These three Bluetooth drivers have had no meaningful changes since
their status was discussed in 2022 [2], and are unlikely to have any
remaining users. The latest functional change to any of them was a
patch to bluecard_cs to fix LED blinking behavior in 2017. The other
two drivers have not had any meaningful changes made since 2007. Remove
them.

Note that even with these drivers removed, it is still possible to use
other PCMCIA Bluetooth cards that present themselves as a standard
serial port via serial_cs and hciattach while the serial_cs driver is
still present.

[1] https://lore.kernel.org/all/c5b39544-a4fb-4796-a046-0b9be9853787@app.fastmail.com/
[2] https://lore.kernel.org/all/Y07d7rMvd5++85BJ@owl.dominikbrodowski.net/

Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: btrtl: fix RTL8761B/BU broken LE extended scan
Alexej Sidorenko [Wed, 29 Apr 2026 15:13:43 +0000 (17:13 +0200)] 
Bluetooth: btrtl: fix RTL8761B/BU broken LE extended scan

RTL8761B and RTL8761BU devices report HCI version 5.1 but do not
support the LE Extended Scan commands. This causes repeated failures
with Opcode 0x2042 (LE Set Extended Scan Parameters) returning -EBUSY
when BlueZ attempts extended scanning while a connection is active.

Set HCI_QUIRK_BROKEN_EXT_SCAN for CHIP_ID_8761B to make BlueZ fall
back to legacy LE scan commands which the firmware supports correctly.

Tested with RTL8761BU (USB ID 0bda:a728) where the issue manifested
as continuous 'Opcode 0x2042 failed: -16' errors in dmesg whenever
a BLE connection was active.

Signed-off-by: Alexej Sidorenko <alexej@sidorenko.cz>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 days agoBluetooth: SMP: Use AES-CMAC library API
Eric Biggers [Tue, 21 Apr 2026 23:09:17 +0000 (16:09 -0700)] 
Bluetooth: SMP: Use AES-CMAC library API

Now that AES-CMAC has a library API, convert net/bluetooth/smp.c to use
it instead of the "cmac(aes)" crypto_shash.  Since the library API
doesn't require dynamic memory allocation, we no longer need to pass a
crypto_shash object down the call stack and can simply allocate the
aes_cmac_key on the stack in smp_aes_cmac() (renamed from aes_cmac()).

The result is simpler and faster code that no longer relies on the
error-prone loading of algorithms by name.

Note that the maximum stack usage actually decreases slightly, despite
the expanded AES key being moved to the stack.  This is because the old
code called crypto_shash_tfm_digest(), which allocates 384 bytes on the
stack for a maximally-sized hash descriptor for any algorithm.  The new
code instead declares a 288-byte aes_cmac_key, then calls aes_cmac()
which declares a 32-byte aes_cmac_ctx.  Since 288 + 32 < 384, the
maximum stack usage decreases.  I.e. the entire expanded AES key easily
fits in the space that the generic crypto API was wasting before.

I didn't add zeroization of the aes_cmac_key, since smp_aes_cmac()
already copies the raw key to the stack without zeroizing it.

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
5 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>
5 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>
5 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>
5 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>
5 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>
5 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>
5 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>
5 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>
5 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>
5 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>
5 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>
5 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 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 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 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>