From: Takashi Iwai <firstname.lastname@example.org>
To: Marcel Holtmann <email@example.com>
Cc: Takashi Iwai <firstname.lastname@example.org>, Paul Menzel <email@example.com>,
Johan Hedberg <firstname.lastname@example.org>,
Luiz Augusto von Dentz <email@example.com>,
Tedd Ho-Jeong An <firstname.lastname@example.org>,
Subject: Re: [PATCH] Bluetooth: Apply initial command workaround for more Intel chips
Date: Sat, 04 Dec 2021 12:20:17 +0100 [thread overview]
Message-ID: <email@example.com> (raw)
On Fri, 03 Dec 2021 22:18:06 +0100,
Marcel Holtmann wrote:
> Hi Takashi,
> >>>>> 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 <firstname.lastname@example.org>
> >>>> […]
> >>>> 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  and a
> >>>> problem transferring greater than some bytes files with the Nokia N9
> >>>> .
> >>>> 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-18.104.22.168.e.bseq
> >>>> [ 8.233520] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-22.214.171.124.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?
> > Maybe, if the upstream agrees with that. More comments needed from
> > Intel, as it's a kind of black magic.
> >>> 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.
> > There two different machines in the report.
> >> Can you check,
> >> what firmware is used?
> > It's the place before loading the firmware, so the firmware version
> > doesn't matter.
> I want to apply this quirk to as little devices as possible. It is one of these quirks we have to hardcode per USB VID:PID since we can’t auto-detect which boot loader is faulty.
> So before I blacklist them, we better get a good understand of which they are. Can you include a btmon trace for that part. You most likely have to blacklist btusb.ko, start btmon and then load btusb.ko manually. One with and one without the quirk. And add that to the commit message.
One of the reporters uploaded the logs to the kernel.org bugzilla
(I forgot to add this URL to the patch description, although this
could be reached from openSUSE Bugzila entry.)
Let me know (or better to access to bugzilla above by yourself) if
anything else is required.
next prev parent reply other threads:[~2021-12-04 11:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-02 16:22 [PATCH] Bluetooth: Apply initial command workaround for more Intel chips Takashi Iwai
2021-12-02 16:32 ` Paul Menzel
2021-12-02 16:47 ` Takashi Iwai
2021-12-02 16:58 ` Paul Menzel
2021-12-03 7:24 ` Takashi Iwai
2021-12-03 21:18 ` Marcel Holtmann
2021-12-04 11:20 ` Takashi Iwai [this message]
2021-12-05 10:33 ` Fernando Ramos
2021-12-07 16:14 ` Marcel Holtmann
2021-12-10 13:23 ` Takashi Iwai
2022-01-16 14:06 ` Paul Menzel
2022-01-20 14:26 ` Thorsten Leemhuis
2022-01-20 15:07 ` Marcel Holtmann
2022-01-20 15:13 ` Thorsten Leemhuis
2022-01-20 14:32 ` Takashi Iwai
2021-12-28 12:43 ` Thorsten Leemhuis
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).