linux-kernel - Re: Atheros 1525/QCA6174 BT issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <2D7B44D5-BF8C-42EE-A315-64DE11D25C79@holtmann.org>
Date:   Tue, 13 Mar 2018 09:10:41 +0100
From:   Marcel Holtmann <marcel@...tmann.org>
To:     Takashi Iwai <tiwai@...e.de>
Cc:     Johan Hedberg <johan.hedberg@...il.com>,
        Linux Bluetooth mailing list 
        <linux-bluetooth@...r.kernel.org>, linux-kernel@...r.kernel.org
Subject: Re: Atheros 1525/QCA6174 BT issue

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