From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from nbd.name ([46.4.11.11]:39832 "EHLO nbd.name" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1033423AbeBOOpv (ORCPT ); Thu, 15 Feb 2018 09:45:51 -0500 Subject: Re: [PATCH v2] ath9k: mark RSSI as invalid if frame received during channel setup To: Jean Pierre TOSONI , Kalle Valo Cc: "linux-wireless@vger.kernel.org" , "ath9k-devel@qca.qualcomm.com" References: From: Felix Fietkau Message-ID: (sfid-20180215_154554_921414_ADA70E81) Date: Thu, 15 Feb 2018 15:45:48 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 2018-02-14 17:26, Jean Pierre TOSONI wrote: > ath9k returns a wrong RSSI value for frames received in a 30ms time > window after a channel change. The correct value is typically 10dB > below the returned value. > > This was found with a Atheros AR9300 Rev:3 chip (WLE350NX / JWX6083 > cards), during offchannel scans. > > Mark the signal value as invalid in this case. > > Signed-off-by: Jean Pierre TOSONI It seems that this will potentially cause a lot of scan results with RSSI information missing, which I think may be worse than a 10 db fluctuation. Actually, it could also be that the hardware is reporting accurate RSSI values (they're reported as SNR relative to the noise floor) and this is just a blip caused by the fact that the hw is updating its internal noise floor value based on running measurements. Does the same fluctuation also happen if you set update = false for calls to ath9k_hw_start_nfcal? - Felix