On Thu, 2012-08-09 at 11:44 +0200, Antonio Quartulli wrote: > On Thu, Aug 09, 2012 at 11:32:46AM +0200, Antonio Quartulli wrote: > > On Thu, Aug 09, 2012 at 08:14:57AM +0200, Johannes Berg wrote: > > > Also there's already an update call sta_rc_update() so I think you > > > should just define a new change flag for that? > > > > mh, at the very beginning I thought it was not correct what you said, but indeed > > we should be able to do the job in sta_rc_update(). > > > > But then why does the ath9k_htc driver implement ath9k_htc_update_rate() to > > update the rate used to talk to the AP? Should it use sta_rc_update() as well? > > Well, I am digging into the driver a bit more and I realised that the supported > rate set does not touch the RC at all. The supported rates are only stored in > the device (this is why there is another function for doing that in case of STA > mode) and then the RC will play its game from a different point. That's strange, why would the device care about the supported rateset of an IBSS peer? or does it have some rate control in the device? > For the reason above sta_rc_update() can't do what we want. At this point I > think we have two options: > 1) mac80211 forces this change to be done by sta_rc_update() => ath9k has to > adapt it's implementation to follow the API > 2) mac80211 uses another callback (sta_update_rates()) to refresh the supported > rates set. > > I think that option 2) is probably the way to go, because the RC stuff is > usually not strictly related to the real device (e.g. ath9k has its own rc > routines shared among ath9k and ath9k_htc but they have different routins to set > the supported_rates set for a station.) But the rate control algorithm is re-inited in this case or something? johannes -- 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
