[wireless-regdb] [PATCH v3 1/6] cfg80211: Add indoor only and GO concurrent channel attributes

[Luis R. Rodriguez]

On Mon, Jan 27, 2014 at 12:21:53PM +0200, Ilan Peer wrote:
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index b1f84b0..dbc5490 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -109,6 +109,27 @@ 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.
> + *	A channel marked with IEEE80211_CHAN_INDOOR_ONLY can only be used when
> + *	there is a clear assessment that the device is operating in an indoor
> + *	surroundings, i.e., it is connected to AC power (and not through
> + *	portable DC inverters)

Curious, what are the plans to avoid the situation of portable DC
inverters from being used in this case ? Stating that is in
the documentation alludes that this is possible in userspace.

Is it?

> or is under the control of a master that is
> + *	acting as an AP and is connected to AC power.
> + * @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.

What do you mean "on 5.2" ? Maybe just "the 5 GHz band" would be better
if this is not UNII specific. If the rule applies to a UNII band then
mentioning the band name nomenclature would make it clearer, ie, UNII-1,
or UNII-2. If this flag could later be used by other 5 GHz UNII bands then
making it in the documentation UNII band agnostic and just using 5 GHz
would suffice, while your handler in code adjusts as regulations change.

> + *	Instantiating a GO on a channel marked with IEEE80211_CHAN_GO_CONCURRENT
> + *	can be done when there is a clear assessment that the device is
> + *	operating under the guidance of an authorized master, i.e., setting up a
> + *	GO while the device is also connected to an AP with DFS and radar
> + *	detection on the UNII band (however, this example does not imply that
> + *	all channels marked with IEEE80211_CHAN_RADAR must also be marked with
> + *	IEEE80211_CHAN_GO_CONCURRENT and vise versa).

Your mentioning of DFS here makes things a bit confusing. We should be
distinguishing between the case of a device beign associated to on a BSS
where the AP is on a DFS channel, and the case where the AP is not on
a DFS channel. Are you saying that if IEEE80211_CHAN_GO_CONCURRENT is
enabled on a channel that also has IEEE80211_CHAN_RADAR that the device
can start GO on the same channel if it *doesn't support DFS itself* if
its associated to a real AP, which presumably supports DFS? If so
consider then a third GO which would associate to the secondary GO,
we now have a link of 3 devices and an inherent delay can be created
letting a master device do things. How do we avoid latency issues
in communication in this type of setup?

If IEEE80211_CHAN_GO_CONCURRENT is meant only for channels that do not
have IEEE80211_CHAN_RADAR that makes it simpler but I think you were
trying to clarify that daisy chaning trust on the root AP is valid.

Please clarify both use cases on the documentation.

> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
> index 91054fd..06440ac 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -2304,6 +2304,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.

Same UNII band clarification applies here.

  Luis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/wireless-regdb/attachments/20140218/ae676cdf/attachment.sig>