On Sun, 2013-08-25 at 16:14 +0300, Arik Nemtsov wrote: > >> The right thing for chan_switch drivers would be not to call hw_config().. > > > > chan_switch? or chanctx? > > both. the hw_config(channel) is meaningless for chanctx drivers. The > legacy code for op_chan_switch drivers didn't call hw_config() as > well, assuming they'd already get notified internally by their op. Right. > >> 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. > > Yep, it's good enough. The driver gets the chandef from the vif. Ok, fair enough. > >> 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. > > I was thinking it's equivalent to to AP case - currently mac80211 is > the dictator and simply changes the chandef once the lower drv > completes the switch. Yeah but the driver in this case has a choice to not supported it. > Anyway IMHO the simplest approach to handle all the legacy stuff + > chanctx it to keep the current patch as is, and add a mac80211 HW flag > to support it, keeping the deauth option as default. > That's what I think you're suggesting? Yeah, that sounds about right. > >> 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. > > Let's keep the csa_active as I've used it, and just do a deauth when > the csa-support HW flag is not given? Works for me - I wasn't particularly worried about the csa_active handling per se, but rather what it implied about the calls and driver support etc. 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
