[RFC 0/9] nl/cfg/mac80211: add DFS master ability

[RFC 0/9] nl/cfg/mac80211: add DFS master ability

[Victor Goldenshtein]

This patch set (with hostap patch series) adds support for DFS (Dynamic Frequency Selection) according 802.11h.


Main idea
===================

DFS master algorithm is implemented in the hostapd, while nl/cfg/mac80211 will pipe relevant commands/events to the driver/hostapd.

Based on the assumption that the device/driver supports radar interference detection i.e., it is capable to generate radar_detected event by using different pattern detection techniques:


1. Pattern detection in the HW: the device generates 'radar_detected' event.
2. Pattern detection in the driver: the driver receives radar pulses from the device and generates 'radar detected' event.


Main DFS procedures
===================

1. Hostapd gets driver's dfs capabilities.

2. If 80211h is enabled in the hostapd.conf and the driver supports one of the above radar detection techniques, hostapd may use DFS channels.

3. Hostapd selects an operational channel (default from hostapd.conf), if selected channel is a DFS channel, hostapd sends start_radar_detection command to the device/driver which starts monitoring for radar interference while hostapd sets a timer for a CAC (Channel Availability Check) time, which is 60 seconds.

4. As CAC timer expires and no radar has been detected, hostapd may continue with the init flow, otherwise if interference is detected hostapd selects another channel (random selection) and repeats the CAC on the new channel (in case the new channel is also a DFS channel), while the original channel is added to a "black list" for a period of ''No-Occupancy'' time (time that the channel can't be used/selected).

5. While using the channel the device/driver continuously monitors for potential radar interference. If interference is detected hostapd notified with 'radar detected' event, which selects a new channel and triggers a channel switch procedure, if the new channel is also a DFS channel, hostapd performs the CAC test, once it's successfully passed hostapd instructs the driver to initiate the transmission on the channel.



Victor Goldenshtein (9):
  nl80211/cfg80211: add radar detection command/event
  mac80211: add radar detection command/event
  nl80211/cfg80211: add ability to enable TX on op-channel
  mac80211: add ability to enable TX on op-channel
  nl80211/cfg80211: add ap channel switch command/event
  mac80211: add ap channel switch command/event
  nl80211/cfg80211: add DFS feature flag
  mac80211: add DFS capabilities flag
  mac80211: add DFS support to monitor interface

 include/linux/nl80211.h     |   39 ++++++++++
 include/net/cfg80211.h      |   38 +++++++++
 include/net/mac80211.h      |   33 ++++++++
 net/mac80211/cfg.c          |   67 ++++++++++++++++
 net/mac80211/driver-ops.h   |   24 ++++++
 net/mac80211/driver-trace.h |   12 +++
 net/mac80211/main.c         |    3 +
 net/mac80211/mlme.c         |   18 +++++
 net/mac80211/tx.c           |   15 ++--
 net/wireless/mlme.c         |   21 +++++
 net/wireless/nl80211.c      |  178 ++++++++++++++++++++++++++++++++++++++++++-
 net/wireless/nl80211.h      |   10 +++
 12 files changed, 450 insertions(+), 8 deletions(-)

-- 
1.7.5.4

[RFC 1/9] nl80211/cfg80211: add radar detection command/event

[Victor Goldenshtein]

Add start radar detection command, which triggers radar
detection in the driver/FW, this command will also notify
usermode with 'radar detected' event.

Signed-off-by: Victor Goldenshtein <victorg@ti.com>
---
 include/linux/nl80211.h |    5 ++++
 include/net/cfg80211.h  |   16 ++++++++++++
 net/wireless/mlme.c     |   10 ++++++++
 net/wireless/nl80211.c  |   59 ++++++++++++++++++++++++++++++++++++++++++++++-
 net/wireless/nl80211.h  |    6 ++++
 5 files changed, 95 insertions(+), 1 deletions(-)

diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index 0f5ff37..5bffba0 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -541,6 +541,9 @@
  * @NL80211_CMD_SET_NOACK_MAP: sets a bitmap for the individual TIDs whether
  *      No Acknowledgement Policy should be applied.
  *
+ * @NL80211_CMD_DFS_RADAR_DETECTION: Start radar detection in the
+ *	driver/HW. Once radar detected usermode notified with this event.
+ *
  * @NL80211_CMD_MAX: highest used command number
  * @__NL80211_CMD_AFTER_LAST: internal use
  */
@@ -680,6 +683,8 @@ enum nl80211_commands {
 
 	NL80211_CMD_SET_NOACK_MAP,
 
+	NL80211_CMD_DFS_RADAR_DETECTION,
+
 	/* add new commands above here */
 
 	/* used to define NL80211_CMD_MAX below */
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 15f4be7..b47217b 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1482,6 +1482,8 @@ struct cfg80211_gtk_rekey_data {
  *	later passes to cfg80211_probe_status().
  *
  * @set_noack_map: Set the NoAck Map for the TIDs.
+ *
+ * @dfs_start_radar_detection: Start radar detection in the driver.
  */
 struct cfg80211_ops {
 	int	(*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
@@ -1680,6 +1682,9 @@ struct cfg80211_ops {
 				  u16 noack_map);
 
 	struct ieee80211_channel *(*get_channel)(struct wiphy *wiphy);
+
+	int    (*dfs_start_radar_detection)(struct wiphy *wiphy,
+					    struct net_device *dev);
 };
 
 /*
@@ -3216,6 +3221,17 @@ void cfg80211_cqm_rssi_notify(struct net_device *dev,
 			      gfp_t gfp);
 
 /**
+ * cfg80211_radar_detected_notify - radar detection event
+ * @dev: network device
+ * @freq: radar detected on this channel frequency
+ * @gfp: context flags
+ *
+ * This function is called when a radar is detected on the current channel.
+ */
+void cfg80211_radar_detected_notify(struct net_device *dev,
+				    u16 freq, gfp_t gfp);
+
+/**
  * cfg80211_cqm_pktloss_notify - notify userspace about packetloss to peer
  * @dev: network device
  * @peer: peer's MAC address
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index 438dfc1..6ef723d 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -1109,6 +1109,16 @@ void cfg80211_cqm_rssi_notify(struct net_device *dev,
 }
 EXPORT_SYMBOL(cfg80211_cqm_rssi_notify);
 
+void cfg80211_radar_detected_notify(struct net_device *dev, u16 freq, gfp_t gfp)
+{
+	struct wireless_dev *wdev = dev->ieee80211_ptr;
+	struct wiphy *wiphy = wdev->wiphy;
+	struct cfg80211_registered_device *rdev = wiphy_to_dev(wiphy);
+
+	nl80211_send_radar_detected_notify(rdev, freq, dev, gfp);
+}
+EXPORT_SYMBOL(cfg80211_radar_detected_notify);
+
 void cfg80211_cqm_pktloss_notify(struct net_device *dev,
 				 const u8 *peer, u32 num_packets, gfp_t gfp)
 {
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index b3d3cf8..e96bfc5 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -4044,6 +4044,20 @@ static int nl80211_stop_sched_scan(struct sk_buff *skb,
 	return err;
 }
 
+static int nl80211_dfs_start_radar_detection(struct sk_buff *skb,
+					     struct genl_info *info)
+{
+	struct cfg80211_registered_device *rdev = info->user_ptr[0];
+	struct net_device *dev = info->user_ptr[1];
+
+	ASSERT_RDEV_LOCK(rdev);
+
+	if (!rdev->ops->dfs_start_radar_detection)
+		return -EOPNOTSUPP;
+
+	return rdev->ops->dfs_start_radar_detection(&rdev->wiphy, dev);
+}
+
 static int nl80211_send_bss(struct sk_buff *msg, struct netlink_callback *cb,
 			    u32 seq, int flags,
 			    struct cfg80211_registered_device *rdev,
@@ -6711,7 +6725,14 @@ static struct genl_ops nl80211_ops[] = {
 		.internal_flags = NL80211_FLAG_NEED_NETDEV |
 				  NL80211_FLAG_NEED_RTNL,
 	},
-
+	{
+		.cmd = NL80211_CMD_DFS_RADAR_DETECTION,
+		.doit = nl80211_dfs_start_radar_detection,
+		.policy = nl80211_policy,
+		.flags = GENL_ADMIN_PERM,
+		.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+				  NL80211_FLAG_NEED_RTNL,
+	},
 };
 
 static struct genl_multicast_group nl80211_mlme_mcgrp = {
@@ -7748,6 +7769,42 @@ void nl80211_pmksa_candidate_notify(struct cfg80211_registered_device *rdev,
 }
 
 void
+nl80211_send_radar_detected_notify(struct cfg80211_registered_device *rdev,
+				   u16 freq, struct net_device *netdev,
+				   gfp_t gfp)
+{
+	struct sk_buff *msg;
+	void *hdr;
+
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
+	if (!msg)
+		return;
+
+	hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_DFS_RADAR_DETECTION);
+	if (!hdr) {
+		nlmsg_free(msg);
+		return;
+	}
+
+	NLA_PUT_U32(msg, NL80211_ATTR_WIPHY, rdev->wiphy_idx);
+	NLA_PUT_U32(msg, NL80211_ATTR_IFINDEX, netdev->ifindex);
+	NLA_PUT_U32(msg, NL80211_ATTR_WIPHY_FREQ, freq);
+
+	if (genlmsg_end(msg, hdr) < 0) {
+		nlmsg_free(msg);
+		return;
+	}
+
+	genlmsg_multicast_netns(wiphy_net(&rdev->wiphy), msg, 0,
+				nl80211_mlme_mcgrp.id, gfp);
+	return;
+
+ nla_put_failure:
+	genlmsg_cancel(msg, hdr);
+	nlmsg_free(msg);
+}
+
+void
 nl80211_send_cqm_pktloss_notify(struct cfg80211_registered_device *rdev,
 				struct net_device *netdev, const u8 *peer,
 				u32 num_packets, gfp_t gfp)
diff --git a/net/wireless/nl80211.h b/net/wireless/nl80211.h
index 12bf4d1..075bcc9 100644
--- a/net/wireless/nl80211.h
+++ b/net/wireless/nl80211.h
@@ -104,6 +104,12 @@ nl80211_send_cqm_rssi_notify(struct cfg80211_registered_device *rdev,
 			     struct net_device *netdev,
 			     enum nl80211_cqm_rssi_threshold_event rssi_event,
 			     gfp_t gfp);
+
+void
+nl80211_send_radar_detected_notify(struct cfg80211_registered_device *rdev,
+				   u16 freq, struct net_device *netdev,
+				   gfp_t gfp);
+
 void
 nl80211_send_cqm_pktloss_notify(struct cfg80211_registered_device *rdev,
 				struct net_device *netdev, const u8 *peer,
-- 
1.7.5.4

Re: [RFC 1/9] nl80211/cfg80211: add radar detection command/event

[Johannes Berg]

On 1/26/2012 4:37 AM, Victor Goldenshtein wrote:

> + * @NL80211_CMD_DFS_RADAR_DETECTION: Start radar detection in the
> + *	driver/HW. Once radar detected usermode notified with this event.

Why DFS & radar detection? I mean, why not just call it CMD_RADAR_DETECT 
or so?

> + *
> + * @dfs_start_radar_detection: Start radar detection in the driver.

ditto here

> @@ -3216,6 +3221,17 @@ void cfg80211_cqm_rssi_notify(struct net_device *dev,
>   			      gfp_t gfp);
>
>   /**
> + * cfg80211_radar_detected_notify - radar detection event

The _notify suffix seems useless, maybe remove it?

> + * @dev: network device
> + * @freq: radar detected on this channel frequency

unit?

> +static int nl80211_dfs_start_radar_detection(struct sk_buff *skb,
> +					     struct genl_info *info)
> +{
> +	struct cfg80211_registered_device *rdev = info->user_ptr[0];
> +	struct net_device *dev = info->user_ptr[1];
> +
> +	ASSERT_RDEV_LOCK(rdev);

That assert isn't really worth much here.


How do you *end* radar detection? What channel does it apply to? Any 
channel you're on? The channel you were on when it was enabled?

johannes

Re: [RFC 1/9] nl80211/cfg80211: add radar detection command/event

[Goldenshtein, Victor]

On Tue, Jan 31, 2012 at 7:39 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> Why DFS & radar detection? I mean, why not just call it CMD_RADAR_DETECT or
> so?
>

will rename it to CMD_RADAR_DETECT

>> + *
>> + * @dfs_start_radar_detection: Start radar detection in the driver.
>
>
> ditto here

will rename it to start_radar_detection

>
>
>> @@ -3216,6 +3221,17 @@ void cfg80211_cqm_rssi_notify(struct net_device
>> *dev,
>>                              gfp_t gfp);
>>
>>  /**
>> + * cfg80211_radar_detected_notify - radar detection event
>
>
> The _notify suffix seems useless, maybe remove it?
>

most of the function here use this suffix, but I don't mind to remove it ..

>
>> + * @dev: network device
>> + * @freq: radar detected on this channel frequency
>
>
> unit?
>

ok

>
>> +static int nl80211_dfs_start_radar_detection(struct sk_buff *skb,
>> +                                            struct genl_info *info)
>> +{
>> +       struct cfg80211_registered_device *rdev = info->user_ptr[0];
>> +       struct net_device *dev = info->user_ptr[1];
>> +
>> +       ASSERT_RDEV_LOCK(rdev);
>
>
> That assert isn't really worth much here.
>

will remove it also from: nl80211_dfs_en_tx, nl80211_ap_channel_switch

>
> How do you *end* radar detection? What channel does it apply to? Any channel
> you're on? The channel you were on when it was enabled?

Once we start radar detection, it should continuously monitor for
radar until we switch from this channel. The command applies to
current operational channel.


-- 
Thanks,
Victor.

Re: [RFC 1/9] nl80211/cfg80211: add radar detection command/event

[Luis R. Rodriguez]

On Thu, Feb 2, 2012 at 8:06 AM, Goldenshtein, Victor <victorg@ti.com> wrote:
> On Tue, Jan 31, 2012 at 7:39 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> Why DFS & radar detection? I mean, why not just call it CMD_RADAR_DETECT or
>> so?
>>
>
> will rename it to CMD_RADAR_DETECT

May want to also make the language a bit clearer on the description.

>>
>> How do you *end* radar detection? What channel does it apply to? Any channel
>> you're on? The channel you were on when it was enabled?
>
> Once we start radar detection, it should continuously monitor for
> radar until we switch from this channel. The command applies to
> current operational channel.

Please consider adding this to the documentation,  it would make this
crystal clear.

  Luis

Re: [RFC 1/9] nl80211/cfg80211: add radar detection command/event

[Goldenshtein, Victor]

On Fri, Feb 10, 2012 at 12:02 AM, Luis R. Rodriguez
<mcgrof@frijolero.org> wrote:
> On Thu, Feb 2, 2012 at 8:06 AM, Goldenshtein, Victor <victorg@ti.com> wrote:
>> Once we start radar detection, it should continuously monitor for
>> radar until we switch from this channel. The command applies to
>> current operational channel.
>
> Please consider adding this to the documentation,  it would make this
> crystal clear.
>

Will do that.

-- 
Thanks,
Victor.

[RFC 2/9] mac80211: add radar detection command/event

[Victor Goldenshtein]

Add command to trigger radar detection in the driver/FW.
Once radar detected usermode notified with 'radar detected'
event.

Signed-off-by: Victor Goldenshtein <victorg@ti.com>
---
 include/net/mac80211.h      |   13 +++++++++++++
 net/mac80211/cfg.c          |   17 +++++++++++++++++
 net/mac80211/driver-ops.h   |   12 ++++++++++++
 net/mac80211/driver-trace.h |    6 ++++++
 net/mac80211/mlme.c         |    9 +++++++++
 5 files changed, 57 insertions(+), 0 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 2a7523e..de3a97ee 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2236,6 +2236,8 @@ struct ieee80211_ops {
 					u16 tids, int num_frames,
 					enum ieee80211_frame_release_type reason,
 					bool more_data);
+	int (*hw_dfs_start_radar_detection)(struct ieee80211_hw *hw,
+					    struct ieee80211_vif *vif);
 };
 
 /**
@@ -3406,6 +3408,17 @@ void ieee80211_cqm_rssi_notify(struct ieee80211_vif *vif,
 			       gfp_t gfp);
 
 /**
+ * ieee80211_radar_detected_notify - inform a configured connection that
+ * radar was detected on the current channel
+ *
+ * @vif: &struct ieee80211_vif pointer from the add_interface callback.
+ * @freq: frequency of the 'radar detected' channel.
+ * @gfp: context flags.
+ */
+void ieee80211_radar_detected_notify(struct ieee80211_vif *vif,
+				     u16 freq, gfp_t gfp);
+
+/**
  * ieee80211_get_operstate - get the operstate of the vif
  *
  * @vif: &struct ieee80211_vif pointer from the add_interface callback.
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 850bb96..080a2a4 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2013,6 +2013,22 @@ static int ieee80211_cancel_remain_on_channel(struct wiphy *wiphy,
 	return ieee80211_wk_cancel_remain_on_channel(sdata, cookie);
 }
 
+static int ieee80211_dfs_start_radar_detection(struct wiphy *wiphy,
+					       struct net_device *dev)
+{
+	struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+	struct ieee80211_local *local = sdata->local;
+	int ret = -ENOENT;
+
+	if (!local->ops->hw_dfs_start_radar_detection)
+		return -EOPNOTSUPP;
+
+	mutex_lock(&local->mtx);
+	ret = drv_dfs_en_radar_detection(local, sdata);
+	mutex_unlock(&local->mtx);
+	return ret;
+}
+
 static enum work_done_result
 ieee80211_offchan_tx_done(struct ieee80211_work *wk, struct sk_buff *skb)
 {
@@ -2760,4 +2776,5 @@ struct cfg80211_ops mac80211_config_ops = {
 	.probe_client = ieee80211_probe_client,
 	.get_channel = ieee80211_wiphy_get_channel,
 	.set_noack_map = ieee80211_set_noack_map,
+	.dfs_start_radar_detection = ieee80211_dfs_start_radar_detection,
 };
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index e8960ae..b84cade 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -309,6 +309,18 @@ static inline void drv_cancel_hw_scan(struct ieee80211_local *local,
 	trace_drv_return_void(local);
 }
 
+static inline int drv_dfs_en_radar_detection(struct ieee80211_local *local,
+					 struct ieee80211_sub_if_data *sdata)
+{
+	int ret;
+
+	might_sleep();
+
+	trace_drv_dfs_en_radar_detection(local, sdata);
+	ret = local->ops->hw_dfs_start_radar_detection(&local->hw, &sdata->vif);
+	return ret;
+}
+
 static inline int
 drv_sched_scan_start(struct ieee80211_local *local,
 		     struct ieee80211_sub_if_data *sdata,
diff --git a/net/mac80211/driver-trace.h b/net/mac80211/driver-trace.h
index 6e9df8f..75cca02 100644
--- a/net/mac80211/driver-trace.h
+++ b/net/mac80211/driver-trace.h
@@ -498,6 +498,12 @@ DEFINE_EVENT(local_sdata_evt, drv_cancel_hw_scan,
 	TP_ARGS(local, sdata)
 );
 
+DEFINE_EVENT(local_sdata_evt, drv_dfs_en_radar_detection,
+	TP_PROTO(struct ieee80211_local *local,
+		 struct ieee80211_sub_if_data *sdata),
+	TP_ARGS(local, sdata)
+);
+
 DEFINE_EVENT(local_sdata_evt, drv_sched_scan_start,
 	TP_PROTO(struct ieee80211_local *local,
 		 struct ieee80211_sub_if_data *sdata),
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index ecb4c84..57aeb84 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2869,6 +2869,15 @@ void ieee80211_cqm_rssi_notify(struct ieee80211_vif *vif,
 }
 EXPORT_SYMBOL(ieee80211_cqm_rssi_notify);
 
+void ieee80211_radar_detected_notify(struct ieee80211_vif *vif,
+				     u16 freq, gfp_t gfp)
+{
+	struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
+
+	cfg80211_radar_detected_notify(sdata->dev, freq, gfp);
+}
+EXPORT_SYMBOL(ieee80211_radar_detected_notify);
+
 unsigned char ieee80211_get_operstate(struct ieee80211_vif *vif)
 {
 	struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
-- 
1.7.5.4

Re: [RFC 2/9] mac80211: add radar detection command/event

[Johannes Berg]

On 1/26/2012 4:37 AM, Victor Goldenshtein wrote:
> +	int (*hw_dfs_start_radar_detection)(struct ieee80211_hw *hw,
> +					    struct ieee80211_vif *vif);

This name is getting ridiculously long -- no need for the hw_ prefix either.

> +void ieee80211_radar_detected_notify(struct ieee80211_vif *vif,
> +				     u16 freq, gfp_t gfp);

Btw, why not a channel pointer? Most APIs use that.

> +static int ieee80211_dfs_start_radar_detection(struct wiphy *wiphy,
> +					       struct net_device *dev)
> +{
> +	struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
> +	struct ieee80211_local *local = sdata->local;
> +	int ret = -ENOENT;

??? No need for a default value.

> +	if (!local->ops->hw_dfs_start_radar_detection)
> +		return -EOPNOTSUPP;
> +
> +	mutex_lock(&local->mtx);
> +	ret = drv_dfs_en_radar_detection(local, sdata);
> +	mutex_unlock(&local->mtx);

Why even lock here? That's not protecting anything.

> +static inline int drv_dfs_en_radar_detection(struct ieee80211_local *local,
> +					 struct ieee80211_sub_if_data *sdata)
> +{
> +	int ret;
> +
> +	might_sleep();
> +
> +	trace_drv_dfs_en_radar_detection(local, sdata);
> +	ret = local->ops->hw_dfs_start_radar_detection(&local->hw,&sdata->vif);

trace_drv_ret_int()

johannes

Re: [RFC 2/9] mac80211: add radar detection command/event

[Goldenshtein, Victor]

On Tue, Jan 31, 2012 at 7:42 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> This name is getting ridiculously long -- no need for the hw_ prefix either.
>

will remove it

>
>> +void ieee80211_radar_detected_notify(struct ieee80211_vif *vif,
>> +                                    u16 freq, gfp_t gfp);
>
>
> Btw, why not a channel pointer? Most APIs use that.
>

I can't find any use for other ieee80211_channel parameters, moreover
the freq parameter is also not required for single channel platforms
because the usermode knows his own operational channel. The freq is
here for future multi-channel DFS support.

>
>> +static int ieee80211_dfs_start_radar_detection(struct wiphy *wiphy,
>> +                                              struct net_device *dev)
>> +{
>> +       struct ieee80211_sub_if_data *sdata =
>> IEEE80211_DEV_TO_SUB_IF(dev);
>> +       struct ieee80211_local *local = sdata->local;
>> +       int ret = -ENOENT;
>
>
> ??? No need for a default value.
>

right, will remove it.

>
>> +       if (!local->ops->hw_dfs_start_radar_detection)
>> +               return -EOPNOTSUPP;
>> +
>> +       mutex_lock(&local->mtx);
>> +       ret = drv_dfs_en_radar_detection(local, sdata);
>> +       mutex_unlock(&local->mtx);
>
>
> Why even lock here? That's not protecting anything.
>

will remove it.


>
>> +static inline int drv_dfs_en_radar_detection(struct ieee80211_local
>> *local,
>> +                                        struct ieee80211_sub_if_data
>> *sdata)
>> +{
>> +       int ret;
>> +
>> +       might_sleep();
>> +
>> +       trace_drv_dfs_en_radar_detection(local, sdata);
>> +       ret =
>> local->ops->hw_dfs_start_radar_detection(&local->hw,&sdata->vif);
>
>
> trace_drv_ret_int()


will change the trace to trace_drv_return_int()


-- 
Thanks,
Victor.

[RFC 3/9] nl80211/cfg80211: add ability to enable TX on op-channel

[Victor Goldenshtein]

The dfs master device should monitor radar channels
for potential radar interference for a minimum of
CAC (channel availability check) time, during this
period no tx can occur. If no radar interference
is detected the dfs master may initiate the tx with
new NL80211_CMD_DFS_ENABLE_TX command.

Signed-off-by: Victor Goldenshtein <victorg@ti.com>
---
 include/linux/nl80211.h |    9 +++++++++
 include/net/cfg80211.h  |    3 +++
 net/wireless/nl80211.c  |   22 ++++++++++++++++++++++
 3 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index 5bffba0..b45ceb1 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -544,6 +544,13 @@
  * @NL80211_CMD_DFS_RADAR_DETECTION: Start radar detection in the
  *	driver/HW. Once radar detected usermode notified with this event.
  *
+ * @NL80211_CMD_DFS_ENABLE_TX: Initiate tx after verifying radar clearness on
+ *	current channel. The dfs master device should monitor radar channels
+ *	for potential radar interference for a minimum of CAC (channel
+ *	availability check) time, during this period no tx can occur. If no
+ *	radar interference is detected during this period the dfs master may
+ *	initiate the tx.
+ *
  * @NL80211_CMD_MAX: highest used command number
  * @__NL80211_CMD_AFTER_LAST: internal use
  */
@@ -685,6 +692,8 @@ enum nl80211_commands {
 
 	NL80211_CMD_DFS_RADAR_DETECTION,
 
+	NL80211_CMD_DFS_ENABLE_TX,
+
 	/* add new commands above here */
 
 	/* used to define NL80211_CMD_MAX below */
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index b47217b..fbd5b7a 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1481,6 +1481,8 @@ struct cfg80211_gtk_rekey_data {
  * @probe_client: probe an associated client, must return a cookie that it
  *	later passes to cfg80211_probe_status().
  *
+ * @dfs_en_tx: Enable tx after radar interference check.
+ *
  * @set_noack_map: Set the NoAck Map for the TIDs.
  *
  * @dfs_start_radar_detection: Start radar detection in the driver.
@@ -1685,6 +1687,7 @@ struct cfg80211_ops {
 
 	int    (*dfs_start_radar_detection)(struct wiphy *wiphy,
 					    struct net_device *dev);
+	int    (*dfs_en_tx)(struct wiphy *wiphy, struct net_device *dev);
 };
 
 /*
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index e96bfc5..66dfcef 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -4058,6 +4058,20 @@ static int nl80211_dfs_start_radar_detection(struct sk_buff *skb,
 	return rdev->ops->dfs_start_radar_detection(&rdev->wiphy, dev);
 }
 
+static int nl80211_dfs_en_tx(struct sk_buff *skb, struct genl_info *info)
+{
+	struct cfg80211_registered_device *rdev = info->user_ptr[0];
+	struct net_device *dev = info->user_ptr[1];
+
+
+	ASSERT_RDEV_LOCK(rdev);
+
+	if (!rdev->ops->dfs_en_tx)
+		return -EOPNOTSUPP;
+
+	return rdev->ops->dfs_en_tx(&rdev->wiphy, dev);
+}
+
 static int nl80211_send_bss(struct sk_buff *msg, struct netlink_callback *cb,
 			    u32 seq, int flags,
 			    struct cfg80211_registered_device *rdev,
@@ -6733,6 +6747,14 @@ static struct genl_ops nl80211_ops[] = {
 		.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
 				  NL80211_FLAG_NEED_RTNL,
 	},
+	{
+		.cmd = NL80211_CMD_DFS_ENABLE_TX,
+		.doit = nl80211_dfs_en_tx,
+		.policy = nl80211_policy,
+		.flags = GENL_ADMIN_PERM,
+		.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+				  NL80211_FLAG_NEED_RTNL,
+	},
 };
 
 static struct genl_multicast_group nl80211_mlme_mcgrp = {
-- 
1.7.5.4

Re: [RFC 3/9] nl80211/cfg80211: add ability to enable TX on op-channel

[Johannes Berg]

On 1/26/2012 4:37 AM, Victor Goldenshtein wrote:
> The dfs master device should monitor radar channels
> for potential radar interference for a minimum of
> CAC (channel availability check) time, during this
> period no tx can occur. If no radar interference
> is detected the dfs master may initiate the tx with
> new NL80211_CMD_DFS_ENABLE_TX command.

So do we think that no safeguards here at all are acceptable? Not even 
checking that radar detection was enabled, CAC time expired, etc.?

johannes

Re: [RFC 3/9] nl80211/cfg80211: add ability to enable TX on op-channel

[Goldenshtein, Victor]

On Tue, Jan 31, 2012 at 7:43 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On 1/26/2012 4:37 AM, Victor Goldenshtein wrote:
>>
>> The dfs master device should monitor radar channels
>> for potential radar interference for a minimum of
>> CAC (channel availability check) time, during this
>> period no tx can occur. If no radar interference
>> is detected the dfs master may initiate the tx with
>> new NL80211_CMD_DFS_ENABLE_TX command.
>
>
> So do we think that no safeguards here at all are acceptable? Not even
> checking that radar detection was enabled, CAC time expired, etc.?

We can add a check whether dfs is supported by the driver
(rdev->wiphy.features & NL80211_FEATURE_DFS).

The nl/cfg/mac doesn't have the info whether the radar detection is
enabled and definitely doesn't heard about CAC time, on other hand the
driver which starts/handles radar detection know whether it started or
not. I think the driver should perform this simple "sanity" checks,
otherwise we"ll need to save different DFS states in the mac, not sure
that this is what we want.



-- 
Thanks,
Victor.

Re: [RFC 3/9] nl80211/cfg80211: add ability to enable TX on op-channel

[zefir.kurtisi]

On 02/03/2012 05:06 PM, zefir.kurtisi@gmail.com wrote:
> On 02.02.2012 17:06, Goldenshtein, Victor wrote:
>> On Tue, Jan 31, 2012 at 7:43 AM, Johannes Berg
>> <johannes@sipsolutions.net>  wrote:
>>> On 1/26/2012 4:37 AM, Victor Goldenshtein wrote:
>>>>
>>>> The dfs master device should monitor radar channels
>>>> for potential radar interference for a minimum of
>>>> CAC (channel availability check) time, during this
>>>> period no tx can occur. If no radar interference
>>>> is detected the dfs master may initiate the tx with
>>>> new NL80211_CMD_DFS_ENABLE_TX command.
>>>
>>>
>>> So do we think that no safeguards here at all are acceptable? Not even
>>> checking that radar detection was enabled, CAC time expired, etc.?
>>
>> We can add a check whether dfs is supported by the driver
>> (rdev->wiphy.features&  NL80211_FEATURE_DFS).
>>
>> The nl/cfg/mac doesn't have the info whether the radar detection is
>> enabled and definitely doesn't heard about CAC time, on other hand the
>> driver which starts/handles radar detection know whether it started or
>> not. I think the driver should perform this simple "sanity" checks,
>> otherwise we"ll need to save different DFS states in the mac, not sure
>> that this is what we want.
>>
>>
>>
> I noticed this issue working on interfacing ath9k to your DFS 
> [ ... more unfinished garbage ]

Sorry folks for that garbage. My Thunderbird crashed in the middle of writing and for some reason sent out the draft after restart (which I noticed right now).

So, what I really wanted to comment is:

I noticed this issue working on interfacing ath9k to your DFS management component. When a DFS channel is initially set, the driver has no information whether to block TX or not (as opposed to ap_process_chanswitch() providing these flags). What is the assumption here? Is the driver required to check itself whether a DFS channel is set and raise some internal tx_disabled flag to be reset via hw_dfs_en_tx()? With all the logic being located in hostap, this looks inconsistent (but doable).

Aside from that, I managed to interface ath9k to the proposed component. So far, it enables me to set up a DFS monitor to physically test my pattern detectors, while it fails to run in master mode. Need to go through the trace logs to isolate the problem and will report then.


Thanks
Zefir

Re: [RFC 3/9] nl80211/cfg80211: add ability to enable TX on op-channel

[Goldenshtein, Victor]

On Mon, Feb 6, 2012 at 1:16 PM, zefir.kurtisi@gmail.com
<zefir.kurtisi@gmail.com> wrote:
> I noticed this issue working on interfacing ath9k to your DFS management component. When a DFS channel is initially set, the driver has no information whether to block TX or not (as opposed to ap_process_chanswitch() providing these flags). What is the assumption here? Is the driver required to check itself whether a DFS channel is set and raise some internal tx_disabled flag to be reset via hw_dfs_en_tx()? With all the logic being located in hostap, this looks inconsistent (but doable).
>

When a DFS channel is initially set (with hostapd_set_freq()) the AP
is during early init phase and obviously not transmitting anything yet
at this point, the AP should start the tx (transmitting beacons) only
after hostapd_setup_bss() call, which is blocked until we validate the
channel for radar clearness. If during the CAC tes a radar is detected
we select and set another frequency/channel (still with
hostapd_set_freq()) and start the radar detection once again for the
new freq. Once the channel pass the "channel availability check" we
continue with the init flow as usual. IMHO the driver doesn't need to
block anything at this point and no flag is required.

In wl12xx we have one "FLAG_DFS_CAC_IN_PROGRESS" which basically
indicates that we're in the middle of a CAC test and no tx can occur
during this period. This flag is set during
"hw_dfs_start_radar_detection()" and unset during hw_dfs_en_tx(), this
is one of the reason that I thought to change the "hw_dfs_en_tx()" to
something like "dfs_resume_cac()", in this case it would be also
aligned with "hostapd_resume_dfs_cac()" callback, what do you think
about this?


> Aside from that, I managed to interface ath9k to the proposed component. So far, it enables me to set up a DFS monitor to physically test my pattern detectors, while it fails to run in master mode. Need to go through the trace logs to isolate the problem and will report then.
>

We're planning to release wl12xx DFS RFC which might help better
understand the DFS implementation from driver's point of view.


-- 
Thanks,
Victor.

Re: [RFC 3/9] nl80211/cfg80211: add ability to enable TX on op-channel

[Zefir Kurtisi]

On 02/06/2012 02:01 PM, Goldenshtein, Victor wrote:
> On Mon, Feb 6, 2012 at 1:16 PM, zefir.kurtisi@gmail.com 
> <zefir.kurtisi@gmail.com> wrote:
>> I noticed this issue working on interfacing ath9k to your DFS
>> management component. When a DFS channel is initially set, the
>> driver has no information whether to block TX or not (as opposed to
>> ap_process_chanswitch() providing these flags). What is the
>> assumption here? Is the driver required to check itself whether a
>> DFS channel is set and raise some internal tx_disabled flag to be
>> reset via hw_dfs_en_tx()? With all the logic being located in
>> hostap, this looks inconsistent (but doable).
>> 
> 
> When a DFS channel is initially set (with hostapd_set_freq()) the AP 
> is during early init phase and obviously not transmitting anything
> yet at this point, the AP should start the tx (transmitting beacons)
> only after hostapd_setup_bss() call, which is blocked until we
> validate the channel for radar clearness. If during the CAC tes a
> radar is detected we select and set another frequency/channel (still
> with hostapd_set_freq()) and start the radar detection once again for
> the new freq. Once the channel pass the "channel availability check"
> we continue with the init flow as usual. IMHO the driver doesn't need
> to block anything at this point and no flag is required.
> 
> In wl12xx we have one "FLAG_DFS_CAC_IN_PROGRESS" which basically 
> indicates that we're in the middle of a CAC test and no tx can occur 
> during this period. This flag is set during 
> "hw_dfs_start_radar_detection()" and unset during hw_dfs_en_tx(),
> this is one of the reason that I thought to change the
> "hw_dfs_en_tx()" to something like "dfs_resume_cac()", in this case
> it would be also aligned with "hostapd_resume_dfs_cac()" callback,
> what do you think about this?
> 
So the driver does not need to be aware of disabled TX condition at all, since hostapd ensures that no TX will happen during CAC? What is then your FLAG_DFS_CAC_IN_PROGRESS used for?

As for the naming, I'd maybe call them just dfs_start_cac() and dfs_end_cac(), but am also fine with the 'resume' variant.
 
> 
>> Aside from that, I managed to interface ath9k to the proposed
>> component. So far, it enables me to set up a DFS monitor to
>> physically test my pattern detectors, while it fails to run in
>> master mode. Need to go through the trace logs to isolate the
>> problem and will report then.
>> 
> 
> We're planning to release wl12xx DFS RFC which might help better 
> understand the DFS implementation from driver's point of view.
> 
> 
Yeah, having a working reference implementation would definitively help.


Thanks,
Zefir

Re: [RFC 3/9] nl80211/cfg80211: add ability to enable TX on op-channel

[Goldenshtein, Victor]

On Mon, Feb 6, 2012 at 4:48 PM, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
> So the driver does not need to be aware of disabled TX condition at all, since hostapd ensures that no TX will happen during CAC? What is then your FLAG_DFS_CAC_IN_PROGRESS used for?
>

Additional protection prior starting the AP role.

> As for the naming, I'd maybe call them just dfs_start_cac() and dfs_end_cac(), but am also fine with the 'resume' variant.
>

Both this are also fine with me.


-- 
Victor.

Re: [RFC 3/9] nl80211/cfg80211: add ability to enable TX on op-channel

[Johannes Berg]

On Thu, 2012-02-02 at 18:06 +0200, Goldenshtein, Victor wrote:

> > So do we think that no safeguards here at all are acceptable? Not even
> > checking that radar detection was enabled, CAC time expired, etc.?
> 
> We can add a check whether dfs is supported by the driver
> (rdev->wiphy.features & NL80211_FEATURE_DFS).
> 
> The nl/cfg/mac doesn't have the info whether the radar detection is
> enabled and definitely doesn't heard about CAC time, on other hand the
> driver which starts/handles radar detection know whether it started or
> not. 

I'm just trying to make sure that you're OK with a simple two-line iw
patch being sufficient to start transmitting on radar channels ...

> I think the driver should perform this simple "sanity" checks,
> otherwise we"ll need to save different DFS states in the mac, not sure
> that this is what we want.

I disagree -- adding this in each driver, which will surely end up with
slightly different semantics, seems like a recipe for disaster.

johannes

Re: [RFC 3/9] nl80211/cfg80211: add ability to enable TX on op-channel

[Goldenshtein, Victor]

On Mon, Feb 6, 2012 at 11:01 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> I'm just trying to make sure that you're OK with a simple two-line iw
> patch being sufficient to start transmitting on radar channels ...
>
>> I think the driver should perform this simple "sanity" checks,
>> otherwise we"ll need to save different DFS states in the mac, not sure
>> that this is what we want.
>
> I disagree -- adding this in each driver, which will surely end up with
> slightly different semantics, seems like a recipe for disaster.
>

Zefir Kurtisi and myself thought to rename the start_radar detection +
en_tx functions to something like
dfs_start_cac() and dfs_resume_cac(), these two will set/reset
WIPHY_FLAG_DFS_CAC_IN_PROGRESS flag, which should add some additional
protection.
Are you OK with this ?


-- 
Thanks,
Victor.

Re: [RFC 3/9] nl80211/cfg80211: add ability to enable TX on op-channel

[Luis R. Rodriguez]

On Thu, Feb 9, 2012 at 1:04 PM, Goldenshtein, Victor <victorg@ti.com> wrote:
> On Mon, Feb 6, 2012 at 11:01 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> I'm just trying to make sure that you're OK with a simple two-line iw
>> patch being sufficient to start transmitting on radar channels ...
>>
>>> I think the driver should perform this simple "sanity" checks,
>>> otherwise we"ll need to save different DFS states in the mac, not sure
>>> that this is what we want.
>>
>> I disagree -- adding this in each driver, which will surely end up with
>> slightly different semantics, seems like a recipe for disaster.
>>
>
> Zefir Kurtisi and myself thought to rename the start_radar detection +
> en_tx functions to something like
> dfs_start_cac() and dfs_resume_cac(), these two will set/reset
> WIPHY_FLAG_DFS_CAC_IN_PROGRESS flag, which should add some additional
> protection.
> Are you OK with this ?

I'd be more comfortable with a timer for the CAC as well.

  Luis

Re: [RFC 3/9] nl80211/cfg80211: add ability to enable TX on op-channel

[Goldenshtein, Victor]

On Fri, Feb 10, 2012 at 12:34 AM, Luis R. Rodriguez
<mcgrof@frijolero.org> wrote:
> On Thu, Feb 9, 2012 at 1:04 PM, Goldenshtein, Victor <victorg@ti.com> wrote:
>> Zefir Kurtisi and myself thought to rename the start_radar detection +
>> en_tx functions to something like
>> dfs_start_cac() and dfs_resume_cac(), these two will set/reset
>> WIPHY_FLAG_DFS_CAC_IN_PROGRESS flag, which should add some additional
>> protection.
>> Are you OK with this ?
>
> I'd be more comfortable with a timer for the CAC as well.
>
>  Luis

Not sure I"m understand what you're saying here, the CAC timer handled
in the hostap, kernel doesn't know anything about it. The
WIPHY_FLAG_DFS_CAC_IN_PROGRESS exactly says that DFS master (hostapd)
performs a channel availability check, which also indicates that the
CAC timer is running (if this what you mean).



-- 
Thanks,
Victor.

Re: [RFC 3/9] nl80211/cfg80211: add ability to enable TX on op-channel

[Goldenshtein, Victor]

On Wed, Feb 15, 2012 at 6:45 PM, Goldenshtein, Victor <victorg@ti.com> wrote:
> On Fri, Feb 10, 2012 at 12:34 AM, Luis R. Rodriguez
> > I'd be more comfortable with a timer for the CAC as well.
> >
> >  Luis
>
> Not sure I"m understand what you're saying here, the CAC timer handled
> in the hostap, kernel doesn't know anything about it. The
> WIPHY_FLAG_DFS_CAC_IN_PROGRESS exactly says that DFS master (hostapd)
> performs a channel availability check, which also indicates that the
> CAC timer is running (if this what you mean).
>

To add an additional protection will also save a time stamp of the
last start radar detection command (something like
"last_dfs_cac_time"), and prior enabling the tx on the DFS channels
will validate whether DFS_MIN_CAC_TIME (60 seconds) has passed since
"last_dfs_cac_time".

--
Thanks,
Victor.

Re: [RFC 3/9] nl80211/cfg80211: add ability to enable TX on op-channel

[Coelho, Luciano]

Hi Victor,

On 3/15/12, Goldenshtein, Victor <victorg@ti.com> wrote:
> To add an additional protection will also save a time stamp of the
> last start radar detection command (something like
> "last_dfs_cac_time"), and prior enabling the tx on the DFS channels
> will validate whether DFS_MIN_CAC_TIME (60 seconds) has passed since
> "last_dfs_cac_time".

Remember to also reset the last_dfs_cac_time when you receive a
RADAR_DETECTED event, as we discussed.  This will make sure we never
allow TX in DFS channels unless the DFS_MIN_CAC_TIME has passed since
detection started AND since the last radio signal was detected.

This will prevent the userspace from TXing illegally in DFS channels.

-- 
Cheers,
Luca.

[RFC 4/9] mac80211: add ability to enable TX on op-channel

[Victor Goldenshtein]

Prior starting tx on DFS channels, the DFS master
device shall perform a Channel Availability Check
to ensure that there is no radar interference on
those channels. Once CAC done, the tx can be
enabled with ieee80211_dfs_en_tx().

Signed-off-by: Victor Goldenshtein <victorg@ti.com>
---
 include/net/mac80211.h      |    2 ++
 net/mac80211/cfg.c          |   16 ++++++++++++++++
 net/mac80211/driver-ops.h   |   12 ++++++++++++
 net/mac80211/driver-trace.h |    6 ++++++
 4 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index de3a97ee..d08b808 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2238,6 +2238,8 @@ struct ieee80211_ops {
 					bool more_data);
 	int (*hw_dfs_start_radar_detection)(struct ieee80211_hw *hw,
 					    struct ieee80211_vif *vif);
+	int (*hw_dfs_en_tx)(struct ieee80211_hw *hw,
+			    struct ieee80211_vif *vif);
 };
 
 /**
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 080a2a4..2d85a97 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2029,6 +2029,21 @@ static int ieee80211_dfs_start_radar_detection(struct wiphy *wiphy,
 	return ret;
 }
 
+static int ieee80211_dfs_en_tx(struct wiphy *wiphy, struct net_device *dev)
+{
+	struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+	struct ieee80211_local *local = sdata->local;
+	int ret = -ENOENT;
+
+	if (!local->ops->hw_dfs_en_tx)
+		return -EOPNOTSUPP;
+
+	mutex_lock(&local->mtx);
+	ret = drv_dfs_en_tx(local, sdata);
+	mutex_unlock(&local->mtx);
+	return ret;
+}
+
 static enum work_done_result
 ieee80211_offchan_tx_done(struct ieee80211_work *wk, struct sk_buff *skb)
 {
@@ -2777,4 +2792,5 @@ struct cfg80211_ops mac80211_config_ops = {
 	.get_channel = ieee80211_wiphy_get_channel,
 	.set_noack_map = ieee80211_set_noack_map,
 	.dfs_start_radar_detection = ieee80211_dfs_start_radar_detection,
+	.dfs_en_tx = ieee80211_dfs_en_tx,
 };
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index b84cade..b37fac5 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -321,6 +321,18 @@ static inline int drv_dfs_en_radar_detection(struct ieee80211_local *local,
 	return ret;
 }
 
+static inline int drv_dfs_en_tx(struct ieee80211_local *local,
+				struct ieee80211_sub_if_data *sdata)
+{
+	int ret;
+
+	might_sleep();
+
+	trace_drv_dfs_en_tx(local, sdata);
+	ret = local->ops->hw_dfs_en_tx(&local->hw, &sdata->vif);
+	return ret;
+}
+
 static inline int
 drv_sched_scan_start(struct ieee80211_local *local,
 		     struct ieee80211_sub_if_data *sdata,
diff --git a/net/mac80211/driver-trace.h b/net/mac80211/driver-trace.h
index 75cca02..5ec9792 100644
--- a/net/mac80211/driver-trace.h
+++ b/net/mac80211/driver-trace.h
@@ -504,6 +504,12 @@ DEFINE_EVENT(local_sdata_evt, drv_dfs_en_radar_detection,
 	TP_ARGS(local, sdata)
 );
 
+DEFINE_EVENT(local_sdata_evt, drv_dfs_en_tx,
+	TP_PROTO(struct ieee80211_local *local,
+		 struct ieee80211_sub_if_data *sdata),
+	TP_ARGS(local, sdata)
+);
+
 DEFINE_EVENT(local_sdata_evt, drv_sched_scan_start,
 	TP_PROTO(struct ieee80211_local *local,
 		 struct ieee80211_sub_if_data *sdata),
-- 
1.7.5.4

Re: [RFC 4/9] mac80211: add ability to enable TX on op-channel

[Johannes Berg]

On 1/26/2012 4:37 AM, Victor Goldenshtein wrote:
> Prior starting tx on DFS channels, the DFS master
> device shall perform a Channel Availability Check
> to ensure that there is no radar interference on
> those channels. Once CAC done, the tx can be
> enabled with ieee80211_dfs_en_tx().

How do you expect this to be used by the device? It seems that it should 
have the side effect of lifting some TX-prohibited flag instead?

johannes

Re: [RFC 4/9] mac80211: add ability to enable TX on op-channel

[Goldenshtein, Victor]

On Tue, Jan 31, 2012 at 7:45 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On 1/26/2012 4:37 AM, Victor Goldenshtein wrote:
>>
>> Prior starting tx on DFS channels, the DFS master
>> device shall perform a Channel Availability Check
>> to ensure that there is no radar interference on
>> those channels. Once CAC done, the tx can be
>> enabled with ieee80211_dfs_en_tx().
>
>
> How do you expect this to be used by the device? It seems that it should
> have the side effect of lifting some TX-prohibited flag instead?

In wl12xx driver we starting the AP role, and clearing FLAG_DFS_CAC_IN_PROGRESS.
Maybe the function name is misleading here ? maybe we should rename it
to something like resume_dfs_cac() - because it is called at the end
of the CAC test.

The other question is whether we want to add DFS flags into mac? I
mean something like FLAG_DFS_CAC_IN_PROGRESS.

-- 
Thanks,
Victor.

Re: [RFC 4/9] mac80211: add ability to enable TX on op-channel

[Luis R. Rodriguez]

On Thu, Feb 2, 2012 at 8:06 AM, Goldenshtein, Victor <victorg@ti.com> wrote:
> On Tue, Jan 31, 2012 at 7:45 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> On 1/26/2012 4:37 AM, Victor Goldenshtein wrote:
>>>
>>> Prior starting tx on DFS channels, the DFS master
>>> device shall perform a Channel Availability Check
>>> to ensure that there is no radar interference on
>>> those channels. Once CAC done, the tx can be
>>> enabled with ieee80211_dfs_en_tx().
>>
>>
>> How do you expect this to be used by the device? It seems that it should
>> have the side effect of lifting some TX-prohibited flag instead?
>
> In wl12xx driver we starting the AP role, and clearing FLAG_DFS_CAC_IN_PROGRESS.
> Maybe the function name is misleading here ? maybe we should rename it
> to something like resume_dfs_cac() - because it is called at the end
> of the CAC test.
>
> The other question is whether we want to add DFS flags into mac? I
> mean something like FLAG_DFS_CAC_IN_PROGRESS.

How about that and a CAC timer as sanity checks to cfg80211, not mac80211.

  Luis

Re: [RFC 4/9] mac80211: add ability to enable TX on op-channel

[Goldenshtein, Victor]

On Fri, Feb 10, 2012 at 12:36 AM, Luis R. Rodriguez
<mcgrof@frijolero.org> wrote:
> How about that and a CAC timer as sanity checks to cfg80211, not mac80211.
>

Please see my previous email.

-- 
Thanks,
Victor.

[RFC 5/9] nl80211/cfg80211: add ap channel switch command/event

[Victor Goldenshtein]

Add new NL80211_CMD_AP_CHANNEL_SWITCH command which
triggers a channel switch process, this command also
notifies usermode about channel switch complete event.

Signed-off-by: Victor Goldenshtein <victorg@ti.com>
---
 include/linux/nl80211.h |   23 +++++++++++++
 include/net/cfg80211.h  |   16 +++++++++
 net/wireless/mlme.c     |   11 ++++++
 net/wireless/nl80211.c  |   80 +++++++++++++++++++++++++++++++++++++++++++++++
 net/wireless/nl80211.h  |    4 ++
 5 files changed, 134 insertions(+), 0 deletions(-)

diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index b45ceb1..8a004fc 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -551,6 +551,15 @@
  *	radar interference is detected during this period the dfs master may
  *	initiate the tx.
  *
+ * @NL80211_CMD_AP_CHANNEL_SWITCH: Perform a channel switch in the driver (for
+ *	AP/GO).
+ *	%NL80211_ATTR_WIPHY_FREQ: new channel frequency.
+ *	%NL80211_ATTR_CH_SWITCH_BLOCK_TX: block tx on the current channel.
+ *	%NL80211_ATTR_CH_SWITCH_POST_BLOCK_TX: block tx on the target channel.
+ *	%NL80211_FREQ_ATTR_CH_SWITCH_COUNT: number of TBTT's until the channel
+ *	switch event.
+ *	This command will also notify about channel switch complete event.
+ *
  * @NL80211_CMD_MAX: highest used command number
  * @__NL80211_CMD_AFTER_LAST: internal use
  */
@@ -694,6 +703,8 @@ enum nl80211_commands {
 
 	NL80211_CMD_DFS_ENABLE_TX,
 
+	NL80211_CMD_AP_CHANNEL_SWITCH,
+
 	/* add new commands above here */
 
 	/* used to define NL80211_CMD_MAX below */
@@ -1207,6 +1218,14 @@ enum nl80211_commands {
  * @NL80211_ATTR_NOACK_MAP: This u16 bitmap contains the No Ack Policy of
  *      up to 16 TIDs.
  *
+ * @NL80211_ATTR_CH_SWITCH_COUNT: the number of TBTT's until the channel
+ *	switch event
+ * @NL80211_ATTR_CH_SWITCH_BLOCK_TX: block tx on the current channel before the
+ *	channel switch operation.
+ * @NL80211_ATTR_CH_SWITCH_POST_BLOCK_TX: block tx on the target channel after
+ *	the channel switch operation, should be set if the target channel is
+ *	DFS channel.
+ *
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
  */
@@ -1452,6 +1471,10 @@ enum nl80211_attrs {
 
 	NL80211_ATTR_NOACK_MAP,
 
+	NL80211_ATTR_CH_SWITCH_COUNT,
+	NL80211_ATTR_CH_SWITCH_BLOCK_TX,
+	NL80211_ATTR_CH_SWITCH_POST_BLOCK_TX,
+
 	/* add attributes here, update the policy in nl80211.c */
 
 	__NL80211_ATTR_AFTER_LAST,
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index fbd5b7a..824883a 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1486,6 +1486,8 @@ struct cfg80211_gtk_rekey_data {
  * @set_noack_map: Set the NoAck Map for the TIDs.
  *
  * @dfs_start_radar_detection: Start radar detection in the driver.
+ *
+ * @ap_channel_switch: Perform a channel switch (for AP/GO).
  */
 struct cfg80211_ops {
 	int	(*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
@@ -1688,6 +1690,10 @@ struct cfg80211_ops {
 	int    (*dfs_start_radar_detection)(struct wiphy *wiphy,
 					    struct net_device *dev);
 	int    (*dfs_en_tx)(struct wiphy *wiphy, struct net_device *dev);
+
+	int    (*ap_channel_switch)(struct wiphy *wiphy, struct net_device *dev,
+				    u32 count, bool block_tx,
+				    bool post_switch_block_tx, u32 freq);
 };
 
 /*
@@ -3235,6 +3241,16 @@ void cfg80211_radar_detected_notify(struct net_device *dev,
 				    u16 freq, gfp_t gfp);
 
 /**
+ * cfg80211_ap_ch_switch_complete_notify - channel switch complete event
+ * @dev: network device
+ * @gfp: context flags
+ *
+ * Notify userspace about channel switch complete event.
+ */
+void cfg80211_ap_ch_switch_complete_notify(struct net_device *dev,
+					   u16 freq, gfp_t gfp);
+
+/**
  * cfg80211_cqm_pktloss_notify - notify userspace about packetloss to peer
  * @dev: network device
  * @peer: peer's MAC address
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index 6ef723d..c9837a2 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -1119,6 +1119,17 @@ void cfg80211_radar_detected_notify(struct net_device *dev, u16 freq, gfp_t gfp)
 }
 EXPORT_SYMBOL(cfg80211_radar_detected_notify);
 
+void cfg80211_ap_ch_switch_complete_notify(struct net_device *dev,
+					   u16 freq, gfp_t gfp)
+{
+	struct wireless_dev *wdev = dev->ieee80211_ptr;
+	struct wiphy *wiphy = wdev->wiphy;
+	struct cfg80211_registered_device *rdev = wiphy_to_dev(wiphy);
+
+	nl80211_ap_ch_switch_complete_notify(rdev, freq, dev, gfp);
+}
+EXPORT_SYMBOL(cfg80211_ap_ch_switch_complete_notify);
+
 void cfg80211_cqm_pktloss_notify(struct net_device *dev,
 				 const u8 *peer, u32 num_packets, gfp_t gfp)
 {
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 66dfcef..8fe7e59 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -204,6 +204,9 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
 		.len = NL80211_HT_CAPABILITY_LEN
 	},
 	[NL80211_ATTR_NOACK_MAP] = { .type = NLA_U16 },
+	[NL80211_ATTR_CH_SWITCH_COUNT] = { .type = NLA_U32 },
+	[NL80211_ATTR_CH_SWITCH_BLOCK_TX] = { .type = NLA_FLAG },
+	[NL80211_ATTR_CH_SWITCH_POST_BLOCK_TX] = { .type = NLA_FLAG },
 };
 
 /* policy for the key attributes */
@@ -4072,6 +4075,39 @@ static int nl80211_dfs_en_tx(struct sk_buff *skb, struct genl_info *info)
 	return rdev->ops->dfs_en_tx(&rdev->wiphy, dev);
 }
 
+static int nl80211_ap_channel_switch(struct sk_buff *skb,
+				     struct genl_info *info)
+{
+	struct cfg80211_registered_device *rdev = info->user_ptr[0];
+	struct net_device *dev = info->user_ptr[1];
+	u32 freq = 0, count = 0, post_switch_block_tx = 0, block_tx = 0;
+
+	ASSERT_RDEV_LOCK(rdev);
+
+	if (!rdev->ops->ap_channel_switch)
+		return -EOPNOTSUPP;
+
+	if (dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP &&
+	    dev->ieee80211_ptr->iftype != NL80211_IFTYPE_P2P_GO)
+		return -EOPNOTSUPP;
+
+	if (!info->attrs[NL80211_ATTR_CH_SWITCH_COUNT] ||
+	    !info->attrs[NL80211_ATTR_WIPHY_FREQ])
+		return -EINVAL;
+
+	count = nla_get_u32(info->attrs[NL80211_ATTR_CH_SWITCH_COUNT]);
+	freq = nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_FREQ]);
+
+	if (info->attrs[NL80211_ATTR_CH_SWITCH_BLOCK_TX])
+		block_tx = true;
+
+	if (info->attrs[NL80211_ATTR_CH_SWITCH_POST_BLOCK_TX])
+		post_switch_block_tx = true;
+
+	return rdev->ops->ap_channel_switch(&rdev->wiphy, dev, count, block_tx,
+					    post_switch_block_tx, freq);
+}
+
 static int nl80211_send_bss(struct sk_buff *msg, struct netlink_callback *cb,
 			    u32 seq, int flags,
 			    struct cfg80211_registered_device *rdev,
@@ -6755,6 +6791,14 @@ static struct genl_ops nl80211_ops[] = {
 		.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
 				  NL80211_FLAG_NEED_RTNL,
 	},
+	{
+		.cmd = NL80211_CMD_AP_CHANNEL_SWITCH,
+		.doit = nl80211_ap_channel_switch,
+		.policy = nl80211_policy,
+		.flags = GENL_ADMIN_PERM,
+		.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+				  NL80211_FLAG_NEED_RTNL,
+	},
 };
 
 static struct genl_multicast_group nl80211_mlme_mcgrp = {
@@ -7827,6 +7871,42 @@ nl80211_send_radar_detected_notify(struct cfg80211_registered_device *rdev,
 }
 
 void
+nl80211_ap_ch_switch_complete_notify(struct cfg80211_registered_device *rdev,
+				     u16 freq, struct net_device *netdev,
+				     gfp_t gfp)
+{
+	struct sk_buff *msg;
+	void *hdr;
+
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
+	if (!msg)
+		return;
+
+	hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_AP_CHANNEL_SWITCH);
+	if (!hdr) {
+		nlmsg_free(msg);
+		return;
+	}
+
+	NLA_PUT_U32(msg, NL80211_ATTR_WIPHY, rdev->wiphy_idx);
+	NLA_PUT_U32(msg, NL80211_ATTR_IFINDEX, netdev->ifindex);
+	NLA_PUT_U32(msg, NL80211_ATTR_WIPHY_FREQ, freq);
+
+	if (genlmsg_end(msg, hdr) < 0) {
+		nlmsg_free(msg);
+		return;
+	}
+
+	genlmsg_multicast_netns(wiphy_net(&rdev->wiphy), msg, 0,
+				nl80211_mlme_mcgrp.id, gfp);
+	return;
+
+ nla_put_failure:
+	genlmsg_cancel(msg, hdr);
+	nlmsg_free(msg);
+}
+
+void
 nl80211_send_cqm_pktloss_notify(struct cfg80211_registered_device *rdev,
 				struct net_device *netdev, const u8 *peer,
 				u32 num_packets, gfp_t gfp)
diff --git a/net/wireless/nl80211.h b/net/wireless/nl80211.h
index 075bcc9..2dd37d2 100644
--- a/net/wireless/nl80211.h
+++ b/net/wireless/nl80211.h
@@ -109,6 +109,10 @@ void
 nl80211_send_radar_detected_notify(struct cfg80211_registered_device *rdev,
 				   u16 freq, struct net_device *netdev,
 				   gfp_t gfp);
+void
+nl80211_ap_ch_switch_complete_notify(struct cfg80211_registered_device *rdev,
+				     u16 freq, struct net_device *netdev,
+				     gfp_t gfp);
 
 void
 nl80211_send_cqm_pktloss_notify(struct cfg80211_registered_device *rdev,
-- 
1.7.5.4

Re: [RFC 5/9] nl80211/cfg80211: add ap channel switch command/event

[Johannes Berg]

On 1/26/2012 4:38 AM, Victor Goldenshtein wrote:
> Add new NL80211_CMD_AP_CHANNEL_SWITCH command which
> triggers a channel switch process, this command also
> notifies usermode about channel switch complete event.

I think this needs a little more explaining how it would be used with 
hostapd adding the channel switch IEs into the beacon.

johannes

Re: [RFC 5/9] nl80211/cfg80211: add ap channel switch command/event

[Goldenshtein, Victor]

On Tue, Jan 31, 2012 at 7:46 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On 1/26/2012 4:38 AM, Victor Goldenshtein wrote:
>>
>> Add new NL80211_CMD_AP_CHANNEL_SWITCH command which
>> triggers a channel switch process, this command also
>> notifies usermode about channel switch complete event.
>
>
> I think this needs a little more explaining how it would be used with
> hostapd adding the channel switch IEs into the beacon.
>

Will add additional explanation.

-- 
Thanks,
Victor.

Re: [RFC 5/9] nl80211/cfg80211: add ap channel switch command/event

[Luis R. Rodriguez]

On Thu, Jan 26, 2012 at 4:38 AM, Victor Goldenshtein <victorg@ti.com> wrote:
> Add new NL80211_CMD_AP_CHANNEL_SWITCH command which
> triggers a channel switch process, this command also
> notifies usermode about channel switch complete event.
>
> Signed-off-by: Victor Goldenshtein <victorg@ti.com>
> ---
>  include/linux/nl80211.h |   23 +++++++++++++
>  include/net/cfg80211.h  |   16 +++++++++
>  net/wireless/mlme.c     |   11 ++++++
>  net/wireless/nl80211.c  |   80 +++++++++++++++++++++++++++++++++++++++++++++++
>  net/wireless/nl80211.h  |    4 ++
>  5 files changed, 134 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
> index b45ceb1..8a004fc 100644
> --- a/include/linux/nl80211.h
> +++ b/include/linux/nl80211.h
> @@ -551,6 +551,15 @@
>  *     radar interference is detected during this period the dfs master may
>  *     initiate the tx.
>  *
> + * @NL80211_CMD_AP_CHANNEL_SWITCH: Perform a channel switch in the driver (for
> + *     AP/GO).
> + *     %NL80211_ATTR_WIPHY_FREQ: new channel frequency.
> + *     %NL80211_ATTR_CH_SWITCH_BLOCK_TX: block tx on the current channel.
> + *     %NL80211_ATTR_CH_SWITCH_POST_BLOCK_TX: block tx on the target channel.

This is left as optional. It would be good to explain why this is
option and/or why userspace would set this
NL80211_ATTR_CH_SWITCH_POST_BLOCK_TX flag or not.

> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> @@ -4072,6 +4075,39 @@ static int nl80211_dfs_en_tx(struct sk_buff *skb, struct genl_info *info)
>        return rdev->ops->dfs_en_tx(&rdev->wiphy, dev);
>  }
>
> +static int nl80211_ap_channel_switch(struct sk_buff *skb,
> +                                    struct genl_info *info)
> +{
> +       struct cfg80211_registered_device *rdev = info->user_ptr[0];
> +       struct net_device *dev = info->user_ptr[1];
> +       u32 freq = 0, count = 0, post_switch_block_tx = 0, block_tx = 0;

Please use bool for flags.

> +
> +       ASSERT_RDEV_LOCK(rdev);
> +
> +       if (!rdev->ops->ap_channel_switch)
> +               return -EOPNOTSUPP;
> +
> +       if (dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP &&
> +           dev->ieee80211_ptr->iftype != NL80211_IFTYPE_P2P_GO)
> +               return -EOPNOTSUPP;

If we want to restrict this command from userspace to only be able to
issue a channel switch for DFS we need to consider some additional
sanity checks here. It may be worth adding a small state machine to
cfg80211 for the device and only allow certain of these commands for
specific DFS states, if these commands are to be used only on DFS
states. This would limit the stupidities that userspace can put
cfg80211 into.

  Luis

Re: [RFC 5/9] nl80211/cfg80211: add ap channel switch command/event

[Goldenshtein, Victor]

On Fri, Feb 10, 2012 at 12:53 AM, Luis R. Rodriguez
<mcgrof@frijolero.org> wrote:
> On Thu, Jan 26, 2012 at 4:38 AM, Victor Goldenshtein <victorg@ti.com> wrote:
>> Add new NL80211_CMD_AP_CHANNEL_SWITCH command which
>> triggers a channel switch process, this command also
>> notifies usermode about channel switch complete event.
>>
>> Signed-off-by: Victor Goldenshtein <victorg@ti.com>
>> ---
>>  include/linux/nl80211.h |   23 +++++++++++++
>>  include/net/cfg80211.h  |   16 +++++++++
>>  net/wireless/mlme.c     |   11 ++++++
>>  net/wireless/nl80211.c  |   80 +++++++++++++++++++++++++++++++++++++++++++++++
>>  net/wireless/nl80211.h  |    4 ++
>>  5 files changed, 134 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
>> index b45ceb1..8a004fc 100644
>> --- a/include/linux/nl80211.h
>> +++ b/include/linux/nl80211.h
>> @@ -551,6 +551,15 @@
>>  *     radar interference is detected during this period the dfs master may
>>  *     initiate the tx.
>>  *
>> + * @NL80211_CMD_AP_CHANNEL_SWITCH: Perform a channel switch in the driver (for
>> + *     AP/GO).
>> + *     %NL80211_ATTR_WIPHY_FREQ: new channel frequency.
>> + *     %NL80211_ATTR_CH_SWITCH_BLOCK_TX: block tx on the current channel.
>> + *     %NL80211_ATTR_CH_SWITCH_POST_BLOCK_TX: block tx on the target channel.
>
> This is left as optional. It would be good to explain why this is
> option and/or why userspace would set this
> NL80211_ATTR_CH_SWITCH_POST_BLOCK_TX flag or not.
>
>> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
>> @@ -4072,6 +4075,39 @@ static int nl80211_dfs_en_tx(struct sk_buff *skb, struct genl_info *info)
>>        return rdev->ops->dfs_en_tx(&rdev->wiphy, dev);
>>  }
>>
>> +static int nl80211_ap_channel_switch(struct sk_buff *skb,
>> +                                    struct genl_info *info)
>> +{
>> +       struct cfg80211_registered_device *rdev = info->user_ptr[0];
>> +       struct net_device *dev = info->user_ptr[1];
>> +       u32 freq = 0, count = 0, post_switch_block_tx = 0, block_tx = 0;
>
> Please use bool for flags.
>

ok.

>> +
>> +       ASSERT_RDEV_LOCK(rdev);
>> +
>> +       if (!rdev->ops->ap_channel_switch)
>> +               return -EOPNOTSUPP;
>> +
>> +       if (dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP &&
>> +           dev->ieee80211_ptr->iftype != NL80211_IFTYPE_P2P_GO)
>> +               return -EOPNOTSUPP;
>
> If we want to restrict this command from userspace to only be able to
> issue a channel switch for DFS we need to consider some additional
> sanity checks here. It may be worth adding a small state machine to
> cfg80211 for the device and only allow certain of these commands for
> specific DFS states, if these commands are to be used only on DFS
> states. This would limit the stupidities that userspace can put
> cfg80211 into.
>

DFS implementation in driver has only one state - DFS_CAC_IN_PROGRESS,
so I"m not sure we need here a state machine but some sanity checks
will be added in the next RFC.


-- 
Thanks,
Victor.

[RFC 6/9] mac80211: add ap channel switch command/event

[Victor Goldenshtein]

New ieee80211_ap_process_chanswitch(), to handle a channel switch
request for AP/GO.

New 'post_switch_block_tx' parameter in 'ieee80211_channel_switch'
structure, which indicates whether transmission must be blocked after
the scheduled channel switch, it should be set if the target channel
is DFS channel.

New ieee80211_ap_ch_switch_complete_notify() which notifies upper
layers about channel switch complete event.

Signed-off-by: Victor Goldenshtein <victorg@ti.com>
---
 include/net/mac80211.h |   15 +++++++++++++++
 net/mac80211/cfg.c     |   34 ++++++++++++++++++++++++++++++++++
 net/mac80211/mlme.c    |    9 +++++++++
 3 files changed, 58 insertions(+), 0 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index d08b808..b0f4e67 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -841,12 +841,16 @@ struct ieee80211_conf {
  *	the driver passed into mac80211.
  * @block_tx: Indicates whether transmission must be blocked before the
  *	scheduled channel switch, as indicated by the AP.
+ * @post_switch_block_tx: Indicates whether transmission must be blocked after
+ *	the scheduled channel switch, this should be set if the target channel
+ *	is DFS channel.
  * @channel: the new channel to switch to
  * @count: the number of TBTT's until the channel switch event
  */
 struct ieee80211_channel_switch {
 	u64 timestamp;
 	bool block_tx;
+	bool post_switch_block_tx;
 	struct ieee80211_channel *channel;
 	u8 count;
 };
@@ -3421,6 +3425,17 @@ void ieee80211_radar_detected_notify(struct ieee80211_vif *vif,
 				     u16 freq, gfp_t gfp);
 
 /**
+ * ieee80211_ap_ch_switch_complete_notify - inform a configured connection that
+ * channel switch is complete
+ *
+ * @vif: &struct ieee80211_vif pointer from the add_interface callback.
+ * @gfp: context flags
+ *
+ */
+void ieee80211_ap_ch_switch_complete_notify(struct ieee80211_vif *vif,
+					    u16 freq, gfp_t gfp);
+
+/**
  * ieee80211_get_operstate - get the operstate of the vif
  *
  * @vif: &struct ieee80211_vif pointer from the add_interface callback.
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 2d85a97..89393c8 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2044,6 +2044,39 @@ static int ieee80211_dfs_en_tx(struct wiphy *wiphy, struct net_device *dev)
 	return ret;
 }
 
+static int ieee80211_ap_process_chanswitch(struct wiphy *wiphy,
+					   struct net_device *dev,
+					   u32 count, bool block_tx,
+					   bool post_switch_block_tx,
+					   u32 new_freq)
+{
+	struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+	struct ieee80211_local *local = sdata->local;
+	struct ieee80211_channel *new_ch;
+	struct ieee80211_channel_switch ch_switch;
+
+	new_ch = ieee80211_get_channel(sdata->local->hw.wiphy, new_freq);
+	if (!new_ch || new_ch->flags & IEEE80211_CHAN_DISABLED) {
+		wiphy_debug(local->hw.wiphy,
+			    "failed channel switch on freq: %d\n", new_freq);
+		return -EINVAL;
+	}
+
+	if (!local->ops->channel_switch)
+		return -EOPNOTSUPP;
+
+	memset(&ch_switch, 0, sizeof(ch_switch));
+	ch_switch.channel = new_ch;
+	ch_switch.count = count;
+	ch_switch.block_tx = block_tx;
+	ch_switch.post_switch_block_tx = post_switch_block_tx;
+
+	mutex_lock(&local->mtx);
+	drv_channel_switch(local, &ch_switch);
+	mutex_unlock(&local->mtx);
+	return 0;
+}
+
 static enum work_done_result
 ieee80211_offchan_tx_done(struct ieee80211_work *wk, struct sk_buff *skb)
 {
@@ -2793,4 +2826,5 @@ struct cfg80211_ops mac80211_config_ops = {
 	.set_noack_map = ieee80211_set_noack_map,
 	.dfs_start_radar_detection = ieee80211_dfs_start_radar_detection,
 	.dfs_en_tx = ieee80211_dfs_en_tx,
+	.ap_channel_switch = ieee80211_ap_process_chanswitch,
 };
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 57aeb84..a39b8ed 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2878,6 +2878,15 @@ void ieee80211_radar_detected_notify(struct ieee80211_vif *vif,
 }
 EXPORT_SYMBOL(ieee80211_radar_detected_notify);
 
+void ieee80211_ap_ch_switch_complete_notify(struct ieee80211_vif *vif,
+					    u16 freq, gfp_t gfp)
+{
+	struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
+
+	cfg80211_ap_ch_switch_complete_notify(sdata->dev, freq, gfp);
+}
+EXPORT_SYMBOL(ieee80211_ap_ch_switch_complete_notify);
+
 unsigned char ieee80211_get_operstate(struct ieee80211_vif *vif)
 {
 	struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
-- 
1.7.5.4

Re: [RFC 6/9] mac80211: add ap channel switch command/event

[Johannes Berg]

On 1/26/2012 4:38 AM, Victor Goldenshtein wrote:
> New ieee80211_ap_process_chanswitch(), to handle a channel switch
> request for AP/GO.
>
> New 'post_switch_block_tx' parameter in 'ieee80211_channel_switch'
> structure, which indicates whether transmission must be blocked after
> the scheduled channel switch, it should be set if the target channel
> is DFS channel.
>
> New ieee80211_ap_ch_switch_complete_notify() which notifies upper
> layers about channel switch complete event.

Shouldn't mac80211 have some non-offload implementation for this?

> @@ -841,12 +841,16 @@ struct ieee80211_conf {
>    *	the driver passed into mac80211.
>    * @block_tx: Indicates whether transmission must be blocked before the
>    *	scheduled channel switch, as indicated by the AP.
> + * @post_switch_block_tx: Indicates whether transmission must be blocked after
> + *	the scheduled channel switch, this should be set if the target channel
> + *	is DFS channel.

Hmmm. This channel switch stuff here was really intended for client-side 
channel switching initially ... and it should quite possibly be a 
different mechanism?

> +static int ieee80211_ap_process_chanswitch(struct wiphy *wiphy,
> +					   struct net_device *dev,
> +					   u32 count, bool block_tx,
> +					   bool post_switch_block_tx,
> +					   u32 new_freq)
> +{
> +	struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
> +	struct ieee80211_local *local = sdata->local;
> +	struct ieee80211_channel *new_ch;
> +	struct ieee80211_channel_switch ch_switch;
> +
> +	new_ch = ieee80211_get_channel(sdata->local->hw.wiphy, new_freq);
> +	if (!new_ch || new_ch->flags&  IEEE80211_CHAN_DISABLED) {
> +		wiphy_debug(local->hw.wiphy,
> +			    "failed channel switch on freq: %d\n", new_freq);
> +		return -EINVAL;
> +	}

That code should obviously be in cfg80211.

> @@ -2793,4 +2826,5 @@ struct cfg80211_ops mac80211_config_ops = {
>   	.set_noack_map = ieee80211_set_noack_map,
>   	.dfs_start_radar_detection = ieee80211_dfs_start_radar_detection,
>   	.dfs_en_tx = ieee80211_dfs_en_tx,
> +	.ap_channel_switch = ieee80211_ap_process_chanswitch,

why deviate from the ieee80211_ + callback_name scheme?

johannes

Re: [RFC 6/9] mac80211: add ap channel switch command/event

[Goldenshtein, Victor]

On Tue, Jan 31, 2012 at 7:51 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On 1/26/2012 4:38 AM, Victor Goldenshtein wrote:
>>
>> New ieee80211_ap_process_chanswitch(), to handle a channel switch
>> request for AP/GO.
>>
>> New 'post_switch_block_tx' parameter in 'ieee80211_channel_switch'
>> structure, which indicates whether transmission must be blocked after
>> the scheduled channel switch, it should be set if the target channel
>> is DFS channel.
>>
>> New ieee80211_ap_ch_switch_complete_notify() which notifies upper
>> layers about channel switch complete event.
>
>
> Shouldn't mac80211 have some non-offload implementation for this?
>
>

What do you mean by "non-offload"?

>> @@ -841,12 +841,16 @@ struct ieee80211_conf {
>>   *    the driver passed into mac80211.
>>   * @block_tx: Indicates whether transmission must be blocked before the
>>   *    scheduled channel switch, as indicated by the AP.
>> + * @post_switch_block_tx: Indicates whether transmission must be blocked
>> after
>> + *     the scheduled channel switch, this should be set if the target
>> channel
>> + *     is DFS channel.
>
>
> Hmmm. This channel switch stuff here was really intended for client-side
> channel switching initially ... and it should quite possibly be a different
> mechanism?
>

The mechanism is different from the client-side channel switch, but
the "ieee80211_channel_switch" struct is almost the same (new
post_switch_block_tx). Do you prefer to create a new
"ieee80211_ap_channel_switch" struct + new driver callback ? something
like drv_ap_channel_switch ?

>> +static int ieee80211_ap_process_chanswitch(struct wiphy *wiphy,
>> +                                          struct net_device *dev,
>> +                                          u32 count, bool block_tx,
>> +                                          bool post_switch_block_tx,
>> +                                          u32 new_freq)
>> +{
>> +       struct ieee80211_sub_if_data *sdata =
>> IEEE80211_DEV_TO_SUB_IF(dev);
>> +       struct ieee80211_local *local = sdata->local;
>> +       struct ieee80211_channel *new_ch;
>> +       struct ieee80211_channel_switch ch_switch;
>> +
>> +       new_ch = ieee80211_get_channel(sdata->local->hw.wiphy, new_freq);
>> +       if (!new_ch || new_ch->flags&  IEEE80211_CHAN_DISABLED) {
>>
>> +               wiphy_debug(local->hw.wiphy,
>> +                           "failed channel switch on freq: %d\n",
>> new_freq);
>> +               return -EINVAL;
>> +       }
>
>
> That code should obviously be in cfg80211.
>

Why ? and where exactly ?

>
>> @@ -2793,4 +2826,5 @@ struct cfg80211_ops mac80211_config_ops = {
>>        .set_noack_map = ieee80211_set_noack_map,
>>        .dfs_start_radar_detection = ieee80211_dfs_start_radar_detection,
>>        .dfs_en_tx = ieee80211_dfs_en_tx,
>> +       .ap_channel_switch = ieee80211_ap_process_chanswitch,
>
>
> why deviate from the ieee80211_ + callback_name scheme?
>

Wanted to be aligned with ieee80211_sta_process_chanswitch(), will rename it.


-- 
Thanks,
Victor.

Re: [RFC 6/9] mac80211: add ap channel switch command/event

[Johannes Berg]

On Thu, 2012-02-02 at 18:07 +0200, Goldenshtein, Victor wrote:
> On Tue, Jan 31, 2012 at 7:51 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On 1/26/2012 4:38 AM, Victor Goldenshtein wrote:
> >>
> >> New ieee80211_ap_process_chanswitch(), to handle a channel switch
> >> request for AP/GO.
> >>
> >> New 'post_switch_block_tx' parameter in 'ieee80211_channel_switch'
> >> structure, which indicates whether transmission must be blocked after
> >> the scheduled channel switch, it should be set if the target channel
> >> is DFS channel.
> >>
> >> New ieee80211_ap_ch_switch_complete_notify() which notifies upper
> >> layers about channel switch complete event.
> >
> >
> > Shouldn't mac80211 have some non-offload implementation for this?

> What do you mean by "non-offload"?

When the driver doesn't explicitly implement channel switch for this and
other things, mac80211 could (should?) manage it.

> The mechanism is different from the client-side channel switch, but
> the "ieee80211_channel_switch" struct is almost the same (new
> post_switch_block_tx). Do you prefer to create a new
> "ieee80211_ap_channel_switch" struct + new driver callback ? something
> like drv_ap_channel_switch ?

I think that would be cleaner in terms of API, since not all drivers
will support both.

> >> +static int ieee80211_ap_process_chanswitch(struct wiphy *wiphy,
> >> +                                          struct net_device *dev,
> >> +                                          u32 count, bool block_tx,
> >> +                                          bool post_switch_block_tx,
> >> +                                          u32 new_freq)
> >> +{
> >> +       struct ieee80211_sub_if_data *sdata =
> >> IEEE80211_DEV_TO_SUB_IF(dev);
> >> +       struct ieee80211_local *local = sdata->local;
> >> +       struct ieee80211_channel *new_ch;
> >> +       struct ieee80211_channel_switch ch_switch;
> >> +
> >> +       new_ch = ieee80211_get_channel(sdata->local->hw.wiphy, new_freq);
> >> +       if (!new_ch || new_ch->flags&  IEEE80211_CHAN_DISABLED) {
> >>
> >> +               wiphy_debug(local->hw.wiphy,
> >> +                           "failed channel switch on freq: %d\n",
> >> new_freq);
> >> +               return -EINVAL;
> >> +       }
> >
> >
> > That code should obviously be in cfg80211.
> >
> 
> Why ? and where exactly ?

Why? because all drivers will need to make this check. Wherever cfg80211
calls into this, of course, and then you'd cal in with a channel pointer
rather than the new freq.

johannes

Re: [RFC 6/9] mac80211: add ap channel switch command/event

[Goldenshtein, Victor]

On Mon, Feb 6, 2012 at 11:03 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> When the driver doesn't explicitly implement channel switch for this and
> other things, mac80211 could (should?) manage it.
>

I guess it can be implemented at some later point.


>> The mechanism is different from the client-side channel switch, but
>> the "ieee80211_channel_switch" struct is almost the same (new
>> post_switch_block_tx). Do you prefer to create a new
>> "ieee80211_ap_channel_switch" struct + new driver callback ? something
>> like drv_ap_channel_switch ?
>
> I think that would be cleaner in terms of API, since not all drivers
> will support both.
>

I will do that.

-- 
Thanks,
Victor.

Re: [RFC 6/9] mac80211: add ap channel switch command/event

[Luis R. Rodriguez]

On Thu, Feb 9, 2012 at 12:02 PM, Goldenshtein, Victor <victorg@ti.com> wrote:
> On Mon, Feb 6, 2012 at 11:03 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> When the driver doesn't explicitly implement channel switch for this and
>> other things, mac80211 could (should?) manage it.
>>
>
> I guess it can be implemented at some later point.

Then you need to ensure that a capability is checked and if this
capability is required but not available yet in mac80211 DFS cannot be
started.

  Luis

Re: [RFC 6/9] mac80211: add ap channel switch command/event

[Goldenshtein, Victor]

On Fri, Feb 10, 2012 at 1:04 AM, Luis R. Rodriguez <mcgrof@frijolero.org> wrote:
> Then you need to ensure that a capability is checked and if this
> capability is required but not available yet in mac80211 DFS cannot be
> started.
>

Good point, I will add this check.


-- 
Thanks,
Victor.

Re: [RFC 6/9] mac80211: add ap channel switch command/event

[Luis R. Rodriguez]

On Thu, Jan 26, 2012 at 4:38 AM, Victor Goldenshtein <victorg@ti.com> wrote:
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index d08b808..b0f4e67 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -841,12 +841,16 @@ struct ieee80211_conf {
>  *     the driver passed into mac80211.
>  * @block_tx: Indicates whether transmission must be blocked before the
>  *     scheduled channel switch, as indicated by the AP.
> + * @post_switch_block_tx: Indicates whether transmission must be blocked after
> + *     the scheduled channel switch, this should be set if the target channel
> + *     is DFS channel.

Here you say that post_switch_block_tx is required for DFS channels
but yet you do not check for this. You should instead clarify that
this is required on the nl80211.h command, and also add the sanity
check there.

  Luis

Re: [RFC 6/9] mac80211: add ap channel switch command/event

[Goldenshtein, Victor]

On Fri, Feb 10, 2012 at 1:06 AM, Luis R. Rodriguez <mcgrof@frijolero.org> wrote:
> On Thu, Jan 26, 2012 at 4:38 AM, Victor Goldenshtein <victorg@ti.com> wrote:
>> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
>> index d08b808..b0f4e67 100644
>> --- a/include/net/mac80211.h
>> +++ b/include/net/mac80211.h
>> @@ -841,12 +841,16 @@ struct ieee80211_conf {
>>  *     the driver passed into mac80211.
>>  * @block_tx: Indicates whether transmission must be blocked before the
>>  *     scheduled channel switch, as indicated by the AP.
>> + * @post_switch_block_tx: Indicates whether transmission must be blocked after
>> + *     the scheduled channel switch, this should be set if the target channel
>> + *     is DFS channel.
>
> Here you say that post_switch_block_tx is required for DFS channels
> but yet you do not check for this. You should instead clarify that
> this is required on the nl80211.h command, and also add the sanity
> check there.
>
>  Luis

The AP channel switch functionality is not only for DFS, in the future
other usermode applications/clients might also use it (e.g. ACS ;)).
 In addition even the DFS-Master may switch to a non DFS channel - so
this post_switch_block_tx won't be set.


-- 
Thanks,
Victor.

[RFC 7/9] nl80211/cfg80211: add DFS feature flag

[Victor Goldenshtein]

Add new NL80211_FEATURE_DFS attribute which indicates
that driver/HW supports radar detection.

Signed-off-by: Victor Goldenshtein <victorg@ti.com>
---
 include/linux/nl80211.h |    2 ++
 include/net/cfg80211.h  |    3 +++
 net/wireless/nl80211.c  |   17 ++++++++++++++++-
 3 files changed, 21 insertions(+), 1 deletions(-)

diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index 8a004fc..0ec7956 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -2829,10 +2829,12 @@ enum nl80211_ap_sme_features {
  *	TX status to the socket error queue when requested with the
  *	socket option.
  * @NL80211_FEATURE_HT_IBSS: This driver supports IBSS with HT datarates.
+ * @NL80211_FEATURE_DFS: Radar detection is supported in the HW/driver.
  */
 enum nl80211_feature_flags {
 	NL80211_FEATURE_SK_TX_STATUS	= 1 << 0,
 	NL80211_FEATURE_HT_IBSS		= 1 << 1,
+	NL80211_FEATURE_DFS		= 1 << 2,
 };
 
 /**
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 824883a..363ff09 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1762,6 +1762,8 @@ struct cfg80211_ops {
  *	responds to probe-requests in hardware.
  * @WIPHY_FLAG_OFFCHAN_TX: Device supports direct off-channel TX.
  * @WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL: Device supports remain-on-channel call.
+ * @WIPHY_FLAG_SUPPORTS_DFS: The device supports radar detection
+ *	in the HW/driver.
  */
 enum wiphy_flags {
 	WIPHY_FLAG_CUSTOM_REGULATORY		= BIT(0),
@@ -1785,6 +1787,7 @@ enum wiphy_flags {
 	WIPHY_FLAG_AP_PROBE_RESP_OFFLOAD	= BIT(19),
 	WIPHY_FLAG_OFFCHAN_TX			= BIT(20),
 	WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL	= BIT(21),
+	WIPHY_FLAG_SUPPORTS_DFS			= BIT(22),
 };
 
 /**
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 8fe7e59..3bb83c4 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -695,6 +695,20 @@ nla_put_failure:
 	return -ENOBUFS;
 }
 
+static int nl80211_put_feature_flags(struct wiphy *wiphy,
+				     struct sk_buff *msg)
+{
+	if (wiphy->flags & WIPHY_FLAG_SUPPORTS_DFS)
+		wiphy->features |= NL80211_FEATURE_DFS;
+
+
+	NLA_PUT_U32(msg, NL80211_ATTR_FEATURE_FLAGS, wiphy->features);
+
+	return 0;
+nla_put_failure:
+	return -ENOBUFS;
+}
+
 static int nl80211_send_wiphy(struct sk_buff *msg, u32 pid, u32 seq, int flags,
 			      struct cfg80211_registered_device *dev)
 {
@@ -1038,7 +1052,8 @@ static int nl80211_send_wiphy(struct sk_buff *msg, u32 pid, u32 seq, int flags,
 		NLA_PUT_U32(msg, NL80211_ATTR_DEVICE_AP_SME,
 			    dev->wiphy.ap_sme_capa);
 
-	NLA_PUT_U32(msg, NL80211_ATTR_FEATURE_FLAGS, dev->wiphy.features);
+	if (nl80211_put_feature_flags(&dev->wiphy, msg))
+		goto nla_put_failure;
 
 	if (dev->wiphy.ht_capa_mod_mask)
 		NLA_PUT(msg, NL80211_ATTR_HT_CAPABILITY_MASK,
-- 
1.7.5.4

Re: [RFC 7/9] nl80211/cfg80211: add DFS feature flag

[Johannes Berg]

On 1/26/2012 4:38 AM, Victor Goldenshtein wrote:
> +static int nl80211_put_feature_flags(struct wiphy *wiphy,
> +				     struct sk_buff *msg)
> +{
> +	if (wiphy->flags&  WIPHY_FLAG_SUPPORTS_DFS)
> +		wiphy->features |= NL80211_FEATURE_DFS;
> +
> +
> +	NLA_PUT_U32(msg, NL80211_ATTR_FEATURE_FLAGS, wiphy->features);
> +
> +	return 0;
> +nla_put_failure:
> +	return -ENOBUFS;
> +}

I think you misunderstood the new feature flags -- they're supposed to 
be set by the driver directly, not indirectly via wiphy->flags.

johannes

Re: [RFC 7/9] nl80211/cfg80211: add DFS feature flag

[Goldenshtein, Victor]

On Tue, Jan 31, 2012 at 7:52 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On 1/26/2012 4:38 AM, Victor Goldenshtein wrote:
>>
>> +static int nl80211_put_feature_flags(struct wiphy *wiphy,
>> +                                    struct sk_buff *msg)
>> +{
>> +       if (wiphy->flags&  WIPHY_FLAG_SUPPORTS_DFS)
>>
>> +               wiphy->features |= NL80211_FEATURE_DFS;
>> +
>> +
>> +       NLA_PUT_U32(msg, NL80211_ATTR_FEATURE_FLAGS, wiphy->features);
>> +
>> +       return 0;
>> +nla_put_failure:
>> +       return -ENOBUFS;
>> +}
>
>
> I think you misunderstood the new feature flags -- they're supposed to be
> set by the driver directly, not indirectly via wiphy->flags.
>

yep, I guess you're right.



-- 
Thanks,
Victor.

Re: [RFC 7/9] nl80211/cfg80211: add DFS feature flag

[Luis R. Rodriguez]

On Thu, Feb 2, 2012 at 8:08 AM, Goldenshtein, Victor <victorg@ti.com> wrote:
> On Tue, Jan 31, 2012 at 7:52 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> On 1/26/2012 4:38 AM, Victor Goldenshtein wrote:
>>>
>>> +static int nl80211_put_feature_flags(struct wiphy *wiphy,
>>> +                                    struct sk_buff *msg)
>>> +{
>>> +       if (wiphy->flags&  WIPHY_FLAG_SUPPORTS_DFS)
>>>
>>> +               wiphy->features |= NL80211_FEATURE_DFS;
>>> +
>>> +
>>> +       NLA_PUT_U32(msg, NL80211_ATTR_FEATURE_FLAGS, wiphy->features);
>>> +
>>> +       return 0;
>>> +nla_put_failure:
>>> +       return -ENOBUFS;
>>> +}
>>
>>
>> I think you misunderstood the new feature flags -- they're supposed to be
>> set by the driver directly, not indirectly via wiphy->flags.
>>
>
> yep, I guess you're right.

While a it, consider adding one for the requirement of sending the
channel switch announcement within mac80211, not the driver. In that
case, although a DFS feature may be available in the driver, DFS
should not be enabled on the driver through nl80211 unless that
feature gets implemented in mac80211.

  Luis

Re: [RFC 7/9] nl80211/cfg80211: add DFS feature flag

[Johannes Berg]

On Thu, 2012-02-09 at 15:11 -0800, Luis R. Rodriguez wrote:
> On Thu, Feb 2, 2012 at 8:08 AM, Goldenshtein, Victor <victorg@ti.com> wrote:
> > On Tue, Jan 31, 2012 at 7:52 AM, Johannes Berg
> > <johannes@sipsolutions.net> wrote:
> >> On 1/26/2012 4:38 AM, Victor Goldenshtein wrote:
> >>>
> >>> +static int nl80211_put_feature_flags(struct wiphy *wiphy,
> >>> +                                    struct sk_buff *msg)
> >>> +{
> >>> +       if (wiphy->flags&  WIPHY_FLAG_SUPPORTS_DFS)
> >>>
> >>> +               wiphy->features |= NL80211_FEATURE_DFS;
> >>> +
> >>> +
> >>> +       NLA_PUT_U32(msg, NL80211_ATTR_FEATURE_FLAGS, wiphy->features);
> >>> +
> >>> +       return 0;
> >>> +nla_put_failure:
> >>> +       return -ENOBUFS;
> >>> +}
> >>
> >>
> >> I think you misunderstood the new feature flags -- they're supposed to be
> >> set by the driver directly, not indirectly via wiphy->flags.
> >>
> >
> > yep, I guess you're right.
> 
> While a it, consider adding one for the requirement of sending the
> channel switch announcement within mac80211, not the driver. In that
> case, although a DFS feature may be available in the driver, DFS
> should not be enabled on the driver through nl80211 unless that
> feature gets implemented in mac80211.

That, however, should be feature flag in mac80211, not cfg80211 (wiphy),
and in fact I think it can probably be done by checking if the low-level
function is there instead.

johannes

Re: [RFC 7/9] nl80211/cfg80211: add DFS feature flag

[Goldenshtein, Victor]

On Mon, Feb 13, 2012 at 12:28 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2012-02-09 at 15:11 -0800, Luis R. Rodriguez wrote:
>> On Thu, Feb 2, 2012 at 8:08 AM, Goldenshtein, Victor <victorg@ti.com> wrote:
>> > On Tue, Jan 31, 2012 at 7:52 AM, Johannes Berg
>> > <johannes@sipsolutions.net> wrote:
>> >> On 1/26/2012 4:38 AM, Victor Goldenshtein wrote:
>> >>>
>> >>> +static int nl80211_put_feature_flags(struct wiphy *wiphy,
>> >>> +                                    struct sk_buff *msg)
>> >>> +{
>> >>> +       if (wiphy->flags&  WIPHY_FLAG_SUPPORTS_DFS)
>> >>>
>> >>> +               wiphy->features |= NL80211_FEATURE_DFS;
>> >>> +
>> >>> +
>> >>> +       NLA_PUT_U32(msg, NL80211_ATTR_FEATURE_FLAGS, wiphy->features);
>> >>> +
>> >>> +       return 0;
>> >>> +nla_put_failure:
>> >>> +       return -ENOBUFS;
>> >>> +}
>> >>
>> >>
>> >> I think you misunderstood the new feature flags -- they're supposed to be
>> >> set by the driver directly, not indirectly via wiphy->flags.
>> >>
>> >
>> > yep, I guess you're right.
>>
>> While a it, consider adding one for the requirement of sending the
>> channel switch announcement within mac80211, not the driver. In that
>> case, although a DFS feature may be available in the driver, DFS
>> should not be enabled on the driver through nl80211 unless that
>> feature gets implemented in mac80211.
>
> That, however, should be feature flag in mac80211, not cfg80211 (wiphy),
> and in fact I think it can probably be done by checking if the low-level
> function is there instead.
>
> johannes
>

Besides the NL80211_FEATURE_DFS, I'd prefer to add an additional flag
which will indicate current DFS state, as I wrote in one of my
previous emails:
Zefir Kurtisi and myself thought to rename the start_radar detection +
en_tx functions to something like dfs_start_cac() and
dfs_resume_cac(),
these two will set/reset WIPHY_FLAG_DFS_CAC_IN_PROGRESS flag, which
should add some additional protection.


-- 
Thanks,
Victor.

Re: [RFC 7/9] nl80211/cfg80211: add DFS feature flag

[Goldenshtein, Victor]

On Fri, Feb 10, 2012 at 1:11 AM, Luis R. Rodriguez <mcgrof@frijolero.org> wrote:
> While a it, consider adding one for the requirement of sending the
> channel switch announcement within mac80211, not the driver. In that
> case, although a DFS feature may be available in the driver, DFS
> should not be enabled on the driver through nl80211 unless that
> feature gets implemented in mac80211.
>

At this point I'd prefer to stick to the original design proposal.

-- 
Thanks,
Victor.

[RFC 8/9] mac80211: add DFS capabilities flag

[Victor Goldenshtein]

Add new IEEE80211_HW_SUPPORTS_RADAR_DETECTION attribute which
indicates that hw supports radar detection.

Signed-off-by: Victor Goldenshtein <victorg@ti.com>
---
 include/net/mac80211.h |    3 +++
 net/mac80211/main.c    |    3 +++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index b0f4e67..90564b4 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1138,6 +1138,8 @@ enum sta_notify_cmd {
  * @IEEE80211_HW_TX_AMPDU_SETUP_IN_HW: The device handles TX A-MPDU session
  *	setup strictly in HW. mac80211 should not attempt to do this in
  *	software.
+ *
+ * @IEEE80211_HW_SUPPORTS_RADAR_DETECTION: Hardware supports radar detection.
  */
 enum ieee80211_hw_flags {
 	IEEE80211_HW_HAS_RATE_CONTROL			= 1<<0,
@@ -1164,6 +1166,7 @@ enum ieee80211_hw_flags {
 	IEEE80211_HW_SUPPORTS_PER_STA_GTK		= 1<<21,
 	IEEE80211_HW_AP_LINK_PS				= 1<<22,
 	IEEE80211_HW_TX_AMPDU_SETUP_IN_HW		= 1<<23,
+	IEEE80211_HW_SUPPORTS_RADAR_DETECTION		= 1<<24,
 };
 
 /**
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 0a0d94a..4ec847c 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -866,6 +866,9 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
 	if (local->hw.wiphy->flags & WIPHY_FLAG_SUPPORTS_TDLS)
 		local->hw.wiphy->flags |= WIPHY_FLAG_TDLS_EXTERNAL_SETUP;
 
+	if (local->hw.flags & IEEE80211_HW_SUPPORTS_RADAR_DETECTION)
+		local->hw.wiphy->flags |= WIPHY_FLAG_SUPPORTS_DFS;
+
 	result = wiphy_register(local->hw.wiphy);
 	if (result < 0)
 		goto fail_wiphy_register;
-- 
1.7.5.4

Re: [RFC 8/9] mac80211: add DFS capabilities flag

[Johannes Berg]

On 1/26/2012 4:38 AM, Victor Goldenshtein wrote:
> Add new IEEE80211_HW_SUPPORTS_RADAR_DETECTION attribute which
> indicates that hw supports radar detection.

No need, driver can set the nl80211 flags directly.

johannes

Re: [RFC 8/9] mac80211: add DFS capabilities flag

[Goldenshtein, Victor]

On Tue, Jan 31, 2012 at 7:52 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On 1/26/2012 4:38 AM, Victor Goldenshtein wrote:
>>
>> Add new IEEE80211_HW_SUPPORTS_RADAR_DETECTION attribute which
>> indicates that hw supports radar detection.
>
>
> No need, driver can set the nl80211 flags directly.

ok.


Thanks for the review,
Victor.

[RFC 9/9] mac80211: add DFS support to monitor interface

[Victor Goldenshtein]

Stop dropping packets if we are on 'radar channel'
and the DFS is enabled/supported.

Signed-off-by: Victor Goldenshtein <victorg@ti.com>
---
 net/mac80211/tx.c |   15 +++++++++------
 1 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index edcd1c7..2c728a4 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1569,6 +1569,8 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
 	struct ieee80211_sub_if_data *tmp_sdata, *sdata;
 	u16 len_rthdr;
 	int hdrlen;
+	bool dfs_supported = !!(local->hw.wiphy->flags &
+				WIPHY_FLAG_SUPPORTS_DFS);
 
 	/*
 	 * Frame injection is not allowed if beaconing is not allowed
@@ -1581,15 +1583,16 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
 	 * flag.
 	 *
 	 * Since AP mode uses monitor interfaces to inject/TX management
-	 * frames we can make AP mode the exception to this rule once it
-	 * supports radar detection as its implementation can deal with
-	 * radar detection by itself. We can do that later by adding a
-	 * monitor flag interfaces used for AP support.
+	 * frames we can make AP mode the exception to this rule, in the
+	 * case the driver supports radar detection, allow usage of radar
+	 * channels.
 	 */
-	if ((chan->flags & (IEEE80211_CHAN_NO_IBSS | IEEE80211_CHAN_RADAR |
-	     IEEE80211_CHAN_PASSIVE_SCAN)))
+	if ((!(chan->flags & IEEE80211_CHAN_RADAR) || !dfs_supported) &&
+	    ((chan->flags & (IEEE80211_CHAN_NO_IBSS | IEEE80211_CHAN_RADAR |
+	    IEEE80211_CHAN_PASSIVE_SCAN))))
 		goto fail;
 
+
 	/* check for not even having the fixed radiotap header part */
 	if (unlikely(skb->len < sizeof(struct ieee80211_radiotap_header)))
 		goto fail; /* too short to be possibly valid */
-- 
1.7.5.4

Re: [RFC 9/9] mac80211: add DFS support to monitor interface

[Christian Lamparter]

On Thursday, January 26, 2012 01:38:04 PM Victor Goldenshtein wrote:
> Stop dropping packets if we are on 'radar channel'
> and the DFS is enabled/supported.
> 
> Signed-off-by: Victor Goldenshtein <victorg@ti.com>
> ---
>  net/mac80211/tx.c |   15 +++++++++------
>  1 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index edcd1c7..2c728a4 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -1581,15 +1583,16 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
>  	 * flag.
>  	 *
>  	 * Since AP mode uses monitor interfaces to inject/TX management
> -	 * frames we can make AP mode the exception to this rule once it
> -	 * supports radar detection as its implementation can deal with
> -	 * radar detection by itself. We can do that later by adding a
> -	 * monitor flag interfaces used for AP support.
> +	 * frames we can make AP mode the exception to this rule, in the
> +	 * case the driver supports radar detection, allow usage of radar
> +	 * channels.
>  	 */

Hey, that's great!

I have one question: Wasn't the monitor interface [for AP mode] being
rendered obsolete by Johannes cfg80211-internal-ap-mlme work? If so,
then we could save us the work here, right?

BTW, what about cfg80211_can_beacon_sec_chan in net/wireless/chan.c?
I think it needs to be updated or else we can't have HT40 [secondary
channels] on frequencies which require DFS.

Regards,
	Chr

Re: [RFC 9/9] mac80211: add DFS support to monitor interface

[Goldenshtein, Victor]

On Thu, Jan 26, 2012 at 4:10 PM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
>
> Hey, that's great!
>
> I have one question: Wasn't the monitor interface [for AP mode] being
> rendered obsolete by Johannes cfg80211-internal-ap-mlme work? If so,
> then we could save us the work here, right?

Yep, you're right.

> BTW, what about cfg80211_can_beacon_sec_chan in net/wireless/chan.c?
> I think it needs to be updated or else we can't have HT40 [secondary
> channels] on frequencies which require DFS.

DFS is not supported with HT40 in this initial release, updating the
cfg80211_can_beacon_sec_chan is not enough, we should also check that
there is no radar interference on the secondary channel (if it's a
radar channel).

-- 
Thanks,
Victor.