Re: [RFC] mac80211: advertise supported interface types for sw encryption

[Johannes Berg <johannes@sipsolutions.net>]

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