Hi Johannes, I've done some work on channel contexts. It's based on your recently posted patches (set_channel, join_mesh, etc). This is course for multi-channel operation. This isn't ready/complete yet. Channel selection is unsafe because the for() shouldn't be limited to the IEEE80211_MAX_CHANNEL_CONTEXTS. It should be limited by the maximum number of different channels for a matching interface combination during runtime. This however seems to be a bit tricky right now. I've looked at your cfg80211-enforce-beacon_int_infra_match.patch but the cfg80211_find_current_combination ignores the fact that an interface may be up and running without a channel contexts being bound (i.e. without an association whatsoever). For this to work we need to know whether a given interface is really running/operational for tx. I've thought about using netif_carrier_on/off for this purpose but I'm not sure whether we can use it for our purpose. Other idea is to create a new function that would be able to tell us whether an interface is using a channel. But what would that be based on? Can we check that easily for all interface types (monitor)? My current idea is to make channel contexts work alongside what we have today. Old drivers would remain to use current structures (oper_channel, hw.conf.channel, etc), new ones or the ones wanting to support multi-channel would switch to channel contexts. -- Pozdrawiam / Best regards, Michal Kazior. -- 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