Hi, Sorry for coming to this a bit late, but hopefully not too late. ;) On Mon, 2014-01-20 at 15:09 +0100, Michal Kazior wrote: > This extends NL80211_CMD_CHANNEL_SWITCH by adding > a new attribute NL80211_ATTR_CH_SWITCH_IFACES. The > attribute holds an array of CSA attributes. Each > entry holds attributes that were used until now: > ifindex, chandef, blocktx, beacon/proberesp. Why is this necessary? I think it's easier to treat the CSA's separately. When wpa_supplicant decides to switch channel in one interface, it asks cfg80211 to do so. Then, if that interface change is "approved" (ie. there's no internal reason why it would fail), cfg80211 sends a notification to userspace that the interface will switch. Then wpa_s decides whether any other interfaces need switching as well (ie. if it's in the same channel context). > The new attribute is used as a flag in > send_wiphy() and a driver may advertise the > capability with WIPHY_FLAG_HAS_MULTI_IF_CHSWITCH. > > Userspace may now submit CSA in the old way or > with the new attribute set. If the new attribute > is set attributes outside the nested attribute are > ignored. > > This makes it possible for userspace to request a > multi-interface channel switch while allowing > sanity checks wrt target interface/channel > combination. Okay, the sanity checks are an interesting issue. But if the combination is not good, the whole command will fail and none of the interfaces will switch. If wpa_s does this interface-by-interface, separately, the triggering interface (ie. the one that decided to switch in the first place) may succeed while the subsequent requests may fail (eg. if the interface combination is not allowed in the new channel). If the second one fails, wpa_s may make another decision, for instance trying to switch the second interface to a *different* channel instead, or not switch at all. I think this approach makes things more flexible and simpler. -- 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
