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.



Reply via email to