All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zefir Kurtisi <zefir.kurtisi@neratec.com>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] [PATCH] ath9k: ignore radar PHY errors when DFS is not enabled
Date: Tue, 13 Jan 2015 13:08:01 +0100	[thread overview]
Message-ID: <54B50AA1.3040402@neratec.com> (raw)
In-Reply-To: <3155015.RnApTRDnnO@prime>

On 01/13/2015 12:04 PM, Simon Wunderlich wrote:
> On Tuesday 13 January 2015 11:16:02 Zefir Kurtisi wrote:
>> [...]
>>
>> I did not dig how the hw->conf.radar_enabled flag is set in monitor mode,
>> but if it is same as for master (i.e. set for DFS channels), then it would
>> be a better approach to prevent calling ath9k_dfs_process_phyerr()
>> altogether from ath9k_rx_skb_preprocess() if not set.
> 
> Hm, you mean like - if radar_enabled then dfs_process, otherwise fft_process? 
> That would might be more elegant indeed ...
> 
More concrete / restrictive:
* if radar_enabled
 - spectral must not be enabled
 - only ath9k_dfs_process_phyerr() has to be processed
* if !radar_enabled
 - don't process ath9k_dfs_process_phyerr()

> The monitor mode does not have the radar flag enabled, 
> cfg80211_chandef_dfs_required() returns 0 in this case.
> 
Ah, which then means you can not do (supplemental) CACs with a monitor
out-of-the-box? For that, radar_enabled would need to be set for monitor, which
basically should not harm for a fully passive interface.

>>
>> And while you're at that: slaves do not need to scan for radar, might be
>> worth checking if it makes sense to selectively disable radar detection in
>> STA mode. I am using attached private OpenWRT patch for that - which still
>> would interfere with spectral scanning. Generally, the PHY_ERROR processing
>> should be reworked but becomes quite complicated when you take into account
>> special use-cases. Think of radar events being treated differently
>> depending on whether a master or a monitor detected them (OC-CAC vs. ISM).
> 
> I didn't check if that is enforced correctly, but 
> cfg80211_chandef_dfs_required() returns if radar is required for the various 
> interface types - AP, Adhoc and Mesh have it enabled if its a DFS channel, 
> client, monitor, etc don't have it enabled. That gets marked in the sdata-
>> radar_required, and ieee80211_is_radar_required() checks all interfaces if 
> there is any interface which needs radar. So that should have been taken care 
> of.
> 
> Therefore I think that this is already handled in cfg80211/mac80211 and ath9k 
> should not check the iftype at all, but only check the radar_enabled flag.
> 
Ok, thanks for clarifying that - one private patch less to handle :)

WARNING: multiple messages have this Message-ID (diff)
From: Zefir Kurtisi <zefir.kurtisi@neratec.com>
To: Simon Wunderlich <sw@simonwunderlich.de>
Cc: Arend van Spriel <arend@broadcom.com>,
	linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org,
	kvalo@qca.qualcomm.com, mathias.kretschmer@fokus.fraunhofer.de,
	stable@vger.kernel.org
Subject: Re: [PATCH] ath9k: ignore radar PHY errors when DFS is not enabled
Date: Tue, 13 Jan 2015 13:08:01 +0100	[thread overview]
Message-ID: <54B50AA1.3040402@neratec.com> (raw)
In-Reply-To: <3155015.RnApTRDnnO@prime>

On 01/13/2015 12:04 PM, Simon Wunderlich wrote:
> On Tuesday 13 January 2015 11:16:02 Zefir Kurtisi wrote:
>> [...]
>>
>> I did not dig how the hw->conf.radar_enabled flag is set in monitor mode,
>> but if it is same as for master (i.e. set for DFS channels), then it would
>> be a better approach to prevent calling ath9k_dfs_process_phyerr()
>> altogether from ath9k_rx_skb_preprocess() if not set.
> 
> Hm, you mean like - if radar_enabled then dfs_process, otherwise fft_process? 
> That would might be more elegant indeed ...
> 
More concrete / restrictive:
* if radar_enabled
 - spectral must not be enabled
 - only ath9k_dfs_process_phyerr() has to be processed
* if !radar_enabled
 - don't process ath9k_dfs_process_phyerr()

> The monitor mode does not have the radar flag enabled, 
> cfg80211_chandef_dfs_required() returns 0 in this case.
> 
Ah, which then means you can not do (supplemental) CACs with a monitor
out-of-the-box? For that, radar_enabled would need to be set for monitor, which
basically should not harm for a fully passive interface.

>>
>> And while you're at that: slaves do not need to scan for radar, might be
>> worth checking if it makes sense to selectively disable radar detection in
>> STA mode. I am using attached private OpenWRT patch for that - which still
>> would interfere with spectral scanning. Generally, the PHY_ERROR processing
>> should be reworked but becomes quite complicated when you take into account
>> special use-cases. Think of radar events being treated differently
>> depending on whether a master or a monitor detected them (OC-CAC vs. ISM).
> 
> I didn't check if that is enforced correctly, but 
> cfg80211_chandef_dfs_required() returns if radar is required for the various 
> interface types - AP, Adhoc and Mesh have it enabled if its a DFS channel, 
> client, monitor, etc don't have it enabled. That gets marked in the sdata-
>> radar_required, and ieee80211_is_radar_required() checks all interfaces if 
> there is any interface which needs radar. So that should have been taken care 
> of.
> 
> Therefore I think that this is already handled in cfg80211/mac80211 and ath9k 
> should not check the iftype at all, but only check the radar_enabled flag.
> 
Ok, thanks for clarifying that - one private patch less to handle :)



  reply	other threads:[~2015-01-13 12:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-09 16:54 [ath9k-devel] [PATCH] ath9k: ignore radar PHY errors when DFS is not enabled Simon Wunderlich
2015-01-09 16:54 ` Simon Wunderlich
2015-01-09 18:57 ` [ath9k-devel] " Arend van Spriel
2015-01-09 18:57   ` Arend van Spriel
2015-01-10 16:26   ` [ath9k-devel] " Simon Wunderlich
2015-01-10 16:26     ` Simon Wunderlich
2015-01-13 10:16     ` [ath9k-devel] " Zefir Kurtisi
2015-01-13 10:16       ` Zefir Kurtisi
2015-01-13 11:04       ` [ath9k-devel] " Simon Wunderlich
2015-01-13 11:04         ` Simon Wunderlich
2015-01-13 12:08         ` Zefir Kurtisi [this message]
2015-01-13 12:08           ` Zefir Kurtisi
2015-01-15 14:30         ` [ath9k-devel] " Kalle Valo
2015-01-15 14:30           ` Kalle Valo
2015-01-15 15:58           ` [ath9k-devel] " Simon Wunderlich
2015-01-15 15:58             ` Simon Wunderlich

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=54B50AA1.3040402@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 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.