Re: [PATCH] ath10k: add dynamic vlan support

[Manikanta Pubbisetty <mpubbise@codeaurora.org>]

On 5/23/2018 4:09 PM, Johannes Berg wrote:
> On Wed, 2018-05-23 at 16:09 +0530, Manikanta Pubbisetty wrote:
>>>>>> + * @IEEE80211_HW_SUPPORTS_SW_ENCRYPT: Device is capable of transmitting
>>>>>> + *     frames encrypted in software, only valid when SW_CRYPTO_CONTROL
>>>>>> + *     is enabled. Based on this flag, mac80211 can allow/disallow VLAN
>>>>>> + *     operations in the BSS.
>>>>> Based on the name and initial description, this sounds equivalent to
>>>>> just turning off SW_CRYPTO_CONTROL. I think that's not the intent, but
>>>>> would need some renaming.
>>>> I can rename it to something which is very specific to VLAN support on
>>>> sw crypto controlled devices if that is okay.
>>> I don't think that makes sense. If we split the capability of AP_VLAN
>>> and AP_VLAN_FOR_4ADDR at the "root", then we don't need to play with all
>>> these things. Yes, this is slightly awkward for userspace, and perhaps
>>> with the interface combination checks, but I'd like you to look at that.
>>>
>> Makes sense, I had this thought to split the VLAN and 4-addr
>> functionality, but since we need to fiddle with userspace, I refrained.
>> Anyways, I will check all the possibilities of splitting these
>> functionalities.
> I'm not sure we really have to - it's likely that wpa_s/hostapd don't
> check the capabilities?
>
> johannes

IIUC, hostapd will just invoke a NL command to create the AP/VLAN 
interface, the capabilities are checked mostly in cfg80211.
If we are planning to split the functionality, possibly something like 
having two separate IF-TYPES(one for VLAN and one for 4-addr) instead of 
one(which is the case now),
we should probably change the relevant areas in hostapd as well, not 
really sure of the complexity of the work involved in userspace though.