Jean-Pierre TOSONI writes:
> @Toke: As you can see in the patch, the value 30 was the fixed value
> defined in ath9k, I kept it for compatibility only (and that's why I
> wanted to make it configurable :-)
Yup, I'm aware that this is the default from ath9k; doesn't make it any
less wrong ;)
>
Hi Ben,
I attached the patch. Please remind that it applies to ath9k.
At the end there are 3 comments in French, translation follows:
1) " longretry gives directly the transmit count, the +1 is useless.
Should rather have -1 to account for the first try"
2) " The retries just made for this
Ben Greear writes:
> On 07/18/2018 08:50 AM, Jean-Pierre TOSONI wrote:
>> Hi,
>>
>> We made retries configurable in our mac80211+ath9k system, and we ended with
>> 3 counts:
>> 1) short retry count, defaults to 4
>> 2) long retrys count, defauts to 7
>> 3) software retry count, defaults to 30
On 07/18/2018 08:50 AM, Jean-Pierre TOSONI wrote:
Hi,
We made retries configurable in our mac80211+ath9k system, and we ended with 3
counts:
1) short retry count, defaults to 4
2) long retrys count, defauts to 7
3) software retry count, defaults to 30
This last one is used separately for each
Hi,
We made retries configurable in our mac80211+ath9k system, and we ended with 3
counts:
1) short retry count, defaults to 4
2) long retrys count, defauts to 7
3) software retry count, defaults to 30
This last one is used separately for each frame in an aggregated frame, since
they can be
Debugfs support to do hardware warm reset with WMI command
WMI_PDEV_PARAM_PDEV_RESET for 10.4 and 10.2.4(if wmi
service is enabled in the firmware for backward compatibility).
This change is purely for debugging purpose when hardware hangs/mutes.
This hardware reset won't affect the connectivity
