On Sun, 2013-08-25 at 16:14 +0300, Arik Nemtsov wrote:

quoted

quoted

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.

quoted

quoted

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.

quoted

quoted

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.

quoted

quoted

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