The linux-next integration testing tree https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/atom?h=master 2026-09-08T15:20:43+00:00 2026-09-08T15:20:43+00:00 Mark Brown broonie@kernel.org 2026-09-08T15:20:43+00:00 urn:sha1:3887f7f8a1f1bfac2d41ea59cca2bc66aeb60fdf # Conflicts: # net/bluetooth/hci_sync.c # net/bluetooth/l2cap_core.c 2026-09-04T17:09:43+00:00 Chandrashekar Devegowda chandrashekar.devegowda@intel.com 2026-09-04T00:29:38+00:00 urn:sha1:755cf7adf8dd2d12627cb7de223d35b12228e2f5 Replace the legacy TLV-based coredump with a unified INI-format dump compatible with the iwlwifi decoder so a single decoder can parse coredumps across all Intel BT PCIe controller variants. The dump is emitted via dev_coredumpsg() as structured regions built from firmware-advertised addresses: DRAM monitor buffers (single or MDBGC multi-buffer), SMEM monitor, exception event buffer, DCCM, SDS, SDS IOSF, ECL and dump info metadata. Regions are collected only when firmware advertises a valid address and size, and only collected regions are advertised in regions_mask. Add INTEL_CNVX_TOP_DASH() and INTEL_CNVX_TOP_FLAVOR() helpers to btintel.h for RfIdDash/RfIdFlavor extraction. Assisted-by: Copilot:gemini-3.6-flash Signed-off-by: Chandrashekar Devegowda <chandrashekar.devegowda@intel.com> 2026-09-04T17:09:38+00:00 Chandrashekar Devegowda chandrashekar.devegowda@intel.com 2026-09-04T00:29:37+00:00 urn:sha1:61f725843b5092917184f1305b9d58172b7fd476 Newer Intel BT PCIe variants (Nova Lake SCP2 and PTL FMP2) require three independent DRAM debug (DBGC) buffer pools instead of the single pool used by existing controllers. Factor the per-pool buffer allocation into a common helper and add a multi-DBGC (MDBGC) setup path that allocates three pools using the fragment context format. MDBGC is used when the device reports an MDBGC-capable variant; otherwise the existing single-pool DBGC path is retained. Assisted-by: Copilot:claude-opus-4.7 sparse Signed-off-by: Chandrashekar Devegowda <chandrashekar.devegowda@intel.com> 2026-09-04T14:57:38+00:00 Jiajia Liu liujiajia@kylinos.cn 2026-09-04T08:03:51+00:00 urn:sha1:71729d60938f46745da32f75507b1ad4bf989100 btusb_reset calls usb_autopm_get_interface to resume the device before queuing a reset of it, but never calls the matching usb_autopm_put_interface. usb_queue_reset_device ends up in usb_reset_device(), and since btusb provides no pre_reset/post_reset callbacks the interface is merely unbound and rebound: the interface device object survives this cycle, and so does its PM usage count, which is not cleared when the driver is unbound. As a result every reset permanently leaks a PM usage reference, preventing the interface from being runtime suspended again until it is unbound. Set BTUSB_RESET flag before usb_queue_reset_device so that btusb_disconnect drops the reference. If the flag is already set, drop one reference. Fixes: c9209b269afd ("Bluetooth: btusb: Introduce generic USB reset") Assisted-by: Claude:qwen3.8-max Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn> 2026-09-04T14:57:34+00:00 Jiajia Liu liujiajia@kylinos.cn 2026-09-04T08:03:50+00:00 urn:sha1:a78f54e23804a83c811fa2183f7b0ce614cac8c4 MT7925 on HP Pro Mini 260 sometimes timed out during reloading driver and reset usb device. btusb_suspend is not called again after closing bluetooth interface. usbcore: registered new interface driver btusb Bluetooth: hci0: HW/SW Version: 0x00000000, Build Time: 20260605184935 Bluetooth: hci0: Execution of wmt command timed out Bluetooth: hci0: Failed to send wmt patch dwnld (-110) Bluetooth: hci0: Failed to set up firmware (-110) usb 3-10: reset high-speed USB device number 4 using xhci_hcd Bluetooth: hci0: HW/SW Version: 0x00000000, Build Time: 20260605184935 Bluetooth: hci0: Device setup in 1856545 usecs Bluetooth: hci0: AOSP extensions version v1.00 Bluetooth: hci0: AOSP quality report is supported Bluetooth: MGMT ver 1.23 btusb_mtk_reset calls usb_autopm_get_interface to resume the device before driving the hardware reset, but never calls the matching usb_autopm_put_interface. Every hardware reset therefore leaks a PM usage reference of the interface, preventing the device from being runtime suspended again until it is unbound. Add the BTUSB_RESET flag. It is set before usb_queue_reset_device and is cleared in btusb_disconnect, which drops the reference as well. If the flag is already set when a new reset is requested, drop one reference. Also clear BTMTK_HW_RESET_ACTIVE if usb_autopm_get_interface fails, otherwise no further reset could ever be attempted. Fixes: 25b6d7593a3a ("Bluetooth: btmtk: introduce btmtk reset work") Assisted-by: Claude:qwen3.8-max Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn> 2026-09-04T14:57:29+00:00 Xu Rao raoxu@uniontech.com 2026-09-04T02:54:57+00:00 urn:sha1:b3850074b2c497f419cee5a630a09fd1c150ccb1 The command and ACL RPMsg endpoints store struct btqcomsmd as their callback private data. The receive callbacks dereference btq->hdev without taking an hci_dev reference. The current teardown order frees the hci_dev before destroying the RPMsg endpoints in both the hci_register_dev() error path and the driver remove path. If WCNSS delivers data in that window, the endpoint callback can run with an already freed hci_dev and pass it to the Bluetooth core. For qcom_smd endpoints, rpmsg_destroy_ept() closes the channel and clears the callback under the channel recv_lock. The receive path holds the same lock while invoking the callback, so destroying the endpoints first both prevents new callbacks and serializes with any callback already running. Destroy the command and ACL endpoints before hci_free_dev(). Keep hci_unregister_dev() first during remove so the HCI core stops issuing operations before the transport endpoints are shut down. In the full registration-error cleanup path, return directly after freeing the hci_dev to avoid falling through to the partial-construction labels and destroying the endpoints twice. Fixes: 5052de8deff5 ("soc: qcom: smd: Transition client drivers from smd to rpmsg") Fixes: 9a39a927be01 ("Bluetooth: btqcomsmd: Fix a resource leak in error handling paths in the probe function") Cc: stable@vger.kernel.org Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Xu Rao <raoxu@uniontech.com> 2026-09-04T14:57:25+00:00 Chandrashekar Devegowda chandrashekar.devegowda@intel.com 2026-09-04T00:29:36+00:00 urn:sha1:1cdf710cc2a1358bf472fbba81b6d322f07dd4c3 Two identical definitions of BTINTEL_PCIE_MAGIC_NUM were present in btintel_pcie.c, one indented with spaces and one with a tab. Remove the space-indented duplicate and the surrounding blank lines. Kernel coding style requires tabs for indentation, so keep the tab-indented copy. No functional change. Assisted-by: Copilot:claude-opus-4.7 sparse Fixes: 6ed83047389c ("Bluetooth: btintel_pcie: Setup buffers for firmware traces") Signed-off-by: Chandrashekar Devegowda <chandrashekar.devegowda@intel.com> 2026-09-04T14:57:16+00:00 Ivan Hu ivan.hu@canonical.com 2026-09-04T05:30:07+00:00 urn:sha1:860043e482746e6dc866e7249e109827695f84b2 btmtk_fw_get_filename() constructs the firmware name at runtime, so for the MT7920 variant (dev_id 0x7961 with fw_flavor set) it requests "mediatek/BT_RAM_CODE_MT7961_1a_2_hdr.bin" without ever declaring it via MODULE_FIRMWARE(). Tools that select firmware from module metadata (e.g. "modinfo -F firmware") therefore omit this blob, so request_firmware() fails and Bluetooth does not initialise on MT7920, even though the file is present in linux-firmware. Declare it with MODULE_FIRMWARE(), as the mt76 driver already does for the corresponding MT7920 wifi firmware. Fixes: 1cb63d80fff6 ("Bluetooth: btusb: Add support Mediatek MT7920") Signed-off-by: Ivan Hu <ivan.hu@canonical.com> 2026-09-04T14:57:12+00:00 Andy Chang Andy.Chang@synaptics.com 2026-09-03T12:18:24+00:00 urn:sha1:9aa9447804c7b9c3dae7c2c95ad6a6b73773480d Add support for the Synaptics 4384 Bluetooth controller by adding the corresponding chip IDs. Tested on the VIM3 platform. Verified that the controller initializes successfully and that firmware loading and basic Bluetooth operation work as expected. The VIM3 is a Khadas single-board computer that I used as the host platform for testing the BCM4384 Bluetooth controller. Test log: Bluetooth: hci0: BCM: chip id 206 Bluetooth: hci0: BCM: features 0x0f Bluetooth: hci0: BCM4384B0 Bluetooth: hci0: BCM4384B0 (002.001.025) build 0000 Bluetooth: hci0: BCM4384B0 'brcm/BCM4384B0.hcd' Patch Bluetooth: hci0: BCM: features 0x0f Bluetooth: hci0: BCM4384B0 AP6684P CN iPA [Version: 1030.1021] Bluetooth: hci0: BCM4384B0 (002.001.025) build 1021 Bluetooth: hci0: BCM: Using default device address (43:84:b0:00:76:93) Signed-off-by: Andy Chang <Andy.Chang@synaptics.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by: Linus Walleij <linusw@kernel.org> 2026-09-03T19:32:59+00:00 Catherine L catherine.l@intel.com 2026-09-02T19:00:37+00:00 urn:sha1:fe87a0e402c503c20f7063c7ac49feaa6e2edcbd $ lsusb Bus 003 Device 003: ID 8087:0043 Intel Corp. $ cat /sys/kernel/debug/usb/devices T: Bus=03 Lev=01 Prnt=01 Port=09 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=8087 ProdID=0043 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 Signed-off-by: Catherine L <catherine.l@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>