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]>