From patchwork Tue Jan 13 10:16:02 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zefir Kurtisi X-Patchwork-Id: 5618991 Return-Path: X-Original-To: patchwork-linux-wireless@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 04ABC9F2ED for ; Tue, 13 Jan 2015 10:16:17 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 3C99020605 for ; Tue, 13 Jan 2015 10:16:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AF856205F7 for ; Tue, 13 Jan 2015 10:16:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751712AbbAMKQJ (ORCPT ); Tue, 13 Jan 2015 05:16:09 -0500 Received: from mail.neratec.com ([46.140.151.2]:43143 "EHLO mail.neratec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751630AbbAMKQF (ORCPT ); Tue, 13 Jan 2015 05:16:05 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.neratec.com (Postfix) with ESMTP id 6766EA02717; Tue, 13 Jan 2015 11:16:03 +0100 (CET) Received: from mail.neratec.com ([127.0.0.1]) by localhost (mail.neratec.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id mrGgGRlb23GF; Tue, 13 Jan 2015 11:16:02 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.neratec.com (Postfix) with ESMTP id E302CA0271C; Tue, 13 Jan 2015 11:16:02 +0100 (CET) X-Virus-Scanned: amavisd-new at neratec.com Received: from mail.neratec.com ([127.0.0.1]) by localhost (mail.neratec.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id x7Fa7C7tUdnR; Tue, 13 Jan 2015 11:16:02 +0100 (CET) Received: from [192.168.11.73] (CHB0038.neratec.local [192.168.11.73]) by mail.neratec.com (Postfix) with ESMTPSA id BF4D8A02717; Tue, 13 Jan 2015 11:16:02 +0100 (CET) Message-ID: <54B4F062.2090301@neratec.com> Date: Tue, 13 Jan 2015 11:16:02 +0100 From: Zefir Kurtisi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Simon Wunderlich , Arend van Spriel 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: [PATCH] ath9k: ignore radar PHY errors when DFS is not enabled References: <1420822458-531-1-git-send-email-sw@simonwunderlich.de> <54B024A1.4040809@broadcom.com> <2179820.H2CYa3nAla@prime> In-Reply-To: <2179820.H2CYa3nAla@prime> Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, T_TVD_MIME_EPI, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 01/10/2015 05:26 PM, Simon Wunderlich wrote: > 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 > Hi, the issue here is that DFS and spectral use the same PHY_ERROR reporting mechanism, and the dfs module is still in its initial state prior the spectral support was added. With that, feeding the dfs detector with PHY_ERROR frames generated by spectral scanner might cause false radar detections. 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. 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). Cheers, Zefir From 089ab0d624d4b6f3a206ea8a81b4a3e061cf3edb Mon Sep 17 00:00:00 2001 From: Zefir Kurtisi Date: Thu, 30 Jan 2014 13:33:50 +0100 Subject: [PATCH] ath9k: do not enable radar pulse detection in STA mode --- drivers/net/wireless/ath/ath9k/recv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/wireless/ath/ath9k/recv.c +++ b/drivers/net/wireless/ath/ath9k/recv.c @@ -384,7 +384,7 @@ u32 ath_calcrxfilter(struct ath_softc *s | ATH9K_RX_FILTER_MCAST; /* if operating on a DFS channel, enable radar pulse detection */ - if (sc->hw->conf.radar_enabled) + if (sc->hw->conf.radar_enabled && sc->sc_ah->opmode != NL80211_IFTYPE_STATION) rfilt |= ATH9K_RX_FILTER_PHYRADAR | ATH9K_RX_FILTER_PHYERR; spin_lock_bh(&sc->chan_lock);