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

[Paul Menzel]

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?


Kind regards,

Paul


[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95655456e7cee858a23793f67025765b4c4c227b