[PATCH 2/4] Bluetooth: btbcm: clear vendor bits in LE advertising report types

[Aditya Garg]

> On 4 Nov 2026, at 8:55 PM, Luiz Augusto von Dentz <luiz.dentz at gmail.com> wrote:
> 
> Hi Andre,
> 
>> On Wed, Nov 4, 2026 at 10:16 AM Andre Eikmeyer <dev at deq.rocks> wrote:
>> 
>> The BCM4364B0 of the MacBookPro15,1 (UART) and the BCM4377 of the
>> MacBookAir9,1 (PCIe) set bits 4, 5 and 7 of the event type in LE
>> Advertising Report events. btmon on the 15,1 shows types 0x10, 0x13,
>> 0x14, 0x20, 0x23, 0x24, 0x93 and 0xa0 next to plain 0x00, 0x03 and 0x04,
>> the same advertiser shows up as 0x13, 0x23 and 0x03. The kernel log of
>> the 9,1 lists 0x10 to 0x24 and 0x80, 0x83, 0x90, 0x93, 0xa0, 0xa3.
>> process_adv_report() drops every type above 0x04 with "Unknown
>> advertising packet type", so most advertisements never reach the host.
>> An AirDrop sender was reported as 0x23, 0x23 and 0x13 and only the
>> fourth report, 0x03, reached BlueZ 32 s after the first one.
>> 
>> Add btbcm_fixup_le_adv_report(), which clears the bits above the type,
>> and call it from hci_bcm on Apple machines and from hci_bcm4377 before
>> the event goes to the core.
>> 
>> Suggested-by: Jose Miguel Ochoa <josemiguelo.ochoa at gmail.com>
>> Tested-by: Yossef Osman <Yossef.Osman at proton.me>
>> Tested-by: Aditya Garg <aditya.garg at linux.dev>
>> Signed-off-by: Andre Eikmeyer <dev at deq.rocks>
>> ---
>> drivers/bluetooth/btbcm.c       | 30 ++++++++++++++++++++++++++++++
>> drivers/bluetooth/btbcm.h       |  5 +++++
>> drivers/bluetooth/hci_bcm.c     |  5 +++++
>> drivers/bluetooth/hci_bcm4377.c |  1 +
>> 4 files changed, 41 insertions(+)
>> 
>> diff --git a/drivers/bluetooth/btbcm.c b/drivers/bluetooth/btbcm.c
>> index 0facfe62333..527a5c75fd6 100644
>> --- a/drivers/bluetooth/btbcm.c
>> +++ b/drivers/bluetooth/btbcm.c
>> @@ -282,6 +282,36 @@ void btbcm_set_acl_priority_on_connect(struct hci_dev *hdev, struct sk_buff *skb
>> }
>> EXPORT_SYMBOL_GPL(btbcm_set_acl_priority_on_connect);
>> 
>> +/* The BCM4364 and BCM4377 of the T2 Macs set bits above the event type of LE
>> + * Advertising Reports, 0x13 and 0x23 for ADV_NONCONN_IND for example. The
>> + * core drops reports of unknown types, so clear them.
>> + */
>> +void btbcm_fixup_le_adv_report(struct sk_buff *skb)
>> +{
>> +       struct hci_event_hdr *hdr = (void *)skb->data;
>> +       struct hci_ev_le_advertising_info *info;
>> +       u8 *p, *end;
>> +       u8 num;
>> +
>> +       if (hci_skb_pkt_type(skb) != HCI_EVENT_PKT ||
>> +           skb->len < HCI_EVENT_HDR_SIZE + 2 || hdr->evt != HCI_EV_LE_META)
>> +               return;
>> +
>> +       p = skb->data + HCI_EVENT_HDR_SIZE;
>> +       if (p[0] != HCI_EV_LE_ADVERTISING_REPORT)
>> +               return;
>> +
>> +       num = p[1];
>> +       p += 2;
>> +       end = skb->data + skb->len;
>> +       while (num-- && p + sizeof(*info) + 1 <= end) {
>> +               info = (void *)p;
>> +               info->type &= 0x0f;
>> +               p += sizeof(*info) + info->length + 1;
>> +       }
>> +}
>> +EXPORT_SYMBOL_GPL(btbcm_fixup_le_adv_report);
> 
> I don't think I agree with this being cleaner then doing at
> hci_event.though; not only is it more code but it also walks the
> packet which is inefficient and may have security implications as
> well.

The hci_event patch makes it apply for all Broadcom chips. The author who sent that patch themselves use a T2 Mac. I doubt all Broadcom chips need this because there have been no bug reports from normal PCs.