tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
ath-next
branch HEAD: 776c9c93bb0511d04e6222546499e5ea20ad51b0 wifi: ath12k: fix
license in p2p.c and p2p.h
elapsed time: 871m
configs tested: 154
configs skipped: 3
The following configs have been built successfully.
I'm looking to add support for the QCA9379 chipset to ath10k, specifically for
the SDIO bus version.
The vendor driver treats QCA9379 chips the same as QCA9377 chips:
https://git.codelinaro.org/clo/external-wlan/qcacld-2.0/-/commit/6258d7865b4d336daca097f42ca6f963e96e6f34
Device used for testing:
Add support for the QCA9379 chipset. Analogous to the vendor qcacld driver
this change treats the QCA9379 family the same as the QCA9377 family.
The card generally works and connects to a variety of networks (open,
WPA2-PSK, WPA3 Personal) but currently does not roam cleanly and will
reauthenticat
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
ath-qca
branch HEAD: 919ba0573cdc18a7d02983b1488d7352d83616a9 Merge branch 'ath-next'
into ath-qca
elapsed time: 766m
configs tested: 137
configs skipped: 3
The following configs have been built successfully.
More conf
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
master-pending
branch HEAD: 9f1cf0c0205ab8742682bcb0e0e4c940cb5f138a Merge branch 'pending'
into master-pending
elapsed time: 732m
configs tested: 136
configs skipped: 3
The following configs have been built successful
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
pending
branch HEAD: 5a1c33152dd053b31bd9c71148c435c751c74bda wifi: ath10k: poll
service ready message before failing
elapsed time: 732m
configs tested: 112
configs skipped: 3
The following configs have been built succ
On 2/28/2024 10:46 AM, James Prestwood wrote:
> This does appear to have fixed it! For reference this was my test:
>
> for i in $(seq 1 10); do sudo ip link set wlan0 down; sudo ip link
> set wlan0 up; echo $?; done
>
> I never saw the up command fail, and after a while I noticed one of th
Hi Baochen,
On 2/21/24 6:18 PM, Baochen Qiang wrote:
On 2/21/2024 8:38 PM, James Prestwood wrote:
Hi Baochen,
On 2/20/24 7:17 PM, Baochen Qiang wrote:
Currently host relies on CE interrupts to get notified that
the service ready message is ready. This results in timeout
issue if the interru
On 28/02/2024 17:37, Kalle Valo wrote:
> Marc Gonzalez writes:
>
>> On 28/02/2024 15:03, Kalle Valo wrote:
>>
>>> Marc Gonzalez writes:
>>>
+ qcom,no-msa-ready-indicator:
+type: boolean
+description:
+ The driver waits for this indicator before proceeding,
+
Marc Gonzalez writes:
> On 28/02/2024 15:03, Kalle Valo wrote:
>
>> Marc Gonzalez writes:
>>
>>> + qcom,no-msa-ready-indicator:
>>> +type: boolean
>>> +description:
>>> + The driver waits for this indicator before proceeding,
>>> + yet some WCNSS firmwares apparently do not se
On 28/02/2024 15:03, Kalle Valo wrote:
> Marc Gonzalez writes:
>
>> The driver waits for this indicator before proceeding,
>> yet some WCNSS firmwares apparently do not send it.
>> On those devices, it seems safe to ignore the indicator,
>> and continue loading the firmware.
>>
>> Signed-off-by:
[ Adding Jami Kettunen who documented the same issue 3 years ago ]
[ Adding Jeffrey Hugo for his past work on msm8998 ]
On 28/02/2024 15:59, Jeff Johnson wrote:
> On 2/28/2024 5:24 AM, Marc Gonzalez wrote:
>
>> The driver waits for this indicator before proceeding,
>> yet some WCNSS firmwares ap
On 2/28/2024 5:24 AM, Marc Gonzalez wrote:
> The driver waits for this indicator before proceeding,
> yet some WCNSS firmwares apparently do not send it.
> On those devices, it seems safe to ignore the indicator,
> and continue loading the firmware.
Can you list the product/hardware/firmware where
Marc Gonzalez writes:
> The driver waits for this indicator before proceeding,
> yet some WCNSS firmwares apparently do not send it.
> On those devices, it seems safe to ignore the indicator,
> and continue loading the firmware.
>
> Signed-off-by: Pierre-Hugues Husson
> Signed-off-by: Marc Gonza
The driver waits for this indicator before proceeding,
yet some WCNSS firmwares apparently do not send it.
On those devices, it seems safe to ignore the indicator,
and continue loading the firmware.
Signed-off-by: Pierre-Hugues Husson
Signed-off-by: Marc Gonzalez
---
Documentation/devicetree/bi
Work around missing MSA_READY indicator from ath10k FW
Marc Gonzalez (1):
dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop
Pierre-Hugues Husson (1):
wifi: ath10k: work around missing MSA ready indicator
Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
From: Pierre-Hugues Husson
On our APQ8998 device, driver never receives MSA_READY indicator.
We only seem to receive FW_READY and PIN_CONNECT indicators.
Not waiting for the MSA_READY indicator seems to fix the WiFi.
Signed-off-by: Pierre-Hugues Husson
Signed-off-by: Marc Gonzalez
---
drivers
17 matches
Mail list logo
