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

Rameshkumar Sundaram <[email protected]>
Newsgroups org.infradead.lists.ath12k,org.kernel.vger.linux-wireless
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]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.