Add central regulatory domain agent - Patchset I

Patchset I - Add central regulatory domain agent

This is patchset I of II which adds a central regulatory domain agent onto the wireless subsystem. I've split it into two patchsets in order to introduce the agent before affecting mac80211 drivers. This allows work to continue on the central reg agent independant of mac80211 advancements.

Patch series I adds the central regulatory domain agent and integrates it with cfg80211. The central reg agent consists of 2 main modules:

* ISO3166-1
* Regdomains

Additionally, changing regulatory domains can be acomplished through the use of a new configfs module which will be introduced for the wireless subsystem.

Patch series II will add support for the centreal reglatory agent onto mac80211, remove mac80211's simple regulatory control and and replace each driver's own regulatory domain implementation with the central one.

Luis

Patchset I - Add central regulatory domain agent

This is patchset I of II which adds a central regulatory domain agent onto the wireless subsystem. I've split it into two patchsets in order to introduce the agent before affecting mac80211 drivers. This allows work to continue on the central reg agent independant of mac80211 advancements.

Patch series I adds the central regulatory domain agent and integrates it with cfg80211. The central reg agent consists of 2 main modules:

* ISO3166-1
* Regdomains

Additionally, changing regulatory domains can be acomplished through the use of a new configfs module which will be introduced for the wireless subsystem.

Patch series II will add support for the centreal reglatory agent onto mac80211, remove mac80211's simple regulatory control and and replace each driver's own regulatory domain implementation with the central one.

Luis

+ * @IEEE80211_CHAN_W_SCAN: if this flag is set it informs the lower layer that
+ * this channel can be passively scanned for.

+/**
+ * ieee80211_channel - internal structure definiton for an IEEE-802.11 channel
+ *
+ * This defines an ieee80211_channel. The IEEE-802.11 regulatory domain agent
+ * is in charge of filling most of these fields out. The low-level driver
+ * is expected to fill in, if needed, the val field. Note that val is already
+ * set by the regulatory agent to the same channel as in chan.

+ * @modulation_cap: could be IEEE80211_RATE_*

+ * @list: lets you make this structure part of a linked list

+/* XXX consider removing the holes bellow */

+/**
+ * enum rate_flags - internal &ieee80211_rate flags

+ * Use these flags to indicate to the lower layers details about an
+ * &ieee80211_rate.

+ * @IEEE80211_RATE_ERP: indicates if the rate is an Extended Rate PHY (ERP)
+ * @IEEE80211_RATE_BASIC: indicates the rate is a basic rate for the
+ * currently used mode
+ * @IEEE80211_RATE_PREAMBLE2: used to indicates that the rate for short
+ * preamble is to be used. This is set in &ieee80211_rate's @val2.

+ * @IEEE80211_RATE_SUPPORTED: indicates if rate is supported by the given mode

+ * @IEEE80211_RATE_OFDM: indicates support for ODFM modulation
+ * @IEEE80211_RATE_CCK: indicates support for CCK modulation

+ * @IEEE80211_RATE_MANDATORY: indicates if this rate is mandatory for the
+ * currently used mode

+/* XXX move to inline and add documenation, kernel-doc can't doc defines */

+ * Low-level driver should set PREAMBLE2, OFDM and CCK flags.
+ * BASIC, SUPPORTED, ERP, and MANDATORY flags are set in 80211.o based on the
+ * configuration.

+ * @flags: IEEE80211_RATE_* flags
+ * @val2: hw specific value for the rate when using short preamble
+ * (only when IEEE80211_RATE_PREAMBLE2 flag is set, i.e., for
+ * 2, 5.5, and 11 Mbps)

+ * @min_rssi_ack: Minimum required RSSI of packet to generate an ACK ??
+ * @min_rssi_ack_delta: ??

+/**
+ * struct ieee80211_subband_restrictions - defines a regulatory domain
+ * subband restrictions list

+ * @name: name for this subband.

+ * @min_freq: minimum frequency for this subband, in MHz. This represents the
+ * center of frequency of a channel.
+ * @max_freq: maximum frequency for this subband, in MHz. This represents the
+ * center of frequency of a channel.

include/net/ieee80211_regdomains.h new file +5 -0

+struct ieee80211_subband_restrictions {
+	u8 band;
+	char name[REGSBNAMSIZ];
+	u16 min_freq;
+	u16 max_freq;

+/**
+ * struct ieee80211_regdomain - defines a regulatory domain
+ *
+ * @regdomain_id: ID of this regulatory domain. Some come from
+ * http://standards.ieee.org/getieee802/download/802.11b-1999_Cor1-2001.pdf
+ * @regdomain_name: name of this regulatory domain.

+ * @list: node, part of band_restrictions_list
+ *
+ * This structure defines a regulatory domain, which consists of channel and
+ * power restrictions. Some regulatory domains come from
+ * 802.11b-1999_Cor1-2001, the rest are based on Reyk Floeter's ar5k. If
+ * there is need to add more values here, please add one that is either
+ * defined in a standard or that many hardware devices have adopted. Also
+ * note that multiple countries can map to the same @regdomain_id

+ * This structure holds the mapping of the country to a specific regulatory
+ * domain. Keep in mind more than one country can map to the same regulatory
+ * domain. The ISO-3166-1 alpha2 country code also happens to be used in the
+ * 802.11d Country Information Element on the string for the country. It
+ * should be noted, however, that in that the size of this string, is
+ * three octects while our string is only 2. The third octet is used to
+ * indicate Indoor/outdoor capabilities which we set in
+ * @ieee80211_subband_restrictions environment_cap.
+ */

+u16 regdomain_ieee2mhz(u16 chan, u8 band);

+void print_regdomain(struct ieee80211_regdomain *);

+void print_iso3166_reg_map(void);

+int get_ieee80211_regname(u32, char *);

On Fri, 2007-09-21 at 17:00 -0400, Luis R. Rodriguez wrote:

Ok one thing up front: I'm looking at this basically as "new code", iow something we should do right from the start. mac80211 stuff is a mess, so imho we should clean it up at this point when we break things anyway.

Quoted 2 lines

+ * @IEEE80211_CHAN_W_SCAN: if this flag is set it informs the lower layer that
+ * this channel can be passively scanned for.

Are there really channels that don't have _SCAN?

Quoted 7 lines

+/**
+ * ieee80211_channel - internal structure definiton for an IEEE-802.11 channel
+ *
+ * This defines an ieee80211_channel. The IEEE-802.11 regulatory domain agent
+ * is in charge of filling most of these fields out. The low-level driver
+ * is expected to fill in, if needed, the val field. Note that val is already
+ * set by the regulatory agent to the same channel as in chan.

Shouldn't you also set chan and freq in the driver?

Quoted 1 line

+ * @modulation_cap: could be IEEE80211_RATE_*

Could be?

Quoted 1 line

+ * @list: lets you make this structure part of a linked list

What do we need this for?

include/net/wireless_common.h line 55

Quoted 3 lines

include/net/wireless_common.h new file +3 -0

+struct ieee80211_channel {
+     /* XXX change to u8 */
+     short chan;

Not sure, is a u8 always enough? I thought 802.11a had huge channel numbers?

Quoted 1 line

+/* XXX consider removing the holes bellow */

I think these flags are shared with hostapd right now... :(

Quoted 5 lines

+/**
+ * enum rate_flags - internal &ieee80211_rate flags

+ * Use these flags to indicate to the lower layers details about an
+ * &ieee80211_rate.

^ struct ieee80211_rate, for kernel-doc

Quoted 5 lines

+ * @IEEE80211_RATE_ERP: indicates if the rate is an Extended Rate PHY (ERP)
+ * @IEEE80211_RATE_BASIC: indicates the rate is a basic rate for the
+ * currently used mode
+ * @IEEE80211_RATE_PREAMBLE2: used to indicates that the rate for short
+ * preamble is to be used. This is set in &ieee80211_rate's @val2.

Couldn't we just call it SHORT_PREAMBLE? :)

Quoted 1 line

+ * @IEEE80211_RATE_SUPPORTED: indicates if rate is supported by the given mode

What do we use this for?

Quoted 2 lines

+ * @IEEE80211_RATE_OFDM: indicates support for ODFM modulation
+ * @IEEE80211_RATE_CCK: indicates support for CCK modulation

I think this should be called "this rate is an OFDM/CCK rate"

Quoted 2 lines

+ * @IEEE80211_RATE_MANDATORY: indicates if this rate is mandatory for the
+ * currently used mode

I think this is wrong. Isn't the "mandatory" flag something for an AP to ask it's stations for?

Quoted 2 lines

+/* XXX move to inline and add documenation, kernel-doc can't doc defines */

Why don't you just do that then? :)

Quoted 3 lines

+ * Low-level driver should set PREAMBLE2, OFDM and CCK flags.
+ * BASIC, SUPPORTED, ERP, and MANDATORY flags are set in 80211.o based on the
+ * configuration.

Oh come on. There hasn't been 80211.o for a loong time :)

Quoted 4 lines

+ * @flags: IEEE80211_RATE_* flags
+ * @val2: hw specific value for the rate when using short preamble
+ * (only when IEEE80211_RATE_PREAMBLE2 flag is set, i.e., for
+ * 2, 5.5, and 11 Mbps)

Can't we just get rid of this field? Does anybody use it?

Quoted 2 lines

+ * @min_rssi_ack: Minimum required RSSI of packet to generate an ACK ??
+ * @min_rssi_ack_delta: ??

I thought we didn't use these fields.

Quoted 1 line

+ /* the following fields are set by 80211.o and need not be filled by the

80211.o again :)

Patchset I - Add central regulatory domain agent

This is patchset I of II which adds a central regulatory domain agent onto the wireless subsystem. I've split it into two patchsets in order to introduce the agent before affecting mac80211 drivers. This allows work to continue on the central reg agent independant of mac80211 advancements.

Patch series I adds the central regulatory domain agent and integrates it with cfg80211. The central reg agent consists of 2 main modules:

* ISO3166-1
* Regdomains

Additionally, changing regulatory domains can be acomplished through the use of a new configfs module which will be introduced for the wireless subsystem.

Patch series II will add support for the centreal reglatory agent onto mac80211, remove mac80211's simple regulatory control and and replace each driver's own regulatory domain implementation with the central one.

Luis

Also, if you could make sure this stuff is completely separate conceptually and architecturally from mac80211 itself, but have mac80211 _rely_ on it, then we can rip the bits out of the fullmac drivers that do regdomain stuff and plug them into this framework too. I think that's a real win.

include/net/ieee80211_regdomains.h line 36

Quoted 5 lines · Luis R. Rodriguez

include/net/ieee80211_regdomains.h new file +5 -0

+/* XXX: <net/ieee80211.h> has two band defs bellow */
+#ifndef IEEE80211_24GHZ_BAND
+#define IEEE80211_24GHZ_BAND     (1<<0)
+#define IEEE80211_52GHZ_BAND     (1<<1)
+#endif

Hmm. Could we make a new definition with just an enum?

enum ieee80211_band {
        IEEE80211_BAND_24GHZ,
        IEEE80211_BAND_52GHZ,
};

Then we can use "enum ieee80211_band" below in the structs and get type checking. Generally, no new stuff has anything to do with include/net/ieee80211.h, that's just for the old "stack".

Quoted 3 lines

+/**
+ * struct ieee80211_subband_restrictions - defines a regulatory domain
+ * subband restrictions list

I think the docs should include where this structure is used.

Quoted 1 line

+ * @name: name for this subband.

Why does it need a name?

Quoted 4 lines

+ * @min_freq: minimum frequency for this subband, in MHz. This represents the
+ * center of frequency of a channel.
+ * @max_freq: maximum frequency for this subband, in MHz. This represents the
+ * center of frequency of a channel.

How can both be center freq?

Quoted 9 lines

include/net/ieee80211_regdomains.h new file +9 -0

+struct ieee80211_subband_restrictions {
+     u8 band;
+     char name[REGSBNAMSIZ];
+     u16 min_freq;
+     u16 max_freq;
+     u32 modulation_cap;
+     u8 max_antenna_gain;
+     u8 max_ir_ptmp;
+     u8 max_ir_ptp;

include/net/ieee80211_regdomains.h line 108

Quoted 6 lines

include/net/ieee80211_regdomains.h new file +6 -0

+#define REG_DIPOLE_ANTENNA_GAIN 2
+     u8 max_eirp_ptmp;
+     u8 max_eirp_ptp;
+#define REG_CAP_INDOOR       'I'
+#define REG_CAP_OUTDOOR      'O'
+#define REG_CAP_INOUT        ' '

Did you actually run kernel-doc? it's rather unhappy with such things :)

Quoted 6 lines

+/**
+ * struct ieee80211_regdomain - defines a regulatory domain
+ *
+ * @regdomain_id: ID of this regulatory domain. Some come from
+ * http://standards.ieee.org/getieee802/download/802.11b-1999_Cor1-2001.pdf
+ * @regdomain_name: name of this regulatory domain.

Quoted 8 lines

+ * @list: node, part of band_restrictions_list
+ *
+ * This structure defines a regulatory domain, which consists of channel and
+ * power restrictions. Some regulatory domains come from
+ * 802.11b-1999_Cor1-2001, the rest are based on Reyk Floeter's ar5k. If
+ * there is need to add more values here, please add one that is either
+ * defined in a standard or that many hardware devices have adopted. Also
+ * note that multiple countries can map to the same @regdomain_id

There's no table here where you could add values, is there?.

include/net/ieee80211_regdomains.h line 132

Quoted 5 lines

+ */

include/net/ieee80211_regdomains.h new file +4 -0

+struct ieee80211_regdomain {
+     u32 regdomain_id;
+     char regdomain_name[REGNAMSIZ];
+     struct ieee80211_subband_restrictions subbands[REG_NUM_SUBBANDS];

Why is that not a variable length array with the number of items given in an extra var?

Quoted 10 lines

+ * This structure holds the mapping of the country to a specific regulatory
+ * domain. Keep in mind more than one country can map to the same regulatory
+ * domain. The ISO-3166-1 alpha2 country code also happens to be used in the
+ * 802.11d Country Information Element on the string for the country. It
+ * should be noted, however, that in that the size of this string, is
+ * three octects while our string is only 2. The third octet is used to
+ * indicate Indoor/outdoor capabilities which we set in
+ * @ieee80211_subband_restrictions environment_cap.
+ */
+struct ieee80211_iso3166_reg_map {

include/net/ieee80211_regdomains.h line 157

Quoted 5 lines

include/net/ieee80211_regdomains.h new file +5 -0

+     char alpha2[ISOCOUNTRYSIZ2];
+     u32 regdomain_id; /* stack-aware value */
+     /* XXX: shall we just use an array? */
+     struct list_head list; /* node, part of iso3166_reg_map_list */
+};

Why does this need a list if it's a static mapping? Why does it need to be visible outside of net/wireless/?

include/net/ieee80211_regdomains.h line 168

Quoted 10 lines

include/net/ieee80211_regdomains.h new file +10 -0

+/**
+ * regdomain_mhz2ieee - convert a frequency to an IEEE-80211 channel number
+ * @freq: center of frequency in MHz. We support a range:
+ *   2412 - 2732 MHz (Channel 1 - 26) in the 2GHz band and
+ *   5005 - 6100 MHz (Channel 1 - 220) in the 5GHz band.
+ *
+ * Given a frequency in MHz returns the respective IEEE-80211 channel
+ * number. You are expected to provide the center of freqency in MHz.
+ */
+u16 regdomain_mhz2ieee(u16 freq);

Ok this I can see being necessary for drivers/stacks.

Quoted 1 line

+u16 regdomain_ieee2mhz(u16 chan, u8 band);

Same here.

Quoted 1 line

+void print_regdomain(struct ieee80211_regdomain *);

Ssame.

Quoted 1 line

+void print_iso3166_reg_map(void);

But why does this need to be exported?

Quoted 1 line

+int get_ieee80211_regname(u32, char *);

What are the arguments?

Quoted 3 lines

Then we can use "enum ieee80211_band" below in the structs and get type checking. Generally, no new stuff has anything to do with include/net/ieee80211.h, that's just for the old "stack".

Sure, I just wanted to point out the band def existed in another header. My hopes is we can address all common header stuff once in for all. I guess it'll have to wait a bit more.

Quoted 3 lines

Quoted 1 line

+ * @name: name for this subband.

Why does it need a name?

Well to distinguish it.

Quoted 6 lines

Quoted 4 lines

+ * @min_freq: minimum frequency for this subband, in MHz. This represents the
+ * center of frequency of a channel.
+ * @max_freq: maximum frequency for this subband, in MHz. This represents the
+ * center of frequency of a channel.

How can both be center freq?

min_freq is the center of frequency for the minimum channel on the subband. max_freq is the center of frequency for the max channel on the subband. I guess I should clear that up a little more huh.

Quoted 15 lines

Quoted 14 lines

+/**
+ * struct ieee80211_regdomain - defines a regulatory domain
+ *
+ * @regdomain_id: ID of this regulatory domain. Some come from
+ * http://standards.ieee.org/getieee802/download/802.11b-1999_Cor1-2001.pdf
+ * @regdomain_name: name of this regulatory domain.
+ * @list: node, part of band_restrictions_list
+ *
+ * This structure defines a regulatory domain, which consists of channel and
+ * power restrictions. Some regulatory domains come from
+ * 802.11b-1999_Cor1-2001, the rest are based on Reyk Floeter's ar5k. If
+ * there is need to add more values here, please add one that is either
+ * defined in a standard or that many hardware devices have adopted. Also
+ * note that multiple countries can map to the same @regdomain_id

Quoted 1 line

There's no table here where you could add values, is there?.

There is a lot of them.. but we can add few to show as an example.

I should have explained that too. Well, if you may recall in my last implementation of this I actually used a linked list. I then decided we weren't going to add new 2.4GHz or 5GHz subbands unless a big IEEE-802.11 change occurs. That doesn't happen so often to either use linked list or a variable length array.

Quoted 5 lines · Dan Williams

Also, if you could make sure this stuff is completely separate conceptually and architecturally from mac80211 itself, but have mac80211 _rely_ on it, then we can rip the bits out of the fullmac drivers that do regdomain stuff and plug them into this framework too. I think that's a real win.

Yeah, I think that's the plan. In fact, I always consider mac80211 to be on the the same level like fullmac _drivers_ and mac80211-based drivers somewhere below that (at a level that with fullmac drivers doesn't exist)

Quoted 4 lines · Luis R. Rodriguez

Quoted 3 lines

Then we can use "enum ieee80211_band" below in the structs and get type checking. Generally, no new stuff has anything to do with include/net/ieee80211.h, that's just for the old "stack".

Quoted 3 lines

Sure, I just wanted to point out the band def existed in another header. My hopes is we can address all common header stuff once in for all. I guess it'll have to wait a bit more.

Oh ok. But I think we should start using sane values (these bits look awfully like you could OR them which is totally bogus) and convert the other stack over.

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

+ * @name: name for this subband.

Why does it need a name?

Well to distinguish it.

But why do we need to distinguish subbands by name? What do we use them for anyway?

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

+ * @min_freq: minimum frequency for this subband, in MHz. This represents the
+ * center of frequency of a channel.
+ * @max_freq: maximum frequency for this subband, in MHz. This represents the
+ * center of frequency of a channel.

Quoted 5 lines

Quoted 1 line

How can both be center freq?

min_freq is the center of frequency for the minimum channel on the subband. max_freq is the center of frequency for the max channel on the subband. I guess I should clear that up a little more huh.

Uh ok, no, I just need to read better :)

Quoted 15 lines

Quoted 15 lines

Quoted 14 lines

+/**
+ * struct ieee80211_regdomain - defines a regulatory domain
+ *
+ * @regdomain_id: ID of this regulatory domain. Some come from
+ * http://standards.ieee.org/getieee802/download/802.11b-1999_Cor1-2001.pdf
+ * @regdomain_name: name of this regulatory domain.
+ * @list: node, part of band_restrictions_list
+ *
+ * This structure defines a regulatory domain, which consists of channel and
+ * power restrictions. Some regulatory domains come from
+ * 802.11b-1999_Cor1-2001, the rest are based on Reyk Floeter's ar5k. If
+ * there is need to add more values here, please add one that is either
+ * defined in a standard or that many hardware devices have adopted. Also
+ * note that multiple countries can map to the same @regdomain_id

Quoted 3 lines

Quoted 1 line

There's no table here where you could add values, is there?.

There is a lot of them.. but we can add few to show as an example.

Then again. Why do we have this struct in a header file?

Quoted 5 lines

I should have explained that too. Well, if you may recall in my last implementation of this I actually used a linked list. I then decided we weren't going to add new 2.4GHz or 5GHz subbands unless a big IEEE-802.11 change occurs. That doesn't happen so often to either use linked list or a variable length array.

Ok I just don't understand why you have this information in a struct. Shouldn't all of this information be essentially internal to the regulatory code, and people who use it simply query it and get back a pointer to the subband that applies to their query?

I don't see why
everybody needs to see this huge array.

http://www.kernel.org/pub/linux/kernel/people/mcgrof/v2-regdomain-pat=

Quoted 8 lines

Quoted 6 lines

+ * ieee80211_channel - internal structure definiton for an IEEE-802.11 channel
+ *
+ * This defines an ieee80211_channel. The IEEE-802.11 regulatory domain agent
+ * is in charge of filling most of these fields out. The low-level driver
+ * is expected to fill in, if needed, the val field. Note that val is already
+ * set by the regulatory agent to the same channel as in chan.

Shouldn't you also set chan and freq in the driver?

Initially I wanted to move mac80211 to use a linked list of channels instead of an array for each mode. As we discussed it over (you, me and a few others) we determined it wasn't best to do this (I have a patch that allows this just in case we later change our mind). But -- previous to doing this I had a wrapper on ieee80211_channel as I wanted the central regdomain to have a linked list of reg domain channels. If we don't want a wrapper we have to add this to the ieee8021_channel struct. Otherwise I need to define my own channel struct which wraps around ieee80211_channel.

Quoted 6 lines

include/net/wireless_common.h line 55

Quoted 3 lines

include/net/wireless_common.h new file +3 -0

+struct ieee80211_channel {
+     /* XXX change to u8 */
+     short chan;

Not sure, is a u8 always enough? I thought 802.11a had huge channel numbers?

Not that huge :-) Highest I've heard is 220. u8 should suffice.

Quoted 8 lines · Luis R. Rodriguez

Quoted 8 lines

Quoted 6 lines

+ * ieee80211_channel - internal structure definiton for an IEEE-802.11 channel
+ *
+ * This defines an ieee80211_channel. The IEEE-802.11 regulatory domain agent
+ * is in charge of filling most of these fields out. The low-level driver
+ * is expected to fill in, if needed, the val field. Note that val is already
+ * set by the regulatory agent to the same channel as in chan.

Shouldn't you also set chan and freq in the driver?

[...]

Quoted 17 lines

Initially I wanted to move mac80211 to use a linked list of channels instead of an array for each mode. As we discussed it over (you, me and a few others) we determined it wasn't best to do this (I have a patch that allows this just in case we later change our mind). But -- previous to doing this I had a wrapper on ieee80211_channel as I wanted the central regdomain to have a linked list of reg domain channels. If we don't want a wrapper we have to add this to the ieee8021_channel struct. Otherwise I need to define my own channel struct which wraps around ieee80211_channel.

Quoted 6 lines

include/net/wireless_common.h line 55

Quoted 3 lines

include/net/wireless_common.h new file +3 -0

+struct ieee80211_channel {
+     /* XXX change to u8 */
+     short chan;

Not sure, is a u8 always enough? I thought 802.11a had huge channel numbers?

Quoted 1 line

Not that huge :-) Highest I've heard is 220. u8 should suffice.

What's the idea of working with channels? Channels are non-uniq numbers. Internally everything should work with center frequency and not with channels. If necessary, information should be converted from channels by the driver when reporting it into the stack. That way there also won't be any problems if there ever is a channel 417.

Quoted 27 lines · Joerg Mayer

Quoted 8 lines · Luis R. Rodriguez

Quoted 8 lines

Quoted 6 lines

+ * ieee80211_channel - internal structure definiton for an IEEE-802.11 channel
+ *
+ * This defines an ieee80211_channel. The IEEE-802.11 regulatory domain agent
+ * is in charge of filling most of these fields out. The low-level driver
+ * is expected to fill in, if needed, the val field. Note that val is already
+ * set by the regulatory agent to the same channel as in chan.

Shouldn't you also set chan and freq in the driver?

[...]

Quoted 17 lines

Initially I wanted to move mac80211 to use a linked list of channels instead of an array for each mode. As we discussed it over (you, me and a few others) we determined it wasn't best to do this (I have a patch that allows this just in case we later change our mind). But -- previous to doing this I had a wrapper on ieee80211_channel as I wanted the central regdomain to have a linked list of reg domain channels. If we don't want a wrapper we have to add this to the ieee8021_channel struct. Otherwise I need to define my own channel struct which wraps around ieee80211_channel.

Quoted 6 lines

include/net/wireless_common.h line 55

Quoted 3 lines

include/net/wireless_common.h new file +3 -0

+struct ieee80211_channel {
+     /* XXX change to u8 */
+     short chan;

Not sure, is a u8 always enough? I thought 802.11a had huge channel numbers?

Quoted 7 lines

Quoted 1 line

Not that huge :-) Highest I've heard is 220. u8 should suffice.

What's the idea of working with channels? Channels are non-uniq numbers. Internally everything should work with center frequency and not with channels. If necessary, information should be converted from channels by the driver when reporting it into the stack. That way there also won't be any problems if there ever is a channel 417.

I agree. I'm OK with just having center of freq. Right now WE supports channel or freqs and the value is passed directly to the driver (for FullMAC) or mac80211 (for SoftMAC). For nl80211 we can just support channel passing onto the kernel, if the user supplies a channel we'll do the conversion to freq in userspace. On step at a time.

Quoted 36 lines · Luis R. Rodriguez

Quoted 27 lines · Joerg Mayer

Quoted 8 lines · Luis R. Rodriguez

Quoted 8 lines

Quoted 6 lines

+ * ieee80211_channel - internal structure definiton for an IEEE-802.11 channel
+ *
+ * This defines an ieee80211_channel. The IEEE-802.11 regulatory domain agent
+ * is in charge of filling most of these fields out. The low-level driver
+ * is expected to fill in, if needed, the val field. Note that val is already
+ * set by the regulatory agent to the same channel as in chan.

Shouldn't you also set chan and freq in the driver?

[...]

Quoted 17 lines

Initially I wanted to move mac80211 to use a linked list of channels instead of an array for each mode. As we discussed it over (you, me and a few others) we determined it wasn't best to do this (I have a patch that allows this just in case we later change our mind). But -- previous to doing this I had a wrapper on ieee80211_channel as I wanted the central regdomain to have a linked list of reg domain channels. If we don't want a wrapper we have to add this to the ieee8021_channel struct. Otherwise I need to define my own channel struct which wraps around ieee80211_channel.

Quoted 6 lines

include/net/wireless_common.h line 55

Quoted 3 lines

include/net/wireless_common.h new file +3 -0

+struct ieee80211_channel {
+     /* XXX change to u8 */
+     short chan;

Not sure, is a u8 always enough? I thought 802.11a had huge channel numbers?

Quoted 7 lines

Quoted 1 line

Not that huge :-) Highest I've heard is 220. u8 should suffice.

What's the idea of working with channels? Channels are non-uniq numbers. Internally everything should work with center frequency and not with channels. If necessary, information should be converted from channels by the driver when reporting it into the stack. That way there also won't be any problems if there ever is a channel 417.

Quoted 5 lines

I agree. I'm OK with just having center of freq. Right now WE supports channel or freqs and the value is passed directly to the driver (for FullMAC) or mac80211 (for SoftMAC). For nl80211 we can just support channel passing onto the kernel, if the user supplies a channel we'll do the conversion to freq in userspace. On step at a time.

Definitely need to use freq and not channel. Channels are not unique (they just _happen_ to be so right now). Of course remember that we can't just pass channel really, we need to pass the tuple of (channel, band) or maybe even (channel, [A|B|G|N]) or something.