[PATCH] ath10k: add dynamic vlan support

Manikanta Pubbisetty mpubbise at codeaurora.org
Tue Apr 24 02:18:10 PDT 2018

Yes Sebastian, Your point is valid. This would break the 4-addr 
operation on other ath10k devices which does not support the new WMI 

I have another approach to solve this problem, I will come with a small 
patch and see what johannes has to say on that approach.


On 4/24/2018 2:39 PM, Sebastian Gottschall wrote:
> consider my comment regarding vlan_ap.
> this patch will break wds ap / wds sta support with latest mac80211 
> (see also my post on the wireless mailing list about the breaking 
> patch in mac80211)
> so AP_VLAN must be masked always for all chipsets. otherwise wds 
> breaks and this is not just a guess. i tested it yesterday using this 
> patch and found
> the cause of the issue
> the following lines
>   +    if (test_bit(WMI_SERVICE_PER_PACKET_SW_ENCRYPT, 
> ar->wmi.svc_map)) {
> +        ar->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_AP_VLAN);
> +        ar->hw->wiphy->software_iftypes |= BIT(NL80211_IFTYPE_AP_VLAN);
> +    }
> must be just
> +        ar->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_AP_VLAN);
> +        ar->hw->wiphy->software_iftypes |= BIT(NL80211_IFTYPE_AP_VLAN);
> everthing else will cause a regression
> Am 24.04.2018 um 10:09 schrieb Kalle Valo:
>> Manikanta Pubbisetty <mpubbise at codeaurora.org> writes:
>>> Mutlicast/broadcast traffic destined for a particular vlan group will
>>> always be encrypted in software. To enable dynamic VLANs, it requires
>>> driver support for sending software encrypted packets.
>>> In ath10k, sending sw encrypted frames is allowed only when we insmod
>>> the driver with cryptmode param set to 1, this configuration disables
>>> hardware crypto and enables RAW mode implicitly. Since, enabling raw
>>> mode has performance impact, this cannot be considered as an ideal
>>> solution for supporting VLANs in the driver.
>>> As an alternative take, in this approach, cryptographic keys for
>>> unicast traffic(per peer PTKs) and keys for non-vlan group traffic
>>> will be configured in hardware, allowing hardware encryption for 
>>> unicast
>>> and non-vlan group traffic. Only vlan group traffic will be 
>>> encrypted in
>>> software and pushed to the target with encap mode set to RAW in the TX
>>> descriptors.
>>> Not all firmwares can support this type of key configuration(having few
>>> keys installed in hardware and few only in software); for this 
>>> purpose a
>>> new WMI service flag "WMI_SERVICE_PER_PACKET_SW_ENCRYPT" is 
>>> introduced to
>>> advertise this support.
>>> Also, adding the logic required to send sw encrypted frames in raw 
>>> mode.
>>> Tested this change on QCA9984(firmware version 10.4-3.5.3-00057).
>>> Signed-off-by: Manikanta Pubbisetty <mpubbise at codeaurora.org>
>> Your name in patchwork is wrong and hence my script uses the wrong
>> name. Please fix it by registering to patchwork[1] where it's possible
>> to change your name during registration, but only one time. If that
>> doesn't work then send a request to helpdesk at kernel.org and the admins
>> can fix it.
>> [1] https://patchwork.kernel.org/register/

More information about the ath10k mailing list