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 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. Sven
