On Mon, 2014-02-03 at 13:43 +0100, Johannes Berg wrote: > On Mon, 2014-02-03 at 10:58 +0100, Michal Kazior wrote: > > > The patchset aims at making cfg80211 aware of > > channel switches. > > That seems like a worthy goal :) I like the "awareness", but I don't like the control over channel switch so much. > > This makes it possible for more elegant channel > > switching behavior by moving the decision up to > > cfg80211. > > > > Until now mac80211 could start channel switching > > internally for STA, mesh and IBSS interfaces > > without userspace interaction. This bypassed > > interface combination checks at the very least. > > > > Now mac80211 requests cfg80211 to channel switch > > an interface, in a similar manner as userspace > > asks cfg80211 for a channel switch. This makes it > > possible to perform interface combination checks > > (albeit it is not implemented yet). > > Couldn't you just return the decision to mac80211? It would also have to > keep track of start/end of the CSA period, I guess, since a few things > that Ilan is working on shouldn't be allowed while the AP announces CSA. mac80211 could keep track of the start/finalize callbacks. But I don't think that's a good idea, as I mentioned in the other email. I think mac80211 should keep the client CSA control and the userspace should control the host interfaces. cfg80211 should keep track of the channel switches and be asked if the switch is okay (so it can take the interface combinations and regulatory into consideration). Maybe mac80211 could call a cfg80211_reserve_channel() function? If that call fails, it means the switch cannot be done. If it succeeds, cfg80211 keeps the reservation. Same thing if the switch is coming from userspace, nl80211 could call cfg80211_reserve_channel() in the same way. > > The channel switch is split into two phases now - > > start and finalize. This is required to make > > cfg80211 in control of the whole channel > > switching process. It also makes it apparent that > > mac80211's STA CSA offload doesn't work quite well > > here. Can we kill it? > > No. Well, you could make cfg80211 be in charge, but not wpa_supplicant, > I think. > > > The initial patchset has a lot of TODOs in the > > code and the idea is to provide follow up patches > > that implement missing functionality. > > > > Major drawback now is cfg80211 will refuse a > > channel switch if there's one in progress already, > > although this shouldn't be much of a problem in > > most use cases. > > > > This approach should be suited for multi-interface > > CSA as well as some other cases such as > > "GO-follows-STA". > > > > The patchset seemed to work in my limited testing > > (ath9k as AP and iwldvm as STA). > > Nice. I hope Luca can take a look too :) I did. :) Hopefully I have added good points and not only complicated things further. :P -- 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
