Support for QCA9377

Support for QCA9377

[Patrick Doyle]

Hello All,
Where can I look to learn about support for the QCA9377.  I would like
to evaluate this module with an SDIO interface to an embedded
(Atmel/Microchip) processor running a 4.9.x kernel.  I found
https://patchwork.kernel.org/patch/9979563/, along with 10 other
patches submitted by Silex in September of 2017, but it appears that
nothing was ever done with that... or was it?


Basically, I'm asking for some clues as to where I could start, if I
wanted to use an open source driver with the QCA9377.

Thank you.

--wpd

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

Re: Support for QCA9377

[Gangadharan Vemula]

Hi,

Silex patch-set was applied to master-pending branch of ath.git. Now,
it is in the process of getting into mainline, Mr. Kvalo is working on
it.

As silex patches were developed on top of ath10k (which has others
developers patches from community), need to have those patches as
well.

The following branches have working version of ath10k sdio:

Boundary devices 4.9.x branch with ath10k_sdio:

https://github.com/boundarydevices/linux-imx6/tree/test-ath10k

https://github.com/erstrom/linux-ath/tree/ath-201709250721-ath10k-high-latency-silex-sdio


Need to apply [RFC,v3] from Mr. Erik Stromdahl.

Patches:

https://patchwork.kernel.org/project/ath10k/list/?submitter=164941

Refer :

https://github.com/boundarydevices/linux-imx6/commits/test-ath10k

and

https://github.com/erstrom/linux-ath/commits/ath-201709250721-ath10k-high-latency-silex-sdio

for patch dependencies.


Thanks !


Best Regards,

Gangadharan Vemula,

silex technology India Pvt. Ltd.




On Mon, May 14, 2018 at 11:09 AM, Patrick Doyle <wpdster@gmail.com> wrote:
> Hello All,
> Where can I look to learn about support for the QCA9377.  I would like
> to evaluate this module with an SDIO interface to an embedded
> (Atmel/Microchip) processor running a 4.9.x kernel.  I found
> https://patchwork.kernel.org/patch/9979563/, along with 10 other
> patches submitted by Silex in September of 2017, but it appears that
> nothing was ever done with that... or was it?
>
>
> Basically, I'm asking for some clues as to where I could start, if I
> wanted to use an open source driver with the QCA9377.
>
> Thank you.
>
> --wpd
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k

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

Re: Support for QCA9377

[Patrick Doyle]

On Mon, May 14, 2018 at 3:28 PM, Gangadharan Vemula
<gangadharan@silex-india.com> wrote:
> Hi,
>
> Silex patch-set was applied to master-pending branch of ath.git. Now,
> it is in the process of getting into mainline, Mr. Kvalo is working on
> it.
Thank you.  I will check that out.


> Need to apply [RFC,v3] from Mr. Erik Stromdahl.
>
> Patches:
>
> https://patchwork.kernel.org/project/ath10k/list/?submitter=164941

I notice that there is now an [RFC,v4] set of patches from Mr.
Stromdhal and that they include many/some/all? of the patches from the
[RFC,v3] patch set.  Would it be more appropriate to apply those on
top of the master-pending branch?

--wpd

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

Re: Support for QCA9377

[Gangadharan Vemula]

On Mon, May 14, 2018 at 12:50 PM, Patrick Doyle <wpdster@gmail.com> wrote:
> On Mon, May 14, 2018 at 3:28 PM, Gangadharan Vemula
> <gangadharan@silex-india.com> wrote:
>> Hi,
>>
>> Silex patch-set was applied to master-pending branch of ath.git. Now,
>> it is in the process of getting into mainline, Mr. Kvalo is working on
>> it.
> Thank you.  I will check that out.
>

Removed from master-pending branch and new branch has been created for
ath10k-sdio-usb,

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/log/?h=ath10k-pending-sdio-usb

I hope this is the base-branch for ath10k-sdio-usb. But, we (silex)
didn't verify anything on this branch yet.

Not sure, whether Mr.Kvalo is using this (ath10k-pending-sdio-usb)
branch for testing.

>
>> Need to apply [RFC,v3] from Mr. Erik Stromdahl.
>>
>> Patches:
>>
>> https://patchwork.kernel.org/project/ath10k/list/?submitter=164941
>
> I notice that there is now an [RFC,v4] set of patches from Mr.
> Stromdhal and that they include many/some/all? of the patches from the
> [RFC,v3] patch set.  Would it be more appropriate to apply those on
> top of the master-pending branch?
>
> --wpd

Thanks !

Best Regards,

Gangadharan Vemula,

silex technology India Pvt. Ltd.

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

Re: Support for QCA9377

[Jay Foster]

On 5/14/2018 1:09 PM, Gangadharan Vemula wrote:
> On Mon, May 14, 2018 at 12:50 PM, Patrick Doyle <wpdster@gmail.com> wrote:
>> On Mon, May 14, 2018 at 3:28 PM, Gangadharan Vemula
>> <gangadharan@silex-india.com> wrote:
>>> Hi,
>>>
>>> Silex patch-set was applied to master-pending branch of ath.git. Now,
>>> it is in the process of getting into mainline, Mr. Kvalo is working on
>>> it.
>> Thank you.  I will check that out.
>>
> Removed from master-pending branch and new branch has been created for
> ath10k-sdio-usb,
>
> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/log/?h=ath10k-pending-sdio-usb
>
> I hope this is the base-branch for ath10k-sdio-usb. But, we (silex)
> didn't verify anything on this branch yet.
>
> Not sure, whether Mr.Kvalo is using this (ath10k-pending-sdio-usb)
> branch for testing.
>
>
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?  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?
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?

Jay


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

Re: Support for QCA9377

[Kalle Valo]

Jay Foster <jayf0ster@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.

> 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).

-- 
Kalle Valo

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

Re: Support for QCA9377

[Jay Foster]

On 5/15/2018 9:56 PM, Kalle Valo wrote:
> Jay Foster <jayf0ster@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.


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

Re: Support for QCA9377

[Kalle Valo]

+ linux-wireless

Jay Foster <jayf0ster@roadrunner.com> writes:

> On 5/15/2018 9:56 PM, Kalle Valo wrote:
>> Jay Foster <jayf0ster@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?

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 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.

Yeah, that delay is a common problem and not ath10k related. IIRC
there's a Kconfig option which you can disable to avoid the delay, maybe
it was CONFIG_FW_LOADER_USER_HELPER_FALLBACK? Not sure though, Google
should be able to help with that.

-- 
Kalle Valo

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

Re: Support for QCA9377

[Jay Foster]

On 5/16/2018 11:27 AM, Kalle Valo wrote:
> + linux-wireless
>
> Jay Foster <jayf0ster@roadrunner.com> writes:
>
>> On 5/15/2018 9:56 PM, Kalle Valo wrote:
>>> Jay Foster <jayf0ster@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?
> 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=0000,subsystem-device=0000 
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 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.
> Yeah, that delay is a common problem and not ath10k related. IIRC
> there's a Kconfig option which you can disable to avoid the delay, maybe
> it was CONFIG_FW_LOADER_USER_HELPER_FALLBACK? Not sure though, Google
> should be able to help with that.
>
Thanks.  Selecting CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n did the trick.

Other issues that I have observed (probably FW related):
1) In STA mode, I observe several messages from the driver "received tx 
completion for invalid msdu_id: 0".  A Google search led me to 
https://github.com/erstrom/linux-ath/issues/1, but I did not find a 
resolution.

2) If I reboot, it appears that the USB Wi-Fi adapter is left in a 
broken state, so the device fails to enumerate and the driver won't 
load.  A power cycle is required.

3) AP mode does not work.  The driver reports:
usb 1-1.2: Failed to submit usb control message: -110
usb 1-1.2: unable to send the bmi data to the device: -110
usb 1-1.2: unable to write to the device (-110)
usb 1-1.2: settings HTC version failed
usb 1-1.2: Could not init core: -22
At this point, the device is stuffed again, and requires a power cycle.

Jay



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

Re: Support for QCA9377

[Erik Stromdahl]

Hi Jay,

On 05/16/2018 10:00 PM, Jay Foster wrote:
> Other issues that I have observed (probably FW related):
> 1) In STA mode, I observe several messages from the driver "received tx completion for invalid msdu_id: 0".  A Google search led me to https://github.com/erstrom/linux-ath/issues/1, but I did not find a resolution.
> 
> 2) If I reboot, it appears that the USB Wi-Fi adapter is left in a broken state, so the device fails to enumerate and the driver won't load.  A power cycle is required.
> 
> 3) AP mode does not work.  The driver reports:
> usb 1-1.2: Failed to submit usb control message: -110
> usb 1-1.2: unable to send the bmi data to the device: -110
> usb 1-1.2: unable to write to the device (-110)
> usb 1-1.2: settings HTC version failed
> usb 1-1.2: Could not init core: -22
> At this point, the device is stuffed again, and requires a power cycle.
> 
> Jay
> 
I am currently not working with USB at the moment (SDIO is taking all time),
so it is very likely that there has been regressions in newer kernels.

The last status of the USB stuff can be found in the cover letter of the v4 patches:

https://marc.info/?l=linux-wireless&m=151474153324114&w=2

I will most likely revisit the USB stuff at a later time, but as I said, I am currently
focusing on the SDIO chipsets.

--
Erik

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

Re: Support for QCA9377

[Kalle Valo]

Jay Foster <jayf0ster@roadrunner.com> writes:

>>> 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.
>> Yeah, that delay is a common problem and not ath10k related. IIRC
>> there's a Kconfig option which you can disable to avoid the delay, maybe
>> it was CONFIG_FW_LOADER_USER_HELPER_FALLBACK? Not sure though, Google
>> should be able to help with that.
>>
> Thanks.  Selecting CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n did the trick.

Good that you got it working.

> Other issues that I have observed (probably FW related):
> 1) In STA mode, I observe several messages from the driver "received
> tx completion for invalid msdu_id: 0".  A Google search led me to
> https://github.com/erstrom/linux-ath/issues/1, but I did not find a
> resolution.

Yeah, I think have seen the same while I was testing USB patches.

> 2) If I reboot, it appears that the USB Wi-Fi adapter is left in a
> broken state, so the device fails to enumerate and the driver won't
> load.  A power cycle is required.

That's not good. We should find a way to reset the USB device, does
anyone know how?

> 3) AP mode does not work.  The driver reports:
> usb 1-1.2: Failed to submit usb control message: -110
> usb 1-1.2: unable to send the bmi data to the device: -110
> usb 1-1.2: unable to write to the device (-110)
> usb 1-1.2: settings HTC version failed
> usb 1-1.2: Could not init core: -22
> At this point, the device is stuffed again, and requires a power cycle.

Ok, so we need to disable AP mode support for USB devices from ath10k,
at least temporarily before we find a solution for it.

-- 
Kalle Valo

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