From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4CF042BCF46 for ; Sat, 22 Aug 2026 14:12:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787407943; cv=none; b=Q1tD3bbdA+8tXHBmW1QHv60Reukjaac0uIeuBkXU4/xPkOfDTcR27l7ApZJsB0zy2h1JLz+Yk/IVzKj71/CQPLvOpweikDKJNXqLNMlNCeqTNTQ9jhRSZQxTvHE6mN+JupwHe6l+HORELlqMrzaNzdFgdQ8WeIJNwdJD9Yb2PY0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787407943; c=relaxed/simple; bh=xDOQfxPkBNbbsOuEBrPL5Ba9mbUc5B/HErZUMyRz/Dw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=bjMnz1EfyZt/z/qOJBUWaE0EWnmEe/jwMZhyziVMjoPYHmdmz9fxXcuJWz6MlcYaALiB/SWOwhiWRvu2rlGJ60VBlPRRETWV054CSxpcSCJNk7kHDNddmNUURqMBmaySzSlO1bzT3taq68wRyptlfWHe8g/uLYlEkWHkgGn1fs4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=IyjMao6I; arc=none smtp.client-ip=209.85.218.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="IyjMao6I" Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-c20ce3c118aso377112866b.0 for ; Sat, 22 Aug 2026 07:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787407940; x=1788012740; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=lzl656Kc/WnTsoNCqMH4D8QoNvmFwpgPRUVtnsAcOfI=; b=IyjMao6IN/foTY4AFQO043JCr2my550MMW02KzYaTRG70YyNLhzc1qIOz+OHad50YD cN0Ue8IqYcd32V6Mmb7z9UbyXHe/i+ed9waOemhE/0eE4hikHo4CjE5Q6lx26Of7rmXZ QwtYsLlyJM7vr2rglgJeAsnfZa9FgIBQ3u2lZVFRubdGauMzweLrJUTs2FQFQX5MtgNe 6Yer+V5+hVCC/2USKz3HZduYBAMIVkvIH70ZAuWa/o06RTg2l2uhqfC1y2d9yvpWEYWx Ot62ykw5VCeBuunrA39tvs5dH0v8y5oAS6A5aoGOLc6145a2akmbHtuonRYq86j+Ajrx Mu0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787407940; x=1788012740; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=lzl656Kc/WnTsoNCqMH4D8QoNvmFwpgPRUVtnsAcOfI=; b=pYZgkiRsM9GFtAOnEy6dG4IHf/5IQ7+3RR7VOBsrp4UjcamoYUIjqCsKU6YuXAIaOy Hl9eoFt10qu+pdTSMGrzn2JU6Az0TnMLc/7Egz0VS6hyf+QjqcoCzp54yIlk+hxNzk5l lKAx1a3jUPGCwxOTnFjfvQ6iP/DO7oDrxEtLgXLr5n5f8nqXnUuUWqOumAeje2/AOEj2 3Is7zoh2AzfxLsqAw+U2BcmmotKO0oL0vsJSKHYydTCDmaL1g46OkHLirHHJGlnjUDJk GktUlkuGdMXGXnaN8lIavRm/sB6rewx9zbB9Dpet5DmIZAzHbm/Gv49IN/9umg2cucQO kYJg== X-Forwarded-Encrypted: i=1; AHgh+Rq8ExQwOO2OgWZaqejQ2ZveardhlEPfNQUnNxQb8Lsiksiz0VV9S3TkVUvd5mNzIOQlPN9TlBmcs4xn0l8=@vger.kernel.org X-Gm-Message-State: AFuF++n6e7xhaFiyep/ZKK3Qql7hBSMbL60BVVRido5RNJxQrdd9yrGk 8eFcNWKgmAnm0sIzAMl2saK/XIkP7Q30mCuwgiBmIydEYmtQFfhY0RVI X-Gm-Gg: AR+sD122kUG+uxjd/zNpK8b3Cb/zlH5XGvauJjecX2moMoAixrzVtyym5yJ0rp/FjK9 rK8TwTW327vvsQl0V77Imnn/thUp8/d8/BFAyNQpwUsggACGGhStoAxHOjwoO3Q0RhaFhLk4A7K 5eMX4SNndGAWvDP1vzOx7HkWq/EA1C3pJJteZnEpceNjcjpDqM39b/zDct+9sH4ad0734HJhHLY I0DKBh5waAaOHT+P1KMZ8sqNkQfXAggHun/fmYtw3CiRVCGYtwyGGXUQvz+SsOdysykSlgpjn6H I2ZG5HjfzT7dQKiYimbS/bG6mNjGFxANi+C/RCl6UGBtsOj7sXzPuRZmZNfKaFwFHySa3HGMjMo ogxSAjKjK8zMg8oDTlTdW/5MuDyA8sy820TvPGGI55cpM85HO15quTxHlQx0gT8TrIiQsMHzoaW P8e6C7YhgAH40Y6Ma4NEtSnYRLT97Ejszexcrtsm4cs7B8hMmYjdCplTJULFlZcGkNUAmvEU29s EOkY95VBVxM2dAcHIvb7GZq9jcFCul0bA10qT56HMQdLBvckxS7yAcqehyTPhu8cqgitXVrlWdT PgwGKWMPdxoYMQu85rc= X-Received: by 2002:a17:907:a88b:b0:c1c:2218:f317 with SMTP id a640c23a62f3a-c244d45ad2amr1712327066b.2.1787407940275; Sat, 22 Aug 2026 07:12:20 -0700 (PDT) Received: from bobo (d163-170.icpnet.pl. [109.173.163.170]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2496734bfcsm340625266b.43.2026.08.22.07.12.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Aug 2026 07:12:19 -0700 (PDT) From: Kamil Serwus To: linux-bluetooth@vger.kernel.org Cc: Alexej Sidorenko , Luiz Augusto von Dentz , Marcel Holtmann , regressions@lists.linux.dev, linux-kernel@vger.kernel.org, Kamil Serwus Subject: [RFC PATCH 0/2] Bluetooth: detect broken extended scan instead of guessing by chip id Date: Sat, 22 Aug 2026 16:11:13 +0200 Message-ID: <20260822141115.58815-1-kserwus@gmail.com> X-Mailer: git-send-email 2.55.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi, commit 5ead2063611ae5 ("Bluetooth: btrtl: fix RTL8761B/BU broken LE extended scan"), which landed in v7.2, regresses a different RTL8761BU dongle than the one it was written for. This series reports that and proposes a way out that should not need a new patch per dongle. The regression -------------- Hardware here is USB 0bda:8771, firmware 0xdfc6d922, ROM lmp_subver 0x8761 - an RTL8761BU, so CHIP_ID_8761B, so it gets the new quirk, which makes use_ext_scan() false and moves scanning from LE Set Extended Scan Enable (0x2042) to the legacy LE Set Scan Enable (0x200c). This dongle is the opposite of the one the quirk was written for: extended scan works flawlessly, but the firmware stops answering the legacy scan-disable command about ten seconds into any scan: Bluetooth: hci0: command 0x200c tx timeout Bluetooth: hci0: Opcode 0x200c failed: -110 Bluetooth: hci0: Unable to disable scanning: -110 Bluetooth: hci0: disable scanning failed: -110 Bluetooth: hci0: Resetting usb device. Bluetooth: hci0: start background scanning failed: -110 usb 3-1: reset full-speed USB device number 2 using xhci_hcd btusb resets the device, it re-enumerates (hci0 -> hci1 -> hci2 -> ...) and every connected BLE device is dropped. With a Bluetooth keyboard and trackball that leaves the machine with no input at all. v7.1.7 drives the same dongle, with byte-identical linux-firmware and identical CONFIG_BT_HCIBTUSB_*, for eleven hours and nine BLE HID connects without a single scan error. Why not just narrow the quirk ----------------------------- Nothing available at setup time separates the two dongles: - same project_id (CHIP_ID_8761B) - same ic_id_table entry, IC_INFO(RTL_ROM_LMP_8761A, 0xb, 0xa, HCI_USB) - same firmware file, rtl_bt/rtl8761bu_fw.bin - both advertise the extended scan commands in commands[37] They differ only by USB id, which btrtl_set_quirks() cannot see. driver_info cannot carry it either: 0bda:a728 has no entry of its own, so it falls to the generic Realtek entry in btusb's quirks_table - USB_VENDOR_AND_INTERFACE_INFO(0x0bda, 0xe0, 0x01, 0x01) - which precedes the per-device entries. usb_match_id() takes the first match and 0bda:8771 also presents e0/01/01, so the specific entry for it at quirks_table:840 never applies. What this series does instead ----------------------------- The quirk is documented as being for controllers which "erroneously claim to support extended scanning" - and one that claims support in commands[37] and then answers Command Disallowed is saying so itself. Patch 1 latches the quirk right where that command is issued; every later scan uses the legacy commands. Patch 2 then drops the static per-chip-id guess, which 0bda:a728 no longer needs. In this order the series is bisectable: patch 1 alone changes nothing for anyone whose quirk is already set at setup. An affected controller pays one rejected scan round per power cycle instead of a permanent stream of failures, and dongles nobody has owned yet are handled without waiting for a patch. The latch is sticky, as quirk_flags is never cleared, so it matters that false positives are unlikely: hci_passive_scan_sync() always disables scanning before starting it, so the controller is never asked to enable a scan that is already running - the obvious legitimate source of Command Disallowed. Testing ------- Built and running on v7.2 on the 0bda:8771 dongle. Extended scan is used, the quirk is never set, no 0x200c and no controller resets, and a keyboard plus a trackball stay connected across repeated LE scans - the exact sequence that wedged the adapter within ten seconds before. What I cannot test is the other half: I do not have a 0bda:a728, so the err == -EBUSY path has never executed here. Alexej, does your dongle still work with this series, and do you see the "extended scan rejected, using legacy scan" warning once? Also, 0x2042 carries both the enable and the disable, so I cannot tell from your report which call site returned -EBUSY - knowing that would tell us whether a single rejected round is really all it costs you. Sending as RFC mainly because patch 1 sets the quirk at runtime, while the existing comment says it is set before hci_register_dev or in hdev->setup. I updated that comment, but if you would rather keep the quirk strictly setup-time I am happy to respin as a USB-id match in btusb.c instead - it just needs the quirks_table ordering sorted out first. #regzbot introduced: 5ead2063611ae56809b1b113ac44cef9547c81d7 Kamil Serwus (2): Bluetooth: hci_sync: latch broken ext scan on Command Disallowed Bluetooth: btrtl: drop the blanket RTL8761B extended scan quirk drivers/bluetooth/btrtl.c | 13 ------------- include/net/bluetooth/hci.h | 4 ++-- net/bluetooth/hci_sync.c | 15 +++++++++++++-- 3 files changed, 15 insertions(+), 17 deletions(-) base-commit: 8d3ae59288f1e7d58d76558a6ee96d533bc5019f -- 2.55.0