From: Zefir Kurtisi <zefir.kurtisi@neratec.com>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] [PATCH] ath9k: Prevent radar detection and spectral scan to be used concurrently
Date: Mon, 21 Nov 2016 17:16:42 +0100 [thread overview]
Message-ID: <d2611789-09d7-0382-b100-46ef0a94ea41@neratec.com> (raw)
In-Reply-To: <CA+BoTQm5do0pfMpQ=ua=Q3Uomd2jV6_xbRFK=BMzUi-D5z7C+A@mail.gmail.com>
On 11/21/2016 04:10 PM, Michal Kazior wrote:
> On 21 November 2016 at 15:41, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
>> On 11/21/2016 03:04 PM, Benjamin Berg wrote:
>>> In the case that a spectral scan is enabled the PHY errors sent by the
>>> hardware as part of the scanning might trigger the radar detection and
>>> channels might be marked as 'unusable' incorrectly. This patch fixes
>>> the issue by preventing the spectral scan to be enabled if DFS is used
>>> and only analysing the PHY errors for DFS if radar detection is enabled.
>>>
>>> [...]
>>
>> From the relevant source code portion in channel.c:ath_set_channel()
>>
>> 80 /* Enable radar pulse detection if on a DFS channel. Spectral
>> 81 * scanning and radar detection can not be used concurrently.
>> 82 */
>> 83 if (hw->conf.radar_enabled) {
>> 84 u32 rxfilter;
>> 85
>> 86 rxfilter = ath9k_hw_getrxfilter(ah);
>> 87 rxfilter |= ATH9K_RX_FILTER_PHYRADAR |
>> 88 ATH9K_RX_FILTER_PHYERR;
>> 89 ath9k_hw_setrxfilter(ah, rxfilter);
>> 90 ath_dbg(common, DFS, "DFS enabled at freq %d\n",
>> 91 chan->center_freq);
>> 92 } else {
>> 93 /* perform spectral scan if requested. */
>> 94 if (test_bit(ATH_OP_SCANNING, &common->op_flags) &&
>> 95 sc->spec_priv.spectral_mode == SPECTRAL_CHANSCAN)
>> 96 ath9k_cmn_spectral_scan_trigger(common, &sc->spec_priv);
>> 97 }
>>
>> it seems that spectral can't ever be activated while operating on a DFS channel.
>>
>> If you need to catch the opposite case, i.e. prevent feeding pseudo-radar pulses
>> into the pattern detector, you just need to ensure that they depend on
>> hw->conf.radar_enabled. A patch like the attached one should be enough.
>
> Good point. I guess set_channel could be oversimplified as well. I
> mean, it makes sense to consider radar and spectral mutually exclusive
> if they use the same phyerr code. However some chips actually seem (as
> per the comment I mentioned) to distinguish the two so I don't know if
> the "mutually exclusive" is true for all chips per se. Just thinking
> out loud.
>
You're right, blindly feeding PHYERR frames to spectral when spectral is not
enabled is as wrong as feeding them to the dfs-detector when not on a radar
channel. Therefore, the patch I proposed should be extended to make calling
ath_cmn_process_fft() depending on
a) not operating on radar channel, and
b) spectral scan is enabled
Updated patch attached as proposal.
> I also wonder if calling ieee80211_radar_detect() should have any
> effect if there are no radar operated interfaces in the first place?
>
True, calling ieee80211_radar_detect() for a non-DFS channel is (or should be)
ignored by mac. But feeding the dfs-detector with invalid pulses causes quite some
computational overhead - dropping them if no radar detection is required is a good
thing to do.
Cheers,
Zefir
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ath9k-feed-DFS-detector-only-if-operating-on-radar-c.patch
Type: text/x-patch
Size: 0 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20161121/ab36ab4e/attachment-0001.bin
prev parent reply other threads:[~2016-11-21 16:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-21 14:04 [ath9k-devel] [PATCH] ath9k: Prevent radar detection and spectral scan to be used concurrently Benjamin Berg
2016-11-21 14:16 ` Michal Kazior
2016-11-21 14:41 ` Zefir Kurtisi
2016-11-21 15:10 ` Michal Kazior
2016-11-21 16:16 ` Zefir Kurtisi [this message]
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=d2611789-09d7-0382-b100-46ef0a94ea41@neratec.com \
--to=zefir.kurtisi@neratec.com \
--cc=ath9k-devel@lists.ath9k.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).