Search Linux Wireless

Re: [RFC 2/2] cfg80211: move channel switch logic to cfg80211

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2014-02-03 at 10:58 +0100, Michal Kazior wrote:
> This introduces the following benefits:
>  * cfg80211 is now aware of channel switching
>    (although more work still needs to be done wrt
>     interface combinations & multi-interface CSA)
>  * fixes some channel switching failcases by
>    disconnecting offending interfaces
>  * STA CSA no longer modifies BSS channel from
>    within mac80211

That's nice.

> This aims to make the following possible later:
>  * defer channel switching decision to userspace
>    (if desired so),

That's probably not needed, it can disconnect after the CSA event (that
should be sent when the CSA is first received)

>  * inform userspace what interfaces will be
>    possibly disconnected by a channel switch,

Huh? Not sure I get that part, why would userspace ever be notified
about something that *will* happen? Either the interface disconnects
when the CSA is received, or it just switches and userspace gets a "CSA
will happen" event?

>  * disconnect non-complying interfaces that were
>    sharing a channel that is being abandoned by
>    channel switching interface(s),

Hmm, that sounds a bit the wrong way around? Shouldn't the CSA not be
possible (userspace CSA) or cause the switching interface to disconnect,
rather than *others*??

> - * @channel_switch: initiate channel-switch procedure (with CSA)
> + * @ch_switch_start: initiate channel-switch procedure (with CSA). This should
> + *	prompt the driver to perform preparation work (start some timers,
> + *	include CS IEs in beacons, etc) but don't do an actual channel switch.
> + *	Once driver has completed all preparations and is ready for the actual
> + *	switch (after CSA counter is completed) it must call
> + *	cfg80211_ch_switch_complete(wdev). After that ch_switch_finalize() MAY
> + *	be called, but it doesn't necessarily happen immediately as cfg80211
> + *	may need to synchronize with other interfaces. If channel switch is
> + *	cancelled for some reason ch_switch_finalize() is not called and driver
> + *	should free up resources/cleanup state in interface disconnection flow.
> + * @ch_switch_finalize: finalize channel-switch procedure, i.e. perform the
> + *	actual switch.

I don't like this at all. This totally assumes that every driver behaves
like mac80211, which clearly is not the case. The split between
"starting" and "finalizing" it should not be part of the API.

>  /**
> + * enum cfg80211_chsw_state - interface channel switch state
> + *
> + * @CHSW_STATE_NONE: channel switch is not active
> + * @CHSW_STATE_REQUESTED: channel switch has been requested but not processed
> + * @CHSW_STATE_STARTED: channel switch has been processed and accepted
> + * @CHSW_STATE_COMPLETED: channel switch has been scheduled for finalization
> + * @CHSW_STATE_SYNCING: interface is ready for channel to be re-programmed in
> + *	driver. Interface may remain in this state until some additional
> + *	requirements are met, i.e. wait until other channel switch requests on other
> + *	interfaces are synching as well.
> + */

This therefore doesn't belong into cfg80211, at least not all of it.

[snip rest that seemed pointless to look at now]

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




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux