public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Bastien Nocera <hadess@hadess.net>
To: Pauli Virtanen <pav@iki.fi>,
	StefanCondorache <condorachest@gmail.com>,
	 linux-bluetooth@vger.kernel.org
Cc: marcel@holtmann.org, luiz.dentz@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Bluetooth: Add HCI_QUIRK_NO_SCAN_WHILE_CONNECTED for combo chips
Date: Mon, 20 Apr 2026 11:08:57 +0200	[thread overview]
Message-ID: <c4593a49ef6ed7151eceebfd22d602a0d018e9f5.camel@hadess.net> (raw)
In-Reply-To: <8961a9ba3e4a48eaa33060114366573439bbf73f.camel@iki.fi>

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.
> >  	 *

  reply	other threads:[~2026-04-20  9:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-19  7:24 [PATCH] Bluetooth: Add HCI_QUIRK_NO_SCAN_WHILE_CONNECTED for combo chips StefanCondorache
2026-04-19  8:37 ` bluez.test.bot
2026-04-19 10:35 ` [PATCH] " Pauli Virtanen
2026-04-20  9:08   ` Bastien Nocera [this message]
2026-04-20 21:01     ` Luiz Augusto von Dentz
     [not found]     ` <CAGfCjSajE4hBroEUXa=LNw1Z=52b6oT7DsFBm_X_LVphpLoLBA@mail.gmail.com>
2026-04-21  7:33       ` Bastien Nocera

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c4593a49ef6ed7151eceebfd22d602a0d018e9f5.camel@hadess.net \
    --to=hadess@hadess.net \
    --cc=condorachest@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.org \
    --cc=pav@iki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox