From patchwork Mon Sep 25 19:09:15 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Manikanta Pubbisetty X-Patchwork-Id: 9970375 X-Patchwork-Delegate: johannes@sipsolutions.net 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 87EA2602D8 for ; Mon, 25 Sep 2017 19:09:45 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6B1D928C46 for ; Mon, 25 Sep 2017 19:09:45 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 600AE28CC2; Mon, 25 Sep 2017 19:09:45 +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.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID 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 ADC3E28CBD for ; Mon, 25 Sep 2017 19:09:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935830AbdIYTJW (ORCPT ); Mon, 25 Sep 2017 15:09:22 -0400 Received: from sabertooth02.qualcomm.com ([65.197.215.38]:43829 "EHLO sabertooth02.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933306AbdIYTJV (ORCPT ); Mon, 25 Sep 2017 15:09:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1506366561; x=1537902561; h=from:to:cc:subject:date:message-id:mime-version; bh=PA5XDdNG/9ilTV1hwfsMkK2m1l/B+1i5RQ4Rq/gUiBc=; b=oMwzF1ezyG+/HVvcNxQ5tTWvMjwaKx2nfbDh+cll98X2PyhGxvD0gcGJ dTe1EEnuBLRF5Qws9hR9kR8qTQKPYWQUobcLiECjGGHK8kedCMqjwJRwa nzqSXbVqtLDrS5fl8UG3z7FADrxTKrDy4BVo13FFLZ+fHfCEtLdJTNIYa Y=; X-IronPort-AV: E=Sophos;i="5.42,437,1500966000"; d="scan'208";a="116171256" Received: from unknown (HELO Ironmsg03-R.qualcomm.com) ([10.53.140.107]) by sabertooth02.qualcomm.com with ESMTP; 25 Sep 2017 12:09:20 -0700 X-IronPort-AV: E=McAfee;i="5900,7806,8665"; a="1449039766" X-MGA-submission: =?us-ascii?q?MDEQK6JMDz8+E+/1kPO9TpgLOXSv7bPKAVdwCa?= =?us-ascii?q?YQ72O6iqGPhJ/KeuIOvR4dCmAy+YBNz6yHqradzoS7sKcuPHxROSnpf7?= =?us-ascii?q?FxA9Yz7ZiilQHj5UNGa0TSLkl6zrbF7R6SMyrDoz7WMyuNBbWPtmwxqu?= =?us-ascii?q?KI?= Received: from nasanexm01d.na.qualcomm.com ([10.85.0.84]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES256-SHA; 25 Sep 2017 12:09:20 -0700 Received: from aphydexm01f.ap.qualcomm.com (10.252.127.15) by NASANEXM01D.na.qualcomm.com (10.85.0.84) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 25 Sep 2017 12:09:19 -0700 Received: from localhost (10.80.80.8) by aphydexm01f.ap.qualcomm.com (10.252.127.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 26 Sep 2017 00:39:13 +0530 From: To: CC: , Manikanta Pubbisetty Subject: [PATCH] mac80211: fix bandwidth computation for TDLS peers Date: Tue, 26 Sep 2017 00:39:15 +0530 Message-ID: <1506366555-21862-1-git-send-email-mpubbise@qti.qualcomm.com> X-Mailer: git-send-email 1.7.9.5 MIME-Version: 1.0 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.85.0.31) To aphydexm01f.ap.qualcomm.com (10.252.127.15) 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: Manikanta Pubbisetty Section 11.23.1 of 80211-2016 specification allows TDLS peers to operate on wider bandwidths though they are connected to a BSS which do not support wider bandwidth operations, provided both the peers advertize wider banwidth capabilities. The existing logic considers the minimum of station's and AP's capability for bandwidth computation. The same logic applies for TDLS peers as well, this restricts operating on wider bandwidths over a TDLS link when the peers are connected to legacy APs. As an example, If 80Mhz VHT capable peers are connected to a 20Mhz 11a AP, then as per the existing logic TDLS operation will be restricted to 20Mhz. Addressing this problem by not considering BSS capability in bandwidth computaion if the participating TDLS peers have wider bandwidth capability. Signed-off-by: Manikanta Pubbisetty --- net/mac80211/vht.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c index 19ec218..b9276ac 100644 --- a/net/mac80211/vht.c +++ b/net/mac80211/vht.c @@ -386,6 +386,16 @@ enum ieee80211_sta_rx_bandwidth ieee80211_sta_cur_vht_bw(struct sta_info *sta) bw = ieee80211_sta_cap_rx_bw(sta); bw = min(bw, sta->cur_max_bandwidth); + + /* Don't consider AP's bandwidth for TDLS peers, section 11.23.1 of + * IEEE80211-2016 specification makes higher bandwidth operation + * possible on the TDLS link if the peers have wider bandwidth + * capability. + */ + if (test_sta_flag(sta, WLAN_STA_TDLS_PEER) && + test_sta_flag(sta, WLAN_STA_TDLS_WIDER_BW)) + return bw; + bw = min(bw, ieee80211_chan_width_to_rx_bw(bss_width)); return bw;