Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 294CEC43381 for ; Wed, 13 Mar 2019 13:09:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F272D20693 for ; Wed, 13 Mar 2019 13:09:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726539AbfCMNJP (ORCPT ); Wed, 13 Mar 2019 09:09:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54665 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726167AbfCMNJO (ORCPT ); Wed, 13 Mar 2019 09:09:14 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7ECDD3023078; Wed, 13 Mar 2019 13:09:14 +0000 (UTC) Received: from localhost (unknown [10.43.2.106]) by smtp.corp.redhat.com (Postfix) with ESMTP id 12F50605A8; Wed, 13 Mar 2019 13:09:13 +0000 (UTC) Date: Wed, 13 Mar 2019 14:09:11 +0100 From: Stanislaw Gruszka To: Tom Psyborg Cc: linux-wireless@vger.kernel.org, kvalo@codeaurora.org, daniel@makrotopia.org Subject: Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt Message-ID: <20190313130910.GD2003@redhat.com> References: <1552417902-11040-1-git-send-email-pozega.tomislav@gmail.com> <1552417902-11040-2-git-send-email-pozega.tomislav@gmail.com> <20190313091252.GB2663@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Wed, 13 Mar 2019 13:09:14 +0000 (UTC) Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Wed, Mar 13, 2019 at 02:02:32PM +0100, Tom Psyborg wrote: > On 13/03/2019, Stanislaw Gruszka wrote: > > On Tue, Mar 12, 2019 at 08:11:42PM +0100, Tomislav Požega wrote: > >> MFP can work with enabled HW crypt engine, but in this case > >> available bandwidth is reduced at least when connecting to > >> Archer C7 (QCA9558). Enable the feature for known to work chipsets- > >> MT7620, RT3070 and RT5390. Userspace setting for ieee80211w should > >> default to 0 in order to prevent unintentional bandwidth drop. > >> > >> Signed-off-by: Tomislav Po?ega > >> --- > >> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 11 +++++++---- > >> 1 files changed, 7 insertions(+), 4 deletions(-) > >> > >> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c > >> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c > >> index a03b528..bb8204d 100644 > >> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c > >> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c > >> @@ -9326,6 +9326,13 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev > >> *rt2x00dev) > >> ieee80211_hw_set(rt2x00dev->hw, SIGNAL_DBM); > >> ieee80211_hw_set(rt2x00dev->hw, SUPPORTS_PS); > >> > >> + /* Experimental: Set MFP with HW crypto enabled. */ > >> + if (rt2x00_rt(rt2x00dev, RT3070) || rt2x00_rt(rt2x00dev, RT5390) || > >> + rt2x00_rt(rt2x00dev, RT6352)) > >> + ieee80211_hw_set(rt2x00dev->hw, MFP_CAPABLE); > > > > Is not that we support MFP in hardware. We just return -EOPNOTSUPP > > in rt2x00mac_set_key() when mac80211 will try to set MFP ciphers > > (since rt2x00crypto_key_to_cipher() will return CIPHER_NONE) and > > we fallback to software encryption. > > > > Please repost patch that enable MFP unconditionally with > > 'Cc: stable@vger.kernel.org' tag. > > > > Stanislaw > > > > No, I have not test any other chipsets besides the ones I enabled it > for. It is possible this would cause problems on other devices, so > just enable it for the known to work ones. It's just matter of sending already encrypted frames. All chipsets handle that. Stanislaw