On Wed, 2014-02-05 at 14:11 +0200, Luca Coelho wrote: > It's the same if the STA CSA would be "started" in the userspace. If > the remote AP sets a too short count, the userspace won't have the > chance to react. In either case, we would have to send a notification > to the userspace and it would have to tell us what to do. If we wait > for the userspace to react on our STA CSA, we will be too late on both > interfaces. If mac80211 does the STA CSA directly, at least the STA CSA > will be done on time and the GO can move a bit later (or get > disconnected if we were short on chanctx's). I don't think the GO would get disconnected, rather the STA would, no? > > The purpose of ch_switch_finalize() is to perform the final switch > > atomically and make sure non-complying interfaces are disconnected > > before channel is actually switched (this could include Ilan's GO case > > in a clean way). > > I was thinking about eventual drivers that offload the whole channel > switch process to the firmware. The driver just sends the count, the > new channel and everything and the firmware takes care of it all. It > will beacon for count TBTTs and perform the actual channel switch at the > right time. In this case, all the decision making about what needs to > be disconnected or switched must be made at the beginning. > > But I'll let Johannes comment more. ;) Yes, I'm pretty sure that this kind of situation will happen sooner or later, so preventing it in the APIs right now seems like a bad idea. 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
