From: Simon Wunderlich <sw@simonwunderlich.de>
To: Arend van Spriel <arend@broadcom.com>
Cc: 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: Re: [PATCH] ath9k: ignore radar PHY errors when DFS is not enabled
Date: Sat, 10 Jan 2015 17:26:26 +0100 [thread overview]
Message-ID: <2179820.H2CYa3nAla@prime> (raw)
In-Reply-To: <54B024A1.4040809@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]
On Friday 09 January 2015 19:57:37 Arend van Spriel wrote:
> On 01/09/15 17:54, Simon Wunderlich wrote:
> > Performing spectral scans on 5 GHz channels may result in PHY errors
> > sent by the hardware, even if DFS support is not enabled in the driver
> > (e.g. channel scanning or passive monitoring). In that case channels may
> > falsely get marked as 'unusable'. To fix that, only process radar PHY
> > errors when radar is explicitly enabled in the driver.
>
> Hi Simon,
>
> Not an ath9k expert, but I would think those channels would already be
> marked as unusable, because DFS is disabled in the driver. Or does this
> also affect 5G channels that do not require DFS.
>
> Regards,
> Arend
Hey Arend,
maybe that was not really clear, but this is talking about the DFS state
"unusable". By default, channels are marked in DFS state "usable", and after
the clear channel assessment (which is done e.g. when starting AP mode) they
are marked as "available". As soon as radar is detected they are marked as
"unusable".
These DFS state changes should only happen while there is something operating
with radar enabled, e.g. AP mode. It should not happen if we just have monitor
mode or scan for channels. These channels should then stay in their previous
DFS state (e.g. 'usable'). This was borked and this patch tries to fix it. :)
Cheers,
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2015-01-10 16:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-09 16:54 [PATCH] ath9k: ignore radar PHY errors when DFS is not enabled Simon Wunderlich
2015-01-09 18:57 ` Arend van Spriel
2015-01-10 16:26 ` Simon Wunderlich [this message]
2015-01-13 10:16 ` Zefir Kurtisi
2015-01-13 11:04 ` Simon Wunderlich
2015-01-13 12:08 ` Zefir Kurtisi
2015-01-15 14:30 ` Kalle Valo
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=2179820.H2CYa3nAla@prime \
--to=sw@simonwunderlich.de \
--cc=arend@broadcom.com \
--cc=ath9k-devel@lists.ath9k.org \
--cc=kvalo@qca.qualcomm.com \
--cc=linux-wireless@vger.kernel.org \
--cc=mathias.kretschmer@fokus.fraunhofer.de \
--cc=stable@vger.kernel.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 NNTP newsgroup(s).