On Fri, 2013-08-16 at 23:09 +0300, Arik Nemtsov wrote: > > Well, it can't. If you look carefully then the old chan_switch op > > behaviour is to let the driver switch, not switch in software > > afterwards. > > The right thing for chan_switch drivers would be not to call hw_config().. chan_switch? or chanctx? > > Yeah but it's (currently) meant for interfaces controlling the CSA (i.e. > > AP only right now) ... so I really think we need to make this > > controllable, I think that when we want to implement it for Intel MVM > > firmware then we'll let the firmware control the switch timing, etc. > > None of this can even be done today or with your patch. > > The TI driver implements the chan_switch op and uses channel contexts. Huh, ok, that was a combination I didn't think was going to exist, since the chanswitch API doesn't really tell you what channel context etc. OTOH, it does give you the vif so you have the chanctx implicitly. > If I catch your drift you would rather these kind of drivers (which > include MVM) use a new API exposed by mac80211 to complete the channel > switch. This API would basically be ieee80211_vif_change_channel(). Do > we still need to touch the cfg80211 chandef definition in ifmgd? That's what I was thinking, yes. > The above is maybe cleaner, but it's functionally equivalent to the > solution today - the low level driver decides when the channel switch > is completed, and ieee80211_chswitch_work() is called, which does the > right thing for all cases. Right ... I guess that works. > Note that with the above, the channel_contexts + software chan-switch > drivers will still need the kind of code that I wrote. So it would > just lead to replicated code. Or maybe you meant something else? We have too many possibilities I guess ... I think for MVM I want the disconnect, not the channel context change in software. You're taking that possibility away, hence my suggestion of a new hardware flag for it or so. > Also, where would you put csa_active = true (if at all) for a STA > interface? Unlike AP, the trigger here is mac80211 code. So putting it > there seemed appropriate. Yeah, I was really just trying to say that current chanctx drivers need not really expect a chanctx to change channel unless they implement CSA, but that currently means AP-CSA - basically what I just said above with taking away the possibility of doing the deauth instead. 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
