mbox series

[v3,0/3] support ftm responder configuration/statistics

Message ID 1536195700-1351-1-git-send-email-pradeepc@codeaurora.org (mailing list archive)
Headers show
Series support ftm responder configuration/statistics | expand

Message

Pradeep Kumar Chitrapu Sept. 6, 2018, 1:01 a.m. UTC
Currently ftm_responder parameter in hostapd.conf is only used for fine
timing measurement (FTM) capability advertisement and actual control of
the functionality is with low-level device/driver. This leads to confusion
to the user when the capability advertisement is different from actual FTM
responder functionality.

For example, FTM responder capability advertisement is set to 'enabled',
but the functionality is disabled or not supported by the driver.

The patch set allows userspace to enable FTM responder functionality
with the addition of new Netlink flag attribute NL80211_ATTR_FTM_RESPONDER
with configurable lci/civic ocation parameters. Also extended feature flag
is added for the drivers to advertise the support. Setting the flag to
enable FTM responder would imply that AP responds to all FTM requests.
Default is considered to be disabled.

changes in V3:
 - fixed the ambiguous ftm responder disable case to be not supported

changes in V2:
- updated version number
- rebased patches

Johannes Berg, Pradeep Kumar Chitrapu (1):
  cfg80211: support FTM responder configuration/statistics

David Spinadel, Johannes Berg, Pradeep Kumar Chitrapu (1):
  mac80211: support FTM responder configuration/statistics

Pradeep Kumar Chitrapu (1):
  ath10k: Add support to configure ftm responder role

 drivers/net/wireless/ath/ath10k/core.h |   1 +
 drivers/net/wireless/ath/ath10k/mac.c  |  29 ++++++++
 drivers/net/wireless/ath/ath10k/wmi.c  |   4 ++
 drivers/net/wireless/ath/ath10k/wmi.h  |  10 +++
 include/net/cfg80211.h                 |  66 ++++++++++++++++++
 include/net/mac80211.h                 |  13 ++++
 include/uapi/linux/nl80211.h           |  81 +++++++++++++++++++++
 net/mac80211/cfg.c                     |  84 ++++++++++++++++++++++
 net/mac80211/driver-ops.h              |  16 +++++
 net/mac80211/trace.h                   |  23 ++++++
 net/mac80211/util.c                    |   3 +
 net/wireless/nl80211.c                 | 124 +++++++++++++++++++++++++++++++--
 net/wireless/rdev-ops.h                |  15 ++++
 net/wireless/trace.h                   |  44 ++++++++++++
 14 files changed, 508 insertions(+), 5 deletions(-)

Comments

Johannes Berg Sept. 6, 2018, 6:34 a.m. UTC | #1
On Wed, 2018-09-05 at 18:01 -0700, Pradeep Kumar Chitrapu wrote:
> Currently ftm_responder parameter in hostapd.conf is only used for fine
> timing measurement (FTM) capability advertisement and actual control of
> the functionality is with low-level device/driver. This leads to confusion
> to the user when the capability advertisement is different from actual FTM
> responder functionality.
> 
> For example, FTM responder capability advertisement is set to 'enabled',
> but the functionality is disabled or not supported by the driver.
> 
> The patch set allows userspace to enable FTM responder functionality
> with the addition of new Netlink flag attribute NL80211_ATTR_FTM_RESPONDER
> with configurable lci/civic ocation parameters. Also extended feature flag
> is added for the drivers to advertise the support. Setting the flag to
> enable FTM responder would imply that AP responds to all FTM requests.
> Default is considered to be disabled.
> 
> changes in V3:
>  - fixed the ambiguous ftm responder disable case to be not supported

For reasons unknown to me, this patchset made it neither to the list
nor, consequently, patchwork. Please resend.

johannes
Kalle Valo Sept. 6, 2018, 3:15 p.m. UTC | #2
Johannes Berg <johannes@sipsolutions.net> writes:

> On Wed, 2018-09-05 at 18:01 -0700, Pradeep Kumar Chitrapu wrote:
>> Currently ftm_responder parameter in hostapd.conf is only used for fine
>> timing measurement (FTM) capability advertisement and actual control of
>> the functionality is with low-level device/driver. This leads to confusion
>> to the user when the capability advertisement is different from actual FTM
>> responder functionality.
>> 
>> For example, FTM responder capability advertisement is set to 'enabled',
>> but the functionality is disabled or not supported by the driver.
>> 
>> The patch set allows userspace to enable FTM responder functionality
>> with the addition of new Netlink flag attribute NL80211_ATTR_FTM_RESPONDER
>> with configurable lci/civic ocation parameters. Also extended feature flag
>> is added for the drivers to advertise the support. Setting the flag to
>> enable FTM responder would imply that AP responds to all FTM requests.
>> Default is considered to be disabled.
>> 
>> changes in V3:
>>  - fixed the ambiguous ftm responder disable case to be not supported
>
> For reasons unknown to me, this patchset made it neither to the list
> nor, consequently, patchwork. Please resend.

Actually patch 3 made it:

https://patchwork.kernel.org/patch/10590115/

But it didn't get the rest as it says "Untitled series #15763".
Patchwork was timing out for me quite heavily so in that way I'm not
surprised that patches are getting lost :(
Johannes Berg Sept. 6, 2018, 4:08 p.m. UTC | #3
On Thu, 2018-09-06 at 18:15 +0300, Kalle Valo wrote:
> 
> Actually patch 3 made it:
> 
> https://patchwork.kernel.org/patch/10590115/
> 
> But it didn't get the rest as it says "Untitled series #15763".
> Patchwork was timing out for me quite heavily so in that way I'm not
> surprised that patches are getting lost :(

No, it's not patchwork - I didn't get the patches (except for #3) via
the list either.

johannes
Kalle Valo Sept. 6, 2018, 4:18 p.m. UTC | #4
Johannes Berg <johannes@sipsolutions.net> writes:

> On Thu, 2018-09-06 at 18:15 +0300, Kalle Valo wrote:
>> 
>> Actually patch 3 made it:
>> 
>> https://patchwork.kernel.org/patch/10590115/
>> 
>> But it didn't get the rest as it says "Untitled series #15763".
>> Patchwork was timing out for me quite heavily so in that way I'm not
>> surprised that patches are getting lost :(
>
> No, it's not patchwork - I didn't get the patches (except for #3) via
> the list either.

Ah, missed that as the ath10k list did get all the patches. But very
good that patchwork was not to blame here.