Bug 216817 - btusb device with ID 0489:e0d0 no longer working after v6.0
Summary: btusb device with ID 0489:e0d0 no longer working after v6.0
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Bluetooth (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: linux-bluetooth@vger.kernel.org
URL: https://bugzilla.redhat.com/show_bug....
Keywords:
Depends on:
Blocks:
 
Reported: 2022-12-18 04:28 UTC by Andrew M
Modified: 2023-01-26 16:21 UTC (History)
3 users (show)

See Also:
Kernel Version: 6.0, 6.0.12
Tree: Mainline
Regression: No


Attachments
output of lsusb -v -d 0489:e0d0 (839 bytes, application/gzip)
2022-12-18 04:30 UTC, Andrew M
Details

Description Andrew M 2022-12-18 04:28:43 UTC
The internal USB Bluetooth device in my laptop no longer works since v6.0

Device in question:
ID 0489:e0d0 Foxconn / Hon Hai

Works fine in 5.19.x and fails after 6.0
I ran a bisect that resulted in it breaking after this commit:
26afbd826ee326e63a334c37fd45e82e50a615ec Bluetooth: Add initial implementation of CIS connections

System: Lenovo ThinkPad T14 (AMD) Gen 2

dmesg output:

[    0.978396] usb 5-4: new full-speed USB device number 2 using xhci_hcd
[    1.142461] usb 5-4: New USB device found, idVendor=0489, idProduct=e0d0, bcdDevice= 0.01
[    1.142467] usb 5-4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    4.591285] Bluetooth: Core ver 2.22
[    4.591304] Bluetooth: HCI device and connection manager initialized
[    4.591308] Bluetooth: HCI socket layer initialized
[    4.591309] Bluetooth: L2CAP socket layer initialized
[    4.591315] Bluetooth: SCO socket layer initialized
[    4.871972] usbcore: registered new interface driver btusb
[    4.883484] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.
[    4.973465] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[    4.973468] Bluetooth: BNEP filters: protocol multicast
[    4.973472] Bluetooth: BNEP socket layer initialized
[    4.975525] Bluetooth: hci0: unexpected cc 0x2060 length: 1 < 7
[    4.975537] Bluetooth: hci0: Opcode 0x2060 failed: -38
[    6.985714] Bluetooth: hci0: command tx timeout

Attached is output of lsusb -v -d 0489:e0d0
Comment 1 Andrew M 2022-12-18 04:30:41 UTC
Created attachment 303421 [details]
output of lsusb -v -d 0489:e0d0
Comment 2 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-12-19 08:33:21 UTC
FWIW, there is a fix for that patch that might or might not be related to your problem (I'm not a bluetooth developer):
https://lore.kernel.org/all/20221206012323.3684462-1-luiz.dentz@gmail.com/

You also might want to check if 6.1 works, as some fixes are not backported -- and 6.0 will likely be soon EOL anyway
Comment 3 Andrew M 2022-12-19 10:55:13 UTC
Unfortunately it sill fails with 6.1 from Arch testing and a latest git pull (6.1.r13139.gf9ff5644bcc0) which both include that change.
Comment 4 Luiz Von Dentz 2022-12-19 21:06:39 UTC
Looks like the command that is failing is HCI_OP_LE_READ_BUFFER_SIZE_V2:

#define HCI_OP_LE_READ_BUFFER_SIZE_V2	0x2060

Looks like the controller is marking as supported but in fact it doesn't:

	/* Use Read LE Buffer Size V2 if supported */
	if (hdev->commands[41] & 0x20)
		return __hci_cmd_sync_status(hdev,
					     HCI_OP_LE_READ_BUFFER_SIZE_V2,
					     0, NULL, HCI_CMD_TIMEOUT);

So either we introduce a quirk that must be set by the driver or we fallback to HCI_OP_LE_READ_BUFFER_SIZE if HCI_OP_LE_READ_BUFFER_SIZE_V2 is not supported, the later perhaps save us more time detecting this broken behavior since some manufacturers don't seem to even care to qualify their controllers.
Comment 5 Luiz Von Dentz 2022-12-19 21:10:16 UTC
(In reply to Andrew M from comment #3)
> Unfortunately it sill fails with 6.1 from Arch testing and a latest git pull
> (6.1.r13139.gf9ff5644bcc0) which both include that change.

Can you try with the following patch:

diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index 5220bfd75b00..b3676b899647 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -3572,7 +3572,7 @@ static const struct hci_init_stage hci_init2[] = {
 static int hci_le_read_buffer_size_sync(struct hci_dev *hdev)
 {
        /* Use Read LE Buffer Size V2 if supported */
-       if (hdev->commands[41] & 0x20)
+       if (iso_capable(hdev) && hdev->commands[41] & 0x20)
                return __hci_cmd_sync_status(hdev,
                                             HCI_OP_LE_READ_BUFFER_SIZE_V2,
                                             0, NULL, HCI_CMD_TIMEOUT);
Comment 6 Andrew M 2022-12-20 03:25:03 UTC
(In reply to Luiz Von Dentz from comment #5)
> Can you try with the following patch

Thanks for the quick response. Tried the patch and it has solved the problem for me on both 6.1.0 and git.
I hope it makes it into 6.1.1
Comment 7 Luiz Von Dentz 2022-12-20 20:25:02 UTC
(In reply to Andrew M from comment #6)
> (In reply to Luiz Von Dentz from comment #5)
> > Can you try with the following patch
> 
> Thanks for the quick response. Tried the patch and it has solved the problem
> for me on both 6.1.0 and git.
> I hope it makes it into 6.1.1

Please test with the latest version:

https://patchwork.kernel.org/project/bluetooth/patch/20221219234945.3733741-1-luiz.dentz@gmail.com/

It turns out the features are not ready if we don't change the command sequence so iso_capable would always evaluate to false.
Comment 8 Andrew M 2022-12-21 11:19:06 UTC
(In reply to Luiz Von Dentz from comment #7)
> (In reply to Andrew M from comment #6)
> > (In reply to Luiz Von Dentz from comment #5)
> > > Can you try with the following patch
> > 
> > Thanks for the quick response. Tried the patch and it has solved the
> problem
> > for me on both 6.1.0 and git.
> > I hope it makes it into 6.1.1
> 
> Please test with the latest version:
> 
> https://patchwork.kernel.org/project/bluetooth/patch/20221219234945.3733741-
> 1-luiz.dentz@gmail.com/
> 
> It turns out the features are not ready if we don't change the command
> sequence so iso_capable would always evaluate to false.

Still works. Tested v6.1 and 6.1.r13872.gb6bb9676f216
Comment 9 Mario Limonciello (AMD) 2023-01-11 19:44:09 UTC
As this completely broke bluetooth for a number of people, can you please consider this to be sent up to 6.2-rc in a fixes PR rather than waiting for 6.3 and

Cc: stable@vger.kernel.org # 6.1
Comment 10 The Linux kernel's regression tracker (Thorsten Leemhuis) 2023-01-16 13:29:29 UTC
(In reply to Mario Limonciello (AMD) from comment #9)
> As this completely broke bluetooth for a number of people,

Did it? Ohh, interesting.

> can you please
> consider this to be sent up to 6.2-rc in a fixes PR rather than waiting for
> 6.3 and
> 
> Cc: stable@vger.kernel.org # 6.1

Luiz, that sounds like a reasonable request. Did you work on that front? Doesn't look like it from here, but maybe I missed something.
Comment 11 Luiz Von Dentz 2023-01-17 19:22:26 UTC
Sorry for late reply, long weekend here, I will create a pull request for net so hopefully this get in the next rc.
Comment 12 Mario Limonciello (AMD) 2023-01-26 16:21:49 UTC
As this is upstreamed as of 6.2-rc5 (3a4d29b6d631b ("Bluetooth: hci_sync: Fix use HCI_OP_LE_READ_BUFFER_SIZE_V2")) closing this issue.

The fix should trickle into 6.1.y as well.

Note You need to log in before you can comment on or make changes to this bug.