Message ID | 20230920082349.29111-1-quic_wgong@quicinc.com |
---|---|
Headers | show |
Series | wifi: ath11k: add support for 6 GHz station for various modes : LPI, SP and VLP | expand |
On 9/22/2023 9:18 PM, Aditya Kumar Singh wrote: > On 9/22/23 15:32, Wen Gong wrote: >> On 9/22/2023 5:39 PM, Aditya Kumar Singh wrote: >>> On 9/20/23 13:53, Wen Gong wrote: >>> >>>> + if (ath11k_mac_supports_6ghz_cc_ext(ar) && >>>> + ctx->def.chan->band == NL80211_BAND_6GHZ && >>>> + arvif->vdev_type == WMI_VDEV_TYPE_STA) { >>>> + reg_info = &ab->reg_info_store[ar->pdev_idx]; >>>> + power_type = vif->bss_conf.power_type; >>>> + ath11k_dbg(ab, ATH11K_DBG_MAC, "mac chanctx power type %d\n", >>>> + power_type); >>>> + if (power_type == IEEE80211_REG_UNSET_AP) >>>> + power_type = IEEE80211_REG_LPI_AP; >>> Why having _UNSET_ power type in vif->bss_conf.power_type is fine? >>> Typically, during association, we would be setting this from the >>> beacon/association response frame's HE 6 GHz Operation Info Field. >>> So is it fine if the field is carrying some info which we don't know >>> (or may be don't support it yet)? Why are we masking it with _LPI_ >>> mode? >>> >>> Also, I see that currently mac80211 only sets LPI or SP. So let's >>> say STA is trying to connect to VLP AP, mac80211 will set it as >>> _UNSET_. And then here, we will be treating it as LPI AP. Is that fine? >> >> Currently only SP/LPI are defined in "Table E-12—Regulatory Info >> subfield encoding in the United States" of IEEE Std 802.11ax™‐2021. >> >> So maybe I need to set power_type to VLP when it is UNSET here. > Yeah, or may be deny association if we don't support that mode? I > would let others comment on this. Do you know how to check which mode support by ath11k?
On 9/25/2023 6:52 PM, Aditya Kumar Singh wrote: > On 9/25/23 16:13, Wen Gong wrote: >> On 9/22/2023 9:18 PM, Aditya Kumar Singh wrote: >>> On 9/22/23 15:32, Wen Gong wrote: >>>> On 9/22/2023 5:39 PM, Aditya Kumar Singh wrote: >>>>> On 9/20/23 13:53, Wen Gong wrote: >>>>> >>>>>> + if (ath11k_mac_supports_6ghz_cc_ext(ar) && >>>>>> + ctx->def.chan->band == NL80211_BAND_6GHZ && >>>>>> + arvif->vdev_type == WMI_VDEV_TYPE_STA) { >>>>>> + reg_info = &ab->reg_info_store[ar->pdev_idx]; >>>>>> + power_type = vif->bss_conf.power_type; >>>>>> + ath11k_dbg(ab, ATH11K_DBG_MAC, "mac chanctx power type >>>>>> %d\n", >>>>>> + power_type); >>>>>> + if (power_type == IEEE80211_REG_UNSET_AP) >>>>>> + power_type = IEEE80211_REG_LPI_AP; >>>>> Why having _UNSET_ power type in vif->bss_conf.power_type is fine? >>>>> Typically, during association, we would be setting this from the >>>>> beacon/association response frame's HE 6 GHz Operation Info Field. >>>>> So is it fine if the field is carrying some info which we don't >>>>> know (or may be don't support it yet)? Why are we masking it with >>>>> _LPI_ mode? >>>>> >>>>> Also, I see that currently mac80211 only sets LPI or SP. So let's >>>>> say STA is trying to connect to VLP AP, mac80211 will set it as >>>>> _UNSET_. And then here, we will be treating it as LPI AP. Is that >>>>> fine? >>>> >>>> Currently only SP/LPI are defined in "Table E-12—Regulatory Info >>>> subfield encoding in the United States" of IEEE Std 802.11ax™‐2021. >>>> >>>> So maybe I need to set power_type to VLP when it is UNSET here. >>> Yeah, or may be deny association if we don't support that mode? I >>> would let others comment on this. >> Do you know how to check which mode support by ath11k? > IMHO we should not maintain two different supported modes, one in > driver and another in mac80211. I mean w.r.t mac80211 we should try to > match it as far as possible. In this case, we can return error from > mac80211 itself when a non-supported mode (as in VLP) is trying to > associate? Since as you have quoted, VLP is not yet defined in spec > IEEE Std 802.11ax‐2021 so why to mask the mode and continue in > mac80211 itself? > > If we do like this, then mac80211 will not simply set _UNSET_ for 6 > GHz client interface and in driver if we see its still _UNSET_ then we > can be sure that something has gone wrong and we can take steps > accordingly. Yes, I will change to return fail for _UNSET_.