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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 2 Dec 2021 17:58:01 +0100
From:   Paul Menzel <pmenzel@...gen.mpg.de>
To:     Takashi Iwai <tiwai@...e.de>
Cc:     Marcel Holtmann <marcel@...tmann.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        Tedd Ho-Jeong An <tedd.an@...el.com>,
        linux-kernel@...r.kernel.org, linux-bluetooth@...r.kernel.org
Subject: Re: [PATCH] Bluetooth: Apply initial command workaround for more
 Intel chips

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@...e.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