Bug 199271

Summary: AR3012 [0cf3:3004] - Bluetooth: hci0: don't support firmware rome 0x31010000.
Product: Drivers Reporter: Przemek (soprwa)
Component: BluetoothAssignee: linux-bluetooth (linux-bluetooth)
Status: RESOLVED CODE_FIX    
Severity: normal CC: antdev66, antonio.toma, jwrdegoede, neyzanrumi, rafalbilski
Priority: P1    
Hardware: x86-64   
OS: Linux   
Kernel Version: 4.16 Subsystem:
Regression: No Bisected commit-id:
Attachments: dmesg output
excerpt from "lsusb -v"
kernel config file
[PATCH] Bluetooth: btusb: Apply QCQ_ROME setup for BTUSB_ATH3012 quirk, too

Description Przemek 2018-04-03 14:35:39 UTC
Created attachment 275081 [details]
dmesg output

Hi all,
I am using gentoo ~amd64 with kernel 4.16.

My netbook, Lenovo G50-45, has an AR3012 bluetooth adapter.

After upgrade from kernel 4.15.14 bluez cannot find BT, and dmesg output is saying that: "Bluetooth: hci0: don't support firmware rome 0x31010000".

I have attached:
- dmesg output;
- excerpt from "lsusb -v";
- full kernel config file.

My system has linux firmware dated 2018-03-14.

Any help is appreciated.
Thanks,
Przemek.
Comment 1 Przemek 2018-04-03 14:36:48 UTC
Created attachment 275083 [details]
excerpt from "lsusb -v"
Comment 2 Przemek 2018-04-03 14:37:23 UTC
Created attachment 275085 [details]
kernel config file
Comment 3 Przemek 2018-04-06 18:49:29 UTC
I have bisected and commit that is causing problems on AR3012 is f44cb4b19ed40b655c2d422c9021ab2c2625adb6.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=15a4417cc65212d2cf895e872d9757b0785af4f4

"Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174

The Atheros 1525/QCA6174 BT doesn't seem working properly on the
recent kernels, as it tries to load a wrong firmware
ar3k/AthrBT_0x00000200.dfu and it fails.

This seems to have been a problem for some time, and the known
workaround is to apply BTUSB_QCA_ROM quirk instead of BTUSB_ATH3012.

The device in question is:

T: Bus=01 Lev=01 Prnt=01 Port=09 Cnt=03 Dev#=  4 Spd=12   MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P: Vendor=0cf3 ProdID=3004 Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms

Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=1082504
Reported-by: Ivan Levshin <ivan.levshin@microfocus.com>
Tested-by: Ivan Levshin <ivan.levshin@microfocus.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"


Reverting this patch make AR3012 BT work again.

From dmesg:

"[   36.434510] usb 4-1.3: New USB device found, idVendor=0cf3, idProduct=3004
[   36.434515] usb 4-1.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[   36.546749] Bluetooth: RFCOMM TTY layer initialized
[   36.546761] Bluetooth: RFCOMM socket layer initialized
[   36.546778] Bluetooth: RFCOMM ver 1.11"
Comment 4 antonio.toma 2018-04-09 08:05:10 UTC
QC reused the usb identifier from BT AR3012 for Rome based WiFi devices (see http://lkml.iu.edu/hypermail/linux/kernel/1603.0/00209.html) causing this mess.
Commit f44cb4b19ed40b655c2d422c9021ab2c2625adb6 doesn't look as proper solution, though, as it breaks an existing working device to fix a new one
Comment 5 Neyzan 2018-04-22 10:37:05 UTC
I filed this same bug with the blueman project (https://github.com/blueman-project/blueman/issues/862), but it seems that the problem originates in the kernel. From 4.15.14 onwards BT is not functioning and I get the following:


"journalctl" gave this related output:

Apr 22 11:36:15 localhost.localdomain kernel: Bluetooth: hci0: don't support firmware rome 0x31010000


"hciconfig" gives me:

hci0:   Type: Primary  Bus: USB
        BD Address: 00:00:00:00:00:00  ACL MTU: 0:0  SCO MTU: 0:0
        DOWN 
        RX bytes:0 acl:0 sco:0 events:0 errors:0
        TX bytes:0 acl:0 sco:0 commands:0 errors:0


"hciconfig hci0 reset":

Can't init device hci0: Input/output error (5)
Comment 6 Rafa&#322; Bilski 2018-04-26 20:01:53 UTC
Kernel 4.16.5, Archlinux on Lenovo IdeaPad Flex 10

I don't use Bluetooth often, but I just needed it to work and I get message:
"Bluetooth: hci0: don't support firmware rome 0x31010000"

Bus 001 Device 005: ID 0cf3:3004 Qualcomm Atheros Communications AR3012 Bluetooth 4.0
Comment 7 Neyzan 2018-04-26 21:37:35 UTC
This issue was also reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1568911
Comment 8 Hans de Goede 2018-04-27 08:59:46 UTC
Hi,

Thank you for the bug-report.

I've submitted a revert for the commit causing this upstream, this should hopefully find its way into a new 4.16.x release soonish.

In the mean time we are working on an alternative fix to get the bluetooth devices which were fixed by the troublesome changes to work, without breaking other bluetooth devices.

If you're a Fedora user, see https://bugzilla.redhat.com/show_bug.cgi?id=1568911 for a test-kernel build which includes the revert + the alternative fix we are working on.

Regards,

Hans
Comment 9 Przemek 2018-04-27 09:37:27 UTC
(In reply to Hans de Goede from comment #8)
> I've submitted a revert for the commit causing this upstream, this should
> hopefully find its way into a new 4.16.x release soonish.

Thank you for the firm response on this.
For me with gentoo it is not critical to revert the troublesome commit, but when kernels are precompiled it's indeed "inconvenience".

> In the mean time we are working on an alternative fix to get the bluetooth
> devices which were fixed by the troublesome changes to work, without
> breaking other bluetooth devices.

If you need any cross-testing on the new patch, please do not hesitate.

Thanks, 
Przemek.
Comment 10 Hans de Goede 2018-04-27 09:41:35 UTC
Created attachment 275613 [details]
[PATCH] Bluetooth: btusb: Apply QCQ_ROME setup for BTUSB_ATH3012 quirk, too

Here is the patch we are looking at as a replacement for the reverted commit.

If you can test this patch (together with the reverted commit) and let us know if this does NOT break things for you (unlike the previous reverted patch) then that would be great.
Comment 11 Hans de Goede 2018-04-27 09:42:57 UTC
I just (In reply to Przemek from comment #9)
> If you need any cross-testing on the new patch, please do not hesitate.

I just attached a patch, if you can test this patch (together with the reverted commit) that would be great.

I accidentally made the attachment and comment private, but you should be able to see it now.
Comment 12 Hans de Goede 2018-04-27 09:43:55 UTC
Erm to be clear when I say "together with the reverted commit" what I mean is that to test you should:

1) Revert the commit causing the trouble
2) Apply the attached patch on top of the revert.
Comment 13 Przemek 2018-04-27 10:41:29 UTC
Just for the clarification if I understand your instructions correctly:
1. Revert the ""Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174".
2. Apply the patch that you provided.

My AR3012 [0cf3:3004] is working properly, there is no message in dmesg, and I can connect a PC with my phone (tested by sending files from phone to PC and from the PC to the phone).

Everything was done on 4.16.4 kernel, so if this patch restores functionality of bluetooth devices which were fixed by the troublesome changes IMHO it could be targeted upstream.

Thanks,
Przemek.
Comment 14 Hans de Goede 2018-04-27 12:12:05 UTC
(In reply to Przemek from comment #13)
> Just for the clarification if I understand your instructions correctly:
> 1. Revert the ""Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174".
> 2. Apply the patch that you provided.
> 
> My AR3012 [0cf3:3004] is working properly, there is no message in dmesg, and
> I can connect a PC with my phone (tested by sending files from phone to PC
> and from the PC to the phone).
> 
> Everything was done on 4.16.4 kernel, so if this patch restores
> functionality of bluetooth devices which were fixed by the troublesome
> changes IMHO it could be targeted upstream.

Great, thank you for testing. I've told Takashi (who wrote the patch) that he can go ahead and submit it upstream.
Comment 15 Przemek 2018-05-20 11:17:06 UTC
I am closing this bug report because troublesome commit was reverted upstream in 4.16.9, 4.14.41, 4.9.100 and 4.4.132.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=544a591668813583021474fa5c7ff4942244d654

Unfortunately alternative fix to get the Atheros 1525/QCA6174 to work hasn't been committed yet, but that's another story.

Thank you very much Hans,
Przemek.
Comment 16 Antonio 2020-12-14 08:48:46 UTC
After upgrade kernel to version 5.10:

kernel: Bluetooth: hci0: don't support firmware rome 0x31010000

previous kernel 5.9.13 was ok.
Comment 17 Hans de Goede 2020-12-14 10:12:51 UTC
(In reply to anthony from comment #16)
> After upgrade kernel to version 5.10:
> 
> kernel: Bluetooth: hci0: don't support firmware rome 0x31010000
> 
> previous kernel 5.9.13 was ok.

The last activity on this bug was more then 2 years ago, so this sounds like a comletely new (introduced in 5.10) and unrelated problem. Please file a new bug for this.