wifi: ath12k: advertise AP_VLAN interface mode for IPQ5332

Only the two QCN9274 hw_params advertise NL80211_IFTYPE_AP_VLAN; the IPQ5332 entry does not. As ath12k sets SW_CRYPTO_CONTROL, mac80211 does not add the mode on the driver's behalf, so AP/VLAN is absent from the wiphy and hostapd cannot create WDS station interfaces:

nl80211: Failed to create interface <name>: -95 (Operation not supported)

The 4-address datapath itself (sta_set_4addr, per-station TCL metadata, WMI_PEER_USE_4ADDR/WMI_VDEV_PARAM_WDS, 4-address frame and NULL/EAPOL handling) is shared Wi-Fi 7 code with no per-chip or per-bus gating, so IPQ5332 can already deliver it. AP_VLAN is a software interface type, so no interface combination changes are needed.

On a mixed-bus single-wiphy group the effect is wider still, since ath12k_mac_get_ifmodes() intersects interface_modes across all radios:
one IPQ5332 masks AP_VLAN for the QCN9274 radios too.

Advertise AP_VLAN on IPQ5332 as QCN9274 does. Tested with 4-address WDS stations on IPQ5332 + 2x QCN9274; RADIUS dynamic VLAN was not tested.

Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01270-QCAHKSWPL_SILICONZ-1
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1

Signed-off-by Kamil Bienkiewicz <[email protected]>

---
v2: rebased onto ath/main (8150c22bc). No functional change; v1 was generated against a backports tree and its trailing context no longer matched after .supports_cong_ctrl_max_msdus was added to the IPQ5332 hw_params entry.

IPQ5424 (line ~845, and possibly QCC2072/WCN7850) appears to need the same change, but I have no such hardware, so I have limited this to IPQ5332 which I could test.

  drivers/net/wireless/ath/ath12k/wifi7/hw.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

drivers/net/wireless/ath/ath12k/wifi7/hw.c +0 -0

index 7b86f324b..a20c21807 100644

Quoted 4 lines · Kamil Bienkiewicz

Only the two QCN9274 hw_params advertise NL80211_IFTYPE_AP_VLAN; the IPQ5332 entry does not. As ath12k sets SW_CRYPTO_CONTROL, mac80211 does not add the mode on the driver's behalf, so AP/VLAN is absent from the wiphy and hostapd cannot create WDS station interfaces:

Small clarification: for WDS station interfaces, hostapd creates the AP_VLAN interface with NL80211_ATTR_4ADDR set. That path is allowed by cfg80211_iftype_allowed() via WIPHY_FLAG_4ADDR_AP even when NL80211_IFTYPE_AP_VLAN is not set in wiphy->interface_modes.

So the missing interface_modes bit seems to affect the non-4addr AP_VLAN case instead, e.g. dynamic/per-station VLAN interfaces created via hostapd_vlan_if_add(). Is that the failure path you hit?

Quoted 37 lines

nl80211: Failed to create interface <name>: -95 (Operation not supported)

The 4-address datapath itself (sta_set_4addr, per-station TCL metadata, WMI_PEER_USE_4ADDR/WMI_VDEV_PARAM_WDS, 4-address frame and NULL/EAPOL handling) is shared Wi-Fi 7 code with no per-chip or per-bus gating, so IPQ5332 can already deliver it. AP_VLAN is a software interface type, so no interface combination changes are needed.

On a mixed-bus single-wiphy group the effect is wider still, since ath12k_mac_get_ifmodes() intersects interface_modes across all radios:
one IPQ5332 masks AP_VLAN for the QCN9274 radios too.

Advertise AP_VLAN on IPQ5332 as QCN9274 does. Tested with 4-address WDS stations on IPQ5332 + 2x QCN9274; RADIUS dynamic VLAN was not tested.

Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01270-QCAHKSWPL_SILICONZ-1
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1

Signed-off-by Kamil Bienkiewicz <[email protected]>

---
v2: rebased onto ath/main (8150c22bc). No functional change; v1 was generated against a backports tree and its trailing context no longer matched after .supports_cong_ctrl_max_msdus was added to the IPQ5332 hw_params entry.

IPQ5424 (line ~845, and possibly QCC2072/WCN7850) appears to need the same change, but I have no such hardware, so I have limited this to IPQ5332 which I could test.

  drivers/net/wireless/ath/ath12k/wifi7/hw.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

drivers/net/wireless/ath/ath12k/wifi7/hw.c +0 -0

index 7b86f324b..a20c21807 100644

drivers/net/wireless/ath/ath12k/wifi7/hw.c static const struct ath12k_hw_params ath12k_wifi7_hw_params[] = { · line 671

Quoted 9 lines

drivers/net/wireless/ath/ath12k/wifi7/hw.c +2 -1

@@ -664,7 +664,8 @@ static const struct ath12k_hw_params ath12k_wifi7_hw_params[] = {
 
              .interface_modes = BIT(NL80211_IFTYPE_STATION) |
                                 BIT(NL80211_IFTYPE_AP) |
-                                BIT(NL80211_IFTYPE_MESH_POINT),
+                                BIT(NL80211_IFTYPE_MESH_POINT) |
+                                BIT(NL80211_IFTYPE_AP_VLAN),
              .supports_monitor = true,
              .supports_cong_ctrl_max_msdus = true,
 

Actual change looks good to me so,

Reviewed-by Rameshkumar Sundaram <[email protected]>

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.

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.