Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-783-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Feedback-ID: i51094778:Fastmail
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Sven Peter <sven@svenpeter.dev>
Precedence: bulk
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v3] Bluetooth: Fix Bluetooth for BCM4377 on T2 Intel MacBooks
Message-Id: <AB87C916-9CF9-4B8C-AFF5-74CA4151C4FC@svenpeter.dev>
Date: Thu, 28 Dec 2023 10:46:57 +0100
Cc: Paul Menzel <pmenzel@molgen.mpg.de>, Felix Zhang <mrman@mrman314.tech>,
 linux-bluetooth@vger.kernel.org, stable@vger.kernel.org,
 Johan Hovold <johan+linaro@kernel.org>, Hector Martin <marcan@marcan.st>,
 Bagas Sanjaya <bagasdotme@gmail.com>,
 Alyssa Rosenzweig <alyssa@rosenzweig.io>,
 Marcel Holtmann <marcel@holtmann.org>,
 Johan Hedberg <johan.hedberg@gmail.com>,
 Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
 Orlando Chamberlain <orlandoch.dev@gmail.com>, kekrby@gmail.com,
 admin@kodeit.net, Janne Grunau <j@jannau.net>,
 Aditya Garg <gargaditya08@live.com>, asahi@lists.linux.dev,
 linux-kernel@vger.kernel.org
To: Johan Hovold <johan@kernel.org>

=EF=BB=BFSending this again because Apple mail decided to default to HTML
mails since the last update apparently *sigh*


=EF=BB=BFHi,


> On Dec 27, 2023, at 11:30, Johan Hovold <johan@kernel.org> wrote:
>=20
> On Mon, Dec 25, 2023 at 09:26:05PM +0100, Paul Menzel wrote:
>=20
>> Thank you very much for the patch. I am adding Johan to Cc field.
>=20
> Thanks for the report. Guess I could use a break from the proverbial
> eggnog.
>=20
>> Am 25.12.23 um 21:01 schrieb Felix Zhang:
>>> Starting v6.5, Bluetooth does not work at all on my T2 MacBookAir9,1
>>> with the BCM4377 chip.  When I boot up the computer, go into
>> Somehow a blank line snug in above.
>>> bluetoothctl, and then try to run commands like scan on, show, list,
>>> it returns "No default controller available."  I have tried reloading
>>> the
>> It=E2=80=99d be great if you reflowed for 75 characters per line (also be=
low).
>>> kernel module, in which the log outputs "{Added,Removed} hci0
>>> (unconfigured)."  With this patch, I am able to use Bluetooth as
>>> normal
>>> without any errors regarding hci0 being unconfigured.  However, an
>>> issue is still present where sometimes hci_bcm4377 will have to be
>>> reloaded in order to get bluetooth to work.  I believe this was still
>>> present before the previously mentioned commit.
>>> Due to the bit HCI_QUIRK_USE_BDADDR_PROPERTY being always set in
>>> drivers/bluetooth/hci_bcm4377.c (line 2371), the chip would be left
>>> unconfigured on kernels compiled after commit 6945795bc81a
>>> ("Bluetooth:
>>> fix use-bdaddr-property quirk") due to a change in its logic.  On the
>>> M1 Macs, the device would be configured in the devicetree.  However,
>>> that is not the case on T2 Macs.  Because the bluetooth adapter is
>>> left
>>> unconfigured, it is not usable in the operating system.  In order to
>>> circumvent this issue, a flag is added to prevent the bit from being
>>> set on the BCM4377, while setting it on the other devices.
>=20
> The commit you tracked this down to restored the original semantics for
> HCI_QUIRK_USE_BDADDR_PROPERTY, which means that it should only be set
> for devices with an invalid address.
>=20
> The Broadcom BCM4377 driver has so far been setting this flag
> unconditionally which now potentially results in also valid addresses
> being marked as invalid.
>=20
> I've just sent a patch that makes sure to only mark invalid addresses as
> invalid:
>=20
> https://lore.kernel.org/lkml/20231227101003.10534-1-johan+linaro@kernel.or=
g/
>=20
> Note however that the flag still needs to be set in case your device
> lacks storage for a unique device address so you cannot simply drop it
> for some device classes as you do below (unless you are certain that
> these devices will always have a valid address).


We do know that though.

BCM4377 is present on Apple=E2=80=99s x86 Macs and always has internal stora=
ge
for the address. If the board comes up without an address there=E2=80=99s no=
thing
much we can do because the address isn=E2=80=99t provided by ACPI or anythin=
g
else and setting the invalid address quirk for that situation seems appropri=
ate.

BCM4378/4387 is present on Apple=E2=80=99s ARM Macs and never has internal s=
torage.
The address is always provided by our bootloader in the device tree.
These should always unconditionally set HCI_QUIRK_USE_BDADDR_PROPERTY
just like this patch does.


Best,


Sven=