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

---
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(-)

index 7b86f324b..a20c21807 100644
@@ -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

Applied, thanks!

[1/1] wifi: ath12k: advertise AP_VLAN interface mode for IPQ5332

      commit: 6a0832c986f14518645714be87724f13e9d59a95

Best regards,

Jeff Johnson <[email protected]>