All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: Peter Oh <peter.oh@bowerswilkins.com>
Cc: linux-wireless@vger.kernel.org,
	Sriram R <srirrama@codeaurora.org>,
	ath10k@lists.infradead.org
Subject: Re: [PATCH 2/2] ath10k: DFS Host Confirmation
Date: Wed, 02 May 2018 14:27:42 +0300	[thread overview]
Message-ID: <87d0ye2t75.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <0c224b54-dd10-576f-944f-2d20d1cb2c46@bowerswilkins.com> (Peter Oh's message of "Mon, 30 Apr 2018 12:50:40 -0700")

Peter Oh <peter.oh@bowerswilkins.com> writes:

> On 04/30/2018 10:45 AM, Sriram R wrote:
>> In the 10.4-3.6 firmware branch there's a new DFS Host confirmation
>> feature which is advertised using WMI_SERVICE_HOST_DFS_CHECK_SUPPORT flag.
>>
>> This new features enables the ath10k host to send information to the
>> firmware on the specifications of detected radar type. This allows the
>> firmware to validate if the host's radar pattern detector unit is
>> operational and check if the radar information shared by host matches
>> the radar pulses sent as phy error events from firmware. If the check
>> fails the firmware won't allow use of DFS channels on AP mode when using
>> FCC regulatory region.
>
> What's the main reason you introduce this feature?
> What are you trying to solve with this change?

Otherwise one cannot use DFS channels on FCC regions with a firmware
from 10.4-3.6 branch.

>> @@ -3765,25 +3834,46 @@ static void ath10k_dfs_radar_report(struct ath10k *ar,
>>     	ATH10K_DFS_STAT_INC(ar, pulses_detected);
>>   -	if (!ar->dfs_detector->add_pulse(ar->dfs_detector, &pe, NULL))
>> {
>> +	if (!ar->dfs_detector->add_pulse(ar->dfs_detector, &pe, &rs)) {
>>   		ath10k_dbg(ar, ATH10K_DBG_REGULATORY,
>>   			   "dfs no pulse pattern detected, yet\n");
>>   		return;
>>   	}
>>   -radar_detected:
>> -	ath10k_dbg(ar, ATH10K_DBG_REGULATORY, "dfs radar detected\n");
>> -	ATH10K_DFS_STAT_INC(ar, radar_detected);
>> +	if ((test_bit(WMI_SERVICE_HOST_DFS_CHECK_SUPPORT, ar->wmi.svc_map)) &&
>> +	    ar->dfs_detector->region == NL80211_DFS_FCC) {
>
> I feel risky that host drivers have no way to control this new feature
> and totally rely on FW feature mask. We should have a host drivers'
> feature mask such as module param and set it false (don't use) by
> default until it proves safe to use.

This is for regulatory enforcement so it's not possible to disable the
feature from host.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@codeaurora.org>
To: Peter Oh <peter.oh@bowerswilkins.com>
Cc: Sriram R <srirrama@codeaurora.org>,
	ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCH 2/2] ath10k: DFS Host Confirmation
Date: Wed, 02 May 2018 14:27:42 +0300	[thread overview]
Message-ID: <87d0ye2t75.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <0c224b54-dd10-576f-944f-2d20d1cb2c46@bowerswilkins.com> (Peter Oh's message of "Mon, 30 Apr 2018 12:50:40 -0700")

Peter Oh <peter.oh@bowerswilkins.com> writes:

> On 04/30/2018 10:45 AM, Sriram R wrote:
>> In the 10.4-3.6 firmware branch there's a new DFS Host confirmation
>> feature which is advertised using WMI_SERVICE_HOST_DFS_CHECK_SUPPORT flag.
>>
>> This new features enables the ath10k host to send information to the
>> firmware on the specifications of detected radar type. This allows the
>> firmware to validate if the host's radar pattern detector unit is
>> operational and check if the radar information shared by host matches
>> the radar pulses sent as phy error events from firmware. If the check
>> fails the firmware won't allow use of DFS channels on AP mode when using
>> FCC regulatory region.
>
> What's the main reason you introduce this feature?
> What are you trying to solve with this change?

Otherwise one cannot use DFS channels on FCC regions with a firmware
from 10.4-3.6 branch.

>> @@ -3765,25 +3834,46 @@ static void ath10k_dfs_radar_report(struct ath10k *ar,
>>     	ATH10K_DFS_STAT_INC(ar, pulses_detected);
>>   -	if (!ar->dfs_detector->add_pulse(ar->dfs_detector, &pe, NULL))
>> {
>> +	if (!ar->dfs_detector->add_pulse(ar->dfs_detector, &pe, &rs)) {
>>   		ath10k_dbg(ar, ATH10K_DBG_REGULATORY,
>>   			   "dfs no pulse pattern detected, yet\n");
>>   		return;
>>   	}
>>   -radar_detected:
>> -	ath10k_dbg(ar, ATH10K_DBG_REGULATORY, "dfs radar detected\n");
>> -	ATH10K_DFS_STAT_INC(ar, radar_detected);
>> +	if ((test_bit(WMI_SERVICE_HOST_DFS_CHECK_SUPPORT, ar->wmi.svc_map)) &&
>> +	    ar->dfs_detector->region == NL80211_DFS_FCC) {
>
> I feel risky that host drivers have no way to control this new feature
> and totally rely on FW feature mask. We should have a host drivers'
> feature mask such as module param and set it false (don't use) by
> default until it proves safe to use.

This is for regulatory enforcement so it's not possible to disable the
feature from host.

-- 
Kalle Valo

  reply	other threads:[~2018-05-02 11:27 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-30 17:45 [PATCH 0/2] ath/ath10k: DFS Host Confirmation Sriram R
2018-04-30 17:45 ` Sriram R
2018-04-30 17:45 ` [PATCH 1/2] ath: Add support to get the detected radar specifications Sriram R
2018-04-30 17:45   ` Sriram R
2018-04-30 19:01   ` Peter Oh
2018-04-30 19:01     ` Peter Oh
2018-05-14 14:51     ` Kalle Valo
2018-05-14 14:51       ` Kalle Valo
2018-04-30 17:45 ` [PATCH 2/2] ath10k: DFS Host Confirmation Sriram R
2018-04-30 17:45   ` Sriram R
2018-04-30 19:50   ` Peter Oh
2018-04-30 19:50     ` Peter Oh
2018-05-02 11:27     ` Kalle Valo [this message]
2018-05-02 11:27       ` Kalle Valo
2018-05-03  6:25       ` Peter Oh
2018-05-03  6:25         ` Peter Oh
2018-05-14 18:10         ` Kalle Valo
2018-05-14 18:10           ` Kalle Valo
2018-05-14 20:55           ` Peter Oh
2018-05-14 20:55             ` Peter Oh
2018-05-05  9:45       ` Sebastian Gottschall
2018-05-05  9:45         ` Sebastian Gottschall
2018-05-09 10:45     ` Sriram R
2018-05-09 10:45       ` Sriram R
2018-05-03 23:48   ` Adrian Chadd
2018-05-03 23:48     ` Adrian Chadd
2018-05-14 18:25     ` Kalle Valo
2018-05-14 18:25       ` Kalle Valo
2018-05-14 21:13       ` Adrian Chadd
2018-05-14 21:13         ` Adrian Chadd
2018-05-15  5:04         ` Kalle Valo
2018-05-15  5:04           ` Kalle Valo
2018-05-15 18:59           ` Peter Oh
2018-05-15 18:59             ` Peter Oh
2018-05-16 10:09             ` Kalle Valo
2018-05-16 10:09               ` Kalle Valo
2018-05-12  9:57   ` Kalle Valo
2018-05-12  9:57     ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d0ye2t75.fsf@kamboji.qca.qualcomm.com \
    --to=kvalo@codeaurora.org \
    --cc=ath10k@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=peter.oh@bowerswilkins.com \
    --cc=srirrama@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.