Similar to VHT/HE. This is utilized to pass MU-MIMO configurations
from user space (i.e. hostapd) to driver.
Signed-off-by: Ryder Lee <[email protected]>
---
changes since v2
- fix typo of commit logs.
- revise statement of newly added members in ieee80211_bss_conf
- remove unneeded braces.
---
include/net/mac80211.h | 9 +++++++++
net/mac80211/cfg.c | 14 ++++++++++++++
2 files changed, 23 insertions(+)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 0cc76eea2014..879fc14ebd2a 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -670,6 +670,12 @@ struct ieee80211_fils_discovery {
* @he_full_ul_mumimo: does this BSS support the reception (AP) or transmission
* (non-AP STA) of an HE TB PPDU on an RU that spans the entire PPDU
* bandwidth
+ * @eht_su_beamformer: in AP-mode, does this BSS enable operation as an EHT SU
+ * beamformer
+ * @eht_su_beamformee: in AP-mode, does this BSS enable operation as an EHT SU
+ * beamformee
+ * @eht_mu_beamformer: in AP-mode, does this BSS enable operation as an EHT MU
+ * beamformer
*/
struct ieee80211_bss_conf {
const u8 *bssid;
@@ -752,6 +758,9 @@ struct ieee80211_bss_conf {
bool he_su_beamformee;
bool he_mu_beamformer;
bool he_full_ul_mumimo;
+ bool eht_su_beamformer;
+ bool eht_su_beamformee;
+ bool eht_mu_beamformer;
};
/**
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index f5d43f42f6d8..6bf1cdf254f6 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1296,6 +1296,20 @@ static int ieee80211_start_ap(struct wiphy *wiphy, struct net_device *dev,
IEEE80211_HE_PHY_CAP2_UL_MU_FULL_MU_MIMO;
}
+ if (params->eht_cap) {
+ link_conf->eht_su_beamformer =
+ params->eht_cap->fixed.phy_cap_info[0] &
+ IEEE80211_EHT_PHY_CAP0_SU_BEAMFORMER;
+ link_conf->eht_su_beamformee =
+ params->eht_cap->fixed.phy_cap_info[0] &
+ IEEE80211_EHT_PHY_CAP0_SU_BEAMFORMEE;
+ link_conf->eht_mu_beamformer =
+ params->eht_cap->fixed.phy_cap_info[7] &
+ (IEEE80211_EHT_PHY_CAP7_MU_BEAMFORMER_80MHZ |
+ IEEE80211_EHT_PHY_CAP7_MU_BEAMFORMER_160MHZ |
+ IEEE80211_EHT_PHY_CAP7_MU_BEAMFORMER_320MHZ);
+ }
+
if (sdata->vif.type == NL80211_IFTYPE_AP &&
params->mbssid_config.tx_wdev) {
err = ieee80211_set_ap_mbssid_options(sdata,
--
2.18.0
This is utilized to pass LDPC configurations from user space
(i.e. hostapd) to driver.
Signed-off-by: Ryder Lee <[email protected]>
---
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(+)
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;
--
2.18.0
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