From: Jean-Pierre Tosoni <jp.tosoni@acksys.fr>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] [RFC v2] [resend] ath9k: allow up to 8 access point vifs on DFS channels
Date: Wed, 16 Sep 2015 10:27:02 -0000 [thread overview]
Message-ID: <000901d0f055$f5c46680$e14d3380$@acksys.fr> (raw)
In-Reply-To: <55F7EB74.30701@neratec.com>
Hi Matthias,
The patch is working for me, and I am using it, but I could not test
Much further since real-life radar situations are hard to produce.
Before DFS integration, combinations were less limited. I submitted
the patch as a RFC only, because I suspected the DFS people had a
hidden reason for limiting the combinations on radar channels.
However I received no comments.
Maybe I was on the wrong list. I will CC the ath9k maintainer now,
and try to submit a patch in a week or two.
Best regards
Jean-Pierre
> -----Message d'origine-----
> De?: Matthias May [mailto:matthias.may at neratec.com]
> Envoy??: mardi 15 septembre 2015 11:57
> ??: Jean-Pierre TOSONI; linux-wireless at vger.kernel.org
> Objet?: Re: [RFC v2] [resend] ath9k: allow up to 8 access point vifs on
> DFS channels
>
> On 09/06/15 18:26, Jean-Pierre TOSONI wrote:
> > Allow the combination of 8 (AP + mesh) interfaces on radar channels
> >
> > Tested with hostapd, 2 and 8 BSSIDs, 1 or 2 DFS channels, BW 20 MHz
> > TODO: test AP+mesh combination
> > TODO: test 40 MHz BW
> > ---
> > This patch was done with quilt on Openwrt against compat-wireless
> > 2014-11-04
> >
> > Any feedback?
> >
> > --- a/drivers/net/wireless/ath/ath9k/init.c
> > +++ b/drivers/net/wireless/ath/ath9k/init.c
> > @@ -723,6 +723,14 @@ static const struct ieee80211_iface_limi
> > BIT(NL80211_IFTYPE_ADHOC) },
> > };
> >
> > +static const struct ieee80211_iface_limit if_dfs_limits_mvap[] = {
> > + { .max = 8, .types =
> > +#ifdef CONFIG_MAC80211_MESH
> > + BIT(NL80211_IFTYPE_MESH_POINT) | #endif
> > + BIT(NL80211_IFTYPE_AP) },
> > +};
> > +
> > static const struct ieee80211_iface_combination if_comb[] = {
> > {
> > .limits = if_limits,
> > @@ -746,6 +754,16 @@ static const struct ieee80211_iface_comb
> > .num_different_channels = 1,
> > .beacon_int_infra_match = true,
> > .radar_detect_widths = BIT(NL80211_CHAN_WIDTH_20_NOHT)
> > |
> > + BIT(NL80211_CHAN_WIDTH_20) |
> > + BIT(NL80211_CHAN_WIDTH_40),
> > + },
> > + {
> > + .limits = if_dfs_limits_mvap,
> > + .n_limits = ARRAY_SIZE(if_dfs_limits_mvap),
> > + .max_interfaces = 8,
> > + .num_different_channels = 1,
> > + .beacon_int_infra_match = true,
> > + .radar_detect_widths = BIT(NL80211_CHAN_WIDTH_20_NOHT)
> > |
> > BIT(NL80211_CHAN_WIDTH_20) |
> > BIT(NL80211_CHAN_WIDTH_40),
> > }
> Hi
> This mail is in my list of "potentially interesting changes".
> Do you plan to send this as patch at some point?
> Or are you still testing something?
>
> Best regards
> Matthias
parent reply other threads:[~2015-09-16 10:27 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <55F7EB74.30701@neratec.com>]
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='000901d0f055$f5c46680$e14d3380$@acksys.fr' \
--to=jp.tosoni@acksys.fr \
--cc=ath9k-devel@lists.ath9k.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