problems with a 9377 based SDIO module

problems with a 9377 based SDIO module

[Greg Ungerer]

Hi Erik,

I have a Compex WSD377 WiFi module with SDIO interface on a new
iMX6 based platform. I am trying to get the module going but am
having problems with it at probe/init time.

Ultimately what I see at ath10k_sdio module load time is:

<4>ath10k_sdio mmc0:0001:1: WARNING: ath10k SDIO support is incomplete, don't expect anything to work!
<6>ath10k_sdio mmc0:0001:1: qca9377 hw1.1 sdio target 0x05020001 chip_id 0x00000000 sub 0000:0000
<6>ath10k_sdio mmc0:0001:1: kconfig debug 1 debugfs 0 tracing 0 dfs 0 testmode 0
<6>ath10k_sdio mmc0:0001:1: firmware ver WLAN.TF.1.1.1-00061-QCATFSWPZ-1 api 5 features ignore-otp crc32 7746e551
<3>ath10k_sdio mmc0:0001:1: failed to fetch board data for bus=sdio,vendor=0271,device=0701,subsystem-vendor=0000,subsystem-device=0000 from ath10k/QCA9377/hw1.0/board-2.bin
<6>ath10k_sdio mmc0:0001:1: board_file api 1 bmi_id N/A crc32 78c48ff6
<4>ath10k_sdio mmc0:0001:1: failed to write to address 0x828: -84
<4>ath10k_sdio mmc0:0001:1: unable to disable sdio interrupts: -84
<3>ath10k_sdio mmc0:0001:1: could not start HIF: -84
<3>ath10k_sdio mmc0:0001:1: could not init core (-84)
<4>mmc0: queuing unknown CIS tuple 0x01 (3 bytes)
<4>mmc0: queuing unknown CIS tuple 0x1a (5 bytes)
<4>mmc0: queuing unknown CIS tuple 0x1b (8 bytes)
<4>mmc0: queuing unknown CIS tuple 0x14 (0 bytes)
<3>ath10k_sdio mmc0:0001:1: could not probe fw (-84)

Tracing I can see that a fair bit of IO has gone on when it finally
gets to the "failed to write to address 0x828: -84". I assume the
bulk writes up to that point are the firmware download.

I am using a linux-5.2 kernel with your patches at
https://github.com/erstrom/linux-ath.git, v5.2-ath10k-sdio branch.

My primary concern is if I am using the write firmware.

I have a firmware-sdio-5.bin which is the QCA9377/hw1.0/untested/firmware-sdio-5.bin_WLAN.TF.1.1.1-00061-QCATFSWPZ-1
file from the ath10k-firmware tree at https://github.com/kvalo/ath10k-firmware.git.
And the board-sdio.bin which is the bdwlan30.bin from https://github.com/boundarydevices/qca-firmware.git.

I ended up with those from comments made in
https://ath10k.infradead.narkive.com/lgpFutCZ/patch-00-11-sdio-support-for-ath10k
But maybe I am off-track here?

Does the kernel trace give any clues as what the problem may be?
Any other ideas?

Regards
Greg


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

Re: problems with a 9377 based SDIO module

[Greg Ungerer]

On 29/8/19 4:33 pm, Greg Ungerer wrote:
> I have a Compex WSD377 WiFi module with SDIO interface on a new
> iMX6 based platform. I am trying to get the module going but am
> having problems with it at probe/init time.
> 
> Ultimately what I see at ath10k_sdio module load time is:
> 
> <4>ath10k_sdio mmc0:0001:1: WARNING: ath10k SDIO support is incomplete, don't expect anything to work!
> <6>ath10k_sdio mmc0:0001:1: qca9377 hw1.1 sdio target 0x05020001 chip_id 0x00000000 sub 0000:0000
> <6>ath10k_sdio mmc0:0001:1: kconfig debug 1 debugfs 0 tracing 0 dfs 0 testmode 0
> <6>ath10k_sdio mmc0:0001:1: firmware ver WLAN.TF.1.1.1-00061-QCATFSWPZ-1 api 5 features ignore-otp crc32 7746e551
> <3>ath10k_sdio mmc0:0001:1: failed to fetch board data for bus=sdio,vendor=0271,device=0701,subsystem-vendor=0000,subsystem-device=0000 from ath10k/QCA9377/hw1.0/board-2.bin
> <6>ath10k_sdio mmc0:0001:1: board_file api 1 bmi_id N/A crc32 78c48ff6
> <4>ath10k_sdio mmc0:0001:1: failed to write to address 0x828: -84
> <4>ath10k_sdio mmc0:0001:1: unable to disable sdio interrupts: -84
> <3>ath10k_sdio mmc0:0001:1: could not start HIF: -84
> <3>ath10k_sdio mmc0:0001:1: could not init core (-84)
> <4>mmc0: queuing unknown CIS tuple 0x01 (3 bytes)
> <4>mmc0: queuing unknown CIS tuple 0x1a (5 bytes)
> <4>mmc0: queuing unknown CIS tuple 0x1b (8 bytes)
> <4>mmc0: queuing unknown CIS tuple 0x14 (0 bytes)
> <3>ath10k_sdio mmc0:0001:1: could not probe fw (-84)
> 
> Tracing I can see that a fair bit of IO has gone on when it finally
> gets to the "failed to write to address 0x828: -84". I assume the
> bulk writes up to that point are the firmware download.
> 
> I am using a linux-5.2 kernel with your patches at
> https://github.com/erstrom/linux-ath.git, v5.2-ath10k-sdio branch.

Problem mostly solved by also patching with the changes at
https://kernel.googlesource.com/pub/scm/linux/kernel/git/kvalo/ath.
Applying the v5.2-ath10k-sdio changes on top of them.

Now it successfully probes the device. But after configuring wlan0
and sending/receiving a few packets I started to see:

ath10k_sdio mmc0:0001:1: msdu_id allocation failed -28^M
ath10k_sdio mmc0:0001:1: failed to transmit packet, dropping: -28^M
ath10k_sdio mmc0:0001:1: failed to submit frame: -28^M
ath10k_sdio mmc0:0001:1: failed to push frame: -28^M

Regards
Greg



> My primary concern is if I am using the write firmware.
> 
> I have a firmware-sdio-5.bin which is the QCA9377/hw1.0/untested/firmware-sdio-5.bin_WLAN.TF.1.1.1-00061-QCATFSWPZ-1
> file from the ath10k-firmware tree at https://github.com/kvalo/ath10k-firmware.git.
> And the board-sdio.bin which is the bdwlan30.bin from https://github.com/boundarydevices/qca-firmware.git.
> 
> I ended up with those from comments made in
> https://ath10k.infradead.narkive.com/lgpFutCZ/patch-00-11-sdio-support-for-ath10k
> But maybe I am off-track here?
> 
> Does the kernel trace give any clues as what the problem may be?
> Any other ideas?
> 
> Regards
> Greg
> 

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

Re: problems with a 9377 based SDIO module

[Erik Stromdahl]

Hi Greg,

On 8/30/19 4:52 PM, Greg Ungerer wrote:
> 
> On 29/8/19 4:33 pm, Greg Ungerer wrote:
>> I have a Compex WSD377 WiFi module with SDIO interface on a new
>> iMX6 based platform. I am trying to get the module going but am
>> having problems with it at probe/init time.
>>
>> Ultimately what I see at ath10k_sdio module load time is:
>>
>> <4>ath10k_sdio mmc0:0001:1: WARNING: ath10k SDIO support is incomplete, don't expect anything to work!
>> <6>ath10k_sdio mmc0:0001:1: qca9377 hw1.1 sdio target 0x05020001 chip_id 0x00000000 sub 0000:0000
>> <6>ath10k_sdio mmc0:0001:1: kconfig debug 1 debugfs 0 tracing 0 dfs 0 testmode 0
>> <6>ath10k_sdio mmc0:0001:1: firmware ver WLAN.TF.1.1.1-00061-QCATFSWPZ-1 api 5 features ignore-otp crc32 7746e551
>> <3>ath10k_sdio mmc0:0001:1: failed to fetch board data for bus=sdio,vendor=0271,device=0701,subsystem-vendor=0000,subsystem-device=0000 from ath10k/QCA9377/hw1.0/board-2.bin
>> <6>ath10k_sdio mmc0:0001:1: board_file api 1 bmi_id N/A crc32 78c48ff6
>> <4>ath10k_sdio mmc0:0001:1: failed to write to address 0x828: -84
>> <4>ath10k_sdio mmc0:0001:1: unable to disable sdio interrupts: -84
>> <3>ath10k_sdio mmc0:0001:1: could not start HIF: -84
>> <3>ath10k_sdio mmc0:0001:1: could not init core (-84)
>> <4>mmc0: queuing unknown CIS tuple 0x01 (3 bytes)
>> <4>mmc0: queuing unknown CIS tuple 0x1a (5 bytes)
>> <4>mmc0: queuing unknown CIS tuple 0x1b (8 bytes)
>> <4>mmc0: queuing unknown CIS tuple 0x14 (0 bytes)
>> <3>ath10k_sdio mmc0:0001:1: could not probe fw (-84)
>>
>> Tracing I can see that a fair bit of IO has gone on when it finally
>> gets to the "failed to write to address 0x828: -84". I assume the
>> bulk writes up to that point are the firmware download.
>>
>> I am using a linux-5.2 kernel with your patches at
>> https://github.com/erstrom/linux-ath.git, v5.2-ath10k-sdio branch.
> 
> Problem mostly solved by also patching with the changes at
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/kvalo/ath.
> Applying the v5.2-ath10k-sdio changes on top of them.
> 
> Now it successfully probes the device. But after configuring wlan0
> and sending/receiving a few packets I started to see:
> 
> ath10k_sdio mmc0:0001:1: msdu_id allocation failed -28^M
> ath10k_sdio mmc0:0001:1: failed to transmit packet, dropping: -28^M
> ath10k_sdio mmc0:0001:1: failed to submit frame: -28^M
> ath10k_sdio mmc0:0001:1: failed to push frame: -28^M
> 
I was actually trying my v5.2 branch with my QCA9377 SDIO device today,
and everything was running without any problems.

I don't recognize your errors.
The error message you get is because the driver is not able to allocate an
MSDU ID for the TX MSDU.

It looks as if your hardware does not notify the driver that it has consumed
the MSDUs (with a TX_COMPL_IND). Then the MSDU ID never gets freed and the
driver will run out of IDs.

> 
> 
>> My primary concern is if I am using the write firmware.
>>
>> I have a firmware-sdio-5.bin which is the QCA9377/hw1.0/untested/firmware-sdio-5.bin_WLAN.TF.1.1.1-00061-QCATFSWPZ-1
>> file from the ath10k-firmware tree at https://github.com/kvalo/ath10k-firmware.git.
>> And the board-sdio.bin which is the bdwlan30.bin from https://github.com/boundarydevices/qca-firmware.git.
This firmware should work. I am using it as well.

>>
>> I ended up with those from comments made in
>> https://ath10k.infradead.narkive.com/lgpFutCZ/patch-00-11-sdio-support-for-ath10k
>> But maybe I am off-track here?
>>
>> Does the kernel trace give any clues as what the problem may be?
>> Any other ideas?
The only thing I can think of is that something is wrong with your SDIO/MMC setup
(device tree?) or your actual hardware.

--
Erik

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

Re: problems with a 9377 based SDIO module

[Greg Ungerer]

Hi Erik,

Thanks for the response.

On 1/9/19 12:49 am, Erik Stromdahl wrote:
> On 8/30/19 4:52 PM, Greg Ungerer wrote:
>> On 29/8/19 4:33 pm, Greg Ungerer wrote:
>>> I have a Compex WSD377 WiFi module with SDIO interface on a new
>>> iMX6 based platform. I am trying to get the module going but am
>>> having problems with it at probe/init time.
>>>
>>> Ultimately what I see at ath10k_sdio module load time is:
>>>
>>> <4>ath10k_sdio mmc0:0001:1: WARNING: ath10k SDIO support is incomplete, don't expect anything to work!
>>> <6>ath10k_sdio mmc0:0001:1: qca9377 hw1.1 sdio target 0x05020001 chip_id 0x00000000 sub 0000:0000
>>> <6>ath10k_sdio mmc0:0001:1: kconfig debug 1 debugfs 0 tracing 0 dfs 0 testmode 0
>>> <6>ath10k_sdio mmc0:0001:1: firmware ver WLAN.TF.1.1.1-00061-QCATFSWPZ-1 api 5 features ignore-otp crc32 7746e551
>>> <3>ath10k_sdio mmc0:0001:1: failed to fetch board data for bus=sdio,vendor=0271,device=0701,subsystem-vendor=0000,subsystem-device=0000 from ath10k/QCA9377/hw1.0/board-2.bin
>>> <6>ath10k_sdio mmc0:0001:1: board_file api 1 bmi_id N/A crc32 78c48ff6
>>> <4>ath10k_sdio mmc0:0001:1: failed to write to address 0x828: -84
>>> <4>ath10k_sdio mmc0:0001:1: unable to disable sdio interrupts: -84
>>> <3>ath10k_sdio mmc0:0001:1: could not start HIF: -84
>>> <3>ath10k_sdio mmc0:0001:1: could not init core (-84)
>>> <4>mmc0: queuing unknown CIS tuple 0x01 (3 bytes)
>>> <4>mmc0: queuing unknown CIS tuple 0x1a (5 bytes)
>>> <4>mmc0: queuing unknown CIS tuple 0x1b (8 bytes)
>>> <4>mmc0: queuing unknown CIS tuple 0x14 (0 bytes)
>>> <3>ath10k_sdio mmc0:0001:1: could not probe fw (-84)
>>>
>>> Tracing I can see that a fair bit of IO has gone on when it finally
>>> gets to the "failed to write to address 0x828: -84". I assume the
>>> bulk writes up to that point are the firmware download.
>>>
>>> I am using a linux-5.2 kernel with your patches at
>>> https://github.com/erstrom/linux-ath.git, v5.2-ath10k-sdio branch.
>>
>> Problem mostly solved by also patching with the changes at
>> https://kernel.googlesource.com/pub/scm/linux/kernel/git/kvalo/ath.
>> Applying the v5.2-ath10k-sdio changes on top of them.
>>
>> Now it successfully probes the device. But after configuring wlan0
>> and sending/receiving a few packets I started to see:
>>
>> ath10k_sdio mmc0:0001:1: msdu_id allocation failed -28^M
>> ath10k_sdio mmc0:0001:1: failed to transmit packet, dropping: -28^M
>> ath10k_sdio mmc0:0001:1: failed to submit frame: -28^M
>> ath10k_sdio mmc0:0001:1: failed to push frame: -28^M
>>
> I was actually trying my v5.2 branch with my QCA9377 SDIO device today,
> and everything was running without any problems.

So do you mean you can use your v5.2 branch with no other kernel
changes and get a QCA9377 module to work?

I could not do that (as per my original mail that started this thread).
I took just your changes and applied to my v5.2 tree, they all applied
cleanly and compile cleanly. But do not work.

I had to apply a lot of patches from the kvalo/ath tree first. And that
was a real can of worms - I mostly applied patches that appeared to be
part of changes submitted for v5.3.

Regards
Greg



> I don't recognize your errors.
> The error message you get is because the driver is not able to allocate an
> MSDU ID for the TX MSDU.
> 
> It looks as if your hardware does not notify the driver that it has consumed
> the MSDUs (with a TX_COMPL_IND). Then the MSDU ID never gets freed and the
> driver will run out of IDs.
> 
>>
>>
>>> My primary concern is if I am using the write firmware.
>>>
>>> I have a firmware-sdio-5.bin which is the QCA9377/hw1.0/untested/firmware-sdio-5.bin_WLAN.TF.1.1.1-00061-QCATFSWPZ-1
>>> file from the ath10k-firmware tree at https://github.com/kvalo/ath10k-firmware.git.
>>> And the board-sdio.bin which is the bdwlan30.bin from https://github.com/boundarydevices/qca-firmware.git.
> This firmware should work. I am using it as well.
> 
>>>
>>> I ended up with those from comments made in
>>> https://ath10k.infradead.narkive.com/lgpFutCZ/patch-00-11-sdio-support-for-ath10k
>>> But maybe I am off-track here?
>>>
>>> Does the kernel trace give any clues as what the problem may be?
>>> Any other ideas?
> The only thing I can think of is that something is wrong with your SDIO/MMC setup
> (device tree?) or your actual hardware.
> 
> -- 
> Erik
> 

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

Re: problems with a 9377 based SDIO module

[Greg Ungerer]

Hi Erik,

On 2/9/19 4:58 pm, Greg Ungerer wrote:
> On 1/9/19 12:49 am, Erik Stromdahl wrote:
>> On 8/30/19 4:52 PM, Greg Ungerer wrote:
>>> On 29/8/19 4:33 pm, Greg Ungerer wrote:
>>>> I have a Compex WSD377 WiFi module with SDIO interface on a new
>>>> iMX6 based platform. I am trying to get the module going but am
>>>> having problems with it at probe/init time.
>>>>
>>>> Ultimately what I see at ath10k_sdio module load time is:
>>>>
>>>> <4>ath10k_sdio mmc0:0001:1: WARNING: ath10k SDIO support is incomplete, don't expect anything to work!
>>>> <6>ath10k_sdio mmc0:0001:1: qca9377 hw1.1 sdio target 0x05020001 chip_id 0x00000000 sub 0000:0000
>>>> <6>ath10k_sdio mmc0:0001:1: kconfig debug 1 debugfs 0 tracing 0 dfs 0 testmode 0
>>>> <6>ath10k_sdio mmc0:0001:1: firmware ver WLAN.TF.1.1.1-00061-QCATFSWPZ-1 api 5 features ignore-otp crc32 7746e551
>>>> <3>ath10k_sdio mmc0:0001:1: failed to fetch board data for bus=sdio,vendor=0271,device=0701,subsystem-vendor=0000,subsystem-device=0000 from ath10k/QCA9377/hw1.0/board-2.bin
>>>> <6>ath10k_sdio mmc0:0001:1: board_file api 1 bmi_id N/A crc32 78c48ff6
>>>> <4>ath10k_sdio mmc0:0001:1: failed to write to address 0x828: -84
>>>> <4>ath10k_sdio mmc0:0001:1: unable to disable sdio interrupts: -84
>>>> <3>ath10k_sdio mmc0:0001:1: could not start HIF: -84
>>>> <3>ath10k_sdio mmc0:0001:1: could not init core (-84)
>>>> <4>mmc0: queuing unknown CIS tuple 0x01 (3 bytes)
>>>> <4>mmc0: queuing unknown CIS tuple 0x1a (5 bytes)
>>>> <4>mmc0: queuing unknown CIS tuple 0x1b (8 bytes)
>>>> <4>mmc0: queuing unknown CIS tuple 0x14 (0 bytes)
>>>> <3>ath10k_sdio mmc0:0001:1: could not probe fw (-84)
>>>>
>>>> Tracing I can see that a fair bit of IO has gone on when it finally
>>>> gets to the "failed to write to address 0x828: -84". I assume the
>>>> bulk writes up to that point are the firmware download.
>>>>
>>>> I am using a linux-5.2 kernel with your patches at
>>>> https://github.com/erstrom/linux-ath.git, v5.2-ath10k-sdio branch.
>>>
>>> Problem mostly solved by also patching with the changes at
>>> https://kernel.googlesource.com/pub/scm/linux/kernel/git/kvalo/ath.
>>> Applying the v5.2-ath10k-sdio changes on top of them.
>>>
>>> Now it successfully probes the device. But after configuring wlan0
>>> and sending/receiving a few packets I started to see:
>>>
>>> ath10k_sdio mmc0:0001:1: msdu_id allocation failed -28^M
>>> ath10k_sdio mmc0:0001:1: failed to transmit packet, dropping: -28^M
>>> ath10k_sdio mmc0:0001:1: failed to submit frame: -28^M
>>> ath10k_sdio mmc0:0001:1: failed to push frame: -28^M
>>>
>> I was actually trying my v5.2 branch with my QCA9377 SDIO device today,
>> and everything was running without any problems.
> 
> So do you mean you can use your v5.2 branch with no other kernel
> changes and get a QCA9377 module to work?
> 
> I could not do that (as per my original mail that started this thread).
> I took just your changes and applied to my v5.2 tree, they all applied
> cleanly and compile cleanly. But do not work.
> 
> I had to apply a lot of patches from the kvalo/ath tree first. And that
> was a real can of worms - I mostly applied patches that appeared to be
> part of changes submitted for v5.3.

I tried a lightly different approach and had more success.

I started with my linux-5.2 kernel. Copied the entire ath10k driver
sources from linux-5.3-rc7 (drivers/net/wireless/ath/ath10k/*)
and then applied the patches from your master branch at
https://github.com/erstrom/linux-ath.git.

That produced a working client wlan interface.

Regards
Greg



>> I don't recognize your errors.
>> The error message you get is because the driver is not able to allocate an
>> MSDU ID for the TX MSDU.
>>
>> It looks as if your hardware does not notify the driver that it has consumed
>> the MSDUs (with a TX_COMPL_IND). Then the MSDU ID never gets freed and the
>> driver will run out of IDs.
>>
>>>
>>>
>>>> My primary concern is if I am using the write firmware.
>>>>
>>>> I have a firmware-sdio-5.bin which is the QCA9377/hw1.0/untested/firmware-sdio-5.bin_WLAN.TF.1.1.1-00061-QCATFSWPZ-1
>>>> file from the ath10k-firmware tree at https://github.com/kvalo/ath10k-firmware.git.
>>>> And the board-sdio.bin which is the bdwlan30.bin from https://github.com/boundarydevices/qca-firmware.git.
>> This firmware should work. I am using it as well.
>>
>>>>
>>>> I ended up with those from comments made in
>>>> https://ath10k.infradead.narkive.com/lgpFutCZ/patch-00-11-sdio-support-for-ath10k
>>>> But maybe I am off-track here?
>>>>
>>>> Does the kernel trace give any clues as what the problem may be?
>>>> Any other ideas?
>> The only thing I can think of is that something is wrong with your SDIO/MMC setup
>> (device tree?) or your actual hardware.
>>
>> -- 
>> Erik
>>

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

Re: problems with a 9377 based SDIO module

[Erik Stromdahl]

Hi Greg,

On 9/3/19 1:37 PM, Greg Ungerer wrote:
> Hi Erik,
> 
> On 2/9/19 4:58 pm, Greg Ungerer wrote:
>> On 1/9/19 12:49 am, Erik Stromdahl wrote:
>>> On 8/30/19 4:52 PM, Greg Ungerer wrote:
>>>> On 29/8/19 4:33 pm, Greg Ungerer wrote:
>>>>> I have a Compex WSD377 WiFi module with SDIO interface on a new
>>>>> iMX6 based platform. I am trying to get the module going but am
>>>>> having problems with it at probe/init time.
>>>>>
>>>>> Ultimately what I see at ath10k_sdio module load time is:
>>>>>
>>>>> <4>ath10k_sdio mmc0:0001:1: WARNING: ath10k SDIO support is incomplete, don't expect anything to work!
>>>>> <6>ath10k_sdio mmc0:0001:1: qca9377 hw1.1 sdio target 0x05020001 chip_id 0x00000000 sub 0000:0000
>>>>> <6>ath10k_sdio mmc0:0001:1: kconfig debug 1 debugfs 0 tracing 0 dfs 0 testmode 0
>>>>> <6>ath10k_sdio mmc0:0001:1: firmware ver WLAN.TF.1.1.1-00061-QCATFSWPZ-1 api 5 features ignore-otp crc32 7746e551
>>>>> <3>ath10k_sdio mmc0:0001:1: failed to fetch board data for bus=sdio,vendor=0271,device=0701,subsystem-vendor=0000,subsystem-device=0000 from ath10k/QCA9377/hw1.0/board-2.bin
>>>>> <6>ath10k_sdio mmc0:0001:1: board_file api 1 bmi_id N/A crc32 78c48ff6
>>>>> <4>ath10k_sdio mmc0:0001:1: failed to write to address 0x828: -84
>>>>> <4>ath10k_sdio mmc0:0001:1: unable to disable sdio interrupts: -84
>>>>> <3>ath10k_sdio mmc0:0001:1: could not start HIF: -84
>>>>> <3>ath10k_sdio mmc0:0001:1: could not init core (-84)
>>>>> <4>mmc0: queuing unknown CIS tuple 0x01 (3 bytes)
>>>>> <4>mmc0: queuing unknown CIS tuple 0x1a (5 bytes)
>>>>> <4>mmc0: queuing unknown CIS tuple 0x1b (8 bytes)
>>>>> <4>mmc0: queuing unknown CIS tuple 0x14 (0 bytes)
>>>>> <3>ath10k_sdio mmc0:0001:1: could not probe fw (-84)
>>>>>
>>>>> Tracing I can see that a fair bit of IO has gone on when it finally
>>>>> gets to the "failed to write to address 0x828: -84". I assume the
>>>>> bulk writes up to that point are the firmware download.
>>>>>
>>>>> I am using a linux-5.2 kernel with your patches at
>>>>> https://github.com/erstrom/linux-ath.git, v5.2-ath10k-sdio branch.
>>>>
>>>> Problem mostly solved by also patching with the changes at
>>>> https://kernel.googlesource.com/pub/scm/linux/kernel/git/kvalo/ath.
>>>> Applying the v5.2-ath10k-sdio changes on top of them.
>>>>
>>>> Now it successfully probes the device. But after configuring wlan0
>>>> and sending/receiving a few packets I started to see:
>>>>
>>>> ath10k_sdio mmc0:0001:1: msdu_id allocation failed -28^M
>>>> ath10k_sdio mmc0:0001:1: failed to transmit packet, dropping: -28^M
>>>> ath10k_sdio mmc0:0001:1: failed to submit frame: -28^M
>>>> ath10k_sdio mmc0:0001:1: failed to push frame: -28^M
>>>>
>>> I was actually trying my v5.2 branch with my QCA9377 SDIO device today,
>>> and everything was running without any problems.
>>
>> So do you mean you can use your v5.2 branch with no other kernel
>> changes and get a QCA9377 module to work?
>>
Yes, this is what I have been running
>> I could not do that (as per my original mail that started this thread).
>> I took just your changes and applied to my v5.2 tree, they all applied
>> cleanly and compile cleanly. But do not work.
>>
>> I had to apply a lot of patches from the kvalo/ath tree first. And that
>> was a real can of worms - I mostly applied patches that appeared to be
>> part of changes submitted for v5.3.
> 
> I tried a lightly different approach and had more success.
> 
> I started with my linux-5.2 kernel. Copied the entire ath10k driver
> sources from linux-5.3-rc7 (drivers/net/wireless/ath/ath10k/*)
> and then applied the patches from your master branch at
> https://github.com/erstrom/linux-ath.git.
> 
> That produced a working client wlan interface.
> 
Good that you got it working, but it is really odd that it didn't work
with my 5.2 branch (as I said, I have been running that branch as-is without
any other patches and it has been working fine).

--
Erik

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

Re: problems with a 9377 based SDIO module

[Greg Ungerer]

Hi Erik,

On 4/9/19 6:00 am, Erik Stromdahl wrote:
> On 9/3/19 1:37 PM, Greg Ungerer wrote:
>> On 2/9/19 4:58 pm, Greg Ungerer wrote:
>>> On 1/9/19 12:49 am, Erik Stromdahl wrote:
>>>> On 8/30/19 4:52 PM, Greg Ungerer wrote:
>>>>> On 29/8/19 4:33 pm, Greg Ungerer wrote:
[snip]
>>>> I was actually trying my v5.2 branch with my QCA9377 SDIO device today,
>>>> and everything was running without any problems.
>>>
>>> So do you mean you can use your v5.2 branch with no other kernel
>>> changes and get a QCA9377 module to work?
>>>
> Yes, this is what I have been running
>>> I could not do that (as per my original mail that started this thread).
>>> I took just your changes and applied to my v5.2 tree, they all applied
>>> cleanly and compile cleanly. But do not work.
>>>
>>> I had to apply a lot of patches from the kvalo/ath tree first. And that
>>> was a real can of worms - I mostly applied patches that appeared to be
>>> part of changes submitted for v5.3.
>>
>> I tried a lightly different approach and had more success.
>>
>> I started with my linux-5.2 kernel. Copied the entire ath10k driver
>> sources from linux-5.3-rc7 (drivers/net/wireless/ath/ath10k/*)
>> and then applied the patches from your master branch at
>> https://github.com/erstrom/linux-ath.git.
>>
>> That produced a working client wlan interface.
>>
> Good that you got it working, but it is really odd that it didn't work
> with my 5.2 branch (as I said, I have been running that branch as-is without
> any other patches and it has been working fine).

I was testing in AP mode today and came across another problem.

Immediately on starting up the AP interface I get a dump:

------------[ cut here ]------------^M
WARNING: CPU: 0 PID: 18675 at kernel/dma/mapping.c:247 dma_alloc_attrs+0xb8/0xec^M
Modules linked in: nf_conntrack_netlink xt_realm arptable_filter arp_tables ip6table_mangle ip6table_raw ip6table_nat nf_log_ipv6 ip6table_filter ip6_tables xt_TCPMSS xt_mark xt_connmark iptable_mangle xt_CT iptable_raw iptable_nat nf_log_ipv4 nf_log_common xt_set xt_tcpudp xt_conntrack xt_LOG xt_limit xt_addrtype ip_set_hash_netiface ip_set_hash_net ip_set_hash_ip ip_set nfnetlink nf_nat_pptp nf_conntrack_pptp nf_nat_tftp nf_conntrack_tftp nf_nat_ftp ath10k_sdio nf_conntrack_ftp ath10k_core nf_nat nf_conntrack nf_defrag_ipv6 ath nf_defrag_ipv4 imx_sdma virt_dma iptable_filter ip_tables x_tables^M
CPU: 0 PID: 18675 Comm: hostapd Not tainted 5.2.0-ac0 #1^M
Hardware name: Freescale i.MX6 Ultralite (Device Tree)^M
[<c010c120>] (unwind_backtrace) from [<c010aa34>] (show_stack+0x10/0x14)^M
[<c010aa34>] (show_stack) from [<c011a5bc>] (__warn+0xf8/0x110)^M
[<c011a5bc>] (__warn) from [<c011a69c>] (warn_slowpath_null+0x40/0x48)^M
[<c011a69c>] (warn_slowpath_null) from [<c014e3b8>] (dma_alloc_attrs+0xb8/0xec)^M
[<c014e3b8>] (dma_alloc_attrs) from [<bf052eb8>] (ath10k_add_interface+0x5f0/0x144c [ath10k_core])^M
[<bf052eb8>] (ath10k_add_interface [ath10k_core]) from [<c05f06b8>] (drv_add_interface+0x30/0x7c)^M
[<c05f06b8>] (drv_add_interface) from [<c060330c>] (ieee80211_do_open+0x450/0x900)^M
[<c060330c>] (ieee80211_do_open) from [<c0468d20>] (__dev_open+0xc0/0x144)^M
[<c0468d20>] (__dev_open) from [<c04690ac>] (__dev_change_flags+0x154/0x1ac)^M
[<c04690ac>] (__dev_change_flags) from [<c046911c>] (dev_change_flags+0x18/0x48)^M
[<c046911c>] (dev_change_flags) from [<c0510e98>] (devinet_ioctl+0x688/0x768)^M
[<c0510e98>] (devinet_ioctl) from [<c0512da8>] (inet_ioctl+0x1f0/0x3b4)^M
[<c0512da8>] (inet_ioctl) from [<c044936c>] (sock_ioctl+0x21c/0x6d8)^M
[<c044936c>] (sock_ioctl) from [<c01bd84c>] (do_vfs_ioctl+0x9c/0x850)^M
[<c01bd84c>] (do_vfs_ioctl) from [<c01be034>] (ksys_ioctl+0x34/0x5c)^M
[<c01be034>] (ksys_ioctl) from [<c0101000>] (ret_fast_syscall+0x0/0x54)^M
Exception stack(0xc2aadfa8 to 0xc2aadff0)^M
dfa0:                   00000007 000f8080 00000007 00008914 bea71d68 00000000^M
dfc0: 00000007 000f8080 00000007 00000036 000f8080 00000001 000f7f58 000f9594^M
dfe0: 000f5d08 bea71d30 00071604 b6be65e4^M
---[ end trace 6b49e67b28c15dab ]---^M
ath10k_sdio mmc0:0001:1: coherent DMA mask is unset^M
ath10k_sdio mmc0:0001:1: failed to allocate beacon buffer: -12^M

It is failing at a dma_alloc_coherent() call in ath10k_add_interface(),
drivers/net/wireless/ath/ath10k/mac.c.

That is pretty easy to work around, by setting the coherent_dma_mask to
something like DMA_BIT_MASK(32) when it is 0. But I am wondering why
it is not initially getting that passed down from the bus driver?

Anyway with that hacked fix in the AP works (at least at 2.4GHz).

Regards
Greg


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