All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Kazior <michal.kazior@tieto.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [RFC v3 7/7] mac80211: reuse channels for channel contexts
Date: Tue, 26 Jun 2012 15:55:35 +0200	[thread overview]
Message-ID: <4FE9BF57.6080100@tieto.com> (raw)
In-Reply-To: <1340718113.14634.45.camel@jlt3.sipsolutions.net>

Johannes Berg wrote:
> On Tue, 2012-06-26 at 14:37 +0200, Michal Kazior wrote:
>
>> +static enum nl80211_channel_type
>> +ieee80211_calc_chantype(struct ieee80211_local *local,
>> +			struct ieee80211_chanctx *ctx)
>> +{
>> +	struct ieee80211_chanctx_conf *conf = &ctx->conf;
>> +	struct ieee80211_sub_if_data *sdata;
>> +	enum nl80211_channel_type chantype = NL80211_CHAN_NO_HT;
>> +	enum nl80211_channel_type compat;
>> +
>> +	lockdep_assert_held(&local->chanctx_mtx);
>> +
>> +	rcu_read_lock();
>> +	list_for_each_entry_rcu(sdata, &local->interfaces, list) {
>> +		if (!ieee80211_sdata_running(sdata))
>> +			continue;
>> +		if (sdata->vif.chanctx_conf != conf)
>> +			continue;
>> +
>> +		BUG_ON(!ieee80211_channel_types_are_compatible(
>> +				conf->channel_type, chantype, &compat));
>
> Please no BUG_ON, maybe only WARN_ON_ONCE even?

Okay. I guess returning NL80211_CHAN_NO_HT in such case is okay.


>> +		chantype = compat;
>> +	}
>> +	rcu_read_unlock();
>> +
>> +	return chantype;
>> +}
>
> I don't think I understand this, wouldn't it need some per-vif requested
> channel type to work correctly? I don't see any chantype values coming
> from the sdata here, so I don't think this could work?
>
> If say vif1 needs ht40+ and vif2 ht20, the channel context will be set
> to ht40+, but then if vif1 goes away and you don't know anything about
> vif2 at all, then how can this work? The way I see it, your code here
> doesn't really do anything, except recalculate that ht40+ is compatible
> with ht40+, or something like that? I guess I'm a bit confused, it seems
> to me that this cannot work even in theory unless you have per-vif data.

It seems I must've had a mind-derp. I was planning on using 
sdata->vif.bss_conf.channel_type which should be ok, right?


>>   static void
>>   ieee80211_unassign_vif_chanctx(struct ieee80211_sub_if_data *sdata,
>>   			       struct ieee80211_chanctx *ctx)
>> @@ -248,6 +302,8 @@ ieee80211_unassign_vif_chanctx(struct ieee80211_sub_if_data *sdata,
>>
>>   	drv_unassign_vif_chanctx(sdata->local, sdata, ctx);
>>
>> +	ieee80211_recalc_chanctx_chantype(sdata->local, ctx);
>> +
>>   	ctx->refcount--;
>>   	sdata->vif.chanctx_conf = NULL;
>
> And then shouldn't you recalc *after* setting chanctx_conf = NULL so you
> skip this vif?

You're absolutely right.


-- 
Pozdrawiam / Best regards, Michal Kazior.


  reply	other threads:[~2012-06-26 13:55 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-26 12:37 [RFC v3] initial channel context implementation Michal Kazior
2012-06-26 12:37 ` [RFC v3 1/7] mac80211: introduce channel context skeleton code Michal Kazior
2012-06-26 12:37 ` [RFC v3 2/7] mac80211: introduce new ieee80211_ops Michal Kazior
2012-06-26 12:37 ` [RFC v3 3/7] mac80211: add drv_* wrappers for channel contexts Michal Kazior
2012-06-26 12:37 ` [RFC v3 4/7] mac80211: add chanctx tracing Michal Kazior
2012-06-26 12:37 ` [RFC v3 5/7] mac80211: use channel context notifications Michal Kazior
2012-06-26 13:35   ` Johannes Berg
2012-06-26 14:01     ` Michal Kazior
2012-06-26 15:34       ` Johannes Berg
2012-06-26 12:37 ` [RFC v3 6/7] mac80211: refactor set_channel_type Michal Kazior
2012-06-26 14:04   ` Eliad Peller
2012-06-26 12:37 ` [RFC v3 7/7] mac80211: reuse channels for channel contexts Michal Kazior
2012-06-26 13:41   ` Johannes Berg
2012-06-26 13:55     ` Michal Kazior [this message]
2012-06-26 15:34       ` Johannes Berg
2012-06-26 13:43 ` [RFC v3] initial channel context implementation Johannes Berg
2012-06-27  7:30   ` Michal Kazior
2012-06-27  8:10     ` Johannes Berg
2012-06-27 10:13       ` Michal Kazior
2012-06-27 11:10         ` Johannes Berg
2012-06-27 12:43           ` Michal Kazior
2012-06-27 14:02             ` Johannes Berg
2012-06-28  6:04               ` Michal Kazior
2012-06-28  7:31                 ` Johannes Berg
2012-06-28  7:54                   ` Michal Kazior
2012-06-28  8:13                     ` Johannes Berg
2012-06-28  9:20                       ` Michal Kazior
2012-06-28  9:27                         ` Johannes Berg
2012-06-28  9:47                           ` Michal Kazior
2012-06-28  7:01               ` Michal Kazior
2012-06-28  8:15                 ` Johannes Berg
2012-06-28  8:54                   ` Michal Kazior
2012-06-28  9:27                     ` Johannes Berg
2012-07-25 10:22 ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FE9BF57.6080100@tieto.com \
    --to=michal.kazior@tieto.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.