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]
Message-ID: <s5h7dcnt0lp.wl-tiwai@suse.de>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ