[PATCH v3] 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. ath12k sets SW_CRYPTO_CONTROL, so mac80211 does
not add the mode on the driver's behalf either -- ieee80211_alloc_hw_nm()
only does that for drivers that leave SW_CRYPTO_CONTROL clear, leaving
the declaration to drivers that can transmit software-encrypted frames.

AP/VLAN is therefore absent from the wiphy, and creating an AP_VLAN
interface without NL80211_ATTR_4ADDR is rejected by
cfg80211_iftype_allowed():

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

That is the path hostapd uses for dynamic per-station VLANs, in
hostapd_vlan_if_add(). The 4-address (WDS) case is not affected, as
cfg80211_iftype_allowed() short-circuits it on WIPHY_FLAG_4ADDR_AP,
which mac80211 sets unconditionally at alloc time.

The QCN9274 entries already declare AP_VLAN, and the transmit path is
shared Wi-Fi 7 code with no per-chip or per-bus gating, so IPQ5332 can
deliver it as well. 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. With the mode advertised,
a non-4addr AP_VLAN interface can be created on an AP interface of an
IPQ5332 + 2x QCN9274 single-wiphy group:

  # iw dev phy0.0-ap0 interface add tvlan0 type __ap_vlan
  # iw dev tvlan0 info
  Interface tvlan0
  	ifindex 19
  	wdev 0x9
  	addr 00:03:7f:12:0b:0b
  	type AP/VLAN
  	wiphy 0
  	Radios: 0 1 2

RADIUS-assigned dynamic VLANs were not exercised end to end.

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]>
Reviewed-by: Rameshkumar Sundaram <[email protected]>
---
v3: corrected the rationale. The missing interface_modes bit gates the
non-4addr AP_VLAN path (hostapd dynamic per-station VLANs), not the
4-address WDS interfaces I originally blamed -- those are allowed via
WIPHY_FLAG_4ADDR_AP regardless (thanks Rameshkumar). Added the
interface-creation check on hardware. The diff is unchanged from v2, so
I have kept the Reviewed-by.

v2: rebased onto ath/main (8150c22bc); 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 (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(-)

diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hw.c b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
index 7b86f324b..a20c21807 100644
--- a/drivers/net/wireless/ath/ath12k/wifi7/hw.c
+++ b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
@@ -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,
 
-- 
2.55.0