[PATCH v2 0/2] Bluetooth: Broadcom controllers of the Apple T2 Macs

[PATCH v2 0/2] Bluetooth: Broadcom controllers of the Apple T2 Macs

[Andre Eikmeyer]

Hello everyone,

This series is for the Broadcom Bluetooth controllers of the Apple T2
Macs, the BCM4364 over UART (hci_bcm) and the BCM4377 over PCIe
(hci_bcm4377).

Patch 1 builds on a vendor command the Android Broadcom vendor library
uses, 0xfc57, to keep A2DP from dropping out while WLAN runs on 2.4 GHz.
Patch 2 sets the strict duplicate filter quirk in both drivers, so a
discovery reports changed advertisement data before its next cycle.

The KaiT2en community, about 280 members, runs these patches with its
kernels. Users reported them working on the MacBookPro15,1, 15,2, 15,3,
15,4, 16,1, 16,4, MacBookAir9,1 and iMac20,1, and nobody reported a
regression.

Changes in v2:
- Dropped "Bluetooth: btbcm: clear vendor bits in LE advertising report
  types" and the revert of 88397423671f. The mask in hci_event.c stays
  as it is.
- Link to v1:
  https://lore.kernel.org/all/20261104151601.70493-1-dev@deq.rocks/



Andre Eikmeyer (2):
  Bluetooth: btbcm: raise ACL priority on Apple Broadcom controllers
  Bluetooth: set the strict duplicate filter quirk on Apple Broadcom
    controllers

 drivers/bluetooth/Kconfig       |  1 +
 drivers/bluetooth/btbcm.c       | 71 +++++++++++++++++++++++++++++++++
 drivers/bluetooth/btbcm.h       |  7 ++++
 drivers/bluetooth/hci_bcm.c     | 23 +++++++++--
 drivers/bluetooth/hci_bcm4377.c |  8 ++++
 5 files changed, 107 insertions(+), 3 deletions(-)


base-commit: 3f425f95ba3923d605f6a8b382e8fcdc59d479db

[PATCH v2 1/2] Bluetooth: btbcm: raise ACL priority on Apple Broadcom controllers

[Andre Eikmeyer]

On the MacBookPro15,1 (BCM4364B0 over UART) A2DP audio drops out as
soon as WLAN runs on 2.4 GHz with traffic. The host keeps the eight ACL
buffers of the controller filled, but the controller holds single ACL
packets for 160-200 ms, so the sink runs dry.

Sending the Broadcom vendor command 0xfc57 (HCI_BRCM_SET_ACL_PRIORITY,
handle and priority, as used by the Android Broadcom vendor library) with
priority high for the audio link stops the dropouts. Setting it back to
normal brings them back right away. The BCM4377 of the MacBookAir9,1
accepts the command as well.

Raise the priority for every BR/EDR ACL link once its Connection Complete
event arrives. This covers audio as well as HID links. hci_bcm does this
on Apple machines only, hci_bcm4377 always, since it only runs on Apple
machines. The PCIe driver receives events in hard interrupt context, so
the command is queued from a work item.

Tested-by: Yossef Osman <Yossef.Osman@proton.me>
Tested-by: Aditya Garg <aditya.garg@linux.dev>
Signed-off-by: Andre Eikmeyer <dev@deq.rocks>
---
 drivers/bluetooth/Kconfig       |  1 +
 drivers/bluetooth/btbcm.c       | 71 +++++++++++++++++++++++++++++++++
 drivers/bluetooth/btbcm.h       |  7 ++++
 drivers/bluetooth/hci_bcm.c     | 18 ++++++++-
 drivers/bluetooth/hci_bcm4377.c |  3 ++
 5 files changed, 98 insertions(+), 2 deletions(-)

diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index b18482b5677..3e2426abdff 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -318,6 +318,7 @@ config BT_HCIBCM4377
 	tristate "HCI BCM4377/4378/4387/4388 PCIe driver"
 	depends on PCI
 	select FW_LOADER
+	select BT_BCM
 	help
 	  Support for Broadcom BCM4377/4378/4387/4388 Bluetooth chipsets
 	  attached via PCIe. These are usually found in Apple machines.
diff --git a/drivers/bluetooth/btbcm.c b/drivers/bluetooth/btbcm.c
index 065536d4ec7..60114561593 100644
--- a/drivers/bluetooth/btbcm.c
+++ b/drivers/bluetooth/btbcm.c
@@ -210,6 +210,77 @@ int btbcm_write_pcm_int_params(struct hci_dev *hdev,
 }
 EXPORT_SYMBOL_GPL(btbcm_write_pcm_int_params);
 
+#define BCM_SET_ACL_PRIORITY	0xfc57
+#define BCM_ACL_PRIORITY_HIGH	0x01
+
+struct bcm_set_acl_priority {
+	__le16	handle;
+	u8	priority;
+} __packed;
+
+struct btbcm_acl_priority_work {
+	struct work_struct	work;
+	struct hci_dev		*hdev;
+	u16			handle;
+};
+
+static int btbcm_set_acl_priority_sync(struct hci_dev *hdev, void *data)
+{
+	struct bcm_set_acl_priority cp;
+	int err;
+
+	cp.handle = cpu_to_le16(PTR_UINT(data));
+	cp.priority = BCM_ACL_PRIORITY_HIGH;
+
+	err = __hci_cmd_sync_status(hdev, BCM_SET_ACL_PRIORITY, sizeof(cp),
+				    &cp, HCI_CMD_TIMEOUT);
+	if (err)
+		bt_dev_warn(hdev, "BCM: setting ACL priority for handle 0x%4.4x failed (%d)",
+			    le16_to_cpu(cp.handle), err);
+	return err;
+}
+
+static void btbcm_acl_priority_work(struct work_struct *work)
+{
+	struct btbcm_acl_priority_work *w =
+		container_of(work, struct btbcm_acl_priority_work, work);
+
+	hci_cmd_sync_queue(w->hdev, btbcm_set_acl_priority_sync,
+			   UINT_PTR(w->handle), NULL);
+	hci_dev_put(w->hdev);
+	kfree(w);
+}
+
+/* Give every BR/EDR ACL link high priority in the controller as soon as it
+ * is connected. Without it the BCM4364 coexistence arbitration lets 2.4 GHz
+ * WLAN traffic delay ACL packets by up to 200 ms, which drops A2DP audio.
+ */
+void btbcm_set_acl_priority_on_connect(struct hci_dev *hdev, struct sk_buff *skb)
+{
+	struct hci_event_hdr *hdr = (void *)skb->data;
+	struct hci_ev_conn_complete *ev;
+	struct btbcm_acl_priority_work *w;
+
+	if (hci_skb_pkt_type(skb) != HCI_EVENT_PKT ||
+	    skb->len < sizeof(*hdr) + sizeof(*ev) ||
+	    hdr->evt != HCI_EV_CONN_COMPLETE)
+		return;
+
+	ev = (void *)(skb->data + sizeof(*hdr));
+	if (ev->status || ev->link_type != ACL_LINK)
+		return;
+
+	w = kzalloc_obj(*w, GFP_ATOMIC);
+	if (!w)
+		return;
+
+	INIT_WORK(&w->work, btbcm_acl_priority_work);
+	w->hdev = hci_dev_hold(hdev);
+	w->handle = __le16_to_cpu(ev->handle);
+	queue_work(system_dfl_wq, &w->work);
+}
+EXPORT_SYMBOL_GPL(btbcm_set_acl_priority_on_connect);
+
 int btbcm_patchram(struct hci_dev *hdev, const struct firmware *fw)
 {
 	const struct hci_command_hdr *cmd;
diff --git a/drivers/bluetooth/btbcm.h b/drivers/bluetooth/btbcm.h
index b4cb24231a2..a4d47b242e9 100644
--- a/drivers/bluetooth/btbcm.h
+++ b/drivers/bluetooth/btbcm.h
@@ -59,6 +59,8 @@ int btbcm_read_pcm_int_params(struct hci_dev *hdev,
 int btbcm_write_pcm_int_params(struct hci_dev *hdev,
 			       const struct bcm_set_pcm_int_params *params);
 
+void btbcm_set_acl_priority_on_connect(struct hci_dev *hdev, struct sk_buff *skb);
+
 int btbcm_setup_patchram(struct hci_dev *hdev);
 int btbcm_setup_apple(struct hci_dev *hdev);
 
@@ -94,6 +96,11 @@ static inline int btbcm_patchram(struct hci_dev *hdev, const struct firmware *fw
 	return -EOPNOTSUPP;
 }
 
+static inline void btbcm_set_acl_priority_on_connect(struct hci_dev *hdev,
+						     struct sk_buff *skb)
+{
+}
+
 static inline int btbcm_setup_patchram(struct hci_dev *hdev)
 {
 	return 0;
diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index e70b9f3fd96..cf4f1455cf9 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -147,6 +147,7 @@ struct bcm_device {
 	bool			drive_rts_on_open;
 	bool			no_uart_clock_set;
 	bool			use_autobaud_mode;
+	bool			acl_priority;
 	u8			pcm_int_params[5];
 	u32			max_autobaud_speed;
 };
@@ -680,10 +681,21 @@ static int bcm_setup(struct hci_uart *hu)
 	.lsize = 0, \
 	.maxlen = BCM_TYPE52_SIZE
 
+static int bcm_recv_event(struct hci_dev *hdev, struct sk_buff *skb)
+{
+	struct hci_uart *hu = hci_get_drvdata(hdev);
+	struct bcm_data *bcm = hu->priv;
+
+	if (bcm->dev && bcm->dev->acl_priority)
+		btbcm_set_acl_priority_on_connect(hdev, skb);
+
+	return hci_recv_frame(hdev, skb);
+}
+
 static const struct h4_recv_pkt bcm_recv_pkts[] = {
 	{ H4_RECV_ACL,      .recv = hci_recv_frame },
 	{ H4_RECV_SCO,      .recv = hci_recv_frame },
-	{ H4_RECV_EVENT,    .recv = hci_recv_frame },
+	{ H4_RECV_EVENT,    .recv = bcm_recv_event },
 	{ H4_RECV_ISO,      .recv = hci_recv_frame },
 	{ BCM_RECV_LM_DIAG, .recv = hci_recv_diag  },
 	{ BCM_RECV_NULL,    .recv = hci_recv_diag  },
@@ -1086,8 +1098,10 @@ static int bcm_get_resources(struct bcm_device *dev)
 
 	dev->name = dev_name(dev->dev);
 
-	if (x86_apple_machine && !bcm_apple_get_resources(dev))
+	if (x86_apple_machine && !bcm_apple_get_resources(dev)) {
+		dev->acl_priority = true;
 		return 0;
+	}
 
 	dev->txco_clk = bcm_get_txco(dev->dev);
 	if (IS_ERR(dev->txco_clk))
diff --git a/drivers/bluetooth/hci_bcm4377.c b/drivers/bluetooth/hci_bcm4377.c
index 66d49b47154..30fcadfae3f 100644
--- a/drivers/bluetooth/hci_bcm4377.c
+++ b/drivers/bluetooth/hci_bcm4377.c
@@ -22,6 +22,8 @@
 #include <net/bluetooth/bluetooth.h>
 #include <net/bluetooth/hci_core.h>
 
+#include "btbcm.h"
+
 enum bcm4377_chip {
 	BCM4377 = 0,
 	BCM4378,
@@ -689,6 +691,7 @@ static void bcm4377_handle_event(struct bcm4377_data *bcm4377,
 
 	memcpy(skb_put(skb, len), payload, len);
 	hci_skb_pkt_type(skb) = type;
+	btbcm_set_acl_priority_on_connect(bcm4377->hdev, skb);
 	hci_recv_frame(bcm4377->hdev, skb);
 
 out:

base-commit: 3f425f95ba3923d605f6a8b382e8fcdc59d479db

Re: [PATCH v2 1/2] Bluetooth: btbcm: raise ACL priority on Apple Broadcom controllers

[Myria Sarvay]

On Thu, Nov 05, 2026 at 09:57:49AM +0100, Andre Eikmeyer wrote:
> On the MacBookPro15,1 (BCM4364B0 over UART) A2DP audio drops out as
> soon as WLAN runs on 2.4 GHz with traffic. The host keeps the eight ACL
> buffers of the controller filled, but the controller holds single ACL
> packets for 160-200 ms, so the sink runs dry.
> 
> Sending the Broadcom vendor command 0xfc57 (HCI_BRCM_SET_ACL_PRIORITY,
> handle and priority, as used by the Android Broadcom vendor library) with
> priority high for the audio link stops the dropouts. Setting it back to
> normal brings them back right away. The BCM4377 of the MacBookAir9,1
> accepts the command as well.
> 
> Raise the priority for every BR/EDR ACL link once its Connection Complete
> event arrives. This covers audio as well as HID links. hci_bcm does this
> on Apple machines only, hci_bcm4377 always, since it only runs on Apple
> machines. The PCIe driver receives events in hard interrupt context, so
> the command is queued from a work item.
Hi Andre,

Just wanted to point it out, if you hadn't seen it before, that Sasha
has in the past sent a different patch [1] to run these priority
commands. They seem to take a different approach to when to enable/run
them. Wasn't sure if one was better or worse though.

Thanks,
Myria

[1]: https://lore.kernel.org/asahi/20260525-brcm-prio-v3-1-6259e10233f8@chaosmail.tech/

Re: [PATCH v2 1/2] Bluetooth: btbcm: raise ACL priority on Apple Broadcom controllers

[André Eikmeyer]

On Fri, 6 Nov 2026 17:05:19 +1100
Myria Sarvay <myrialsarvay@gmail.com> wrote:

> Just wanted to point it out, if you hadn't seen it before, that Sasha
> has in the past sent a different patch [1] to run these priority
> commands. They seem to take a different approach to when to enable/run
> them. Wasn't sure if one was better or worse though.

Hi Myria,

thanks, indeed I hadn't seen it. Sasha's approach is the better one
IMO, it only raises the links that carry audio. The dropouts I measured
are on the BCM4364 of the MacBookPro15,1 and 16,x behind hci_bcm, which
only needs hci_set_brcm_capable() on Apple machines on top of Sasha's
patch.

Luiz, let me tinker. I'll drop 1/2 and send the hci_bcm part on top of
Sasha's patch once I've tested. Then we should have it nice and
consistent.

Andre

Re: [PATCH v2 1/2] Bluetooth: btbcm: raise ACL priority on Apple Broadcom controllers

[Sasha Finkelstein]

On Nov 6, 2026, at 08:33, André Eikmeyer <dev@deq.rocks> wrote:
> 
> I'll drop 1/2 and send the hci_bcm part on top of
> Sasha's patch once I've tested. Then we should have it nice and
> consistent.

You probably shouldn't, or at least base it on v2, not v3 (that one
ended up being a bad idea and caused firmware timeouts, so Asahi
downstream ships something more similar to v2).

In addition - have your tests included entering and exiting stream with
an ACL link active? That part always caused problems for me.

Re: [PATCH v2 1/2] Bluetooth: btbcm: raise ACL priority on Apple Broadcom controllers

[André Eikmeyer]

On Fri, 6 Nov 2026 10:40:58 +0100
Sasha Finkelstein <k@chaosmail.tech> wrote:

> You probably shouldn't, or at least base it on v2, not v3 (that one
> ended up being a bad idea and caused firmware timeouts, so Asahi
> downstream ships something more similar to v2).
> 
> In addition - have your tests included entering and exiting stream
> with an ACL link active? That part always caused problems for me.

Hi Sasha,

I tested both on the BCM4364 (15,1) with 2.4 ghz wifi under load.
Your patch (668d849694ef) and mine, each with a reconnect, plenty of
A2DP stream cycles and profile switches with the ACL link up.

Mine sends 0xfc57 1 ms after connection complete, before AVDTP Open.
Yours right after AVDTP Start. Both complete with success. Neither
needs it again when the stream is left and entered, the priority stays
on the handle. No timeouts with either. The short glitch at each
suspend is the same on both, so it comes from the stream restart I
would guess. Scratching my head now. How you wish me to proceed? 


Andre

Re: [PATCH v2 1/2] Bluetooth: btbcm: raise ACL priority on Apple Broadcom controllers

[Sasha Finkelstein]

On Nov 6, 2026, at 11:39, André Eikmeyer <dev@deq.rocks> wrote:
> 
> On Fri, 6 Nov 2026 10:40:58 +0100
> Sasha Finkelstein <k@chaosmail.tech> wrote:
> 
>> You probably shouldn't, or at least base it on v2, not v3 (that one
>> ended up being a bad idea and caused firmware timeouts, so Asahi
>> downstream ships something more similar to v2).
>> 
>> In addition - have your tests included entering and exiting stream
>> with an ACL link active? That part always caused problems for me.
> 
> Hi Sasha,
> 
> I tested both on the BCM4364 (15,1) with 2.4 ghz wifi under load.
> Your patch (668d849694ef) and mine, each with a reconnect, plenty of
> A2DP stream cycles and profile switches with the ACL link up.
> 
> Mine sends 0xfc57 1 ms after connection complete, before AVDTP Open.
> Yours right after AVDTP Start. Both complete with success. Neither
> needs it again when the stream is left and entered, the priority stays
> on the handle. No timeouts with either. The short glitch at each
> suspend is the same on both, so it comes from the stream restart I
> would guess. Scratching my head now. How you wish me to proceed? 
> 
> 
> Andre

Sleep. I intened to say sleep and I have no idea how I managed to typo
it as stream, but that is what I meant. Sorry.

Re: [PATCH v2 1/2] Bluetooth: btbcm: raise ACL priority on Apple Broadcom controllers

[André Eikmeyer]

On Fri, 6 Nov 2026 11:53:13 +0100
Sasha Finkelstein <k@chaosmail.tech> wrote:

> Sleep. I intened to say sleep and I have no idea how I managed to typo
> it as stream, but that is what I meant. Sorry.

Bwah! Well... np. But you know we are using s3 on T2? So the
controller will be off to Nirvana anyways. My last info is that Asahi
is stuck on s2? So even when testing with s2 on T2, we have UART
transport on the 4634 chips... So if at all the 4377 on 9,1 and 15,4
T2s is in question, right?

Andre

Re: [PATCH v2 1/2] Bluetooth: btbcm: raise ACL priority on Apple Broadcom controllers

[André Eikmeyer]

On Fri, 6 Nov 2026 11:53:13 +0100
Sasha Finkelstein <k@chaosmail.tech> wrote:

Hi Sasha, coming back to this after testing

> >> You probably shouldn't, or at least base it on v2, not v3 (that one
> >> ended up being a bad idea and caused firmware timeouts, so Asahi
> >> downstream ships something more similar to v2).

Linux doesn't keep ACL link across sleep. The core disconnects all
links before suspend ("terminated by local host for suspend"). I saw
that with S3 on the BCM4364 and with s2idle/s3 on the BCM4377. After
resume my headphones reconnect and my patch sets the priority again.
On the T2 Macs the BCM4377 BT itself does not come back from
s2idle yet, even with patches 01, 04 and 05 from your 4388 series,
so I couldn't test there. Would need to investigate, tho s2idle is not
my priority right now.

Since connection time works on these chips, I'd keep 1/2 as it is while
being open for proposals.


Andre

[PATCH v2 2/2] Bluetooth: set the strict duplicate filter quirk on Apple Broadcom controllers

[Andre Eikmeyer]

btbcm_finalize() sets HCI_QUIRK_STRICT_DUPLICATE_FILTER, but bcm_setup()
returns before it when no patch file was loaded. The MacBookPro15,1 has
none for its BCM4364B0 ("BCM: firmware Patch file not found").
hci_bcm4377 does not use btbcm_finalize() and never sets the quirk. A
service discovery then scans with "Filter duplicates: Enabled", and the
controller reports an address once per discovery cycle of about 10.7 s.
A Mac that changed its advertisement data on the same address was
reported 6 s after the change, at the next cycle.

Set the quirk in hci_bcm on that path and in hci_bcm4377.

Tested-by: Yossef Osman <Yossef.Osman@proton.me>
Tested-by: Aditya Garg <aditya.garg@linux.dev>
Signed-off-by: Andre Eikmeyer <dev@deq.rocks>
---
 drivers/bluetooth/hci_bcm.c     | 5 ++++-
 drivers/bluetooth/hci_bcm4377.c | 5 +++++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index cf4f1455cf9..9eeeaf5d6b0 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -596,8 +596,11 @@ static int bcm_setup(struct hci_uart *hu)
 	if (err)
 		return err;
 
-	if (!fw_load_done)
+	if (!fw_load_done) {
+		/* btbcm_finalize() sets this after loading a patch file */
+		hci_set_quirk(hu->hdev, HCI_QUIRK_STRICT_DUPLICATE_FILTER);
 		return 0;
+	}
 
 	/* Init speed if any */
 	if (bcm->dev && bcm->dev->init_speed)
diff --git a/drivers/bluetooth/hci_bcm4377.c b/drivers/bluetooth/hci_bcm4377.c
index 30fcadfae3f..66cdd896c95 100644
--- a/drivers/bluetooth/hci_bcm4377.c
+++ b/drivers/bluetooth/hci_bcm4377.c
@@ -2391,6 +2391,11 @@ static int bcm4377_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 	hdev->set_bdaddr = bcm4377_hci_set_bdaddr;
 	hdev->setup = bcm4377_hci_setup;
 
+	/* The controller reports an address once per scan with duplicate
+	 * filtering, also after its advertisement data changed.
+	 */
+	hci_set_quirk(hdev, HCI_QUIRK_STRICT_DUPLICATE_FILTER);
+
 	if (bcm4377->hw->broken_mws_transport_config)
 		hci_set_quirk(hdev, HCI_QUIRK_BROKEN_MWS_TRANSPORT_CONFIG);
 	if (bcm4377->hw->broken_ext_scan)