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. 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.) Cheers, > > Cheers, > > > > > > johannes > > -- > Antonio Quartulli > > ..each of us alone is worth nothing.. > Ernesto "Che" Guevara -- Antonio Quartulli ..each of us alone is worth nothing.. Ernesto "Che" Guevara
Attachment:
pgp5lAjIZvzHf.pgp
Description: PGP signature
