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

[PATCH v2] 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>
---
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,
 
-- 
2.55.0

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

[Rameshkumar Sundaram]

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 <perceivalpercy@gmail.com>
> ---
> 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 <rameshkumar.sundaram@oss.qualcomm.com>

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

[Kamil Bienkiewicz]

Esteemed Rameshkumar,

Thanks for the review and for the correction — you're right, and my commit
message is wrong. I've verified it in the tree rather than argue it:

`cfg80211_iftype_allowed()` (net/wireless/util.c) short-circuits before
`interface_modes` is consulted for the 4addr case:

case 0:
if (is_vlan && is_4addr)
return wiphy->flags & WIPHY_FLAG_4ADDR_AP;
return wiphy->interface_modes & BIT(iftype);

and `WIPHY_FLAG_4ADDR_AP` is set unconditionally by mac80211 at alloc time,
not gated on AP_VLAN being advertised (net/mac80211/main.c, in
`ieee80211_alloc_hw_nm()`):

wiphy->flags |= WIPHY_FLAG_NETNS_OK |
WIPHY_FLAG_4ADDR_AP |
WIPHY_FLAG_4ADDR_STATION | ...

So the missing `NL80211_IFTYPE_AP_VLAN` bit cannot have blocked hostapd's WDS
path, which sets NL80211_ATTR_4ADDR. The `check_swif == 1` case falls back to
the same flag, so interface combinations don't block it either.

The premise the patch rests on is still correct — mac80211 skips adding AP_VLAN
for us because of SW_CRYPTO_CONTROL (main.c):

/* if low-level driver supports AP, we also support VLAN.
* drivers advertising SW_CRYPTO_CONTROL should enable AP_VLAN
* based on their support to transmit SW encrypted packets.
*/
if (local->hw.wiphy->interface_modes & BIT(NL80211_IFTYPE_AP) &&
    !ieee80211_hw_check(&local->hw, SW_CRYPTO_CONTROL)) {

— but the consequence I attributed to it is the wrong one. As you say, what is
actually gated is the non-4addr AP_VLAN case, i.e. dynamic per-station VLANs via
`hostapd_vlan_if_add()`.

On what I actually hit: the symptom was hostapd failing to bring up WDS station
interfaces on IPQ5332, and I developed this patch alongside a hostapd fix in
`get_hapd_bssid()` (bss->ctx dispatch), which Jouni has since applied. Given the
above, the hostapd change is almost certainly what fixed the WDS case, and my
attribution to this patch was confounded — the two were tested together, and at
least one of my A/B runs was invalid because wpad was never actually restarted.
I should have caught that before writing the commit message.

I'll send a v3 with the rationale corrected to the dynamic-VLAN path and drop
the WDS claim, keeping your Reviewed-by only if you're happy with the reworded
message — say the word if you'd rather re-review it.

I have the hardware set up (IPQ5332 AP with a 4addr client), so if it is useful
I can also test the non-4addr dynamic-VLAN path explicitly — with and without
the bit — and report what each does, rather than leaving the justification
resting on code reading alone.

Regards,
Kamil

On Wed, 5 Aug 2026 at 20:18, Rameshkumar Sundaram
<rameshkumar.sundaram@oss.qualcomm.com> wrote:
>
> 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 <perceivalpercy@gmail.com>
> > ---
> > 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 <rameshkumar.sundaram@oss.qualcomm.com>