From: Johannes Berg <johannes@sipsolutions.net>
To: Ilan Peer <ilan.peer@intel.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH 2/2] [RFC] mac80211: Add all enabled channels to the supported channels element
Date: Tue, 07 Jan 2014 16:30:09 +0100 [thread overview]
Message-ID: <1389108609.4645.10.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <1388503946-25862-3-git-send-email-ilan.peer@intel.com> (sfid-20131231_163100_337930_7D3482AD)
On Tue, 2013-12-31 at 17:32 +0200, Ilan Peer wrote:
> + chan =
> ieee80211_frequency_to_channel(center_freq);
> +
> + if (first_chan == 0) {
> + /* first subband */
> + first_chan = chan;
> + count = 1;
> + } else if (first_chan + count == chan) {
> + /* continue the subband.
> + * TODO: this is really only useful
> for 2.4,
> + * need to add spacing considerations for other
> + * bands as well (the definition of a
> subband
> + * in the 802.11 spec. is a bit
> vague).
> + */
> + count++;
I agree this is very vague - anyone have a good idea who to ask?
As it is now, I'm not sure it's correct at all, even in the version we
have today, since different operating classes could have different
requirements. Especially since we support 5/10 MHz now, I suspect even
ieee80211_frequency_to_channel() really should be taught about operating
classes in some form?
> + /* Get the number of enabled channels for spectrum management */
> + n_channels = ieee80211_get_num_enabled_channels(local->hw.wiphy);
I would prefer you did this with an upper bound rather than the number
of enabled channels - we don't need a good estimate, worst case we'll
allocate a few bytes too many, but if we get it completely wrong e.g.
because the channel flags are being changed, then we could overrun the
SKB allocation, I think?
It'd also be faster to iterate only the bands and add up n_channels
rather than checking each channel's enabled bit.
johannes
next prev parent reply other threads:[~2014-01-07 15:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-31 15:32 [PATCH 0/2] modify the inclusion of supported channels IE Ilan Peer
2013-12-31 15:32 ` [PATCH 1/2] cfg80211: Add a function to get the number of enabled channels Ilan Peer
2014-01-09 9:17 ` [PATCH 1/2 v2] cfg80211: Add a function to get the number of supported channels Ilan Peer
2014-01-09 9:18 ` Johannes Berg
2014-01-09 9:18 ` Johannes Berg
2014-01-09 9:37 ` [PATCH 1/2 v3] " Ilan Peer
2014-01-09 12:57 ` Johannes Berg
2013-12-31 15:32 ` [PATCH 2/2] [RFC] mac80211: Add all enabled channels to the supported channels element Ilan Peer
2013-12-31 15:33 ` Peer, Ilan
2014-01-07 15:30 ` Johannes Berg [this message]
2014-01-09 7:42 ` Peer, Ilan
2014-01-09 9:18 ` [PATCH 2/2 v2] [RFC]mac80211: " Ilan Peer
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=1389108609.4645.10.camel@jlt4.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=ilan.peer@intel.com \
--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.