On 28 February 2014 13:23, Luca Coelho <luca@xxxxxxxxx> wrote:
[...]
> +int ieee80211_vif_reserve_chanctx(struct ieee80211_sub_if_data *sdata,
> + const struct cfg80211_chan_def *chandef)
> +{
> + struct ieee80211_local *local = sdata->local;
> + struct ieee80211_chanctx_conf *conf;
> + struct ieee80211_chanctx *new_ctx, *curr_ctx;
> + int ret = 0;
> +
> + mutex_lock(&local->chanctx_mtx);
> +
> + conf = rcu_dereference_protected(sdata->vif.chanctx_conf,
> + lockdep_is_held(&local->chanctx_mtx));
> + if (!conf) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + curr_ctx = container_of(conf, struct ieee80211_chanctx, conf);
> +
> + /* try to find another context with the chandef we want */
> + new_ctx = ieee80211_find_chanctx(local, chandef,
> + IEEE80211_CHANCTX_SHARED);
I find one thing puzzling -- why is ieee80211_find_chanctx() calling
ieee80211_change_chanctx()? I don't think it makes sense. I can't
understand why chanctx has two chandefs (isn't min_def enough
already?).
> + /* TODO: we're assuming that the bandwidth of the context
> + * changes here, but in fact, it will only change if the
> + * combination of the channels used in this context change.
> + * We should set this flag according to what happens when
> + * ieee80211_recalc_chanctx_chantype() is called. Maybe the
> + * nicest thing to do would be to change that function so that
> + * it returns changed flags (which will be either 0 or
> + * BSS_CHANGED_BANDWIDTH).
> + */
I don't understand this. Either I'm missing something here or we had a
misunderstanding earlier. It doesn't matter what chanctx width we end
up with. What's important is the BSS width here and it's readily
available to check & use.
> +
> + if (sdata->vif.bss_conf.chandef.width != ctx->conf.def.width)
> + local_changed |= BSS_CHANGED_BANDWIDTH;
This should use sdata->reserved_chandef.width instead of
ctx->conf.def.width, shouldn't it?
Michał
--
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
