On Fri, Jul 07, 2023 at 03:11:11PM +0530, Amit Pundir wrote:
> On Wed, 31 May 2023 at 14:35, Johan Hovold <johan+linaro@xxxxxxxxxx> wrote:
> >
> > Devices that lack persistent storage for the device address can indicate
> > this by setting the HCI_QUIRK_INVALID_BDADDR which causes the controller
> > to be marked as unconfigured until user space has set a valid address.
> >
> > The related HCI_QUIRK_USE_BDADDR_PROPERTY was later added to similarly
> > indicate that the device lacks a valid address but that one may be
> > specified in the devicetree.
> >
> > As is clear from commit 7a0e5b15ca45 ("Bluetooth: Add quirk for reading
> > BD_ADDR from fwnode property") that added and documented this quirk and
> > commits like de79a9df1692 ("Bluetooth: btqcomsmd: use
> > HCI_QUIRK_USE_BDADDR_PROPERTY"), the device address of controllers with
> > this flag should be treated as invalid until user space has had a chance
> > to configure the controller in case the devicetree property is missing.
> >
> > As it does not make sense to allow controllers with invalid addresses,
> > restore the original semantics, which also makes sure that the
> > implementation is consistent (e.g. get_missing_options() indicates that
> > the address must be set) and matches the documentation (including
> > comments in the code, such as, "In case any of them is set, the
> > controller has to start up as unconfigured.").
> This patch broke Bluetooth on Dragonboard 845c (SDM845) devboard.
> Reverting this patch fixes the BT breakage and I see the following
> messages in dmesg:
>
> Bluetooth: hci0: setting up wcn399x
> Bluetooth: hci0: QCA Product ID :0x0000000a
> Bluetooth: hci0: QCA SOC Version :0x40010214
> Bluetooth: hci0: QCA ROM Version :0x00000201
> Bluetooth: hci0: QCA Patch Version:0x00000001
> Bluetooth: hci0: QCA controller version 0x02140201
> Bluetooth: hci0: QCA Downloading qca/crbtfw21.tlv
> Bluetooth: hci0: QCA Downloading qca/crnv21.bin
> Bluetooth: hci0: QCA setup on UART is completed
That's odd. You should still see the above messages also with this patch
applied, but you may now need to provide a valid device address before
being able to use device in case the bootloader has not provided one
(e.g. using btmgmt).
Are there any error messages in the log when running with this patch?
Does
btmgmt --index 0 public-addr <bdaddr>
work?
Johan
