Driver support for QCA6174 chip using SDIO interface

[Erik Stromdahl]

On 2017-05-16 09:14, Kalle Valo wrote:
> Erik Stromdahl <erik.stromdahl at gmail.com> writes:
>
>> On 2017-05-12 02:20, Ann Lo wrote:
>>> Hi Erik,
>>>
>>> We are hoping to use your new SDIO patches for QCA9377 on kernel
>>> version 4.1.36. There appears to be version 7 patches according to the
>>> following email:
>>> http://lists.infradead.org/pipermail/ath10k/2017-April/009633.html
>>>
>>> Would you advise on the followings?
>>>
>>> 1) What is the status of ath10k SDIO for QCA9377? The above email has
>>> the comment "With this patch we have the low level HTC protocol
>>> working and it's possible to boot the firmware, but it's still not
>>> possible to connect or anything like." Do you have an estimate of the
>>> time for full functionality, that wpa_supplicant and hostapd will run
>>> successfully? How much further work is needed?
>>
>> Well, first of all, the patches on the ath10k master only contain the
>> HIF layer (which is not that useful by itself). You will need a bunch
>> of generic HL (High Latency) patches as well. These patches are common
>> for both USB and SDIO and has not yet been integrated into the ath
>> mainline.
>> These patches are available on my ath repo on github:
>>
>> https://github.com/erstrom/linux-ath
>>
>> They should be treated as very experimental though!
>> There are a few known issues with the QCA9377 SDIO chip.
>> I have as of today not been able to associate with an AP (which
>> kind of limits the usefulness of the device, at least when operating
>> in STA mode :).
>> QCA9377 USB (Linksys WUSB6100M) works much better, but is unfortunately
>> not fully stable either since I am only capable of transmit/receive
>> ~3Mbytes before it goes deaf (but at least I can associate and authenticate
>> to an AP with WPA2 PSK security).
>>
>> So what remains to be done then?
>> Well, it seems as if the sdio chipset won't work that well with the
>> generic parts of ath10k. The setup of a device is HIF layer independent
>> (mostly implemented in mac.c) and has been tested thoroughly with the
>> PCIe devices. When looking at qcacld (another driver that is not part
>> of the Linux kernel), the setup is very different (different internal
>> parameters are configured and commands are executed in a different order).
>>
>> From my point of view I think the following things needs to be done:
>>
>> 1. Make mac.c work with high latency devices (SDIO and USB). I suspect
>>    that the setup of SDIO and USB is similar.
>> 2. Add support for newer version of the WMI protocol. qcacld uses a
>>    different ABI version for the WMI messages.
>>
>> Since I am doing this work as a spare time activity only, I can't make
>> any commitments or estimates of when everything is fully implemented.
>
> I think we should try to get rest of your patches into mainline as well,
> even if they are experimental still. Hopefully we get more people
> helping that way, Adrian already expressed his interest which is very
> cool and others have been also asking especially SDIO support. And with
> good luck there are just small fixes needed to SDIO and USB properly
> working.
>
I am actually preparing another RFC round for USB. I think I will split
my remaining patches in two patchsets: USB and High Latency.

The USB patches will have a few USB specific patches and the HL patches
will have the high latency stuff that is common between SDIO and USB.

What do you think?

> Let's just clearly document that SDIO and USB support is work in
> progress, both during driver initialisation and Kconfig documentation.
> Maybe we should even depend on BROKEN, dunno?
>
I will write a similar disclaimer for USB as you did for SDIO.
Something like this:

"This module adds experimental support for USB bus. Currently
work in progress and will not fully work"