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
Date: Fri, 10 May 2024 16:43:30 +0200 [thread overview]
Message-ID: <afd2cfb0-1406-4a17-a0d1-f7f6b073d26f@app.fastmail.com> (raw)
In-Reply-To: <CABBYNZKkkAA0KXDR-R0M5jCHNhnLrpH38Ympfm5-JgC0yiD7Bw@mail.gmail.com>
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@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 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@svenpeter.dev/
[2] https://lore.kernel.org/linux-bluetooth/220ab728-ed5b-415d-ab15-47a7153e8e5c@www.fastmail.com/
Best,
Sven
prev parent reply other threads:[~2024-05-10 14:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240405204037.3451091-1-luiz.dentz@gmail.com>
2024-05-09 16:06 ` [PATCH v1] Bluetooth: hci_sync: Use advertised PHYs on hci_le_ext_create_conn_sync Janne Grunau
2024-05-09 16:30 ` Luiz Augusto von Dentz
2024-05-09 20:09 ` Janne Grunau
2024-05-09 22:23 ` Luiz Augusto von Dentz
2024-05-09 22:41 ` Luiz Augusto von Dentz
2024-05-10 3:13 ` Hector Martin
2024-05-10 9:54 ` Sven Peter
2024-05-10 14:33 ` Luiz Augusto von Dentz
2024-05-10 14:43 ` Sven Peter [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=afd2cfb0-1406-4a17-a0d1-f7f6b073d26f@app.fastmail.com \
--to=sven@svenpeter.dev \
--cc=asahi@lists.linux.dev \
--cc=j@jannau.net \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=marcan@marcan.st \
--cc=regressions@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).