From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0076BC433F5 for ; Thu, 20 Jan 2022 14:32:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348377AbiATOcN (ORCPT ); Thu, 20 Jan 2022 09:32:13 -0500 Received: from smtp-out1.suse.de ([195.135.220.28]:60416 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242911AbiATOcF (ORCPT ); Thu, 20 Jan 2022 09:32:05 -0500 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 6D2DD218F4; Thu, 20 Jan 2022 14:32:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1642689124; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SdhE3yGuL1j1Y+9OkqRVq3PYCvoY1DAlQilRPmBvGa8=; b=Z89nY7b1TszvbvkGqCkD7rDKUuWHkU0eeIXJwnjqgQF5xXRtHbn0b5bmz8iOSp6G877f6T lwbo88tTnXL7RK7Op1Vl1BfjfLOr3Skg2XjkZBKODtd+OmdpNLYCsm9YXAoGZrno7HDrm6 tlUh/Sx822O8fJ8Nt7SnEQ4IXO2PWao= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1642689124; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SdhE3yGuL1j1Y+9OkqRVq3PYCvoY1DAlQilRPmBvGa8=; b=FQ5VS20Vy0hZ4gkgxCBbhE2E64YBMsmabTCWpeoED4zcze0kzNesgJGp3cMlIue8i/t+zV PLN9cPpUrtfGe0DQ== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id 4ACFBA3B83; Thu, 20 Jan 2022 14:32:04 +0000 (UTC) Date: Thu, 20 Jan 2022 15:32:04 +0100 Message-ID: From: Takashi Iwai To: Paul Menzel Cc: Takashi Iwai , Fernando Ramos , Johan Hedberg , Luiz Augusto von Dentz , Tedd Ho-Jeong An , LKML , linux-bluetooth@vger.kernel.org, Marcel Holtmann Subject: Re: [PATCH] Bluetooth: Apply initial command workaround for more Intel chips In-Reply-To: <7886757f-60f4-b63e-95a6-52dc7dcb86d8@molgen.mpg.de> References: <20211202162256.31837-1-tiwai@suse.de> <1D49EE9C-42D4-45C9-AE37-F4C508FD2D64@holtmann.org> <7886757f-60f4-b63e-95a6-52dc7dcb86d8@molgen.mpg.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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