All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Michal Kazior <michal.kazior@tieto.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	Bing Zhao <bzhao@marvell.com>, Kalle Valo <kvalo@adurom.com>
Subject: Re: [RFC 07/14] cfg80211: track monitor interfaces count
Date: Wed, 06 Jun 2012 13:53:01 +0200	[thread overview]
Message-ID: <1338983581.26346.2.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <4FCF41AA.9070400@tieto.com>

On Wed, 2012-06-06 at 13:40 +0200, Michal Kazior wrote:
> Johannes Berg wrote:
> > The other thing we might then want to is make this more general and not
> > just inform the driver about the monitor/no-monitor layout change, but
> > also tell it which interface combination we're in right now? Might look
> > a bit more like
> >
> > set_iface_combination(wiphy, dev, combination);
> >
> > or even
> > set_iface_combination(wiphy, dev, combination, have_monitor);
> >
> >
> > Then pure monitor would be "combination == NULL, have_monitor=True",
> > etc. The only downside is that we don't have combinations advertised for
> > when there's a single interface only, so we'd have to point to some
> > internal single-interface combinations then (static in cfg80211).
> > Thoughts?
> 
> I'm afraid we can't simply tell which combination we're in. I imagine 
> there may be two or three combinations matching at the same time. Take 
> this for example:
> 
>    comb1: 1xSTA + 1xAP (max channels = 1)
>    comb2: 2xSTA (max channels = 2)
> 
>    wlan0 is running as STA @ chan=1
> 
> Which combination are we in? Which one should we report to the driver?

Doesn't matter, right? Pick the one with most channels or something? :-)

> I don't see what passing current interface combination would be useful 
> for. Do you have something particular in mind?

I'm thinking about # of channels in the combination mostly, in
particular in combination with IBSS. OTOH, if we always reserve one
channel for IBSS in cfg80211 (unless it's fixed & driver supports that)
then it won't matter.

But then again, what about say 2xSTA being active and drivers with
connect() API?

johannes


  reply	other threads:[~2012-06-06 11:53 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-28 11:18 [RFC] multi-channel work Michal Kazior
2012-05-28 11:18 ` [RFC 01/14] cfg80211: respect intf combinations for 1 interface Michal Kazior
2012-06-06  8:51   ` Johannes Berg
2012-06-06  8:56     ` Michal Kazior
2012-06-06  9:02       ` Johannes Berg
2012-05-28 11:18 ` [RFC 02/14] cfg80211: check iface combinations only when intf is running Michal Kazior
2012-06-06  8:52   ` Johannes Berg
2012-05-28 11:18 ` [RFC 03/14] cfg80211: introduce cfg80211_stop_ap Michal Kazior
2012-06-06  8:54   ` Johannes Berg
2012-05-28 11:18 ` [RFC 04/14] cfg80211: .stop_ap when interface is going down Michal Kazior
2012-06-06  8:54   ` Johannes Berg
2012-05-28 11:18 ` [RFC 05/14] cfg80211: add channel tracking for AP and mesh Michal Kazior
2012-06-06  8:55   ` Johannes Berg
2012-05-28 11:18 ` [RFC 06/14] cfg80211: introduce cfg80211_get_used_channel Michal Kazior
2012-06-06  8:57   ` Johannes Berg
2012-05-28 11:18 ` [RFC 07/14] cfg80211: track monitor interfaces count Michal Kazior
2012-05-29 14:13   ` Eliad Peller
2012-06-06  9:10   ` Johannes Berg
2012-06-06 11:40     ` Michal Kazior
2012-06-06 11:53       ` Johannes Berg [this message]
2012-06-07  2:46     ` Bing Zhao
2012-05-28 11:18 ` [RFC 08/14] mac80211: refactor virtual monitor code Michal Kazior
2012-06-06  8:58   ` Johannes Berg
2012-06-06  8:59     ` Johannes Berg
2012-06-06  9:11   ` Johannes Berg
2012-05-28 11:18 ` [RFC 09/14] cfg80211: refuse to .set_monitor_channel when non-monitors are present Michal Kazior
2012-06-06  9:11   ` Johannes Berg
2012-05-28 11:18 ` [RFC 10/14] cfg80211: track monitor channel Michal Kazior
2012-06-06  9:13   ` Johannes Berg
2012-05-28 11:18 ` [RFC 11/14] cfg80211/mac80211: remove .get_channel Michal Kazior
2012-06-06  9:14   ` Johannes Berg
2012-05-28 11:19 ` [RFC 12/14] cfg80211: move devlist locking out of can_change_interface Michal Kazior
2012-05-28 11:19 ` [RFC 13/14] cfg80211: extend combination checking to consider channels Michal Kazior
2012-05-29 14:21   ` Eliad Peller
2012-06-06  9:18   ` Johannes Berg
2012-05-28 11:19 ` [RFC 14/14] cfg80211: respect iface combinations when starting operation Michal Kazior
2012-05-29 14:52   ` Eliad Peller
2012-06-06  9:20   ` Johannes Berg
2012-05-29  7:04 ` [RFC] multi-channel work Johannes Berg
2012-05-29  7:09   ` Michal Kazior
2012-06-06  9: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=1338983581.26346.2.camel@jlt3.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=bzhao@marvell.com \
    --cc=kvalo@adurom.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=michal.kazior@tieto.com \
    /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.