On 23 May 2014 08:16, Michal Kazior <michal.kazior@xxxxxxxxx> wrote:
> On 22 May 2014 16:51, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:
>> On Thu, 2014-05-22 at 16:07 +0200, Michal Kazior wrote:
>>> +static int
>>> +ieee80211_vif_use_reserved_incompat(struct ieee80211_local *local,
>>> + struct ieee80211_chanctx *ctx,
>>> + const struct cfg80211_chan_def *chandef)
>>> +{
>>> + struct ieee80211_sub_if_data *sdata, *tmp;
>>> + struct ieee80211_chanctx *new_ctx;
>>> + u32 changed = 0;
>>> + int err;
>>> +
>>> + lockdep_assert_held(&local->mtx);
>>> + lockdep_assert_held(&local->chanctx_mtx);
>>> +
>>> + if (!ieee80211_chanctx_all_reserved_vifs_ready(local, ctx))
>>> + return 0;
>>> +
>>> + if (ieee80211_chanctx_num_assigned(local, ctx) !=
>>> + ieee80211_chanctx_num_reserved(local, ctx)) {
>>> + wiphy_info(local->hw.wiphy,
>>> + "channel context reservation cannot be finalized because some interfaces aren't switching\n");
>>> + err = -EBUSY;
>>> + goto err;
>>> }
>>
>> I don't think I understand that condition, it's it possible to switch
>> from two vifs using two channels to both using a single third one?
>
> I assume you have a case where max number of different channels is
> degraded (e.g. non-radar -> more restrictive radar combination) in
> mind, right? In that case this won't work with this code. Now that I
> think about it it also won't work with cross-swapping (2 chanctx are
> being swapped and some vifs try to interchange between).
>
> I'll have to re-think this a bit more.
Actually I think I've just spotted a little problem. This is also
related to the `[PATCH v6 6/6] cfg80211: remove channel_switch
combination check` thread.
Currently mac80211 verifies interface combinations in channel_switch.
It has an implicit assumption that channel switch does not change the
number of different channels (or at least it doesn't decrease it).
We were discussing degradation of number of different channels
earlier, e.g. due to non-radar -> radar change (going from max 2
channels to 1). With how things are now it's impossible to perform
such a channel switch.
Basically if we want to support this kind of channel switch we must
remove interface combination checks from ieee80211_channel_switch
because it's simply impossible to know the future (userspace may or
may not submit subsequent requests to match an existing interface
combination).
So while I still intend to rework the multi-vif reservation a little
(to support cross-swapping at least) I'd like to know if I should
invest my time implementing degradation of number of channels in
multi-vif reservation or not.
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
