Re: ath10k wake_tx_queue issues
On Wed, May 16, 2018 at 07:54:54AM +0200, Alexander Wetzel wrote: > Hello, > > This sounds exactly like the issue I just submitted a patch for. > Can you test https://patchwork.kernel.org/patch/10399613/ if that solves > the issue? Hello Alexander, I just tried you fix, and unfortunately it doesn't solve my problem. Regards, Niklas > > > > Am 15.05.2018 um 22:31 schrieb Niklas Cassel: > > On Tue, May 15, 2018 at 04:13:48PM +0200, Toke Høiland-Jørgensen wrote: > >> [ Adding Felix ] > >> > >> > >> Niklas Cassel writes: > >> > >>> Hello mac80211 and ath10k people > >>> > >>> Using ath10k, TX stops working when running iperf > >>> > >>> [ 3] 0.0- 1.0 sec 2.00 MBytes 16.8 Mbits/sec > >>> [ 3] 1.0- 2.0 sec 3.12 MBytes 26.2 Mbits/sec > >>> [ 3] 2.0- 3.0 sec 3.25 MBytes 27.3 Mbits/sec > >>> [ 3] 3.0- 4.0 sec 655 KBytes 5.36 Mbits/sec > >>> [ 3] 4.0- 5.0 sec 0.00 Bytes 0.00 bits/sec > >>> [ 3] 5.0- 6.0 sec 0.00 Bytes 0.00 bits/sec > >>> [ 3] 6.0- 7.0 sec 0.00 Bytes 0.00 bits/sec > >>> [ 3] 7.0- 8.0 sec 0.00 Bytes 0.00 bits/sec > >>> [ 3] 8.0- 9.0 sec 0.00 Bytes 0.00 bits/sec > >>> [ 3] 9.0-10.0 sec 0.00 Bytes 0.00 bits/sec > >>> [ 3] 0.0-10.3 sec 9.01 MBytes 7.32 Mbits/sec > >>> > >>> The problem can be reproduced without specifying a send buffer size, > >>> however, specifying a small send buffer helps to reproduce the problem > >>> faster. > >>> > >>> What happens is that iperf gets -EAGAIN on write(). > >>> It continues to get -EAGAIN, even if iperf runs for e.g. 300 seconds. > >>> The reason why we get -EAGAIN is because the send socket buffer is full > >>> (iperf uses non-blocking I/O). > >>> > >>> The problem is that the mac80211 wake_tx_queue callback never comes. > >>> > >>> I guess the best way to describe this is to show my ftrace buffer: > >>> > >>> ksoftirqd/2-21[002] .ns474.711744: > >>> ath10k_htt_tx_dec_pending: num_pen: 60 > >>> ksoftirqd/2-21[002] .ns374.711761: > >>> ath10k_mac_op_wake_tx_queue: txq: frame_cnt: 1 byte_cnt: 1534 f_txq: > >>> frame_cnt: 1 byte_cnt: 1534 num_pen: 60 queue: 0 > >>> ksoftirqd/2-21[002] .ns474.711765: > >>> ath10k_htt_tx_inc_pending: num_pen: 61 > >>> ksoftirqd/2-21[002] .ns474.711781: > >>> ath10k_htt_tx_inc_pending: num_pen: 62 > >>> ksoftirqd/2-21[002] .ns474.711787: > >>> ath10k_htt_tx_dec_pending: num_pen: 61 > >>> ksoftirqd/2-21[002] .ns374.711803: > >>> ath10k_mac_op_wake_tx_queue: txq: frame_cnt: 1 byte_cnt: 1534 f_txq: > >>> frame_cnt: 1 byte_cnt: 1534 num_pen: 61 queue: 0 > >>> ksoftirqd/2-21[002] .ns474.711807: > >>> ath10k_htt_tx_inc_pending: num_pen: 62 > >>> ksoftirqd/2-21[002] .ns474.711823: > >>> ath10k_htt_tx_inc_pending: num_pen: 63 > >>> ksoftirqd/2-21[002] .ns474.711829: > >>> ath10k_htt_tx_dec_pending: num_pen: 62 > >>> ksoftirqd/2-21[002] .ns374.711845: > >>> ath10k_mac_op_wake_tx_queue: txq: frame_cnt: 1 byte_cnt: 1534 f_txq: > >>> frame_cnt: 1 byte_cnt: 1534 num_pen: 62 queue: 0 > >>> ksoftirqd/2-21[002] .ns474.711849: > >>> ath10k_htt_tx_inc_pending: num_pen: 63 > >>> ksoftirqd/2-21[002] .ns474.711865: > >>> ath10k_htt_tx_inc_pending: num_pen: 64 > >>> ksoftirqd/2-21[002] dns574.711870: stop_queue: phy0 queue:0, > >>> reason:0 > >>> ksoftirqd/2-21[002] dns574.711874: stop_queue: phy0 queue:1, > >>> reason:0 > >>> ksoftirqd/2-21[002] dns574.711877: stop_queue: phy0 queue:2, > >>> reason:0 > >>> ksoftirqd/2-21[002] dns574.711880: stop_queue: phy0 queue:3, > >>> reason:0 > >>> ksoftirqd/2-21[002] dns574.711882: stop_queue: phy0 queue:4, > >>> reason:0 > >>> ksoftirqd/2-21[002] dns574.711885: stop_queue: phy0 queue:5, > >>> reason:0 > >>> ksoftirqd/2-21[002] dns574.711887: stop_queue: phy0 queue:6, > >>> reason:0 > >>> ksoftirqd/2-21[002] dns574.711890: stop_queue: phy0 queue:7, > >>> reason:0 > >>> ksoftirqd/2-21[002] dns574.711892: stop_queue: phy0 queue:8, > >>> reason:0 > >>> ksoftirqd/2-21[002] dns574.711895: stop_queue: phy0 queue:9, > >>> reason:0 > >>> ksoftirqd/2-21[002] dns574.711898: stop_queue: phy0 > >>> queue:10, reason:0 > >>> ksoftirqd/2-21[002] dns574.711900: stop_queue: phy0 > >>> queue:11, reason:0 > >>> ksoftirqd/2-21[002] dns574.711903: stop_queue: phy0 > >>> queue:12, reason:0 > >>> ksoftirqd/2-21[002] dns574.711905: stop_queue: phy0 > >>> queue:13, reason:0 > >>> ksoftirqd/2-21[002] dns574.711908: stop_queue: phy0 > >>> queue:14, reason:0 > >>> ksoftirqd/2-21[002] dns574.711910: stop_queue: phy0 > >>> queue:15, reason:0 > >>> ksoftirqd/2-21[002] .ns474.711917: > >>> ath10k_htt_tx_dec_pending: num_pen: 63 > >>> ksoftirqd/2-21[002] dns574.711922: wake_queue:
Re: ath10k wake_tx_queue issues
Niklas Cassel writes: > [ .. snip .. ] >> > Sure, the regular way ath10k_mac_op_wake_tx_queue is called is via >> > ieee80211_subif_start_xmit => __ieee80211_subif_start_xmit => >> > ieee80211_xmit_fast >> > => ieee80211_queue_skb => drv_wake_tx_queue. >> > >> > But I was expecting the call to ieee80211_wake_queue to somehow trigger a >> > call >> > to ath10k_mac_op_wake_tx_queue, since there is still data in the send >> > buffer/ >> > in the ieee80211_txq that needs to be sent, to allow more data to be >> > written to >> > the socket. But obviously the callback never comes. >> > Or how else is this supposed to work? >> >> The driver should reschedule itself before/after calling >> ieee80211_wake_queue. mt76 does this; I'm not actually sure if ath9k >> does the right thing either, I'm not too familiar with that part of the >> code. There's no direct call to reschedule that I can see, but there may >> be another reason why this is not needed for ath9k. I'm sure Felix >> knows? > > Hello Toke > > Unfortunately, it doesn't look like mt76 uses any ieee80211_* function > to reschedule. It doesn't need to; it just reschedules itself. Basically, the wake_tx_queue() callback is just a way for mac80211 to notify the driver that new packets are available and that it should start its scheduling function. But in this case it is the driver that is restarting the queues, so it already knows that. And so it can just call its internal scheduling function. This is what mt76 does in mt76_dma_tx_cleanup() with the call to mt76_txq_schedule() before calling ieee80211_wake_queue(). I think that what ath10k should be doing is calling ath10k_mac_tx_push_pending() when it restarts the queues. > I just came across a ieee80211_schedule_txq() function in e937b8da5a59 > ("mac80211: Add TXQ scheduling API"). However, this commit was > reverted. Any plans on resubmitting this? Yeah, I have a revised version lying around waiting for Felix to review it. But that wouldn't help this bug; it's just an API change, it doesn't change behaviour... -Toke ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 2/2] ath10k: DFS Host Confirmation
Peter Oh writes: >> Sure, every software change can cause regressions. But the thing is that >> this isn't an optional, ath10k has to have this to be able to continue >> using DFS channels. > > Kalle, you said you don't know which exact FCC requirement this is for > in another email thread. Then how come you're sure this is not an > optional To me this is a mandatory ath10k feature because if the host driver does not have this DFS channels won't work anymore. > and this approach is right one? That's something you need to ask the firmware team who designed and implemented this. This discussion is going circles, it would be a lot easier if you could clearly say your point. But if your point is just "I don't like this" then there's not much, if any, I can do about that. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: Support for QCA9377
On 5/15/2018 9:56 PM, Kalle Valo wrote: Jay Foster writes: I too have been, off and on, looking for an ath10k driver solution for a SparkLAN WUBQ-159ACN USB Wi-Fi adapter, so I have been keeping an eye on this mailing list. I just tried the latest ath10k-pending-sdio-usb branch (ath10k-pending-sdio-usb-201804210910 tag), since I could see that support for the SparkLAN USB 0CF3:9378 device was just added. The driver refers to this as the SparkLAN WPEQ-160ACN device, but it has the same USB vendor/product ID as my WUBQ-159ACN. They both use the QCA9377 chip. I got a driver to build with the 4.9 kernel and when it boots, it recognizes my Wi-Fi adapter. Now, I am trying to sort out what to do about firmware. I downloaded the board-2.bin, board.bin, firmware-5.bin files from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath10k/QCA9377/hw1.0. I used the ath10k-fwencoder application from the qca-swiss-army-knife tools to also build a firmware file, but I am not clear on what files I should be using. SparkLAN provided, with the qcacld-2.0 wlan driver, the following files: athsetup.bin, athwlan.bin, cfg.dat, fakeboar.bin, otp.bin, and qcom_cfg.ini. I used the command: qca-swiss-army-knife/tools/scripts/ath10k/ath10k-fwencoder --create --otp ../../../otp.bin --firmware ../../../athwlan.bin --set-wmi-op-version=tlv --set-htt-op-version=tlv --set-fw-api=6 --features=ignore-otp-result to create my firmware-usb-6.bin and used the fakeboar.bin for my board-usb.bin files. However, when the driver loads, it is looking for a file called ath10k/cal-usb-1-1.2.bin. Where do I get that file? You can ignore that warning. cal-*.bin are optional files containing the calibration data, in case you don't have the calibration data in OTP. But my guess is that in your device you have the calibration data in OTP so you don't need cal-*.bin. Hopefully in 4.18 that warning will be away and users won't get confused anymore. I tried using the athsetup.bin file for this, but I do not think that works. The driver reports: /lib/firmware/ath10k/QCA9377/hw1.0# usb 1-1.2: qca9377 hw1.1 SparkLAN WPEQ-160ACN target 0x05020001 chip_id 0x sub : usb 1-1.2: kconfig debug 1 debugfs 0 tracing 0 dfs 0 testmode 1 usb 1-1.2: firmware ver api 6 features ignore-otp crc32 e8985f67 usb 1-1.2: found invalid board magic usb 1-1.2: board_file api 1 bmi_id N/A crc32 58a139e9 usb 1-1.2: invalid hw_params.n_cipher_suites 0 What does invalid board magic mean? This log means that ath10k first tried to load board-2.bin but it was corrupted for some reason. Then it found and used board.bin instead. It seems odd that the board-2.bin file I downloaded from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath10k/QCA9377/hw1.0 is somehow corrupted. Does the message mean that the board-2.bin file itself is bad or that it is not appropriate/useful for my particular Wi-Fi device? When you say that the driver then used board.bin instead, I think in my case this is board-usb.bin (the same as my fakeboar.bin file from SparkLAN), since my device is a USB device. I am just trying to be clear on my understanding. The Wi-Fi USB adapter may be installed in any number of different USB locations, so why is the USB location (1-1.2) part of one of the filenames? Because there needs to be some way to identify multiple devices on the same host. But cal-*.bin is mainly meant for AP devices where the devices have a fixed slot in the PCI bus and the calibration data is stored in host's filesystem (check openwrt to see how it's used). I did manage to get a successful Wi-Fi STA mode connection with this driver. One issue that I don't understand is when the driver attempts to load a FW file that is not present, it fails with error -2 and then reports, "Falling back to user helper". However, this 'user helper' does not exist/work either, but the driver waits quite a while waiting for it (about half a minute or so). This causes a delay loading the driver (about half a minute for each missing file). So, even though the cal files are optional, if they are not there, it significantly delays loading of the driver. I need to eliminate this delay. For now, I patched the driver to not attempt to load the pre-cal-usb-.bin or the cal-usb-.bin files (that do not exist for my adapter), but there must be a better way to avoid this delay. Thanks very much for your help. ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k wake_tx_queue issues
Hello Niklas Quick question: Are you using my patch: "ath10k: add htt_tx num_pending window"? I assume (from your logs below) that you are not... See more comments below. I guess the best way to describe this is to show my ftrace buffer: ksoftirqd/2-21[002] .ns474.711744: ath10k_htt_tx_dec_pending: num_pen: 60 ksoftirqd/2-21[002] .ns374.711761: ath10k_mac_op_wake_tx_queue: txq: frame_cnt: 1 byte_cnt: 1534 f_txq: frame_cnt: 1 byte_cnt: 1534 num_pen: 60 queue: 0 ksoftirqd/2-21[002] .ns474.711765: ath10k_htt_tx_inc_pending: num_pen: 61 ksoftirqd/2-21[002] .ns474.711781: ath10k_htt_tx_inc_pending: num_pen: 62 ksoftirqd/2-21[002] .ns474.711787: ath10k_htt_tx_dec_pending: num_pen: 61 ksoftirqd/2-21[002] .ns374.711803: ath10k_mac_op_wake_tx_queue: txq: frame_cnt: 1 byte_cnt: 1534 f_txq: frame_cnt: 1 byte_cnt: 1534 num_pen: 61 queue: 0 ksoftirqd/2-21[002] .ns474.711807: ath10k_htt_tx_inc_pending: num_pen: 62 ksoftirqd/2-21[002] .ns474.711823: ath10k_htt_tx_inc_pending: num_pen: 63 ksoftirqd/2-21[002] .ns474.711829: ath10k_htt_tx_dec_pending: num_pen: 62 ksoftirqd/2-21[002] .ns374.711845: ath10k_mac_op_wake_tx_queue: txq: frame_cnt: 1 byte_cnt: 1534 f_txq: frame_cnt: 1 byte_cnt: 1534 num_pen: 62 queue: 0 ksoftirqd/2-21[002] .ns474.711849: ath10k_htt_tx_inc_pending: num_pen: 63 ksoftirqd/2-21[002] .ns474.711865: ath10k_htt_tx_inc_pending: num_pen: 64 For high latency devices, when the num_pending counter reaches this point (64), ath10k calls ieee80211_stop_queues (from ath10k_htt_tx_inc_pending -> ath10k_mac_tx_lock). This will stop all per-TID queues (16 in total). ksoftirqd/2-21[002] dns574.711870: stop_queue: phy0 queue:0, reason:0 ksoftirqd/2-21[002] dns574.711874: stop_queue: phy0 queue:1, reason:0 ksoftirqd/2-21[002] dns574.711877: stop_queue: phy0 queue:2, reason:0 ksoftirqd/2-21[002] dns574.711880: stop_queue: phy0 queue:3, reason:0 ksoftirqd/2-21[002] dns574.711882: stop_queue: phy0 queue:4, reason:0 ksoftirqd/2-21[002] dns574.711885: stop_queue: phy0 queue:5, reason:0 ksoftirqd/2-21[002] dns574.711887: stop_queue: phy0 queue:6, reason:0 ksoftirqd/2-21[002] dns574.711890: stop_queue: phy0 queue:7, reason:0 ksoftirqd/2-21[002] dns574.711892: stop_queue: phy0 queue:8, reason:0 ksoftirqd/2-21[002] dns574.711895: stop_queue: phy0 queue:9, reason:0 ksoftirqd/2-21[002] dns574.711898: stop_queue: phy0 queue:10, reason:0 ksoftirqd/2-21[002] dns574.711900: stop_queue: phy0 queue:11, reason:0 ksoftirqd/2-21[002] dns574.711903: stop_queue: phy0 queue:12, reason:0 ksoftirqd/2-21[002] dns574.711905: stop_queue: phy0 queue:13, reason:0 ksoftirqd/2-21[002] dns574.711908: stop_queue: phy0 queue:14, reason:0 ksoftirqd/2-21[002] dns574.711910: stop_queue: phy0 queue:15, reason:0 ksoftirqd/2-21[002] .ns474.711917: ath10k_htt_tx_dec_pending: num_pen: 63 At this point, the driver have received a TX_COMPL_IND (since num_pending has been decremented to 63). Without the patch I mentioned above, the logic is that the TX queues will be re-enabled immediately. This is achieved by calling ieee80211_stop_queues. ksoftirqd/2-21[002] dns574.711922: wake_queue: phy0 queue:0, reason:0 ksoftirqd/2-21[002] dns574.711929: wake_queue: phy0 queue:15, reason:0 2 queues have been enabled here. I don't know why not all queues have been re-enabled. Perhaps it is due to that mac80211 immediately gets more data on one of the just re-enabled queues, resulting in... ksoftirqd/2-21[002] .ns374.711948: ath10k_mac_op_wake_tx_queue: txq: frame_cnt: 1 byte_cnt: 1534 f_txq: frame_cnt: 1 byte_cnt: 1534 num_pen: 63 queue: 0 ...the the wake_tx_queue op beeing invoked again ... ksoftirqd/2-21[002] .ns474.711952: ath10k_htt_tx_inc_pending: num_pen: 64 ... and the num_pending counter beeing incremented as a result of this. This results in all queues beeing ... ksoftirqd/2-21[002] dns574.711956: stop_queue: phy0 queue:0, reason:0 ksoftirqd/2-21[002] dns574.711959: stop_queue: phy0 queue:1, reason:0 ksoftirqd/2-21[002] dns574.711962: stop_queue: phy0 queue:2, reason:0 ksoftirqd/2-21[002] dns574.711964: stop_queue: phy0 queue:3, reason:0 ksoftirqd/2-21[002] dns574.711967: stop_queue: phy0 queue:4, reason:0 ksoftirqd/2-21[002] dns574.711969: stop_queue: phy0 queue:5, reason:0 ksoftirqd/2-21[002] dns574.711972: stop_queue: phy0 queue:6, reason:0 ksoftirqd/2-21[002] dns574.711974: stop_queue: phy0 queue:7, reason:0 ksoftirqd/2-21
Re: Support for QCA9377
+ linux-wireless Jay Foster writes: > On 5/15/2018 9:56 PM, Kalle Valo wrote: >> Jay Foster writes: >> >>> I too have been, off and on, looking for an ath10k driver solution for >>> a SparkLAN WUBQ-159ACN USB Wi-Fi adapter, so I have been keeping an >>> eye on this mailing list. I just tried the latest >>> ath10k-pending-sdio-usb branch (ath10k-pending-sdio-usb-201804210910 >>> tag), since I could see that support for the SparkLAN USB 0CF3:9378 >>> device was just added. The driver refers to this as the SparkLAN >>> WPEQ-160ACN device, but it has the same USB vendor/product ID as my >>> WUBQ-159ACN. They both use the QCA9377 chip. >>> >>> I got a driver to build with the 4.9 kernel and when it boots, it >>> recognizes my Wi-Fi adapter. Now, I am trying to sort out what to do >>> about firmware. I downloaded the board-2.bin, board.bin, >>> firmware-5.bin files from >>> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath10k/QCA9377/hw1.0. >>> I used the ath10k-fwencoder application from the qca-swiss-army-knife >>> tools to also build a firmware file, but I am not clear on what files >>> I should be using. SparkLAN provided, with the qcacld-2.0 wlan >>> driver, the following files: >>> athsetup.bin, athwlan.bin, cfg.dat, fakeboar.bin, otp.bin, and >>> qcom_cfg.ini. I used the command: >>> >>> qca-swiss-army-knife/tools/scripts/ath10k/ath10k-fwencoder --create >>> --otp ../../../otp.bin --firmware ../../../athwlan.bin >>> --set-wmi-op-version=tlv --set-htt-op-version=tlv --set-fw-api=6 >>> --features=ignore-otp-result >>> >>> to create my firmware-usb-6.bin and used the fakeboar.bin for my >>> board-usb.bin files. However, when the driver loads, it is looking >>> for a file called ath10k/cal-usb-1-1.2.bin. Where do I get that >>> file? >> You can ignore that warning. cal-*.bin are optional files containing the >> calibration data, in case you don't have the calibration data in OTP. >> But my guess is that in your device you have the calibration data in OTP >> so you don't need cal-*.bin. >> >> Hopefully in 4.18 that warning will be away and users won't get confused >> anymore. >> >>> I tried using the athsetup.bin file for this, but I do not >>> think that works. The driver reports: >>> >>> /lib/firmware/ath10k/QCA9377/hw1.0# usb 1-1.2: qca9377 hw1.1 SparkLAN >>> WPEQ-160ACN target 0x05020001 chip_id 0x sub : >>> usb 1-1.2: kconfig debug 1 debugfs 0 tracing 0 dfs 0 testmode 1 >>> usb 1-1.2: firmware ver api 6 features ignore-otp crc32 e8985f67 >>> usb 1-1.2: found invalid board magic >>> usb 1-1.2: board_file api 1 bmi_id N/A crc32 58a139e9 >>> usb 1-1.2: invalid hw_params.n_cipher_suites 0 >>> >>> What does invalid board magic mean? >> This log means that ath10k first tried to load board-2.bin but it was >> corrupted for some reason. Then it found and used board.bin instead. > It seems odd that the board-2.bin file I downloaded from > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath10k/QCA9377/hw1.0 > is somehow corrupted. Does the message mean that the board-2.bin file > itself is bad or that it is not appropriate/useful for my particular > Wi-Fi device? I meant that the file itself is bad, but of course there could be a bug lurking somewhere as well. The md5sum should be: 0234621d41643e46243438b1661c2407 ath10k/QCA9377/hw1.0/board-2.bin But this does not make any difference for you as the board-2.bin file does not have any board files for usb devices yet. > When you say that the driver then used board.bin instead, I think in > my case this is board-usb.bin (the same as my fakeboar.bin file from > SparkLAN), since my device is a USB device. I am just trying to be > clear on my understanding. A good point and you are correct. I forgot that Erik's patches are still using that special board-usb.bin. That should be removed before the patches get applied upstream as we should get all the board files to board-2.bin anyway. (board.bin is just for testing purposes) >>> The Wi-Fi USB adapter may be installed in any number of different USB >>> locations, so why is the USB location (1-1.2) part of one of the >>> filenames? >> Because there needs to be some way to identify multiple devices on the >> same host. But cal-*.bin is mainly meant for AP devices where the >> devices have a fixed slot in the PCI bus and the calibration data is >> stored in host's filesystem (check openwrt to see how it's used). >> > I did manage to get a successful Wi-Fi STA mode connection with this > driver. One issue that I don't understand is when the driver attempts > to load a FW file that is not present, it fails with error -2 and then > reports, "Falling back to user helper". However, this 'user helper' > does not exist/work either, but the driver waits quite a while waiting > for it (about half a minute or so). This causes a delay loading the > driver (about half a minute for each missing file). So, even though > the cal
Re: Support for QCA9377
On 5/16/2018 11:27 AM, Kalle Valo wrote: + linux-wireless Jay Foster writes: On 5/15/2018 9:56 PM, Kalle Valo wrote: Jay Foster writes: I too have been, off and on, looking for an ath10k driver solution for a SparkLAN WUBQ-159ACN USB Wi-Fi adapter, so I have been keeping an eye on this mailing list. I just tried the latest ath10k-pending-sdio-usb branch (ath10k-pending-sdio-usb-201804210910 tag), since I could see that support for the SparkLAN USB 0CF3:9378 device was just added. The driver refers to this as the SparkLAN WPEQ-160ACN device, but it has the same USB vendor/product ID as my WUBQ-159ACN. They both use the QCA9377 chip. I got a driver to build with the 4.9 kernel and when it boots, it recognizes my Wi-Fi adapter. Now, I am trying to sort out what to do about firmware. I downloaded the board-2.bin, board.bin, firmware-5.bin files from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath10k/QCA9377/hw1.0. I used the ath10k-fwencoder application from the qca-swiss-army-knife tools to also build a firmware file, but I am not clear on what files I should be using. SparkLAN provided, with the qcacld-2.0 wlan driver, the following files: athsetup.bin, athwlan.bin, cfg.dat, fakeboar.bin, otp.bin, and qcom_cfg.ini. I used the command: qca-swiss-army-knife/tools/scripts/ath10k/ath10k-fwencoder --create --otp ../../../otp.bin --firmware ../../../athwlan.bin --set-wmi-op-version=tlv --set-htt-op-version=tlv --set-fw-api=6 --features=ignore-otp-result to create my firmware-usb-6.bin and used the fakeboar.bin for my board-usb.bin files. However, when the driver loads, it is looking for a file called ath10k/cal-usb-1-1.2.bin. Where do I get that file? You can ignore that warning. cal-*.bin are optional files containing the calibration data, in case you don't have the calibration data in OTP. But my guess is that in your device you have the calibration data in OTP so you don't need cal-*.bin. Hopefully in 4.18 that warning will be away and users won't get confused anymore. I tried using the athsetup.bin file for this, but I do not think that works. The driver reports: /lib/firmware/ath10k/QCA9377/hw1.0# usb 1-1.2: qca9377 hw1.1 SparkLAN WPEQ-160ACN target 0x05020001 chip_id 0x sub : usb 1-1.2: kconfig debug 1 debugfs 0 tracing 0 dfs 0 testmode 1 usb 1-1.2: firmware ver api 6 features ignore-otp crc32 e8985f67 usb 1-1.2: found invalid board magic usb 1-1.2: board_file api 1 bmi_id N/A crc32 58a139e9 usb 1-1.2: invalid hw_params.n_cipher_suites 0 What does invalid board magic mean? This log means that ath10k first tried to load board-2.bin but it was corrupted for some reason. Then it found and used board.bin instead. It seems odd that the board-2.bin file I downloaded from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath10k/QCA9377/hw1.0 is somehow corrupted. Does the message mean that the board-2.bin file itself is bad or that it is not appropriate/useful for my particular Wi-Fi device? I meant that the file itself is bad, but of course there could be a bug lurking somewhere as well. The md5sum should be: 0234621d41643e46243438b1661c2407 ath10k/QCA9377/hw1.0/board-2.bin But this does not make any difference for you as the board-2.bin file does not have any board files for usb devices yet. This was my bad. My file was corrupted. I fixed it (matches the md5sum above), but as you noted, it is of no help for USB devices. usb 1-1.2: failed to fetch board data for bus=usb,vendor=0cf3,device=9378,subsystem-vendor=,subsystem-device= from ath10k/QCA9377/hw1.0/board-2.bin The driver then goes on and reads from board-usb.bin: usb 1-1.2: board_file api 1 bmi_id N/A crc32 58a139e9 usb 1-1.2: invalid hw_params.n_cipher_suites 0 When you say that the driver then used board.bin instead, I think in my case this is board-usb.bin (the same as my fakeboar.bin file from SparkLAN), since my device is a USB device. I am just trying to be clear on my understanding. A good point and you are correct. I forgot that Erik's patches are still using that special board-usb.bin. That should be removed before the patches get applied upstream as we should get all the board files to board-2.bin anyway. (board.bin is just for testing purposes) The Wi-Fi USB adapter may be installed in any number of different USB locations, so why is the USB location (1-1.2) part of one of the filenames? Because there needs to be some way to identify multiple devices on the same host. But cal-*.bin is mainly meant for AP devices where the devices have a fixed slot in the PCI bus and the calibration data is stored in host's filesystem (check openwrt to see how it's used). I did manage to get a successful Wi-Fi STA mode connection with this driver. One issue that I don't understand is when the driver attempts to load a FW file that is not present, it fails with error -2 and then reports, "Falling back to user help