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@xxxxxxxxxx> 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@xxxxxxxxx>
> > > ---
> > >  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