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

Rameshkumar Sundaram <[email protected]> Wed, 5 Aug 2026 23:48:43 +0530
Newsgroups org.kernel.vger.linux-wireless,org.infradead.lists.ath12k
Message-ID <[email protected]>
On 8/1/2026 6:12 AM, Kamil Bienkiewicz wrote:
> 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?

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

Actual change looks good to me so,

Reviewed-by: Rameshkumar Sundaram <[email protected]>