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 <johannes@sipsolutions.net>
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

On Fri, 2018-03-09 at 11:57 +0530, mpubbise@codeaurora.org wrote:
> From: Manikanta Pubbisetty <mpubbise@codeaurora.org>
> 
> 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