Support for QCA9377

[Jay Foster]

On 5/15/2018 9:56 PM, Kalle Valo wrote:
> Jay Foster <jayf0ster at roadrunner.com> 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 0x00000000 sub 0000:0000
>> 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-<bus>.bin or 
the cal-usb-<bus>.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.