From patchwork Fri Jun 9 11:07:48 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sven Eckelmann X-Patchwork-Id: 9778079 X-Patchwork-Delegate: kvalo@adurom.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 5A66E6034B for ; Fri, 9 Jun 2017 11:08:03 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4CB4F285FB for ; Fri, 9 Jun 2017 11:08:03 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4152028609; Fri, 9 Jun 2017 11:08:03 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 96C28285FB for ; Fri, 9 Jun 2017 11:08:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751535AbdFILIA (ORCPT ); Fri, 9 Jun 2017 07:08:00 -0400 Received: from mail-wr0-f175.google.com ([209.85.128.175]:34224 "EHLO mail-wr0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751524AbdFILIA (ORCPT ); Fri, 9 Jun 2017 07:08:00 -0400 Received: by mail-wr0-f175.google.com with SMTP id g76so29064852wrd.1 for ; Fri, 09 Jun 2017 04:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openmesh-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=esf31fNCe4wbGidYc1qvg9Z2RPCcFg6ooHfJQK2k2ek=; b=OI5GGv8RQUE7g+iVjxoi4LeW9/LQhpVadcY7HXaKHDoO+11sN3crXuXoaD7gFa5NO/ uslKawzc3g9DTT9PrxqCDsRBny5/wBGS2HxGtcTrkiG9ubbFmpCnpU1hvduxCF0Aqkc1 RNyhbCOTtU6VZFW0s8+6agVua9S2lXKZZAeW3HMFe+fSNQ22RvZv9KDaWwk8KTmnkJKe +vNofN2n5zwBRstNOxE17yrv+/qqFzcibtlo/QyrHgvSl9JVjcgOGvGj3bprptpcbU5u u2M0EAqZXsCLVuP9rBBbXrlppsmMRD6VIwhJ47xZPll54V5b4Ip/I5+EKGSVpndeO26g cgHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=esf31fNCe4wbGidYc1qvg9Z2RPCcFg6ooHfJQK2k2ek=; b=Neh0lLp2C9snHgYem0ev1gczlJZGhgGJXz4PxTJe1AkK1/w3a2dxH9Q5UxW8ljcE8/ /qvqZIXbttVjOtlnMQzLW716gyAc7ObmrKV4mpdLlA9MaYwkHPos3VVDH5HZLC+3JZF2 TGXwrU2QYFWB6vf0r7hKRwZCPT2bX6wqG7WNcPDgCIhtukcCyXW42YoKu2xizBJax1VI mnlC7jAWFCXEaMBlgFYpDLwBeby7hXM9gxI4nYN7Qh/Mkmwqx9mHOsz5VQFVzi7TMDUY apB6H70pbYLySCF+bf0h6SjRed1h6njraz3o+cr+Xtlx7JwE5Tb9D3n7N+TNa7Qo6kwv 2z7A== X-Gm-Message-State: AKS2vOw0QRJMa7PPG6QtywALNSzBSbCmQYhy6molcyYxTgsaRdsSKVHw YKStk8J2wBwEHQpV2K0= X-Received: by 10.28.58.143 with SMTP id h137mr7185845wma.72.1497006478589; Fri, 09 Jun 2017 04:07:58 -0700 (PDT) Received: from sven-desktop.home.narfation.org (p2003007C6F55E5FE527B9DFFFECE2683.dip0.t-ipconnect.de. [2003:7c:6f55:e5fe:527b:9dff:fece:2683]) by smtp.gmail.com with ESMTPSA id f70sm1970565wmd.25.2017.06.09.04.07.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 09 Jun 2017 04:07:57 -0700 (PDT) From: Sven Eckelmann To: ath10k@lists.infradead.org Cc: linux-wireless@vger.kernel.org, Ben Greear , Sven Eckelmann Subject: [PATCH v2 1/3] ath10k: Use complete VHT chan width for 160MHz workaround Date: Fri, 9 Jun 2017 13:07:48 +0200 Message-Id: <20170609110750.14950-1-sven.eckelmann@openmesh.com> X-Mailer: git-send-email 2.11.0 Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Ben Greear The ath10k firmware doesn't announce its VHT channel width capabilities in the vht_cap information from the "service ready event" arguments. The driver must therefore check whether the 160MHz short GI bit is set and whether the driver still doesn't set the bits for the 160/80+80 MHz capabilities. The two bits for the channel width are a two bit integer and not two separate bits which cannot be parsed without the knowledge of the other bit. Using IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ (b10..) as a mask for this task doesn't make any sense. The correct mask for the VHT channel width should be used instead to make this check more readable. Signed-off-by: Ben Greear [sven.eckelmann@openmesh.com: separate 160Mhz workaround cleanup, add commit message] Signed-off-by: Sven Eckelmann --- v2: - extracted this cleanup portion and converted it to a separate patch drivers/net/wireless/ath/ath10k/mac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 4674ff33d320..8087b6be5484 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -4391,7 +4391,7 @@ static struct ieee80211_sta_vht_cap ath10k_create_vht_cap(struct ath10k *ar) * mode until that's resolved. */ if ((ar->vht_cap_info & IEEE80211_VHT_CAP_SHORT_GI_160) && - !(ar->vht_cap_info & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ)) + (ar->vht_cap_info & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK) == 0) vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ; mcs_map = 0;