[PATCH] Bluetooth: Apply initial command workaround for more Intel chips

[PATCH] Bluetooth: Apply initial command workaround for more Intel chips

[Takashi Iwai]

It seems that a few more Intel chips require the workaround for the
broken initial command.  At least, per openSUSE Bugzilla reports,
8087:0a2a and 8087:0026 need BTUSB_INTEL_BROKEN_INITIAL_NCMD flag.

Fixes: 83f2dafe2a62 ("Bluetooth: btintel: Refactoring setup routine for legacy ROM sku")
Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124
Signed-off-by: Takashi Iwai <tiwai@suse.de>

---
 drivers/bluetooth/btusb.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 75c83768c257..b26989b2df23 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -359,14 +359,16 @@ static const struct usb_device_id blacklist_table[] = {
 
 	/* Intel Bluetooth devices */
 	{ USB_DEVICE(0x8087, 0x0025), .driver_info = BTUSB_INTEL_COMBINED },
-	{ USB_DEVICE(0x8087, 0x0026), .driver_info = BTUSB_INTEL_COMBINED },
+	{ USB_DEVICE(0x8087, 0x0026), .driver_info = BTUSB_INTEL_COMBINED |
+						     BTUSB_INTEL_BROKEN_INITIAL_NCMD },
 	{ USB_DEVICE(0x8087, 0x0029), .driver_info = BTUSB_INTEL_COMBINED },
 	{ USB_DEVICE(0x8087, 0x0032), .driver_info = BTUSB_INTEL_COMBINED },
 	{ USB_DEVICE(0x8087, 0x0033), .driver_info = BTUSB_INTEL_COMBINED },
 	{ USB_DEVICE(0x8087, 0x07da), .driver_info = BTUSB_CSR },
 	{ USB_DEVICE(0x8087, 0x07dc), .driver_info = BTUSB_INTEL_COMBINED |
 						     BTUSB_INTEL_BROKEN_INITIAL_NCMD },
-	{ USB_DEVICE(0x8087, 0x0a2a), .driver_info = BTUSB_INTEL_COMBINED },
+	{ USB_DEVICE(0x8087, 0x0a2a), .driver_info = BTUSB_INTEL_COMBINED |
+						     BTUSB_INTEL_BROKEN_INITIAL_NCMD },
 	{ USB_DEVICE(0x8087, 0x0a2b), .driver_info = BTUSB_INTEL_COMBINED },
 	{ USB_DEVICE(0x8087, 0x0aa7), .driver_info = BTUSB_INTEL_COMBINED },
 	{ USB_DEVICE(0x8087, 0x0aaa), .driver_info = BTUSB_INTEL_COMBINED },
-- 
2.31.1

Re: [PATCH] Bluetooth: Apply initial command workaround for more Intel chips

[Paul Menzel]

Dear Takashi,


Am 02.12.21 um 17:22 schrieb Takashi Iwai:
> It seems that a few more Intel chips require the workaround for the
> broken initial command.  At least, per openSUSE Bugzilla reports,
> 8087:0a2a and 8087:0026 need BTUSB_INTEL_BROKEN_INITIAL_NCMD flag.
> 
> Fixes: 83f2dafe2a62 ("Bluetooth: btintel: Refactoring setup routine for legacy ROM sku")
> Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> 

[…]

I have a Dell Latitude E7250 with

     Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless 
interface

and Bluetooth seems to work fine minus some Linux warnings [1] and a 
problem transferring greater than some bytes files with the Nokia N9 [2].

Linux 5.16-rc3, Dell Inc. Latitude E7250/0TVD2T, BIOS A19 01/23/2018:

```
$ sudo dmesg | grep -i bluet
[    8.173417] calling  bt_init+0x0/0xb3 [bluetooth] @ 301
[    8.173439] Bluetooth: Core ver 2.22
[    8.173463] NET: Registered PF_BLUETOOTH protocol family
[    8.173464] Bluetooth: HCI device and connection manager initialized
[    8.173467] Bluetooth: HCI socket layer initialized
[    8.173470] Bluetooth: L2CAP socket layer initialized
[    8.173473] Bluetooth: SCO socket layer initialized
[    8.173475] initcall bt_init+0x0/0xb3 [bluetooth] returned 0 after 35 
usecs
[    8.216875] Bluetooth: hci0: Legacy ROM 2.5 revision 1.0 build 3 week 
17 2014
[    8.233515] bluetooth hci0: firmware: direct-loading firmware 
intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
[    8.233520] Bluetooth: hci0: Intel Bluetooth firmware file: 
intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
[    8.540884] Bluetooth: hci0: unexpected event for opcode 0xfc2f
[    8.558942] Bluetooth: hci0: Intel BT fw patch 0x32 completed & activated
```


Kind regards,

Paul


[1]: https://bugzilla.kernel.org/show_bug.cgi?id=215189
[2]: 
https://lore.kernel.org/linux-bluetooth/cf71bdea-ec22-e4c9-016c-69e94a130607@molgen.mpg.de/T/#t

Re: [PATCH] Bluetooth: Apply initial command workaround for more Intel chips

[Takashi Iwai]

On Thu, 02 Dec 2021 17:32:14 +0100,
Paul Menzel wrote:
> 
> Dear Takashi,
> 
> 
> Am 02.12.21 um 17:22 schrieb Takashi Iwai:
> > It seems that a few more Intel chips require the workaround for the
> > broken initial command.  At least, per openSUSE Bugzilla reports,
> > 8087:0a2a and 8087:0026 need BTUSB_INTEL_BROKEN_INITIAL_NCMD flag.
> >
> > Fixes: 83f2dafe2a62 ("Bluetooth: btintel: Refactoring setup routine for legacy ROM sku")
> > Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124
> > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> >
> 
> […]
> 
> I have a Dell Latitude E7250 with
> 
>     Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless
> interface
> 
> and Bluetooth seems to work fine minus some Linux warnings [1] and a
> problem transferring greater than some bytes files with the Nokia N9
> [2].
> 
> Linux 5.16-rc3, Dell Inc. Latitude E7250/0TVD2T, BIOS A19 01/23/2018:
> 
> ```
> $ sudo dmesg | grep -i bluet
> [    8.173417] calling  bt_init+0x0/0xb3 [bluetooth] @ 301
> [    8.173439] Bluetooth: Core ver 2.22
> [    8.173463] NET: Registered PF_BLUETOOTH protocol family
> [    8.173464] Bluetooth: HCI device and connection manager initialized
> [    8.173467] Bluetooth: HCI socket layer initialized
> [    8.173470] Bluetooth: L2CAP socket layer initialized
> [    8.173473] Bluetooth: SCO socket layer initialized
> [    8.173475] initcall bt_init+0x0/0xb3 [bluetooth] returned 0 after
> 35 usecs
> [    8.216875] Bluetooth: hci0: Legacy ROM 2.5 revision 1.0 build 3
> week 17 2014
> [    8.233515] bluetooth hci0: firmware: direct-loading firmware
> intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
> [    8.233520] Bluetooth: hci0: Intel Bluetooth firmware file:
> intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
> [    8.540884] Bluetooth: hci0: unexpected event for opcode 0xfc2f
> [    8.558942] Bluetooth: hci0: Intel BT fw patch 0x32 completed & activated
> ```

Thanks, so this seems depending on the hardware, maybe a subtle
difference matters.  As far as I read the code changes, the workaround
was applied in the past unconditionally, so it must be fairly safe
even if the chip works as is.

Or, for avoiding the unnecessarily application of the workaround,
should it be changed as a fallback after the failure at the first
try...?


Takashi

Re: [PATCH] Bluetooth: Apply initial command workaround for more Intel chips

[Paul Menzel]

Dear Takashi,


Am 02.12.21 um 17:47 schrieb Takashi Iwai:
> On Thu, 02 Dec 2021 17:32:14 +0100, Paul Menzel wrote:

>> Am 02.12.21 um 17:22 schrieb Takashi Iwai:
>>> It seems that a few more Intel chips require the workaround for the
>>> broken initial command.  At least, per openSUSE Bugzilla reports,
>>> 8087:0a2a and 8087:0026 need BTUSB_INTEL_BROKEN_INITIAL_NCMD flag.
>>>
>>> Fixes: 83f2dafe2a62 ("Bluetooth: btintel: Refactoring setup routine for legacy ROM sku")
>>> Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124
>>> Signed-off-by: Takashi Iwai <tiwai@suse.de>
>>>
>>
>> […]
>>
>> I have a Dell Latitude E7250 with
>>
>>      Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
>>
>> and Bluetooth seems to work fine minus some Linux warnings [1] and a
>> problem transferring greater than some bytes files with the Nokia N9
>> [2].
>>
>> Linux 5.16-rc3, Dell Inc. Latitude E7250/0TVD2T, BIOS A19 01/23/2018:
>>
>> ```
>> $ sudo dmesg | grep -i bluet
>> [    8.173417] calling  bt_init+0x0/0xb3 [bluetooth] @ 301
>> [    8.173439] Bluetooth: Core ver 2.22
>> [    8.173463] NET: Registered PF_BLUETOOTH protocol family
>> [    8.173464] Bluetooth: HCI device and connection manager initialized
>> [    8.173467] Bluetooth: HCI socket layer initialized
>> [    8.173470] Bluetooth: L2CAP socket layer initialized
>> [    8.173473] Bluetooth: SCO socket layer initialized
>> [    8.173475] initcall bt_init+0x0/0xb3 [bluetooth] returned 0 after 35 usecs
>> [    8.216875] Bluetooth: hci0: Legacy ROM 2.5 revision 1.0 build 3 week 17 2014
>> [    8.233515] bluetooth hci0: firmware: direct-loading firmware intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
>> [    8.233520] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
>> [    8.540884] Bluetooth: hci0: unexpected event for opcode 0xfc2f
>> [    8.558942] Bluetooth: hci0: Intel BT fw patch 0x32 completed & activated
>> ```
> 
> Thanks, so this seems depending on the hardware, maybe a subtle
> difference matters.  As far as I read the code changes, the workaround
> was applied in the past unconditionally, so it must be fairly safe
> even if the chip works as is.

Maybe add that to the commit message?

> Or, for avoiding the unnecessarily application of the workaround,
> should it be changed as a fallback after the failure at the first
> try...?

Reading through the openSUSE Bugzilla issue, the failure is:

     Bluetooth: hci0: Reading Intel version command failed (-110)
     Bluetooth: hci0: command 0xfc05 tx timeout

I couldn’t find the report for 8087:0a2a in the issue. Can you check, 
what firmware is used?

If the functionality of 5.14 is restored by your patch, then it should 
work I guess. I didn’t use Bluetooth for file transfers in the past and 
only for connecting to external speakers.


Kind regards,

Paul

Re: [PATCH] Bluetooth: Apply initial command workaround for more Intel chips

[Takashi Iwai]

On Thu, 02 Dec 2021 17:58:01 +0100,
Paul Menzel wrote:
> 
> Dear Takashi,
> 
> 
> Am 02.12.21 um 17:47 schrieb Takashi Iwai:
> > On Thu, 02 Dec 2021 17:32:14 +0100, Paul Menzel wrote:
> 
> >> Am 02.12.21 um 17:22 schrieb Takashi Iwai:
> >>> It seems that a few more Intel chips require the workaround for the
> >>> broken initial command.  At least, per openSUSE Bugzilla reports,
> >>> 8087:0a2a and 8087:0026 need BTUSB_INTEL_BROKEN_INITIAL_NCMD flag.
> >>>
> >>> Fixes: 83f2dafe2a62 ("Bluetooth: btintel: Refactoring setup routine for legacy ROM sku")
> >>> Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124
> >>> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> >>>
> >>
> >> […]
> >>
> >> I have a Dell Latitude E7250 with
> >>
> >>      Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
> >>
> >> and Bluetooth seems to work fine minus some Linux warnings [1] and a
> >> problem transferring greater than some bytes files with the Nokia N9
> >> [2].
> >>
> >> Linux 5.16-rc3, Dell Inc. Latitude E7250/0TVD2T, BIOS A19 01/23/2018:
> >>
> >> ```
> >> $ sudo dmesg | grep -i bluet
> >> [    8.173417] calling  bt_init+0x0/0xb3 [bluetooth] @ 301
> >> [    8.173439] Bluetooth: Core ver 2.22
> >> [    8.173463] NET: Registered PF_BLUETOOTH protocol family
> >> [    8.173464] Bluetooth: HCI device and connection manager initialized
> >> [    8.173467] Bluetooth: HCI socket layer initialized
> >> [    8.173470] Bluetooth: L2CAP socket layer initialized
> >> [    8.173473] Bluetooth: SCO socket layer initialized
> >> [    8.173475] initcall bt_init+0x0/0xb3 [bluetooth] returned 0 after 35 usecs
> >> [    8.216875] Bluetooth: hci0: Legacy ROM 2.5 revision 1.0 build 3 week 17 2014
> >> [    8.233515] bluetooth hci0: firmware: direct-loading firmware intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
> >> [    8.233520] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
> >> [    8.540884] Bluetooth: hci0: unexpected event for opcode 0xfc2f
> >> [    8.558942] Bluetooth: hci0: Intel BT fw patch 0x32 completed & activated
> >> ```
> >
> > Thanks, so this seems depending on the hardware, maybe a subtle
> > difference matters.  As far as I read the code changes, the workaround
> > was applied in the past unconditionally, so it must be fairly safe
> > even if the chip works as is.
> 
> Maybe add that to the commit message?

Maybe, if the upstream agrees with that.  More comments needed from
Intel, as it's a kind of black magic.

> > Or, for avoiding the unnecessarily application of the workaround,
> > should it be changed as a fallback after the failure at the first
> > try...?
> 
> Reading through the openSUSE Bugzilla issue, the failure is:
> 
>     Bluetooth: hci0: Reading Intel version command failed (-110)
>     Bluetooth: hci0: command 0xfc05 tx timeout
> 
> I couldn’t find the report for 8087:0a2a in the issue.

There two different machines in the report.

> Can you check,
> what firmware is used?

It's the place before loading the firmware, so the firmware version
doesn't matter.


thanks,

Takashi

Re: [PATCH] Bluetooth: Apply initial command workaround for more Intel chips

[Marcel Holtmann]

Hi Takashi,

>>>>> It seems that a few more Intel chips require the workaround for the
>>>>> broken initial command.  At least, per openSUSE Bugzilla reports,
>>>>> 8087:0a2a and 8087:0026 need BTUSB_INTEL_BROKEN_INITIAL_NCMD flag.
>>>>> 
>>>>> Fixes: 83f2dafe2a62 ("Bluetooth: btintel: Refactoring setup routine for legacy ROM sku")
>>>>> Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124
>>>>> Signed-off-by: Takashi Iwai <tiwai@suse.de>
>>>>> 
>>>> 
>>>> […]
>>>> 
>>>> I have a Dell Latitude E7250 with
>>>> 
>>>>     Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
>>>> 
>>>> and Bluetooth seems to work fine minus some Linux warnings [1] and a
>>>> problem transferring greater than some bytes files with the Nokia N9
>>>> [2].
>>>> 
>>>> Linux 5.16-rc3, Dell Inc. Latitude E7250/0TVD2T, BIOS A19 01/23/2018:
>>>> 
>>>> ```
>>>> $ sudo dmesg | grep -i bluet
>>>> [    8.173417] calling  bt_init+0x0/0xb3 [bluetooth] @ 301
>>>> [    8.173439] Bluetooth: Core ver 2.22
>>>> [    8.173463] NET: Registered PF_BLUETOOTH protocol family
>>>> [    8.173464] Bluetooth: HCI device and connection manager initialized
>>>> [    8.173467] Bluetooth: HCI socket layer initialized
>>>> [    8.173470] Bluetooth: L2CAP socket layer initialized
>>>> [    8.173473] Bluetooth: SCO socket layer initialized
>>>> [    8.173475] initcall bt_init+0x0/0xb3 [bluetooth] returned 0 after 35 usecs
>>>> [    8.216875] Bluetooth: hci0: Legacy ROM 2.5 revision 1.0 build 3 week 17 2014
>>>> [    8.233515] bluetooth hci0: firmware: direct-loading firmware intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
>>>> [    8.233520] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
>>>> [    8.540884] Bluetooth: hci0: unexpected event for opcode 0xfc2f
>>>> [    8.558942] Bluetooth: hci0: Intel BT fw patch 0x32 completed & activated
>>>> ```
>>> 
>>> Thanks, so this seems depending on the hardware, maybe a subtle
>>> difference matters.  As far as I read the code changes, the workaround
>>> was applied in the past unconditionally, so it must be fairly safe
>>> even if the chip works as is.
>> 
>> Maybe add that to the commit message?
> 
> Maybe, if the upstream agrees with that.  More comments needed from
> Intel, as it's a kind of black magic.
> 
>>> Or, for avoiding the unnecessarily application of the workaround,
>>> should it be changed as a fallback after the failure at the first
>>> try...?
>> 
>> Reading through the openSUSE Bugzilla issue, the failure is:
>> 
>>    Bluetooth: hci0: Reading Intel version command failed (-110)
>>    Bluetooth: hci0: command 0xfc05 tx timeout
>> 
>> I couldn’t find the report for 8087:0a2a in the issue.
> 
> There two different machines in the report.
> 
>> Can you check,
>> what firmware is used?
> 
> It's the place before loading the firmware, so the firmware version
> doesn't matter.

I want to apply this quirk to as little devices as possible. It is one of these quirks we have to hardcode per USB VID:PID since we can’t auto-detect which boot loader is faulty.

So before I blacklist them, we better get a good understand of which they are. Can you include a btmon trace for that part. You most likely have to blacklist btusb.ko, start btmon and then load btusb.ko manually. One with and one without the quirk. And add that to the commit message.

We then try to find that module internally. It must be some SKU that we didn’t have in our test rack.

Regards

Marcel

Re: [PATCH] Bluetooth: Apply initial command workaround for more Intel chips

[Takashi Iwai]

On Fri, 03 Dec 2021 22:18:06 +0100,
Marcel Holtmann wrote:
> 
> Hi Takashi,
> 
> >>>>> It seems that a few more Intel chips require the workaround for the
> >>>>> broken initial command.  At least, per openSUSE Bugzilla reports,
> >>>>> 8087:0a2a and 8087:0026 need BTUSB_INTEL_BROKEN_INITIAL_NCMD flag.
> >>>>> 
> >>>>> Fixes: 83f2dafe2a62 ("Bluetooth: btintel: Refactoring setup routine for legacy ROM sku")
> >>>>> Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124
> >>>>> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> >>>>> 
> >>>> 
> >>>> […]
> >>>> 
> >>>> I have a Dell Latitude E7250 with
> >>>> 
> >>>>     Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
> >>>> 
> >>>> and Bluetooth seems to work fine minus some Linux warnings [1] and a
> >>>> problem transferring greater than some bytes files with the Nokia N9
> >>>> [2].
> >>>> 
> >>>> Linux 5.16-rc3, Dell Inc. Latitude E7250/0TVD2T, BIOS A19 01/23/2018:
> >>>> 
> >>>> ```
> >>>> $ sudo dmesg | grep -i bluet
> >>>> [    8.173417] calling  bt_init+0x0/0xb3 [bluetooth] @ 301
> >>>> [    8.173439] Bluetooth: Core ver 2.22
> >>>> [    8.173463] NET: Registered PF_BLUETOOTH protocol family
> >>>> [    8.173464] Bluetooth: HCI device and connection manager initialized
> >>>> [    8.173467] Bluetooth: HCI socket layer initialized
> >>>> [    8.173470] Bluetooth: L2CAP socket layer initialized
> >>>> [    8.173473] Bluetooth: SCO socket layer initialized
> >>>> [    8.173475] initcall bt_init+0x0/0xb3 [bluetooth] returned 0 after 35 usecs
> >>>> [    8.216875] Bluetooth: hci0: Legacy ROM 2.5 revision 1.0 build 3 week 17 2014
> >>>> [    8.233515] bluetooth hci0: firmware: direct-loading firmware intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
> >>>> [    8.233520] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
> >>>> [    8.540884] Bluetooth: hci0: unexpected event for opcode 0xfc2f
> >>>> [    8.558942] Bluetooth: hci0: Intel BT fw patch 0x32 completed & activated
> >>>> ```
> >>> 
> >>> Thanks, so this seems depending on the hardware, maybe a subtle
> >>> difference matters.  As far as I read the code changes, the workaround
> >>> was applied in the past unconditionally, so it must be fairly safe
> >>> even if the chip works as is.
> >> 
> >> Maybe add that to the commit message?
> > 
> > Maybe, if the upstream agrees with that.  More comments needed from
> > Intel, as it's a kind of black magic.
> > 
> >>> Or, for avoiding the unnecessarily application of the workaround,
> >>> should it be changed as a fallback after the failure at the first
> >>> try...?
> >> 
> >> Reading through the openSUSE Bugzilla issue, the failure is:
> >> 
> >>    Bluetooth: hci0: Reading Intel version command failed (-110)
> >>    Bluetooth: hci0: command 0xfc05 tx timeout
> >> 
> >> I couldn’t find the report for 8087:0a2a in the issue.
> > 
> > There two different machines in the report.
> > 
> >> Can you check,
> >> what firmware is used?
> > 
> > It's the place before loading the firmware, so the firmware version
> > doesn't matter.
> 
> I want to apply this quirk to as little devices as possible. It is one of these quirks we have to hardcode per USB VID:PID since we can’t auto-detect which boot loader is faulty.
> 
> So before I blacklist them, we better get a good understand of which they are. Can you include a btmon trace for that part. You most likely have to blacklist btusb.ko, start btmon and then load btusb.ko manually. One with and one without the quirk. And add that to the commit message.

One of the reporters uploaded the logs to the kernel.org bugzilla
  https://bugzilla.kernel.org/show_bug.cgi?id=215167

(I forgot to add this URL to the patch description, although this
 could be reached from openSUSE Bugzila entry.)

Let me know (or better to access to bugzilla above by yourself) if
anything else is required.


thanks,

Takashi

Re: [PATCH] Bluetooth: Apply initial command workaround for more Intel chips

[Fernando Ramos]

On 21/12/02 05:47PM, Takashi Iwai wrote:
> Thanks, so this seems depending on the hardware, maybe a subtle
> difference matters.  As far as I read the code changes, the workaround
> was applied in the past unconditionally, so it must be fairly safe
> even if the chip works as is.
> 
> Or, for avoiding the unnecessarily application of the workaround,
> should it be changed as a fallback after the failure at the first
> try...?

I don't know if this helps, but I started experiencing this same issue ("hci0:
command 0xfc05 tx timeout") yesterday after a kernel upgrade.

My controller is a different one:

    8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter
    ^^^^^^^^^

I tried with different (older) versions of the v5.15.x kernel but none worked.

Now, this is the interesting (?) part: today, when I switched on the computer
to keep testing, the bluetooth was *already* working once again.

I have reviewed my bash history to try to figure out what is it that I did, and
the only thing I see is that yesterday, before going to sleep, I did a full
poweroff instead of a reset (which is what I used yesterday to try different
kernels).

This does not make any sense... but then I found this [1] post from someone else
who experienced the same.

Is there any reasonable explanation for this? Could this be the reason why you
seem to have different results with the same controller (8087:0a2a)?

[1] https://bbs.archlinux.org/viewtopic.php?pid=2006188#p2006188

Re: [PATCH] Bluetooth: Apply initial command workaround for more Intel chips

[Marcel Holtmann]

Hi Fernando,

>> Thanks, so this seems depending on the hardware, maybe a subtle
>> difference matters.  As far as I read the code changes, the workaround
>> was applied in the past unconditionally, so it must be fairly safe
>> even if the chip works as is.
>> 
>> Or, for avoiding the unnecessarily application of the workaround,
>> should it be changed as a fallback after the failure at the first
>> try...?
> 
> I don't know if this helps, but I started experiencing this same issue ("hci0:
> command 0xfc05 tx timeout") yesterday after a kernel upgrade.
> 
> My controller is a different one:
> 
>    8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter
>    ^^^^^^^^^
> 
> I tried with different (older) versions of the v5.15.x kernel but none worked.
> 
> Now, this is the interesting (?) part: today, when I switched on the computer
> to keep testing, the bluetooth was *already* working once again.
> 
> I have reviewed my bash history to try to figure out what is it that I did, and
> the only thing I see is that yesterday, before going to sleep, I did a full
> poweroff instead of a reset (which is what I used yesterday to try different
> kernels).
> 
> This does not make any sense... but then I found this [1] post from someone else
> who experienced the same.
> 
> Is there any reasonable explanation for this? Could this be the reason why you
> seem to have different results with the same controller (8087:0a2a)?

we trying to figure out what went wrong here. This should be really only an issue on the really early Intel hardware like Wilkens Peak. However it seems it slipped into later parts now as well. We are investigating what happened and see if this can be fixed via a firmware update or if we really have to mark this hardware as having a broken boot loader.

Regards

Marcel

Re: [PATCH] Bluetooth: Apply initial command workaround for more Intel chips

[Takashi Iwai]

On Tue, 07 Dec 2021 17:14:02 +0100,
Marcel Holtmann wrote:
> 
> Hi Fernando,
> 
> >> Thanks, so this seems depending on the hardware, maybe a subtle
> >> difference matters.  As far as I read the code changes, the workaround
> >> was applied in the past unconditionally, so it must be fairly safe
> >> even if the chip works as is.
> >> 
> >> Or, for avoiding the unnecessarily application of the workaround,
> >> should it be changed as a fallback after the failure at the first
> >> try...?
> > 
> > I don't know if this helps, but I started experiencing this same issue ("hci0:
> > command 0xfc05 tx timeout") yesterday after a kernel upgrade.
> > 
> > My controller is a different one:
> > 
> >    8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter
> >    ^^^^^^^^^
> > 
> > I tried with different (older) versions of the v5.15.x kernel but none worked.
> > 
> > Now, this is the interesting (?) part: today, when I switched on the computer
> > to keep testing, the bluetooth was *already* working once again.
> > 
> > I have reviewed my bash history to try to figure out what is it that I did, and
> > the only thing I see is that yesterday, before going to sleep, I did a full
> > poweroff instead of a reset (which is what I used yesterday to try different
> > kernels).
> > 
> > This does not make any sense... but then I found this [1] post from someone else
> > who experienced the same.
> > 
> > Is there any reasonable explanation for this? Could this be the reason why you
> > seem to have different results with the same controller (8087:0a2a)?
> 
> we trying to figure out what went wrong here. This should be really only an issue on the really early Intel hardware like Wilkens Peak. However it seems it slipped into later parts now as well. We are investigating what happened and see if this can be fixed via a firmware update or if we really have to mark this hardware as having a broken boot loader.

The upstream bugzilla indicates that 8087:0aa7 seems hitting the same
problem:
  https://bugzilla.kernel.org/show_bug.cgi?id=215167

OTOH, on openSUSE Bugzilla, there has been a report that applying the
workaround for 8087:0026 may cause another issue about the reset
error, so the entry for 8087:0026 should be dropped.


Takashi

Re: [PATCH] Bluetooth: Apply initial command workaround for more Intel chips

[Paul Menzel]

Dear Takashi,


Am 10.12.21 um 14:23 schrieb Takashi Iwai:
> On Tue, 07 Dec 2021 17:14:02 +0100, Marcel Holtmann wrote:

>>>> Thanks, so this seems depending on the hardware, maybe a subtle
>>>> difference matters.  As far as I read the code changes, the workaround
>>>> was applied in the past unconditionally, so it must be fairly safe
>>>> even if the chip works as is.
>>>>
>>>> Or, for avoiding the unnecessarily application of the workaround,
>>>> should it be changed as a fallback after the failure at the first
>>>> try...?
>>>
>>> I don't know if this helps, but I started experiencing this same issue ("hci0:
>>> command 0xfc05 tx timeout") yesterday after a kernel upgrade.
>>>
>>> My controller is a different one:
>>>
>>>     8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter
>>>     ^^^^^^^^^
>>>
>>> I tried with different (older) versions of the v5.15.x kernel but none worked.
>>>
>>> Now, this is the interesting (?) part: today, when I switched on the computer
>>> to keep testing, the bluetooth was *already* working once again.
>>>
>>> I have reviewed my bash history to try to figure out what is it that I did, and
>>> the only thing I see is that yesterday, before going to sleep, I did a full
>>> poweroff instead of a reset (which is what I used yesterday to try different
>>> kernels).
>>>
>>> This does not make any sense... but then I found this [1] post from someone else
>>> who experienced the same.
>>>
>>> Is there any reasonable explanation for this? Could this be the reason why you
>>> seem to have different results with the same controller (8087:0a2a)?
>>
>> we trying to figure out what went wrong here. This should be really only an
>> issue on the really early Intel hardware like Wilkens Peak. However it seems
>> it slipped into later parts now as well. We are investigating what happened >> and see if this can be fixed via a firmware update or if we really 
have to
>> mark this hardware as having a broken boot loader.
> 
> The upstream bugzilla indicates that 8087:0aa7 seems hitting the same
> problem:
>    https://bugzilla.kernel.org/show_bug.cgi?id=215167
> 
> OTOH, on openSUSE Bugzilla, there has been a report that applying the
> workaround for 8087:0026 may cause another issue about the reset
> error, so the entry for 8087:0026 should be dropped.

Can you confirm that commit 95655456e7ce (Bluetooth: btintel: Fix broken 
LED quirk for legacy ROM devices) [1] merged in the current Linux 5.17 
cycle this week fixed the issue?


Kind regards,

Paul


[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95655456e7cee858a23793f67025765b4c4c227b

Re: [PATCH] Bluetooth: Apply initial command workaround for more Intel chips

[Thorsten Leemhuis]

Hi, this is your Linux kernel regression tracker speaking.

Top-posting for once, to make this easy accessible to everyone.

Could the bluetooth maintainers please provide a status update? I wonder
if it's time to bring this regression to Linus attention, as it seems to
be an issue that hits quite a few users -- and at the same takes quite a
long time to get fixed for a issue where a patch with a workaround was
already proposed one and a half months ago.

Ciao, Thorsten

On 16.01.22 15:06, Paul Menzel wrote:
> 
> Dear Takashi,
> 
> 
> Am 10.12.21 um 14:23 schrieb Takashi Iwai:
>> On Tue, 07 Dec 2021 17:14:02 +0100, Marcel Holtmann wrote:
> 
>>>>> Thanks, so this seems depending on the hardware, maybe a subtle
>>>>> difference matters.  As far as I read the code changes, the workaround
>>>>> was applied in the past unconditionally, so it must be fairly safe
>>>>> even if the chip works as is.
>>>>>
>>>>> Or, for avoiding the unnecessarily application of the workaround,
>>>>> should it be changed as a fallback after the failure at the first
>>>>> try...?
>>>>
>>>> I don't know if this helps, but I started experiencing this same
>>>> issue ("hci0:
>>>> command 0xfc05 tx timeout") yesterday after a kernel upgrade.
>>>>
>>>> My controller is a different one:
>>>>
>>>>     8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter
>>>>     ^^^^^^^^^
>>>>
>>>> I tried with different (older) versions of the v5.15.x kernel but
>>>> none worked.
>>>>
>>>> Now, this is the interesting (?) part: today, when I switched on the
>>>> computer
>>>> to keep testing, the bluetooth was *already* working once again.
>>>>
>>>> I have reviewed my bash history to try to figure out what is it that
>>>> I did, and
>>>> the only thing I see is that yesterday, before going to sleep, I did
>>>> a full
>>>> poweroff instead of a reset (which is what I used yesterday to try
>>>> different
>>>> kernels).
>>>>
>>>> This does not make any sense... but then I found this [1] post from
>>>> someone else
>>>> who experienced the same.
>>>>
>>>> Is there any reasonable explanation for this? Could this be the
>>>> reason why you
>>>> seem to have different results with the same controller (8087:0a2a)?
>>>
>>> we trying to figure out what went wrong here. This should be really
>>> only an
>>> issue on the really early Intel hardware like Wilkens Peak. However
>>> it seems
>>> it slipped into later parts now as well. We are investigating what
>>> happened >> and see if this can be fixed via a firmware update or if
>>> we really 
> have to
>>> mark this hardware as having a broken boot loader.
>>
>> The upstream bugzilla indicates that 8087:0aa7 seems hitting the same
>> problem:
>>    https://bugzilla.kernel.org/show_bug.cgi?id=215167
>>
>> OTOH, on openSUSE Bugzilla, there has been a report that applying the
>> workaround for 8087:0026 may cause another issue about the reset
>> error, so the entry for 8087:0026 should be dropped.
> 
> Can you confirm that commit 95655456e7ce (Bluetooth: btintel: Fix broken
> LED quirk for legacy ROM devices) [1] merged in the current Linux 5.17
> cycle this week fixed the issue?
> 
> 
> Kind regards,
> 
> Paul
> 
> 
> [1]:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95655456e7cee858a23793f67025765b4c4c227b
> 

Re: [PATCH] Bluetooth: Apply initial command workaround for more Intel chips

[Marcel Holtmann]

Hi Thorsten,

> Could the bluetooth maintainers please provide a status update? I wonder
> if it's time to bring this regression to Linus attention, as it seems to
> be an issue that hits quite a few users -- and at the same takes quite a
> long time to get fixed for a issue where a patch with a workaround was
> already proposed one and a half months ago.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95655456e7cee858a23793f67025765b4c4c227b

Regards

Marcel

Re: [PATCH] Bluetooth: Apply initial command workaround for more Intel chips

[Thorsten Leemhuis]

On 20.01.22 16:07, Marcel Holtmann wrote:
> 
>> Could the bluetooth maintainers please provide a status update? I wonder
>> if it's time to bring this regression to Linus attention, as it seems to
>> be an issue that hits quite a few users -- and at the same takes quite a
>> long time to get fixed for a issue where a patch with a workaround was
>> already proposed one and a half months ago.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95655456e7cee858a23793f67025765b4c4c227b

Ahh, okay, many thx for the update, it wasn't clear enough to me that
this should fix the issue. Would have been nice if the commit would have
had "Link:" tags to all reports about the issue (as explained in
Documentation/process/submitting-patches.rst and
Documentation/process/5.Posting.rst ), as that would have avoided confusion.

Anyway, to close this:

#regzbot introduced: ffcba827c0a1d
#regzbot fixed-by: 95655456e7cee858a23793f67025765b4c4c227b

Ciao, Thorsten

Re: [PATCH] Bluetooth: Apply initial command workaround for more Intel chips

[Takashi Iwai]

On Sun, 16 Jan 2022 15:06:26 +0100,
Paul Menzel wrote:
> 
> 
> Dear Takashi,
> 
> 
> Am 10.12.21 um 14:23 schrieb Takashi Iwai:
> > On Tue, 07 Dec 2021 17:14:02 +0100, Marcel Holtmann wrote:
> 
> >>>> Thanks, so this seems depending on the hardware, maybe a subtle
> >>>> difference matters.  As far as I read the code changes, the workaround
> >>>> was applied in the past unconditionally, so it must be fairly safe
> >>>> even if the chip works as is.
> >>>>
> >>>> Or, for avoiding the unnecessarily application of the workaround,
> >>>> should it be changed as a fallback after the failure at the first
> >>>> try...?
> >>>
> >>> I don't know if this helps, but I started experiencing this same issue ("hci0:
> >>> command 0xfc05 tx timeout") yesterday after a kernel upgrade.
> >>>
> >>> My controller is a different one:
> >>>
> >>>     8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter
> >>>     ^^^^^^^^^
> >>>
> >>> I tried with different (older) versions of the v5.15.x kernel but none worked.
> >>>
> >>> Now, this is the interesting (?) part: today, when I switched on the computer
> >>> to keep testing, the bluetooth was *already* working once again.
> >>>
> >>> I have reviewed my bash history to try to figure out what is it that I did, and
> >>> the only thing I see is that yesterday, before going to sleep, I did a full
> >>> poweroff instead of a reset (which is what I used yesterday to try different
> >>> kernels).
> >>>
> >>> This does not make any sense... but then I found this [1] post from someone else
> >>> who experienced the same.
> >>>
> >>> Is there any reasonable explanation for this? Could this be the reason why you
> >>> seem to have different results with the same controller (8087:0a2a)?
> >>
> >> we trying to figure out what went wrong here. This should be really only an
> >> issue on the really early Intel hardware like Wilkens Peak. However it seems
> >> it slipped into later parts now as well. We are investigating what
> >> happened >> and see if this can be fixed via a firmware update or
> >> if we really 
> have to
> >> mark this hardware as having a broken boot loader.
> >
> > The upstream bugzilla indicates that 8087:0aa7 seems hitting the same
> > problem:
> >    https://bugzilla.kernel.org/show_bug.cgi?id=215167
> >
> > OTOH, on openSUSE Bugzilla, there has been a report that applying the
> > workaround for 8087:0026 may cause another issue about the reset
> > error, so the entry for 8087:0026 should be dropped.
> 
> Can you confirm that commit 95655456e7ce (Bluetooth: btintel: Fix
> broken LED quirk for legacy ROM devices) [1] merged in the current
> Linux 5.17 cycle this week fixed the issue?

I myself have no such devices, so cannot confirm by myself.

The openSUSE Tumbleweed kernel is already updated with the upstream
fix (in 5.16.1), so user will notice whether any regression happens or
not.  Let's see.


Takashi

Re: [PATCH] Bluetooth: Apply initial command workaround for more Intel chips

[Thorsten Leemhuis]

Hi, this is your Linux kernel regression tracker speaking.

Hey bluetooth maintainers, what's the status here? It looks like the
issue was discussed quite a bit, but then nothing happened anymore. Or
am I missing something?

Other users seem to still run into the issue, see for example this report:
https://lore.kernel.org/all/b0f6f66b-28aa-9d43-0aab-e6887ee0fda8@logobject.ch/

For the rest of the mail:

[TLDR: I'm adding this regression to regzbot, the Linux kernel
regression tracking bot; most text you find below is compiled from a few
templates paragraphs some of you might have seen already.]

On 02.12.21 17:22, Takashi Iwai wrote:
> It seems that a few more Intel chips require the workaround for the
> broken initial command.  At least, per openSUSE Bugzilla reports,
> 8087:0a2a and 8087:0026 need BTUSB_INTEL_BROKEN_INITIAL_NCMD flag.
> 
> Fixes: 83f2dafe2a62 ("Bluetooth: btintel: Refactoring setup routine for legacy ROM sku")
> Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> 
> ---
>  drivers/bluetooth/btusb.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 75c83768c257..b26989b2df23 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -359,14 +359,16 @@ static const struct usb_device_id blacklist_table[] = {
>  
>  	/* Intel Bluetooth devices */
>  	{ USB_DEVICE(0x8087, 0x0025), .driver_info = BTUSB_INTEL_COMBINED },
> -	{ USB_DEVICE(0x8087, 0x0026), .driver_info = BTUSB_INTEL_COMBINED },
> +	{ USB_DEVICE(0x8087, 0x0026), .driver_info = BTUSB_INTEL_COMBINED |
> +						     BTUSB_INTEL_BROKEN_INITIAL_NCMD },
>  	{ USB_DEVICE(0x8087, 0x0029), .driver_info = BTUSB_INTEL_COMBINED },
>  	{ USB_DEVICE(0x8087, 0x0032), .driver_info = BTUSB_INTEL_COMBINED },
>  	{ USB_DEVICE(0x8087, 0x0033), .driver_info = BTUSB_INTEL_COMBINED },
>  	{ USB_DEVICE(0x8087, 0x07da), .driver_info = BTUSB_CSR },
>  	{ USB_DEVICE(0x8087, 0x07dc), .driver_info = BTUSB_INTEL_COMBINED |
>  						     BTUSB_INTEL_BROKEN_INITIAL_NCMD },
> -	{ USB_DEVICE(0x8087, 0x0a2a), .driver_info = BTUSB_INTEL_COMBINED },
> +	{ USB_DEVICE(0x8087, 0x0a2a), .driver_info = BTUSB_INTEL_COMBINED |
> +						     BTUSB_INTEL_BROKEN_INITIAL_NCMD },
>  	{ USB_DEVICE(0x8087, 0x0a2b), .driver_info = BTUSB_INTEL_COMBINED },
>  	{ USB_DEVICE(0x8087, 0x0aa7), .driver_info = BTUSB_INTEL_COMBINED },
>  	{ USB_DEVICE(0x8087, 0x0aaa), .driver_info = BTUSB_INTEL_COMBINED },

Adding the regression mailing list to the list of recipients, as it
should be in the loop for all regressions, as explained here:
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html

To be sure this issue doesn't fall through the cracks unnoticed, I'm
adding it to regzbot, my Linux kernel regression tracking bot:

#regzbot ^introduced 83f2dafe2a62
#regzbot title bluetooth: more Intel chips require the workaround for
the broken initial command
#regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=215167
#regzbot link: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124
#regzbot ignore-activity

Reminder: when fixing the issue, please add a 'Link:' tag with the URL
to the report (the parent of this mail) using the kernel.org redirector,
as explained in 'Documentation/process/submitting-patches.rst'. Regzbot
then will automatically mark the regression as resolved once the fix
lands in the appropriate tree. For more details about regzbot see footer.

Sending this to everyone that got the initial report, to make all aware
of the tracking. I also hope that messages like this motivate people to
directly get at least the regression mailing list and ideally even
regzbot involved when dealing with regressions, as messages like this
wouldn't be needed then.

Don't worry, I'll send further messages wrt to this regression just to
the lists (with a tag in the subject so people can filter them away), as
long as they are intended just for regzbot. With a bit of luck no such
messages will be needed anyway.

Ciao, Thorsten (wearing his 'Linux kernel regression tracker' hat)

P.S.: As a Linux kernel regression tracker I'm getting a lot of reports
on my table. I can only look briefly into most of them. Unfortunately
therefore I sometimes will get things wrong or miss something important.
I hope that's not the case here; if you think it is, don't hesitate to
tell me about it in a public reply, that's in everyone's interest.

BTW, I have no personal interest in this issue, which is tracked using
regzbot, my Linux kernel regression tracking bot
(https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting
this mail to get things rolling again and hence don't need to be CC on
all further activities wrt to this regression.

---
Additional information about regzbot:

If you want to know more about regzbot, check out its web-interface, the
getting start guide, and/or the references documentation:

https://linux-regtracking.leemhuis.info/regzbot/
https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md
https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md

The last two documents will explain how you can interact with regzbot
yourself if your want to.

Hint for reporters: when reporting a regression it's in your interest to
tell #regzbot about it in the report, as that will ensure the regression
gets on the radar of regzbot and the regression tracker. That's in your
interest, as they will make sure the report won't fall through the
cracks unnoticed.

Hint for developers: you normally don't need to care about regzbot once
it's involved. Fix the issue as you normally would, just remember to
include a 'Link:' tag to the report in the commit message, as explained
in Documentation/process/submitting-patches.rst
That aspect was recently was made more explicit in commit 1f57bd42b77c:
https://git.kernel.org/linus/1f57bd42b77c