diff mbox series

[v2,2/2] wifi: mac80211: add LDPC related flags in ieee80211_bss_conf

Message ID 1de696aaa34efd77a926eb657b8c0fda05aaa177.1676628065.git.ryder.lee@mediatek.com (mailing list archive)
State New, archived
Headers show
Series [v2,1/2] wifi: mac80211: add EHT MU-MIMO related flags in ieee80211_bss_conf | expand

Commit Message

Ryder Lee Feb. 17, 2023, 5:49 p.m. UTC
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(+)

Comments

Johannes Berg March 7, 2023, 10:08 a.m. UTC | #1
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
Ryder Lee March 14, 2023, 5:47 p.m. UTC | #2
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
Johannes Berg March 14, 2023, 6:01 p.m. UTC | #3
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 mbox series

Patch

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;