On 26 September 2014 21:35, Luca Coelho <[email protected]> wrote:
> From: Luciano Coelho <[email protected]>
>
> Instead of immediately reopening the queues (in case of block_tx),
> calling the post_channel_switch operation and sending the
> notification, wait for the first beacon on the new channel.  This
> makes sure that we don't lose packets if the AP/GO is not on the new
> channel yet.
>
> Signed-off-by: Luciano Coelho <[email protected]>
[...]

Just a few nitpicks from me:

> +static void ieee80211_chswitch_post_beacon(struct ieee80211_sub_if_data 
> *sdata)
> +{
> +       struct ieee80211_local *local = sdata->local;
> +       struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
> +       int ret;
> +
> +       sdata_assert_lock(sdata);
>

I was thinking about WARN_ON(!sdata->vif.csa_active) here. csa_active
should be set in all cases if csa_waiting_bcn is set, no?


> -       /* XXX: wait for a beacon first? */
>         if (sdata->csa_block_tx) {
>                 ieee80211_wake_vif_queues(local, sdata,
>                                           IEEE80211_QUEUE_STOP_REASON_CSA);
>                 sdata->csa_block_tx = false;
>         }
>
> +       sdata->vif.csa_active = false;
> +       ifmgd->csa_waiting_bcn = false;
> +
>         ret = drv_post_channel_switch(sdata);
>         if (ret) {
>                 sdata_info(sdata,
>                            "driver post channel switch failed, 
> disconnecting\n");
>                 ieee80211_queue_work(&local->hw,
>                                      &ifmgd->csa_connection_drop_work);
> -               goto out;
> +               return;
>         }
>       <---- here
> -       ieee80211_sta_reset_beacon_monitor(sdata);
> -       ieee80211_sta_reset_conn_monitor(sdata);
> -
> -out:
> -       mutex_unlock(&local->chanctx_mtx);
> -       mutex_unlock(&local->mtx);
> -       sdata_unlock(sdata);
>  }

Is that an empty line I before final `}`?


MichaƂ
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to