diff mbox series

[RESEND,v2] Bluetooth: btqcomsmd: Fix command timeout after setting BD address

Message ID 20221018085431.2913217-1-stephan.gerhold@kernkonzept.com (mailing list archive)
State New, archived
Headers show
Series [RESEND,v2] Bluetooth: btqcomsmd: Fix command timeout after setting BD address | expand

Checks

Context Check Description
tedd_an/pre-ci_am success Success
tedd_an/checkpatch success Checkpatch PASS
tedd_an/gitlint success Gitlint PASS
tedd_an/subjectprefix success PASS
tedd_an/buildkernel success Build Kernel PASS
tedd_an/buildkernel32 success Build Kernel32 PASS
tedd_an/incremental_build success Pass
tedd_an/testrunnersetup success Test Runner Setup PASS
tedd_an/testrunnerl2cap-tester success Total: 40, Passed: 40 (100.0%), Failed: 0, Not Run: 0
tedd_an/testrunneriso-tester success Total: 55, Passed: 55 (100.0%), Failed: 0, Not Run: 0
tedd_an/testrunnerbnep-tester success Total: 1, Passed: 1 (100.0%), Failed: 0, Not Run: 0
tedd_an/testrunnermgmt-tester success Total: 494, Passed: 494 (100.0%), Failed: 0, Not Run: 0
tedd_an/testrunnerrfcomm-tester success Total: 11, Passed: 11 (100.0%), Failed: 0, Not Run: 0
tedd_an/testrunnersco-tester success Total: 12, Passed: 12 (100.0%), Failed: 0, Not Run: 0
tedd_an/testrunnerioctl-tester success Total: 28, Passed: 28 (100.0%), Failed: 0, Not Run: 0
tedd_an/testrunnermesh-tester success Total: 10, Passed: 10 (100.0%), Failed: 0, Not Run: 0
tedd_an/testrunnersmp-tester success Total: 8, Passed: 8 (100.0%), Failed: 0, Not Run: 0
tedd_an/testrunneruserchan-tester success Total: 4, Passed: 4 (100.0%), Failed: 0, Not Run: 0

Commit Message

Stephan Gerhold Oct. 18, 2022, 8:54 a.m. UTC
On most devices using the btqcomsmd driver (e.g. the DragonBoard 410c
and other devices based on the Qualcomm MSM8916/MSM8909/... SoCs)
the Bluetooth firmware seems to become unresponsive for a while after
setting the BD address. On recent kernel versions (at least 5.17+)
this often causes timeouts for subsequent commands, e.g. the HCI reset
sent by the Bluetooth core during initialization:

    Bluetooth: hci0: Opcode 0x c03 failed: -110

Unfortunately this behavior does not seem to be documented anywhere.
Experimentation suggests that the minimum necessary delay to avoid
the problem is ~150us. However, to be sure add a sleep for > 1ms
in case it is a bit longer on other firmware versions.

Older kernel versions are likely also affected, although perhaps with
slightly different errors or less probability. Side effects can easily
hide the issue in most cases, e.g. unrelated incoming interrupts that
cause the necessary delay.

Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver")
Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
---
(Unmodified resend of the v2 I sent back in June, it seems to have
 disappeared from patchwork)

I tested this using a script that reboots repeatedly and checks for the
error. With this patch, BT shows up successfully for 100+ consecutive
boots. Without this patch it usually fails after 1-5 boots (or even
always on some boards).

Changes in v2:
  - Clarify commit message: Add affected devices and kernel versions
---
 drivers/bluetooth/btqcomsmd.c | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

Comments

bluez.test.bot@gmail.com Oct. 18, 2022, 10:22 a.m. UTC | #1
This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=686199

---Test result---

Test Summary:
CheckPatch                    PASS      1.42 seconds
GitLint                       PASS      0.82 seconds
SubjectPrefix                 PASS      0.61 seconds
BuildKernel                   PASS      42.50 seconds
BuildKernel32                 PASS      38.50 seconds
Incremental Build with patchesPASS      58.24 seconds
TestRunner: Setup             PASS      623.73 seconds
TestRunner: l2cap-tester      PASS      19.58 seconds
TestRunner: iso-tester        PASS      19.77 seconds
TestRunner: bnep-tester       PASS      7.70 seconds
TestRunner: mgmt-tester       PASS      121.78 seconds
TestRunner: rfcomm-tester     PASS      11.94 seconds
TestRunner: sco-tester        PASS      11.57 seconds
TestRunner: ioctl-tester      PASS      12.95 seconds
TestRunner: mesh-tester       PASS      9.72 seconds
TestRunner: smp-tester        PASS      11.25 seconds
TestRunner: userchan-tester   PASS      7.99 seconds



---
Regards,
Linux Bluetooth
Stephan Gerhold Nov. 14, 2022, 8:36 a.m. UTC | #2
Hi Luiz,

It looks like this patch will get archived again in patchwork end of
this week. Is there anything I can change to make it acceptable?

This is a fairly important fix to have Bluetooth working on these
devices, since it fails to initialize most of the times without it.

Thanks!
Stephan

On Tue, Oct 18, 2022 at 10:54:31AM +0200, Stephan Gerhold wrote:
> On most devices using the btqcomsmd driver (e.g. the DragonBoard 410c
> and other devices based on the Qualcomm MSM8916/MSM8909/... SoCs)
> the Bluetooth firmware seems to become unresponsive for a while after
> setting the BD address. On recent kernel versions (at least 5.17+)
> this often causes timeouts for subsequent commands, e.g. the HCI reset
> sent by the Bluetooth core during initialization:
> 
>     Bluetooth: hci0: Opcode 0x c03 failed: -110
> 
> Unfortunately this behavior does not seem to be documented anywhere.
> Experimentation suggests that the minimum necessary delay to avoid
> the problem is ~150us. However, to be sure add a sleep for > 1ms
> in case it is a bit longer on other firmware versions.
> 
> Older kernel versions are likely also affected, although perhaps with
> slightly different errors or less probability. Side effects can easily
> hide the issue in most cases, e.g. unrelated incoming interrupts that
> cause the necessary delay.
> 
> Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver")
> Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
> ---
> (Unmodified resend of the v2 I sent back in June, it seems to have
>  disappeared from patchwork)
> 
> I tested this using a script that reboots repeatedly and checks for the
> error. With this patch, BT shows up successfully for 100+ consecutive
> boots. Without this patch it usually fails after 1-5 boots (or even
> always on some boards).
> 
> Changes in v2:
>   - Clarify commit message: Add affected devices and kernel versions
> ---
>  drivers/bluetooth/btqcomsmd.c | 17 ++++++++++++++++-
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/bluetooth/btqcomsmd.c b/drivers/bluetooth/btqcomsmd.c
> index 2acb719e596f..11c7e04bf394 100644
> --- a/drivers/bluetooth/btqcomsmd.c
> +++ b/drivers/bluetooth/btqcomsmd.c
> @@ -122,6 +122,21 @@ static int btqcomsmd_setup(struct hci_dev *hdev)
>  	return 0;
>  }
>  
> +static int btqcomsmd_set_bdaddr(struct hci_dev *hdev, const bdaddr_t *bdaddr)
> +{
> +	int ret;
> +
> +	ret = qca_set_bdaddr_rome(hdev, bdaddr);
> +	if (ret)
> +		return ret;
> +
> +	/* The firmware stops responding for a while after setting the bdaddr,
> +	 * causing timeouts for subsequent commands. Sleep a bit to avoid this.
> +	 */
> +	usleep_range(1000, 10000);
> +	return 0;
> +}
> +
>  static int btqcomsmd_probe(struct platform_device *pdev)
>  {
>  	struct btqcomsmd *btq;
> @@ -162,7 +177,7 @@ static int btqcomsmd_probe(struct platform_device *pdev)
>  	hdev->close = btqcomsmd_close;
>  	hdev->send = btqcomsmd_send;
>  	hdev->setup = btqcomsmd_setup;
> -	hdev->set_bdaddr = qca_set_bdaddr_rome;
> +	hdev->set_bdaddr = btqcomsmd_set_bdaddr;
>  
>  	ret = hci_register_dev(hdev);
>  	if (ret < 0)
> -- 
> 2.30.2
>
diff mbox series

Patch

diff --git a/drivers/bluetooth/btqcomsmd.c b/drivers/bluetooth/btqcomsmd.c
index 2acb719e596f..11c7e04bf394 100644
--- a/drivers/bluetooth/btqcomsmd.c
+++ b/drivers/bluetooth/btqcomsmd.c
@@ -122,6 +122,21 @@  static int btqcomsmd_setup(struct hci_dev *hdev)
 	return 0;
 }
 
+static int btqcomsmd_set_bdaddr(struct hci_dev *hdev, const bdaddr_t *bdaddr)
+{
+	int ret;
+
+	ret = qca_set_bdaddr_rome(hdev, bdaddr);
+	if (ret)
+		return ret;
+
+	/* The firmware stops responding for a while after setting the bdaddr,
+	 * causing timeouts for subsequent commands. Sleep a bit to avoid this.
+	 */
+	usleep_range(1000, 10000);
+	return 0;
+}
+
 static int btqcomsmd_probe(struct platform_device *pdev)
 {
 	struct btqcomsmd *btq;
@@ -162,7 +177,7 @@  static int btqcomsmd_probe(struct platform_device *pdev)
 	hdev->close = btqcomsmd_close;
 	hdev->send = btqcomsmd_send;
 	hdev->setup = btqcomsmd_setup;
-	hdev->set_bdaddr = qca_set_bdaddr_rome;
+	hdev->set_bdaddr = btqcomsmd_set_bdaddr;
 
 	ret = hci_register_dev(hdev);
 	if (ret < 0)