bluetooth: strip Broadcom vendor bits from legacy LE adv report type - #57
bluetooth: strip Broadcom vendor bits from legacy LE adv report type#57josemiguelo wants to merge 1 commit into
Conversation
|
I believe AI has been used here? |
|
All this to suppress noise on journal?? never had an issue with keyboard (Reddragon k530) or mouse (Logitech Pro X) |
Yes. Used it to test the solution and to redact the summary |
I don't care about the noise on the journal. Logitech MX3 and Keychron keyboard were not reconnecting automatically. With this they reconnecting within 2 seconds even after waking up from suspend |
|
Is this an AI novel for 5 lines of code? I was not able to figure out what is not working even after 3 times of reading. Could you describe your actual issue in just one sentence and describe the solution in a second sentence? |
fdc004d to
9dda525
Compare
Sorry for the inconvenience @deqrocks. I understand the summary may have had a lot of unnecessary text so I updated the PR description. Here's also more anwers to your questions: Why not patch the peripherals' drivers? They never get the chance: the report is dropped in hci_event.c before the kernel knows which device it is or any peer driver (hidpp etc.) is involved. And the peers aren't at fault — btmon shows the same mouse packet arriving mangled 19 times and clean the 20th (reconnecting in 70 ms), so the packets are spec-valid on air and our controller corrupts them on the way up. Why not mainline? I'll submit it upstream too. Posted here first because only ROM-firmware T2 controllers reproduce it, this repo already carries the extended-adv counterpart of this exact quirk (9001-…-LE-Extended-Adv-Report.patch), and t2linux users are the ones who can actually test it. If it lands mainline I'll drop it from here. I hope this answers can be of any help now |
T2 ROM-firmware controllers (BCM4364B3, no patchram) mangle the legacy LE adv report Event_Type with vendor bits, so the kernel drops directed reconnect adverts and bonded LE peripherals never auto-reconnect; mask the type to its low nibble for Broadcom. Legacy counterpart of the 9001 extended-report quirk. Applies with git am on v7.1.9 and v7.2.3.
9dda525 to
bc9942b
Compare
4 participants
Bluetooth: LE auto-reconnect never fires on BCM4364 (ROM firmware) — strip vendor bits from adv report type
Hardware / software
hci_uart_bcm, ROM firmware (BCM (001.016.091) build 0115; nobrcm/BCM.hcdexists for this model — t2linux only ships BT firmware for 15,4 / 16,3 / Air9,1)kernel-7.0.10-201.t2.fc44,6.19.12-210.t2and — with thestock module — on the current
kernel-7.1.9-200.t2.fc44, so this is not an old-kernel artifact.TLDR
Issue: On T2 Macs where the BCM4364 runs ROM firmware (t2linux ships no .hcd for these models), the controller sets vendor bits in the Event_Type of legacy LE Advertising Reports (0x81/0xa1/…), so process_adv_report() discards ~95% of bonded peripherals' directed reconnect adverts — BLE devices stay disconnected on wake until a rare clean report slips through.
Fix: For Broadcom controllers only (hdev->manufacturer == 15), mask an out-of-range Event_Type to its low nibble before validation — reports that are valid today take the same path as before, and Broadcom controllers with real firmware never emit these types, so the quirk is inert everywhere else.
Only these two devices? No — the corruption happens on the local controller, so every bonded BLE peripheral is affected; the mouse and keyboard are just the two I own. BR/EDR devices are untouched (my Sony earbuds on the same machine reconnect fine — classic paging doesn't go through this path).
Long explanation
Symptom
Bonded LE HID devices don't reconnect when woken.
dmesgfills withTally over several boots (144 drops):
0xa1×350x81×350x91×170x11×80x21×60x90×40x80×40x14×40xa0×30x10×20xa20x930x240x23. The low nibble is always a valid legacy type (0–4); the upper nibble is0x1/0x2/0x8/0x9/0xavendor noise.Root cause (btmon)
The controller reports the mouse's reconnect adverts with garbage high bits in
Event_Typemost of the time, and cleanly sometimes:hci_le_adv_report_evt()→process_adv_report()rejects any type >LE_ADV_SCAN_RSP, so the passive-scan auto-connect for bonded peripherals never triggers on the mangled reports. Reconnection only happens when a report slips through clean (~1 in 20). Every userspace path (bluetoothctl connect, L2CAP sockets) goes through the same scan-then-connect code, so no userspace workaround exists — abluetoothctl connectloop only raises the odds.Fix
Mask the type to its low nibble for Broadcom controllers (
hdev->manufacturer == 15) when it is out of range, before validation. 2 lines of logic innet/bluetooth/hci_event.c; other vendors untouched.This repo has carried the same shape of quirk before:
9001-Bluetooth-hci_event-Add-quirk-to-ignore-byte-in-LE-Extended-Adv-Report.patchpatched the extended adv report path in this very file for T2 controllers. This is the legacy-report counterpart.Scope / risk
hdev->manufacturer == 15), not on the peer device, and only forEvent_Type > 0x04— reports that were being discarded anyway. Valid reports (0x0–0x4) take the exact same path as before, so devices that work today are unaffected; the BR/EDR path is not involved.0x01for the same packet): a strayLE Create Connectionthat times out after a few seconds. No effect on established links.