On Mon, 2014-02-03 at 14:41 +0100, Johannes Berg wrote: > 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) I agree that this shouldn't be needed for client (ie. P2P client or managed) interfaces. > > * 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? How do we get the "target" beacon from userspace if the interface just switches? Now a bit of brain burp: I think that the "count" decision should remain in the userspace so it can decide to give more time for its stations to switch. Eg. if the client interface got a CSA with count == x and a host interface has dtim_interval > x, the userspace can send a "quiet" CSA with count == dtim_interval + 1. The two requests would be "merged" and the highest count would win. The client would be a bit late on the new channel, but at least the AP wouldn't lose most of its clients. Does this make any sense? I'm not sure myself. :) > > * 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*?? It depends. And this logic is too complicated to stay in the kernel, IMHO. If we are in a GO-follows-STA scenario, we want to disconnect the GO. Now, if you have an AP (with tons of STAs connected to it) and a P2P client gets a CSA for whatever reason, do we really want to stop the AP? > > - * @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. I agree, especially if the driver offloads the channel switch, in which case it wouldn't be possible for cfg80211 to hold the finalize call to sync all the interfaces. -- Luca. -- 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
