[PATCH] cfg80211: Add new fields to wiphy structure

[PATCH] cfg80211: Add new fields to wiphy structure

[Amar Singhal]

A channel is completely defined by (oper_class, channel number) tuple,
and not just by center frequency. Operating class also tells about the
bandwidth supported by the channel. Therefore add the operating class and
channel number to the wiphy structure.

Signed-off-by: Amar Singhal <asinghal@codeaurora.org>
---
 include/net/cfg80211.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 2d17e32..6467b60 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -129,6 +129,8 @@ enum ieee80211_channel_flags {
  * with cfg80211.
  *
  * @center_freq: center frequency in MHz
+ * @oper_class: global operating class for the channel
+ * @chan_num: channel number per IEEE operating class Annex E Table E-4
  * @hw_value: hardware-specific value for the channel
  * @flags: channel flags from &enum ieee80211_channel_flags.
  * @orig_flags: channel flags at registration time, used by regulatory
@@ -150,6 +152,8 @@ enum ieee80211_channel_flags {
 struct ieee80211_channel {
 	enum nl80211_band band;
 	u32 center_freq;
+	u8 oper_class;
+	u8 chan_num;
 	u16 hw_value;
 	u32 flags;
 	int max_antenna_gain;
--
1.9.1

Re: [PATCH] cfg80211: Add new fields to wiphy structure

[Johannes Berg]

On Thu, 2019-08-29 at 15:09 -0700, Amar Singhal wrote:
> A channel is completely defined by (oper_class, channel number) tuple,
> and not just by center frequency. Operating class also tells about the
> bandwidth supported by the channel. Therefore add the operating class and
> channel number to the wiphy structure.

We don't split out the channels that way, so this doesn't seem like the
right approach.

Instead, we list the *frequencies*, and then have flags for the
permitted bandwidths. We already support things like "no-HT40+" and
could possibly extend that to others, if it were _really_ possible,
though in practice those limitations are usually not present in devices,
just in the spec, and we can rely on hostapd/wpa_s to take care of them.

Even if you do have those limitations, this isn't the right way to go
about it, because it'll be very confusing to userspace to see the same
frequency multiple times. It'd also cause a bunch of problems with
scanning (listing the same channel twice) etc.

Since you haven't explained why you want to do this I cannot offer any
further guidance, but this cannot be the right approach.

johannes