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
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
(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.