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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
