Re: [PATCH v2] wifi: ath12k: advertise AP_VLAN interface mode for IPQ5332

On 8/6/2026 10:41 AM, Kamil Bienkiewicz wrote:
> Esteemed Rameshkumar,
> 
> Thanks for the review and for the correction — you're right, and my commit
> message is wrong. I've verified it in the tree rather than argue it:
> 
> `cfg80211_iftype_allowed()` (net/wireless/util.c) short-circuits before
> `interface_modes` is consulted for the 4addr case:
> 
> case 0:
> if (is_vlan && is_4addr)
> return wiphy->flags & WIPHY_FLAG_4ADDR_AP;
> return wiphy->interface_modes & BIT(iftype);
> 
> and `WIPHY_FLAG_4ADDR_AP` is set unconditionally by mac80211 at alloc time,
> not gated on AP_VLAN being advertised (net/mac80211/main.c, in
> `ieee80211_alloc_hw_nm()`):
> 
> wiphy->flags |= WIPHY_FLAG_NETNS_OK |
> WIPHY_FLAG_4ADDR_AP |
> WIPHY_FLAG_4ADDR_STATION | ...
> 
> So the missing `NL80211_IFTYPE_AP_VLAN` bit cannot have blocked hostapd's WDS
> path, which sets NL80211_ATTR_4ADDR. The `check_swif == 1` case falls back to
> the same flag, so interface combinations don't block it either.
> 
> The premise the patch rests on is still correct — mac80211 skips adding AP_VLAN
> for us because of SW_CRYPTO_CONTROL (main.c):
> 
> /* if low-level driver supports AP, we also support VLAN.
> * drivers advertising SW_CRYPTO_CONTROL should enable AP_VLAN
> * based on their support to transmit SW encrypted packets.
> */
> if (local->hw.wiphy->interface_modes & BIT(NL80211_IFTYPE_AP) &&
>      !ieee80211_hw_check(&local->hw, SW_CRYPTO_CONTROL)) {
> 
> — but the consequence I attributed to it is the wrong one. As you say, what is
> actually gated is the non-4addr AP_VLAN case, i.e. dynamic per-station VLANs via
> `hostapd_vlan_if_add()`.
> 
> On what I actually hit: the symptom was hostapd failing to bring up WDS station
> interfaces on IPQ5332, and I developed this patch alongside a hostapd fix in
> `get_hapd_bssid()` (bss->ctx dispatch), which Jouni has since applied. Given the
> above, the hostapd change is almost certainly what fixed the WDS case, and my
> attribution to this patch was confounded — the two were tested together, and at
> least one of my A/B runs was invalid because wpad was never actually restarted.
> I should have caught that before writing the commit message.
> 
> I'll send a v3 with the rationale corrected to the dynamic-VLAN path and drop
> the WDS claim, keeping your Reviewed-by only if you're happy with the reworded
> message — say the word if you'd rather re-review it.

Sounds good to me.

> 
> I have the hardware set up (IPQ5332 AP with a 4addr client), so if it is useful
> I can also test the non-4addr dynamic-VLAN path explicitly — with and without
> the bit — and report what each does, rather than leaving the justification
> resting on code reading alone.
> 

Also, please use inline replies in upstream discussions instead of top 
posting as recommended by the kernel documentation - 
https://docs.kernel.org/process/submitting-patches.html#use-trimmed-interleaved-replies-in-email-discussions


--
Ramesh