Re: [PATCH 3/3] rt2x00: rt2800: use correct txop value in tx descriptor

[Helmut Schaa <helmut.schaa@googlemail.com>]

Am Donnerstag 06 Mai 2010 schrieb Gertjan van Wingerde:
> On 05/06/10 12:29, Helmut Schaa wrote:

[...]

> > diff --git a/drivers/net/wireless/rt2x00/rt2x00ht.c b/drivers/net/wireless/rt2x00/rt2x00ht.c
> > index 1056c92..5483fec 100644
> > --- a/drivers/net/wireless/rt2x00/rt2x00ht.c
> > +++ b/drivers/net/wireless/rt2x00/rt2x00ht.c
> > @@ -66,4 +66,6 @@ void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
> >  		__set_bit(ENTRY_TXD_HT_BW_40, &txdesc->flags);
> >  	if (txrate->flags & IEEE80211_TX_RC_SHORT_GI)
> >  		__set_bit(ENTRY_TXD_HT_SHORT_GI, &txdesc->flags);
> > +
> > +	txdesc->txop = TXOP_HTTXOP;
> >  }
> 
> I am not too sure about this part. If I look at the Ralink vendor driver, they are most of the time
> using IFS_BACKOFF (value 3). Why did you put this on TXOP_HTTXOP?

>From what I saw in the ralink driver IFS_BACKOFF is only used for management frames, IFS_SIFS only
for subsequent frames in a fragment burst and IFS_HTTXOPS for "normal" data frames. But that's
just the result of a _quick_ review. So I might be wrong here as well :)

To be honest I don't really know what the device does in case IFS_HTTXOPS is set but that was
the value we've passed to the driver before ;) (==IFS_BACKOFF on all other ralink chips) and it 
works quite well. I also tried IFS_BACKOFF and I wasn't able to see a difference when using
legacy (11b & 11g) rates (neither on the device itself nor with a second machine monitoring
the traffic).

But I agree that we have to dig further on when to use which value but nevertheless the patch
shouldn't cause any harm but is meant as a base for further improvements.

If you want to we can also wait with this one until we completely figured out what to do?

Helmut