[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZKvvN53dM5vbAFGi@hovoldconsulting.com>
Date: Mon, 10 Jul 2023 13:44:55 +0200
From: Johan Hovold <johan@...nel.org>
To: Amit Pundir <amit.pundir@...aro.org>
Cc: Johan Hovold <johan+linaro@...nel.org>,
Marcel Holtmann <marcel@...tmann.org>,
Johan Hedberg <johan.hedberg@...il.com>,
Luiz Augusto von Dentz <luiz.dentz@...il.com>,
Matthias Kaehlcke <mka@...omium.org>,
linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org,
Linux regressions mailing list <regressions@...ts.linux.dev>
Subject: Re: [PATCH RESEND 2/2] Bluetooth: fix use-bdaddr-property quirk
On Fri, Jul 07, 2023 at 07:12:35PM +0530, Amit Pundir wrote:
> On Fri, 7 Jul 2023 at 16:37, Johan Hovold <johan@...nel.org> wrote:
> > 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).
>
> Sorry for the confusion, I missed the part where I do see these
> messages when the kernel module is loaded but the direct firmware
> loading fails.
>
> 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: Direct firmware load for qca/crbtfw21.tlv failed with error -2
> Bluetooth: hci0: QCA Failed to request file: qca/crbtfw21.tlv (-2)
> Bluetooth: hci0: QCA Failed to download patch (-2)
> Bluetooth: hci0: QCA preshutdown_cmd failed (-56)
>
> This happens in all the cases (working and non-working BT) because
> filesystem is not mounted by that time. I'm running AOSP and all the
> kernel modules get loaded from a ramdisk. But in the working case, the
> firmware loading kicks in again later in the boot process and BT gets
> initiazed..
>
> With this patch, after the first attempt to load the firmware fails,
> the firmware loading doesn't kick-in again. Also even if I keep the
> firmware in ramdisk then the direct firmware loading from ramdisk
> happens but BT still doesn't work
> https://bugs.linaro.org/attachment.cgi?id=1148.
So everything appears to work as intended. First, the firmware needs to
be in your initramfs if you want to avoid that initial fw load failure.
And after that you need to provide a valid device address as these
devices ship without one.
Once you set the address, the firmware should be loaded if it hasn't
been already.
> > Are there any error messages in the log when running with this patch?
>
> I don't see any relevant error message in dmesg. I'll check if I can
> find a command line BT debug tool which I can use on AOSP for
> debugging. There used to be a few hci command line tools, when I
> looked into it a few years ago. Not sure if they are still around and
> useful.
Yeah, I'm not sure how you set the device address with the Android
stack, but there must be some way as there are other bluetooth
controllers out there which similarly need a valid address before they
can be used.
Johan
Powered by blists - more mailing lists