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, 02 Dec 2021 17:47:46 +0100
From:   Takashi Iwai <tiwai@...e.de>
To:     Paul Menzel <pmenzel@...gen.mpg.de>
Cc:     Takashi Iwai <tiwai@...e.de>,
        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

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

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


Takashi