Bluetooth: hci_ll: Enable BROKEN_ENHANCED_SETUP_SYNC_CONN for WL183x

While validating SCO audio on a platform using TI WL183x Bluetooth modules with the hci_ll driver, we observed failures when the HCI Enhanced Setup Synchronous Connection command was used.

Although the controller advertises support for the command, SCO setup fails in certain configurations (e.g. BT_VOICE_TRANSPARENT/mSBC). This matches the scenario described in commit 05abad857277 ("Bluetooth: HCI: Add HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN quirk").

Initially, we considered setting the HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN quirk unconditionally in hci_ll. However, this would affect all TI controllers handled by the driver, including configurations where the enhanced setup command works correctly.

To avoid hardcoding the quirk globally, we first proposed a DT-based solution. Based on review feedback, the quirk is now enabled automatically for the affected devices by deducing it from the compatible string instead.

The issue has been observed on WL1831, WL1835 and WL1837 modules, therefore the quirk is enabled for:
- "ti,wl1831-st"
- "ti,wl1835-st"
- "ti,wl1837-st"

This keeps the change limited to the affected WL183x family and avoids impacting other TI controllers handled by hci_ll.

v1->v2:
- Remove DT property, used compatible instead

v1:

Stefano Radaelli (1):
Bluetooth: hci_ll: Enable BROKEN_ENHANCED_SETUP_SYNC_CONN for WL183x

 drivers/bluetooth/hci_ll.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f

2.47.3

From: Stefano Radaelli <[email protected]>

TI WL183x controllers advertise support for the HCI Enhanced Setup Synchronous Connection command, but SCO setup fails when the enhanced path is used. The only working configuration is to fall back to the legacy HCI Setup Synchronous Connection (0x0028).

This matches the scenario described in commit 05abad857277 ("Bluetooth: HCI: Add HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN quirk").

Enable HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN automatically for devices compatible with:
- ti,wl1831-st
- ti,wl1835-st
- ti,wl1837-st

---
v1->v2:
-

 drivers/bluetooth/hci_ll.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

index 91acf24f1ef5..6f060eec3b81 100644
@@ -68,6 +68,7 @@ struct ll_device {
 	struct gpio_desc *enable_gpio;
 	struct clk *ext_clk;
 	bdaddr_t bdaddr;
+	bool broken_enhanced_setup;
 };
 
 struct ll_struct {

@@ -656,6 +657,10 @@ static int ll_setup(struct hci_uart *hu)
 			hci_set_quirk(hu->hdev, HCI_QUIRK_INVALID_BDADDR);
 	}
 
+	if (lldev->broken_enhanced_setup)
+		hci_set_quirk(hu->hdev,
+			      HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN);
+
 	/* Operational speed if any */
 	if (hu->oper_speed)
 		speed = hu->oper_speed;

@@ -710,6 +715,11 @@ static int hci_ti_probe(struct serdev_device *serdev)
 	of_property_read_u32(serdev->dev.of_node, "max-speed", &max_speed);
 	hci_uart_set_speeds(hu, 115200, max_speed);
 
+	if (of_device_is_compatible(serdev->dev.of_node, "ti,wl1831-st") ||
+	    of_device_is_compatible(serdev->dev.of_node, "ti,wl1835-st") ||
+	    of_device_is_compatible(serdev->dev.of_node, "ti,wl1837-st"))
+		lldev->broken_enhanced_setup = true;
+
 	/* optional BD address from nvram */
 	bdaddr_cell = nvmem_cell_get(&serdev->dev, "bd-address");
 	if (IS_ERR(bdaddr_cell)) {

2.47.3

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=1057165

---Test result---

Test Summary:

CheckPatch                    PENDING   0.52 seconds
GitLint                       PENDING   0.32 seconds
SubjectPrefix                 PASS      0.06 seconds
BuildKernel                   PASS      26.00 seconds
CheckAllWarning               PASS      28.95 seconds
CheckSparse                   PASS      32.94 seconds
BuildKernel32                 PASS      25.47 seconds
TestRunnerSetup               PASS      558.94 seconds
TestRunner_l2cap-tester       PASS      28.47 seconds
TestRunner_iso-tester         PASS      73.06 seconds
TestRunner_bnep-tester        PASS      6.25 seconds
TestRunner_mgmt-tester        FAIL      113.22 seconds
TestRunner_rfcomm-tester      PASS      9.60 seconds
TestRunner_sco-tester         FAIL      14.34 seconds
TestRunner_ioctl-tester       PASS      10.15 seconds
TestRunner_mesh-tester        FAIL      12.51 seconds
TestRunner_smp-tester         PASS      8.57 seconds
TestRunner_userchan-tester    PASS      6.61 seconds
IncrementalBuild              PENDING   1.03 seconds

Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:

##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:

##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4

Failed Test Cases
Read Exp Feature - Success Failed 0.108 seconds
##############################
Test: TestRunner_sco-tester - FAIL
Desc: Run sco-tester with test-runner
Output:
WARNING: possible circular locking dependency detected

BUG: sleeping function called from invalid context at net/core/sock.c:3782

Total: 30, Passed: 30 (100.0%), Failed: 0, Not Run: 0
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0

Failed Test Cases

Mesh - Send cancel - 1                               Timed out    2.731 seconds
Mesh - Send cancel - 2                               Timed out    1.991 seconds

##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series Output:

---
Regards,
Linux Bluetooth

Hi,

I noticed that this patch has not received feedback and is now marked as archived in patchwork.

I also saw that the CI reported some test failures (e.g. mgmt-tester and others), and I was wondering if this might be the reason why it has not been considered.

Could you please let me know if I should address those issues or if any changes are needed for this patch?

Thanks,
Stefano

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=1057165

---Test result---

Test Summary:

CheckPatch                    PENDING   0.34 seconds
GitLint                       PENDING   0.26 seconds
SubjectPrefix                 PASS      0.12 seconds
BuildKernel                   PASS      27.48 seconds
CheckAllWarning               PASS      29.02 seconds
CheckSparse                   PASS      28.54 seconds
BuildKernel32                 PASS      25.85 seconds
TestRunnerSetup               PASS      580.48 seconds
TestRunner_l2cap-tester       FAIL      28.64 seconds
TestRunner_iso-tester         PASS      42.20 seconds
TestRunner_bnep-tester        PASS      6.64 seconds
TestRunner_mgmt-tester        FAIL      116.54 seconds
TestRunner_rfcomm-tester      PASS      9.90 seconds
TestRunner_sco-tester         FAIL      14.70 seconds
TestRunner_ioctl-tester       PASS      10.38 seconds
TestRunner_mesh-tester        FAIL      12.47 seconds
TestRunner_smp-tester         PASS      8.65 seconds
TestRunner_userchan-tester    PASS      7.00 seconds
IncrementalBuild              PENDING   0.57 seconds

Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:

##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:

##############################
Test: TestRunner_l2cap-tester - FAIL
Desc: Run l2cap-tester with test-runner Output:
Total: 96, Passed: 95 (99.0%), Failed: 1, Not Run: 0

Failed Test Cases
L2CAP BR/EDR Server - Set PHY 2M Failed 0.117 seconds
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4

Failed Test Cases
Read Exp Feature - Success Failed 0.111 seconds
##############################
Test: TestRunner_sco-tester - FAIL
Desc: Run sco-tester with test-runner
Output:
WARNING: possible circular locking dependency detected

BUG: sleeping function called from invalid context at net/core/sock.c:3782

Total: 30, Passed: 30 (100.0%), Failed: 0, Not Run: 0
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0

Failed Test Cases

Mesh - Send cancel - 1                               Timed out    2.628 seconds
Mesh - Send cancel - 2                               Timed out    1.998 seconds

##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series Output:

---
Regards,
Linux Bluetooth

Hi Stefano,

Please resend.

Luiz Augusto von Dentz

Hi Luiz,

I've re-sent the patch.

Thank you,
Best Regards,
Stefano

Dear Stefano,

Thank you for the patch.

Am 02.04.26 um 20:47 schrieb Stefano Radaelli:

Do you have a reproducer?

Have you contacted TI about this?

Do you have an example device, that uses one of these? Also, do you know of TI device, where the HCI Enhanced Setup Synchronous Connection command works?

For the future, if you just resend, just add the tag [RESEND] instead of v2, so it’s clear no changes were made.

Hi Paul,

Yes,
the issue can be reproduced on our Variscite platforms using TI WL183x modules (e.g. VAR-SOM-MX6). When establishing an SCO connection using the HCI Enhanced Setup Synchronous Connection command.

Forcing the legacy HCI Setup Synchronous Connection (0x0028) instead restores correct SCO operation.

No, we have not contacted TI.

WL183x devices are quite old (released more than 10 years ago), and the latest available firmware is also quite dated and predates the introduction of the Enhanced Setup Synchronous Connection handling in the Linux kernel.

Given this, these devices cannot realistically work correctly with this command unless a new firmware update is provided by TI, which seems unlikely at this point.

Yes, for example the VAR-SOM-MX6, which integrates WL183x modules. The issue has been consistently observed across our platforms using WL1831, WL1835 and WL1837 modules.

At the moment I do not have access to other TI Bluetooth families using this driver to verify whether the enhanced command works correctly on newer devices.

For this reason, the patch limits the quirk only to the WL183x family, based on the compatible string, and does not affect other TI devices handled by hci_ll. Additional compatibles can be added in the future if similar behaviour is observed on other controllers.

Thanks for your review!

Best Regards,
Stefano