Re: [PATCH 1/2] mac80211: add sta_update_rates callback

[Johannes Berg <johannes@sipsolutions.net>]

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