Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-4497-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
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: <afd2cfb0-1406-4a17-a0d1-f7f6b073d26f@app.fastmail.com>
In-Reply-To: 
 <CABBYNZKkkAA0KXDR-R0M5jCHNhnLrpH38Ympfm5-JgC0yiD7Bw@mail.gmail.com>
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>
 <4e194251-d175-49d0-af03-b2cdd8a30fe0@app.fastmail.com>
 <CABBYNZKkkAA0KXDR-R0M5jCHNhnLrpH38Ympfm5-JgC0yiD7Bw@mail.gmail.com>
Date: Fri, 10 May 2024 16:43:30 +0200
From: "Sven Peter" <sven@svenpeter.dev>
To: "Luiz Augusto von Dentz" <luiz.dentz@gmail.com>
Cc: "Hector Martin" <marcan@marcan.st>, "Janne Grunau" <j@jannau.net>,
 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;charset=utf-8
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFAM Sven Peter <sven@svenpeter.dev=
> 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 t=
hat
>> >> is an apple thing then perhaps we could ask them to provide firmwa=
re
>> >> that acts according to the spec.
>> >
>> > Apple and Broadcom do not support Linux on this platform. The kerne=
l has
>> > to work with the existing firmware (which is the firmware macOS use=
s),
>> > we don't get to request changes. If the firmware has quirks the ker=
nel
>> > 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 c=
ommon
>> > (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" wh=
ich
>> include their "PacketLogger" which contains most of their vendor
>> specific hacks with a human readable explanation. I wasn't able to ge=
nerate
>> 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 decod=
ed.
>>
>> 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 wha=
t the
>> higher bits mean though since they are ignored and don't seem to be d=
ecoded.
>
> 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 w=
hen 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 la=
ter
decided to just do it unconditionally [2].


[1] https://lore.kernel.org/linux-bluetooth/20220801103633.27772-4-sven@=
svenpeter.dev/
[2] https://lore.kernel.org/linux-bluetooth/220ab728-ed5b-415d-ab15-47a7=
153e8e5c@www.fastmail.com/


Best,


Sven