[rt2x00-users] [PATCH v2] rt2x00: Enable fallback rates for rt61pci and rt73usb
Gertjan van Wingerde
gwingerde at gmail.com
Mon Jun 7 22:25:42 UTC 2010
On 06/07/10 23:16, Ivo Van Doorn wrote:
>>>>> Shouldn't we check whether actually a fallback rate was used, instead of simply
>>>>> always indicating that a fallback rate was used? Or will retry be 0 if the original
>>>>> requested rate was used?
>>>>
>>>> That's how it is handled in rt2800 at the moment and I couldn't find any
>>>> disadvantages (under the assumption that retries==0).
>
> Actually it is quite simple, we don't know which retry rates where used,
> so we must assume the register settings have worked correctly and base
> our txdone reporting on that.
>
>>> Hmm, that really looks odd, as the flag itself is meant to indicate that the frame
>>> was successfully sent using a fallback rate.
>>
>> But we also want to report the used fallback rates in case of a failure to
>> the rc algorithm. I mean if the driver tried MCS15 down to MCS8 for example
>> and none worked we should provide all that information to mac80211 and not
>> only that the initial rate didn't work.
>
> Agreed.
>
>>> Why do we have this flag if it isn't used in accordance with its intended usage?
>>
>> Maybe we should just change the documentation in rt2x00queue.h as below (btw.
>> I don't know what the & in front of TXDONE_FAILURE means but I just copied it ;) ).
>
> I think the & is used to make it a link within the generated HTML code from the
> source code comments.
>
>> diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.h b/drivers/net/wireless/rt2x00/rt2x00queue.h
>> index f791708..b84bfb2 100644
>> --- a/drivers/net/wireless/rt2x00/rt2x00queue.h
>> +++ b/drivers/net/wireless/rt2x00/rt2x00queue.h
>> @@ -215,7 +215,9 @@ struct rxdone_entry_desc {
>> *
>> * @TXDONE_UNKNOWN: Hardware could not determine success of transmission.
>> * @TXDONE_SUCCESS: Frame was successfully send
>> - * @TXDONE_FALLBACK: Frame was successfully send using a fallback rate.
>> + * @TXDONE_FALLBACK: Hardware used fallback rates while trying to
>> + * send this frame, only used in conjunction with &TXDONE_SUCCESS
>> + * and &TXDONE_FAILURE.
>> * @TXDONE_FAILURE: Frame was not successfully send
>> * @TXDONE_EXCESSIVE_RETRY: In addition to &TXDONE_FAILURE, the
>> * frame transmission failed due to excessive retries.
>
> This makes sense, although we should perhaps clarify a bit that there
> are 3 base flags:
> UNKNOWN, SUCCESS, FAILURE
>
> and 2 additional information flags:
> FALLBACK and EXCESSIVE_RETRY
> Whereas the first is used in combination with the SUCCESS and FAILURE
> base flags, while the latter is
> used in combination with the FAILURE base flag.
Hmmm, it sounds more logical to me to only use the FALLBACK flag if there were any retries.
There's no point in having a flag that will always be set by a driver; make it a driver
flag then, not a TX status flag.
To me we should update the rt2800pci (and Ivo's patch) to only set the FALLBACK flag when
the number of retries is larger than 0.
---
Gertjan.
More information about the users
mailing list