From: Dmitry Lebed <[email protected]>
Add wiphy flag to indicate that HW does all DFS actions by itself.
User-space functionality already implemented in hostapd using
vendor-specific (QCA) OUI to advertise HW support.
Need to introduce generic flag to inform about DFS offload support.
For deivces with DFS_OFFLOAD flag set user-space will no longer
need to issue CAC or do any actions in response to
"radar detected" events. HW will do everything by itself and send
events to user-space to idicate that CAC was started/finished, etc.
Signed-off-by: Dmitrii Lebed <[email protected]>
---
include/net/cfg80211.h | 7 ++++++-
include/uapi/linux/nl80211.h | 9 +++++++++
net/wireless/nl80211.c | 7 +++++++
3 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index ed3a28105d6c..b2d17993ae4d 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3241,6 +3241,11 @@ struct cfg80211_ops {
* @WIPHY_FLAG_IBSS_RSN: The device supports IBSS RSN.
* @WIPHY_FLAG_MESH_AUTH: The device supports mesh authentication by routing
* auth frames to userspace. See @NL80211_MESH_SETUP_USERSPACE_AUTH.
+ * @WIPHY_FLAG_DFS_OFFLOAD: Device will do all DFS-related actions by itself,
+ * informing user-space about CAC progress, radar detection event,
+ * channel change triggered by radar detection event.
+ * No need to start CAC from user-space, no need to react to
+ * "radar detected" event.
* @WIPHY_FLAG_SUPPORTS_FW_ROAM: The device supports roaming feature in the
* firmware.
* @WIPHY_FLAG_AP_UAPSD: The device supports uapsd on AP.
@@ -3275,7 +3280,7 @@ enum wiphy_flags {
WIPHY_FLAG_CONTROL_PORT_PROTOCOL = BIT(7),
WIPHY_FLAG_IBSS_RSN = BIT(8),
WIPHY_FLAG_MESH_AUTH = BIT(10),
- /* use hole at 11 */
+ WIPHY_FLAG_DFS_OFFLOAD = BIT(11),
/* use hole at 12 */
WIPHY_FLAG_SUPPORTS_FW_ROAM = BIT(13),
WIPHY_FLAG_AP_UAPSD = BIT(14),
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 22cca373161d..c53281397be6 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2156,6 +2156,13 @@ enum nl80211_commands {
* @NL80211_ATTR_PMKR0_NAME: PMK-R0 Name for offloaded FT.
* @NL80211_ATTR_PORT_AUTHORIZED: (reserved)
*
+ * @NL80211_ATTR_DFS_OFFLOAD: Indicates that the HW will offload DFS actions.
+ * Device will do all DFS-related actions by itself,
+ * informing user-space about CAC progress, radar detection event,
+ * channel change triggered by radar detection event.
+ * No need to start CAC from user-space, no need to react to
+ * "radar detected" event.
+ *
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2582,6 +2589,8 @@ enum nl80211_attrs {
NL80211_ATTR_PMKR0_NAME,
NL80211_ATTR_PORT_AUTHORIZED,
+ NL80211_ATTR_DFS_OFFLOAD,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index b5e613d14d6a..635bf4143d03 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1530,6 +1530,9 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
if ((rdev->wiphy.flags & WIPHY_FLAG_TDLS_EXTERNAL_SETUP) &&
nla_put_flag(msg, NL80211_ATTR_TDLS_EXTERNAL_SETUP))
goto nla_put_failure;
+ if ((rdev->wiphy.flags & WIPHY_FLAG_DFS_OFFLOAD) &&
+ nla_put_flag(msg, NL80211_ATTR_DFS_OFFLOAD))
+ goto nla_put_failure;
state->split_start++;
if (state->split)
break;
@@ -7816,6 +7819,10 @@ static int nl80211_start_radar_detection(struct sk_buff *skb,
if (!cfg80211_chandef_dfs_usable(wdev->wiphy, &chandef))
return -EINVAL;
+ /* CAC start is offloaded to HW and can't be started manually */
+ if (wdev->wiphy->flags & WIPHY_FLAG_DFS_OFFLOAD)
+ return -EOPNOTSUPP;
+
if (!rdev->ops->start_radar_detection)
return -EOPNOTSUPP;
--
2.11.0
On 21.02.2018 14:03, Arend van Spriel wrote:
> On 2/21/2018 11:56 AM, Sergey Matyukevich wrote:
>> From: Dmitry Lebed <[email protected]>
>>
>> Add wiphy flag to indicate that HW does all DFS actions by itself.
>> User-space functionality already implemented in hostapd using
>> vendor-specific (QCA) OUI to advertise HW support.
>> Need to introduce generic flag to inform about DFS offload support.
>> For deivces with DFS_OFFLOAD flag set user-space will no longer
>> need to issue CAC or do any actions in response to
>> "radar detected" events. HW will do everything by itself and send
>> events to user-space to idicate that CAC was started/finished, etc.
>>
>> Signed-off-by: Dmitrii Lebed <[email protected]>
>> ---
>> include/net/cfg80211.h | 7 ++++++-
>> include/uapi/linux/nl80211.h | 9 +++++++++
>> net/wireless/nl80211.c | 7 +++++++
>> 3 files changed, 22 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
>> index ed3a28105d6c..b2d17993ae4d 100644
>> --- a/include/net/cfg80211.h
>> +++ b/include/net/cfg80211.h
>> @@ -3241,6 +3241,11 @@ struct cfg80211_ops {
>> * @WIPHY_FLAG_IBSS_RSN: The device supports IBSS RSN.
>> * @WIPHY_FLAG_MESH_AUTH: The device supports mesh authentication
>> by routing
>> * auth frames to userspace. See @NL80211_MESH_SETUP_USERSPACE_AUTH.
>> + * @WIPHY_FLAG_DFS_OFFLOAD: Device will do all DFS-related actions
>> by itself,
>> + * informing user-space about CAC progress, radar detection event,
>> + * channel change triggered by radar detection event.
>> + * No need to start CAC from user-space, no need to react to
>> + * "radar detected" event.
>
> wiphy flags are kinda deprecated. At least no new flags should be added.
> Instead use EXT_FEATURE flag.
>
> Regards,
> Arend
Thanks for clarification, Arend. I'll change it to use new EXT_FEATURE flag=
.
BTW, are there any concerns regarding adding generic DFS_OFFLOAD driver
capability?
I want to add DFS_OFFLOAD support to qtnfmac driver and fix hostapd to
support
generic EXT_FEATURE flag as well as vendor-specific capabilities.
Thanks,
Dmitrii
>
>> * @WIPHY_FLAG_SUPPORTS_FW_ROAM: The device supports roaming
>> feature in the
>> * firmware.
>> * @WIPHY_FLAG_AP_UAPSD: The device supports uapsd on AP.
>
This email, including its contents and any attachment(s), may contain confi=
dential information of Quantenna Communications, Inc. and is solely for the=
intended recipient(s). If you may have received this in error, please cont=
act the sender and permanently delete this email, its contents and any atta=
chment(s).
On 2/21/2018 11:56 AM, Sergey Matyukevich wrote:
> From: Dmitry Lebed <[email protected]>
>
> Add wiphy flag to indicate that HW does all DFS actions by itself.
> User-space functionality already implemented in hostapd using
> vendor-specific (QCA) OUI to advertise HW support.
> Need to introduce generic flag to inform about DFS offload support.
> For deivces with DFS_OFFLOAD flag set user-space will no longer
> need to issue CAC or do any actions in response to
> "radar detected" events. HW will do everything by itself and send
> events to user-space to idicate that CAC was started/finished, etc.
>
> Signed-off-by: Dmitrii Lebed <[email protected]>
> ---
> include/net/cfg80211.h | 7 ++++++-
> include/uapi/linux/nl80211.h | 9 +++++++++
> net/wireless/nl80211.c | 7 +++++++
> 3 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index ed3a28105d6c..b2d17993ae4d 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -3241,6 +3241,11 @@ struct cfg80211_ops {
> * @WIPHY_FLAG_IBSS_RSN: The device supports IBSS RSN.
> * @WIPHY_FLAG_MESH_AUTH: The device supports mesh authentication by routing
> * auth frames to userspace. See @NL80211_MESH_SETUP_USERSPACE_AUTH.
> + * @WIPHY_FLAG_DFS_OFFLOAD: Device will do all DFS-related actions by itself,
> + * informing user-space about CAC progress, radar detection event,
> + * channel change triggered by radar detection event.
> + * No need to start CAC from user-space, no need to react to
> + * "radar detected" event.
wiphy flags are kinda deprecated. At least no new flags should be added.
Instead use EXT_FEATURE flag.
Regards,
Arend
> * @WIPHY_FLAG_SUPPORTS_FW_ROAM: The device supports roaming feature in the
> * firmware.
> * @WIPHY_FLAG_AP_UAPSD: The device supports uapsd on AP.
Hello Kalle,
> > Friendly advice: you may want to avoid using this footer in emails on
> > the kernel.org mailing lists.
>
> Indeed. Most of the time I don't even reply to mails with such
> disclaimers and patches containing that will be automatically dropped.
Based on our previous experience we already know that sending patches from
our 'normal' emails with disclaimer is being frowned upon. So all the
patches are being sent from 'oss' emails. But so far we had impression
that participating in further discussion was allowed even from email
addresses with disclaimer.
If this is a problem, we will do the following. Patches will be posted
from 'oss' emails, and authors will participate in discussions from
their personal emails for the time being. Meanwhile we will work with
our management to get 'oss' emails for all the engineers in the team.
Regards,
Sergey
Arend van Spriel <[email protected]> writes:
> Friendly advice: you may want to avoid using this footer in emails on
> the kernel.org mailing lists.
Indeed. Most of the time I don't even reply to mails with such
disclaimers and patches containing that will be automatically dropped.
--
Kalle Valo
On 2/21/2018 12:25 PM, Dmitrii Lebed wrote:
>
> On 21.02.2018 14:03, Arend van Spriel wrote:
>> On 2/21/2018 11:56 AM, Sergey Matyukevich wrote:
>>> From: Dmitry Lebed <[email protected]>
>>>
>>> Add wiphy flag to indicate that HW does all DFS actions by itself.
>>> User-space functionality already implemented in hostapd using
>>> vendor-specific (QCA) OUI to advertise HW support.
>>> Need to introduce generic flag to inform about DFS offload support.
>>> For deivces with DFS_OFFLOAD flag set user-space will no longer
>>> need to issue CAC or do any actions in response to
>>> "radar detected" events. HW will do everything by itself and send
>>> events to user-space to idicate that CAC was started/finished, etc.
>>>
>>> Signed-off-by: Dmitrii Lebed <[email protected]>
>>> ---
>>> include/net/cfg80211.h | 7 ++++++-
>>> include/uapi/linux/nl80211.h | 9 +++++++++
>>> net/wireless/nl80211.c | 7 +++++++
>>> 3 files changed, 22 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
>>> index ed3a28105d6c..b2d17993ae4d 100644
>>> --- a/include/net/cfg80211.h
>>> +++ b/include/net/cfg80211.h
>>> @@ -3241,6 +3241,11 @@ struct cfg80211_ops {
>>> * @WIPHY_FLAG_IBSS_RSN: The device supports IBSS RSN.
>>> * @WIPHY_FLAG_MESH_AUTH: The device supports mesh authentication
>>> by routing
>>> * auth frames to userspace. See @NL80211_MESH_SETUP_USERSPACE_AUTH.
>>> + * @WIPHY_FLAG_DFS_OFFLOAD: Device will do all DFS-related actions
>>> by itself,
>>> + * informing user-space about CAC progress, radar detection event,
>>> + * channel change triggered by radar detection event.
>>> + * No need to start CAC from user-space, no need to react to
>>> + * "radar detected" event.
>>
>> wiphy flags are kinda deprecated. At least no new flags should be added.
>> Instead use EXT_FEATURE flag.
>>
>> Regards,
>> Arend
> Thanks for clarification, Arend. I'll change it to use new EXT_FEATURE
> flag.
> BTW, are there any concerns regarding adding generic DFS_OFFLOAD driver
> capability?
> I want to add DFS_OFFLOAD support to qtnfmac driver and fix hostapd to
> support
> generic EXT_FEATURE flag as well as vendor-specific capabilities.
I suppose you are referring to the qcom vendor-specific stuff for DFS
offload. I can not speak for Kalle nor Johannes, but you have my thumbs
up. I am not familiar enough with the qcom implementation to say whether
there are concerns.
> Thanks,
> Dmitrii
>>
>>> * @WIPHY_FLAG_SUPPORTS_FW_ROAM: The device supports roaming
>>> feature in the
>>> * firmware.
>>> * @WIPHY_FLAG_AP_UAPSD: The device supports uapsd on AP.
>>
>
>
> This email, including its contents and any attachment(s), may contain
> confidential information of Quantenna Communications, Inc. and is solely
> for the intended recipient(s). If you may have received this in error,
> please contact the sender and permanently delete this email, its
> contents and any attachment(s).
Friendly advice: you may want to avoid using this footer in emails on
the kernel.org mailing lists.
Regards,
Arend
Sergey Matyukevich <[email protected]> writes:
> Hello Kalle,
>
>> > Friendly advice: you may want to avoid using this footer in emails on
>> > the kernel.org mailing lists.
>>
>> Indeed. Most of the time I don't even reply to mails with such
>> disclaimers and patches containing that will be automatically dropped.
>
> Based on our previous experience we already know that sending patches from
> our 'normal' emails with disclaimer is being frowned upon. So all the
> patches are being sent from 'oss' emails. But so far we had impression
> that participating in further discussion was allowed even from email
> addresses with disclaimer.
I think it's just rude to send emails to public with such disclaimers,
this is a public list where people voluntarily use their time to reply
to emails. I guess some people don't mind but there are people who do
not like it, myself included.
--
Kalle Valo