Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-4461-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Feedback-ID: i51094778:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-443-g0dc955c2a-fm-20240507.001-g0dc955c2
Precedence: bulk
MIME-Version: 1.0
Message-Id: <4e194251-d175-49d0-af03-b2cdd8a30fe0@app.fastmail.com>
In-Reply-To: <70078624-d766-4db6-8ddb-511251baf0f2@marcan.st>
References: <20240405204037.3451091-1-luiz.dentz@gmail.com>
 <Zjz0atzRhFykROM9@robin>
 <CABBYNZLMODHp+jBu2oVDC5Pg6fyAKJugQF0N-XgarjWQJJPObg@mail.gmail.com>
 <Zj0tcmseJCjR4hK2@robin>
 <CABBYNZLnYz-vPrMbtsJTsLPsyo62j+cxctSkLjRom3bWEU9N3A@mail.gmail.com>
 <CABBYNZJ-6oyLnBov9H_jym9m-9qiUt1ELxYGuBOdZT29aj9MCA@mail.gmail.com>
 <70078624-d766-4db6-8ddb-511251baf0f2@marcan.st>
Date: Fri, 10 May 2024 11:54:40 +0200
From: "Sven Peter" <sven@svenpeter.dev>
To: "Hector Martin" <marcan@marcan.st>,
 "Luiz Augusto von Dentz" <luiz.dentz@gmail.com>,
 "Janne Grunau" <j@jannau.net>
Cc: linux-bluetooth@vger.kernel.org,
 "regressions@lists.linux.dev" <regressions@lists.linux.dev>,
 asahi@lists.linux.dev
Subject: Re: [PATCH v1] Bluetooth: hci_sync: Use advertised PHYs on
 hci_le_ext_create_conn_sync
Content-Type: text/plain

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