| Message ID | 1de696aaa34efd77a926eb657b8c0fda05aaa177.1676628065.git.ryder.lee@mediatek.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v2,1/2] wifi: mac80211: add EHT MU-MIMO related flags in ieee80211_bss_conf | expand |
On Sat, 2023-02-18 at 01:49 +0800, Ryder Lee wrote: > This is utilized to pass LDPC configurations from user space > (i.e. hostapd) to driver. > I'm applying this, but could you do me a favour and check that we really don't need to reset this? What if we added a previous BSS with e.g. VHT and then reconfigure the interface to w/o VHT and then the settings might stick? More generally, it might be worth checking if we can just memset the entire bss_conf to 0? We already do this for link conf today (always reallocate it) so it should be OK? Same actually goes for client mode so maybe we can generally clean that up? johannes
On Tue, 2023-03-07 at 11:08 +0100, Johannes Berg wrote: > On Sat, 2023-02-18 at 01:49 +0800, Ryder Lee wrote: > > This is utilized to pass LDPC configurations from user space > > (i.e. hostapd) to driver. > > > > I'm applying this, but could you do me a favour and check that we > really > don't need to reset this? What if we added a previous BSS with e.g. > VHT > and then reconfigure the interface to w/o VHT and then the settings > might stick? > > More generally, it might be worth checking if we can just memset the > entire bss_conf to 0? We already do this for link conf today (always > reallocate it) so it should be OK? Same actually goes for client mode > so > maybe we can generally clean that up? > I agree, and myabe this is a long standing issue. I think we need a fresh start for bss_conf. I've seen this case: hostapd would pass fils_interval only if (param->fils_interval), so if someone tries to disable it by "0" which doesn't work. Kernel should ptotect such case. Ryder
On Tue, 2023-03-14 at 17:47 +0000, Ryder Lee wrote: > On Tue, 2023-03-07 at 11:08 +0100, Johannes Berg wrote: > > On Sat, 2023-02-18 at 01:49 +0800, Ryder Lee wrote: > > > This is utilized to pass LDPC configurations from user space > > > (i.e. hostapd) to driver. > > > > > > > I'm applying this, but could you do me a favour and check that we > > really > > don't need to reset this? What if we added a previous BSS with e.g. > > VHT > > and then reconfigure the interface to w/o VHT and then the settings > > might stick? > > > > More generally, it might be worth checking if we can just memset the > > entire bss_conf to 0? We already do this for link conf today (always > > reallocate it) so it should be OK? Same actually goes for client mode > > so > > maybe we can generally clean that up? > > > > I agree, and myabe this is a long standing issue. I think we need a > fresh start for bss_conf. > > I've seen this case: > hostapd would pass fils_interval only if (param->fils_interval), so if > someone tries to disable it by "0" which doesn't work. Kernel should > ptotect such case. Yeah, that's another one of those cases ... :( johannes
diff --git a/include/net/mac80211.h b/include/net/mac80211.h index 879fc14ebd2a..5f0902b4f8ea 100644 --- a/include/net/mac80211.h +++ b/include/net/mac80211.h @@ -653,6 +653,9 @@ struct ieee80211_fils_discovery { * write-protected by sdata_lock and local->mtx so holding either is fine * for read access. * @color_change_color: the bss color that will be used after the change. + * @ht_ldpc: in AP mode, indicates interface has HT LDPC capability. + * @vht_ldpc: in AP mode, indicates interface has VHT LDPC capability. + * @he_ldpc: in AP mode, indicates interface has HE LDPC capability. * @vht_su_beamformer: in AP mode, does this BSS support operation as an VHT SU * beamformer * @vht_su_beamformee: in AP mode, does this BSS support operation as an VHT SU @@ -750,6 +753,9 @@ struct ieee80211_bss_conf { bool color_change_active; u8 color_change_color; + bool ht_ldpc; + bool vht_ldpc; + bool he_ldpc; bool vht_su_beamformer; bool vht_su_beamformee; bool vht_mu_beamformer; diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c index 6bf1cdf254f6..b02cd0acc4e3 100644 --- a/net/mac80211/cfg.c +++ b/net/mac80211/cfg.c @@ -1252,7 +1252,15 @@ static int ieee80211_start_ap(struct wiphy *wiphy, struct net_device *dev, prev_beacon_int = link_conf->beacon_int; link_conf->beacon_int = params->beacon_interval; + if (params->ht_cap) + link_conf->ht_ldpc = + params->ht_cap->cap_info & + cpu_to_le16(IEEE80211_HT_CAP_LDPC_CODING); + if (params->vht_cap) { + link_conf->vht_ldpc = + params->vht_cap->vht_cap_info & + cpu_to_le32(IEEE80211_VHT_CAP_RXLDPC); link_conf->vht_su_beamformer = params->vht_cap->vht_cap_info & cpu_to_le32(IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE); @@ -1282,6 +1290,9 @@ static int ieee80211_start_ap(struct wiphy *wiphy, struct net_device *dev, } if (params->he_cap) { + link_conf->he_ldpc = + params->he_cap->phy_cap_info[1] & + IEEE80211_HE_PHY_CAP1_LDPC_CODING_IN_PAYLOAD; link_conf->he_su_beamformer = params->he_cap->phy_cap_info[3] & IEEE80211_HE_PHY_CAP3_SU_BEAMFORMER;
This is utilized to pass LDPC configurations from user space (i.e. hostapd) to driver. Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> --- changes since v2 - fix typo of commit logs. - revise statement of newly added members in ieee80211_bss_conf. --- include/net/mac80211.h | 6 ++++++ net/mac80211/cfg.c | 11 +++++++++++ 2 files changed, 17 insertions(+)