From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from s3.sipsolutions.net ([144.76.63.242]:60782 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751405AbeCUHxK (ORCPT ); Wed, 21 Mar 2018 03:53:10 -0400 Message-ID: <1521618788.2645.5.camel@sipsolutions.net> (sfid-20180321_085313_185321_6EA21ABC) Subject: Re: [RFC] mac80211: advertise supported interface types for sw encryption From: Johannes Berg To: mpubbise@codeaurora.org Cc: linux-wireless@vger.kernel.org Date: Wed, 21 Mar 2018 08:53:08 +0100 In-Reply-To: <1520576822-1954-1-git-send-email-mpubbise@codeaurora.org> References: <1520576822-1954-1-git-send-email-mpubbise@codeaurora.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Fri, 2018-03-09 at 11:57 +0530, mpubbise@codeaurora.org wrote: > From: Manikanta Pubbisetty > > Extending SW_CRYPTO_CONTROL interface so that drivers can advertise > the interface types on which they can support software encryption. > Driver's job is not done by advertising the supported vif types alone, > they should also return -EOPNOTSUPP from set_key. > > Mac80211 will make the fallback decision to sw ecryption based > on the return type of set_key callback and the driver's support for > software encryption. > > This change is done with the sole reason of adding the support of > VLANs for drivers which enable SW_CRYPTO_CONTROL(ex:ath10k). > > With the current logic, configuring GTKs for specific VLAN groups will > always fail with the drivers enabling SW_CRYPTO_CONTROL. I understand > that the driver can return 1 from set_key to enable software encryption > in mac80211, but GTKs for VLANs are never passed down to the driver. > Since the return value is initialized to -EOPNOTSUPP, with this approach, > we get away with the failure. Is there much value in having this control to start with, rather than saying it's *always* allowed for AP_VLAN interfaces? I mean - if the driver wants to support (encryption on) AP_VLAN interfaces with SW_CRYPTO_CONTROL it basically has to set this to allow it, which is kinda pointless - it's hard to imagine a driver that wants to support AP_VLAN only for unencrypted, so if it doesn't support this it might as well just disable AP_VLAN support entirely. So IMHO - just get rid of the bitmap and hard-code AP_VLAN. johannes