From: Luca Coelho <luca@coelho.fi>
To: Michal Kazior <michal.kazior@tieto.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>,
Johannes Berg <johannes@sipsolutions.net>,
"sw@simonwunderlich.de" <sw@simonwunderlich.de>,
"Otcheretianski, Andrei" <andrei.otcheretianski@intel.com>,
Eliad Peller <eliad@wizery.com>
Subject: Re: [PATCH v10 3/5] cfg80211/mac80211: move interface counting for combination check to mac80211
Date: Tue, 18 Mar 2014 10:44:08 +0200 [thread overview]
Message-ID: <1395132248.15856.21.camel@dubbel> (raw)
In-Reply-To: <CA+BoTQn5dB8-4U0X+_GX_J7rDctTpCWg8ydjSQbrEjMB28NKEA@mail.gmail.com>
On Tue, 2014-03-18 at 09:36 +0100, Michal Kazior wrote:
> On 18 March 2014 09:13, Coelho, Luciano <luciano.coelho@intel.com> wrote:
> > On Fri, 2014-03-14 at 09:40 +0100, Michal Kazior wrote:
> >> On 11 March 2014 15:16, Luciano Coelho <luciano.coelho@intel.com> wrote:
>
> [...]
>
> >> > + list_for_each_entry(ctx, &local->chanctx_list, list) {
> >> > + if (ctx->conf.radar_enabled)
> >> > + radar_detect |= BIT(ctx->conf.def.width);
> >>
> >> Is this really correct?
> >
> > I'm not sure anymore. :)
> >
> >
> >> The original behaviour was to:
> >>
> >> for each wdev:
> >> get_chan_state(..., &radar_width)
> >>
> >> where get_chan_state() ORs BIT(width) accordingly to iftype, etc.
> >>
> >> For 2 APs with different operational widths (e.g. 20 and 40) this means:
> >>
> >> a) old code: width_detect = BIT(WIDTH_20) | BIT(WIDTH_40)
> >> b) new code: width_detect = BIT(chanctx->width) which is BIT(WIDTH_40)
> >>
> >> I think radar_detect should be computed:
> >>
> >> radar_detect = 0 // **
> >> for each vif:
> >> if vif.ctx == ctx && vif.radar_required:
> >> radar_detect = BIT(vif.bss.width)
> >>
> >> ** you could argue to initialize with BIT(ctx->width), but all things
> >> seem to use ieee80211_vif_use_channel() (including CAC/radar
> >> detection) so bss_conf.chandef.width should be set correctly and
> >> iteration alone should suffice.
> >
> > But does this really make sense? This was more or less the idea I had
> > when I changed the cfg80211_chandef_dfs_required() to return a bit mask
> > (which I later reverted).
> >
> > I think the current behavior may be wrong. In the old
> > cfg80211_can_use_iftype_chan() we match *any* of the bits in
> > radar_detect with the bits supported in the interface combinations. So,
> > in your example, we would accept the combination even if the driver did
> > not support WIDTH_40 (because it would match WIDTH_20). If the context
> > is set to WIDTH_40, don't we have to make sure the driver can detect
> > radars on that width?
>
> Fair point, but current behaviour of cfg80211_can_use_iftype_chan()
> doesn't seem like a correct one to me. It shouldn't match any but
> *all* of the radar_detect bits, no?
I don't really know. I think that if we're using 40MHz, we need to be
able to detect on the entire 40MHz, and that includes the 20MHz part as
well. So being able to detect on 20MHz in that same channel context is
irrelevant, isn't it?
I think the current cfg80211_can_use_iftype_chan() is wrong because it
allows narrow bandwidths to pass the test, even if we're using wider
ones.
--
Luca.
next prev parent reply other threads:[~2014-03-18 8:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-11 14:16 [PATCH v10 0/5] cfg80211/mac80211: move interface combinations check to mac80211 Luciano Coelho
2014-03-11 14:16 ` [PATCH v10 1/5] cfg80211: refactor cfg80211_can_use_iftype_chan() Luciano Coelho
2014-03-11 14:16 ` [PATCH v10 2/5] cfg80211/mac80211: refactor cfg80211_chandef_dfs_required() Luciano Coelho
2014-03-11 14:16 ` [PATCH v10 3/5] cfg80211/mac80211: move interface counting for combination check to mac80211 Luciano Coelho
2014-03-14 8:40 ` Michal Kazior
2014-03-18 8:13 ` Coelho, Luciano
2014-03-18 8:36 ` Michal Kazior
2014-03-18 8:44 ` Luca Coelho [this message]
2014-03-18 8:58 ` Michal Kazior
2014-03-18 9:24 ` Luca Coelho
2023-01-09 9:39 ` Wen Gong
2023-01-09 10:05 ` Johannes Berg
2023-01-10 7:23 ` Wen Gong
2023-02-14 14:41 ` Johannes Berg
2023-02-15 1:56 ` Wen Gong
2014-03-11 14:16 ` [PATCH v10 4/5] cfg80211/mac80211: move combination check to mac80211 for ibss Luciano Coelho
2014-03-11 14:16 ` [PATCH v10 5/5] cfg80211/mac80211: move more combination checks to mac80211 Luciano Coelho
2014-03-19 14:01 ` [PATCH v10 0/5] cfg80211/mac80211: move interface combinations check " Luca Coelho
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=1395132248.15856.21.camel@dubbel \
--to=luca@coelho.fi \
--cc=andrei.otcheretianski@intel.com \
--cc=eliad@wizery.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=michal.kazior@tieto.com \
--cc=sw@simonwunderlich.de \
/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).