Re: [PATCH wireless-next v3 06/15] wifi: cfg80211: add proximity detection capabilities to PMSR

[Peddolla Harshavardhan Reddy <peddolla.reddy@oss.qualcomm.com>]

On 13-Mar-26 2:38 AM, Stern, Avraham wrote:
>
>> From: Peddolla Harshavardhan Reddy <peddolla.reddy@oss.qualcomm.com> 
>> Sent: Thursday, March 5, 2026 6:07 PM
>> To: johannes@sipsolutions.net
>> Cc: linux-wireless@vger.kernel.org; kavita.kavita@oss.qualcomm.com
>> Subject: [PATCH wireless-next v3 06/15] wifi: cfg80211: add proximity detection capabilities to PMSR
>> + * @pd_support: supports peer-to-peer ranging as mentioned in the specification
>> + *	"PR Implementation Consideration Draft 1.9 rev 1" where PD stands for
>> + *	proximity detection
>> + * @pd_concurrent_ista_rsta_support: As the peer measurement request can be a
>> + *	multi-peer request this will indicate if the device can act
>> + *	simultaneously as initiator and a responder. Only valid if @pd_support
>> + *	is set.
>> * @ftm: FTM measurement data
> These should be part of the FTM data.
> pd_concurrent_ista_rsta_support is only valid if ftm.support_rsta is set.


Fixed it in the next version.

>
>> + * @ftm.max_no_of_tx_antennas: maximum number of transmit antennas supported for
>> + *	ranging
>> + * @ftm.max_no_of_rx_antennas: maximum number of receive antennas supported for
>> + *	ranging
> Supported for EDCA based ranging

Fixed it in the next version.


>
>> + * @ftm.min_allowed_ranging_interval_edca: Minimum EDCA ranging
>> + *	interval supported by the device in milli seconds. (0 means unknown)
>> + * @ftm.min_allowed_ranging_interval_ntb: Minimum NTB ranging
>> + *	interval supported by the device in milli seconds. (0 means unknown)
> These are not advertised anywhere, and time between measurements is not part of the measurement request from the user.
> So why this capability is needed?


User space can use this to calculate Nominal time or burst period as needed based on how quickly can the driver/ Firmware can do the ranging.

>
>>  * @ftm.support_rsta: supports operating as RSTA in PMSR FTM request
>> + * @ftm.support_edca_responder: supports operating as FTM responder in PMSR FTM
>> + *	request for EDCA-based ranging
> So support rsta means supports RSTA for NTB only now? Do we also need support TB RSTA?


Updated in the next version.

>  
> 	struct {
>  		u32 preambles;
>> +		u32 max_no_of_tx_antennas;
>> +		u32 max_no_of_rx_antennas;
> u8 should be enough

Updated in the next version.


>
>   * @NUM_NL80211_PMSR_ATTR: internal
>>   * @NL80211_PMSR_ATTR_MAX: highest attribute number @@ -7841,6 +7850,8 @@ enum nl80211_peer_measurement_attrs {
>> 	NL80211_PMSR_ATTR_RANDOMIZE_MAC_ADDR,
>>  	NL80211_PMSR_ATTR_TYPE_CAPA,
>>  	NL80211_PMSR_ATTR_PEERS,
>> +	NL80211_PMSR_ATTR_PD_SUPPORT,
>> +	NL80211_PMSR_ATTR_PD_CONCURRENT_ISTA_RSTA_SUPPORT,
>  
> These should be under nl80211_peer_measurement_ftm_capa


Updated in the next version.


>
>> -	if (out->ftm.rsta && !capa->ftm.support_rsta) {
>> +	if (out->ftm.rsta && !capa->ftm.support_rsta &&
>> +	    !capa->ftm.support_edca_responder) {
>>  		NL_SET_ERR_MSG_ATTR(info->extack,
>>  				    tb[NL80211_PMSR_FTM_REQ_ATTR_RSTA],
>> 				    "FTM: RSTA not supported by device");
> capa->ftm.support_edca_responder is only needed if out->ftm.non_trigger_based is not set


removed support_edca_responder and added separate ISTA and RSTA based capabilities for TB, NTB, EDCA, and added new validation checks in PMSR request path for all three.

>
> ---------------------------------------------------------------------
> A member of the Intel Corporation group of companies
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>