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
