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] initial channel context implementation
Date: Wed, 27 Jun 2012 12:13:02 +0200 [thread overview]
Message-ID: <4FEADCAE.5080508@tieto.com> (raw)
In-Reply-To: <1340784614.8305.8.camel@jlt3.sipsolutions.net>
Johannes Berg wrote:
> On Wed, 2012-06-27 at 09:30 +0200, Michal Kazior wrote:
>
>>> How are you planning to proceed from here? I'm happy to pick these up
>>> even if you're not going to work on using it right away since I think in
>>> that case I would probably be working on using it pretty soon, but if
>>> you are planning to work on it that's even better :-)
>>
>> The next step is to start using channel contexts in mac80211. I was
>> thinking of using chanctx->channel instead of hw.conf.channel if
>> .assign_vif_chanctx is defined. I expect some issues like using channel
>> before it is set.
>
> Ok. Thinking about this a bit I get a feeling that we should internally
> fully convert mac80211 over to channel contexts and not make things
> conditional. Then, whenever a new channel context is allocated it will
> be the only one and we can set hw.conf.channel/type to its channel(type)
> and call hw_config() instead of ... add/change chanctx?
>
> That way, we really only need to make a distinction in the low-level
> code that actually calls into the driver, and on a higher level we can
> just use the channel contexts everywhere.
But wouldn't that make hw.conf.channel have a different value then the
channel context after running hw_config() (in case of sw scan for
example)? You want to copy the value back from hw.conf.channel back to
(an immutable) context channel in such a case? Could you elaborate more
on this, please?
> The biggest issue here will be CSA handling. I have no idea yet how this
> will work in multi-channel, maybe we need to disconnect all other
> interfaces on the same channel, or so?
We don't care about CSA in cfg80211 right now, do we? We probably should
as it can break interface combinations right now too. We could maybe use
the cfg80211_ch_switch_notify. This would probably require some more
additional changes too (maybe with regard to channel tracking too).
Worst-case we disconnect other interfaces. We might be able to create a
new channel context (provided num_different_channels hasn't been reached
yet) or reuse an existing channel context (provided CSA happens to
target a channel we have a channel context for already).
--
Pozdrawiam / Best regards, Michal Kazior.
next prev parent reply other threads:[~2012-06-27 10:13 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
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 [this message]
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=4FEADCAE.5080508@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).