* Atheros 1525/QCA6174 BT issue @ 2018-03-08 8:27 Takashi Iwai 2018-03-08 9:06 ` Marcel Holtmann 0 siblings, 1 reply; 11+ messages in thread From: Takashi Iwai @ 2018-03-08 8:27 UTC (permalink / raw) To: Marcel Holtmann, Johan Hedberg; +Cc: linux-bluetooth, linux-kernel Hi, we've got a but report about the broken Atheros BT on the recent kernels: http://bugzilla.opensuse.org/show_bug.cgi?id=1082504 In short, btusb can't load the patch ar3k/AthrBT_0x00000200.dfu, and this could be worked around by the patch to move 0cf3:3004 blacklist entry to use BTUSB_QCA_ROM instead of BTUSB_ATH3012. And this looks like a long-standing problem, at least for over two years. Many web pages suggest the same patch, but it's never merged to upstream. So this made me wonder what's going on. I see that the BTUSB_ATH3012 quirk was originally introduced just for this chip id (0cf3:3004). Is it a different variant from the original chip that causes a problem? I'm happy to get any fix patch and can provide a test kernel to the reporter. FWIW, the device looks like: 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 And the lsusb output: Bus 001 Device 004: ID 0cf3:3004 Qualcomm Atheros Communications AR3012 Bluetooth 4.0 thanks, Takashi ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Atheros 1525/QCA6174 BT issue 2018-03-08 8:27 Atheros 1525/QCA6174 BT issue Takashi Iwai @ 2018-03-08 9:06 ` Marcel Holtmann 2018-03-08 9:16 ` Takashi Iwai 0 siblings, 1 reply; 11+ messages in thread From: Marcel Holtmann @ 2018-03-08 9:06 UTC (permalink / raw) To: Takashi Iwai; +Cc: Johan Hedberg, Linux Bluetooth mailing list, linux-kernel Hi Takashi, > we've got a but report about the broken Atheros BT on the recent > kernels: > http://bugzilla.opensuse.org/show_bug.cgi?id=1082504 > > In short, btusb can't load the patch ar3k/AthrBT_0x00000200.dfu, and > this could be worked around by the patch to move 0cf3:3004 blacklist > entry to use BTUSB_QCA_ROM instead of BTUSB_ATH3012. > > And this looks like a long-standing problem, at least for over two > years. Many web pages suggest the same patch, but it's never merged > to upstream. > > So this made me wonder what's going on. I see that the BTUSB_ATH3012 > quirk was originally introduced just for this chip id (0cf3:3004). > Is it a different variant from the original chip that causes a > problem? not all patches from distro kernel are sent upstream. I have not heard of this specific issues, but happy to accept patches to get it fixed. Regards Marcel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Atheros 1525/QCA6174 BT issue 2018-03-08 9:06 ` Marcel Holtmann @ 2018-03-08 9:16 ` Takashi Iwai 2018-03-13 8:05 ` Takashi Iwai 0 siblings, 1 reply; 11+ messages in thread From: Takashi Iwai @ 2018-03-08 9:16 UTC (permalink / raw) To: Marcel Holtmann; +Cc: Johan Hedberg, Linux Bluetooth mailing list, linux-kernel On Thu, 08 Mar 2018 10:06:51 +0100, Marcel Holtmann wrote: > > Hi Takashi, > > > we've got a but report about the broken Atheros BT on the recent > > kernels: > > http://bugzilla.opensuse.org/show_bug.cgi?id=1082504 > > > > In short, btusb can't load the patch ar3k/AthrBT_0x00000200.dfu, and > > this could be worked around by the patch to move 0cf3:3004 blacklist > > entry to use BTUSB_QCA_ROM instead of BTUSB_ATH3012. > > > > And this looks like a long-standing problem, at least for over two > > years. Many web pages suggest the same patch, but it's never merged > > to upstream. > > > > So this made me wonder what's going on. I see that the BTUSB_ATH3012 > > quirk was originally introduced just for this chip id (0cf3:3004). > > Is it a different variant from the original chip that causes a > > problem? > > not all patches from distro kernel are sent upstream. I have not heard of this specific issues, but happy to accept patches to get it fixed. OK, basically it's like below. But, as mentioned, this made me wonder whether it's the right fix. The BTUSB_ATH3012 quirk was introduced exactly for this chip ID (0cf3:3004), and now this chip is moved to another quirk... If this is the right move, I can re-submit via git-send-email, too. Just let me know. thanks, Takashi -- 8< -- From: Takashi Iwai <tiwai@suse.de> Subject: [PATCH] Bluebooth: 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 Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> --- drivers/bluetooth/btusb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 60bf04b8f103..c5c566fdc629 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -231,7 +231,6 @@ static const struct usb_device_id blacklist_table[] = { { USB_DEVICE(0x0930, 0x0227), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0b05, 0x17d0), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0cf3, 0x0036), .driver_info = BTUSB_ATH3012 }, - { USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0cf3, 0x3008), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0cf3, 0x311d), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0cf3, 0x311e), .driver_info = BTUSB_ATH3012 }, @@ -264,6 +263,7 @@ static const struct usb_device_id blacklist_table[] = { { USB_DEVICE(0x0489, 0xe03c), .driver_info = BTUSB_ATH3012 }, /* QCA ROME chipset */ + { USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_QCA_ROME }, { USB_DEVICE(0x0cf3, 0xe007), .driver_info = BTUSB_QCA_ROME }, { USB_DEVICE(0x0cf3, 0xe009), .driver_info = BTUSB_QCA_ROME }, { USB_DEVICE(0x0cf3, 0xe010), .driver_info = BTUSB_QCA_ROME }, -- 2.16.2 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: Atheros 1525/QCA6174 BT issue 2018-03-08 9:16 ` Takashi Iwai @ 2018-03-13 8:05 ` Takashi Iwai 2018-03-13 8:10 ` Marcel Holtmann 0 siblings, 1 reply; 11+ messages in thread From: Takashi Iwai @ 2018-03-13 8:05 UTC (permalink / raw) To: Marcel Holtmann; +Cc: Johan Hedberg, Linux Bluetooth mailing list, linux-kernel On Thu, 08 Mar 2018 10:16:46 +0100, Takashi Iwai wrote: > > On Thu, 08 Mar 2018 10:06:51 +0100, > Marcel Holtmann wrote: > > > > Hi Takashi, > > > > > we've got a but report about the broken Atheros BT on the recent > > > kernels: > > > http://bugzilla.opensuse.org/show_bug.cgi?id=1082504 > > > > > > In short, btusb can't load the patch ar3k/AthrBT_0x00000200.dfu, and > > > this could be worked around by the patch to move 0cf3:3004 blacklist > > > entry to use BTUSB_QCA_ROM instead of BTUSB_ATH3012. > > > > > > And this looks like a long-standing problem, at least for over two > > > years. Many web pages suggest the same patch, but it's never merged > > > to upstream. > > > > > > So this made me wonder what's going on. I see that the BTUSB_ATH3012 > > > quirk was originally introduced just for this chip id (0cf3:3004). > > > Is it a different variant from the original chip that causes a > > > problem? > > > > not all patches from distro kernel are sent upstream. I have not heard of this specific issues, but happy to accept patches to get it fixed. > > OK, basically it's like below. > But, as mentioned, this made me wonder whether it's the right fix. > The BTUSB_ATH3012 quirk was introduced exactly for this chip ID > (0cf3:3004), and now this chip is moved to another quirk... > > If this is the right move, I can re-submit via git-send-email, too. > Just let me know. Marcel, could you take a look at this? If it sucks, let's seek for a better solution. thanks, Takashi > > > thanks, > > Takashi > > -- 8< -- > From: Takashi Iwai <tiwai@suse.de> > Subject: [PATCH] Bluebooth: 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 > Cc: <stable@vger.kernel.org> > Signed-off-by: Takashi Iwai <tiwai@suse.de> > --- > drivers/bluetooth/btusb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c > index 60bf04b8f103..c5c566fdc629 100644 > --- a/drivers/bluetooth/btusb.c > +++ b/drivers/bluetooth/btusb.c > @@ -231,7 +231,6 @@ static const struct usb_device_id blacklist_table[] = { > { USB_DEVICE(0x0930, 0x0227), .driver_info = BTUSB_ATH3012 }, > { USB_DEVICE(0x0b05, 0x17d0), .driver_info = BTUSB_ATH3012 }, > { USB_DEVICE(0x0cf3, 0x0036), .driver_info = BTUSB_ATH3012 }, > - { USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 }, > { USB_DEVICE(0x0cf3, 0x3008), .driver_info = BTUSB_ATH3012 }, > { USB_DEVICE(0x0cf3, 0x311d), .driver_info = BTUSB_ATH3012 }, > { USB_DEVICE(0x0cf3, 0x311e), .driver_info = BTUSB_ATH3012 }, > @@ -264,6 +263,7 @@ static const struct usb_device_id blacklist_table[] = { > { USB_DEVICE(0x0489, 0xe03c), .driver_info = BTUSB_ATH3012 }, > > /* QCA ROME chipset */ > + { USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_QCA_ROME }, > { USB_DEVICE(0x0cf3, 0xe007), .driver_info = BTUSB_QCA_ROME }, > { USB_DEVICE(0x0cf3, 0xe009), .driver_info = BTUSB_QCA_ROME }, > { USB_DEVICE(0x0cf3, 0xe010), .driver_info = BTUSB_QCA_ROME }, > -- > 2.16.2 > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Atheros 1525/QCA6174 BT issue 2018-03-13 8:05 ` Takashi Iwai @ 2018-03-13 8:10 ` Marcel Holtmann 2018-03-13 8:32 ` Takashi Iwai 0 siblings, 1 reply; 11+ messages in thread From: Marcel Holtmann @ 2018-03-13 8:10 UTC (permalink / raw) To: Takashi Iwai; +Cc: Johan Hedberg, Linux Bluetooth mailing list, linux-kernel Hi Takashi, >>>> we've got a but report about the broken Atheros BT on the recent >>>> kernels: >>>> http://bugzilla.opensuse.org/show_bug.cgi?id=1082504 >>>> >>>> In short, btusb can't load the patch ar3k/AthrBT_0x00000200.dfu, and >>>> this could be worked around by the patch to move 0cf3:3004 blacklist >>>> entry to use BTUSB_QCA_ROM instead of BTUSB_ATH3012. >>>> >>>> And this looks like a long-standing problem, at least for over two >>>> years. Many web pages suggest the same patch, but it's never merged >>>> to upstream. >>>> >>>> So this made me wonder what's going on. I see that the BTUSB_ATH3012 >>>> quirk was originally introduced just for this chip id (0cf3:3004). >>>> Is it a different variant from the original chip that causes a >>>> problem? >>> >>> not all patches from distro kernel are sent upstream. I have not heard of this specific issues, but happy to accept patches to get it fixed. >> >> OK, basically it's like below. >> But, as mentioned, this made me wonder whether it's the right fix. >> The BTUSB_ATH3012 quirk was introduced exactly for this chip ID >> (0cf3:3004), and now this chip is moved to another quirk... >> >> If this is the right move, I can re-submit via git-send-email, too. >> Just let me know. > > Marcel, could you take a look at this? > If it sucks, let's seek for a better solution. wasn’t the confusion that this is fixed with a recent kernel? I am lost in this thread. I mean if people add Tested-by, then I can take this as well. Otherwise we might need someone from Qualcomm to shed some light into these. Regards Marcel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Atheros 1525/QCA6174 BT issue 2018-03-13 8:10 ` Marcel Holtmann @ 2018-03-13 8:32 ` Takashi Iwai 2018-03-13 8:38 ` Marcel Holtmann 0 siblings, 1 reply; 11+ messages in thread From: Takashi Iwai @ 2018-03-13 8:32 UTC (permalink / raw) To: Marcel Holtmann Cc: Johan Hedberg, Linux Bluetooth mailing list, linux-kernel, Ivan Levshin On Tue, 13 Mar 2018 09:10:41 +0100, Marcel Holtmann wrote: > > Hi Takashi, > > >>>> we've got a but report about the broken Atheros BT on the recent > >>>> kernels: > >>>> http://bugzilla.opensuse.org/show_bug.cgi?id=1082504 > >>>> > >>>> In short, btusb can't load the patch ar3k/AthrBT_0x00000200.dfu, and > >>>> this could be worked around by the patch to move 0cf3:3004 blacklist > >>>> entry to use BTUSB_QCA_ROM instead of BTUSB_ATH3012. > >>>> > >>>> And this looks like a long-standing problem, at least for over two > >>>> years. Many web pages suggest the same patch, but it's never merged > >>>> to upstream. > >>>> > >>>> So this made me wonder what's going on. I see that the BTUSB_ATH3012 > >>>> quirk was originally introduced just for this chip id (0cf3:3004). > >>>> Is it a different variant from the original chip that causes a > >>>> problem? > >>> > >>> not all patches from distro kernel are sent upstream. I have not heard of this specific issues, but happy to accept patches to get it fixed. > >> > >> OK, basically it's like below. > >> But, as mentioned, this made me wonder whether it's the right fix. > >> The BTUSB_ATH3012 quirk was introduced exactly for this chip ID > >> (0cf3:3004), and now this chip is moved to another quirk... > >> > >> If this is the right move, I can re-submit via git-send-email, too. > >> Just let me know. > > > > Marcel, could you take a look at this? > > If it sucks, let's seek for a better solution. > > wasn’t the confusion that this is fixed with a recent kernel? I am lost in this thread. I mean if people add Tested-by, then I can take this as well. Otherwise we might need someone from Qualcomm to shed some light into these. Well, *this* thread is likely different from the recent other threads. Isn't 4.15.7 recent enough? At least, it already contains the backport of relevant fixes: Revert "Bluetooth: btusb: fix QCA Rome suspend/resume" Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version (And it's not Yoga but MSI GS40 laptop, so DMI doesn't matter.) According to Ivan, the reporter of the bug (now Cc'ed), 4.15.7 didn't work without the patch, so the problem is still there, as it seems. In anyway, I'm going to build a kernel with my patch on top of 4.15.9 for testing again. Maybe also a patched 4.16-rc5 kernel, too. If it's confirmed, will report back with tested-by tag. thanks, Takashi ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Atheros 1525/QCA6174 BT issue 2018-03-13 8:32 ` Takashi Iwai @ 2018-03-13 8:38 ` Marcel Holtmann 2018-03-13 8:50 ` Takashi Iwai 0 siblings, 1 reply; 11+ messages in thread From: Marcel Holtmann @ 2018-03-13 8:38 UTC (permalink / raw) To: Takashi Iwai Cc: Johan Hedberg, Linux Bluetooth mailing list, linux-kernel, Ivan Levshin Hi Takashi, >>>>>> we've got a but report about the broken Atheros BT on the recent >>>>>> kernels: >>>>>> http://bugzilla.opensuse.org/show_bug.cgi?id=1082504 >>>>>> >>>>>> In short, btusb can't load the patch ar3k/AthrBT_0x00000200.dfu, and >>>>>> this could be worked around by the patch to move 0cf3:3004 blacklist >>>>>> entry to use BTUSB_QCA_ROM instead of BTUSB_ATH3012. >>>>>> >>>>>> And this looks like a long-standing problem, at least for over two >>>>>> years. Many web pages suggest the same patch, but it's never merged >>>>>> to upstream. >>>>>> >>>>>> So this made me wonder what's going on. I see that the BTUSB_ATH3012 >>>>>> quirk was originally introduced just for this chip id (0cf3:3004). >>>>>> Is it a different variant from the original chip that causes a >>>>>> problem? >>>>> >>>>> not all patches from distro kernel are sent upstream. I have not heard of this specific issues, but happy to accept patches to get it fixed. >>>> >>>> OK, basically it's like below. >>>> But, as mentioned, this made me wonder whether it's the right fix. >>>> The BTUSB_ATH3012 quirk was introduced exactly for this chip ID >>>> (0cf3:3004), and now this chip is moved to another quirk... >>>> >>>> If this is the right move, I can re-submit via git-send-email, too. >>>> Just let me know. >>> >>> Marcel, could you take a look at this? >>> If it sucks, let's seek for a better solution. >> >> wasn’t the confusion that this is fixed with a recent kernel? I am lost in this thread. I mean if people add Tested-by, then I can take this as well. Otherwise we might need someone from Qualcomm to shed some light into these. > > Well, *this* thread is likely different from the recent other > threads. > > Isn't 4.15.7 recent enough? At least, it already contains the > backport of relevant fixes: > Revert "Bluetooth: btusb: fix QCA Rome suspend/resume" > Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a > "rewritten" version > > (And it's not Yoga but MSI GS40 laptop, so DMI doesn't matter.) > According to Ivan, the reporter of the bug (now Cc'ed), 4.15.7 didn't > work without the patch, so the problem is still there, as it seems. > > In anyway, I'm going to build a kernel with my patch on top of 4.15.9 > for testing again. Maybe also a patched 4.16-rc5 kernel, too. If > it's confirmed, will report back with tested-by tag. I think there are two patches that are not yet in Linus’ tree and waiting in Dave’s net tree. We actually removed the Yoga DMI entry again since it was found that it is not needed. However there is a Dell OptiPlex entry that was needed. https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=0c6e526646c04ce31d4aaa280ed2237dd1cd774c Regards Marcel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Atheros 1525/QCA6174 BT issue 2018-03-13 8:38 ` Marcel Holtmann @ 2018-03-13 8:50 ` Takashi Iwai 2018-03-13 9:15 ` Marcel Holtmann 0 siblings, 1 reply; 11+ messages in thread From: Takashi Iwai @ 2018-03-13 8:50 UTC (permalink / raw) To: Marcel Holtmann Cc: Johan Hedberg, Linux Bluetooth mailing list, linux-kernel, Ivan Levshin On Tue, 13 Mar 2018 09:38:30 +0100, Marcel Holtmann wrote: > > Hi Takashi, > > >>>>>> we've got a but report about the broken Atheros BT on the recent > >>>>>> kernels: > >>>>>> http://bugzilla.opensuse.org/show_bug.cgi?id=1082504 > >>>>>> > >>>>>> In short, btusb can't load the patch ar3k/AthrBT_0x00000200.dfu, and > >>>>>> this could be worked around by the patch to move 0cf3:3004 blacklist > >>>>>> entry to use BTUSB_QCA_ROM instead of BTUSB_ATH3012. > >>>>>> > >>>>>> And this looks like a long-standing problem, at least for over two > >>>>>> years. Many web pages suggest the same patch, but it's never merged > >>>>>> to upstream. > >>>>>> > >>>>>> So this made me wonder what's going on. I see that the BTUSB_ATH3012 > >>>>>> quirk was originally introduced just for this chip id (0cf3:3004). > >>>>>> Is it a different variant from the original chip that causes a > >>>>>> problem? > >>>>> > >>>>> not all patches from distro kernel are sent upstream. I have not heard of this specific issues, but happy to accept patches to get it fixed. > >>>> > >>>> OK, basically it's like below. > >>>> But, as mentioned, this made me wonder whether it's the right fix. > >>>> The BTUSB_ATH3012 quirk was introduced exactly for this chip ID > >>>> (0cf3:3004), and now this chip is moved to another quirk... > >>>> > >>>> If this is the right move, I can re-submit via git-send-email, too. > >>>> Just let me know. > >>> > >>> Marcel, could you take a look at this? > >>> If it sucks, let's seek for a better solution. > >> > >> wasn’t the confusion that this is fixed with a recent kernel? I am lost in this thread. I mean if people add Tested-by, then I can take this as well. Otherwise we might need someone from Qualcomm to shed some light into these. > > > > Well, *this* thread is likely different from the recent other > > threads. > > > > Isn't 4.15.7 recent enough? At least, it already contains the > > backport of relevant fixes: > > Revert "Bluetooth: btusb: fix QCA Rome suspend/resume" > > Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a > > "rewritten" version > > > > (And it's not Yoga but MSI GS40 laptop, so DMI doesn't matter.) > > According to Ivan, the reporter of the bug (now Cc'ed), 4.15.7 didn't > > work without the patch, so the problem is still there, as it seems. > > > > In anyway, I'm going to build a kernel with my patch on top of 4.15.9 > > for testing again. Maybe also a patched 4.16-rc5 kernel, too. If > > it's confirmed, will report back with tested-by tag. > > I think there are two patches that are not yet in Linus’ tree and waiting in Dave’s net tree. We actually removed the Yoga DMI entry again since it was found that it is not needed. However there is a Dell OptiPlex entry that was needed. > > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=0c6e526646c04ce31d4aaa280ed2237dd1cd774c In our case, the target machine is a MSI laptop, so these changes should be irrelevant. Or do you suggest to try the same DMI reset quirk matching with the MSI machine? thanks, Takashi ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Atheros 1525/QCA6174 BT issue 2018-03-13 8:50 ` Takashi Iwai @ 2018-03-13 9:15 ` Marcel Holtmann 2018-03-15 15:56 ` Takashi Iwai 0 siblings, 1 reply; 11+ messages in thread From: Marcel Holtmann @ 2018-03-13 9:15 UTC (permalink / raw) To: Takashi Iwai Cc: Johan Hedberg, Linux Bluetooth mailing list, LKML, Ivan Levshin Hi Takashi, >>>>>>>> we've got a but report about the broken Atheros BT on the recent >>>>>>>> kernels: >>>>>>>> http://bugzilla.opensuse.org/show_bug.cgi?id=1082504 >>>>>>>> >>>>>>>> In short, btusb can't load the patch ar3k/AthrBT_0x00000200.dfu, and >>>>>>>> this could be worked around by the patch to move 0cf3:3004 blacklist >>>>>>>> entry to use BTUSB_QCA_ROM instead of BTUSB_ATH3012. >>>>>>>> >>>>>>>> And this looks like a long-standing problem, at least for over two >>>>>>>> years. Many web pages suggest the same patch, but it's never merged >>>>>>>> to upstream. >>>>>>>> >>>>>>>> So this made me wonder what's going on. I see that the BTUSB_ATH3012 >>>>>>>> quirk was originally introduced just for this chip id (0cf3:3004). >>>>>>>> Is it a different variant from the original chip that causes a >>>>>>>> problem? >>>>>>> >>>>>>> not all patches from distro kernel are sent upstream. I have not heard of this specific issues, but happy to accept patches to get it fixed. >>>>>> >>>>>> OK, basically it's like below. >>>>>> But, as mentioned, this made me wonder whether it's the right fix. >>>>>> The BTUSB_ATH3012 quirk was introduced exactly for this chip ID >>>>>> (0cf3:3004), and now this chip is moved to another quirk... >>>>>> >>>>>> If this is the right move, I can re-submit via git-send-email, too. >>>>>> Just let me know. >>>>> >>>>> Marcel, could you take a look at this? >>>>> If it sucks, let's seek for a better solution. >>>> >>>> wasn’t the confusion that this is fixed with a recent kernel? I am lost in this thread. I mean if people add Tested-by, then I can take this as well. Otherwise we might need someone from Qualcomm to shed some light into these. >>> >>> Well, *this* thread is likely different from the recent other >>> threads. >>> >>> Isn't 4.15.7 recent enough? At least, it already contains the >>> backport of relevant fixes: >>> Revert "Bluetooth: btusb: fix QCA Rome suspend/resume" >>> Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a >>> "rewritten" version >>> >>> (And it's not Yoga but MSI GS40 laptop, so DMI doesn't matter.) >>> According to Ivan, the reporter of the bug (now Cc'ed), 4.15.7 didn't >>> work without the patch, so the problem is still there, as it seems. >>> >>> In anyway, I'm going to build a kernel with my patch on top of 4.15.9 >>> for testing again. Maybe also a patched 4.16-rc5 kernel, too. If >>> it's confirmed, will report back with tested-by tag. >> >> I think there are two patches that are not yet in Linus’ tree and waiting in Dave’s net tree. We actually removed the Yoga DMI entry again since it was found that it is not needed. However there is a Dell OptiPlex entry that was needed. >> >> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=0c6e526646c04ce31d4aaa280ed2237dd1cd774c > > In our case, the target machine is a MSI laptop, so these changes > should be irrelevant. Or do you suggest to try the same DMI reset > quirk matching with the MSI machine? that is maybe needed. I honestly do not know. Someone needs to root cause this. And obviously bi-secting a root-cause git commit would be helpful as well. Regards Marcel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Atheros 1525/QCA6174 BT issue 2018-03-13 9:15 ` Marcel Holtmann @ 2018-03-15 15:56 ` Takashi Iwai 2018-03-15 18:32 ` Marcel Holtmann 0 siblings, 1 reply; 11+ messages in thread From: Takashi Iwai @ 2018-03-15 15:56 UTC (permalink / raw) To: Marcel Holtmann Cc: Johan Hedberg, Linux Bluetooth mailing list, LKML, Ivan Levshin On Tue, 13 Mar 2018 10:15:26 +0100, Marcel Holtmann wrote: > > Hi Takashi, > > >>>>>>>> we've got a but report about the broken Atheros BT on the recent > >>>>>>>> kernels: > >>>>>>>> http://bugzilla.opensuse.org/show_bug.cgi?id=1082504 > >>>>>>>> > >>>>>>>> In short, btusb can't load the patch ar3k/AthrBT_0x00000200.dfu, and > >>>>>>>> this could be worked around by the patch to move 0cf3:3004 blacklist > >>>>>>>> entry to use BTUSB_QCA_ROM instead of BTUSB_ATH3012. > >>>>>>>> > >>>>>>>> And this looks like a long-standing problem, at least for over two > >>>>>>>> years. Many web pages suggest the same patch, but it's never merged > >>>>>>>> to upstream. > >>>>>>>> > >>>>>>>> So this made me wonder what's going on. I see that the BTUSB_ATH3012 > >>>>>>>> quirk was originally introduced just for this chip id (0cf3:3004). > >>>>>>>> Is it a different variant from the original chip that causes a > >>>>>>>> problem? > >>>>>>> > >>>>>>> not all patches from distro kernel are sent upstream. I have not heard of this specific issues, but happy to accept patches to get it fixed. > >>>>>> > >>>>>> OK, basically it's like below. > >>>>>> But, as mentioned, this made me wonder whether it's the right fix. > >>>>>> The BTUSB_ATH3012 quirk was introduced exactly for this chip ID > >>>>>> (0cf3:3004), and now this chip is moved to another quirk... > >>>>>> > >>>>>> If this is the right move, I can re-submit via git-send-email, too. > >>>>>> Just let me know. > >>>>> > >>>>> Marcel, could you take a look at this? > >>>>> If it sucks, let's seek for a better solution. > >>>> > >>>> wasn’t the confusion that this is fixed with a recent kernel? I am lost in this thread. I mean if people add Tested-by, then I can take this as well. Otherwise we might need someone from Qualcomm to shed some light into these. > >>> > >>> Well, *this* thread is likely different from the recent other > >>> threads. > >>> > >>> Isn't 4.15.7 recent enough? At least, it already contains the > >>> backport of relevant fixes: > >>> Revert "Bluetooth: btusb: fix QCA Rome suspend/resume" > >>> Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a > >>> "rewritten" version > >>> > >>> (And it's not Yoga but MSI GS40 laptop, so DMI doesn't matter.) > >>> According to Ivan, the reporter of the bug (now Cc'ed), 4.15.7 didn't > >>> work without the patch, so the problem is still there, as it seems. > >>> > >>> In anyway, I'm going to build a kernel with my patch on top of 4.15.9 > >>> for testing again. Maybe also a patched 4.16-rc5 kernel, too. If > >>> it's confirmed, will report back with tested-by tag. > >> > >> I think there are two patches that are not yet in Linus’ tree and waiting in Dave’s net tree. We actually removed the Yoga DMI entry again since it was found that it is not needed. However there is a Dell OptiPlex entry that was needed. > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=0c6e526646c04ce31d4aaa280ed2237dd1cd774c > > > > In our case, the target machine is a MSI laptop, so these changes > > should be irrelevant. Or do you suggest to try the same DMI reset > > quirk matching with the MSI machine? > > that is maybe needed. OK, now the results: 4.15.9 vanilla -> BAD 4.16-rc5 vanilla -> BAD 4.16-rc5 with DMI quirk -> BAD So, btusb_needs_reset_resume_table[] doesn't help in our case. And the patch was confirmed to work on both 4.15.9 and 4.16-rc5. I'll resubmit the patch. thanks, Takashi ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Atheros 1525/QCA6174 BT issue 2018-03-15 15:56 ` Takashi Iwai @ 2018-03-15 18:32 ` Marcel Holtmann 0 siblings, 0 replies; 11+ messages in thread From: Marcel Holtmann @ 2018-03-15 18:32 UTC (permalink / raw) To: Takashi Iwai Cc: Johan Hedberg, Linux Bluetooth mailing list, LKML, Ivan Levshin Hi Takashi, >>>>>>>>>> we've got a but report about the broken Atheros BT on the recent >>>>>>>>>> kernels: >>>>>>>>>> http://bugzilla.opensuse.org/show_bug.cgi?id=1082504 >>>>>>>>>> >>>>>>>>>> In short, btusb can't load the patch ar3k/AthrBT_0x00000200.dfu, and >>>>>>>>>> this could be worked around by the patch to move 0cf3:3004 blacklist >>>>>>>>>> entry to use BTUSB_QCA_ROM instead of BTUSB_ATH3012. >>>>>>>>>> >>>>>>>>>> And this looks like a long-standing problem, at least for over two >>>>>>>>>> years. Many web pages suggest the same patch, but it's never merged >>>>>>>>>> to upstream. >>>>>>>>>> >>>>>>>>>> So this made me wonder what's going on. I see that the BTUSB_ATH3012 >>>>>>>>>> quirk was originally introduced just for this chip id (0cf3:3004). >>>>>>>>>> Is it a different variant from the original chip that causes a >>>>>>>>>> problem? >>>>>>>>> >>>>>>>>> not all patches from distro kernel are sent upstream. I have not heard of this specific issues, but happy to accept patches to get it fixed. >>>>>>>> >>>>>>>> OK, basically it's like below. >>>>>>>> But, as mentioned, this made me wonder whether it's the right fix. >>>>>>>> The BTUSB_ATH3012 quirk was introduced exactly for this chip ID >>>>>>>> (0cf3:3004), and now this chip is moved to another quirk... >>>>>>>> >>>>>>>> If this is the right move, I can re-submit via git-send-email, too. >>>>>>>> Just let me know. >>>>>>> >>>>>>> Marcel, could you take a look at this? >>>>>>> If it sucks, let's seek for a better solution. >>>>>> >>>>>> wasn’t the confusion that this is fixed with a recent kernel? I am lost in this thread. I mean if people add Tested-by, then I can take this as well. Otherwise we might need someone from Qualcomm to shed some light into these. >>>>> >>>>> Well, *this* thread is likely different from the recent other >>>>> threads. >>>>> >>>>> Isn't 4.15.7 recent enough? At least, it already contains the >>>>> backport of relevant fixes: >>>>> Revert "Bluetooth: btusb: fix QCA Rome suspend/resume" >>>>> Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a >>>>> "rewritten" version >>>>> >>>>> (And it's not Yoga but MSI GS40 laptop, so DMI doesn't matter.) >>>>> According to Ivan, the reporter of the bug (now Cc'ed), 4.15.7 didn't >>>>> work without the patch, so the problem is still there, as it seems. >>>>> >>>>> In anyway, I'm going to build a kernel with my patch on top of 4.15.9 >>>>> for testing again. Maybe also a patched 4.16-rc5 kernel, too. If >>>>> it's confirmed, will report back with tested-by tag. >>>> >>>> I think there are two patches that are not yet in Linus’ tree and waiting in Dave’s net tree. We actually removed the Yoga DMI entry again since it was found that it is not needed. However there is a Dell OptiPlex entry that was needed. >>>> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=0c6e526646c04ce31d4aaa280ed2237dd1cd774c >>> >>> In our case, the target machine is a MSI laptop, so these changes >>> should be irrelevant. Or do you suggest to try the same DMI reset >>> quirk matching with the MSI machine? >> >> that is maybe needed. > > OK, now the results: > > 4.15.9 vanilla -> BAD > 4.16-rc5 vanilla -> BAD > 4.16-rc5 with DMI quirk -> BAD > > So, btusb_needs_reset_resume_table[] doesn't help in our case. > > And the patch was confirmed to work on both 4.15.9 and 4.16-rc5. > > I'll resubmit the patch. thanks for verifying. Lets run with your patch. Regards Marcel ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2018-03-15 18:32 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-03-08 8:27 Atheros 1525/QCA6174 BT issue Takashi Iwai 2018-03-08 9:06 ` Marcel Holtmann 2018-03-08 9:16 ` Takashi Iwai 2018-03-13 8:05 ` Takashi Iwai 2018-03-13 8:10 ` Marcel Holtmann 2018-03-13 8:32 ` Takashi Iwai 2018-03-13 8:38 ` Marcel Holtmann 2018-03-13 8:50 ` Takashi Iwai 2018-03-13 9:15 ` Marcel Holtmann 2018-03-15 15:56 ` Takashi Iwai 2018-03-15 18:32 ` Marcel Holtmann
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).