On Wed, 2014-01-22 at 11:13 +0100, Michal Kazior wrote: > > That seems pretty much fine, though I was talking to Luca yesterday and > > there is actually a case where a CSA chanctx should be usable later, for > > example if you have this: > > * managed mode interface receives a channel switch announcements and > > acts on it > > * it also sends an event to userspace (this is a TODO but we're on it) > > * wpa_s decides that a concurrent GO should also switch > > Hmm. This sounds interesting. But it makes me wonder.. > > If STA iface receives CSA it starts it right away? It doesn't care if > other interfaces are using a given channel context too? It just > assumes other intefaces may actively request channel switch and if > they do, the CSA will be 'aggregated/merged'? Well, in Luca's implementation a new channel context has to be available. In the current implementation, it will simply disconnect if using chanctx, or if there's any other interface using the channel (I believe) > What about cfg80211 intf combinations? If GO sends a channel switch it > will fail on num_available_channels unless you implicitly consider the > userspace event you mentioned or export CSA state down to cfg80211. Yeah, that's a good point, need to consider that. > At one point I was wondering if channel contexts should be actually > exposed in cfg80211. It would probably make it easier to coordinate > some CSA scenarios like this in a sane way, don't you think? But then > again that's quite big of a change. Yeah that'd be a bit of a change, but maybe it's worth it? Not sure. 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
