On 2020-09-07 23:55, Kalle Valo wrote:
Wen Gong writes:
On 2020-08-15 01:19, Kalle Valo wrote:
...
I have been thinking a different approach for this. I think another
option is to have a function like this:
ath10k_core_firmware_crashed()
{
queue_work(ar->workqueue, >restart_work);
Wen Gong writes:
> On 2020-08-15 01:19, Kalle Valo wrote:
> ...
>>
>> I have been thinking a different approach for this. I think another
>> option is to have a function like this:
>>
>> ath10k_core_firmware_crashed()
>> {
>> queue_work(ar->workqueue, >restart_work);
>> }
>>
>> In patch
Wen Gong writes:
> On 2020-08-15 01:19, Kalle Valo wrote:
>> Wen Gong writes:
>>
> ...
>>> diff --git a/drivers/net/wireless/ath/ath10k/core.c
>>> b/drivers/net/wireless/ath/ath10k/core.c
>>> index 91f131b87efc..0e31846e6c89 100644
>>> --- a/drivers/net/wireless/ath/ath10k/core.c
>>> +++
On 2020-08-15 01:19, Kalle Valo wrote:
...
I have been thinking a different approach for this. I think another
option is to have a function like this:
ath10k_core_firmware_crashed()
{
queue_work(ar->workqueue, >restart_work);
}
In patch 1 we would convert all existing callers to call
On 2020-08-15 01:19, Kalle Valo wrote:
...
I have been thinking a different approach for this. I think another
option is to have a function like this:
ath10k_core_firmware_crashed()
{
queue_work(ar->workqueue, >restart_work);
}
In patch 1 we would convert all existing callers to call
On 2020-08-15 01:19, Kalle Valo wrote:
Wen Gong writes:
...
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 91f131b87efc..0e31846e6c89 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@
Wen Gong writes:
> When it has more than one restart_work queued meanwhile, the 2nd
> restart_work is very esay to break the 1st restart work and lead
> recovery fail.
>
> Add a ref count to allow only one restart work running untill
> device successfully recovered.
>
> Tested with QCA6174 SDIO
Sorry, that response was intended for the start retries.
On Mon, Jan 20, 2020 at 5:34 AM Wen Gong wrote:
>
> On 2020-01-20 17:38, Justin Capella wrote:
> > Ok thanks. I am still trying to familiarize myself with ath10k. A
> > couple things come to mind:
> >
> > firstly recently there was a patch
On 2020-01-20 17:38, Justin Capella wrote:
Ok thanks. I am still trying to familiarize myself with ath10k. A
couple things come to mind:
firstly recently there was a patch that set stations back to
associated during recovery, do you know if the branch you're working
against includes that? I
Ok thanks. I am still trying to familiarize myself with ath10k. A
couple things come to mind:
firstly recently there was a patch that set stations back to
associated during recovery, do you know if the branch you're working
against includes that? I will try to figure that out myself but it's
at
On 2020-01-10 02:29, Wen Gong wrote:
On 2020-01-08 20:02, Justin Capella wrote:
I think this might break the "wedged" state.
Would simply not taking action unless STATE ON avoid the problems with
multiple calls to _restart? ie:
ath10k_core_restart is one part of the recovery process,
after
On 2020-01-08 20:02, Justin Capella wrote:
I think this might break the "wedged" state.
Would simply not taking action unless STATE ON avoid the problems with
multiple calls to _restart? ie:
ath10k_core_restart is one part of the recovery process,
after ath10k_core_restart, it has other
I think this might break the "wedged" state.
Would simply not taking action unless STATE ON avoid the problems with
multiple calls to _restart? ie:
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 5ec16ce19b69..a6c11b2bc97c 100644
---
13 matches
Mail list logo
