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. -- Luiz Augusto von Dentz
