Lo, this is your Linux kernel regression tracker speaking. I have this regression on the radar of regzbot, my Linux regression tracking bot: https://linux-regtracking.leemhuis.info/regzbot/regression/4970a940-211b-25d6-edab-21a815313954@xxxxxxxxxxxxxx/ Has any progress been made since below mail? If not: how can we get the ball rolling again and get this regression fixed? Ciao, Thorsten P.S.: I have no personal interest in this issue. Hence, feel free to exclude me on further messages in this thread after the first reply, as I'm only posting this mail to hopefully get a status update and things rolling again. #regzbot poke On 04.10.21 13:15, Orlando Chamberlain wrote: > On Fri, 01 Oct 2021 23:28:03 +1000 > "Orlando Chamberlain" <redecorating@xxxxxxxxxxxxxx> wrote: >> On Fri, 01 Oct 2021 19:35:16 +1000 >> "Marcel Holtmann" <marcel@xxxxxxxxxxxx> wrote: >> >>> I would really prefer to do that via the ACPI table matching in >>> hci_bcm.c and not via some magic chip id check. >> >> Initially I thought we may be able to do this based off BCM2E7C (which >> is in the DSDT table which I'll attach), however it seems like many >> Macs also have that (i.e. MacBookPro14,1, MacBookAir8,1, MacBook9,1), >> so unless all these don't support LE Read Transmit Power, (which >> would be hard to determine), I don't know if BCM2E7C can be used to >> quirk it. > > I think there aren't any Macs that support LE Read Transmit Power. > > I checked the Bluetooth spec here > https://www.bluetooth.com/specifications/specs/core-specification-5-1/ > and it seems like 5.1 is the first version that mentions LE Read > Transmit Power. It says 5.1 was adopted on 21 Jan 2019. > > As far as I know, all of the models released after that date that have > ever had working Bluetooth were affected, while unaffected models were > released before that date (and thus shouldn't support LE Read Transmit > Power? This is at least true for the MacBookPro15,1, a 2018 model that > doesn't support the command). > > I think this means that no Apple computer released so far supports the > command, so disabling LE Read Transmit Power for all Apple controllers > based off "apple-uart-blth" (probably a better choice than "BCM2E7C") > won't affect any controllers that actually support it. > > Device (BLTH) > { > Name (_HID, EisaId ("BCM2E7C")) // _HID: Hardware ID > Name (_CID, "apple-uart-blth") // _CID: Compatible ID > Name (_UID, One) // _UID: Unique ID > Name (_ADR, Zero) // _ADR: Address > > As to future Apple computers, they seem to no longer be using UART and > instead have a second Broadcom PCI device (the first being for WiFi) > that is for Bluetooth. 3 Intel Macs Models have this second device > (MacBookPro15,4, MacBookPro16,3 and MacBookAir9,1), and so do the M1 > ones. > > I can't say that they won't move back to UART at some point and then > support LE Read Transmit Power, but if they do, I don't think they > would move back to x86_64, so only having this quirk activated when > compiling for x86_64 might be an option if that's an issue. > >> I'll try to see if I can find something else in the ACPI tables that >> can be used as a quirk. (I'll see if I can get the table of a similar >> model that wasn't affected and compare the BLTH sections) > > The BLTH sections were the same for affected and unaffected macs. > > > > Would disabling LE Read Transmit Power if the controller is > "apple-uart-blth" work for you? >
