summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-04-13dt-bindings: mips: Add Mobileye EyeQ6Lplus SoCBenoît Monin
Add an entry to the mobileye bindings for the EyeQ6Lplus which is part of the EyeQ family of system-on-chip. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Benoît Monin <benoit.monin@bootlin.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-04-13Bluetooth: hci_qca: Fix missing wakeup during SSR memdump handlingShuai Zhang
When a Bluetooth controller encounters a coredump, it triggers the Subsystem Restart (SSR) mechanism. The controller first reports the coredump data and, once the upload is complete, sends a hw_error event. The host relies on this event to proceed with subsequent recovery actions. If the host has not finished processing the coredump data when the hw_error event is received, it waits until either the processing is complete or the 8-second timeout expires before handling the event. The current implementation clears QCA_MEMDUMP_COLLECTION using clear_bit(), which does not wake up waiters sleeping in wait_on_bit_timeout(). As a result, the waiting thread may remain blocked until the timeout expires even if the coredump collection has already completed. Fix this by clearing QCA_MEMDUMP_COLLECTION with clear_and_wake_up_bit(), which also wakes up the waiting thread and allows the hw_error handling to proceed immediately. Test case: - Trigger a controller coredump using: hcitool cmd 0x3f 0c 26 - Tested on QCA6390. - Capture HCI logs using btmon. - Verify that the delay between receiving the hw_error event and initiating the power-off sequence is reduced compared to the timeout-based behavior. Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btintel_pcie: use strscpy to copy plain stringsThorsten Blum
Use strscpy() instead of snprintf() to copy plain strings with no format specifiers. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: hci_event: fix potential UAF in SSP passkey handlersShuvam Pandey
hci_conn lookup and field access must be covered by hdev lock in hci_user_passkey_notify_evt() and hci_keypress_notify_evt(), otherwise the connection can be freed concurrently. Extend the hci_dev_lock critical section to cover all conn usage in both handlers. Keep the existing keypress notification behavior unchanged by routing the early exits through a common unlock path. Fixes: 92a25256f142 ("Bluetooth: mgmt: Implement support for passkey notification") Cc: stable@vger.kernel.org Signed-off-by: Shuvam Pandey <shuvampandey1@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: hci.h: Avoid a couple -Wflex-array-member-not-at-end warningsGustavo A. R. Silva
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are getting ready to enable it, globally. struct hci_std_codecs and struct hci_std_codecs_v2 are flexible structures, this is structures that contain a flexible-array member (__u8 codec[]; and struct hci_std_codec_v2 codec[];, correspondingly.) Since struct hci_rp_read_local_supported_codecs and struct hci_rp_read_local_supported_codecs_v2 are defined by hardware, we create the new struct hci_std_codecs_hdr and struct hci_std_codecs_v2_hdr types, and use them to replace the object types causing trouble in struct hci_rp_read_local_supported_codecs and struct hci_rp_read_local_supported_codecs_v2, namely struct hci_std_codecs std_codecs; and struct hci_std_codecs_v2_hdr std_codecs;. Also, once -fms-extensions is enabled, we can use transparent struct members in both struct hci_std_codecs and struct hci_std_codecs_v2_hdr. Notice that the newly created types does not contain the flex-array member `codec`, which is the object causing the -Wfamnae warnings. After these changes, the size of struct hci_rp_read_local_supported_codecs and struct hci_rp_read_local_supported_codecs_v2, along with their member's offsets remain the same, hence the memory layouts don't change: Before changes: struct hci_rp_read_local_supported_codecs { __u8 status; /* 0 1 */ struct hci_std_codecs std_codecs; /* 1 1 */ struct hci_vnd_codecs vnd_codecs; /* 2 1 */ /* size: 3, cachelines: 1, members: 3 */ /* last cacheline: 3 bytes */ } __attribute__((__packed__)); struct hci_rp_read_local_supported_codecs_v2 { __u8 status; /* 0 1 */ struct hci_std_codecs_v2 std_codecs; /* 1 1 */ struct hci_vnd_codecs_v2 vendor_codecs; /* 2 1 */ /* size: 3, cachelines: 1, members: 3 */ /* last cacheline: 3 bytes */ } __attribute__((__packed__)); After changes: struct hci_rp_read_local_supported_codecs { __u8 status; /* 0 1 */ struct hci_std_codecs_hdr std_codecs; /* 1 1 */ struct hci_vnd_codecs vnd_codecs; /* 2 1 */ /* size: 3, cachelines: 1, members: 3 */ /* last cacheline: 3 bytes */ } __attribute__((__packed__)); struct hci_rp_read_local_supported_codecs_v2 { __u8 status; /* 0 1 */ struct hci_std_codecs_v2_hdr std_codecs; /* 1 1 */ struct hci_vnd_codecs_v2 vendor_codecs; /* 2 1 */ /* size: 3, cachelines: 1, members: 3 */ /* last cacheline: 3 bytes */ } __attribute__((__packed__)); With these changes fix the following warnings: include/net/bluetooth/hci.h:1490:31: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] include/net/bluetooth/hci.h:1525:34: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: SCO: check for codecs->num_codecs == 1 before assigning to ↵Stefan Metzmacher
sco_pi(sk)->codec copy_struct_from_sockptr() fill 'buffer' in sco_sock_setsockopt() with zeros, so there's no real problem. But it actually looks strange to do this, without checking all of codecs->codecs[0] really comes from userspace: sco_pi(sk)->codec = codecs->codecs[0]; As only optlen < sizeof(struct bt_codecs) is checked and codecs->num_codecs is not checked against != 1, but only <= 1, and the space for the additional struct bt_codec is not checked. Note I don't understand bluetooth and I didn't do any runtime tests with this! I just found it when debugging a problem in copy_struct_from_sockptr(). I just added this to check the size is as expected: BUILD_BUG_ON(struct_size(codecs, codecs, 0) != 1); BUILD_BUG_ON(struct_size(codecs, codecs, 1) != 8); And made sure it still compiles using this: make CF=-D__CHECK_ENDIAN__ W=1ce C=1 net/bluetooth/sco.o Fixes: 3e643e4efa1e ("Bluetooth: Improve setsockopt() handling of malformed user input") Cc: Michal Luczaj <mhal@rbox.co> Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: David Wei <dw@davidwei.uk> Cc: linux-bluetooth@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Stefan Metzmacher <metze@samba.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btintel_pcie: Align shared DMA memory to 128 bytesKiran K
Align each descriptor/index/context region to 128 bytes before calculating the total DMA pool size. This ensures the memory layout shared with firmware meets the 128-byte alignment requirement. The DMA pool alignment is also set to 128 bytes to match the firmware expectation for all shared structures. Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rspDudu Lu
l2cap_ecred_reconf_rsp() calls l2cap_chan_del() without holding l2cap_chan_lock(). Every other l2cap_chan_del() caller in the file acquires the lock first. A remote BLE device can send a crafted L2CAP ECRED reconfiguration response to corrupt the channel list while another thread is iterating it. Add l2cap_chan_hold() and l2cap_chan_lock() before l2cap_chan_del(), and l2cap_chan_unlock() and l2cap_chan_put() after, matching the pattern used in l2cap_ecred_conn_rsp() and l2cap_conn_del(). Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Dudu Lu <phx0fer@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: hci_ll: Enable BROKEN_ENHANCED_SETUP_SYNC_CONN for WL183xStefano Radaelli
TI WL183x controllers advertise support for the HCI Enhanced Setup Synchronous Connection command, but SCO setup fails when the enhanced path is used. The only working configuration is to fall back to the legacy HCI Setup Synchronous Connection (0x0028). This matches the scenario described in commit 05abad857277 ("Bluetooth: HCI: Add HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN quirk"). Enable HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN automatically for devices compatible with: - ti,wl1831-st - ti,wl1835-st - ti,wl1837-st Signed-off-by: Stefano Radaelli <stefano.r@variscite.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btusb: MediaTek MT7922: Add VID 0489 & PID e11dKamiyama Chiaki
Add VID 0489 & PID e11d for MediaTek MT7922 USB Bluetooth chip. Found in Dynabook GA/ZY (W6GAZY5RCL). 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=03 Cnt=02 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e11d Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Kamiyama Chiaki <nercone@nercone.dev> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btmtk: hide unused btmtk_mt6639_devs[] arrayArnd Bergmann
When USB support is disabled, the array is not referenced anywhere, causing a warning: drivers/bluetooth/btmtk.c:35:3: error: 'btmtk_mt6639_devs' defined but not used [-Werror=unused-const-variable=] 35 | } btmtk_mt6639_devs[] = { | ^~~~~~~~~~~~~~~~~ Move it into the #ifdef block. Fixes: 28b7c5a6db74 ("Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btusb: Add MT7927 ID for ASUS X870E / ProArt X870E-CreatorJavier Tia
Add USB device ID 13d3:3588 (IMC Networks/Azurewave) for the MediaTek MT7927 (Filogic 380) Bluetooth interface found on the ASUS ROG STRIX X870E-E GAMING WIFI and ASUS ProArt X870E-Creator WiFi motherboards. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3588 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#= 2 Alt= 0 #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 Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096 Link: https://github.com/openwrt/mt76/issues/927 Signed-off-by: Javier Tia <floss@jetm.me> Tested-by: Jose Tiburcio Ribeiro Netto <jnetto@mineiro.io> Tested-by: Ivan Lubnin <lubnin.ivan@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btusb: Add MT7927 ID for TP-Link Archer TBE550EJavier Tia
Add USB device ID 0489:e116 (Foxconn/Hon Hai) for the MediaTek MT7927 (Filogic 380) Bluetooth interface found on the TP-Link Archer TBE550E PCIe adapter. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e116 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 ... I:* If#= 2 Alt= 0 #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 Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096 Link: https://github.com/openwrt/mt76/issues/927 Signed-off-by: Javier Tia <floss@jetm.me> Tested-by: Thibaut FRANCOIS <tibo@humeurlibre.fr> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btusb: Add MT7927 ID for MSI X870E Ace MaxJavier Tia
Add USB device ID 0489:e110 (Foxconn/Hon Hai) for the MediaTek MT7927 (Filogic 380) Bluetooth interface found on the MSI X870E Ace Max motherboard. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e110 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 ... I:* If#= 2 Alt= 0 #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 Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096 Link: https://github.com/openwrt/mt76/issues/927 Signed-off-by: Javier Tia <floss@jetm.me> Tested-by: Nitin Gurram <nitin.reddy88@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btusb: Add MT7927 ID for Gigabyte Z790 AORUS MASTER XJavier Tia
Add USB device ID 0489:e10f (Foxconn/Hon Hai) for the MediaTek MT7927 (Filogic 380) Bluetooth interface found on the Gigabyte Z790 AORUS MASTER X motherboard. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e10f 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 ... I:* If#= 2 Alt= 0 #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 Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096 Link: https://github.com/openwrt/mt76/issues/927 Signed-off-by: Javier Tia <floss@jetm.me> Tested-by: Chapuis Dario <chapuisdario4@gmail.com> Tested-by: Evgeny Kapusta <3193631@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btusb: Add MT7927 ID for Lenovo Legion Pro 7 16ARX9Javier Tia
Add USB device ID 0489:e0fa (Foxconn/Hon Hai) for the MediaTek MT7927 (Filogic 380) Bluetooth interface found on the Lenovo Legion Pro 7 16ARX9 laptop. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e0fa 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 ... I:* If#= 2 Alt= 0 #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 Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096 Link: https://github.com/openwrt/mt76/issues/927 Signed-off-by: Javier Tia <floss@jetm.me> Tested-by: Llewellyn Curran <melinko2003@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btusb: Add MT7927 ID for ASUS ROG Crosshair X870E HeroJavier Tia
Add USB device ID 0489:e13a (Foxconn/Hon Hai) for the MediaTek MT7927 (Filogic 380) Bluetooth interface found on the ASUS ROG Crosshair X870E Hero WiFi motherboard. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e13a 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 ... I:* If#= 2 Alt= 0 #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 Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096 Link: https://github.com/openwrt/mt76/issues/927 Signed-off-by: Javier Tia <floss@jetm.me> Tested-by: Jose Tiburcio Ribeiro Netto <jnetto@mineiro.io> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btmtk: fix ISO interface setup for single alt settingJavier Tia
Some MT6639 Bluetooth USB interfaces (e.g. IMC Networks 13d3:3588 on ASUS ROG STRIX X870E-E and ProArt X870E-Creator boards) expose only a single alternate setting (alt 0) on the ISO interface. The driver unconditionally requests alt setting 1, which fails with EINVAL on these devices, causing a ~20 second initialization delay and no LE audio support. Check the number of available alternate settings before selecting one. If only alt 0 exists, use it; otherwise request alt 1 as before. Closes: https://github.com/jetm/mediatek-mt7927-dkms/pull/39 Signed-off-by: Javier Tia <floss@jetm.me> Reported-by: Ryan Gilbert <xelnaga@gmail.com> Tested-by: Ryan Gilbert <xelnaga@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth supportJavier Tia
The MediaTek MT7927 (Filogic 380) combo WiFi 7 + BT 5.4 module uses hardware variant 0x6639 for its Bluetooth subsystem. Without this patch, the chip fails with "Unsupported hardware variant (00006639)" or hangs during firmware download. Three changes are needed to support MT6639: 1. CHIPID workaround: On some boards the BT USB MMIO register reads 0x0000 for dev_id, causing the driver to skip the 0x6639 init path. Force dev_id to 0x6639 only when the USB VID/PID matches a known MT6639 device, avoiding misdetection if a future chip also reads zero. This follows the WiFi-side pattern that uses PCI device IDs to scope the same workaround. 2. Firmware naming: MT6639 uses firmware version prefix "2_1" instead of "1_1" used by MT7925 and other variants. The firmware path is mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin, using the mt7927 directory to match the WiFi firmware convention. The filename will likely change to use MT7927 once MediaTek submits a dedicated Linux firmware binary. 3. Section filtering: The MT6639 firmware binary contains 9 sections, but only sections with (dlmodecrctype & 0xff) == 0x01 are Bluetooth-related. Sending the remaining WiFi/other sections causes an irreversible BT subsystem hang requiring a full power cycle. This matches the Windows driver behavior observed via USB captures. Also add 0x6639 to the reset register (CONNV3) and firmware setup switch cases alongside the existing 0x7925 handling. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096 Link: https://github.com/openwrt/mt76/issues/927 Reported-by: Ryan Gilbert <xelnaga@gmail.com> Signed-off-by: Javier Tia <floss@jetm.me> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFERPauli Virtanen
When protocol sets HCI_PROTO_DEFER, hci_conn_request_evt() calls hci_connect_cfm(conn) without hdev->lock. Generally hci_connect_cfm() assumes it is held, and if conn is deleted concurrently -> UAF. Only SCO and ISO set HCI_PROTO_DEFER and only for defer setup listen, and HCI_EV_CONN_REQUEST is not generated for ISO. In the non-deferred listening socket code paths, hci_connect_cfm(conn) is called with hdev->lock held. Fix by holding the lock. Fixes: 70c464256310 ("Bluetooth: Refactor connection request handling") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btmtk: refactor endpoint lookupJohan Hovold
Use the common USB helper for looking up bulk and interrupt endpoints instead of open coding. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btusb: refactor endpoint lookupJohan Hovold
Use the common USB helper for looking up bulk and interrupt endpoints instead of open coding. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: hci_ldisc: Clear HCI_UART_PROTO_INIT on errorJonathan Rissanen
When hci_register_dev() fails in hci_uart_register_dev() HCI_UART_PROTO_INIT is not cleared before calling hu->proto->close(hu) and setting hu->hdev to NULL. This means incoming UART data will reach the protocol-specific recv handler in hci_uart_tty_receive() after resources are freed. Clear HCI_UART_PROTO_INIT with a write lock before calling hu->proto->close() and setting hu->hdev to NULL. The write lock ensures all active readers have completed and no new reader can enter the protocol recv path before resources are freed. This allows the protocol-specific recv functions to remove the "HCI_UART_REGISTERED" guard without risking a null pointer dereference if hci_register_dev() fails. Fixes: 5df5dafc171b ("Bluetooth: hci_uart: Fix another race during initialization") Signed-off-by: Jonathan Rissanen <jonathan.rissanen@axis.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: hci_sync: make hci_cmd_sync_run_once return -EEXIST if existsPauli Virtanen
hci_cmd_sync_run_once() needs to indicate whether a queue item was added, so caller can know if callbacks are called, so it can avoid leaking resources. Change the function to return -EEXIST if queue item already exists. Modify all callsites vs. the changes. The only callsite is hci_abort_conn(). Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: hci_qca: disable power control for WCN7850 when bt_en is not definedShuai Zhang
On platforms using an M.2 slot with both UART and USB support, bt_en is pulled high by hardware. In this case, software-based power control should be disabled. The current platforms are Lemans-EVK and Monaco-EVK. Add QCA_WCN7850 to the existing condition so that power_ctrl_enabled is cleared when bt_en is not software-controlled (or absent), aligning its behavior with WCN6750 and WCN6855 Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13bluetooth: btusb: Fix whitespace in btusb.cLukas Kraft
Replace single space with tab and insert blank line after declaration, according to checkpatch Signed-off-by: Lukas Kraft <rebootrequired42@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: L2CAP: Fix printing wrong information if SDU length exceeds MTULuiz Augusto von Dentz
The code was printing skb->len and sdu_len in the places where it should be sdu_len and chan->imtu respectively to match the if conditions. Link: https://lore.kernel.org/linux-bluetooth/20260315132013.75ab40c5@kernel.org/T/#m1418f9c82eeff8510c1beaa21cf53af20db96c06 Fixes: e1d9a6688986 ("Bluetooth: LE L2CAP: Disconnect if received packet's SDU exceeds IMTU") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
2026-04-13Merge branch 'decouple-receive-and-transmit-enablement-in-team-driver'Paolo Abeni
Marc Harvey says: ==================== Decouple receive and transmit enablement in team driver Allow independent control over receive and transmit enablement states for aggregated ports in the team driver. The motivation is that IEE 802.3ad LACP "independent control" can't be implemented for the team driver currently. This was added to the bonding driver in commit 240fd405528b ("bonding: Add independent control state machine"). This series also has a few patches that add tests to show that the old coupled enablement still works and that the new decoupled enablement works as intended (4, 5, and 10). There are three patches with small fixes as well, with the goal of making the final decoupling patch clearer (1, 2, and 3). Signed-off-by: Marc Harvey <marcharvey@google.com> ==================== Link: https://patch.msgid.link/20260409-teaming-driver-internal-v7-0-f47e7589685d@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-13selftests: net: Add tests for team driver decoupled tx and rx controlMarc Harvey
Use ping and tcpdump to verify that independent rx and tx enablement of team driver member interfaces works as intended. Signed-off-by: Marc Harvey <marcharvey@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260409-teaming-driver-internal-v7-10-f47e7589685d@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-13net: team: Add new tx_enabled team port optionMarc Harvey
This option allows independent control over tx enablement without affecting rx enablement. Like the rx_enabled option, this also implicitly affects the enabled option. If this option is not used, then the enabled option will continue to behave as it did before. Tested in a follow-up patch with a new selftest. Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Marc Harvey <marcharvey@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260409-teaming-driver-internal-v7-9-f47e7589685d@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-13net: team: Add new rx_enabled team port optionMarc Harvey
Allow independent control over rx enablement via the rx_enabled option without affecting tx enablement. This affects the normal enabled option since a port is only considered enabled if both tx and rx are enabled. If this option is not used, then the enabled option will continue to behave exactly as it did before. Tested in a follow-up patch with a new selftest. Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Marc Harvey <marcharvey@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260409-teaming-driver-internal-v7-8-f47e7589685d@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-13net: team: Track rx enablement separately from tx enablementMarc Harvey
Separate the rx and tx enablement/disablement into different functions so that it is easier to interact with them independently later. Although this patch changes receive and transmit paths, the actual behavior of the teaming driver should remain unchanged, since there is no option introduced yet to change rx or tx enablement independently. Those options will be added in follow-up patches. Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Marc Harvey <marcharvey@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260409-teaming-driver-internal-v7-7-f47e7589685d@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-13net: team: Rename enablement functions and struct members to txMarc Harvey
Add no functional changes, but rename enablement functions, variables etc. that are used in teaming driver transmit decisions. Since rx and tx enablement are still coupled, some of the variables renamed in this patch are still used for the rx path, but that will change in a follow-up patch. Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Marc Harvey <marcharvey@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260409-teaming-driver-internal-v7-6-f47e7589685d@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-13selftests: net: Add test for enablement of ports with teamdMarc Harvey
There are no tests that verify enablement and disablement of team driver ports with teamd. This should work even with changes to the enablement option, so it is important to test. This test sets up an active-backup network configuration across two network namespaces, and tries to send traffic while changing which link is the active one. Also increase the team test timeout to 300 seconds, because gracefully killing teamd can take 30 seconds for each instance. Signed-off-by: Marc Harvey <marcharvey@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260409-teaming-driver-internal-v7-5-f47e7589685d@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-13selftests: net: Add tests for failover of team-aggregated portsMarc Harvey
There are currently no kernel tests that verify the effect of setting the enabled team driver option. In a followup patch, there will be changes to this option, so it will be important to make sure it still behaves as it does now. The test verifies that tcp continues to work across two different team devices in separate network namespaces, even when member links are manually disabled. Signed-off-by: Marc Harvey <marcharvey@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260409-teaming-driver-internal-v7-4-f47e7589685d@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-13net: team: Rename port_disabled team mode op to port_tx_disabledMarc Harvey
This team mode op is only used by the load balance mode, and it only uses it in the tx path. Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Marc Harvey <marcharvey@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260409-teaming-driver-internal-v7-3-f47e7589685d@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-13net: team: Remove unused team_mode_op, port_enabledMarc Harvey
This team_mode_op wasn't used by any of the team modes, so remove it. Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Marc Harvey <marcharvey@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260409-teaming-driver-internal-v7-2-f47e7589685d@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-13net: team: Annotate reads and writes for mixed lock accessed valuesMarc Harvey
The team_port's "index" and the team's "en_port_count" are read in the hot transmit path, but are only written to when holding the rtnl lock. Use READ_ONCE() for all lockless reads of these values, and use WRITE_ONCE() for all writes. Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Marc Harvey <marcharvey@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260409-teaming-driver-internal-v7-1-f47e7589685d@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-13drm/i915/mst: Remove redundant has_pch_encoder=false assignmentVille Syrjälä
The entire crtc_state is zeroed by default, there is no need to fiddle with crtc_state->has_pch_encoder unless we are actually dealing with a port on the PCH (which we never are for DP MST). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409100841.1907-2-ville.syrjala@linux.intel.com Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
2026-04-13drm/i915/mst: Call intel_pfit_compute_config() for sharpness filterVille Syrjälä
The sharpness filter property is on the CRTC (as opposed to the connector) so the expectation is that it's usable on all output types. Since the sharpness filter is now fully integrateds into the normal pfit code intel_pfit_compute_config() must be called from the encoder .compute_config() on all relevant output types. Sharpness filter is supported on LNL+ so only HDMI and DP SST/MST outputs are actually relevant. I already took care of HDMI and DP SST, but (as usual) forgot about DP MST. Add the missing intel_pfit_compute_config() call to make the sharpness filter operational on DP MST as well. Cc: Nemesa Garg <nemesa.garg@intel.com> Fixes: d4686f34bbeb ("drm/i915/pfit: Call intel_pfit_compute_config() unconditionally on (e)DP/HDMI") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409100841.1907-1-ville.syrjala@linux.intel.com Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
2026-04-13ipmi:ssif: Remove unnecessary indentionCorey Minyard
A section was in {} that didn't need to be, move the variable definition to the top and set th eindentino properly. Signed-off-by: Corey Minyard <corey@minyard.net>
2026-04-13Merge branch 'slab/for-7.1/misc' into slab/for-nextVlastimil Babka (SUSE)
Merge misc slab changes that are not related to sheaves. Various improvements for sysfs, debugging and testing.
2026-04-13platform/x86: hp-wmi: add Omen 14-fb0xxx (board 8C58) supportShaun Varghese
Board 8C58 (HP Omen Transcend Gaming Laptop 14-fb0xxx) appears to use the same thermal profile handling as other supported Omen systems, including board 8E41. Add it to omen_thermal_profile_boards so hp-wmi can expose the firmware thermal profiles through the platform_profile interface. Tested on Omen 14-fb0xxx: the profile handler exposes cool, balanced, and performance modes, and selecting performance increases sustained CPU package power under load. Signed-off-by: Shaun Varghese <shaunvarghese43@gmail.com> Link: https://patch.msgid.link/20260410174651.1424000-1-shaunvarghese43@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-04-13platform/wmi: Replace .no_notify_data with .min_event_sizeArmin Wolf
WMI drivers using the buffer-based WMI API are expected to reject undersized event payloads. Extend the WMI driver core to allow such drivers to specify their minimum supported event payload size. Also remove the now redundant .no_notify_data field. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260406203237.2970-7-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-04-13platform/wmi: Extend wmidev_query_block() to reject undersized dataArmin Wolf
WMI drivers using the buffer-based WMI API are expected to reject undersized query results. Extend wmidev_query_block() to enable the WMI driver core to perform this size check internally. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260406203237.2970-6-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-04-13platform/wmi: Extend wmidev_invoke_method() to reject undersized dataArmin Wolf
WMI drivers using the buffer-based WMI API are expected to reject undersized method return values. Extend wmidev_invoke_method() to enable the WMI driver core to perform this size check internally. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260406203237.2970-5-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-04-13platform/wmi: Prepare to reject undersized unmarshalling resultsArmin Wolf
Driver using the buffer-based WMI API usually reject buffers resulting from WMI method calls or block queries if they contain not enough data. Prepare the WMI core for assisting in this by automatically rejecting undersized unmarshalling results. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260406203237.2970-4-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-04-13platform/wmi: Convert drivers to use wmidev_invoke_procedure()Armin Wolf
Convert users of wmidev_invoke_method() to wmidev_invoke_procedure() where applicable to prepare for future changes. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260406203237.2970-3-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-04-13platform/wmi: Add wmidev_invoke_procedure()Armin Wolf
Some WMI methods return no values, so the whole postprocessing of the result data is not needed for them. Add a special function for calling such WMI methods to prepare for future changes of the main wmidev_invoke_method() function. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260406203237.2970-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-04-13platform/x86: int3472: Add support for GPIO type 0x02 (IR flood LED)Marco Nenciarini
Add support for GPIO type 0x02, which controls an IR flood LED used for face authentication on some laptops (e.g. Dell Pro Max 16 Premium). Without this patch, the kernel logs "GPIO type 0x02 unknown; the sensor may not work" and IR sensors paired with a flood LED cannot function. The flood LED is registered through the LED subsystem like the existing privacy LED, including a lookup entry to allow future consumer drivers to find and control it via led_get(). To support multiple LEDs per INT3472 device, convert the single led struct member to an array with a counter. Signed-off-by: Marco Nenciarini <mnencia@kcore.it> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Link: https://patch.msgid.link/20260401203638.1601661-5-mnencia@kcore.it Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-13 22:35:57 +0000