On Fri, 2018-03-09 at 11:57 +0530, [email protected] wrote: > From: Manikanta Pubbisetty <[email protected]> > > 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
