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_.
