lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <ZYv95BOowY38NesX@hovoldconsulting.com> Date: Wed, 27 Dec 2023 11:35:16 +0100 From: Johan Hovold <johan@...nel.org> To: Felix Zhang <mrman@...an314.tech> Cc: linux-bluetooth@...r.kernel.org, stable@...r.kernel.org, marcan@...can.st, bagasdotme@...il.com, sven@...npeter.dev, alyssa@...enzweig.io, marcel@...tmann.org, johan.hedberg@...il.com, luiz.dentz@...il.com, orlandoch.dev@...il.com, kekrby@...il.com, admin@...eit.net, j@...nau.net, gargaditya08@...e.com, asahi@...ts.linux.dev, linux-kernel@...r.kernel.org Subject: Re: [PATCH v4] Bluetooth: Fix Bluetooth for BCM4377 on T2 Intel MacBooks On Mon, Dec 25, 2023 at 03:21:04PM -0500, Felix Zhang wrote: > 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 bluetoothctl, and then try to run commands like scan on, > show, list, it returns "No default controller available." I have > tried reloading the 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. > > I would also like to thank Kerem Karabay <kekrby@...il.com> for > assisting me with this patch. > > Fixes: 6945795bc81a ("Bluetooth: fix use-bdaddr-property quirk") > Cc: <stable@...r.kernel.org> > Signed-off-by: Felix Zhang <mrman@...an314.tech> > --- > v4: > * Adjust the format to pass the CI (again). > * Shorten description As explained here: https://lore.kernel.org/all/ZYv8tp3fMiAqK8OI@hovoldconsulting.com/ I don't this is necessarily the right fix. The BD_ADDR quirk property should not be set unconditionally but it is still needed for devices that lack storage for a unique device address. So the following fix is needed either way and is probably all that is needed here: https://lore.kernel.org/lkml/20231227101003.10534-1-johan+linaro@kernel.org/ Johan
Powered by blists - more mailing lists