[PATCH 0/3] Enable additional channels for GO

[PATCH 0/3] Enable additional channels for GO

[Ilan Peer]

The FCC are clarifying some soft configuration requirements,
which among other includes the following:

1. Concurrent GO operation, where devices may support WFD in
   bands where an authorized master (for example with DFS and
   DFS and radar detection capability in the UNII band) is operating.
2. Indoor operation, where in bands requiring indoor operation, the
   device must be programmed to detect indoor operation, or
   - Device must be connected to AC Power
   - Device must be under the control of a local master that is acting
     as an AP and is connected to AC Power.

See https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn=528122

David Spinadel (2):
  [RFC] cfg80211: Add indoor only and GO concurrent channel attributes
  [RFC] cfg80211: Enable GO operation on additional channels

Ilan Peer (1):
  [RFC] cfg80211: Add Kconfig option for cellular BS hints

 include/net/cfg80211.h       |   10 ++++-
 include/uapi/linux/nl80211.h |    7 +++
 net/mac80211/ibss.c          |    2 +-
 net/wireless/Kconfig         |   17 ++++++++
 net/wireless/chan.c          |   98 +++++++++++++++++++++++++++++++++++++++---
 net/wireless/mesh.c          |    2 +-
 net/wireless/nl80211.c       |   14 ++++--
 net/wireless/reg.c           |    2 +-
 net/wireless/trace.h         |   11 +++--
 9 files changed, 145 insertions(+), 18 deletions(-)

-- 
1.7.10.4

[PATCH 1/3] [RFC] cfg80211: Add indoor only and GO concurrent channel attributes

[Ilan Peer]

From: David Spinadel <david.spinadel@intel.com>

The FCC are clarifying some soft configuration requirements,
which among other includes the following:

1. Concurrent GO operation, where devices may support WFD in
   bands where an authorized master (for example with DFS and
   DFS and radar detection capability in the UNII band) is operating.
2. Indoor operation, where in bands requiring indoor operation, the
   device must be programmed to detect indoor operation, or
   - Device must be connected to AC Power
   - Device must be under the control of a local master that is acting
     as an AP and is connected to AC Power.

See https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn=528122

Add support for advertising Indoor-only and Concurrent-GO channel
properties.

Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
---
 include/net/cfg80211.h       |    6 ++++++
 include/uapi/linux/nl80211.h |    7 +++++++
 net/wireless/nl80211.c       |    6 ++++++
 3 files changed, 19 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 7b0730a..f0badeb 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -110,6 +110,10 @@ enum ieee80211_band {
  *	channel as the control or any of the secondary channels.
  *	This may be due to the driver or due to regulatory bandwidth
  *	restrictions.
+ * @IEEE80211_CHAN_INDOOR_ONLY: Only indoor use is permitted on this channel.
+ * @IEEE80211_CHAN_GO_CONCURRENT: GO operation is allowed on this channel if
+ *	it's connected concurrently to a BSS on the same channel on 2.4 or
+ *	to a channel in the same UNII band on 5.2.
  */
 enum ieee80211_channel_flags {
 	IEEE80211_CHAN_DISABLED		= 1<<0,
@@ -121,6 +125,8 @@ enum ieee80211_channel_flags {
 	IEEE80211_CHAN_NO_OFDM		= 1<<6,
 	IEEE80211_CHAN_NO_80MHZ		= 1<<7,
 	IEEE80211_CHAN_NO_160MHZ	= 1<<8,
+	IEEE80211_CHAN_INDOOR_ONLY	= 1<<9,
+	IEEE80211_CHAN_GO_CONCURRENT	= 1<<10,
 };
 
 #define IEEE80211_CHAN_NO_HT40 \
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 861e5eb..09a4f6b 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2158,6 +2158,11 @@ enum nl80211_band_attr {
  * @NL80211_FREQUENCY_ATTR_NO_160MHZ: any 160 MHz (but not 80+80) channel
  *	using this channel as the primary or any of the secondary channels
  *	isn't possible
+ * @NL80211_FREQUENCY_ATTR_INDOOR_ONLY: Indoor only use is permitted
+ *	on this channel in current regulatory domain.
+ * @NL80211_FREQUENCY_ATTR_GO_CONCURRENT: GO operation is allowed on this
+ *      channel if it's connected concurrently to a BSS on the same channel on
+ *      2.4 or to a channel in the same UNII band on 5.2.
  * @NL80211_FREQUENCY_ATTR_MAX: highest frequency attribute number
  *	currently defined
  * @__NL80211_FREQUENCY_ATTR_AFTER_LAST: internal use
@@ -2176,6 +2181,8 @@ enum nl80211_frequency_attr {
 	NL80211_FREQUENCY_ATTR_NO_HT40_PLUS,
 	NL80211_FREQUENCY_ATTR_NO_80MHZ,
 	NL80211_FREQUENCY_ATTR_NO_160MHZ,
+	NL80211_FREQUENCY_ATTR_INDOOR_ONLY,
+	NL80211_FREQUENCY_ATTR_GO_CONCURRENT,
 
 	/* keep last */
 	__NL80211_FREQUENCY_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 7dc3343..cf22b22 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -563,6 +563,12 @@ static int nl80211_msg_put_channel(struct sk_buff *msg,
 		if ((chan->flags & IEEE80211_CHAN_NO_160MHZ) &&
 		    nla_put_flag(msg, NL80211_FREQUENCY_ATTR_NO_160MHZ))
 			goto nla_put_failure;
+		if ((chan->flags & IEEE80211_CHAN_INDOOR_ONLY) &&
+		    nla_put_flag(msg, NL80211_FREQUENCY_ATTR_INDOOR_ONLY))
+			goto nla_put_failure;
+		if ((chan->flags & IEEE80211_CHAN_GO_CONCURRENT) &&
+		    nla_put_flag(msg, NL80211_FREQUENCY_ATTR_GO_CONCURRENT))
+			goto nla_put_failure;
 	}
 
 	if (nla_put_u32(msg, NL80211_FREQUENCY_ATTR_MAX_TX_POWER,
-- 
1.7.10.4

[PATCH 2/3] [RFC] cfg80211: Add Kconfig option for cellular BS hints

[Ilan Peer]

Move the regulatory cellular base station hints support under
a specific configuration option and make the option depend
on CFG80211_CERTIFICATION_ONUS.

Signed-off-by: Ilan Peer <ilan.peer@intel.com>
---
 net/wireless/Kconfig |    7 +++++++
 net/wireless/reg.c   |    2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 16d08b3..de76078 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -95,6 +95,13 @@ config CFG80211_CERTIFICATION_ONUS
 	  you are a wireless researcher and are working in a controlled
 	  and approved environment by your local regulatory agency.
 
+config CFG80211_REG_CELLULAR_HINTS
+	bool "cfg80211 regulatory support for cellular base station hints"
+	depends on CFG80211 && CFG80211_CERTIFICATION_ONUS
+	---help---
+	  This option adds support for drivers that can receive regulatory
+	  hints from cellular base stations
+
 config CFG80211_DEFAULT_PS
 	bool "enable powersave by default"
 	depends on CFG80211
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5a24c98..2459a69 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -928,7 +928,7 @@ bool reg_last_request_cell_base(void)
 	return reg_request_cell_base(get_last_request());
 }
 
-#ifdef CONFIG_CFG80211_CERTIFICATION_ONUS
+#ifdef CONFIG_CFG80211_REG_CELLULAR_HINTS
 /* Core specific check */
 static enum reg_request_treatment
 reg_ignore_cell_hint(struct regulatory_request *pending_request)
-- 
1.7.10.4

[PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional channels

[Ilan Peer]

From: David Spinadel <david.spinadel@intel.com>

Allow GO operation on a channel marked with
IEEE80211_CHAN_INDOOR_ONLY or IEEE80211_CHAN_GO_CONCURRENT
iff there is an active station interface that is associated to
an AP operating on this channel.

Note that this is a permissive approach to the FCC definitions,
that require a clear assessment that either the platform device
is an indoor device, or the device operating the AP is an indoor
device, i.e., AC powered.
It is assumed that these restrictions are enforced by user space.
Furthermore, it is assumed, that if the conditions that allowed for
the operation of the GO on such a channel change, it is the
responsibility of user space to evacuate the GO from the channel.

Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
---
 include/net/cfg80211.h |    4 +-
 net/mac80211/ibss.c    |    2 +-
 net/wireless/Kconfig   |   10 +++++
 net/wireless/chan.c    |   98 ++++++++++++++++++++++++++++++++++++++++++++----
 net/wireless/mesh.c    |    2 +-
 net/wireless/nl80211.c |    8 ++--
 net/wireless/trace.h   |   11 ++++--
 7 files changed, 118 insertions(+), 17 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index f0badeb..17d693d 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -4070,12 +4070,14 @@ void cfg80211_report_obss_beacon(struct wiphy *wiphy,
  * cfg80211_reg_can_beacon - check if beaconing is allowed
  * @wiphy: the wiphy
  * @chandef: the channel definition
+ * @p2p_go: if the interface type is a P2P GO
  *
  * Return: %true if there is no secondary channel or the secondary channel(s)
  * can be used for beaconing (i.e. is not a radar channel etc.)
  */
 bool cfg80211_reg_can_beacon(struct wiphy *wiphy,
-			     struct cfg80211_chan_def *chandef);
+			     struct cfg80211_chan_def *chandef,
+			     bool p2p_go);
 
 /*
  * cfg80211_ch_switch_notify - update wdev channel and notify userspace
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index ea7b9c2..1e0fac1 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -82,7 +82,7 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
 	sdata->drop_unencrypted = capability & WLAN_CAPABILITY_PRIVACY ? 1 : 0;
 
 	chandef = ifibss->chandef;
-	if (!cfg80211_reg_can_beacon(local->hw.wiphy, &chandef)) {
+	if (!cfg80211_reg_can_beacon(local->hw.wiphy, &chandef, false)) {
 		chandef.width = NL80211_CHAN_WIDTH_20;
 		chandef.center_freq1 = chan->center_freq;
 	}
diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index de76078..d9e2be7 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -102,6 +102,16 @@ config CFG80211_REG_CELLULAR_HINTS
 	  This option adds support for drivers that can receive regulatory
 	  hints from cellular base stations
 
+config CFG80211_REG_SOFT_CONFIGURATIONS
+	bool "cfg80211 support for GO operation on additional channels"
+	depends on CFG80211 && CFG80211_CERTIFICATION_ONUS
+	---help---
+	  This option enables the operation of a P2P Group Owner on
+	  additional channels, if there is a clear assessment that
+	  the platform device operates in an indoor environment or
+	  in case that there is an additional BSS interface which is
+	  connected to an AP which is an indoor device.
+
 config CFG80211_DEFAULT_PS
 	bool "enable powersave by default"
 	depends on CFG80211
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 50f6195..92d9e3c 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -457,18 +457,102 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy,
 }
 EXPORT_SYMBOL(cfg80211_chandef_usable);
 
+#ifdef CPTCFG_CFG80211_REG_SOFT_CONFIGURATIONS
+static int cfg80211_get_unii_band(int freq)
+{
+	/* UNII-1 */
+	if (freq >= 5150 && freq <= 5250)
+		return 0;
+
+	/* UNII-2 */
+	if (freq > 5250 && freq <= 5350)
+		return 1;
+
+	/* UNII-2E */
+	if (freq >= 5470 && freq <= 5725)
+		return 2;
+
+	/* UNII-3 */
+	if (freq > 5725 && freq <= 5825)
+		return 3;
+
+	WARN_ON(1);
+	return -EINVAL;
+}
+#endif
+
+/* For GO only, check if the channel can be used under permissive conditions
+ * mandated by the FCC, i.e., the channel is marked as:
+ * 1. Indoor only: a GO can be operational on such a channel, iff there is
+ *    clear assessment that the platform device is indoor.
+ * 2. Concurrent GO: a GO can be operational on such a channel, iff there is an
+ *    additional station interface connected to an AP on this channel.
+ *
+ * TODO: The function is too permissive, as it does not verify the platform
+ * device type is indeed indoor, or that the AP is indoor/AC powered.
+ */
+static bool cfg80211_can_go_use_chan(struct cfg80211_registered_device *rdev,
+				     struct ieee80211_channel *chan)
+{
+#ifdef CPTCFG_CFG80211_REG_SOFT_CONFIGURATIONS
+	struct wireless_dev *wdev_iter;
+
+	ASSERT_RTNL();
+
+	if (!(chan->flags & (IEEE80211_CHAN_INDOOR_ONLY |
+			     IEEE80211_CHAN_GO_CONCURRENT)))
+		return false;
+
+	if (chan->band == IEEE80211_BAND_60GHZ)
+		return false;
+
+	list_for_each_entry(wdev_iter, &rdev->wdev_list, list) {
+		struct ieee80211_channel *other_chan = NULL;
+
+		if (wdev_iter->iftype != NL80211_IFTYPE_STATION ||
+		    (!netif_running(wdev_iter->netdev)))
+				continue;
+
+
+		wdev_lock(wdev_iter);
+		if (wdev_iter->current_bss)
+			other_chan = wdev_iter->current_bss->pub.channel;
+		wdev_unlock(wdev_iter);
+
+		if (!other_chan)
+			continue;
+
+		if (chan == other_chan)
+			return true;
+		else if ((chan->band == IEEE80211_BAND_5GHZ) &&
+			 (cfg80211_get_unii_band(chan->center_freq) ==
+			  cfg80211_get_unii_band(other_chan->center_freq)))
+			return true;
+	}
+#endif
+	return false;
+}
+
 bool cfg80211_reg_can_beacon(struct wiphy *wiphy,
-			     struct cfg80211_chan_def *chandef)
+			     struct cfg80211_chan_def *chandef,
+			     bool p2p_go)
 {
+	struct cfg80211_registered_device *rdev = wiphy_to_dev(wiphy);
 	bool res;
+	u32 flags;
 
-	trace_cfg80211_reg_can_beacon(wiphy, chandef);
+	trace_cfg80211_reg_can_beacon(wiphy, chandef, p2p_go);
+
+	flags = IEEE80211_CHAN_DISABLED | IEEE80211_CHAN_RADAR;
+
+	/* Under certain conditions a GO can operate on channels marked
+	 * with IEEE80211_CHAN_PASSIVE_SCAN and IEEE80211_CHAN_NO_IBSS, so set
+	 * these flags only if the conditions are not met.
+	 */
+	if (!p2p_go || !cfg80211_can_go_use_chan(rdev, chandef->chan))
+		flags |= IEEE80211_CHAN_PASSIVE_SCAN | IEEE80211_CHAN_NO_IBSS;
 
-	res = cfg80211_chandef_usable(wiphy, chandef,
-				      IEEE80211_CHAN_DISABLED |
-				      IEEE80211_CHAN_PASSIVE_SCAN |
-				      IEEE80211_CHAN_NO_IBSS |
-				      IEEE80211_CHAN_RADAR);
+	res = cfg80211_chandef_usable(wiphy, chandef, flags);
 
 	trace_cfg80211_return_bool(res);
 	return res;
diff --git a/net/wireless/mesh.c b/net/wireless/mesh.c
index 30c4920..746c8b4 100644
--- a/net/wireless/mesh.c
+++ b/net/wireless/mesh.c
@@ -172,7 +172,7 @@ int __cfg80211_join_mesh(struct cfg80211_registered_device *rdev,
 		setup->basic_rates = ieee80211_mandatory_rates(sband);
 	}
 
-	if (!cfg80211_reg_can_beacon(&rdev->wiphy, &setup->chandef))
+	if (!cfg80211_reg_can_beacon(&rdev->wiphy, &setup->chandef, false))
 		return -EINVAL;
 
 	err = cfg80211_can_use_chan(rdev, wdev, setup->chandef.chan,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index cf22b22..204c160 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1801,7 +1801,8 @@ static int __nl80211_set_channel(struct cfg80211_registered_device *rdev,
 			result = -EBUSY;
 			break;
 		}
-		if (!cfg80211_reg_can_beacon(&rdev->wiphy, &chandef)) {
+		if (!cfg80211_reg_can_beacon(&rdev->wiphy, &chandef,
+					     iftype == NL80211_IFTYPE_P2P_GO)) {
 			result = -EINVAL;
 			break;
 		}
@@ -3150,7 +3151,8 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info)
 	} else if (!nl80211_get_ap_channel(rdev, &params))
 		return -EINVAL;
 
-	if (!cfg80211_reg_can_beacon(&rdev->wiphy, &params.chandef))
+	if (!cfg80211_reg_can_beacon(&rdev->wiphy, &params.chandef,
+				     wdev->iftype == NL80211_IFTYPE_P2P_GO))
 		return -EINVAL;
 
 	err = cfg80211_chandef_dfs_required(wdev->wiphy, &params.chandef);
@@ -6319,7 +6321,7 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
 	if (err)
 		return err;
 
-	if (!cfg80211_reg_can_beacon(&rdev->wiphy, &ibss.chandef))
+	if (!cfg80211_reg_can_beacon(&rdev->wiphy, &ibss.chandef, false))
 		return -EINVAL;
 
 	switch (ibss.chandef.width) {
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index e1534baf..7be32c3 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -2115,18 +2115,21 @@ TRACE_EVENT(cfg80211_cqm_rssi_notify,
 );
 
 TRACE_EVENT(cfg80211_reg_can_beacon,
-	TP_PROTO(struct wiphy *wiphy, struct cfg80211_chan_def *chandef),
-	TP_ARGS(wiphy, chandef),
+	TP_PROTO(struct wiphy *wiphy, struct cfg80211_chan_def *chandef,
+		 bool p2p_go),
+	TP_ARGS(wiphy, chandef, p2p_go),
 	TP_STRUCT__entry(
 		WIPHY_ENTRY
 		CHAN_DEF_ENTRY
+		__field(bool, p2p_go)
 	),
 	TP_fast_assign(
 		WIPHY_ASSIGN;
 		CHAN_DEF_ASSIGN(chandef);
+		__entry->p2p_go = p2p_go;
 	),
-	TP_printk(WIPHY_PR_FMT ", " CHAN_DEF_PR_FMT,
-		  WIPHY_PR_ARG, CHAN_DEF_PR_ARG)
+	TP_printk(WIPHY_PR_FMT ", " CHAN_DEF_PR_FMT ", p2p_go=%d",
+		  WIPHY_PR_ARG, CHAN_DEF_PR_ARG, __entry->p2p_go)
 );
 
 TRACE_EVENT(cfg80211_chandef_dfs_required,
-- 
1.7.10.4

Re: [PATCH 2/3] [RFC] cfg80211: Add Kconfig option for cellular BS hints

[Arend van Spriel]

On 07/02/2013 02:28 PM, Ilan Peer wrote:
> Move the regulatory cellular base station hints support under
> a specific configuration option and make the option depend
> on CFG80211_CERTIFICATION_ONUS.

This one seems not really related to the other patches. On itself it is 
not clear to me what itch is being scratched here. Is the aim to get rid 
of the CERTIFICATION_ONUS dependency further along the road?

Regards,
Arend

> Signed-off-by: Ilan Peer <ilan.peer@intel.com>
> ---
>   net/wireless/Kconfig |    7 +++++++
>   net/wireless/reg.c   |    2 +-
>   2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
> index 16d08b3..de76078 100644
> --- a/net/wireless/Kconfig
> +++ b/net/wireless/Kconfig
> @@ -95,6 +95,13 @@ config CFG80211_CERTIFICATION_ONUS
>   	  you are a wireless researcher and are working in a controlled
>   	  and approved environment by your local regulatory agency.
>
> +config CFG80211_REG_CELLULAR_HINTS
> +	bool "cfg80211 regulatory support for cellular base station hints"
> +	depends on CFG80211 && CFG80211_CERTIFICATION_ONUS
> +	---help---
> +	  This option adds support for drivers that can receive regulatory
> +	  hints from cellular base stations
> +
>   config CFG80211_DEFAULT_PS
>   	bool "enable powersave by default"
>   	depends on CFG80211
> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index 5a24c98..2459a69 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -928,7 +928,7 @@ bool reg_last_request_cell_base(void)
>   	return reg_request_cell_base(get_last_request());
>   }
>
> -#ifdef CONFIG_CFG80211_CERTIFICATION_ONUS
> +#ifdef CONFIG_CFG80211_REG_CELLULAR_HINTS
>   /* Core specific check */
>   static enum reg_request_treatment
>   reg_ignore_cell_hint(struct regulatory_request *pending_request)
>

Re: [PATCH 2/3] [RFC] cfg80211: Add Kconfig option for cellular BS hints

[Johannes Berg]

On Tue, 2013-07-02 at 15:55 +0200, Arend van Spriel wrote:
> On 07/02/2013 02:28 PM, Ilan Peer wrote:
> > Move the regulatory cellular base station hints support under
> > a specific configuration option and make the option depend
> > on CFG80211_CERTIFICATION_ONUS.
> 
> This one seems not really related to the other patches. On itself it is 
> not clear to me what itch is being scratched here. Is the aim to get rid 
> of the CERTIFICATION_ONUS dependency further along the road?

No, it's really just so patch 3 can add a separate option under
CERTIFICATION_ONUS while allowing cell base station and the new option
to be separate.

johannes

Re: [PATCH 2/3] [RFC] cfg80211: Add Kconfig option for cellular BS hints

[Arend van Spriel]

On 07/02/2013 04:00 PM, Johannes Berg wrote:
> On Tue, 2013-07-02 at 15:55 +0200, Arend van Spriel wrote:
>> On 07/02/2013 02:28 PM, Ilan Peer wrote:
>>> Move the regulatory cellular base station hints support under
>>> a specific configuration option and make the option depend
>>> on CFG80211_CERTIFICATION_ONUS.
>>
>> This one seems not really related to the other patches. On itself it is
>> not clear to me what itch is being scratched here. Is the aim to get rid
>> of the CERTIFICATION_ONUS dependency further along the road?
>
> No, it's really just so patch 3 can add a separate option under
> CERTIFICATION_ONUS while allowing cell base station and the new option
> to be separate.

Thanks, Johannes

Missed that.

Gr. AvS

Re: [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional channels

[Jouni Malinen]

On Tue, Jul 02, 2013 at 03:28:15PM +0300, Ilan Peer wrote:
> Allow GO operation on a channel marked with
> IEEE80211_CHAN_INDOOR_ONLY or IEEE80211_CHAN_GO_CONCURRENT
> iff there is an active station interface that is associated to
> an AP operating on this channel.
> 
> Note that this is a permissive approach to the FCC definitions,
> that require a clear assessment that either the platform device
> is an indoor device, or the device operating the AP is an indoor
> device, i.e., AC powered.
> It is assumed that these restrictions are enforced by user space.

The introduction in 0/3 mentioned DFS, but I did not see it being
addressed in any of the actual changes. Is this only for indoors vs.
outdoors?

> Furthermore, it is assumed, that if the conditions that allowed for
> the operation of the GO on such a channel change, it is the
> responsibility of user space to evacuate the GO from the channel.

Do you have plans or changes to address this? I'd assume wpa_supplicant
could stop the group on channel list changes, but I don't think it does
that currently.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [PATCH 1/3] [RFC] cfg80211: Add indoor only and GO concurrent channel attributes

[Luis R. Rodriguez]

Cc'ing a few other lists for a wider review.

On Tue, Jul 2, 2013 at 5:28 AM, Ilan Peer <ilan.peer@intel.com> wrote:
> From: David Spinadel <david.spinadel@intel.com>
>
> The FCC are clarifying some soft configuration requirements,
> which among other includes the following:
>
> 1. Concurrent GO operation, where devices may support WFD in
>    bands where an authorized master (for example with DFS and
>    DFS and radar detection capability in the UNII band) is operating.

Is WFD WiFi Display? Is there any strict relationship here to WFD and
GO and regulatory or is WFD just a use case example? Are you
indicating that the FCC is making special rules for cases in specific
bands where GO *can* co-exist with other GO devices ?

You annotate that this is somehow related to DFS, are the GO
concurrent rules that the FCC is defining only applicable to DFS
frequency ranges? If so would it suffice to only use DFS flag ? Or are
there other special cases beyond DFS frequency ranges that the FCC is
creating special handling?

Apart from the FCC are you aware of special cases handling for other
regulatory bodies at this point?

Note that we have already these on regdb.h from CRDA:


/*
 * The Linux map defined in <linux/uapi/nl80211.h> enum nl80211_reg_rule_flags
 */
enum reg_rule_flags {
        RRF_NO_OFDM             = 1<<0, /* OFDM modulation not allowed */
        RRF_NO_CCK              = 1<<1, /* CCK modulation not allowed */
        RRF_NO_INDOOR           = 1<<2, /* indoor operation not allowed */
        RRF_NO_OUTDOOR          = 1<<3, /* outdoor operation not allowed */
        RRF_DFS                 = 1<<4, /* DFS support is required to be
                                         * used */
        RRF_PTP_ONLY            = 1<<5, /* this is only for Point To Point
                                         * links */
        RRF_PTMP_ONLY           = 1<<6, /* this is only for Point To Multi
                                         * Point links */
        RRF_PASSIVE_SCAN        = 1<<7, /* passive scan is required */
        RRF_NO_IBSS             = 1<<8, /* IBSS is not allowed */
};

Historically we don't distinguish then a type of 802.11 device that
initiates radiation except for the NO_IBSS rule, but that rule can be
treated more as legacy given that the intent and motivation behind
that was that some ODMs simply preferred an interpretation of
regulatory rules and we *currently* don't use that in much places
other than custom regulatory domains defined in the kernel. The
PTP_ONLY and PTMP_ONLY are example other rules that could potentially
have been used but to this day we haven't found a use case for it
given that typical 802.11 devices are PTMP.

I mention the NO_IBSS case as I'd like to try to avoid adding GO
specific flag if we can figure out a way to make this more generic. At
this point for example I think a more appropriate flag is in place:

  * NO_IR - cannot initiate radiation

And this could in turn end up replacing most use cases of NO_IBSS and
PASSIVE_SCAN givne that both of these imply we cannot initiate
radiation unless specific things are done. I wonder if we can fold the
GO flag into this and perhaps rename the NO_IBSS flag to the GO one.

Also note that we should keep the flags in sync with the uapi nl80211
change. Please review these suggestions and let me know what you
think.

> 2. Indoor operation, where in bands requiring indoor operation, the
>    device must be programmed to detect indoor operation, or
>    - Device must be connected to AC Power

Does anyone  know if the FCC considers "indoor" if we power a device
through the car on AC power through a converter ? Are we willing to
ignore that corner case?

>    - Device must be under the control of a local master that is acting

Interesting, so some APIs would be defined, I take it on hostapd to do
the proper callbacks to 'slave' type of devices that depend on the
local master(s). I could envision this being implemented on hostapd by
expanding the AP interface type and associating 'slave' devices and
callbacks for updates on AP device updates (channel changes, and so
on). Is this work being planned?

  Luis

>      as an AP and is connected to AC Power.
>
> See https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn=528122
>
> Add support for advertising Indoor-only and Concurrent-GO channel
> properties.
>
> Signed-off-by: David Spinadel <david.spinadel@intel.com>
> Signed-off-by: Ilan Peer <ilan.peer@intel.com>
> ---
>  include/net/cfg80211.h       |    6 ++++++
>  include/uapi/linux/nl80211.h |    7 +++++++
>  net/wireless/nl80211.c       |    6 ++++++
>  3 files changed, 19 insertions(+)
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 7b0730a..f0badeb 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -110,6 +110,10 @@ enum ieee80211_band {
>   *     channel as the control or any of the secondary channels.
>   *     This may be due to the driver or due to regulatory bandwidth
>   *     restrictions.
> + * @IEEE80211_CHAN_INDOOR_ONLY: Only indoor use is permitted on this channel.
> + * @IEEE80211_CHAN_GO_CONCURRENT: GO operation is allowed on this channel if
> + *     it's connected concurrently to a BSS on the same channel on 2.4 or
> + *     to a channel in the same UNII band on 5.2.
>   */
>  enum ieee80211_channel_flags {
>         IEEE80211_CHAN_DISABLED         = 1<<0,
> @@ -121,6 +125,8 @@ enum ieee80211_channel_flags {
>         IEEE80211_CHAN_NO_OFDM          = 1<<6,
>         IEEE80211_CHAN_NO_80MHZ         = 1<<7,
>         IEEE80211_CHAN_NO_160MHZ        = 1<<8,
> +       IEEE80211_CHAN_INDOOR_ONLY      = 1<<9,
> +       IEEE80211_CHAN_GO_CONCURRENT    = 1<<10,
>  };
>
>  #define IEEE80211_CHAN_NO_HT40 \
> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
> index 861e5eb..09a4f6b 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -2158,6 +2158,11 @@ enum nl80211_band_attr {
>   * @NL80211_FREQUENCY_ATTR_NO_160MHZ: any 160 MHz (but not 80+80) channel
>   *     using this channel as the primary or any of the secondary channels
>   *     isn't possible
> + * @NL80211_FREQUENCY_ATTR_INDOOR_ONLY: Indoor only use is permitted
> + *     on this channel in current regulatory domain.
> + * @NL80211_FREQUENCY_ATTR_GO_CONCURRENT: GO operation is allowed on this
> + *      channel if it's connected concurrently to a BSS on the same channel on
> + *      2.4 or to a channel in the same UNII band on 5.2.
>   * @NL80211_FREQUENCY_ATTR_MAX: highest frequency attribute number
>   *     currently defined
>   * @__NL80211_FREQUENCY_ATTR_AFTER_LAST: internal use
> @@ -2176,6 +2181,8 @@ enum nl80211_frequency_attr {
>         NL80211_FREQUENCY_ATTR_NO_HT40_PLUS,
>         NL80211_FREQUENCY_ATTR_NO_80MHZ,
>         NL80211_FREQUENCY_ATTR_NO_160MHZ,
> +       NL80211_FREQUENCY_ATTR_INDOOR_ONLY,
> +       NL80211_FREQUENCY_ATTR_GO_CONCURRENT,
>
>         /* keep last */
>         __NL80211_FREQUENCY_ATTR_AFTER_LAST,
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 7dc3343..cf22b22 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -563,6 +563,12 @@ static int nl80211_msg_put_channel(struct sk_buff *msg,
>                 if ((chan->flags & IEEE80211_CHAN_NO_160MHZ) &&
>                     nla_put_flag(msg, NL80211_FREQUENCY_ATTR_NO_160MHZ))
>                         goto nla_put_failure;
> +               if ((chan->flags & IEEE80211_CHAN_INDOOR_ONLY) &&
> +                   nla_put_flag(msg, NL80211_FREQUENCY_ATTR_INDOOR_ONLY))
> +                       goto nla_put_failure;
> +               if ((chan->flags & IEEE80211_CHAN_GO_CONCURRENT) &&
> +                   nla_put_flag(msg, NL80211_FREQUENCY_ATTR_GO_CONCURRENT))
> +                       goto nla_put_failure;
>         }
>
>         if (nla_put_u32(msg, NL80211_FREQUENCY_ATTR_MAX_TX_POWER,
> --
> 1.7.10.4
>

Re: [wireless-regdb] [PATCH 1/3] [RFC] cfg80211: Add indoor only and GO concurrent channel attributes

[Luis R. Rodriguez]

Cc'ing a few other lists for a wider review.

On Tue, Jul 2, 2013 at 5:28 AM, Ilan Peer <ilan.peer@intel.com> wrote:
> From: David Spinadel <david.spinadel@intel.com>
>
> The FCC are clarifying some soft configuration requirements,
> which among other includes the following:
>
> 1. Concurrent GO operation, where devices may support WFD in
>    bands where an authorized master (for example with DFS and
>    DFS and radar detection capability in the UNII band) is operating.

Is WFD WiFi Display? Is there any strict relationship here to WFD and
GO and regulatory or is WFD just a use case example? Are you
indicating that the FCC is making special rules for cases in specific
bands where GO *can* co-exist with other GO devices ?

You annotate that this is somehow related to DFS, are the GO
concurrent rules that the FCC is defining only applicable to DFS
frequency ranges? If so would it suffice to only use DFS flag ? Or are
there other special cases beyond DFS frequency ranges that the FCC is
creating special handling?

Apart from the FCC are you aware of special cases handling for other
regulatory bodies at this point?

Note that we have already these on regdb.h from CRDA:


/*
 * The Linux map defined in <linux/uapi/nl80211.h> enum nl80211_reg_rule_flags
 */
enum reg_rule_flags {
        RRF_NO_OFDM             = 1<<0, /* OFDM modulation not allowed */
        RRF_NO_CCK              = 1<<1, /* CCK modulation not allowed */
        RRF_NO_INDOOR           = 1<<2, /* indoor operation not allowed */
        RRF_NO_OUTDOOR          = 1<<3, /* outdoor operation not allowed */
        RRF_DFS                 = 1<<4, /* DFS support is required to be
                                         * used */
        RRF_PTP_ONLY            = 1<<5, /* this is only for Point To Point
                                         * links */
        RRF_PTMP_ONLY           = 1<<6, /* this is only for Point To Multi
                                         * Point links */
        RRF_PASSIVE_SCAN        = 1<<7, /* passive scan is required */
        RRF_NO_IBSS             = 1<<8, /* IBSS is not allowed */
};

Historically we don't distinguish then a type of 802.11 device that
initiates radiation except for the NO_IBSS rule, but that rule can be
treated more as legacy given that the intent and motivation behind
that was that some ODMs simply preferred an interpretation of
regulatory rules and we *currently* don't use that in much places
other than custom regulatory domains defined in the kernel. The
PTP_ONLY and PTMP_ONLY are example other rules that could potentially
have been used but to this day we haven't found a use case for it
given that typical 802.11 devices are PTMP.

I mention the NO_IBSS case as I'd like to try to avoid adding GO
specific flag if we can figure out a way to make this more generic. At
this point for example I think a more appropriate flag is in place:

  * NO_IR - cannot initiate radiation

And this could in turn end up replacing most use cases of NO_IBSS and
PASSIVE_SCAN givne that both of these imply we cannot initiate
radiation unless specific things are done. I wonder if we can fold the
GO flag into this and perhaps rename the NO_IBSS flag to the GO one.

Also note that we should keep the flags in sync with the uapi nl80211
change. Please review these suggestions and let me know what you
think.

> 2. Indoor operation, where in bands requiring indoor operation, the
>    device must be programmed to detect indoor operation, or
>    - Device must be connected to AC Power

Does anyone  know if the FCC considers "indoor" if we power a device
through the car on AC power through a converter ? Are we willing to
ignore that corner case?

>    - Device must be under the control of a local master that is acting

Interesting, so some APIs would be defined, I take it on hostapd to do
the proper callbacks to 'slave' type of devices that depend on the
local master(s). I could envision this being implemented on hostapd by
expanding the AP interface type and associating 'slave' devices and
callbacks for updates on AP device updates (channel changes, and so
on). Is this work being planned?

  Luis

>      as an AP and is connected to AC Power.
>
> See https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn=528122
>
> Add support for advertising Indoor-only and Concurrent-GO channel
> properties.
>
> Signed-off-by: David Spinadel <david.spinadel@intel.com>
> Signed-off-by: Ilan Peer <ilan.peer@intel.com>
> ---
>  include/net/cfg80211.h       |    6 ++++++
>  include/uapi/linux/nl80211.h |    7 +++++++
>  net/wireless/nl80211.c       |    6 ++++++
>  3 files changed, 19 insertions(+)
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 7b0730a..f0badeb 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -110,6 +110,10 @@ enum ieee80211_band {
>   *     channel as the control or any of the secondary channels.
>   *     This may be due to the driver or due to regulatory bandwidth
>   *     restrictions.
> + * @IEEE80211_CHAN_INDOOR_ONLY: Only indoor use is permitted on this channel.
> + * @IEEE80211_CHAN_GO_CONCURRENT: GO operation is allowed on this channel if
> + *     it's connected concurrently to a BSS on the same channel on 2.4 or
> + *     to a channel in the same UNII band on 5.2.
>   */
>  enum ieee80211_channel_flags {
>         IEEE80211_CHAN_DISABLED         = 1<<0,
> @@ -121,6 +125,8 @@ enum ieee80211_channel_flags {
>         IEEE80211_CHAN_NO_OFDM          = 1<<6,
>         IEEE80211_CHAN_NO_80MHZ         = 1<<7,
>         IEEE80211_CHAN_NO_160MHZ        = 1<<8,
> +       IEEE80211_CHAN_INDOOR_ONLY      = 1<<9,
> +       IEEE80211_CHAN_GO_CONCURRENT    = 1<<10,
>  };
>
>  #define IEEE80211_CHAN_NO_HT40 \
> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
> index 861e5eb..09a4f6b 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -2158,6 +2158,11 @@ enum nl80211_band_attr {
>   * @NL80211_FREQUENCY_ATTR_NO_160MHZ: any 160 MHz (but not 80+80) channel
>   *     using this channel as the primary or any of the secondary channels
>   *     isn't possible
> + * @NL80211_FREQUENCY_ATTR_INDOOR_ONLY: Indoor only use is permitted
> + *     on this channel in current regulatory domain.
> + * @NL80211_FREQUENCY_ATTR_GO_CONCURRENT: GO operation is allowed on this
> + *      channel if it's connected concurrently to a BSS on the same channel on
> + *      2.4 or to a channel in the same UNII band on 5.2.
>   * @NL80211_FREQUENCY_ATTR_MAX: highest frequency attribute number
>   *     currently defined
>   * @__NL80211_FREQUENCY_ATTR_AFTER_LAST: internal use
> @@ -2176,6 +2181,8 @@ enum nl80211_frequency_attr {
>         NL80211_FREQUENCY_ATTR_NO_HT40_PLUS,
>         NL80211_FREQUENCY_ATTR_NO_80MHZ,
>         NL80211_FREQUENCY_ATTR_NO_160MHZ,
> +       NL80211_FREQUENCY_ATTR_INDOOR_ONLY,
> +       NL80211_FREQUENCY_ATTR_GO_CONCURRENT,
>
>         /* keep last */
>         __NL80211_FREQUENCY_ATTR_AFTER_LAST,
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 7dc3343..cf22b22 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -563,6 +563,12 @@ static int nl80211_msg_put_channel(struct sk_buff *msg,
>                 if ((chan->flags & IEEE80211_CHAN_NO_160MHZ) &&
>                     nla_put_flag(msg, NL80211_FREQUENCY_ATTR_NO_160MHZ))
>                         goto nla_put_failure;
> +               if ((chan->flags & IEEE80211_CHAN_INDOOR_ONLY) &&
> +                   nla_put_flag(msg, NL80211_FREQUENCY_ATTR_INDOOR_ONLY))
> +                       goto nla_put_failure;
> +               if ((chan->flags & IEEE80211_CHAN_GO_CONCURRENT) &&
> +                   nla_put_flag(msg, NL80211_FREQUENCY_ATTR_GO_CONCURRENT))
> +                       goto nla_put_failure;
>         }
>
>         if (nla_put_u32(msg, NL80211_FREQUENCY_ATTR_MAX_TX_POWER,
> --
> 1.7.10.4
>

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional channels

[Luis R. Rodriguez]

On Tue, Jul 2, 2013 at 5:28 AM, Ilan Peer <ilan.peer@intel.com> wrote:
> From: David Spinadel <david.spinadel@intel.com>
>
> Allow GO operation on a channel marked with
> IEEE80211_CHAN_INDOOR_ONLY or IEEE80211_CHAN_GO_CONCURRENT
> iff there is an active station interface that is associated to
> an AP operating on this channel.
>
> Note that this is a permissive approach to the FCC definitions,
> that require a clear assessment that either the platform device
> is an indoor device, or the device operating the AP is an indoor
> device, i.e., AC powered.
> It is assumed that these restrictions are enforced by user space.
> Furthermore, it is assumed, that if the conditions that allowed for
> the operation of the GO on such a channel change, it is the
> responsibility of user space to evacuate the GO from the channel.

In the context of strict regulatory data we currently do not
differentiate specifically between a device that can initiate
radiation between AP and Group Owner (GO) but in your earlier patches
you proposed a way to do that. I reviewed feedback on that patch
there. It may make sense however to define clearly what you mean by
why the flag is being introduced by documenting the use case, ie what
you describe here. Other regulatory bodies may follow and it helps to
provide context here.

My review below.

> Signed-off-by: David Spinadel <david.spinadel@intel.com>
> Signed-off-by: Ilan Peer <ilan.peer@intel.com>
> ---
>  include/net/cfg80211.h |    4 +-
>  net/mac80211/ibss.c    |    2 +-
>  net/wireless/Kconfig   |   10 +++++
>  net/wireless/chan.c    |   98 ++++++++++++++++++++++++++++++++++++++++++++----
>  net/wireless/mesh.c    |    2 +-
>  net/wireless/nl80211.c |    8 ++--
>  net/wireless/trace.h   |   11 ++++--
>  7 files changed, 118 insertions(+), 17 deletions(-)
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index f0badeb..17d693d 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -4070,12 +4070,14 @@ void cfg80211_report_obss_beacon(struct wiphy *wiphy,
>   * cfg80211_reg_can_beacon - check if beaconing is allowed
>   * @wiphy: the wiphy
>   * @chandef: the channel definition
> + * @p2p_go: if the interface type is a P2P GO
>   *
>   * Return: %true if there is no secondary channel or the secondary channel(s)
>   * can be used for beaconing (i.e. is not a radar channel etc.)
>   */
>  bool cfg80211_reg_can_beacon(struct wiphy *wiphy,
> -                            struct cfg80211_chan_def *chandef);
> +                            struct cfg80211_chan_def *chandef,
> +                            bool p2p_go);
>
>  /*
>   * cfg80211_ch_switch_notify - update wdev channel and notify userspace
> diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
> index ea7b9c2..1e0fac1 100644
> --- a/net/mac80211/ibss.c
> +++ b/net/mac80211/ibss.c
> @@ -82,7 +82,7 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
>         sdata->drop_unencrypted = capability & WLAN_CAPABILITY_PRIVACY ? 1 : 0;
>
>         chandef = ifibss->chandef;
> -       if (!cfg80211_reg_can_beacon(local->hw.wiphy, &chandef)) {
> +       if (!cfg80211_reg_can_beacon(local->hw.wiphy, &chandef, false)) {
>                 chandef.width = NL80211_CHAN_WIDTH_20;
>                 chandef.center_freq1 = chan->center_freq;
>         }
> diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
> index de76078..d9e2be7 100644
> --- a/net/wireless/Kconfig
> +++ b/net/wireless/Kconfig
> @@ -102,6 +102,16 @@ config CFG80211_REG_CELLULAR_HINTS
>           This option adds support for drivers that can receive regulatory
>           hints from cellular base stations
>
> +config CFG80211_REG_SOFT_CONFIGURATIONS
> +       bool "cfg80211 support for GO operation on additional channels"
> +       depends on CFG80211 && CFG80211_CERTIFICATION_ONUS
> +       ---help---
> +         This option enables the operation of a P2P Group Owner on
> +         additional channels, if there is a clear assessment that
> +         the platform device operates in an indoor environment or
> +         in case that there is an additional BSS interface which is
> +         connected to an AP which is an indoor device.
> +

I like this approach, indeed this is great work and reflects usage of
the onus kconfig option appropriately in this case due dilligence
required more in part on userspace / other components for full
regulatory compliance.

>  config CFG80211_DEFAULT_PS
>         bool "enable powersave by default"
>         depends on CFG80211
> diff --git a/net/wireless/chan.c b/net/wireless/chan.c
> index 50f6195..92d9e3c 100644
> --- a/net/wireless/chan.c
> +++ b/net/wireless/chan.c
> @@ -457,18 +457,102 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy,
>  }
>  EXPORT_SYMBOL(cfg80211_chandef_usable);
>
> +#ifdef CPTCFG_CFG80211_REG_SOFT_CONFIGURATIONS
> +static int cfg80211_get_unii_band(int freq)
> +{
> +       /* UNII-1 */
> +       if (freq >= 5150 && freq <= 5250)
> +               return 0;
> +
> +       /* UNII-2 */
> +       if (freq > 5250 && freq <= 5350)
> +               return 1;
> +
> +       /* UNII-2E */
> +       if (freq >= 5470 && freq <= 5725)
> +               return 2;
> +
> +       /* UNII-3 */
> +       if (freq > 5725 && freq <= 5825)
> +               return 3;
> +
> +       WARN_ON(1);
> +       return -EINVAL;
> +}
> +#endif

#else?

Are you aware of UNII-1, UNII-2, UNII-2E, UNII-3 are specific world
regulatory language bands? When I last tried to look for a clear
definition I could not find a clear definition of them and its why on
the ath module on for QCA modules I state "we call these" in reference
to the UNII nomenclature. If we can get a clear resource for its
definition that would help here.

> +
> +/* For GO only, check if the channel can be used under permissive conditions
> + * mandated by the FCC, i.e., the channel is marked as:

Ah -- note - FCC, you are making an FCC specific rule global, that
doesn't seems right. The implementation should reflect that *some*
regulatory bodies are implicating software requirements for GO
operation and in that case this tries to implement such known current
interpretations.

Hope is that regulatory bodies will stick to this singular
interpretation / preference when required.

So my point: your code treats this appropriately as agnostic to the
regulatory body but your comments do not, just modify the comments
more to make it more agnostic.

> + * 1. Indoor only: a GO can be operational on such a channel, iff there is
> + *    clear assessment that the platform device is indoor.
> + * 2. Concurrent GO: a GO can be operational on such a channel, iff there is an
> + *    additional station interface connected to an AP on this channel.
> + *
> + * TODO: The function is too permissive, as it does not verify the platform
> + * device type is indeed indoor, or that the AP is indoor/AC powered.

So to do this properly we need an eventual userspace API to throw to
kernelspace if we are AC powered? We'll need this to enhance this
routine here?

> + */
> +static bool cfg80211_can_go_use_chan(struct cfg80211_registered_device *rdev,
> +                                    struct ieee80211_channel *chan)
> +{
> +#ifdef CPTCFG_CFG80211_REG_SOFT_CONFIGURATIONS
> +       struct wireless_dev *wdev_iter;
> +
> +       ASSERT_RTNL();
> +
> +       if (!(chan->flags & (IEEE80211_CHAN_INDOOR_ONLY |
> +                            IEEE80211_CHAN_GO_CONCURRENT)))
> +               return false;
> +
> +       if (chan->band == IEEE80211_BAND_60GHZ)
> +               return false;
> +
> +       list_for_each_entry(wdev_iter, &rdev->wdev_list, list) {
> +               struct ieee80211_channel *other_chan = NULL;
> +
> +               if (wdev_iter->iftype != NL80211_IFTYPE_STATION ||
> +                   (!netif_running(wdev_iter->netdev)))
> +                               continue;
> +
> +
> +               wdev_lock(wdev_iter);
> +               if (wdev_iter->current_bss)
> +                       other_chan = wdev_iter->current_bss->pub.channel;
> +               wdev_unlock(wdev_iter);
> +
> +               if (!other_chan)
> +                       continue;
> +
> +               if (chan == other_chan)
> +                       return true;
> +               else if ((chan->band == IEEE80211_BAND_5GHZ) &&
> +                        (cfg80211_get_unii_band(chan->center_freq) ==
> +                         cfg80211_get_unii_band(other_chan->center_freq)))
> +                       return true;
> +       }
> +#endif
> +       return false;
> +}

Please wrap code as follows:

#ifdef FOO
static int foo(void)
{
  return true;
}
#else
static int foo(void)
  return false;
}
#endif

In the meantime, while you get all your patch sets properly developed
I'd recommend to define the code returning false there strictly or
perhaps for any flag on the channel requiring DFS / no-ibss, or
passive scan. The stricter case, defining false always, seems to be
what you are suggesting here.

Do you have a white list that can exclude some channels for now
globally or somehow as all this lines up?

  Luis

Re: [wireless-regdb] [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional channels

[Luis R. Rodriguez]

On Tue, Jul 2, 2013 at 5:28 AM, Ilan Peer <ilan.peer@intel.com> wrote:
> From: David Spinadel <david.spinadel@intel.com>
>
> Allow GO operation on a channel marked with
> IEEE80211_CHAN_INDOOR_ONLY or IEEE80211_CHAN_GO_CONCURRENT
> iff there is an active station interface that is associated to
> an AP operating on this channel.
>
> Note that this is a permissive approach to the FCC definitions,
> that require a clear assessment that either the platform device
> is an indoor device, or the device operating the AP is an indoor
> device, i.e., AC powered.
> It is assumed that these restrictions are enforced by user space.
> Furthermore, it is assumed, that if the conditions that allowed for
> the operation of the GO on such a channel change, it is the
> responsibility of user space to evacuate the GO from the channel.

In the context of strict regulatory data we currently do not
differentiate specifically between a device that can initiate
radiation between AP and Group Owner (GO) but in your earlier patches
you proposed a way to do that. I reviewed feedback on that patch
there. It may make sense however to define clearly what you mean by
why the flag is being introduced by documenting the use case, ie what
you describe here. Other regulatory bodies may follow and it helps to
provide context here.

My review below.

> Signed-off-by: David Spinadel <david.spinadel@intel.com>
> Signed-off-by: Ilan Peer <ilan.peer@intel.com>
> ---
>  include/net/cfg80211.h |    4 +-
>  net/mac80211/ibss.c    |    2 +-
>  net/wireless/Kconfig   |   10 +++++
>  net/wireless/chan.c    |   98 ++++++++++++++++++++++++++++++++++++++++++++----
>  net/wireless/mesh.c    |    2 +-
>  net/wireless/nl80211.c |    8 ++--
>  net/wireless/trace.h   |   11 ++++--
>  7 files changed, 118 insertions(+), 17 deletions(-)
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index f0badeb..17d693d 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -4070,12 +4070,14 @@ void cfg80211_report_obss_beacon(struct wiphy *wiphy,
>   * cfg80211_reg_can_beacon - check if beaconing is allowed
>   * @wiphy: the wiphy
>   * @chandef: the channel definition
> + * @p2p_go: if the interface type is a P2P GO
>   *
>   * Return: %true if there is no secondary channel or the secondary channel(s)
>   * can be used for beaconing (i.e. is not a radar channel etc.)
>   */
>  bool cfg80211_reg_can_beacon(struct wiphy *wiphy,
> -                            struct cfg80211_chan_def *chandef);
> +                            struct cfg80211_chan_def *chandef,
> +                            bool p2p_go);
>
>  /*
>   * cfg80211_ch_switch_notify - update wdev channel and notify userspace
> diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
> index ea7b9c2..1e0fac1 100644
> --- a/net/mac80211/ibss.c
> +++ b/net/mac80211/ibss.c
> @@ -82,7 +82,7 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
>         sdata->drop_unencrypted = capability & WLAN_CAPABILITY_PRIVACY ? 1 : 0;
>
>         chandef = ifibss->chandef;
> -       if (!cfg80211_reg_can_beacon(local->hw.wiphy, &chandef)) {
> +       if (!cfg80211_reg_can_beacon(local->hw.wiphy, &chandef, false)) {
>                 chandef.width = NL80211_CHAN_WIDTH_20;
>                 chandef.center_freq1 = chan->center_freq;
>         }
> diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
> index de76078..d9e2be7 100644
> --- a/net/wireless/Kconfig
> +++ b/net/wireless/Kconfig
> @@ -102,6 +102,16 @@ config CFG80211_REG_CELLULAR_HINTS
>           This option adds support for drivers that can receive regulatory
>           hints from cellular base stations
>
> +config CFG80211_REG_SOFT_CONFIGURATIONS
> +       bool "cfg80211 support for GO operation on additional channels"
> +       depends on CFG80211 && CFG80211_CERTIFICATION_ONUS
> +       ---help---
> +         This option enables the operation of a P2P Group Owner on
> +         additional channels, if there is a clear assessment that
> +         the platform device operates in an indoor environment or
> +         in case that there is an additional BSS interface which is
> +         connected to an AP which is an indoor device.
> +

I like this approach, indeed this is great work and reflects usage of
the onus kconfig option appropriately in this case due dilligence
required more in part on userspace / other components for full
regulatory compliance.

>  config CFG80211_DEFAULT_PS
>         bool "enable powersave by default"
>         depends on CFG80211
> diff --git a/net/wireless/chan.c b/net/wireless/chan.c
> index 50f6195..92d9e3c 100644
> --- a/net/wireless/chan.c
> +++ b/net/wireless/chan.c
> @@ -457,18 +457,102 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy,
>  }
>  EXPORT_SYMBOL(cfg80211_chandef_usable);
>
> +#ifdef CPTCFG_CFG80211_REG_SOFT_CONFIGURATIONS
> +static int cfg80211_get_unii_band(int freq)
> +{
> +       /* UNII-1 */
> +       if (freq >= 5150 && freq <= 5250)
> +               return 0;
> +
> +       /* UNII-2 */
> +       if (freq > 5250 && freq <= 5350)
> +               return 1;
> +
> +       /* UNII-2E */
> +       if (freq >= 5470 && freq <= 5725)
> +               return 2;
> +
> +       /* UNII-3 */
> +       if (freq > 5725 && freq <= 5825)
> +               return 3;
> +
> +       WARN_ON(1);
> +       return -EINVAL;
> +}
> +#endif

#else?

Are you aware of UNII-1, UNII-2, UNII-2E, UNII-3 are specific world
regulatory language bands? When I last tried to look for a clear
definition I could not find a clear definition of them and its why on
the ath module on for QCA modules I state "we call these" in reference
to the UNII nomenclature. If we can get a clear resource for its
definition that would help here.

> +
> +/* For GO only, check if the channel can be used under permissive conditions
> + * mandated by the FCC, i.e., the channel is marked as:

Ah -- note - FCC, you are making an FCC specific rule global, that
doesn't seems right. The implementation should reflect that *some*
regulatory bodies are implicating software requirements for GO
operation and in that case this tries to implement such known current
interpretations.

Hope is that regulatory bodies will stick to this singular
interpretation / preference when required.

So my point: your code treats this appropriately as agnostic to the
regulatory body but your comments do not, just modify the comments
more to make it more agnostic.

> + * 1. Indoor only: a GO can be operational on such a channel, iff there is
> + *    clear assessment that the platform device is indoor.
> + * 2. Concurrent GO: a GO can be operational on such a channel, iff there is an
> + *    additional station interface connected to an AP on this channel.
> + *
> + * TODO: The function is too permissive, as it does not verify the platform
> + * device type is indeed indoor, or that the AP is indoor/AC powered.

So to do this properly we need an eventual userspace API to throw to
kernelspace if we are AC powered? We'll need this to enhance this
routine here?

> + */
> +static bool cfg80211_can_go_use_chan(struct cfg80211_registered_device *rdev,
> +                                    struct ieee80211_channel *chan)
> +{
> +#ifdef CPTCFG_CFG80211_REG_SOFT_CONFIGURATIONS
> +       struct wireless_dev *wdev_iter;
> +
> +       ASSERT_RTNL();
> +
> +       if (!(chan->flags & (IEEE80211_CHAN_INDOOR_ONLY |
> +                            IEEE80211_CHAN_GO_CONCURRENT)))
> +               return false;
> +
> +       if (chan->band == IEEE80211_BAND_60GHZ)
> +               return false;
> +
> +       list_for_each_entry(wdev_iter, &rdev->wdev_list, list) {
> +               struct ieee80211_channel *other_chan = NULL;
> +
> +               if (wdev_iter->iftype != NL80211_IFTYPE_STATION ||
> +                   (!netif_running(wdev_iter->netdev)))
> +                               continue;
> +
> +
> +               wdev_lock(wdev_iter);
> +               if (wdev_iter->current_bss)
> +                       other_chan = wdev_iter->current_bss->pub.channel;
> +               wdev_unlock(wdev_iter);
> +
> +               if (!other_chan)
> +                       continue;
> +
> +               if (chan == other_chan)
> +                       return true;
> +               else if ((chan->band == IEEE80211_BAND_5GHZ) &&
> +                        (cfg80211_get_unii_band(chan->center_freq) ==
> +                         cfg80211_get_unii_band(other_chan->center_freq)))
> +                       return true;
> +       }
> +#endif
> +       return false;
> +}

Please wrap code as follows:

#ifdef FOO
static int foo(void)
{
  return true;
}
#else
static int foo(void)
  return false;
}
#endif

In the meantime, while you get all your patch sets properly developed
I'd recommend to define the code returning false there strictly or
perhaps for any flag on the channel requiring DFS / no-ibss, or
passive scan. The stricter case, defining false always, seems to be
what you are suggesting here.

Do you have a white list that can exclude some channels for now
globally or somehow as all this lines up?

  Luis

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

RE: [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional channels

[Peer, Ilan]

> -----Original Message-----
> From: Jouni Malinen [mailto:j@w1.fi]
> Sent: Monday, July 08, 2013 13:04
> To: Peer, Ilan
> Cc: linux-wireless@vger.kernel.org; mcgrof@do-not-panic.com; Spinadel, David
> Subject: Re: [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional
> channels
> 
> On Tue, Jul 02, 2013 at 03:28:15PM +0300, Ilan Peer wrote:
> > Allow GO operation on a channel marked with
> IEEE80211_CHAN_INDOOR_ONLY
> > or IEEE80211_CHAN_GO_CONCURRENT iff there is an active station
> > interface that is associated to an AP operating on this channel.
> >
> > Note that this is a permissive approach to the FCC definitions, that
> > require a clear assessment that either the platform device is an
> > indoor device, or the device operating the AP is an indoor device,
> > i.e., AC powered.
> > It is assumed that these restrictions are enforced by user space.
> 
> The introduction in 0/3 mentioned DFS, but I did not see it being addressed in
> any of the actual changes. Is this only for indoors vs.
> outdoors?
>

The DFS was mentioned in 0/3 in the context of an example for a case where a device can support WFD on bands where an authorized master is operating. The example assumes that the master has radar detection capabilities and is able to evacuate its operating channel if needed (which must be followed by the device also evicting the WFD operation from this channel). 

The purpose of this patch was to allow the instantiation of a GO on channels marked as indoor/Concurrent GO assuming some conditions are met, ignoring the NO_IBSS and PASSIVE channels. I intend to implement to full restriction logic in the wpa_supplicant (based on the device type etc.), and also handle the actual indication that this channel can no longer be used, eviction and new channel selection in the wpa_supplicant.

> > Furthermore, it is assumed, that if the conditions that allowed for
> > the operation of the GO on such a channel change, it is the
> > responsibility of user space to evacuate the GO from the channel.
> 
> Do you have plans or changes to address this? I'd assume wpa_supplicant could
> stop the group on channel list changes, but I don't think it does that currently.

Yes. This is currently WIP :)

RE: [PATCH 1/3] [RFC] cfg80211: Add indoor only and GO concurrent channel attributes

[Peer, Ilan]

SGkgTHVpcywNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBXaWxsIG5lZWQgc29tZSBtb3JlIHRp
bWUgdG8gbG9vayBhdCB5b3VyIHN1Z2dlc3Rpb25zIGJlbG93IDopDQoNClJlZ2FyZHMsDQoNCkls
YW4uDQoNCj4gDQo+IE9uIFR1ZSwgSnVsIDIsIDIwMTMgYXQgNToyOCBBTSwgSWxhbiBQZWVyIDxp
bGFuLnBlZXJAaW50ZWwuY29tPiB3cm90ZToNCj4gPiBGcm9tOiBEYXZpZCBTcGluYWRlbCA8ZGF2
aWQuc3BpbmFkZWxAaW50ZWwuY29tPg0KPiA+DQo+ID4gVGhlIEZDQyBhcmUgY2xhcmlmeWluZyBz
b21lIHNvZnQgY29uZmlndXJhdGlvbiByZXF1aXJlbWVudHMsIHdoaWNoDQo+ID4gYW1vbmcgb3Ro
ZXIgaW5jbHVkZXMgdGhlIGZvbGxvd2luZzoNCj4gPg0KPiA+IDEuIENvbmN1cnJlbnQgR08gb3Bl
cmF0aW9uLCB3aGVyZSBkZXZpY2VzIG1heSBzdXBwb3J0IFdGRCBpbg0KPiA+ICAgIGJhbmRzIHdo
ZXJlIGFuIGF1dGhvcml6ZWQgbWFzdGVyIChmb3IgZXhhbXBsZSB3aXRoIERGUyBhbmQNCj4gPiAg
ICBERlMgYW5kIHJhZGFyIGRldGVjdGlvbiBjYXBhYmlsaXR5IGluIHRoZSBVTklJIGJhbmQpIGlz
IG9wZXJhdGluZy4NCj4gDQo+IElzIFdGRCBXaUZpIERpc3BsYXk/IElzIHRoZXJlIGFueSBzdHJp
Y3QgcmVsYXRpb25zaGlwIGhlcmUgdG8gV0ZEIGFuZCBHTyBhbmQNCj4gcmVndWxhdG9yeSBvciBp
cyBXRkQganVzdCBhIHVzZSBjYXNlIGV4YW1wbGU/IEFyZSB5b3UgaW5kaWNhdGluZyB0aGF0IHRo
ZSBGQ0MNCj4gaXMgbWFraW5nIHNwZWNpYWwgcnVsZXMgZm9yIGNhc2VzIGluIHNwZWNpZmljIGJh
bmRzIHdoZXJlIEdPICpjYW4qIGNvLWV4aXN0IHdpdGgNCj4gb3RoZXIgR08gZGV2aWNlcyA/DQoN
CldGRCBpcyBXaUZpIGRpcmVjdCBpbiB0aGlzIGNvbnRleHQuIEkgZG8gbm90IHRoaW5rIHRoYXQg
dGhlIEZDQyBhcmUgbWFraW5nIHNwZWNpYWwgcnVsZXMgb25seSBmb3IgR08gc3BlY2lmaWMgc2Nl
bmFyaW9zIGJ1dCBhIG1vcmUgZ2VuZXJhbCBhcHByb2FjaCB3aGVyZSAiY29tcGxpYW5jZSBtYXkg
YmUgYWNoaWV2ZWQgdW5kZXIgdGhlIGd1aWRhbmNlIG9mIGFuIGF1dGhvcml6ZWQgbWFzdGVyIi4g
VGhlIFdGRC9QMlAgR08gY2FzZSBpcyBvbmx5IGFuIGV4YW1wbGUuDQoNCj4gWW91IGFubm90YXRl
IHRoYXQgdGhpcyBpcyBzb21laG93IHJlbGF0ZWQgdG8gREZTLCBhcmUgdGhlIEdPIGNvbmN1cnJl
bnQgcnVsZXMNCj4gdGhhdCB0aGUgRkNDIGlzIGRlZmluaW5nIG9ubHkgYXBwbGljYWJsZSB0byBE
RlMgZnJlcXVlbmN5IHJhbmdlcz8gSWYgc28gd291bGQgaXQNCj4gc3VmZmljZSB0byBvbmx5IHVz
ZSBERlMgZmxhZyA/IE9yIGFyZSB0aGVyZSBvdGhlciBzcGVjaWFsIGNhc2VzIGJleW9uZCBERlMN
Cj4gZnJlcXVlbmN5IHJhbmdlcyB0aGF0IHRoZSBGQ0MgaXMgY3JlYXRpbmcgc3BlY2lhbCBoYW5k
bGluZz8NCj4NCg0KREZTIHdhcyBnaXZlbiBoZXJlIGFzIGFuIGV4YW1wbGUuIEdlbmVyYWxseSwg
SSB0aGluayB0aGF0IHRoZSBjaGFuZ2VzIHRoYXQgdGhlIEZDQyBhcmUgbWFraW5nIGFyZSB0YXJn
ZXRpbmcgdmFyaW91cyBzY2VuYXJpb3MgYW5kIHZhcmlvdXMgUkYgZGV2aWNlcyAoZm9yIGV4YW1w
bGUgdGhvc2UgZGVmaW5lZCBpbiBwYXJ0IDE1IG9mIENGUiB0aXRsZSA0NykuDQogDQo+IEFwYXJ0
IGZyb20gdGhlIEZDQyBhcmUgeW91IGF3YXJlIG9mIHNwZWNpYWwgY2FzZXMgaGFuZGxpbmcgZm9y
IG90aGVyDQo+IHJlZ3VsYXRvcnkgYm9kaWVzIGF0IHRoaXMgcG9pbnQ/DQoNCk5vdCB0aGF0IEkn
bSBhd2FyZSBvZi4gQWRkaW5nIHNvbWUgbW9yZSBwZW9wbGUgdGhhdCBtaWdodCBrbm93IG1vcmUu
DQoNCj4gDQo+IE5vdGUgdGhhdCB3ZSBoYXZlIGFscmVhZHkgdGhlc2Ugb24gcmVnZGIuaCBmcm9t
IENSREE6DQo+IA0KPiANCj4gLyoNCj4gICogVGhlIExpbnV4IG1hcCBkZWZpbmVkIGluIDxsaW51
eC91YXBpL25sODAyMTEuaD4gZW51bQ0KPiBubDgwMjExX3JlZ19ydWxlX2ZsYWdzICAqLyBlbnVt
IHJlZ19ydWxlX2ZsYWdzIHsNCj4gICAgICAgICBSUkZfTk9fT0ZETSAgICAgICAgICAgICA9IDE8
PDAsIC8qIE9GRE0gbW9kdWxhdGlvbiBub3QgYWxsb3dlZCAqLw0KPiAgICAgICAgIFJSRl9OT19D
Q0sgICAgICAgICAgICAgID0gMTw8MSwgLyogQ0NLIG1vZHVsYXRpb24gbm90IGFsbG93ZWQgKi8N
Cj4gICAgICAgICBSUkZfTk9fSU5ET09SICAgICAgICAgICA9IDE8PDIsIC8qIGluZG9vciBvcGVy
YXRpb24gbm90IGFsbG93ZWQgKi8NCj4gICAgICAgICBSUkZfTk9fT1VURE9PUiAgICAgICAgICA9
IDE8PDMsIC8qIG91dGRvb3Igb3BlcmF0aW9uIG5vdCBhbGxvd2VkICovDQo+ICAgICAgICAgUlJG
X0RGUyAgICAgICAgICAgICAgICAgPSAxPDw0LCAvKiBERlMgc3VwcG9ydCBpcyByZXF1aXJlZCB0
byBiZQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICogdXNlZCAq
Lw0KPiAgICAgICAgIFJSRl9QVFBfT05MWSAgICAgICAgICAgID0gMTw8NSwgLyogdGhpcyBpcyBv
bmx5IGZvciBQb2ludCBUbyBQb2ludA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICogbGlua3MgKi8NCj4gICAgICAgICBSUkZfUFRNUF9PTkxZICAgICAgICAgICA9
IDE8PDYsIC8qIHRoaXMgaXMgb25seSBmb3IgUG9pbnQgVG8gTXVsdGkNCj4gICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqIFBvaW50IGxpbmtzICovDQo+ICAgICAgICAg
UlJGX1BBU1NJVkVfU0NBTiAgICAgICAgPSAxPDw3LCAvKiBwYXNzaXZlIHNjYW4gaXMgcmVxdWly
ZWQgKi8NCj4gICAgICAgICBSUkZfTk9fSUJTUyAgICAgICAgICAgICA9IDE8PDgsIC8qIElCU1Mg
aXMgbm90IGFsbG93ZWQgKi8NCj4gfTsNCj4gDQo+IEhpc3RvcmljYWxseSB3ZSBkb24ndCBkaXN0
aW5ndWlzaCB0aGVuIGEgdHlwZSBvZiA4MDIuMTEgZGV2aWNlIHRoYXQgaW5pdGlhdGVzDQo+IHJh
ZGlhdGlvbiBleGNlcHQgZm9yIHRoZSBOT19JQlNTIHJ1bGUsIGJ1dCB0aGF0IHJ1bGUgY2FuIGJl
IHRyZWF0ZWQgbW9yZSBhcw0KPiBsZWdhY3kgZ2l2ZW4gdGhhdCB0aGUgaW50ZW50IGFuZCBtb3Rp
dmF0aW9uIGJlaGluZCB0aGF0IHdhcyB0aGF0IHNvbWUgT0RNcw0KPiBzaW1wbHkgcHJlZmVycmVk
IGFuIGludGVycHJldGF0aW9uIG9mIHJlZ3VsYXRvcnkgcnVsZXMgYW5kIHdlICpjdXJyZW50bHkq
IGRvbid0DQo+IHVzZSB0aGF0IGluIG11Y2ggcGxhY2VzIG90aGVyIHRoYW4gY3VzdG9tIHJlZ3Vs
YXRvcnkgZG9tYWlucyBkZWZpbmVkIGluIHRoZQ0KPiBrZXJuZWwuIFRoZSBQVFBfT05MWSBhbmQg
UFRNUF9PTkxZIGFyZSBleGFtcGxlIG90aGVyIHJ1bGVzIHRoYXQgY291bGQNCj4gcG90ZW50aWFs
bHkgaGF2ZSBiZWVuIHVzZWQgYnV0IHRvIHRoaXMgZGF5IHdlIGhhdmVuJ3QgZm91bmQgYSB1c2Ug
Y2FzZSBmb3IgaXQNCj4gZ2l2ZW4gdGhhdCB0eXBpY2FsIDgwMi4xMSBkZXZpY2VzIGFyZSBQVE1Q
Lg0KPiANCj4gSSBtZW50aW9uIHRoZSBOT19JQlNTIGNhc2UgYXMgSSdkIGxpa2UgdG8gdHJ5IHRv
IGF2b2lkIGFkZGluZyBHTyBzcGVjaWZpYyBmbGFnIGlmDQo+IHdlIGNhbiBmaWd1cmUgb3V0IGEg
d2F5IHRvIG1ha2UgdGhpcyBtb3JlIGdlbmVyaWMuIEF0IHRoaXMgcG9pbnQgZm9yIGV4YW1wbGUg
SQ0KPiB0aGluayBhIG1vcmUgYXBwcm9wcmlhdGUgZmxhZyBpcyBpbiBwbGFjZToNCj4gDQoNCkFj
dHVhbGx5LCB0aGlzIHNob3VsZCBiZSBhIEdPIG9ubHkgZmxhZywgbWVhbmluZyB0aGF0IHN1Y2gg
cmVsYXhhdGlvbiBzaG91bGQgbm90IGJlIHZhbGlkIGZvciBzb2Z0IEFQLCBJQlNTIG9yIG1lc2gu
IFRoZSBpbnRlbnRpb24gaGVyZSBpcyBsaW1pdCB0aGUgZXh0ZW5kIG9mIHRoZSBjZWxsLCBhbmQg
cHJldmVudCBkYWlzeSBjaGFpbiBzY2VuYXJpb3MgKGFzc3VtZSB0aGF0IHlvdSBhbGxvdyBhIHNv
ZnQgQVAgb24gc3VjaCBhIGNoYW5uZWwgYW5kIHRoYXQgYSBjbGllbnQgYXNzb2NpYXRlZCB0byBp
dCwgYW5kIHRoZW4gdGhhdCBkZXZpY2UgY2FuIGFsc28gc3RhcnQgYSBzb2Z0IEFQIG9uIHRoZSBj
aGFubmVsIC4uLi4pLiBBbnl3YXksIEknbGwgbmVlZCB0byBoYXZlIGFub3RoZXIgbG9vayBhdCB0
aGlzIChtaWdodCBiZSBwZXJtaXNzaWJsZSBmb3IgSUJTUyAuLi4pDQoNCj4gICAqIE5PX0lSIC0g
Y2Fubm90IGluaXRpYXRlIHJhZGlhdGlvbg0KPiANCj4gQW5kIHRoaXMgY291bGQgaW4gdHVybiBl
bmQgdXAgcmVwbGFjaW5nIG1vc3QgdXNlIGNhc2VzIG9mIE5PX0lCU1MgYW5kDQo+IFBBU1NJVkVf
U0NBTiBnaXZuZSB0aGF0IGJvdGggb2YgdGhlc2UgaW1wbHkgd2UgY2Fubm90IGluaXRpYXRlIHJh
ZGlhdGlvbg0KPiB1bmxlc3Mgc3BlY2lmaWMgdGhpbmdzIGFyZSBkb25lLiBJIHdvbmRlciBpZiB3
ZSBjYW4gZm9sZCB0aGUgR08gZmxhZyBpbnRvIHRoaXMgYW5kDQo+IHBlcmhhcHMgcmVuYW1lIHRo
ZSBOT19JQlNTIGZsYWcgdG8gdGhlIEdPIG9uZS4NCj4gDQo+IEFsc28gbm90ZSB0aGF0IHdlIHNo
b3VsZCBrZWVwIHRoZSBmbGFncyBpbiBzeW5jIHdpdGggdGhlIHVhcGkgbmw4MDIxMSBjaGFuZ2Uu
DQo+IFBsZWFzZSByZXZpZXcgdGhlc2Ugc3VnZ2VzdGlvbnMgYW5kIGxldCBtZSBrbm93IHdoYXQg
eW91IHRoaW5rLg0KPiANCg0KU3VyZS4gV2lsbCBuZWVkIHRvIHRha2UgYSBkZWVwZXIgbG9vayBh
dCB0aGlzLg0KDQo+ID4gMi4gSW5kb29yIG9wZXJhdGlvbiwgd2hlcmUgaW4gYmFuZHMgcmVxdWly
aW5nIGluZG9vciBvcGVyYXRpb24sIHRoZQ0KPiA+ICAgIGRldmljZSBtdXN0IGJlIHByb2dyYW1t
ZWQgdG8gZGV0ZWN0IGluZG9vciBvcGVyYXRpb24sIG9yDQo+ID4gICAgLSBEZXZpY2UgbXVzdCBi
ZSBjb25uZWN0ZWQgdG8gQUMgUG93ZXINCj4gDQo+IERvZXMgYW55b25lICBrbm93IGlmIHRoZSBG
Q0MgY29uc2lkZXJzICJpbmRvb3IiIGlmIHdlIHBvd2VyIGEgZGV2aWNlIHRocm91Z2gNCj4gdGhl
IGNhciBvbiBBQyBwb3dlciB0aHJvdWdoIGEgY29udmVydGVyID8gQXJlIHdlIHdpbGxpbmcgdG8g
aWdub3JlIHRoYXQgY29ybmVyDQo+IGNhc2U/DQoNCk5vLiBBQyBwb3dlciBtZWFucyAibWFpbnMi
IGFuZCBub3QgdGhyb3VnaCBwb3J0YWJsZSBEQyBjb252ZXJ0ZXJzIChzZWUgc2xpZGUgMTIgaW4g
aHR0cHM6Ly9hcHBzLmZjYy5nb3YvZWFzL2NvbW1lbnRzL0dldFB1Ymxpc2hlZERvY3VtZW50Lmh0
bWw/aWQ9MzI3JnRuPSA1MjgxMjIpLiBJdCB3b3VsZCBiZSB1cCB0byB0aGUgdXNlciBzcGFjZSB0
byBpZGVudGlmeSB0aGUgZGV2aWNlIHR5cGUgZXRjLiBhbmQgaWRlbnRpZnkgaWYgdGhpcyBhIHRy
dWx5IEFDIHBvd2VyZWQgQVAuDQoNCj4gDQo+ID4gICAgLSBEZXZpY2UgbXVzdCBiZSB1bmRlciB0
aGUgY29udHJvbCBvZiBhIGxvY2FsIG1hc3RlciB0aGF0IGlzIGFjdGluZw0KPiANCj4gSW50ZXJl
c3RpbmcsIHNvIHNvbWUgQVBJcyB3b3VsZCBiZSBkZWZpbmVkLCBJIHRha2UgaXQgb24gaG9zdGFw
ZCB0byBkbyB0aGUNCj4gcHJvcGVyIGNhbGxiYWNrcyB0byAnc2xhdmUnIHR5cGUgb2YgZGV2aWNl
cyB0aGF0IGRlcGVuZCBvbiB0aGUgbG9jYWwgbWFzdGVyKHMpLiBJDQo+IGNvdWxkIGVudmlzaW9u
IHRoaXMgYmVpbmcgaW1wbGVtZW50ZWQgb24gaG9zdGFwZCBieSBleHBhbmRpbmcgdGhlIEFQDQo+
IGludGVyZmFjZSB0eXBlIGFuZCBhc3NvY2lhdGluZyAnc2xhdmUnIGRldmljZXMgYW5kIGNhbGxi
YWNrcyBmb3IgdXBkYXRlcyBvbiBBUA0KPiBkZXZpY2UgdXBkYXRlcyAoY2hhbm5lbCBjaGFuZ2Vz
LCBhbmQgc28gb24pLiBJcyB0aGlzIHdvcmsgYmVpbmcgcGxhbm5lZD8NCg0KWWVzLiBXZSBoYXZl
IHBsYW5zIHRvIGluY29ycG9yYXRlIG1vcmUgbG9naWMgdG8gaG9zdGFwIChjdXJyZW50bHkgaW50
byB3cGFfc3VwcGxpY2FudCBmb3IgUDJQIHVzZSBjYXNlcykuDQoNCg0K

RE: [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional channels

[Peer, Ilan]

SGkgTHVpcywgDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldyA6KQ0KDQpJbGFuLg0KDQo+ID4gTm90
ZSB0aGF0IHRoaXMgaXMgYSBwZXJtaXNzaXZlIGFwcHJvYWNoIHRvIHRoZSBGQ0MgZGVmaW5pdGlv
bnMsIHRoYXQNCj4gPiByZXF1aXJlIGEgY2xlYXIgYXNzZXNzbWVudCB0aGF0IGVpdGhlciB0aGUg
cGxhdGZvcm0gZGV2aWNlIGlzIGFuDQo+ID4gaW5kb29yIGRldmljZSwgb3IgdGhlIGRldmljZSBv
cGVyYXRpbmcgdGhlIEFQIGlzIGFuIGluZG9vciBkZXZpY2UsDQo+ID4gaS5lLiwgQUMgcG93ZXJl
ZC4NCj4gPiBJdCBpcyBhc3N1bWVkIHRoYXQgdGhlc2UgcmVzdHJpY3Rpb25zIGFyZSBlbmZvcmNl
ZCBieSB1c2VyIHNwYWNlLg0KPiA+IEZ1cnRoZXJtb3JlLCBpdCBpcyBhc3N1bWVkLCB0aGF0IGlm
IHRoZSBjb25kaXRpb25zIHRoYXQgYWxsb3dlZCBmb3INCj4gPiB0aGUgb3BlcmF0aW9uIG9mIHRo
ZSBHTyBvbiBzdWNoIGEgY2hhbm5lbCBjaGFuZ2UsIGl0IGlzIHRoZQ0KPiA+IHJlc3BvbnNpYmls
aXR5IG9mIHVzZXIgc3BhY2UgdG8gZXZhY3VhdGUgdGhlIEdPIGZyb20gdGhlIGNoYW5uZWwuDQo+
IA0KPiBJbiB0aGUgY29udGV4dCBvZiBzdHJpY3QgcmVndWxhdG9yeSBkYXRhIHdlIGN1cnJlbnRs
eSBkbyBub3QgZGlmZmVyZW50aWF0ZQ0KPiBzcGVjaWZpY2FsbHkgYmV0d2VlbiBhIGRldmljZSB0
aGF0IGNhbiBpbml0aWF0ZSByYWRpYXRpb24gYmV0d2VlbiBBUCBhbmQgR3JvdXANCj4gT3duZXIg
KEdPKSBidXQgaW4geW91ciBlYXJsaWVyIHBhdGNoZXMgeW91IHByb3Bvc2VkIGEgd2F5IHRvIGRv
IHRoYXQuIEkNCj4gcmV2aWV3ZWQgZmVlZGJhY2sgb24gdGhhdCBwYXRjaCB0aGVyZS4gSXQgbWF5
IG1ha2Ugc2Vuc2UgaG93ZXZlciB0byBkZWZpbmUNCj4gY2xlYXJseSB3aGF0IHlvdSBtZWFuIGJ5
IHdoeSB0aGUgZmxhZyBpcyBiZWluZyBpbnRyb2R1Y2VkIGJ5IGRvY3VtZW50aW5nIHRoZQ0KPiB1
c2UgY2FzZSwgaWUgd2hhdCB5b3UgZGVzY3JpYmUgaGVyZS4gT3RoZXIgcmVndWxhdG9yeSBib2Rp
ZXMgbWF5IGZvbGxvdyBhbmQgaXQNCj4gaGVscHMgdG8gcHJvdmlkZSBjb250ZXh0IGhlcmUuDQoN
ClN1cmUsIEknbGwgYWRkIHN1Y2ggYSB1c2UgY2FzZSB0byB0aGUgcHJldmlvdXMgcGF0Y2gNCg0K
PiA+IGRpZmYgLS1naXQgYS9uZXQvd2lyZWxlc3MvS2NvbmZpZyBiL25ldC93aXJlbGVzcy9LY29u
ZmlnIGluZGV4DQo+ID4gZGU3NjA3OC4uZDllMmJlNyAxMDA2NDQNCj4gPiAtLS0gYS9uZXQvd2ly
ZWxlc3MvS2NvbmZpZw0KPiA+ICsrKyBiL25ldC93aXJlbGVzcy9LY29uZmlnDQo+ID4gQEAgLTEw
Miw2ICsxMDIsMTYgQEAgY29uZmlnIENGRzgwMjExX1JFR19DRUxMVUxBUl9ISU5UUw0KPiA+ICAg
ICAgICAgICBUaGlzIG9wdGlvbiBhZGRzIHN1cHBvcnQgZm9yIGRyaXZlcnMgdGhhdCBjYW4gcmVj
ZWl2ZSByZWd1bGF0b3J5DQo+ID4gICAgICAgICAgIGhpbnRzIGZyb20gY2VsbHVsYXIgYmFzZSBz
dGF0aW9ucw0KPiA+DQo+ID4gK2NvbmZpZyBDRkc4MDIxMV9SRUdfU09GVF9DT05GSUdVUkFUSU9O
Uw0KPiA+ICsgICAgICAgYm9vbCAiY2ZnODAyMTEgc3VwcG9ydCBmb3IgR08gb3BlcmF0aW9uIG9u
IGFkZGl0aW9uYWwgY2hhbm5lbHMiDQo+ID4gKyAgICAgICBkZXBlbmRzIG9uIENGRzgwMjExICYm
IENGRzgwMjExX0NFUlRJRklDQVRJT05fT05VUw0KPiA+ICsgICAgICAgLS0taGVscC0tLQ0KPiA+
ICsgICAgICAgICBUaGlzIG9wdGlvbiBlbmFibGVzIHRoZSBvcGVyYXRpb24gb2YgYSBQMlAgR3Jv
dXAgT3duZXIgb24NCj4gPiArICAgICAgICAgYWRkaXRpb25hbCBjaGFubmVscywgaWYgdGhlcmUg
aXMgYSBjbGVhciBhc3Nlc3NtZW50IHRoYXQNCj4gPiArICAgICAgICAgdGhlIHBsYXRmb3JtIGRl
dmljZSBvcGVyYXRlcyBpbiBhbiBpbmRvb3IgZW52aXJvbm1lbnQgb3INCj4gPiArICAgICAgICAg
aW4gY2FzZSB0aGF0IHRoZXJlIGlzIGFuIGFkZGl0aW9uYWwgQlNTIGludGVyZmFjZSB3aGljaCBp
cw0KPiA+ICsgICAgICAgICBjb25uZWN0ZWQgdG8gYW4gQVAgd2hpY2ggaXMgYW4gaW5kb29yIGRl
dmljZS4NCj4gPiArDQo+IA0KPiBJIGxpa2UgdGhpcyBhcHByb2FjaCwgaW5kZWVkIHRoaXMgaXMg
Z3JlYXQgd29yayBhbmQgcmVmbGVjdHMgdXNhZ2Ugb2YgdGhlIG9udXMNCj4ga2NvbmZpZyBvcHRp
b24gYXBwcm9wcmlhdGVseSBpbiB0aGlzIGNhc2UgZHVlIGRpbGxpZ2VuY2UgcmVxdWlyZWQgbW9y
ZSBpbiBwYXJ0DQo+IG9uIHVzZXJzcGFjZSAvIG90aGVyIGNvbXBvbmVudHMgZm9yIGZ1bGwgcmVn
dWxhdG9yeSBjb21wbGlhbmNlLg0KPiANCg0KVGhlIGNyZWRpdCBoZXJlIHNob3VsZCBnbyB0byBK
b2hhbm5lcyA6KQ0KDQo+ID4gKyNpZmRlZiBDUFRDRkdfQ0ZHODAyMTFfUkVHX1NPRlRfQ09ORklH
VVJBVElPTlMNCj4gPiArc3RhdGljIGludCBjZmc4MDIxMV9nZXRfdW5paV9iYW5kKGludCBmcmVx
KSB7DQo+ID4gKyAgICAgICAvKiBVTklJLTEgKi8NCj4gPiArICAgICAgIGlmIChmcmVxID49IDUx
NTAgJiYgZnJlcSA8PSA1MjUwKQ0KPiA+ICsgICAgICAgICAgICAgICByZXR1cm4gMDsNCj4gPiAr
DQo+ID4gKyAgICAgICAvKiBVTklJLTIgKi8NCj4gPiArICAgICAgIGlmIChmcmVxID4gNTI1MCAm
JiBmcmVxIDw9IDUzNTApDQo+ID4gKyAgICAgICAgICAgICAgIHJldHVybiAxOw0KPiA+ICsNCj4g
PiArICAgICAgIC8qIFVOSUktMkUgKi8NCj4gPiArICAgICAgIGlmIChmcmVxID49IDU0NzAgJiYg
ZnJlcSA8PSA1NzI1KQ0KPiA+ICsgICAgICAgICAgICAgICByZXR1cm4gMjsNCj4gPiArDQo+ID4g
KyAgICAgICAvKiBVTklJLTMgKi8NCj4gPiArICAgICAgIGlmIChmcmVxID4gNTcyNSAmJiBmcmVx
IDw9IDU4MjUpDQo+ID4gKyAgICAgICAgICAgICAgIHJldHVybiAzOw0KPiA+ICsNCj4gPiArICAg
ICAgIFdBUk5fT04oMSk7DQo+ID4gKyAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4gPiArfQ0KPiA+
ICsjZW5kaWYNCj4gDQo+ICNlbHNlPw0KDQpXZSBjb25zaWRlcmVkIHRoaXMgYXBwcm9hY2gsIGJ1
dCBwcmVmZXJyZWQgdG8gbW92ZSB0aGUgaWZkZWYgaW5zaWRlIHRoZSBmdW5jdGlvbi4NCg0KPiAN
Cj4gQXJlIHlvdSBhd2FyZSBvZiBVTklJLTEsIFVOSUktMiwgVU5JSS0yRSwgVU5JSS0zIGFyZSBz
cGVjaWZpYyB3b3JsZCByZWd1bGF0b3J5DQo+IGxhbmd1YWdlIGJhbmRzPyBXaGVuIEkgbGFzdCB0
cmllZCB0byBsb29rIGZvciBhIGNsZWFyIGRlZmluaXRpb24gSSBjb3VsZCBub3QgZmluZA0KPiBh
IGNsZWFyIGRlZmluaXRpb24gb2YgdGhlbSBhbmQgaXRzIHdoeSBvbiB0aGUgYXRoIG1vZHVsZSBv
biBmb3IgUUNBIG1vZHVsZXMgSQ0KPiBzdGF0ZSAid2UgY2FsbCB0aGVzZSIgaW4gcmVmZXJlbmNl
IHRvIHRoZSBVTklJIG5vbWVuY2xhdHVyZS4gSWYgd2UgY2FuIGdldCBhDQo+IGNsZWFyIHJlc291
cmNlIGZvciBpdHMgZGVmaW5pdGlvbiB0aGF0IHdvdWxkIGhlbHAgaGVyZS4NCj4gDQoNCk1heWJl
IHRoZXNlIGxpbmsgd2lsbCBoZWxwLg0KaHR0cDovL3d3dy5ncG8uZ292L2Zkc3lzL3BrZy9DRlIt
MjAxMC10aXRsZTQ3LXZvbDEveG1sL0NGUi0yMDEwLXRpdGxlNDctdm9sMS1wYXJ0MTUueG1sI3Nl
cW51bTE1LjQwMw0KaHR0cDovL2hyYXVuZm9zcy5mY2MuZ292L2Vkb2NzX3B1YmxpYy9hdHRhY2ht
YXRjaC9GQ0MtMTMtMjJBMS5wZGYNCg0KQW55d2F5LCBJIHdpbGwgdXNlIHlvdXIgJyd3ZSBjYWxs
IHRoZXNlIiBub3RhdGlvbiBhcyB3ZWxsIDopDQoNCj4gPiArDQo+ID4gKy8qIEZvciBHTyBvbmx5
LCBjaGVjayBpZiB0aGUgY2hhbm5lbCBjYW4gYmUgdXNlZCB1bmRlciBwZXJtaXNzaXZlDQo+ID4g
K2NvbmRpdGlvbnMNCj4gPiArICogbWFuZGF0ZWQgYnkgdGhlIEZDQywgaS5lLiwgdGhlIGNoYW5u
ZWwgaXMgbWFya2VkIGFzOg0KPiANCj4gQWggLS0gbm90ZSAtIEZDQywgeW91IGFyZSBtYWtpbmcg
YW4gRkNDIHNwZWNpZmljIHJ1bGUgZ2xvYmFsLCB0aGF0IGRvZXNuJ3Qgc2VlbXMNCj4gcmlnaHQu
IFRoZSBpbXBsZW1lbnRhdGlvbiBzaG91bGQgcmVmbGVjdCB0aGF0ICpzb21lKiByZWd1bGF0b3J5
IGJvZGllcyBhcmUNCj4gaW1wbGljYXRpbmcgc29mdHdhcmUgcmVxdWlyZW1lbnRzIGZvciBHTyBv
cGVyYXRpb24gYW5kIGluIHRoYXQgY2FzZSB0aGlzIHRyaWVzDQo+IHRvIGltcGxlbWVudCBzdWNo
IGtub3duIGN1cnJlbnQgaW50ZXJwcmV0YXRpb25zLg0KPiANCj4gSG9wZSBpcyB0aGF0IHJlZ3Vs
YXRvcnkgYm9kaWVzIHdpbGwgc3RpY2sgdG8gdGhpcyBzaW5ndWxhciBpbnRlcnByZXRhdGlvbiAv
DQo+IHByZWZlcmVuY2Ugd2hlbiByZXF1aXJlZC4NCj4gDQo+IFNvIG15IHBvaW50OiB5b3VyIGNv
ZGUgdHJlYXRzIHRoaXMgYXBwcm9wcmlhdGVseSBhcyBhZ25vc3RpYyB0byB0aGUgcmVndWxhdG9y
eQ0KPiBib2R5IGJ1dCB5b3VyIGNvbW1lbnRzIGRvIG5vdCwganVzdCBtb2RpZnkgdGhlIGNvbW1l
bnRzIG1vcmUgdG8gbWFrZSBpdA0KPiBtb3JlIGFnbm9zdGljLg0KPg0KDQpXaWxsIGZpeC4NCiAN
Cj4gPiArICogMS4gSW5kb29yIG9ubHk6IGEgR08gY2FuIGJlIG9wZXJhdGlvbmFsIG9uIHN1Y2gg
YSBjaGFubmVsLCBpZmYgdGhlcmUgaXMNCj4gPiArICogICAgY2xlYXIgYXNzZXNzbWVudCB0aGF0
IHRoZSBwbGF0Zm9ybSBkZXZpY2UgaXMgaW5kb29yLg0KPiA+ICsgKiAyLiBDb25jdXJyZW50IEdP
OiBhIEdPIGNhbiBiZSBvcGVyYXRpb25hbCBvbiBzdWNoIGEgY2hhbm5lbCwgaWZmIHRoZXJlIGlz
DQo+IGFuDQo+ID4gKyAqICAgIGFkZGl0aW9uYWwgc3RhdGlvbiBpbnRlcmZhY2UgY29ubmVjdGVk
IHRvIGFuIEFQIG9uIHRoaXMgY2hhbm5lbC4NCj4gPiArICoNCj4gPiArICogVE9ETzogVGhlIGZ1
bmN0aW9uIGlzIHRvbyBwZXJtaXNzaXZlLCBhcyBpdCBkb2VzIG5vdCB2ZXJpZnkgdGhlDQo+ID4g
KyBwbGF0Zm9ybQ0KPiA+ICsgKiBkZXZpY2UgdHlwZSBpcyBpbmRlZWQgaW5kb29yLCBvciB0aGF0
IHRoZSBBUCBpcyBpbmRvb3IvQUMgcG93ZXJlZC4NCj4gDQo+IFNvIHRvIGRvIHRoaXMgcHJvcGVy
bHkgd2UgbmVlZCBhbiBldmVudHVhbCB1c2Vyc3BhY2UgQVBJIHRvIHRocm93IHRvDQo+IGtlcm5l
bHNwYWNlIGlmIHdlIGFyZSBBQyBwb3dlcmVkPyBXZSdsbCBuZWVkIHRoaXMgdG8gZW5oYW5jZSB0
aGlzIHJvdXRpbmUNCj4gaGVyZT8NCj4gDQoNCk5vdCBzdXJlIGFib3V0IHRoaXMgcG9pbnQuIEkg
cHJlZmVyIGxlYXZpbmcgdGhlIGV4YWN0IGtub3dsZWRnZSBvZiB0aGUgZGV2aWNlIHR5cGUsIGJl
aW5nIEFDIFBvd2VyZWQgb3Igbm90IChhbmQgd2hpY2ggdHlwZSBvZiBBQyBwb3dlcikgZXRjLiBv
dXQgc2lkZSBvZiB0aGUga2VybmVsLiBUaGUgYXBwcm9hY2ggSSBjaG9zZSB3aXRoIHRoaXMgcGF0
Y2ggd2FzIHRvIG9ubHkgYWxsb3cgdG8gc3RhcnQgYSBHTyBvbiBzdWNoIGEgY2hhbm5lbCwgbWFr
aW5nIHRoZSBiYXNpYyB2ZXJpZmljYXRpb24gZG9uZSBhYm92ZSwgYXNzdW1pbmcgdGhhdCB0aGUg
dXNlciBzcGFjZSBjb21wb25lbnQgZ3VhcmFudGVlcyB0aGF0IGFsbCB0aGUgZnVsbCByZXN0cmlj
dGlvbnMgYXJlIHNhdGlzZmllZC4NCg0KPiA+ICsgKi8NCj4gPiArc3RhdGljIGJvb2wgY2ZnODAy
MTFfY2FuX2dvX3VzZV9jaGFuKHN0cnVjdCBjZmc4MDIxMV9yZWdpc3RlcmVkX2RldmljZQ0KPiAq
cmRldiwNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGll
ZWU4MDIxMV9jaGFubmVsICpjaGFuKSB7DQo+ID4gKyNpZmRlZiBDUFRDRkdfQ0ZHODAyMTFfUkVH
X1NPRlRfQ09ORklHVVJBVElPTlMNCj4gPiArICAgICAgIHN0cnVjdCB3aXJlbGVzc19kZXYgKndk
ZXZfaXRlcjsNCj4gPiArDQo+ID4gKyAgICAgICBBU1NFUlRfUlROTCgpOw0KPiA+ICsNCj4gPiAr
ICAgICAgIGlmICghKGNoYW4tPmZsYWdzICYgKElFRUU4MDIxMV9DSEFOX0lORE9PUl9PTkxZIHwN
Cj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgIElFRUU4MDIxMV9DSEFOX0dPX0NPTkNV
UlJFTlQpKSkNCj4gPiArICAgICAgICAgICAgICAgcmV0dXJuIGZhbHNlOw0KPiA+ICsNCj4gPiAr
ICAgICAgIGlmIChjaGFuLT5iYW5kID09IElFRUU4MDIxMV9CQU5EXzYwR0haKQ0KPiA+ICsgICAg
ICAgICAgICAgICByZXR1cm4gZmFsc2U7DQo+ID4gKw0KPiA+ICsgICAgICAgbGlzdF9mb3JfZWFj
aF9lbnRyeSh3ZGV2X2l0ZXIsICZyZGV2LT53ZGV2X2xpc3QsIGxpc3QpIHsNCj4gPiArICAgICAg
ICAgICAgICAgc3RydWN0IGllZWU4MDIxMV9jaGFubmVsICpvdGhlcl9jaGFuID0gTlVMTDsNCj4g
PiArDQo+ID4gKyAgICAgICAgICAgICAgIGlmICh3ZGV2X2l0ZXItPmlmdHlwZSAhPSBOTDgwMjEx
X0lGVFlQRV9TVEFUSU9OIHx8DQo+ID4gKyAgICAgICAgICAgICAgICAgICAoIW5ldGlmX3J1bm5p
bmcod2Rldl9pdGVyLT5uZXRkZXYpKSkNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGNvbnRpbnVlOw0KPiA+ICsNCj4gPiArDQo+ID4gKyAgICAgICAgICAgICAgIHdkZXZfbG9j
ayh3ZGV2X2l0ZXIpOw0KPiA+ICsgICAgICAgICAgICAgICBpZiAod2Rldl9pdGVyLT5jdXJyZW50
X2JzcykNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICBvdGhlcl9jaGFuID0gd2Rldl9pdGVy
LT5jdXJyZW50X2Jzcy0+cHViLmNoYW5uZWw7DQo+ID4gKyAgICAgICAgICAgICAgIHdkZXZfdW5s
b2NrKHdkZXZfaXRlcik7DQo+ID4gKw0KPiA+ICsgICAgICAgICAgICAgICBpZiAoIW90aGVyX2No
YW4pDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgY29udGludWU7DQo+ID4gKw0KPiA+ICsg
ICAgICAgICAgICAgICBpZiAoY2hhbiA9PSBvdGhlcl9jaGFuKQ0KPiA+ICsgICAgICAgICAgICAg
ICAgICAgICAgIHJldHVybiB0cnVlOw0KPiA+ICsgICAgICAgICAgICAgICBlbHNlIGlmICgoY2hh
bi0+YmFuZCA9PSBJRUVFODAyMTFfQkFORF81R0haKSAmJg0KPiA+ICsgICAgICAgICAgICAgICAg
ICAgICAgICAoY2ZnODAyMTFfZ2V0X3VuaWlfYmFuZChjaGFuLT5jZW50ZXJfZnJlcSkgPT0NCj4g
PiArICAgICAgICAgICAgICAgICAgICAgICAgIGNmZzgwMjExX2dldF91bmlpX2JhbmQob3RoZXJf
Y2hhbi0+Y2VudGVyX2ZyZXEpKSkNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4g
dHJ1ZTsNCj4gPiArICAgICAgIH0NCj4gPiArI2VuZGlmDQo+ID4gKyAgICAgICByZXR1cm4gZmFs
c2U7DQo+ID4gK30NCj4gDQo+IFBsZWFzZSB3cmFwIGNvZGUgYXMgZm9sbG93czoNCj4gDQo+ICNp
ZmRlZiBGT08NCj4gc3RhdGljIGludCBmb28odm9pZCkNCj4gew0KPiAgIHJldHVybiB0cnVlOw0K
PiB9DQo+ICNlbHNlDQo+IHN0YXRpYyBpbnQgZm9vKHZvaWQpDQo+ICAgcmV0dXJuIGZhbHNlOw0K
PiB9DQo+ICNlbmRpZg0KDQpPay4gSSBjYW4gZG8gdGhhdC4NCg0KPiBJbiB0aGUgbWVhbnRpbWUs
IHdoaWxlIHlvdSBnZXQgYWxsIHlvdXIgcGF0Y2ggc2V0cyBwcm9wZXJseSBkZXZlbG9wZWQgSSdk
DQo+IHJlY29tbWVuZCB0byBkZWZpbmUgdGhlIGNvZGUgcmV0dXJuaW5nIGZhbHNlIHRoZXJlIHN0
cmljdGx5IG9yIHBlcmhhcHMgZm9yIGFueQ0KPiBmbGFnIG9uIHRoZSBjaGFubmVsIHJlcXVpcmlu
ZyBERlMgLyBuby1pYnNzLCBvciBwYXNzaXZlIHNjYW4uIFRoZSBzdHJpY3RlciBjYXNlLA0KPiBk
ZWZpbmluZyBmYWxzZSBhbHdheXMsIHNlZW1zIHRvIGJlIHdoYXQgeW91IGFyZSBzdWdnZXN0aW5n
IGhlcmUuDQoNCkkgZG8gbm90IHRoaW5rIHRoYXQgdGhpcyBpcyBuZWVkZWQgaGVyZS4gUmV0dXJu
aW5nIGZhbHNlLCBtZWFucyB0aGF0IHRoZSBjb2RlIHNob3VsZCB0ZXN0IGlmIHRoZSBQQVNTSVZF
X1NDQU4gYW5kIE5PX0lCU1MgYXJlIG5vdCBzZXQgb24gdGhlIGNoYW5uZWwgd2Ugd2FudCB0byBz
dGFydCBiZWFjb25pbmcgb24uDQoNCj4gRG8geW91IGhhdmUgYSB3aGl0ZSBsaXN0IHRoYXQgY2Fu
IGV4Y2x1ZGUgc29tZSBjaGFubmVscyBmb3Igbm93IGdsb2JhbGx5IG9yDQo+IHNvbWVob3cgYXMg
YWxsIHRoaXMgbGluZXMgdXA/DQo+IA0KDQpOb3RlIHN1cmUgSSB1bmRlcnN0b29kIHdoYXQgeW91
IGFyZSBsb29raW5nIGZvci4gQ2FuIHlvdSBwbGVhc2UgY2xhcmlmeSB0aGlzIHBvaW50Pw0K

Re: [PATCH 1/3] [RFC] cfg80211: Add indoor only and GO concurrent channel attributes

[Luis R. Rodriguez]

On Wed, Jul 10, 2013 at 3:43 AM, Peer, Ilan <ilan.peer@intel.com> wrote:
>> On Tue, Jul 2, 2013 at 5:28 AM, Ilan Peer <ilan.peer@intel.com> wrote:
>> > From: David Spinadel <david.spinadel@intel.com>
>> >
>> > The FCC are clarifying some soft configuration requirements, which
>> > among other includes the following:
>> >
>> > 1. Concurrent GO operation, where devices may support WFD in
>> >    bands where an authorized master (for example with DFS and
>> >    DFS and radar detection capability in the UNII band) is operating.
>>
>> Is WFD WiFi Display? Is there any strict relationship here to WFD and GO and
>> regulatory or is WFD just a use case example? Are you indicating that the FCC
>> is making special rules for cases in specific bands where GO *can* co-exist with
>> other GO devices ?
>
> WFD is WiFi direct in this context. I do not think that the FCC are making special rules only for GO specific scenarios but a more general approach where "compliance may be achieved under the guidance of an authorized master". The WFD/P2P GO case is only an example.

OK then I think cullular base station regulatory hints might be
another example. In fact I believe I am looking at the information you
might be using as reference. I am looking at public draft edit for FCC
KDB 594280:

https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn=528122

The original KDB:

http://transition.fcc.gov/oet/ea/presentations/files/apr11/3b.SoftwareConfigurationControl-RDJS.pdf

Specifically in the above document, the draft edit, I am looking at
page 12. That actually references WiFi Direct precisely and considers
the case that a GO may need to move out of its channel if its master
device its using to configure itself also switches channels. Given
that cellular base station hints could also technically be used this
also would need to be considered for cellular base stations. But also
note on page 14 it states clearly:

"Mobile Country Codes (MCC) or Mobile Network Codes
(MNC) are not acceptable for programming host
compliance"

So it seems cellular base station hints are simply not allowed by the
FCC (unless specific approval is requested / revised). Even if the FCC
allowed for it I believe an API would need to be provided should
cellular base stations have a case where they may stop operating as
well similar to DFS.

BTW in future iterations of patches I'd appreciate if you can include
the above references to documentation given that we've pulled them up
now.

>> You annotate that this is somehow related to DFS, are the GO concurrent rules
>> that the FCC is defining only applicable to DFS frequency ranges? If so would it
>> suffice to only use DFS flag ? Or are there other special cases beyond DFS
>> frequency ranges that the FCC is creating special handling?
>>
>
> DFS was given here as an example. Generally, I think that the changes that the FCC are making are targeting various scenarios and various RF devices (for example those defined in part 15 of CFR title 47).

OK thanks. Things are clear now that I see the document that you might
be referring to.

>> Apart from the FCC are you aware of special cases handling for other
>> regulatory bodies at this point?
>
> Not that I'm aware of. Adding some more people that might know more.

Hey folks, anyone? :)

>> Note that we have already these on regdb.h from CRDA:
>>
>>
>> /*
>>  * The Linux map defined in <linux/uapi/nl80211.h> enum
>> nl80211_reg_rule_flags  */ enum reg_rule_flags {
>>         RRF_NO_OFDM             = 1<<0, /* OFDM modulation not allowed */
>>         RRF_NO_CCK              = 1<<1, /* CCK modulation not allowed */
>>         RRF_NO_INDOOR           = 1<<2, /* indoor operation not allowed */
>>         RRF_NO_OUTDOOR          = 1<<3, /* outdoor operation not allowed */
>>         RRF_DFS                 = 1<<4, /* DFS support is required to be
>>                                          * used */
>>         RRF_PTP_ONLY            = 1<<5, /* this is only for Point To Point
>>                                          * links */
>>         RRF_PTMP_ONLY           = 1<<6, /* this is only for Point To Multi
>>                                          * Point links */
>>         RRF_PASSIVE_SCAN        = 1<<7, /* passive scan is required */
>>         RRF_NO_IBSS             = 1<<8, /* IBSS is not allowed */
>> };
>>
>> Historically we don't distinguish then a type of 802.11 device that initiates
>> radiation except for the NO_IBSS rule, but that rule can be treated more as
>> legacy given that the intent and motivation behind that was that some ODMs
>> simply preferred an interpretation of regulatory rules and we *currently* don't
>> use that in much places other than custom regulatory domains defined in the
>> kernel. The PTP_ONLY and PTMP_ONLY are example other rules that could
>> potentially have been used but to this day we haven't found a use case for it
>> given that typical 802.11 devices are PTMP.
>>
>> I mention the NO_IBSS case as I'd like to try to avoid adding GO specific flag if
>> we can figure out a way to make this more generic. At this point for example I
>> think a more appropriate flag is in place:
>>
>
> Actually, this should be a GO only flag, meaning that such relaxation should not be valid for soft AP, IBSS or mesh. The intention here is limit the extend of the cell, and prevent daisy chain scenarios (assume that you allow a soft AP on such a channel and that a client associated to it, and then that device can also start a soft AP on the channel ....). Anyway, I'll need to have another look at this (might be permissible for IBSS ...)

Based on the documentation I reviewed and your proposal it'd seem to
me that we can distinguish GO on the upper layers and determine if a
channel is DFS or not by just the DFS flag. The next hint you'd need
is if the GO got regulatory information from a master somehow, no?
That is I am not seeing a need for a new flag at this point in
wireless-regdb, given also I mentioned another type of case for
regulatory hints technically possible (cellular base station hints but
it seems only allowed with exceptional review by the FCC).

I take it what you want to enable here is GO operation on DFS channels
and use country IEs to determine if you can use GO, but if you do have
GO enabled then you'd want hooks to not daisy chain, ack?

>> > 2. Indoor operation, where in bands requiring indoor operation, the
>> >    device must be programmed to detect indoor operation, or
>> >    - Device must be connected to AC Power
>>
>> Does anyone  know if the FCC considers "indoor" if we power a device through
>> the car on AC power through a converter ? Are we willing to ignore that corner
>> case?
>
> No. AC power means "mains" and not through portable DC converters (see slide 12 in https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn= 528122). It would be up to the user space to identify the device type etc. and identify if this a truly AC powered AP.

OK thanks for the clarification. I wonder if we can distinguish
between the two in userspace today. I'm happy to start pegging
frequency ranges as indoor-only on wireless-regdb even if we don't
have the userspace APIs to annotate when a device is indoor or not
yet. Patches welcomed then.

>> >    - Device must be under the control of a local master that is acting
>>
>> Interesting, so some APIs would be defined, I take it on hostapd to do the
>> proper callbacks to 'slave' type of devices that depend on the local master(s). I
>> could envision this being implemented on hostapd by expanding the AP
>> interface type and associating 'slave' devices and callbacks for updates on AP
>> device updates (channel changes, and so on). Is this work being planned?
>
> Yes. We have plans to incorporate more logic to hostap (currently into wpa_supplicant for P2P use cases).

Sweet.

  Luis

Re: [wireless-regdb] [PATCH 1/3] [RFC] cfg80211: Add indoor only and GO concurrent channel attributes

[Luis R. Rodriguez]

On Wed, Jul 10, 2013 at 3:43 AM, Peer, Ilan <ilan.peer@intel.com> wrote:
>> On Tue, Jul 2, 2013 at 5:28 AM, Ilan Peer <ilan.peer@intel.com> wrote:
>> > From: David Spinadel <david.spinadel@intel.com>
>> >
>> > The FCC are clarifying some soft configuration requirements, which
>> > among other includes the following:
>> >
>> > 1. Concurrent GO operation, where devices may support WFD in
>> >    bands where an authorized master (for example with DFS and
>> >    DFS and radar detection capability in the UNII band) is operating.
>>
>> Is WFD WiFi Display? Is there any strict relationship here to WFD and GO and
>> regulatory or is WFD just a use case example? Are you indicating that the FCC
>> is making special rules for cases in specific bands where GO *can* co-exist with
>> other GO devices ?
>
> WFD is WiFi direct in this context. I do not think that the FCC are making special rules only for GO specific scenarios but a more general approach where "compliance may be achieved under the guidance of an authorized master". The WFD/P2P GO case is only an example.

OK then I think cullular base station regulatory hints might be
another example. In fact I believe I am looking at the information you
might be using as reference. I am looking at public draft edit for FCC
KDB 594280:

https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn=528122

The original KDB:

http://transition.fcc.gov/oet/ea/presentations/files/apr11/3b.SoftwareConfigurationControl-RDJS.pdf

Specifically in the above document, the draft edit, I am looking at
page 12. That actually references WiFi Direct precisely and considers
the case that a GO may need to move out of its channel if its master
device its using to configure itself also switches channels. Given
that cellular base station hints could also technically be used this
also would need to be considered for cellular base stations. But also
note on page 14 it states clearly:

"Mobile Country Codes (MCC) or Mobile Network Codes
(MNC) are not acceptable for programming host
compliance"

So it seems cellular base station hints are simply not allowed by the
FCC (unless specific approval is requested / revised). Even if the FCC
allowed for it I believe an API would need to be provided should
cellular base stations have a case where they may stop operating as
well similar to DFS.

BTW in future iterations of patches I'd appreciate if you can include
the above references to documentation given that we've pulled them up
now.

>> You annotate that this is somehow related to DFS, are the GO concurrent rules
>> that the FCC is defining only applicable to DFS frequency ranges? If so would it
>> suffice to only use DFS flag ? Or are there other special cases beyond DFS
>> frequency ranges that the FCC is creating special handling?
>>
>
> DFS was given here as an example. Generally, I think that the changes that the FCC are making are targeting various scenarios and various RF devices (for example those defined in part 15 of CFR title 47).

OK thanks. Things are clear now that I see the document that you might
be referring to.

>> Apart from the FCC are you aware of special cases handling for other
>> regulatory bodies at this point?
>
> Not that I'm aware of. Adding some more people that might know more.

Hey folks, anyone? :)

>> Note that we have already these on regdb.h from CRDA:
>>
>>
>> /*
>>  * The Linux map defined in <linux/uapi/nl80211.h> enum
>> nl80211_reg_rule_flags  */ enum reg_rule_flags {
>>         RRF_NO_OFDM             = 1<<0, /* OFDM modulation not allowed */
>>         RRF_NO_CCK              = 1<<1, /* CCK modulation not allowed */
>>         RRF_NO_INDOOR           = 1<<2, /* indoor operation not allowed */
>>         RRF_NO_OUTDOOR          = 1<<3, /* outdoor operation not allowed */
>>         RRF_DFS                 = 1<<4, /* DFS support is required to be
>>                                          * used */
>>         RRF_PTP_ONLY            = 1<<5, /* this is only for Point To Point
>>                                          * links */
>>         RRF_PTMP_ONLY           = 1<<6, /* this is only for Point To Multi
>>                                          * Point links */
>>         RRF_PASSIVE_SCAN        = 1<<7, /* passive scan is required */
>>         RRF_NO_IBSS             = 1<<8, /* IBSS is not allowed */
>> };
>>
>> Historically we don't distinguish then a type of 802.11 device that initiates
>> radiation except for the NO_IBSS rule, but that rule can be treated more as
>> legacy given that the intent and motivation behind that was that some ODMs
>> simply preferred an interpretation of regulatory rules and we *currently* don't
>> use that in much places other than custom regulatory domains defined in the
>> kernel. The PTP_ONLY and PTMP_ONLY are example other rules that could
>> potentially have been used but to this day we haven't found a use case for it
>> given that typical 802.11 devices are PTMP.
>>
>> I mention the NO_IBSS case as I'd like to try to avoid adding GO specific flag if
>> we can figure out a way to make this more generic. At this point for example I
>> think a more appropriate flag is in place:
>>
>
> Actually, this should be a GO only flag, meaning that such relaxation should not be valid for soft AP, IBSS or mesh. The intention here is limit the extend of the cell, and prevent daisy chain scenarios (assume that you allow a soft AP on such a channel and that a client associated to it, and then that device can also start a soft AP on the channel ....). Anyway, I'll need to have another look at this (might be permissible for IBSS ...)

Based on the documentation I reviewed and your proposal it'd seem to
me that we can distinguish GO on the upper layers and determine if a
channel is DFS or not by just the DFS flag. The next hint you'd need
is if the GO got regulatory information from a master somehow, no?
That is I am not seeing a need for a new flag at this point in
wireless-regdb, given also I mentioned another type of case for
regulatory hints technically possible (cellular base station hints but
it seems only allowed with exceptional review by the FCC).

I take it what you want to enable here is GO operation on DFS channels
and use country IEs to determine if you can use GO, but if you do have
GO enabled then you'd want hooks to not daisy chain, ack?

>> > 2. Indoor operation, where in bands requiring indoor operation, the
>> >    device must be programmed to detect indoor operation, or
>> >    - Device must be connected to AC Power
>>
>> Does anyone  know if the FCC considers "indoor" if we power a device through
>> the car on AC power through a converter ? Are we willing to ignore that corner
>> case?
>
> No. AC power means "mains" and not through portable DC converters (see slide 12 in https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn= 528122). It would be up to the user space to identify the device type etc. and identify if this a truly AC powered AP.

OK thanks for the clarification. I wonder if we can distinguish
between the two in userspace today. I'm happy to start pegging
frequency ranges as indoor-only on wireless-regdb even if we don't
have the userspace APIs to annotate when a device is indoor or not
yet. Patches welcomed then.

>> >    - Device must be under the control of a local master that is acting
>>
>> Interesting, so some APIs would be defined, I take it on hostapd to do the
>> proper callbacks to 'slave' type of devices that depend on the local master(s). I
>> could envision this being implemented on hostapd by expanding the AP
>> interface type and associating 'slave' devices and callbacks for updates on AP
>> device updates (channel changes, and so on). Is this work being planned?
>
> Yes. We have plans to incorporate more logic to hostap (currently into wpa_supplicant for P2P use cases).

Sweet.

  Luis

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional channels

[Luis R. Rodriguez]

On Wed, Jul 10, 2013 at 3:47 AM, Peer, Ilan <ilan.peer@intel.com> wrote:
>> Are you aware of UNII-1, UNII-2, UNII-2E, UNII-3 are specific world regulatory
>> language bands? When I last tried to look for a clear definition I could not find
>> a clear definition of them and its why on the ath module on for QCA modules I
>> state "we call these" in reference to the UNII nomenclature. If we can get a
>> clear resource for its definition that would help here.
>>
>
> Maybe these link will help.
> http://www.gpo.gov/fdsys/pkg/CFR-2010-title47-vol1/xml/CFR-2010-title47-vol1-part15.xml#seqnum15.403
> http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-13-22A1.pdf
>
> Anyway, I will use your ''we call these" notation as well :)

No no, this is good, its just United States / FCC biased and I hadn't
seen the documentation you provided before. This confirms these are
official terms but still just US / FCC biased. My point was that we
should be careful to not make global statements on regulatory code
about things that are not global. If we know only the FCC calls this
UNII well lets document that and provide the reference you supplied. I
anticipated having to deal with special case regulatory code outside
of of what CRDA / wireless-regdb provides -- given that CRDA /
wireless-regdb were meant to be more RF agnostic anyway.

Given that other vendors may also want to get the UNII band can you
stuff instead cfg80211_get_unii_band() into reg.c and do the #ifdef
properly with the Kconfig, and export it as well, as well as document
it properly providing the reference you mentioned.

>> > + * 1. Indoor only: a GO can be operational on such a channel, iff there is
>> > + *    clear assessment that the platform device is indoor.
>> > + * 2. Concurrent GO: a GO can be operational on such a channel, iff there is
>> an
>> > + *    additional station interface connected to an AP on this channel.
>> > + *
>> > + * TODO: The function is too permissive, as it does not verify the
>> > + platform
>> > + * device type is indeed indoor, or that the AP is indoor/AC powered.
>>
>> So to do this properly we need an eventual userspace API to throw to
>> kernelspace if we are AC powered? We'll need this to enhance this routine
>> here?
>>
>
> Not sure about this point. I prefer leaving the exact knowledge of the device type, being AC Powered or not (and which type of AC power) etc. out side of the kernel. The approach I chose with this patch was to only allow to start a GO on such a channel, making the basic verification done above, assuming that the user space component guarantees that all the full restrictions are satisfied.

Fair enough. Seems we just need to zero in now on the requirement or
not on the extra flag you suggested.

>> In the meantime, while you get all your patch sets properly developed I'd
>> recommend to define the code returning false there strictly or perhaps for any
>> flag on the channel requiring DFS / no-ibss, or passive scan. The stricter case,
>> defining false always, seems to be what you are suggesting here.
>
> I do not think that this is needed here. Returning false, means that the code should test if the PASSIVE_SCAN and NO_IBSS are not set on the channel we want to start beaconing on.
>
>> Do you have a white list that can exclude some channels for now globally or
>> somehow as all this lines up?
>>
>
> Note sure I understood what you are looking for. Can you please clarify this point?

It was unclear for what exact channels you needed to deal with here.
Given review so far wouldn't it just be DFS flagged channels on some
UNII bands ? Then again if the indoor flag needs to be pegged to to a
specific UNII band and we can do that on wireless-regdb do we even
need the UNII band check routine helper?

  Luis

Re: [wireless-regdb] [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional channels

[Luis R. Rodriguez]

On Wed, Jul 10, 2013 at 3:47 AM, Peer, Ilan <ilan.peer@intel.com> wrote:
>> Are you aware of UNII-1, UNII-2, UNII-2E, UNII-3 are specific world regulatory
>> language bands? When I last tried to look for a clear definition I could not find
>> a clear definition of them and its why on the ath module on for QCA modules I
>> state "we call these" in reference to the UNII nomenclature. If we can get a
>> clear resource for its definition that would help here.
>>
>
> Maybe these link will help.
> http://www.gpo.gov/fdsys/pkg/CFR-2010-title47-vol1/xml/CFR-2010-title47-vol1-part15.xml#seqnum15.403
> http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-13-22A1.pdf
>
> Anyway, I will use your ''we call these" notation as well :)

No no, this is good, its just United States / FCC biased and I hadn't
seen the documentation you provided before. This confirms these are
official terms but still just US / FCC biased. My point was that we
should be careful to not make global statements on regulatory code
about things that are not global. If we know only the FCC calls this
UNII well lets document that and provide the reference you supplied. I
anticipated having to deal with special case regulatory code outside
of of what CRDA / wireless-regdb provides -- given that CRDA /
wireless-regdb were meant to be more RF agnostic anyway.

Given that other vendors may also want to get the UNII band can you
stuff instead cfg80211_get_unii_band() into reg.c and do the #ifdef
properly with the Kconfig, and export it as well, as well as document
it properly providing the reference you mentioned.

>> > + * 1. Indoor only: a GO can be operational on such a channel, iff there is
>> > + *    clear assessment that the platform device is indoor.
>> > + * 2. Concurrent GO: a GO can be operational on such a channel, iff there is
>> an
>> > + *    additional station interface connected to an AP on this channel.
>> > + *
>> > + * TODO: The function is too permissive, as it does not verify the
>> > + platform
>> > + * device type is indeed indoor, or that the AP is indoor/AC powered.
>>
>> So to do this properly we need an eventual userspace API to throw to
>> kernelspace if we are AC powered? We'll need this to enhance this routine
>> here?
>>
>
> Not sure about this point. I prefer leaving the exact knowledge of the device type, being AC Powered or not (and which type of AC power) etc. out side of the kernel. The approach I chose with this patch was to only allow to start a GO on such a channel, making the basic verification done above, assuming that the user space component guarantees that all the full restrictions are satisfied.

Fair enough. Seems we just need to zero in now on the requirement or
not on the extra flag you suggested.

>> In the meantime, while you get all your patch sets properly developed I'd
>> recommend to define the code returning false there strictly or perhaps for any
>> flag on the channel requiring DFS / no-ibss, or passive scan. The stricter case,
>> defining false always, seems to be what you are suggesting here.
>
> I do not think that this is needed here. Returning false, means that the code should test if the PASSIVE_SCAN and NO_IBSS are not set on the channel we want to start beaconing on.
>
>> Do you have a white list that can exclude some channels for now globally or
>> somehow as all this lines up?
>>
>
> Note sure I understood what you are looking for. Can you please clarify this point?

It was unclear for what exact channels you needed to deal with here.
Given review so far wouldn't it just be DFS flagged channels on some
UNII bands ? Then again if the indoor flag needs to be pegged to to a
specific UNII band and we can do that on wireless-regdb do we even
need the UNII band check routine helper?

  Luis

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

RE: [PATCH 1/3] [RFC] cfg80211: Add indoor only and GO concurrent channel attributes

[Peer, Ilan]

SGkgTHVpcywNCg0KT25jZSBhZ2FpbiwgdGhhbmtzIGZvciB0aGUgY29tbWVudHMgOikNCg0KUmVn
YXJkcywNCg0KSWxhbi4NCg0KPiA+PiBJcyBXRkQgV2lGaSBEaXNwbGF5PyBJcyB0aGVyZSBhbnkg
c3RyaWN0IHJlbGF0aW9uc2hpcCBoZXJlIHRvIFdGRCBhbmQNCj4gPj4gR08gYW5kIHJlZ3VsYXRv
cnkgb3IgaXMgV0ZEIGp1c3QgYSB1c2UgY2FzZSBleGFtcGxlPyBBcmUgeW91DQo+ID4+IGluZGlj
YXRpbmcgdGhhdCB0aGUgRkNDIGlzIG1ha2luZyBzcGVjaWFsIHJ1bGVzIGZvciBjYXNlcyBpbiBz
cGVjaWZpYw0KPiA+PiBiYW5kcyB3aGVyZSBHTyAqY2FuKiBjby1leGlzdCB3aXRoIG90aGVyIEdP
IGRldmljZXMgPw0KPiA+DQo+ID4gV0ZEIGlzIFdpRmkgZGlyZWN0IGluIHRoaXMgY29udGV4dC4g
SSBkbyBub3QgdGhpbmsgdGhhdCB0aGUgRkNDIGFyZSBtYWtpbmcNCj4gc3BlY2lhbCBydWxlcyBv
bmx5IGZvciBHTyBzcGVjaWZpYyBzY2VuYXJpb3MgYnV0IGEgbW9yZSBnZW5lcmFsIGFwcHJvYWNo
IHdoZXJlDQo+ICJjb21wbGlhbmNlIG1heSBiZSBhY2hpZXZlZCB1bmRlciB0aGUgZ3VpZGFuY2Ug
b2YgYW4gYXV0aG9yaXplZCBtYXN0ZXIiLg0KPiBUaGUgV0ZEL1AyUCBHTyBjYXNlIGlzIG9ubHkg
YW4gZXhhbXBsZS4NCj4gDQo+IE9LIHRoZW4gSSB0aGluayBjdWxsdWxhciBiYXNlIHN0YXRpb24g
cmVndWxhdG9yeSBoaW50cyBtaWdodCBiZSBhbm90aGVyIGV4YW1wbGUuDQo+IEluIGZhY3QgSSBi
ZWxpZXZlIEkgYW0gbG9va2luZyBhdCB0aGUgaW5mb3JtYXRpb24geW91IG1pZ2h0IGJlIHVzaW5n
IGFzDQo+IHJlZmVyZW5jZS4gSSBhbSBsb29raW5nIGF0IHB1YmxpYyBkcmFmdCBlZGl0IGZvciBG
Q0MgS0RCIDU5NDI4MDoNCj4gDQo+IGh0dHBzOi8vYXBwcy5mY2MuZ292L2Vhcy9jb21tZW50cy9H
ZXRQdWJsaXNoZWREb2N1bWVudC5odG1sP2lkPTMyNyZ0bj01DQo+IDI4MTIyDQoNClRoaXMgaXMg
aW5kZWVkIHRoZSByZWxldmFudCBkb2N1bWVudC4NCg0KPiANCj4gVGhlIG9yaWdpbmFsIEtEQjoN
Cj4gDQo+IGh0dHA6Ly90cmFuc2l0aW9uLmZjYy5nb3Yvb2V0L2VhL3ByZXNlbnRhdGlvbnMvZmls
ZXMvYXByMTEvM2IuU29mdHdhcmVDb25maWd1cg0KPiBhdGlvbkNvbnRyb2wtUkRKUy5wZGYNCj4g
DQo+IFNwZWNpZmljYWxseSBpbiB0aGUgYWJvdmUgZG9jdW1lbnQsIHRoZSBkcmFmdCBlZGl0LCBJ
IGFtIGxvb2tpbmcgYXQgcGFnZSAxMi4gVGhhdA0KPiBhY3R1YWxseSByZWZlcmVuY2VzIFdpRmkg
RGlyZWN0IHByZWNpc2VseSBhbmQgY29uc2lkZXJzIHRoZSBjYXNlIHRoYXQgYSBHTyBtYXkNCj4g
bmVlZCB0byBtb3ZlIG91dCBvZiBpdHMgY2hhbm5lbCBpZiBpdHMgbWFzdGVyIGRldmljZSBpdHMg
dXNpbmcgdG8gY29uZmlndXJlIGl0c2VsZg0KPiBhbHNvIHN3aXRjaGVzIGNoYW5uZWxzLiBHaXZl
biB0aGF0IGNlbGx1bGFyIGJhc2Ugc3RhdGlvbiBoaW50cyBjb3VsZCBhbHNvDQo+IHRlY2huaWNh
bGx5IGJlIHVzZWQgdGhpcyBhbHNvIHdvdWxkIG5lZWQgdG8gYmUgY29uc2lkZXJlZCBmb3IgY2Vs
bHVsYXIgYmFzZQ0KPiBzdGF0aW9ucy4gQnV0IGFsc28gbm90ZSBvbiBwYWdlIDE0IGl0IHN0YXRl
cyBjbGVhcmx5Og0KPiANCj4gIk1vYmlsZSBDb3VudHJ5IENvZGVzIChNQ0MpIG9yIE1vYmlsZSBO
ZXR3b3JrIENvZGVzDQo+IChNTkMpIGFyZSBub3QgYWNjZXB0YWJsZSBmb3IgcHJvZ3JhbW1pbmcg
aG9zdCBjb21wbGlhbmNlIg0KPiANCj4gU28gaXQgc2VlbXMgY2VsbHVsYXIgYmFzZSBzdGF0aW9u
IGhpbnRzIGFyZSBzaW1wbHkgbm90IGFsbG93ZWQgYnkgdGhlIEZDQyAodW5sZXNzDQo+IHNwZWNp
ZmljIGFwcHJvdmFsIGlzIHJlcXVlc3RlZCAvIHJldmlzZWQpLiBFdmVuIGlmIHRoZSBGQ0MgYWxs
b3dlZCBmb3IgaXQgSSBiZWxpZXZlDQo+IGFuIEFQSSB3b3VsZCBuZWVkIHRvIGJlIHByb3ZpZGVk
IHNob3VsZCBjZWxsdWxhciBiYXNlIHN0YXRpb25zIGhhdmUgYSBjYXNlDQo+IHdoZXJlIHRoZXkg
bWF5IHN0b3Agb3BlcmF0aW5nIGFzIHdlbGwgc2ltaWxhciB0byBERlMuDQo+IA0KPiBCVFcgaW4g
ZnV0dXJlIGl0ZXJhdGlvbnMgb2YgcGF0Y2hlcyBJJ2QgYXBwcmVjaWF0ZSBpZiB5b3UgY2FuIGlu
Y2x1ZGUgdGhlIGFib3ZlDQo+IHJlZmVyZW5jZXMgdG8gZG9jdW1lbnRhdGlvbiBnaXZlbiB0aGF0
IHdlJ3ZlIHB1bGxlZCB0aGVtIHVwIG5vdy4NCj4gDQoNClN1cmUuDQoNCj4gPj4gWW91IGFubm90
YXRlIHRoYXQgdGhpcyBpcyBzb21laG93IHJlbGF0ZWQgdG8gREZTLCBhcmUgdGhlIEdPDQo+ID4+
IGNvbmN1cnJlbnQgcnVsZXMgdGhhdCB0aGUgRkNDIGlzIGRlZmluaW5nIG9ubHkgYXBwbGljYWJs
ZSB0byBERlMNCj4gPj4gZnJlcXVlbmN5IHJhbmdlcz8gSWYgc28gd291bGQgaXQgc3VmZmljZSB0
byBvbmx5IHVzZSBERlMgZmxhZyA/IE9yDQo+ID4+IGFyZSB0aGVyZSBvdGhlciBzcGVjaWFsIGNh
c2VzIGJleW9uZCBERlMgZnJlcXVlbmN5IHJhbmdlcyB0aGF0IHRoZSBGQ0MgaXMNCj4gY3JlYXRp
bmcgc3BlY2lhbCBoYW5kbGluZz8NCj4gPj4NCj4gPg0KPiA+IERGUyB3YXMgZ2l2ZW4gaGVyZSBh
cyBhbiBleGFtcGxlLiBHZW5lcmFsbHksIEkgdGhpbmsgdGhhdCB0aGUgY2hhbmdlcyB0aGF0DQo+
IHRoZSBGQ0MgYXJlIG1ha2luZyBhcmUgdGFyZ2V0aW5nIHZhcmlvdXMgc2NlbmFyaW9zIGFuZCB2
YXJpb3VzIFJGIGRldmljZXMgKGZvcg0KPiBleGFtcGxlIHRob3NlIGRlZmluZWQgaW4gcGFydCAx
NSBvZiBDRlIgdGl0bGUgNDcpLg0KPiANCj4gT0sgdGhhbmtzLiBUaGluZ3MgYXJlIGNsZWFyIG5v
dyB0aGF0IEkgc2VlIHRoZSBkb2N1bWVudCB0aGF0IHlvdSBtaWdodCBiZQ0KPiByZWZlcnJpbmcg
dG8uDQo+IA0KPiA+PiBBcGFydCBmcm9tIHRoZSBGQ0MgYXJlIHlvdSBhd2FyZSBvZiBzcGVjaWFs
IGNhc2VzIGhhbmRsaW5nIGZvciBvdGhlcg0KPiA+PiByZWd1bGF0b3J5IGJvZGllcyBhdCB0aGlz
IHBvaW50Pw0KPiA+DQo+ID4gTm90IHRoYXQgSSdtIGF3YXJlIG9mLiBBZGRpbmcgc29tZSBtb3Jl
IHBlb3BsZSB0aGF0IG1pZ2h0IGtub3cgbW9yZS4NCj4gDQo+IEhleSBmb2xrcywgYW55b25lPyA6
KQ0KPiANCg0KPiA+DQo+ID4gQWN0dWFsbHksIHRoaXMgc2hvdWxkIGJlIGEgR08gb25seSBmbGFn
LCBtZWFuaW5nIHRoYXQgc3VjaCByZWxheGF0aW9uDQo+ID4gc2hvdWxkIG5vdCBiZSB2YWxpZCBm
b3Igc29mdCBBUCwgSUJTUyBvciBtZXNoLiBUaGUgaW50ZW50aW9uIGhlcmUgaXMNCj4gPiBsaW1p
dCB0aGUgZXh0ZW5kIG9mIHRoZSBjZWxsLCBhbmQgcHJldmVudCBkYWlzeSBjaGFpbiBzY2VuYXJp
b3MNCj4gPiAoYXNzdW1lIHRoYXQgeW91IGFsbG93IGEgc29mdCBBUCBvbiBzdWNoIGEgY2hhbm5l
bCBhbmQgdGhhdCBhIGNsaWVudA0KPiA+IGFzc29jaWF0ZWQgdG8gaXQsIGFuZCB0aGVuIHRoYXQg
ZGV2aWNlIGNhbiBhbHNvIHN0YXJ0IGEgc29mdCBBUCBvbiB0aGUNCj4gPiBjaGFubmVsIC4uLi4p
LiBBbnl3YXksIEknbGwgbmVlZCB0byBoYXZlIGFub3RoZXIgbG9vayBhdCB0aGlzIChtaWdodA0K
PiA+IGJlIHBlcm1pc3NpYmxlIGZvciBJQlNTIC4uLikNCj4gDQo+IEJhc2VkIG9uIHRoZSBkb2N1
bWVudGF0aW9uIEkgcmV2aWV3ZWQgYW5kIHlvdXIgcHJvcG9zYWwgaXQnZCBzZWVtIHRvIG1lIHRo
YXQNCj4gd2UgY2FuIGRpc3Rpbmd1aXNoIEdPIG9uIHRoZSB1cHBlciBsYXllcnMgYW5kIGRldGVy
bWluZSBpZiBhIGNoYW5uZWwgaXMgREZTIG9yDQo+IG5vdCBieSBqdXN0IHRoZSBERlMgZmxhZy4g
VGhlIG5leHQgaGludCB5b3UnZCBuZWVkIGlzIGlmIHRoZSBHTyBnb3QgcmVndWxhdG9yeQ0KPiBp
bmZvcm1hdGlvbiBmcm9tIGEgbWFzdGVyIHNvbWVob3csIG5vPw0KDQpUaGlzIHNob3VsZCBhbHNv
IGJlIGhhbmRsZWQgYnkgdXNlciBzcGFjZSwgYmFzZWQgb24gdGhlIGRldmljZSB0eXBlL3N1YiB0
eXBlIG9mIHRoZSBsb2NhbCBkZXZpY2UgZGlyZWN0bHksIG9yIGluZGlyZWN0bHkgdGhyb3VnaCBv
dGhlciBtZWFucyBzdWNoIGEgbWFuYWdlZCBpbnRlcmZhY2UgYXNzb2NpYXRpbmcgd2l0aCBhbiBB
UCB0aGF0IGl0J3MgZGV2aWNlIHR5cGUgdmFsdWUgaXMgNiBldGMuDQoNCj4gVGhhdCBpcyBJIGFt
IG5vdCBzZWVpbmcgYSBuZWVkIGZvciBhIG5ldyBmbGFnIGF0IHRoaXMgcG9pbnQgaW4gd2lyZWxl
c3MtcmVnZGIsDQo+IGdpdmVuIGFsc28gSSBtZW50aW9uZWQgYW5vdGhlciB0eXBlIG9mIGNhc2Ug
Zm9yIHJlZ3VsYXRvcnkgaGludHMgdGVjaG5pY2FsbHkNCj4gcG9zc2libGUgKGNlbGx1bGFyIGJh
c2Ugc3RhdGlvbiBoaW50cyBidXQgaXQgc2VlbXMgb25seSBhbGxvd2VkIHdpdGggZXhjZXB0aW9u
YWwNCj4gcmV2aWV3IGJ5IHRoZSBGQ0MpLg0KPiANCj4gSSB0YWtlIGl0IHdoYXQgeW91IHdhbnQg
dG8gZW5hYmxlIGhlcmUgaXMgR08gb3BlcmF0aW9uIG9uIERGUyBjaGFubmVscyBhbmQgdXNlDQo+
IGNvdW50cnkgSUVzIHRvIGRldGVybWluZSBpZiB5b3UgY2FuIHVzZSBHTywgYnV0IGlmIHlvdSBk
byBoYXZlIEdPIGVuYWJsZWQgdGhlbg0KPiB5b3UnZCB3YW50IGhvb2tzIHRvIG5vdCBkYWlzeSBj
aGFpbiwgYWNrPw0KDQpDdXJyZW50bHksIHdlIGRvIG5vdCBpbnRlbmQgdG8gYmFzZSB0aGUgcmVs
YXhhdGlvbiBvbiB0aGUgY291bnRyeSBJRSBkaXJlY3RseSwgYnV0IGJhc2UgaXQgb24gdGhlIGZh
Y3QgdGhhdCBpZiB0aGVyZSBpcyBhIG1hbmFnZWQgY29ubmVjdGlvbiB0byBhbiBBUCB3aG8ncyBu
b3QgYSBtb2JpbGUgZGV2aWNlIChhc3N1bWluZyB0aGF0IGl0IGlzIGFuIGF1dGhvcml6ZWQgbWFz
dGVyKSwgdGhhbiB0aGUgY2hhbm5lbCB1c2VkIGJ5IHRoZSBtYW5hZ2VkIGNvbm5lY3Rpb24gaXMg
dmFsaWQgZm9yIHVzZSAoYXMgbG9uZyBhcyB0aGUgbWFuYWdlZCBpbnRlcmZhY2UgaXMgY29ubmVj
dGVkIHRvIHRoZSBBUCBvbiB0aGUgY2hhbm5lbCkuIA0KDQo+DQo+ID4+ID4gMi4gSW5kb29yIG9w
ZXJhdGlvbiwgd2hlcmUgaW4gYmFuZHMgcmVxdWlyaW5nIGluZG9vciBvcGVyYXRpb24sIHRoZQ0K
PiA+PiA+ICAgIGRldmljZSBtdXN0IGJlIHByb2dyYW1tZWQgdG8gZGV0ZWN0IGluZG9vciBvcGVy
YXRpb24sIG9yDQo+ID4+ID4gICAgLSBEZXZpY2UgbXVzdCBiZSBjb25uZWN0ZWQgdG8gQUMgUG93
ZXINCj4gPj4NCj4gPj4gRG9lcyBhbnlvbmUgIGtub3cgaWYgdGhlIEZDQyBjb25zaWRlcnMgImlu
ZG9vciIgaWYgd2UgcG93ZXIgYSBkZXZpY2UNCj4gPj4gdGhyb3VnaCB0aGUgY2FyIG9uIEFDIHBv
d2VyIHRocm91Z2ggYSBjb252ZXJ0ZXIgPyBBcmUgd2Ugd2lsbGluZyB0bw0KPiA+PiBpZ25vcmUg
dGhhdCBjb3JuZXIgY2FzZT8NCj4gPg0KPiA+IE5vLiBBQyBwb3dlciBtZWFucyAibWFpbnMiIGFu
ZCBub3QgdGhyb3VnaCBwb3J0YWJsZSBEQyBjb252ZXJ0ZXJzIChzZWUNCj4gc2xpZGUgMTIgaW4N
Cj4gaHR0cHM6Ly9hcHBzLmZjYy5nb3YvZWFzL2NvbW1lbnRzL0dldFB1Ymxpc2hlZERvY3VtZW50
Lmh0bWw/aWQ9MzI3JnRuPQ0KPiA1MjgxMjIpLiBJdCB3b3VsZCBiZSB1cCB0byB0aGUgdXNlciBz
cGFjZSB0byBpZGVudGlmeSB0aGUgZGV2aWNlIHR5cGUgZXRjLiBhbmQNCj4gaWRlbnRpZnkgaWYg
dGhpcyBhIHRydWx5IEFDIHBvd2VyZWQgQVAuDQo+IA0KPiBPSyB0aGFua3MgZm9yIHRoZSBjbGFy
aWZpY2F0aW9uLiBJIHdvbmRlciBpZiB3ZSBjYW4gZGlzdGluZ3Vpc2ggYmV0d2VlbiB0aGUgdHdv
DQo+IGluIHVzZXJzcGFjZSB0b2RheS4gSSdtIGhhcHB5IHRvIHN0YXJ0IHBlZ2dpbmcgZnJlcXVl
bmN5IHJhbmdlcyBhcyBpbmRvb3Itb25seQ0KPiBvbiB3aXJlbGVzcy1yZWdkYiBldmVuIGlmIHdl
IGRvbid0IGhhdmUgdGhlIHVzZXJzcGFjZSBBUElzIHRvIGFubm90YXRlIHdoZW4gYQ0KPiBkZXZp
Y2UgaXMgaW5kb29yIG9yIG5vdCB5ZXQuIFBhdGNoZXMgd2VsY29tZWQgdGhlbi4NCj4gDQoNCkFn
YWluLCB3ZSBhcmUgZ29pbmcgdG8gdXNlIHRoZSBkZXZpY2UgdHlwZS9zdWIgdHlwZSBhcyBhbiBp
bmRpY2F0aW9uIHRvIGFuIEFQIGJlaW5nIEFDIHBvd2VyZWQuDQoNCj4gPj4gPiAgICAtIERldmlj
ZSBtdXN0IGJlIHVuZGVyIHRoZSBjb250cm9sIG9mIGEgbG9jYWwgbWFzdGVyIHRoYXQgaXMNCj4g
Pj4gPiBhY3RpbmcNCj4gPj4NCj4gPj4gSW50ZXJlc3RpbmcsIHNvIHNvbWUgQVBJcyB3b3VsZCBi
ZSBkZWZpbmVkLCBJIHRha2UgaXQgb24gaG9zdGFwZCB0bw0KPiA+PiBkbyB0aGUgcHJvcGVyIGNh
bGxiYWNrcyB0byAnc2xhdmUnIHR5cGUgb2YgZGV2aWNlcyB0aGF0IGRlcGVuZCBvbiB0aGUNCj4g
Pj4gbG9jYWwgbWFzdGVyKHMpLiBJIGNvdWxkIGVudmlzaW9uIHRoaXMgYmVpbmcgaW1wbGVtZW50
ZWQgb24gaG9zdGFwZA0KPiA+PiBieSBleHBhbmRpbmcgdGhlIEFQIGludGVyZmFjZSB0eXBlIGFu
ZCBhc3NvY2lhdGluZyAnc2xhdmUnIGRldmljZXMNCj4gPj4gYW5kIGNhbGxiYWNrcyBmb3IgdXBk
YXRlcyBvbiBBUCBkZXZpY2UgdXBkYXRlcyAoY2hhbm5lbCBjaGFuZ2VzLCBhbmQgc28NCj4gb24p
LiBJcyB0aGlzIHdvcmsgYmVpbmcgcGxhbm5lZD8NCj4gPg0KDQpOb3RlIHN1cmUgdGhhdCBJIGZv
bGxvdyAuLi4gSG93ZXZlciwgd2UgZG8gaW50ZW5kIHRvIGFkZCB0aGlzIHR5cGUgb2Ygc3VwcG9y
dCB0byBob3N0YXAuDQoNCj4gPiBZZXMuIFdlIGhhdmUgcGxhbnMgdG8gaW5jb3Jwb3JhdGUgbW9y
ZSBsb2dpYyB0byBob3N0YXAgKGN1cnJlbnRseSBpbnRvDQo+IHdwYV9zdXBwbGljYW50IGZvciBQ
MlAgdXNlIGNhc2VzKS4NCj4gDQo+IFN3ZWV0Lg0KPiANCj4gICBMdWlzDQoNCg0KDQo=

RE: [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional channels

[Peer, Ilan]

PiBPbiBXZWQsIEp1bCAxMCwgMjAxMyBhdCAzOjQ3IEFNLCBQZWVyLCBJbGFuIDxpbGFuLnBlZXJA
aW50ZWwuY29tPiB3cm90ZToNCj4gPj4gQXJlIHlvdSBhd2FyZSBvZiBVTklJLTEsIFVOSUktMiwg
VU5JSS0yRSwgVU5JSS0zIGFyZSBzcGVjaWZpYyB3b3JsZA0KPiA+PiByZWd1bGF0b3J5IGxhbmd1
YWdlIGJhbmRzPyBXaGVuIEkgbGFzdCB0cmllZCB0byBsb29rIGZvciBhIGNsZWFyDQo+ID4+IGRl
ZmluaXRpb24gSSBjb3VsZCBub3QgZmluZCBhIGNsZWFyIGRlZmluaXRpb24gb2YgdGhlbSBhbmQg
aXRzIHdoeSBvbg0KPiA+PiB0aGUgYXRoIG1vZHVsZSBvbiBmb3IgUUNBIG1vZHVsZXMgSSBzdGF0
ZSAid2UgY2FsbCB0aGVzZSIgaW4NCj4gPj4gcmVmZXJlbmNlIHRvIHRoZSBVTklJIG5vbWVuY2xh
dHVyZS4gSWYgd2UgY2FuIGdldCBhIGNsZWFyIHJlc291cmNlIGZvciBpdHMNCj4gZGVmaW5pdGlv
biB0aGF0IHdvdWxkIGhlbHAgaGVyZS4NCj4gPj4NCj4gPg0KPiA+IE1heWJlIHRoZXNlIGxpbmsg
d2lsbCBoZWxwLg0KPiA+IGh0dHA6Ly93d3cuZ3BvLmdvdi9mZHN5cy9wa2cvQ0ZSLTIwMTAtdGl0
bGU0Ny12b2wxL3htbC9DRlItMjAxMC10aXRsZTQNCj4gPiA3LXZvbDEtcGFydDE1LnhtbCNzZXFu
dW0xNS40MDMNCj4gPiBodHRwOi8vaHJhdW5mb3NzLmZjYy5nb3YvZWRvY3NfcHVibGljL2F0dGFj
aG1hdGNoL0ZDQy0xMy0yMkExLnBkZg0KPiA+DQo+ID4gQW55d2F5LCBJIHdpbGwgdXNlIHlvdXIg
Jyd3ZSBjYWxsIHRoZXNlIiBub3RhdGlvbiBhcyB3ZWxsIDopDQo+IA0KPiBObyBubywgdGhpcyBp
cyBnb29kLCBpdHMganVzdCBVbml0ZWQgU3RhdGVzIC8gRkNDIGJpYXNlZCBhbmQgSSBoYWRuJ3Qg
c2VlbiB0aGUNCj4gZG9jdW1lbnRhdGlvbiB5b3UgcHJvdmlkZWQgYmVmb3JlLiBUaGlzIGNvbmZp
cm1zIHRoZXNlIGFyZSBvZmZpY2lhbCB0ZXJtcyBidXQNCj4gc3RpbGwganVzdCBVUyAvIEZDQyBi
aWFzZWQuIE15IHBvaW50IHdhcyB0aGF0IHdlIHNob3VsZCBiZSBjYXJlZnVsIHRvIG5vdCBtYWtl
DQo+IGdsb2JhbCBzdGF0ZW1lbnRzIG9uIHJlZ3VsYXRvcnkgY29kZSBhYm91dCB0aGluZ3MgdGhh
dCBhcmUgbm90IGdsb2JhbC4gSWYgd2UNCj4ga25vdyBvbmx5IHRoZSBGQ0MgY2FsbHMgdGhpcyBV
TklJIHdlbGwgbGV0cyBkb2N1bWVudCB0aGF0IGFuZCBwcm92aWRlIHRoZQ0KPiByZWZlcmVuY2Ug
eW91IHN1cHBsaWVkLiBJIGFudGljaXBhdGVkIGhhdmluZyB0byBkZWFsIHdpdGggc3BlY2lhbCBj
YXNlDQo+IHJlZ3VsYXRvcnkgY29kZSBvdXRzaWRlIG9mIG9mIHdoYXQgQ1JEQSAvIHdpcmVsZXNz
LXJlZ2RiIHByb3ZpZGVzIC0tIGdpdmVuIHRoYXQNCj4gQ1JEQSAvIHdpcmVsZXNzLXJlZ2RiIHdl
cmUgbWVhbnQgdG8gYmUgbW9yZSBSRiBhZ25vc3RpYyBhbnl3YXkuDQo+IA0KPiBHaXZlbiB0aGF0
IG90aGVyIHZlbmRvcnMgbWF5IGFsc28gd2FudCB0byBnZXQgdGhlIFVOSUkgYmFuZCBjYW4geW91
IHN0dWZmDQo+IGluc3RlYWQgY2ZnODAyMTFfZ2V0X3VuaWlfYmFuZCgpIGludG8gcmVnLmMgYW5k
IGRvIHRoZSAjaWZkZWYgcHJvcGVybHkgd2l0aCB0aGUNCj4gS2NvbmZpZywgYW5kIGV4cG9ydCBp
dCBhcyB3ZWxsLCBhcyB3ZWxsIGFzIGRvY3VtZW50IGl0IHByb3Blcmx5IHByb3ZpZGluZyB0aGUN
Cj4gcmVmZXJlbmNlIHlvdSBtZW50aW9uZWQuDQoNClN1cmUuDQoNCj4gDQo+ID4+ID4gKyAqIDEu
IEluZG9vciBvbmx5OiBhIEdPIGNhbiBiZSBvcGVyYXRpb25hbCBvbiBzdWNoIGEgY2hhbm5lbCwg
aWZmIHRoZXJlIGlzDQo+ID4+ID4gKyAqICAgIGNsZWFyIGFzc2Vzc21lbnQgdGhhdCB0aGUgcGxh
dGZvcm0gZGV2aWNlIGlzIGluZG9vci4NCj4gPj4gPiArICogMi4gQ29uY3VycmVudCBHTzogYSBH
TyBjYW4gYmUgb3BlcmF0aW9uYWwgb24gc3VjaCBhIGNoYW5uZWwsDQo+ID4+ID4gKyBpZmYgdGhl
cmUgaXMNCj4gPj4gYW4NCj4gPj4gPiArICogICAgYWRkaXRpb25hbCBzdGF0aW9uIGludGVyZmFj
ZSBjb25uZWN0ZWQgdG8gYW4gQVAgb24gdGhpcyBjaGFubmVsLg0KPiA+PiA+ICsgKg0KPiA+PiA+
ICsgKiBUT0RPOiBUaGUgZnVuY3Rpb24gaXMgdG9vIHBlcm1pc3NpdmUsIGFzIGl0IGRvZXMgbm90
IHZlcmlmeSB0aGUNCj4gPj4gPiArIHBsYXRmb3JtDQo+ID4+ID4gKyAqIGRldmljZSB0eXBlIGlz
IGluZGVlZCBpbmRvb3IsIG9yIHRoYXQgdGhlIEFQIGlzIGluZG9vci9BQyBwb3dlcmVkLg0KPiA+
Pg0KPiA+PiBTbyB0byBkbyB0aGlzIHByb3Blcmx5IHdlIG5lZWQgYW4gZXZlbnR1YWwgdXNlcnNw
YWNlIEFQSSB0byB0aHJvdyB0bw0KPiA+PiBrZXJuZWxzcGFjZSBpZiB3ZSBhcmUgQUMgcG93ZXJl
ZD8gV2UnbGwgbmVlZCB0aGlzIHRvIGVuaGFuY2UgdGhpcw0KPiA+PiByb3V0aW5lIGhlcmU/DQo+
ID4+DQo+ID4NCj4gPiBOb3Qgc3VyZSBhYm91dCB0aGlzIHBvaW50LiBJIHByZWZlciBsZWF2aW5n
IHRoZSBleGFjdCBrbm93bGVkZ2Ugb2YgdGhlIGRldmljZQ0KPiB0eXBlLCBiZWluZyBBQyBQb3dl
cmVkIG9yIG5vdCAoYW5kIHdoaWNoIHR5cGUgb2YgQUMgcG93ZXIpIGV0Yy4gb3V0IHNpZGUgb2Yg
dGhlDQo+IGtlcm5lbC4gVGhlIGFwcHJvYWNoIEkgY2hvc2Ugd2l0aCB0aGlzIHBhdGNoIHdhcyB0
byBvbmx5IGFsbG93IHRvIHN0YXJ0IGEgR08gb24NCj4gc3VjaCBhIGNoYW5uZWwsIG1ha2luZyB0
aGUgYmFzaWMgdmVyaWZpY2F0aW9uIGRvbmUgYWJvdmUsIGFzc3VtaW5nIHRoYXQgdGhlDQo+IHVz
ZXIgc3BhY2UgY29tcG9uZW50IGd1YXJhbnRlZXMgdGhhdCBhbGwgdGhlIGZ1bGwgcmVzdHJpY3Rp
b25zIGFyZSBzYXRpc2ZpZWQuDQo+IA0KPiBGYWlyIGVub3VnaC4gU2VlbXMgd2UganVzdCBuZWVk
IHRvIHplcm8gaW4gbm93IG9uIHRoZSByZXF1aXJlbWVudCBvciBub3Qgb24NCj4gdGhlIGV4dHJh
IGZsYWcgeW91IHN1Z2dlc3RlZC4NCj4gDQo+ID4+IEluIHRoZSBtZWFudGltZSwgd2hpbGUgeW91
IGdldCBhbGwgeW91ciBwYXRjaCBzZXRzIHByb3Blcmx5IGRldmVsb3BlZA0KPiA+PiBJJ2QgcmVj
b21tZW5kIHRvIGRlZmluZSB0aGUgY29kZSByZXR1cm5pbmcgZmFsc2UgdGhlcmUgc3RyaWN0bHkg
b3INCj4gPj4gcGVyaGFwcyBmb3IgYW55IGZsYWcgb24gdGhlIGNoYW5uZWwgcmVxdWlyaW5nIERG
UyAvIG5vLWlic3MsIG9yDQo+ID4+IHBhc3NpdmUgc2Nhbi4gVGhlIHN0cmljdGVyIGNhc2UsIGRl
ZmluaW5nIGZhbHNlIGFsd2F5cywgc2VlbXMgdG8gYmUgd2hhdCB5b3UNCj4gYXJlIHN1Z2dlc3Rp
bmcgaGVyZS4NCj4gPg0KPiA+IEkgZG8gbm90IHRoaW5rIHRoYXQgdGhpcyBpcyBuZWVkZWQgaGVy
ZS4gUmV0dXJuaW5nIGZhbHNlLCBtZWFucyB0aGF0IHRoZSBjb2RlDQo+IHNob3VsZCB0ZXN0IGlm
IHRoZSBQQVNTSVZFX1NDQU4gYW5kIE5PX0lCU1MgYXJlIG5vdCBzZXQgb24gdGhlIGNoYW5uZWwg
d2UNCj4gd2FudCB0byBzdGFydCBiZWFjb25pbmcgb24uDQo+ID4NCj4gPj4gRG8geW91IGhhdmUg
YSB3aGl0ZSBsaXN0IHRoYXQgY2FuIGV4Y2x1ZGUgc29tZSBjaGFubmVscyBmb3Igbm93DQo+ID4+
IGdsb2JhbGx5IG9yIHNvbWVob3cgYXMgYWxsIHRoaXMgbGluZXMgdXA/DQo+ID4+DQo+ID4NCg0K
SSdsbCB0cnkgdG8gcHJvdmlkZSBzdWNoIGxpc3QgLi4uIA0KDQo+ID4gTm90ZSBzdXJlIEkgdW5k
ZXJzdG9vZCB3aGF0IHlvdSBhcmUgbG9va2luZyBmb3IuIENhbiB5b3UgcGxlYXNlIGNsYXJpZnkg
dGhpcw0KPiBwb2ludD8NCj4gDQo+IEl0IHdhcyB1bmNsZWFyIGZvciB3aGF0IGV4YWN0IGNoYW5u
ZWxzIHlvdSBuZWVkZWQgdG8gZGVhbCB3aXRoIGhlcmUuDQo+IEdpdmVuIHJldmlldyBzbyBmYXIg
d291bGRuJ3QgaXQganVzdCBiZSBERlMgZmxhZ2dlZCBjaGFubmVscyBvbiBzb21lIFVOSUkNCj4g
YmFuZHMgPyBUaGVuIGFnYWluIGlmIHRoZSBpbmRvb3IgZmxhZyBuZWVkcyB0byBiZSBwZWdnZWQg
dG8gdG8gYSBzcGVjaWZpYyBVTklJDQo+IGJhbmQgYW5kIHdlIGNhbiBkbyB0aGF0IG9uIHdpcmVs
ZXNzLXJlZ2RiIGRvIHdlIGV2ZW4gbmVlZCB0aGUgVU5JSSBiYW5kDQo+IGNoZWNrIHJvdXRpbmUg
aGVscGVyPw0KPiANCg0KR2VuZXJhbGx5IGl0IGlzIHBvc3NpYmxlIHRoYXQgdGhlIGluZG9vciBw
cm9wZXJ0eSBpcyBub3QgcGVnZ2VkIHRvIHRoZSAnb3RoZXJfY2hhbm5lbCcsIG9yIGl0IGlzIHBv
c3NpYmxlIHRoYXQgaXQgaXMgcGVnZ2VkIGJ1dCB0aGV5IGFyZSBub3QgaW4gdGhlIHNhbWUgVU5J
SSBiYW5kLCBzbyB0aGUgdmVyaWZpY2F0aW9uIGlzIHN0aWxsIG5lZWRlZC4gSSBndWVzcyB0aGF0
IG9uY2UgSSBnZXQgdGhlIGxpc3QgeW91IHJlcXVlc3RlZCB0aGluZ3Mgd2lsbCBiZSBjbGVhcmVy
IDopIA0KDQpSZWdhcmRzLA0KDQpJbGFuLg0KDQo=

Re: [PATCH 1/3] [RFC] cfg80211: Add indoor only and GO concurrent channel attributes

[Luis R. Rodriguez]

On Wed, Jul 17, 2013 at 11:47 AM, Peer, Ilan <ilan.peer@intel.com> wrote:
> On some day Luis wrote:
>
>> Based on the documentation I reviewed and your proposal it'd seem to me that
>> we can distinguish GO on the upper layers and determine if a channel is DFS or
>> not by just the DFS flag. The next hint you'd need is if the GO got regulatory
>> information from a master somehow, no?
>
> This should also be handled by user space, based on the device type/sub type of the local device directly, or
> indirectly through other means such a managed interface associating with an AP that it's device type
> value is 6 etc.

This seems reasonable but we need to also consider state machine
changes possible on the channel the GO is on as well and there are
different reasons for the channel to change:

  * beacon hint - nl80211_send_beacon_hint_event()
  * regulatory change - nl80211_send_reg_change_event()

The beacon hint multicast group message sends the channel prior to the
beacon hint and after. The regulatory change event currently isn't as
atomic and only provides the the fact that regulatory domain state
machine has incurred a change. In this case it may make sense to send
all wiphy information and have hostapd verify if a change has occurred
on the channel.

>> That is I am not seeing a need for a new flag at this point in wireless-regdb,
>> given also I mentioned another type of case for regulatory hints technically
>> possible (cellular base station hints but it seems only allowed with exceptional
>> review by the FCC).
>>
>> I take it what you want to enable here is GO operation on DFS channels and use
>> country IEs to determine if you can use GO, but if you do have GO enabled then
>> you'd want hooks to not daisy chain, ack?
>
> Currently, we do not intend to base the relaxation on the country IE directly,

Its still a possibility so it should be handled and we should consider
it on core regulatory. One possible solution might be to not enable GO
unless the the NL80211_ATTR_REG_INITIATOR was something appropriate
for the wiphy.

> but base it on the fact that if
> there is a managed connection to an AP who's not a mobile device (assuming that it is an authorized master),

How do you intend on verifying a device that has associated to an AP,
that that AP is not a mobile device, ie that it fits this "authorized
master" category ?

> than the channel used by the managed connection is valid for use (as long as the managed interface
> is connected to the AP on the channel).

Makes sense.

  Luis

Re: [wireless-regdb] [PATCH 1/3] [RFC] cfg80211: Add indoor only and GO concurrent channel attributes

[Luis R. Rodriguez]

On Wed, Jul 17, 2013 at 11:47 AM, Peer, Ilan <ilan.peer@intel.com> wrote:
> On some day Luis wrote:
>
>> Based on the documentation I reviewed and your proposal it'd seem to me that
>> we can distinguish GO on the upper layers and determine if a channel is DFS or
>> not by just the DFS flag. The next hint you'd need is if the GO got regulatory
>> information from a master somehow, no?
>
> This should also be handled by user space, based on the device type/sub type of the local device directly, or
> indirectly through other means such a managed interface associating with an AP that it's device type
> value is 6 etc.

This seems reasonable but we need to also consider state machine
changes possible on the channel the GO is on as well and there are
different reasons for the channel to change:

  * beacon hint - nl80211_send_beacon_hint_event()
  * regulatory change - nl80211_send_reg_change_event()

The beacon hint multicast group message sends the channel prior to the
beacon hint and after. The regulatory change event currently isn't as
atomic and only provides the the fact that regulatory domain state
machine has incurred a change. In this case it may make sense to send
all wiphy information and have hostapd verify if a change has occurred
on the channel.

>> That is I am not seeing a need for a new flag at this point in wireless-regdb,
>> given also I mentioned another type of case for regulatory hints technically
>> possible (cellular base station hints but it seems only allowed with exceptional
>> review by the FCC).
>>
>> I take it what you want to enable here is GO operation on DFS channels and use
>> country IEs to determine if you can use GO, but if you do have GO enabled then
>> you'd want hooks to not daisy chain, ack?
>
> Currently, we do not intend to base the relaxation on the country IE directly,

Its still a possibility so it should be handled and we should consider
it on core regulatory. One possible solution might be to not enable GO
unless the the NL80211_ATTR_REG_INITIATOR was something appropriate
for the wiphy.

> but base it on the fact that if
> there is a managed connection to an AP who's not a mobile device (assuming that it is an authorized master),

How do you intend on verifying a device that has associated to an AP,
that that AP is not a mobile device, ie that it fits this "authorized
master" category ?

> than the channel used by the managed connection is valid for use (as long as the managed interface
> is connected to the AP on the channel).

Makes sense.

  Luis

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional channels

[Luis R. Rodriguez]

On Wed, Jul 17, 2013 at 12:15 PM, Peer, Ilan <ilan.peer@intel.com> wrote:
>> It was unclear for what exact channels you needed to deal with here.
>> Given review so far wouldn't it just be DFS flagged channels on some UNII
>> bands ? Then again if the indoor flag needs to be pegged to to a specific UNII
>> band and we can do that on wireless-regdb do we even need the UNII band
>> check routine helper?
>>
>
> Generally it is possible that the indoor property is not pegged to the 'other_channel', or it is possible that it is pegged but they are not in the same UNII band, so the verification is still needed. I guess that once I get the list you requested things will be clearer :)

OK so there are exceptions to the indoor flag affecting GO under these
rules or not. Looking forward to the respin.

  Luis

Re: [wireless-regdb] [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional channels

[Luis R. Rodriguez]

On Wed, Jul 17, 2013 at 12:15 PM, Peer, Ilan <ilan.peer@intel.com> wrote:
>> It was unclear for what exact channels you needed to deal with here.
>> Given review so far wouldn't it just be DFS flagged channels on some UNII
>> bands ? Then again if the indoor flag needs to be pegged to to a specific UNII
>> band and we can do that on wireless-regdb do we even need the UNII band
>> check routine helper?
>>
>
> Generally it is possible that the indoor property is not pegged to the 'other_channel', or it is possible that it is pegged but they are not in the same UNII band, so the verification is still needed. I guess that once I get the list you requested things will be clearer :)

OK so there are exceptions to the indoor flag affecting GO under these
rules or not. Looking forward to the respin.

  Luis

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional channels

[Luis R. Rodriguez]

On Thu, Jul 18, 2013 at 4:34 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> On Wed, Jul 17, 2013 at 12:15 PM, Peer, Ilan <ilan.peer@intel.com> wrote:
>>> It was unclear for what exact channels you needed to deal with here.
>>> Given review so far wouldn't it just be DFS flagged channels on some UNII
>>> bands ? Then again if the indoor flag needs to be pegged to to a specific UNII
>>> band and we can do that on wireless-regdb do we even need the UNII band
>>> check routine helper?
>>>
>>
>> Generally it is possible that the indoor property is not pegged to the 'other_channel', or it is possible that it is pegged but they are not in the same UNII band, so the verification is still needed. I guess that once I get the list you requested things will be clearer :)
>
> OK so there are exceptions to the indoor flag affecting GO under these
> rules or not. Looking forward to the respin.

Anxiously looking forward to the respin :D

  Luis

Re: [wireless-regdb] [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional channels

[Luis R. Rodriguez]

On Thu, Jul 18, 2013 at 4:34 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> On Wed, Jul 17, 2013 at 12:15 PM, Peer, Ilan <ilan.peer@intel.com> wrote:
>>> It was unclear for what exact channels you needed to deal with here.
>>> Given review so far wouldn't it just be DFS flagged channels on some UNII
>>> bands ? Then again if the indoor flag needs to be pegged to to a specific UNII
>>> band and we can do that on wireless-regdb do we even need the UNII band
>>> check routine helper?
>>>
>>
>> Generally it is possible that the indoor property is not pegged to the 'other_channel', or it is possible that it is pegged but they are not in the same UNII band, so the verification is still needed. I guess that once I get the list you requested things will be clearer :)
>
> OK so there are exceptions to the indoor flag affecting GO under these
> rules or not. Looking forward to the respin.

Anxiously looking forward to the respin :D

  Luis

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

RE: [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional channels

[Peer, Ilan]

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtY2dyb2ZAZ21haWwuY29tIFtt
YWlsdG86bWNncm9mQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIEx1aXMgUi4NCj4gUm9kcmlndWV6
DQo+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAwNCwgMjAxMyAyMDozOA0KPiBUbzogUGVlciwgSWxh
bjsgSmVmZiBKb2huc29uDQo+IENjOiBTcGluYWRlbCwgRGF2aWQ7IGxpbnV4LXdpcmVsZXNzOyB3
aXJlbGVzcy1yZWdkYkBsaXN0cy5pbmZyYWRlYWQub3JnOyBKb3VuaQ0KPiBNYWxpbmVuOyBHaW5z
YnVyZywgTm9hbTsgUGVyZWxtb290ZXIsIExpcmF6OyBTaGFsZXYsIE96OyBNaWNoYWVsIEdyZWVu
DQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMy8zXSBbUkZDXSBjZmc4MDIxMTogRW5hYmxlIEdPIG9w
ZXJhdGlvbiBvbiBhZGRpdGlvbmFsDQo+IGNoYW5uZWxzDQo+IA0KPiBPbiBUaHUsIEp1bCAxOCwg
MjAxMyBhdCA0OjM0IFBNLCBMdWlzIFIuIFJvZHJpZ3VleiA8bWNncm9mQGRvLW5vdC0NCj4gcGFu
aWMuY29tPiB3cm90ZToNCj4gPiBPbiBXZWQsIEp1bCAxNywgMjAxMyBhdCAxMjoxNSBQTSwgUGVl
ciwgSWxhbiA8aWxhbi5wZWVyQGludGVsLmNvbT4gd3JvdGU6DQo+ID4+PiBJdCB3YXMgdW5jbGVh
ciBmb3Igd2hhdCBleGFjdCBjaGFubmVscyB5b3UgbmVlZGVkIHRvIGRlYWwgd2l0aCBoZXJlLg0K
PiA+Pj4gR2l2ZW4gcmV2aWV3IHNvIGZhciB3b3VsZG4ndCBpdCBqdXN0IGJlIERGUyBmbGFnZ2Vk
IGNoYW5uZWxzIG9uIHNvbWUNCj4gPj4+IFVOSUkgYmFuZHMgPyBUaGVuIGFnYWluIGlmIHRoZSBp
bmRvb3IgZmxhZyBuZWVkcyB0byBiZSBwZWdnZWQgdG8gdG8NCj4gPj4+IGEgc3BlY2lmaWMgVU5J
SSBiYW5kIGFuZCB3ZSBjYW4gZG8gdGhhdCBvbiB3aXJlbGVzcy1yZWdkYiBkbyB3ZSBldmVuDQo+
ID4+PiBuZWVkIHRoZSBVTklJIGJhbmQgY2hlY2sgcm91dGluZSBoZWxwZXI/DQo+ID4+Pg0KPiA+
Pg0KPiA+PiBHZW5lcmFsbHkgaXQgaXMgcG9zc2libGUgdGhhdCB0aGUgaW5kb29yIHByb3BlcnR5
IGlzIG5vdCBwZWdnZWQgdG8NCj4gPj4gdGhlICdvdGhlcl9jaGFubmVsJywgb3IgaXQgaXMgcG9z
c2libGUgdGhhdCBpdCBpcyBwZWdnZWQgYnV0IHRoZXkgYXJlDQo+ID4+IG5vdCBpbiB0aGUgc2Ft
ZSBVTklJIGJhbmQsIHNvIHRoZSB2ZXJpZmljYXRpb24gaXMgc3RpbGwgbmVlZGVkLiBJDQo+ID4+
IGd1ZXNzIHRoYXQgb25jZSBJIGdldCB0aGUgbGlzdCB5b3UgcmVxdWVzdGVkIHRoaW5ncyB3aWxs
IGJlIGNsZWFyZXINCj4gPj4gOikNCj4gPg0KPiA+IE9LIHNvIHRoZXJlIGFyZSBleGNlcHRpb25z
IHRvIHRoZSBpbmRvb3IgZmxhZyBhZmZlY3RpbmcgR08gdW5kZXIgdGhlc2UNCj4gPiBydWxlcyBv
ciBub3QuIExvb2tpbmcgZm9yd2FyZCB0byB0aGUgcmVzcGluLg0KPiANCj4gQW54aW91c2x5IGxv
b2tpbmcgZm9yd2FyZCB0byB0aGUgcmVzcGluIDpEDQo+IA0KDQpNZSB0b28gOykgLi4uIHVuZm9y
dHVuYXRlbHkgSSBkaWQgbm90IGdldCBhIGNoYW5jZSB0byB3b3JrIG9uIHRoaXMgaW4gdGhlIGxh
c3QgY291cGxlIG9mIG1vbnRocy4gSG9wZSBJJ2xsIGdldCB0byBpdCB0aGlzIHdlZWsgb3IgdGhl
IG5leHQuIFNvcnJ5IGZvciBub3QgdXBkYXRpbmcgZWFybGllciAuLi4NCg0KUmVnYXJkcywNCg0K
SWxhbi4NCg0K