QCA6164 txbf failure

QCA6164 txbf failure

[Andrew C. Dingman]

It looks like the QCA6164 in my Lenovo Yoga 3 11" has problems with
txbf. I'm using Fedora with a 4.3.0-rc3 kernel from Koji. (A
development build system - it's not a released kernel)

Using firmware from https://github.com/kvalo/ath10k-firmware.git except
for the board.bin, which came https://github.com/atondwal/ath10k-firmwa
re.git. Specifically, to get the card to boot I ran "sudo cp
ath10k/QCA6164/hw2.1/board.bin
/lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:0041:17aa:3545.bin"
from the latter git repo.

Using the unmodified 4.3 kernel above, this allowed the card to be
recognized, and even report successful authentication and association
to an access point in dmesg. However, it never completed a connection,
and scanning access points failed.

Based on the dmesg output, michalk in IRC suggested that I try applying
the patch from http://lists.infradead.org/pipermail/ath10k/2015-August/
005909.html. With that change, the device seems to work fine.

-Andrew

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: QCA6164 txbf failure

[Andrew C. Dingman]

On Mon, 2015-10-05 at 10:38 -0400, Andrew C. Dingman wrote:
> It looks like the QCA6164 in my Lenovo Yoga 3 11" has problems with
> txbf. I'm using Fedora with a 4.3.0-rc3 kernel from Koji. (A
> development build system - it's not a released kernel)
> 
> Using firmware from https://github.com/kvalo/ath10k-firmware.git exce
> pt
> for the board.bin, which came https://github.com/atondwal/ath10k-firm
> wa
> re.git. Specifically, to get the card to boot I ran "sudo cp
> ath10k/QCA6164/hw2.1/board.bin
> /lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:0041:17aa:3545.bin"
> from the latter git repo.
> 
> Using the unmodified 4.3 kernel above, this allowed the card to be
> recognized, and even report successful authentication and association
> to an access point in dmesg. However, it never completed a
> connection,
> and scanning access points failed.
> 
> Based on the dmesg output, michalk in IRC suggested that I try
> applying
> the patch from http://lists.infradead.org/pipermail/ath10k/2015-Augus
> t/
> 005909.html. With that change, the device seems to work fine.

Adding for completeness:

The device in question, as shown by lspci
    [    andrew@amphitrite     ~]$ sudo lspci -v -n -s 2:0
    02:00.0 0280: 168c:0041 (rev 20)
    	    Subsystem: 17aa:3545
    	    Flags: bus master, fast devsel, latency 0, IRQ 50
    	    Memory at c1000000 (64-bit, non-prefetchable) [size=2M]
    	    Capabilities: [40] Power Management version 3
    	    Capabilities: [50] MSI: Enable+ Count=8/8 Maskable+ 64bit-
    	    Capabilities: [70] Express Endpoint, MSI 00
    	    Capabilities: [100] Advanced Error Reporting
    	    Capabilities: [148] Virtual Channel
    	    Capabilities: [168] Device Serial Number 00-00-00-00-00-00-00-
    00
    	    Capabilities: [178] Latency Tolerance Reporting
    	    Capabilities: [180] L1 PM Substates
    	    Kernel driver in use: ath10k_pci
    	    Kernel modules: ath10k_pci

Also, michalk points out that the log contained "failed to poke peer
XXX param for ps workaround on vdev Y: -11"

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k