[PATCH] iw: add optional argument to parse 6G band channel

[PATCH] iw: add optional argument to parse 6G band channel

[Pradeep Kumar Chitrapu]

Channel numbers of 6G band overlaps with those of 2G or 5G bands.
Therefore, an optional argument "6G" is added and expected next
to channel number to map it to correct 6GHz frequency. If not
specified, defaults to matching 2G or 5G frequency.

example:
iw wlanX set channel 149 6G 80MHz  --> maps to 6695 MHz
iw wlanX set channel 149 80MHz     --> maps to 5745 MHz

Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
---
 interface.c |  5 +++--
 phy.c       |  8 ++++----
 util.c      | 13 +++++++++----
 3 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/interface.c b/interface.c
index 89c95a9ac4ab..8e85f831f9f9 100644
--- a/interface.c
+++ b/interface.c
@@ -725,8 +725,9 @@ COMMAND(switch, freq,
 	"<control freq> [5|10|20|40|80|80+80|160] [<center1_freq> [<center2_freq>]] [beacons <count>] [block-tx]",
 	NL80211_CMD_CHANNEL_SWITCH, 0, CIB_NETDEV, handle_freq,
 	"Switch the operating channel by sending a channel switch announcement (CSA).");
-COMMAND(switch, channel, "<channel> [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz] [beacons <count>] [block-tx]",
-	NL80211_CMD_CHANNEL_SWITCH, 0, CIB_NETDEV, handle_chan, NULL);
+COMMAND(switch, channel, "<channel> [6G] [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz] [beacons <count>] [block-tx]",
+	NL80211_CMD_CHANNEL_SWITCH, 0, CIB_NETDEV, handle_chan,
+	"6GHz channels expects '6G' in argument. If not specified, defaults to 5GHz or 2GHz channels");
 
 
 static int toggle_tid_param(const char *argv0, const char *argv1,
diff --git a/phy.c b/phy.c
index 2d489efd7690..31d96cec7886 100644
--- a/phy.c
+++ b/phy.c
@@ -222,9 +222,9 @@ static int handle_chan(struct nl80211_state *state, struct nl_msg *msg,
 
 	return put_chandef(msg, &chandef);
 }
-COMMAND(set, channel, "<channel> [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz|160MHz]",
+COMMAND(set, channel, "<channel> [6G] [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz|160MHz]",
 	NL80211_CMD_SET_WIPHY, 0, CIB_PHY, handle_chan, NULL);
-COMMAND(set, channel, "<channel> [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz|160MHz]",
+COMMAND(set, channel, "<channel> [6G] [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz|160MHz]",
 	NL80211_CMD_SET_WIPHY, 0, CIB_NETDEV, handle_chan, NULL);
 
 
@@ -369,12 +369,12 @@ err_out:
 		free(cac_trigger_argv);
 	return err;
 }
-TOPLEVEL(cac, "channel <channel> [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz]\n"
+TOPLEVEL(cac, "channel <channel> [6G] [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz]\n"
 	      "freq <freq> [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz]\n"
 	      "freq <control freq> [5|10|20|40|80|80+80|160] [<center1_freq> [<center2_freq>]]",
 	 0, 0, CIB_NETDEV, handle_cac, NULL);
 COMMAND(cac, trigger,
-	"channel <channel> [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz]\n"
+	"channel <channel> [6G] [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz]\n"
 	"freq <frequency> [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz]\n"
 	"freq <frequency> [5|10|20|40|80|80+80|160] [<center1_freq> [<center2_freq>]]",
 	NL80211_CMD_RADAR_DETECT, 0, CIB_NETDEV, handle_cac_trigger,
diff --git a/util.c b/util.c
index 0a9083c613a4..9ca32c5295ae 100644
--- a/util.c
+++ b/util.c
@@ -576,7 +576,7 @@ static int parse_freqs(struct chandef *chandef, int argc, char **argv,
  * user by giving "NOHT" instead.
  *
  * The working specifier if chan is set are:
- *   <channel> [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz|160MHz]
+ *   <channel> [6G] [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz|160MHz]
  *
  * And if frequency is set:
  *   <freq> [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz|160MHz]
@@ -648,7 +648,12 @@ int parse_freqchan(struct chandef *chandef, bool chan, int argc, char **argv,
 	if (chan) {
 		enum nl80211_band band;
 
-		band = freq <= 14 ? NL80211_BAND_2GHZ : NL80211_BAND_5GHZ;
+		if (argc > 1 && strcmp(argv[1], "6G") == 0) {
+			band = NL80211_BAND_6GHZ;
+			_parsed += 1;
+		} else {
+			band = freq <= 14 ? NL80211_BAND_2GHZ : NL80211_BAND_5GHZ;
+		}
 		freq = ieee80211_channel_to_frequency(freq, band);
 	}
 	chandef->control_freq = freq;
@@ -656,9 +661,9 @@ int parse_freqchan(struct chandef *chandef, bool chan, int argc, char **argv,
 	chandef->center_freq1 = freq;
 
 	/* Try to parse HT mode definitions */
-	if (argc > 1) {
+	if ((argc - _parsed) > 0) {
 		for (i = 0; i < ARRAY_SIZE(chanmode); i++) {
-			if (strcasecmp(chanmode[i].name, argv[1]) == 0) {
+			if (strcasecmp(chanmode[i].name, argv[_parsed]) == 0) {
 				chanmode_selected = &chanmode[i];
 				_parsed += 1;
 				break;
-- 
1.9.1

[PATCH] iw: enable 80MHz support for 6GHz band 11s mesh

[Pradeep Kumar Chitrapu]

without this 11s mesh could not be configured with bandwidth 80MHz
in 6G band using iw. Also, this will be required to set frequency
for 6GHz band in 80MHz.

example:
iw <interface> mesh join <meshname> freq 6195 80MHz

Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
---
 util.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/util.c b/util.c
index 9ca32c5295ae..175470f11a27 100644
--- a/util.c
+++ b/util.c
@@ -1241,21 +1241,24 @@ void iw_hexdump(const char *prefix, const __u8 *buf, size_t size)
 int get_cf1(const struct chanmode *chanmode, unsigned long freq)
 {
 	unsigned int cf1 = freq, j;
-	unsigned int vht80[] = { 5180, 5260, 5500, 5580, 5660, 5745 };
+	unsigned int bw80[] = { 5180, 5260, 5500, 5580, 5660, 5745,
+				5955, 6035, 6115, 6195, 6275, 6355,
+				6435, 6515, 6595, 6675, 6755, 6835,
+				6195, 6995 };
 	unsigned int vht160[] = { 5180, 5500 };
 
 	switch (chanmode->width) {
 	case NL80211_CHAN_WIDTH_80:
 	        /* setup center_freq1 */
-		for (j = 0; j < ARRAY_SIZE(vht80); j++) {
-			if (freq >= vht80[j] && freq < vht80[j] + 80)
+		for (j = 0; j < ARRAY_SIZE(bw80); j++) {
+			if (freq >= bw80[j] && freq < bw80[j] + 80)
 				break;
 		}
 
-		if (j == ARRAY_SIZE(vht80))
+		if (j == ARRAY_SIZE(bw80))
 			break;
 
-		cf1 = vht80[j] + 30;
+		cf1 = bw80[j] + 30;
 		break;
 	case NL80211_CHAN_WIDTH_160:
 		/* setup center_freq1 */
-- 
1.9.1

Re: [PATCH] iw: add optional argument to parse 6G band channel

[Johannes Berg]

On Fri, 2020-10-09 at 15:49 -0700, Pradeep Kumar Chitrapu wrote:
> Channel numbers of 6G band overlaps with those of 2G or 5G bands.
> Therefore, an optional argument "6G" is added and expected next
> to channel number to map it to correct 6GHz frequency. If not
> specified, defaults to matching 2G or 5G frequency.
> 
> example:
> iw wlanX set channel 149 6G 80MHz  --> maps to 6695 MHz
> iw wlanX set channel 149 80MHz     --> maps to 5745 MHz

Hm. I can't really say I like this much.

Is it _really_ needed? I mean, we mostly specify the frequency today, so
... why not just always do that for 6 GHz?

johannes

Re: [PATCH] iw: add optional argument to parse 6G band channel

[Arend Van Spriel]

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

On 11/6/2020 9:55 AM, Johannes Berg wrote:
> On Fri, 2020-10-09 at 15:49 -0700, Pradeep Kumar Chitrapu wrote:
>> Channel numbers of 6G band overlaps with those of 2G or 5G bands.
>> Therefore, an optional argument "6G" is added and expected next
>> to channel number to map it to correct 6GHz frequency. If not
>> specified, defaults to matching 2G or 5G frequency.
>>
>> example:
>> iw wlanX set channel 149 6G 80MHz  --> maps to 6695 MHz
>> iw wlanX set channel 149 80MHz     --> maps to 5745 MHz
> 
> Hm. I can't really say I like this much.
> 
> Is it _really_ needed? I mean, we mostly specify the frequency today, so
> ... why not just always do that for 6 GHz?

I suspect there are people preferring channel numbers as much as there 
are people preferring frequencies. Personally, I think it is acceptable 
to put this limitation on 6G.

Regards,
Arend

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4176 bytes --]

Re: [PATCH] iw: add optional argument to parse 6G band channel

[Johannes Berg]

On Fri, 2020-11-06 at 10:05 +0100, Arend Van Spriel wrote:
> On 11/6/2020 9:55 AM, Johannes Berg wrote:
> > On Fri, 2020-10-09 at 15:49 -0700, Pradeep Kumar Chitrapu wrote:
> > > Channel numbers of 6G band overlaps with those of 2G or 5G bands.
> > > Therefore, an optional argument "6G" is added and expected next
> > > to channel number to map it to correct 6GHz frequency. If not
> > > specified, defaults to matching 2G or 5G frequency.
> > > 
> > > example:
> > > iw wlanX set channel 149 6G 80MHz  --> maps to 6695 MHz
> > > iw wlanX set channel 149 80MHz     --> maps to 5745 MHz
> > 
> > Hm. I can't really say I like this much.
> > 
> > Is it _really_ needed? I mean, we mostly specify the frequency today, so
> > ... why not just always do that for 6 GHz?
> 
> I suspect there are people preferring channel numbers as much as there 
> are people preferring frequencies. Personally, I think it is acceptable 
> to put this limitation on 6G.

:)

After I sent the message I figured maybe then we should have different
syntax, where we say prefix the channel number by the band?

 iw wlanX set channel 6:149 ...
 iw wlanX set channel 5:149 ...
 iw wlanX set channel 2.4:11 ...

or so?

Seems better than having this optional argument '6G' in one place, and
could be supported in a more general fashion.

johannes

Re: [PATCH] iw: add optional argument to parse 6G band channel

[Arend Van Spriel]

[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]

On 11/6/2020 10:06 AM, Johannes Berg wrote:
> On Fri, 2020-11-06 at 10:05 +0100, Arend Van Spriel wrote:
>> On 11/6/2020 9:55 AM, Johannes Berg wrote:
>>> On Fri, 2020-10-09 at 15:49 -0700, Pradeep Kumar Chitrapu wrote:
>>>> Channel numbers of 6G band overlaps with those of 2G or 5G bands.
>>>> Therefore, an optional argument "6G" is added and expected next
>>>> to channel number to map it to correct 6GHz frequency. If not
>>>> specified, defaults to matching 2G or 5G frequency.
>>>>
>>>> example:
>>>> iw wlanX set channel 149 6G 80MHz  --> maps to 6695 MHz
>>>> iw wlanX set channel 149 80MHz     --> maps to 5745 MHz
>>>
>>> Hm. I can't really say I like this much.
>>>
>>> Is it _really_ needed? I mean, we mostly specify the frequency today, so
>>> ... why not just always do that for 6 GHz?
>>
>> I suspect there are people preferring channel numbers as much as there
>> are people preferring frequencies. Personally, I think it is acceptable
>> to put this limitation on 6G.
> 
> :)
> 
> After I sent the message I figured maybe then we should have different
> syntax, where we say prefix the channel number by the band?
> 
>   iw wlanX set channel 6:149 ...
>   iw wlanX set channel 5:149 ...
>   iw wlanX set channel 2.4:11 ...

Do you want to make that band: prefix required or optional. btw. starts 
to look like the format we use with our wl utility ;-)

Regards,
Arend

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4176 bytes --]

Re: [PATCH] iw: add optional argument to parse 6G band channel

[Johannes Berg]

On Fri, 2020-11-06 at 10:12 +0100, Arend Van Spriel wrote:
> On 11/6/2020 10:06 AM, Johannes Berg wrote:
> > On Fri, 2020-11-06 at 10:05 +0100, Arend Van Spriel wrote:
> > > On 11/6/2020 9:55 AM, Johannes Berg wrote:
> > > > On Fri, 2020-10-09 at 15:49 -0700, Pradeep Kumar Chitrapu wrote:
> > > > > Channel numbers of 6G band overlaps with those of 2G or 5G bands.
> > > > > Therefore, an optional argument "6G" is added and expected next
> > > > > to channel number to map it to correct 6GHz frequency. If not
> > > > > specified, defaults to matching 2G or 5G frequency.
> > > > > 
> > > > > example:
> > > > > iw wlanX set channel 149 6G 80MHz  --> maps to 6695 MHz
> > > > > iw wlanX set channel 149 80MHz     --> maps to 5745 MHz
> > > > 
> > > > Hm. I can't really say I like this much.
> > > > 
> > > > Is it _really_ needed? I mean, we mostly specify the frequency today, so
> > > > ... why not just always do that for 6 GHz?
> > > 
> > > I suspect there are people preferring channel numbers as much as there
> > > are people preferring frequencies. Personally, I think it is acceptable
> > > to put this limitation on 6G.
> > 
> > :)
> > 
> > After I sent the message I figured maybe then we should have different
> > syntax, where we say prefix the channel number by the band?
> > 
> >   iw wlanX set channel 6:149 ...
> >   iw wlanX set channel 5:149 ...
> >   iw wlanX set channel 2.4:11 ...
> 
> Do you want to make that band: prefix required or optional.

That's a good question. Probably should be optional, otherwise
everything breaks ...

> btw. starts 
> to look like the format we use with our wl utility ;-)

Hah! Maybe you have a better idea there? :)

johannes

Re: [PATCH] iw: add optional argument to parse 6G band channel

[Arend Van Spriel]

[-- Attachment #1: Type: text/plain, Size: 1756 bytes --]



On 11/6/2020 10:12 AM, Johannes Berg wrote:
> On Fri, 2020-11-06 at 10:12 +0100, Arend Van Spriel wrote:
>> On 11/6/2020 10:06 AM, Johannes Berg wrote:
>>> On Fri, 2020-11-06 at 10:05 +0100, Arend Van Spriel wrote:
>>>> On 11/6/2020 9:55 AM, Johannes Berg wrote:
>>>>> On Fri, 2020-10-09 at 15:49 -0700, Pradeep Kumar Chitrapu wrote:
>>>>>> Channel numbers of 6G band overlaps with those of 2G or 5G bands.
>>>>>> Therefore, an optional argument "6G" is added and expected next
>>>>>> to channel number to map it to correct 6GHz frequency. If not
>>>>>> specified, defaults to matching 2G or 5G frequency.
>>>>>>
>>>>>> example:
>>>>>> iw wlanX set channel 149 6G 80MHz  --> maps to 6695 MHz
>>>>>> iw wlanX set channel 149 80MHz     --> maps to 5745 MHz
>>>>>
>>>>> Hm. I can't really say I like this much.
>>>>>
>>>>> Is it _really_ needed? I mean, we mostly specify the frequency today, so
>>>>> ... why not just always do that for 6 GHz?
>>>>
>>>> I suspect there are people preferring channel numbers as much as there
>>>> are people preferring frequencies. Personally, I think it is acceptable
>>>> to put this limitation on 6G.
>>>
>>> :)
>>>
>>> After I sent the message I figured maybe then we should have different
>>> syntax, where we say prefix the channel number by the band?
>>>
>>>    iw wlanX set channel 6:149 ...
>>>    iw wlanX set channel 5:149 ...
>>>    iw wlanX set channel 2.4:11 ...
>>
>> Do you want to make that band: prefix required or optional.
> 
> That's a good question. Probably should be optional, otherwise
> everything breaks ...

Right.

>> btw. starts
>> to look like the format we use with our wl utility ;-)
> 
> Hah! Maybe you have a better idea there? :)

Not really. The above format seems fine as is.

Gr. AvS

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4176 bytes --]