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

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

[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:

  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 <perceivalpercy@gmail.com>
---
IPQ5424 (and possibly QCC2072/WCN7850) appear to need the same change,
but I have no such hardware, so I have limited this to IPQ5332 which I
could test.

--- a/drivers/net/wireless/ath/ath12k/wifi7/hw.c
+++ b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
@@ -655,7 +655,8 @@
 
 		.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,
 
 		.idle_ps = false,
-- 
2.47.0