Hi Luiz, On Fri, May 10, 2024, at 16:33, Luiz Augusto von Dentz wrote: > Hi Sven, Hector, > > On Fri, May 10, 2024 at 5:55 AM Sven Peter <sven@xxxxxxxxxxxxx> wrote: >> >> Hi, >> >> >> On Fri, May 10, 2024, at 05:13, Hector Martin wrote: >> > Hi, >> > >> > On 2024/05/10 7:41, Luiz Augusto von Dentz wrote: >> > <snip> >> > >> >> If I print the actual value then we got: >> >> >> >> Primary PHY: Reserved (0x81) >> >> >> >> I guess one needs to disregard the reserved range, well until they are >> >> no longer reserved then it will no longer work. Perhaps we should talk >> >> to broadcom to know what is up with using reserved values and if that >> >> is an apple thing then perhaps we could ask them to provide firmware >> >> that acts according to the spec. >> > >> > Apple and Broadcom do not support Linux on this platform. The kernel has >> > to work with the existing firmware (which is the firmware macOS uses), >> > we don't get to request changes. If the firmware has quirks the kernel >> > has to deal with it, that's how it goes. It would be great if we had >> > vendor support, but that is not something we can control. This is common >> > (Linux is full of quirks to support noncompliant hardware/firmware). > > While this may work for a dedicated driver I don't think it is that > easy when we are talking about a standard interface, except if you are > going to maintain a separate HCI layer at the driver to intercept the > traffic this will cause a lot of regression to users unaware to the > fact, and it is not like you can't get rid of it, just plug an > external Bluetooth dongle that behaves properly. > >> While I agree with Hector here that they won't even talk to us it's >> sometimes possible to figure out what exactly they were thinking with >> their reserved values. Apple provides "Additional Tools for XCode" which >> include their "PacketLogger" which contains most of their vendor >> specific hacks with a human readable explanation. I wasn't able to generate >> this specific event with my hardware here but I was able to inject a custom >> event into their trace format and then load it and see how it's decoded. >> >> From a very brief look it appears that they AND Primary_PHY/Secondary_PHY with >> 0x1f to decode it and then support all values defined in the bluetooth >> spec, i.e. "no packets", "LE 1M", "LE 2M" and "LE coded". No idea what the >> higher bits mean though since they are ignored and don't seem to be decoded. > > Yeah, I think I saw something like that not long ago, we might need > yet another quirk to deal with that though. Agreed. We had a similar situation with this very same broken hardware when I originally upstreamed the driver: Apple and/or Broadcom decided to use the upper event type bits inside LE Extended Advertising Reports for the channel on which the frame has been received [1]. I originally proposed a quick to drop these reserved bits but we then later decided to just do it unconditionally [2]. [1] https://lore.kernel.org/linux-bluetooth/20220801103633.27772-4-sven@xxxxxxxxxxxxx/ [2] https://lore.kernel.org/linux-bluetooth/220ab728-ed5b-415d-ab15-47a7153e8e5c@xxxxxxxxxxxxxxxx/ Best, Sven
