New: HSP/HFP mSBC profile broken with QCA6174

https://bugzilla.kernel.org/show_bug.cgi?id=215576

            Bug ID: 215576
           Summary: HSP/HFP mSBC profile broken with QCA6174
           Product: Drivers
           Version: 2.5
    Kernel Version: 5.16.7
          Hardware: x86-64
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Bluetooth
          Assignee: [email protected]
          Reporter: [email protected]
        Regression: No

Created attachment 300405
--> https://bugzilla.kernel.org/attachment.cgi?id=300405&action=edit
dmesg with 5.16.7

Between v5.15 and v5.16, mSBC via pipewire stopped working with the QCA6174 adapter.

Switching to the HSP/HFP profile with mSBC codec in pipewire produces a loud buzzing sound, and the microphone does not function. When using PulseAudio instead of pipewire, the buzzing is absent but audio input/output also don't work.

Other users are reporting the same issue at [1].

I ran a git bisect between these two versions and the issue seems to have been caused by this commit:

[b2af264ad3af437238c9500aa830ebcafb180e05] Bluetooth: Add support for HCI_Enhanced_Setup_Synchronous_Connection command

[1] https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2019

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[TLDR: I'm adding the regression report below to regzbot, the Linux kernel regression tracking bot; all text you find below is compiled from a few templates paragraphs you might have encountered already already from similar mails.]

Hi, this is your Linux kernel regression tracker speaking.

CCing the regression mailing list, as it should be in the loop for all regressions, as explained here:
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html

To be sure this issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression tracking bot:

#regzbot ^introduced b2af264ad3af437238c9500aa830ebcafb180e05 #regzbot title bluetooth: HSP/HFP mSBC profile broken with QCA6174 #regzbot ignore-activity
#regzbot link https://bugzilla.kernel.org/show_bug.cgi?id=215576

Reminder for developers: when fixing the issue, please add a 'Link:' tags pointing to the report (the mail quoted above) using lore.kernel.org/r/, as explained in 'Documentation/process/submitting-patches.rst' and 'Documentation/process/5.Posting.rst'. This allows the bot to connect the report with any patches posted or committed to fix the issue; this again allows the bot to show the current status of regressions and automatically resolve the issue when the fix hits the right tree.

I'm sending this to everyone that got the initial report, to make them aware of the tracking. I also hope that messages like this motivate people to directly get at least the regression mailing list and ideally even regzbot involved when dealing with regressions, as messages like this wouldn't be needed then.

Don't worry, I'll send further messages wrt to this regression just to the lists (with a tag in the subject so people can filter them away), if they are relevant just for regzbot. With a bit of luck no such messages will be needed anyway.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I'm getting a lot of reports on my table. I can only look briefly into most of them and lack knowledge about most of the areas they concern. I thus unfortunately will sometimes get things wrong or miss something important. I hope that's not the case here; if you think it is, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight.

Additional information about regzbot:

If you want to know more about regzbot, check out its web-interface, the
getting start guide, and the references documentation:

https://linux-regtracking.leemhuis.info/regzbot/
https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md
https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md

The last two documents will explain how you can interact with regzbot
yourself if your want to.

Hint for reporters: when reporting a regression it's in your interest to
CC the regression list and tell regzbot about the issue, as that ensures
the regression makes it onto the radar of the Linux kernel's regression
tracker -- that's in your interest, as it ensures your report won't fall
through the cracks unnoticed.

Hint for developers: you normally don't need to care about regzbot once
it's involved. Fix the issue as you normally would, just remember to
include 'Link:' tag in the patch descriptions pointing to all reports
about the issue. This has been expected from developers even before
regzbot showed up for reasons explained in
'Documentation/process/submitting-patches.rst' and
'Documentation/process/5.Posting.rst'.

TWIMC: this mail is primarily send for documentation purposes and for regzbot, my Linux kernel regression tracking bot. These mails usually contain '#forregzbot' in the subject, to make them easy to spot and filter.

#regzbot monitor:
https://lore.kernel.org/linux-bluetooth/[email protected]/
#regzbot monitor:
https://lore.kernel.org/linux-bluetooth/[email protected]/
#regzbot ignore-activity

#regzbot monitor:
https://lore.kernel.org/all/[email protected]/
#regzbot fixed-by: 38a1944deda4d9

#regzbot fixed-by: d44e1dbda36fff5d7c2586683c4adc0963aef908

https://bugzilla.kernel.org/show_bug.cgi?id=215576

--- Comment #1 from The Linux kernel's regression tracker (Thorsten Leemhuis) ([email protected]) --- [TLDR: I'm adding the regression report below to regzbot, the Linux
kernel regression tracking bot; all text you find below is compiled from
a few templates paragraphs you might have encountered already already
from similar mails.]

Hi, this is your Linux kernel regression tracker speaking.

CCing the regression mailing list, as it should be in the loop for all regressions, as explained here:
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html

To be sure this issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression tracking bot:

#regzbot ^introduced b2af264ad3af437238c9500aa830ebcafb180e05 #regzbot title bluetooth: HSP/HFP mSBC profile broken with QCA6174 #regzbot ignore-activity
#regzbot link https://bugzilla.kernel.org/show_bug.cgi?id=215576

Reminder for developers: when fixing the issue, please add a 'Link:' tags pointing to the report (the mail quoted above) using lore.kernel.org/r/, as explained in 'Documentation/process/submitting-patches.rst' and 'Documentation/process/5.Posting.rst'. This allows the bot to connect the report with any patches posted or committed to fix the issue; this again allows the bot to show the current status of regressions and automatically resolve the issue when the fix hits the right tree.

I'm sending this to everyone that got the initial report, to make them aware of the tracking. I also hope that messages like this motivate people to directly get at least the regression mailing list and ideally even regzbot involved when dealing with regressions, as messages like this wouldn't be needed then.

Don't worry, I'll send further messages wrt to this regression just to the lists (with a tag in the subject so people can filter them away), if they are relevant just for regzbot. With a bit of luck no such messages will be needed anyway.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I'm getting a lot of reports on my table. I can only look briefly into most of them and lack knowledge about most of the areas they concern. I thus unfortunately will sometimes get things wrong or miss something important. I hope that's not the case here; if you think it is, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight.

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215576

Mike Jones ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
Regression|No |Yes

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215576

--- Comment #2 from [email protected] ---
Same regression on a mediatek mt7921e, so unlikely to be controller specific? I also confirm that downgrading to 5.15 fixes mSBC.

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215576

The Linux kernel's regression tracker (Thorsten Leemhuis) ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

                 CC|                            |[email protected],
                   |                            |[email protected]

--- Comment #3 from The Linux kernel's regression tracker (Thorsten Leemhuis) ([email protected]) --- hey bluetooth maintainers, what the status here? This regression was reported
more than ten days ago, it was bisected, and a second person roughly confirms
it, nevertheless there wasn't a single reply yet. Is somebody looking into
this?

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

Hi Kiran,

Looks like a regression introduced by:

https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=b2af264ad3af437238c9500aa830ebcafb180e05

It seems BT_VOICE sets BT_CODEC_TRANSPARENT when perhaps should be setting BT_CODEC_MSBC:

index 8eabf41b2993..b35c772efc7e 100644
@@ -879,15 +879,9 @@ static int sco_sock_setsockopt(struct socket

*sock, int level, int optname,

                }

                sco_pi(sk)->setting = voice.setting;

- hdev = hci_get_route(&sco_pi(sk)->dst, &sco_pi(sk)->src,
- BDADDR_BREDR);
- if (!hdev) {
- err = -EBADFD;
- break;
- }
- if (enhanced_sco_capable(hdev) &&
- voice.setting == BT_VOICE_TRANSPARENT)
- sco_pi(sk)->codec.id = BT_CODEC_TRANSPARENT;
+ if (voice.setting == BT_VOICE_TRANSPARENT)
+ sco_pi(sk)->codec.id = BT_CODEC_MSBC;
+

                hci_dev_put(hdev);
                break;

Luiz Augusto von Dentz

https://bugzilla.kernel.org/show_bug.cgi?id=215576

--- Comment #4 from Luiz Von Dentz ([email protected]) --- Hi Kiran,

Looks like a regression introduced by:

https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=b2af264ad3af437238c9500aa830ebcafb180e05

It seems BT_VOICE sets BT_CODEC_TRANSPARENT when perhaps should be setting BT_CODEC_MSBC:

index 8eabf41b2993..b35c772efc7e 100644
@@ -879,15 +879,9 @@ static int sco_sock_setsockopt(struct socket

*sock, int level, int optname,

                }

                sco_pi(sk)->setting = voice.setting;

- hdev = hci_get_route(&sco_pi(sk)->dst, &sco_pi(sk)->src,
- BDADDR_BREDR);
- if (!hdev) {
- err = -EBADFD;
- break;
- }
- if (enhanced_sco_capable(hdev) &&
- voice.setting == BT_VOICE_TRANSPARENT)
- sco_pi(sk)->codec.id = BT_CODEC_TRANSPARENT;
+ if (voice.setting == BT_VOICE_TRANSPARENT)
+ sco_pi(sk)->codec.id = BT_CODEC_MSBC;
+

                hci_dev_put(hdev);
                break;

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

This is an automated email and please do not reply to this email.

Dear Submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository.

----- Output -----
error: corrupt patch at line 41
hint: Use 'git am --show-current-patch' to see the failed patch

Please resolve the issue and submit the patches again.

---
Regards,
Linux Bluetooth

https://bugzilla.kernel.org/show_bug.cgi?id=215576

--- Comment #5 from [email protected] ---
I tried applying this patch, even though removing the error checking didn't look right to me. Indeed, after, when trying this, it results in BUG: kernel NULL pointer dereference, with the stack directly located here:

Feb 26 15:21:16 kernel:  sco_sock_setsockopt+0x110/0x530 [bluetooth]

Changing just codec.id = BT_CODEC_MSBC doesn't work either (results in a brief noise on the headset).

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215576

--- Comment #6 from [email protected] ---
Commit b2af264ad3af437238c9500aa830ebcafb180e05 doesn't revert cleanly anymore. Looking at the code however, it's obvious that just setting BT_CODEC_MSBC can't work, since hci_enhanced_setup_sync_conn itself only handles TRANSPARENT (which looks like it's already mSBC underneath) and CVSD.

However I tried to brutally disable enhanced synchronous connection support, which is what the commit adds, by doing:

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215576

--- Comment #7 from Mike Jones ([email protected]) ---
Thanks for looking into this, Luiz, and thanks wavexx for your experiments! I can confirm the same results on my system: the first patch (codec.id = BT_CODEC_MSBC) doesn't work, but wavexx's workaround to disable enhanced SCO results in fully-functional mSBC.

I've managed to find a laptop with an Intel AX200, and here mSBC works fine on an unpatched v5.16.11 kernel. So this issue doesn't seem to affect all adapters.

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215576

[email protected] changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #8 from [email protected] ---
If switching back to non-enhanced sco connect is what it takes, then maybe it should be enabled only when userspace has set some codec offload setting at least until someone finds a proper fix. Maybe along these lines:
https://patchwork.kernel.org/project/bluetooth/patch/[email protected]/

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215576

--- Comment #9 from [email protected] ---
Any consensus at least of what a proper fix would look like? I have to rebuild a new kernel for this laptop and I can help test around @pav's patch if needed.

Is Kiran in the loop?

I no longer have access to an AX20? chipset to make some tests on it sadly.

Maybe we just need to check a controller capabilities flag for E-SCO in addition to the device's own capabilities.

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215576

--- Comment #10 from Luiz Von Dentz ([email protected]) --- Posted a new series about this:

https://patchwork.kernel.org/project/bluetooth/list/?series=627309

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215576

--- Comment #11 from [email protected] ---
So did the series got accepted/merged, and did it land in linux yet? (patchwork now shows me just an empty page..).

Just checking on the 5.18 trunk I don't see any change besides minor other fixes.

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215576

Daniel Wennberg ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #12 from Daniel Wennberg ([email protected]) --- I'm a rookie here but it looks like the fix entered the mainline tree with this merge:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e062cda7d90543ac8c7700fc7c5527d0c0f22ad

The fix itself is this commit and its immediate parents:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d44e1dbda36fff5d7c2586683c4adc0963aef908

So it looks like it will be included in the 5.19 release. Hugely appreciated!

However, not having a functioning bluetooth HSP mode is incredibly inconvenient in the age of Zoom, and there are now three major revisions where this is
broken: 5.16, 5.17, and 5.18. Any chance we'll see some backports to get this in people's hands faster?

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215576

--- Comment #13 from Daniel Wennberg ([email protected]) --- The regression tracker expressed a similar sentiment here:
https://patchwork.kernel.org/project/bluetooth/patch/[email protected]/#24810088

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215576

--- Comment #14 from The Linux kernel's regression tracker (Thorsten Leemhuis) ([email protected]) ---

The maintainers just need to ask the stable to to backport this; note sure, maybe asking them for this on the mailing list might lead to better results.

But even if they don't do that, there is a good chance that this might be backported within the next two weeks

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215576

--- Comment #15 from [email protected] ---
Created attachment 301217
--> https://bugzilla.kernel.org/attachment.cgi?id=301217&action=edit
Add HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN to btmtk to fix mSBC

I'm testing now 5.18.5 (from debian unstable) where this has been backported.

Still broken on mt7921e, mSBM doesn't work.

I see no quirk set there. Adding HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN to btmtk fixes it.

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215576

--- Comment #16 from The Linux kernel's regression tracker (Thorsten Leemhuis) ([email protected]) --- (In reply to wavexx from comment #15)

Thx. FWIW, this might easily get lost here. Would be really good if you could sent this to the bluetooth maintainers, ideally as a proper patch with changelog and everything:

BLUETOOTH DRIVERS

M:      Marcel Holtmann <[email protected]>
M:      Johan Hedberg <[email protected]>
M:      Luiz Augusto von Dentz <[email protected]>
L:      [email protected]
S:      Supported
W:      http://www.bluez.org/
T:      git

git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git
T: git
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
F: drivers/bluetooth/

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215576

--- Comment #17 from [email protected] ---
Well I hope it's not going to get lost _in_ the bug tracker ;)

At the moment I'd be happy if some maintainer simply made the commit. For a one line change I'd rather not start cloning yet another repo...

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215576

--- Comment #18 from The Linux kernel's regression tracker (Thorsten Leemhuis) ([email protected]) --- (In reply to wavexx from comment #17)

To quote
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html:

Very few subsystems use a bug tracker, and only some of those rely on bugzilla.kernel.org.

With a bit of luck that will work. But if you don't hear anything within the next few days, you really want to send it by mail. A simple mail with a patch like the one you applied here might do the trick with a bit of luck.

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215576

Dmitry Nezhevenko ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #19 from Dmitry Nezhevenko ([email protected]) --- I think that I've same problem with followed bluetooth adapter:

Bus 001 Device 005: ID 8087:0026 Intel Corp.

[   41.184754] Bluetooth: hci0: Bootloader revision 0.4 build 0 week 30 2018
[   41.185760] Bluetooth: hci0: Device revision is 2
[   41.185769] Bluetooth: hci0: Secure boot is enabled
[   41.185775] Bluetooth: hci0: OTP lock is enabled
[   41.185780] Bluetooth: hci0: API lock is enabled
[   41.185784] Bluetooth: hci0: Debug lock is disabled
[   41.185789] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[   41.187739] Bluetooth: hci0: Found device firmware: intel/ibt-19-0-4.sfi
[   41.187762] Bluetooth: hci0: Boot Address: 0x24800
[   41.187763] Bluetooth: hci0: Firmware Version: 191-21.21
[   41.884145] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   41.884148] Bluetooth: BNEP filters: protocol multicast
[   41.884150] Bluetooth: BNEP socket layer initialized
[   42.786061] Bluetooth: hci0: Waiting for firmware download to complete
[   42.786699] Bluetooth: hci0: Firmware loaded in 1561482 usecs
[   42.786723] Bluetooth: hci0: Waiting for device to boot
[   42.801703] Bluetooth: hci0: Device booted in 14639 usecs
[   42.801733] Bluetooth: hci0: Found Intel DDC parameters:
intel/ibt-19-0-4.ddc
[   42.803713] Bluetooth: hci0: Applying Intel DDC parameters completed
[   42.804752] Bluetooth: hci0: Firmware revision 0.0 build 191 week 21 2021
[   42.887147] Bluetooth: RFCOMM TTY layer initialized
[   42.887153] Bluetooth: RFCOMM socket layer initialized
[   42.887156] Bluetooth: RFCOMM ver 1.11

Also running debian 5.18.5 kernel and getting cracking sound recorded from mic.

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215576

--- Comment #20 from The Linux kernel's regression tracker (Thorsten Leemhuis) ([email protected]) --- (In reply to Dmitry Nezhevenko from comment #19)

See the advice given in Comment 16 (and Comment 18, too) of this bug. In short:
best to report this by mail (or a new ticket).

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.