On Fri, 2008-12-05 at 09:34 +0100, Henning Rogge wrote: > Am Thursday 04 December 2008 22:20:35 schrieb Johannes Berg: > > On Thu, 2008-12-04 at 13:12 -0800, Luis R. Rodriguez wrote: > > > It seems that's the case for ath9k, at least Jouni had pointed out to me. > > > > They cannot, we don't even have that in the API. > Ath9k has it's ***_ratetable which contains a line of data for each > transmission range. 20/40Mhz and guard interval is already contained in this > table (encoded in "phy" variable). Just the MCS number is missing. Well, yes, but it's not done uniformly across drivers. > And I think the intel driver has the necessary data too. If I understand the > iwl5000 driver, it pushes the rate index (even for 802.11n) through > ieee80211_rx_status into mac80211. Sort of, yes, but again, in a much different way. We really have to rename struct ieee80211_tx_rate to struct ieee80211_txrx_rate and embed it into struct ieee80211_rx_status for doing this properly. > > > > then we also don't need the values for the number of streams since > > > > those are perfect multiples (1x, 2x, 3x, 4x for up to 4 streams). > > > > > > Well if you have the MCS index and HT mode you get the # of streams. Not > > > sure I understood the perfect multiple stuff. > > > > Right, but you don't need to store a bitrate for MCS 0, 8, 16 and 24, > > the latter three can just use the first multiplied by 2, 3 and 4 > > respectively. > When I looked at the table in the wiki I noticed it cannot be created just by > a little bit arithmetric ? Maybe someone can look at the 802.11 draft if we > don't need the tables at all but just use a formula ? If yes we could remove > them from kernelspace and just add a macro for calculating the rate into a > userspace-accessable header file. I checked for a bit, but it's not trivial. Cf. http://www.dsprelated.com/showmessage/92947/1.php > > > > and then nest the bitrate information into the STA_INFO_RATE, just like > > > > station flags are nested etc. That way the RATE_INFO things could also > > > > be used elsewhere. > > > > > > So we'll have to add an enum then too to distinguish which rate this is > > > for. > > > > No, we know that based on what "container" attribute it's contained in, > > in netlink. > So it's possible to define a substructure in the station info in nl80211 ? > Sounds like a nice way to construct the tx/rx rate. Yes, you do that by nesting. nl80211 already does that for phy info and many other things, you should be able to figure it out, just look for nla_nest_start/nla_nest_end. > I will see if I get a "v6" patch ready during the weekend. Thanks! johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
