On Mon, 2008-10-20 at 15:06 +0800, Zhu Yi wrote: > > > > + info->status.rates[0].count = tx_resp->failure_frame + 1; > > > > > > This is useless. And it is even confusable with the later count++. > > > > In what way useless? We've changed the semantics and made "count" be the > > "transmit count" rather than the "# of retries", so it has to be one > > more. Or was there a bug in the previous understanding? Wouldn't > > surprise me, and we can fix the bug here. > > I understand the +1 here. But you set the [0].count anyway in the later > for loop. So setting it here (out of the for loop) is useless. Oh, ok. I didn't see that. > I have to look at documents for more details. AFAIK, the uCode handles > the multi rates retries. Yes, I know that much, but can you tell us how exactly? > The driver passes the starting rate and how > many retries for each rates to uCode. Since the uCode is possible to > retry more rates than IEEE80211_TX_MAX_RATES, the info->status.rates[] > might not be accurate all the time. It would be good to actually report as accurate as possible (up to MAX_RATES) the retries the firmware will have done. We're going to export that information to userland in radiotap too. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
