On Thu, Oct 09, 2014 at 04:15:03PM +0200, Johannes Berg wrote: > On Thu, 2014-10-09 at 16:06 +0200, Karl Beldan wrote: > > On Thu, Oct 09, 2014 at 11:06:26AM +0200, Johannes Berg wrote: > > > On Tue, 2014-10-07 at 15:53 +0200, Karl Beldan wrote: > > > > From: Karl Beldan <karl.bel...@rivierawaves.com> > > > > > > Is that really trivial? It seems to have some impact on the code, but I > > > can't right now say exactly what the impact is. Can you describe it and > > > say whether I should add it to mac80211 or mac80211-next? For "trivial" > > > I'd probably say mac80211-next, but this might be more important than > > > that? > > > > > The typo is clearly showing but the faulty behavior clearly demands more > > detail indeed. > > > > It affects non-(V)HT rates and can lead to selecting an rts_cts rate > > that is not a basic rate or way superior to the reference rate (ATM > > rates[0] used for the 1st attempt of the protected frame data). > > E.g, assuming the drivers register growing (bitrate) sorted > > ieee80211_rate tables, having : > > - rates[0].idx == d'2 and basic_rates == b'10100 > > will select rts_cts idx b'10011 & ~d'(BIT(2)-1), i.e. 1, likewise > > - rates[0].idx == d'2 and basic_rates == b'10001 > > will select rts_cts idx b'10000 > > The first is not a basic rate and the second is > rates[0]. > > > > I hope it clarifies things enough. > > Well, I'm still not sure which tree I should put it in, I guess? >
All I can say is that nor this faulty behavior nor the correspond fix are likely to cause a crash (we always tx registered rates). Karl -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
