[PATCH] Bluetooth: Add HCI_QUIRK_NO_SCAN_WHILE_CONNECTED for combo chips

[PATCH] Bluetooth: Add HCI_QUIRK_NO_SCAN_WHILE_CONNECTED for combo chips

[StefanCondorache]

Realtek combo chips share a single antenna between Wi-Fi and Bluetooth.
Background LE passive scanning while an active connection exists causes
antenna multiplexing conflicts via Packet Traffic Arbitration (PTA),
resulting in audio stuttering and Wi-Fi packet loss.

Add HCI_QUIRK_NO_SCAN_WHILE_CONNECTED to suppress passive scanning in
hci_update_passive_scan_sync() when active connections are present.
Set this quirk for all Realtek devices in btrtl_set_quirks().

Also add device ID 0x0bda:0xc829 to the btusb Realtek device table.

Signed-off-by: StefanCondorache <condorachest@gmail.com>
---
 drivers/bluetooth/btrtl.c   |  6 ++++++
 drivers/bluetooth/btusb.c   |  2 ++
 include/net/bluetooth/hci.h | 11 +++++++++++
 net/bluetooth/hci_sync.c    |  7 +++++++
 4 files changed, 26 insertions(+)

diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c
index 62f9d4df3a4f..00dfba656970 100644
--- a/drivers/bluetooth/btrtl.c
+++ b/drivers/bluetooth/btrtl.c
@@ -1299,6 +1299,12 @@ EXPORT_SYMBOL_GPL(btrtl_download_firmware);
 
 void btrtl_set_quirks(struct hci_dev *hdev, struct btrtl_device_info *btrtl_dev)
 {
+	/* Realtek combo chips share the antenna between Wi-Fi and
+	 * Bluetooth. Suppress passive scanning while connected to
+	 * prevent coexistence issues.
+	 */
+	hci_set_quirk(hdev, HCI_QUIRK_NO_SCAN_WHILE_CONNECTED);
+
 	/* Enable controller to do both LE scan and BR/EDR inquiry
 	 * simultaneously.
 	 */
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 5f57953393be..87972f5fc567 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -516,6 +516,8 @@ static const struct usb_device_id quirks_table[] = {
 	/* Realtek 8822CU Bluetooth devices */
 	{ USB_DEVICE(0x13d3, 0x3549), .driver_info = BTUSB_REALTEK |
 						     BTUSB_WIDEBAND_SPEECH },
+	{ USB_DEVICE(0x0bda, 0xc829), .driver_info = BTUSB_REALTEK |
+							 BTUSB_WIDEBAND_SPEECH },
 
 	/* Realtek 8851BE Bluetooth devices */
 	{ USB_DEVICE(0x0bda, 0xb850), .driver_info = BTUSB_REALTEK },
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 572b1c620c5d..8466dc52aeca 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -378,6 +378,17 @@ enum {
 	 */
 	HCI_QUIRK_BROKEN_READ_PAGE_SCAN_TYPE,
 
+	/* When this quirk is set, the controller suppresses passive LE
+	 * background scanning while an active connection exists.
+	 * This is required for combo chips with shared Wi-Fi/Bluetooth
+	 * antennas to prevent coexistence issues causing audio drops
+	 * and Wi-Fi packet loss.
+	 *
+	 * This quirk can be set before hci_register_dev is called or
+	 * during the hdev->setup vendor callback.
+	 */
+	HCI_QUIRK_NO_SCAN_WHILE_CONNECTED,
+
 	__HCI_NUM_QUIRKS,
 };
 
diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index fd3aacdea512..5e30e725efa2 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -3194,6 +3194,13 @@ int hci_update_passive_scan_sync(struct hci_dev *hdev)
 	if (hdev->discovery.state != DISCOVERY_STOPPED)
 		return 0;
 
+	/* If the controller requires no scanning while connected,
+	 * suppress passive scanning when an active connection exists.
+	 */
+	if (hci_test_quirk(hdev, HCI_QUIRK_NO_SCAN_WHILE_CONNECTED) &&
+	    !list_empty(&hdev->conn_hash.list))
+		return 0;
+
 	/* Reset RSSI and UUID filters when starting background scanning
 	 * since these filters are meant for service discovery only.
 	 *
-- 
2.53.0

RE: Bluetooth: Add HCI_QUIRK_NO_SCAN_WHILE_CONNECTED for combo chips

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 3604 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1082905

---Test result---

Test Summary:
CheckPatch                    PASS      1.17 seconds
GitLint                       PASS      0.28 seconds
SubjectPrefix                 PASS      0.10 seconds
BuildKernel                   PASS      24.32 seconds
CheckAllWarning               PASS      26.55 seconds
CheckSparse                   PASS      25.79 seconds
BuildKernel32                 PASS      23.77 seconds
TestRunnerSetup               PASS      530.52 seconds
TestRunner_l2cap-tester       PASS      28.01 seconds
TestRunner_iso-tester         PASS      41.60 seconds
TestRunner_bnep-tester        PASS      6.55 seconds
TestRunner_mgmt-tester        FAIL      114.18 seconds
TestRunner_rfcomm-tester      PASS      9.49 seconds
TestRunner_sco-tester         PASS      14.29 seconds
TestRunner_ioctl-tester       PASS      10.15 seconds
TestRunner_mesh-tester        FAIL      12.23 seconds
TestRunner_smp-tester         PASS      8.76 seconds
TestRunner_userchan-tester    PASS      6.73 seconds
TestRunner_6lowpan-tester     FAIL      8.50 seconds
IncrementalBuild              PASS      22.51 seconds

Details
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4

Failed Test Cases
Read Exp Feature - Success                           Failed       0.102 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0

Failed Test Cases
Mesh - Send cancel - 1                               Timed out    2.670 seconds
Mesh - Send cancel - 2                               Timed out    2.001 seconds
##############################
Test: TestRunner_6lowpan-tester - FAIL
Desc: Run 6lowpan-tester with test-runner
Output:
WARNING: possible circular locking dependency detected
7.0.0-rc7-g83e51bc60491 #1 Not tainted
------------------------------------------------------
kworker/0:1/11 is trying to acquire lock:
ffff88800233e940 ((wq_completion)hci0#2){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x75/0x180

but task is already holding lock:
ffffffff9624f960 (rtnl_mutex){+.+.}-{4:4}, at: lowpan_unregister_netdev+0xd/0x30

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #4 (rtnl_mutex){+.+.}-{4:4}:
       lock_acquire+0xf7/0x2c0
       __mutex_lock+0x16b/0x1fc0
       lowpan_register_netdev+0x11/0x30
       chan_ready_cb+0x836/0xd00
       l2cap_recv_frame+0x61bb/0x88e0
       l2cap_recv_acldata+0x790/0xdf0
       hci_rx_work+0x500/0xd00
       process_scheduled_works+0xba7/0x1a90
       worker_thread+0x514/0xbb0
       kthread+0x368/0x490
       ret_from_fork+0x498/0x7e0
       ret_from_fork_asm+0x19/0x30

-> #3 (&chan->lock#3/1){+.+.}-{4:4}:
       lock_acquire+0xf7/0x2c0
       __mutex_lock+0x16b/0x1fc0
       l2cap_chan_connect+0x74e/0x1980
       lowpan_control_write+0x523/0x660
       full_proxy_write+0x10b/0x190
       vfs_write+0x1c0/0xf60
       ksys_write+0xf1/0x1d0
       do_syscall_64+0xa0/0x570
       entry_SYSCALL_64_after_hwframe+0x74/0x7c

-> #2 (&conn->lock){+.+.}-{4:4}:
...
Total: 8, Passed: 8 (100.0%), Failed: 0, Not Run: 0


https://github.com/bluez/bluetooth-next/pull/104

---
Regards,
Linux Bluetooth

Re: [PATCH] Bluetooth: Add HCI_QUIRK_NO_SCAN_WHILE_CONNECTED for combo chips

[Pauli Virtanen]

Hi,

su, 2026-04-19 kello 10:24 +0300, StefanCondorache kirjoitti:
> Realtek combo chips share a single antenna between Wi-Fi and Bluetooth.
> Background LE passive scanning while an active connection exists causes
> antenna multiplexing conflicts via Packet Traffic Arbitration (PTA),
> resulting in audio stuttering and Wi-Fi packet loss.
> 
> Add HCI_QUIRK_NO_SCAN_WHILE_CONNECTED to suppress passive scanning in
> hci_update_passive_scan_sync() when active connections are present.
> Set this quirk for all Realtek devices in btrtl_set_quirks().

Some general questions on this, which are not immediately apparent from
the commit message:

How is it know which Realtek models have this bug?

Which ones were tested?

Is it better to set the quirk for all Realtek devices than do it per
USB id / chipset for each known bad device?

> Also add device ID 0x0bda:0xc829 to the btusb Realtek device table.

Patches adding USB device ids usually have USB info from
/sys/kernel/debug/usb/devices in the commit message, see other patches
add these. Probably should be separate patch?

> Signed-off-by: StefanCondorache <condorachest@gmail.com>
> ---
>  drivers/bluetooth/btrtl.c   |  6 ++++++
>  drivers/bluetooth/btusb.c   |  2 ++
>  include/net/bluetooth/hci.h | 11 +++++++++++
>  net/bluetooth/hci_sync.c    |  7 +++++++
>  4 files changed, 26 insertions(+)
> 
> diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c
> index 62f9d4df3a4f..00dfba656970 100644
> --- a/drivers/bluetooth/btrtl.c
> +++ b/drivers/bluetooth/btrtl.c
> @@ -1299,6 +1299,12 @@ EXPORT_SYMBOL_GPL(btrtl_download_firmware);
>  
>  void btrtl_set_quirks(struct hci_dev *hdev, struct btrtl_device_info *btrtl_dev)
>  {
> +	/* Realtek combo chips share the antenna between Wi-Fi and
> +	 * Bluetooth. Suppress passive scanning while connected to
> +	 * prevent coexistence issues.
> +	 */
> +	hci_set_quirk(hdev, HCI_QUIRK_NO_SCAN_WHILE_CONNECTED);

This sets the quirk for all Realtek chips.

Realtek chips are also in stuff like Bluetooth USB dongles that are not
combo wifi ones. Can they be identified?

> +
>  	/* Enable controller to do both LE scan and BR/EDR inquiry
>  	 * simultaneously.
>  	 */
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 5f57953393be..87972f5fc567 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -516,6 +516,8 @@ static const struct usb_device_id quirks_table[] = {
>  	/* Realtek 8822CU Bluetooth devices */
>  	{ USB_DEVICE(0x13d3, 0x3549), .driver_info = BTUSB_REALTEK |
>  						     BTUSB_WIDEBAND_SPEECH },
> +	{ USB_DEVICE(0x0bda, 0xc829), .driver_info = BTUSB_REALTEK |
> +							 BTUSB_WIDEBAND_SPEECH },
>  
>  	/* Realtek 8851BE Bluetooth devices */
>  	{ USB_DEVICE(0x0bda, 0xb850), .driver_info = BTUSB_REALTEK },
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index 572b1c620c5d..8466dc52aeca 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -378,6 +378,17 @@ enum {
>  	 */
>  	HCI_QUIRK_BROKEN_READ_PAGE_SCAN_TYPE,
>  
> +	/* When this quirk is set, the controller suppresses passive LE
> +	 * background scanning while an active connection exists.
> +	 * This is required for combo chips with shared Wi-Fi/Bluetooth
> +	 * antennas to prevent coexistence issues causing audio drops
> +	 * and Wi-Fi packet loss.
> +	 *
> +	 * This quirk can be set before hci_register_dev is called or
> +	 * during the hdev->setup vendor callback.
> +	 */
> +	HCI_QUIRK_NO_SCAN_WHILE_CONNECTED,
> +
>  	__HCI_NUM_QUIRKS,
>  };
>  
> diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
> index fd3aacdea512..5e30e725efa2 100644
> --- a/net/bluetooth/hci_sync.c
> +++ b/net/bluetooth/hci_sync.c
> @@ -3194,6 +3194,13 @@ int hci_update_passive_scan_sync(struct hci_dev *hdev)
>  	if (hdev->discovery.state != DISCOVERY_STOPPED)
>  		return 0;
>  
> +	/* If the controller requires no scanning while connected,
> +	 * suppress passive scanning when an active connection exists.
> +	 */
> +	if (hci_test_quirk(hdev, HCI_QUIRK_NO_SCAN_WHILE_CONNECTED) &&
> +	    !list_empty(&hdev->conn_hash.list))
> +		return 0;
> +

Does this break initiating connections via hci_connect_le_scan() if
another connection is active?

Is it possible to make more than one LE connection simultaneously?

>  	/* Reset RSSI and UUID filters when starting background scanning
>  	 * since these filters are meant for service discovery only.
>  	 *

-- 
Pauli Virtanen

Re: [PATCH] Bluetooth: Add HCI_QUIRK_NO_SCAN_WHILE_CONNECTED for combo chips

[Bastien Nocera]

On Sun, 2026-04-19 at 13:35 +0300, Pauli Virtanen wrote:
> Hi,
> 
> su, 2026-04-19 kello 10:24 +0300, StefanCondorache kirjoitti:
> > Realtek combo chips share a single antenna between Wi-Fi and
> > Bluetooth.
> > Background LE passive scanning while an active connection exists
> > causes
> > antenna multiplexing conflicts via Packet Traffic Arbitration
> > (PTA),
> > resulting in audio stuttering and Wi-Fi packet loss.
> > 
> > Add HCI_QUIRK_NO_SCAN_WHILE_CONNECTED to suppress passive scanning
> > in
> > hci_update_passive_scan_sync() when active connections are present.
> > Set this quirk for all Realtek devices in btrtl_set_quirks().
> 
> Some general questions on this, which are not immediately apparent
> from
> the commit message:
> 
> How is it know which Realtek models have this bug?
> 
> Which ones were tested?
> 
> Is it better to set the quirk for all Realtek devices than do it per
> USB id / chipset for each known bad device?

I worked on the rtl8723bs Wi-Fi driver in a previous life (so much so
that I can spell out the model number on top of my head), and I
remember it having code for BT/Wi-Fi coexistence.

Is this only a problem with the lack of BT/Wi-Fi coexistence support in
the upstream Linux drivers (eg. not in the Realtek vendor drivers)

How do you actually test this in a reliable and reproducible way? How
will we know to remove this quirk?

> > Also add device ID 0x0bda:0xc829 to the btusb Realtek device table.
> 
> Patches adding USB device ids usually have USB info from
> /sys/kernel/debug/usb/devices in the commit message, see other
> patches
> add these. Probably should be separate patch?
> 
> > Signed-off-by: StefanCondorache <condorachest@gmail.com>
> > ---
> >  drivers/bluetooth/btrtl.c   |  6 ++++++
> >  drivers/bluetooth/btusb.c   |  2 ++
> >  include/net/bluetooth/hci.h | 11 +++++++++++
> >  net/bluetooth/hci_sync.c    |  7 +++++++
> >  4 files changed, 26 insertions(+)
> > 
> > diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c
> > index 62f9d4df3a4f..00dfba656970 100644
> > --- a/drivers/bluetooth/btrtl.c
> > +++ b/drivers/bluetooth/btrtl.c
> > @@ -1299,6 +1299,12 @@ EXPORT_SYMBOL_GPL(btrtl_download_firmware);
> >  
> >  void btrtl_set_quirks(struct hci_dev *hdev, struct
> > btrtl_device_info *btrtl_dev)
> >  {
> > +	/* Realtek combo chips share the antenna between Wi-Fi and
> > +	 * Bluetooth. Suppress passive scanning while connected to
> > +	 * prevent coexistence issues.
> > +	 */
> > +	hci_set_quirk(hdev, HCI_QUIRK_NO_SCAN_WHILE_CONNECTED);
> 
> This sets the quirk for all Realtek chips.
> 
> Realtek chips are also in stuff like Bluetooth USB dongles that are
> not
> combo wifi ones. Can they be identified?
> 
> > +
> >  	/* Enable controller to do both LE scan and BR/EDR inquiry
> >  	 * simultaneously.
> >  	 */
> > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> > index 5f57953393be..87972f5fc567 100644
> > --- a/drivers/bluetooth/btusb.c
> > +++ b/drivers/bluetooth/btusb.c
> > @@ -516,6 +516,8 @@ static const struct usb_device_id
> > quirks_table[] = {
> >  	/* Realtek 8822CU Bluetooth devices */
> >  	{ USB_DEVICE(0x13d3, 0x3549), .driver_info = BTUSB_REALTEK
> > |
> >  						    
> > BTUSB_WIDEBAND_SPEECH },
> > +	{ USB_DEVICE(0x0bda, 0xc829), .driver_info = BTUSB_REALTEK
> > |
> > +							
> > BTUSB_WIDEBAND_SPEECH },
> >  
> >  	/* Realtek 8851BE Bluetooth devices */
> >  	{ USB_DEVICE(0x0bda, 0xb850), .driver_info = BTUSB_REALTEK
> > },
> > diff --git a/include/net/bluetooth/hci.h
> > b/include/net/bluetooth/hci.h
> > index 572b1c620c5d..8466dc52aeca 100644
> > --- a/include/net/bluetooth/hci.h
> > +++ b/include/net/bluetooth/hci.h
> > @@ -378,6 +378,17 @@ enum {
> >  	 */
> >  	HCI_QUIRK_BROKEN_READ_PAGE_SCAN_TYPE,
> >  
> > +	/* When this quirk is set, the controller suppresses
> > passive LE
> > +	 * background scanning while an active connection exists.
> > +	 * This is required for combo chips with shared Wi-
> > Fi/Bluetooth
> > +	 * antennas to prevent coexistence issues causing audio
> > drops
> > +	 * and Wi-Fi packet loss.
> > +	 *
> > +	 * This quirk can be set before hci_register_dev is called
> > or
> > +	 * during the hdev->setup vendor callback.
> > +	 */
> > +	HCI_QUIRK_NO_SCAN_WHILE_CONNECTED,
> > +
> >  	__HCI_NUM_QUIRKS,
> >  };
> >  
> > diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
> > index fd3aacdea512..5e30e725efa2 100644
> > --- a/net/bluetooth/hci_sync.c
> > +++ b/net/bluetooth/hci_sync.c
> > @@ -3194,6 +3194,13 @@ int hci_update_passive_scan_sync(struct
> > hci_dev *hdev)
> >  	if (hdev->discovery.state != DISCOVERY_STOPPED)
> >  		return 0;
> >  
> > +	/* If the controller requires no scanning while connected,
> > +	 * suppress passive scanning when an active connection
> > exists.
> > +	 */
> > +	if (hci_test_quirk(hdev,
> > HCI_QUIRK_NO_SCAN_WHILE_CONNECTED) &&
> > +	    !list_empty(&hdev->conn_hash.list))
> > +		return 0;
> > +
> 
> Does this break initiating connections via hci_connect_le_scan() if
> another connection is active?
> 
> Is it possible to make more than one LE connection simultaneously?
> 
> >  	/* Reset RSSI and UUID filters when starting background
> > scanning
> >  	 * since these filters are meant for service discovery
> > only.
> >  	 *

Re: [PATCH] Bluetooth: Add HCI_QUIRK_NO_SCAN_WHILE_CONNECTED for combo chips

[Luiz Augusto von Dentz]

Hi Stefan,

On Mon, Apr 20, 2026 at 5:08 AM Bastien Nocera <hadess@hadess.net> wrote:
>
> On Sun, 2026-04-19 at 13:35 +0300, Pauli Virtanen wrote:
> > Hi,
> >
> > su, 2026-04-19 kello 10:24 +0300, StefanCondorache kirjoitti:
> > > Realtek combo chips share a single antenna between Wi-Fi and
> > > Bluetooth.
> > > Background LE passive scanning while an active connection exists
> > > causes
> > > antenna multiplexing conflicts via Packet Traffic Arbitration
> > > (PTA),
> > > resulting in audio stuttering and Wi-Fi packet loss.
> > >
> > > Add HCI_QUIRK_NO_SCAN_WHILE_CONNECTED to suppress passive scanning
> > > in
> > > hci_update_passive_scan_sync() when active connections are present.
> > > Set this quirk for all Realtek devices in btrtl_set_quirks().
> >
> > Some general questions on this, which are not immediately apparent
> > from
> > the commit message:
> >
> > How is it know which Realtek models have this bug?
> >
> > Which ones were tested?
> >
> > Is it better to set the quirk for all Realtek devices than do it per
> > USB id / chipset for each known bad device?
>
> I worked on the rtl8723bs Wi-Fi driver in a previous life (so much so
> that I can spell out the model number on top of my head), and I
> remember it having code for BT/Wi-Fi coexistence.
>
> Is this only a problem with the lack of BT/Wi-Fi coexistence support in
> the upstream Linux drivers (eg. not in the Realtek vendor drivers)
>
> How do you actually test this in a reliable and reproducible way? How
> will we know to remove this quirk?
>
> > > Also add device ID 0x0bda:0xc829 to the btusb Realtek device table.
> >
> > Patches adding USB device ids usually have USB info from
> > /sys/kernel/debug/usb/devices in the commit message, see other
> > patches
> > add these. Probably should be separate patch?
> >
> > > Signed-off-by: StefanCondorache <condorachest@gmail.com>
> > > ---
> > >  drivers/bluetooth/btrtl.c   |  6 ++++++
> > >  drivers/bluetooth/btusb.c   |  2 ++
> > >  include/net/bluetooth/hci.h | 11 +++++++++++
> > >  net/bluetooth/hci_sync.c    |  7 +++++++
> > >  4 files changed, 26 insertions(+)
> > >
> > > diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c
> > > index 62f9d4df3a4f..00dfba656970 100644
> > > --- a/drivers/bluetooth/btrtl.c
> > > +++ b/drivers/bluetooth/btrtl.c
> > > @@ -1299,6 +1299,12 @@ EXPORT_SYMBOL_GPL(btrtl_download_firmware);
> > >
> > >  void btrtl_set_quirks(struct hci_dev *hdev, struct
> > > btrtl_device_info *btrtl_dev)
> > >  {
> > > +   /* Realtek combo chips share the antenna between Wi-Fi and
> > > +    * Bluetooth. Suppress passive scanning while connected to
> > > +    * prevent coexistence issues.
> > > +    */
> > > +   hci_set_quirk(hdev, HCI_QUIRK_NO_SCAN_WHILE_CONNECTED);
> >
> > This sets the quirk for all Realtek chips.
> >
> > Realtek chips are also in stuff like Bluetooth USB dongles that are
> > not
> > combo wifi ones. Can they be identified?

Yeah, this needs to be detectable and not just set to all Realtek
chips, actually I don't think even with quirk this would actually be a
good solution because that would limit the number of connected device
to 1 since otherwise the user would have to manually connect its
device once anything is connected, which will probably cause a lot of
furstration to say least.

> >
> > > +
> > >     /* Enable controller to do both LE scan and BR/EDR inquiry
> > >      * simultaneously.
> > >      */
> > > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> > > index 5f57953393be..87972f5fc567 100644
> > > --- a/drivers/bluetooth/btusb.c
> > > +++ b/drivers/bluetooth/btusb.c
> > > @@ -516,6 +516,8 @@ static const struct usb_device_id
> > > quirks_table[] = {
> > >     /* Realtek 8822CU Bluetooth devices */
> > >     { USB_DEVICE(0x13d3, 0x3549), .driver_info = BTUSB_REALTEK
> > > |
> > >
> > > BTUSB_WIDEBAND_SPEECH },
> > > +   { USB_DEVICE(0x0bda, 0xc829), .driver_info = BTUSB_REALTEK
> > > |
> > > +
> > > BTUSB_WIDEBAND_SPEECH },
> > >
> > >     /* Realtek 8851BE Bluetooth devices */
> > >     { USB_DEVICE(0x0bda, 0xb850), .driver_info = BTUSB_REALTEK
> > > },
> > > diff --git a/include/net/bluetooth/hci.h
> > > b/include/net/bluetooth/hci.h
> > > index 572b1c620c5d..8466dc52aeca 100644
> > > --- a/include/net/bluetooth/hci.h
> > > +++ b/include/net/bluetooth/hci.h
> > > @@ -378,6 +378,17 @@ enum {
> > >      */
> > >     HCI_QUIRK_BROKEN_READ_PAGE_SCAN_TYPE,
> > >
> > > +   /* When this quirk is set, the controller suppresses
> > > passive LE
> > > +    * background scanning while an active connection exists.
> > > +    * This is required for combo chips with shared Wi-
> > > Fi/Bluetooth
> > > +    * antennas to prevent coexistence issues causing audio
> > > drops
> > > +    * and Wi-Fi packet loss.
> > > +    *
> > > +    * This quirk can be set before hci_register_dev is called
> > > or
> > > +    * during the hdev->setup vendor callback.
> > > +    */
> > > +   HCI_QUIRK_NO_SCAN_WHILE_CONNECTED,
> > > +
> > >     __HCI_NUM_QUIRKS,
> > >  };
> > >
> > > diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
> > > index fd3aacdea512..5e30e725efa2 100644
> > > --- a/net/bluetooth/hci_sync.c
> > > +++ b/net/bluetooth/hci_sync.c
> > > @@ -3194,6 +3194,13 @@ int hci_update_passive_scan_sync(struct
> > > hci_dev *hdev)
> > >     if (hdev->discovery.state != DISCOVERY_STOPPED)
> > >             return 0;
> > >
> > > +   /* If the controller requires no scanning while connected,
> > > +    * suppress passive scanning when an active connection
> > > exists.
> > > +    */
> > > +   if (hci_test_quirk(hdev,
> > > HCI_QUIRK_NO_SCAN_WHILE_CONNECTED) &&
> > > +       !list_empty(&hdev->conn_hash.list))
> > > +           return 0;
> > > +
> >
> > Does this break initiating connections via hci_connect_le_scan() if
> > another connection is active?
> >
> > Is it possible to make more than one LE connection simultaneously?

Yeah, I think it breaks even when a user initiates a connection, so
I'm afraid we need feedback from the Realtek engineers on how to
address this properly on their controllers, not that sashiko found
many of the points already described here, and some more, which
further reinforces that we shouldn't just take these changes in as
they are:

https://sashiko.dev/#/patchset/20260419072433.55976-1-condorachest%40gmail.com

> >
> > >     /* Reset RSSI and UUID filters when starting background
> > > scanning
> > >      * since these filters are meant for service discovery
> > > only.
> > >      *



-- 
Luiz Augusto von Dentz

Re: [PATCH] Bluetooth: Add HCI_QUIRK_NO_SCAN_WHILE_CONNECTED for combo chips

[Bastien Nocera]

Hello Ștefan,

The mailing-list needs to be put on CC. FWIW, this LLM-generated reply
that doesn't verify anything and takes me at my word really isn't
useful.

Cheers

On Mon, 2026-04-20 at 19:07 +0300, Ștefan Condorache wrote:
> Hi Bastien, 
> 
> Thank you for the detailed feedback. 
>  Regarding your questions: 
> You are correct that vendor Realtek drivers implement BT/Wi-Fi
> coexistence. 
> The upstream driver lacks this. This quirk is intended as a stopgap
> until proper 
> coexistence support is implemented upstream. 
> 
> The quirk should be removed once the upstream driver gains
> coexistence support 
> equivalent to the vendor driver. Testing was done by streaming audio
> over Bluetooth 
> while running continuous Wi-Fi traffic (iperf3) and observing audio
> dropouts. 
> With the quirk enabled the dropouts stop. I acknowledge this is not
> an automated reproducible test, which is a weakness.
> 
> On Mon, Apr 20, 2026 at 12:08 PM Bastien Nocera <hadess@hadess.net>
> wrote:
> > On Sun, 2026-04-19 at 13:35 +0300, Pauli Virtanen wrote:
> > > Hi,
> > > 
> > > su, 2026-04-19 kello 10:24 +0300, StefanCondorache kirjoitti:
> > > > Realtek combo chips share a single antenna between Wi-Fi and
> > > > Bluetooth.
> > > > Background LE passive scanning while an active connection
> > > > exists
> > > > causes
> > > > antenna multiplexing conflicts via Packet Traffic Arbitration
> > > > (PTA),
> > > > resulting in audio stuttering and Wi-Fi packet loss.
> > > > 
> > > > Add HCI_QUIRK_NO_SCAN_WHILE_CONNECTED to suppress passive
> > > > scanning
> > > > in
> > > > hci_update_passive_scan_sync() when active connections are
> > > > present.
> > > > Set this quirk for all Realtek devices in btrtl_set_quirks().
> > > 
> > > Some general questions on this, which are not immediately
> > > apparent
> > > from
> > > the commit message:
> > > 
> > > How is it know which Realtek models have this bug?
> > > 
> > > Which ones were tested?
> > > 
> > > Is it better to set the quirk for all Realtek devices than do it
> > > per
> > > USB id / chipset for each known bad device?
> > 
> > I worked on the rtl8723bs Wi-Fi driver in a previous life (so much
> > so
> > that I can spell out the model number on top of my head), and I
> > remember it having code for BT/Wi-Fi coexistence.
> > 
> > Is this only a problem with the lack of BT/Wi-Fi coexistence
> > support in
> > the upstream Linux drivers (eg. not in the Realtek vendor drivers)
> > 
> > How do you actually test this in a reliable and reproducible way?
> > How
> > will we know to remove this quirk?
> > 
> > > > Also add device ID 0x0bda:0xc829 to the btusb Realtek device
> > > > table.
> > > 
> > > Patches adding USB device ids usually have USB info from
> > > /sys/kernel/debug/usb/devices in the commit message, see other
> > > patches
> > > add these. Probably should be separate patch?
> > > 
> > > > Signed-off-by: StefanCondorache <condorachest@gmail.com>
> > > > ---
> > > >  drivers/bluetooth/btrtl.c   |  6 ++++++
> > > >  drivers/bluetooth/btusb.c   |  2 ++
> > > >  include/net/bluetooth/hci.h | 11 +++++++++++
> > > >  net/bluetooth/hci_sync.c    |  7 +++++++
> > > >  4 files changed, 26 insertions(+)
> > > > 
> > > > diff --git a/drivers/bluetooth/btrtl.c
> > > > b/drivers/bluetooth/btrtl.c
> > > > index 62f9d4df3a4f..00dfba656970 100644
> > > > --- a/drivers/bluetooth/btrtl.c
> > > > +++ b/drivers/bluetooth/btrtl.c
> > > > @@ -1299,6 +1299,12 @@
> > > > EXPORT_SYMBOL_GPL(btrtl_download_firmware);
> > > >  
> > > >  void btrtl_set_quirks(struct hci_dev *hdev, struct
> > > > btrtl_device_info *btrtl_dev)
> > > >  {
> > > > +   /* Realtek combo chips share the antenna between Wi-Fi and
> > > > +    * Bluetooth. Suppress passive scanning while connected to
> > > > +    * prevent coexistence issues.
> > > > +    */
> > > > +   hci_set_quirk(hdev, HCI_QUIRK_NO_SCAN_WHILE_CONNECTED);
> > > 
> > > This sets the quirk for all Realtek chips.
> > > 
> > > Realtek chips are also in stuff like Bluetooth USB dongles that
> > > are
> > > not
> > > combo wifi ones. Can they be identified?
> > > 
> > > > +
> > > >     /* Enable controller to do both LE scan and BR/EDR inquiry
> > > >      * simultaneously.
> > > >      */
> > > > diff --git a/drivers/bluetooth/btusb.c
> > > > b/drivers/bluetooth/btusb.c
> > > > index 5f57953393be..87972f5fc567 100644
> > > > --- a/drivers/bluetooth/btusb.c
> > > > +++ b/drivers/bluetooth/btusb.c
> > > > @@ -516,6 +516,8 @@ static const struct usb_device_id
> > > > quirks_table[] = {
> > > >     /* Realtek 8822CU Bluetooth devices */
> > > >     { USB_DEVICE(0x13d3, 0x3549), .driver_info = BTUSB_REALTEK
> > > > |
> > > >                                                 
> > > > BTUSB_WIDEBAND_SPEECH },
> > > > +   { USB_DEVICE(0x0bda, 0xc829), .driver_info = BTUSB_REALTEK
> > > > |
> > > > +                                                   
> > > > BTUSB_WIDEBAND_SPEECH },
> > > >  
> > > >     /* Realtek 8851BE Bluetooth devices */
> > > >     { USB_DEVICE(0x0bda, 0xb850), .driver_info = BTUSB_REALTEK
> > > > },
> > > > diff --git a/include/net/bluetooth/hci.h
> > > > b/include/net/bluetooth/hci.h
> > > > index 572b1c620c5d..8466dc52aeca 100644
> > > > --- a/include/net/bluetooth/hci.h
> > > > +++ b/include/net/bluetooth/hci.h
> > > > @@ -378,6 +378,17 @@ enum {
> > > >      */
> > > >     HCI_QUIRK_BROKEN_READ_PAGE_SCAN_TYPE,
> > > >  
> > > > +   /* When this quirk is set, the controller suppresses
> > > > passive LE
> > > > +    * background scanning while an active connection exists.
> > > > +    * This is required for combo chips with shared Wi-
> > > > Fi/Bluetooth
> > > > +    * antennas to prevent coexistence issues causing audio
> > > > drops
> > > > +    * and Wi-Fi packet loss.
> > > > +    *
> > > > +    * This quirk can be set before hci_register_dev is called
> > > > or
> > > > +    * during the hdev->setup vendor callback.
> > > > +    */
> > > > +   HCI_QUIRK_NO_SCAN_WHILE_CONNECTED,
> > > > +
> > > >     __HCI_NUM_QUIRKS,
> > > >  };
> > > >  
> > > > diff --git a/net/bluetooth/hci_sync.c
> > > > b/net/bluetooth/hci_sync.c
> > > > index fd3aacdea512..5e30e725efa2 100644
> > > > --- a/net/bluetooth/hci_sync.c
> > > > +++ b/net/bluetooth/hci_sync.c
> > > > @@ -3194,6 +3194,13 @@ int hci_update_passive_scan_sync(struct
> > > > hci_dev *hdev)
> > > >     if (hdev->discovery.state != DISCOVERY_STOPPED)
> > > >             return 0;
> > > >  
> > > > +   /* If the controller requires no scanning while connected,
> > > > +    * suppress passive scanning when an active connection
> > > > exists.
> > > > +    */
> > > > +   if (hci_test_quirk(hdev,
> > > > HCI_QUIRK_NO_SCAN_WHILE_CONNECTED) &&
> > > > +       !list_empty(&hdev->conn_hash.list))
> > > > +           return 0;
> > > > +
> > > 
> > > Does this break initiating connections via hci_connect_le_scan()
> > > if
> > > another connection is active?
> > > 
> > > Is it possible to make more than one LE connection
> > > simultaneously?
> > > 
> > > >     /* Reset RSSI and UUID filters when starting background
> > > > scanning
> > > >      * since these filters are meant for service discovery
> > > > only.
> > > >      *