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@xxxxxxx>
> >
> 
> […]
> 
> 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