Hi Simon,
On 8 July 2013 15:14, Simon Wunderlich
<simon.wunderlich@xxxxxxxxxxxxxxxxxxxx> wrote:
> +static int ieee80211_channel_switch(struct wiphy *wiphy, struct net_device *dev,
> + struct cfg80211_csa_settings *params)
> +{
> + struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
> + struct ieee80211_local *local = sdata->local;
> + struct ieee80211_chanctx_conf *chanctx_conf;
> + struct ieee80211_chanctx *chanctx;
> + int err;
> +
> + if (!list_empty(&local->roc_list) || local->scanning)
> + return -EBUSY;
> +
> + if (sdata->wdev.cac_started)
> + return -EBUSY;
> +
> + /* don't handle if chanctx is used */
> + if (local->use_chanctx)
> + return -EBUSY;
> +
> + rcu_read_lock();
> + chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
> + if (!chanctx_conf) {
> + rcu_read_unlock();
> + return -EBUSY;
> + }
> +
> + /* don't handle for multi-VIF cases */
> + chanctx = container_of(chanctx_conf, struct ieee80211_chanctx, conf);
> + if (chanctx->refcount > 1) {
> + rcu_read_unlock();
> + return -EBUSY;
> + }
> + rcu_read_unlock();
I'm wondering if it's a huge hassle to support drivers that depend on
channel context API? Perhaps local->open_count could be used instead
of local->use_chantx and chanctx->refcount?
I'm also worried this can possibly do silly things if someone starts
an interface while CSA is under way. Consider the following:
* start AP
* initiate channel switch
[ while channel switch is in progress and driver is yet to call
ieee80211_csa_finish() ]
* start another STA interface and associate
[ CSA completes ]
Upon CSA completion the STA will be moved to a different channel
silently and most likely end up with a beacon loss quickly. I think
mac80211 should forbid bringing up any new interfaces during CSA.
It seems there's nothing preventing from multiple calls to channel
switch callback. Is this expected? Can this work if CSA is invoked
while other CSA is still in progress?
Pozdrawiam / Best regards,
Michał 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
