[rt2x00-users] [PATCH v2] rt2x00: Enable fallback rates for rt61pci and rt73usb

[Ivo Van Doorn]

>> >> 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.

Ivo