* [PATCH] wireless: wil6210: no need to check return value of debugfs_create functions
From: Greg Kroah-Hartman @ 2019-06-11 19:10 UTC (permalink / raw)
To: Maya Erez, Kalle Valo; +Cc: David S. Miller, linux-wireless, wil6210
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Maya Erez <merez@codeaurora.org>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Cc: wil6210@qti.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/ath/wil6210/debugfs.c | 80 ++++++----------------
1 file changed, 22 insertions(+), 58 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/debugfs.c b/drivers/net/wireless/ath/wil6210/debugfs.c
index df2adff6c33a..ea5da93196fd 100644
--- a/drivers/net/wireless/ath/wil6210/debugfs.c
+++ b/drivers/net/wireless/ath/wil6210/debugfs.c
@@ -394,25 +394,18 @@ static int wil_debugfs_iomem_x32_get(void *data, u64 *val)
DEFINE_DEBUGFS_ATTRIBUTE(fops_iomem_x32, wil_debugfs_iomem_x32_get,
wil_debugfs_iomem_x32_set, "0x%08llx\n");
-static struct dentry *wil_debugfs_create_iomem_x32(const char *name,
- umode_t mode,
- struct dentry *parent,
- void *value,
- struct wil6210_priv *wil)
+static void wil_debugfs_create_iomem_x32(const char *name, umode_t mode,
+ struct dentry *parent, void *value,
+ struct wil6210_priv *wil)
{
- struct dentry *file;
struct wil_debugfs_iomem_data *data = &wil->dbg_data.data_arr[
wil->dbg_data.iomem_data_count];
data->wil = wil;
data->offset = value;
- file = debugfs_create_file_unsafe(name, mode, parent, data,
- &fops_iomem_x32);
- if (!IS_ERR_OR_NULL(file))
- wil->dbg_data.iomem_data_count++;
-
- return file;
+ debugfs_create_file_unsafe(name, mode, parent, data, &fops_iomem_x32);
+ wil->dbg_data.iomem_data_count++;
}
static int wil_debugfs_ulong_set(void *data, u64 val)
@@ -430,14 +423,6 @@ static int wil_debugfs_ulong_get(void *data, u64 *val)
DEFINE_DEBUGFS_ATTRIBUTE(wil_fops_ulong, wil_debugfs_ulong_get,
wil_debugfs_ulong_set, "0x%llx\n");
-static struct dentry *wil_debugfs_create_ulong(const char *name, umode_t mode,
- struct dentry *parent,
- ulong *value)
-{
- return debugfs_create_file_unsafe(name, mode, parent, value,
- &wil_fops_ulong);
-}
-
/**
* wil6210_debugfs_init_offset - create set of debugfs files
* @wil - driver's context, used for printing
@@ -454,37 +439,30 @@ static void wil6210_debugfs_init_offset(struct wil6210_priv *wil,
int i;
for (i = 0; tbl[i].name; i++) {
- struct dentry *f;
-
switch (tbl[i].type) {
case doff_u32:
- f = debugfs_create_u32(tbl[i].name, tbl[i].mode, dbg,
- base + tbl[i].off);
+ debugfs_create_u32(tbl[i].name, tbl[i].mode, dbg,
+ base + tbl[i].off);
break;
case doff_x32:
- f = debugfs_create_x32(tbl[i].name, tbl[i].mode, dbg,
- base + tbl[i].off);
+ debugfs_create_x32(tbl[i].name, tbl[i].mode, dbg,
+ base + tbl[i].off);
break;
case doff_ulong:
- f = wil_debugfs_create_ulong(tbl[i].name, tbl[i].mode,
- dbg, base + tbl[i].off);
+ debugfs_create_file_unsafe(tbl[i].name, tbl[i].mode,
+ dbg, base + tbl[i].off,
+ &wil_fops_ulong);
break;
case doff_io32:
- f = wil_debugfs_create_iomem_x32(tbl[i].name,
- tbl[i].mode, dbg,
- base + tbl[i].off,
- wil);
+ wil_debugfs_create_iomem_x32(tbl[i].name, tbl[i].mode,
+ dbg, base + tbl[i].off,
+ wil);
break;
case doff_u8:
- f = debugfs_create_u8(tbl[i].name, tbl[i].mode, dbg,
- base + tbl[i].off);
+ debugfs_create_u8(tbl[i].name, tbl[i].mode, dbg,
+ base + tbl[i].off);
break;
- default:
- f = ERR_PTR(-EINVAL);
}
- if (IS_ERR_OR_NULL(f))
- wil_err(wil, "Create file \"%s\": err %ld\n",
- tbl[i].name, PTR_ERR(f));
}
}
@@ -499,19 +477,14 @@ static const struct dbg_off isr_off[] = {
{},
};
-static int wil6210_debugfs_create_ISR(struct wil6210_priv *wil,
- const char *name,
- struct dentry *parent, u32 off)
+static void wil6210_debugfs_create_ISR(struct wil6210_priv *wil,
+ const char *name, struct dentry *parent,
+ u32 off)
{
struct dentry *d = debugfs_create_dir(name, parent);
- if (IS_ERR_OR_NULL(d))
- return -ENODEV;
-
wil6210_debugfs_init_offset(wil, d, (void * __force)wil->csr + off,
isr_off);
-
- return 0;
}
static const struct dbg_off pseudo_isr_off[] = {
@@ -521,18 +494,13 @@ static const struct dbg_off pseudo_isr_off[] = {
{},
};
-static int wil6210_debugfs_create_pseudo_ISR(struct wil6210_priv *wil,
- struct dentry *parent)
+static void wil6210_debugfs_create_pseudo_ISR(struct wil6210_priv *wil,
+ struct dentry *parent)
{
struct dentry *d = debugfs_create_dir("PSEUDO_ISR", parent);
- if (IS_ERR_OR_NULL(d))
- return -ENODEV;
-
wil6210_debugfs_init_offset(wil, d, (void * __force)wil->csr,
pseudo_isr_off);
-
- return 0;
}
static const struct dbg_off lgc_itr_cnt_off[] = {
@@ -580,13 +548,9 @@ static int wil6210_debugfs_create_ITR_CNT(struct wil6210_priv *wil,
struct dentry *d, *dtx, *drx;
d = debugfs_create_dir("ITR_CNT", parent);
- if (IS_ERR_OR_NULL(d))
- return -ENODEV;
dtx = debugfs_create_dir("TX", d);
drx = debugfs_create_dir("RX", d);
- if (IS_ERR_OR_NULL(dtx) || IS_ERR_OR_NULL(drx))
- return -ENODEV;
wil6210_debugfs_init_offset(wil, d, (void * __force)wil->csr,
lgc_itr_cnt_off);
--
2.22.0
^ permalink raw reply related
* [RFC PATCH v2 3/3] ath11k: register HE mesh capabilities
From: Sven Eckelmann @ 2019-06-11 18:02 UTC (permalink / raw)
To: linux-wireless; +Cc: ath11k, Sven Eckelmann
In-Reply-To: <20190611180247.19524-1-sven@narfation.org>
From: Sven Eckelmann <seckelmann@datto.com>
The capabilities for the HE mesh are generated from the capabilities
reported by the fw. But the firmware only reports the overall capabilities
and not the one which are specific for mesh. Some of them (TWT, MU UL/DL,
TB PPDU, ...) require an infrastructure setup with a main STA (AP)
controlling the operations. This is not the case for mesh and thus these
capabilities are removed from the list of capabilities.
Signed-off-by: Sven Eckelmann <seckelmann@datto.com>
---
This doesn't work currently as expected. No HE rates are used between
the two HE mesh peers:
root@OpenWrt:/# cat /sys/kernel/debug/ieee80211/phy2/netdev:mesh2/stations/00:03:7f:12:bb:97/he_capa
HE supported
MAC-CAP: 0x09 0x0d 0x08 0x0a 0x40 0x00
HTC-HE
DYNAMIC-FRAG-LEVEL-1
MAX-NUM-FRAG-MSDU-1
MIN-FRAG-SIZE-128
TF-MAC-PAD-DUR-24US
MULTI-TID-AGG-RX-QOS-1
LINK-ADAPTATION-NO-FEEDBACK
BSR
OMI-CONTROL
MAX-AMPDU-LEN-EXP-VHT-1
AMSDU-IN-AMPDU
MULTI-TID-AGG-TX-QOS-0
PHY CAP: 0x1c 0x70 0x0c 0x80 0x0d 0x43 0x81 0x1c 0x00 0x00 0x00
CHANNEL-WIDTH-SET-40MHZ-80MHZ-IN-5G
CHANNEL-WIDTH-SET-160MHZ-IN-5G
CHANNEL-WIDTH-SET-80PLUS80-MHZ-IN-5G
IEEE80211-HE-PHY-CAP1-DEVICE-CLASS-A
LDPC-CODING-IN-PAYLOAD
HY-CAP1-HE-LTF-AND-GI-FOR-HE-PPDUS-0-8US
MIDAMBLE-RX-MAX-NSTS-0
STBC-TX-UNDER-80MHZ
STBC-RX-UNDER-80MHZ
DCM-MAX-CONST-TX-NO-DCM
DCM-MAX-CONST-RX-NO-DCM
SU-BEAMFORMER
SU-BEAMFORMEE
BEAMFORMEE-MAX-STS-UNDER-7
BEAMFORMEE-MAX-STS-ABOVE-4
NUM-SND-DIM-UNDER-80MHZ-4
NUM-SND-DIM-ABOVE-80MHZ-1
NG16-SU-FEEDBACK
CODEBOOK-SIZE-42-SU
PPE-THRESHOLD-PRESENT
HE-SU-MU-PPDU-4XLTF-AND-08-US-GI
MAX-NC-4
DCM-MAX-RU-242
NOMINAL-PACKET-PADDING-0US
RX-MCS-80: 0xffaa
RX-MCS-80-0-SUPPORT-0-11
RX-MCS-80-1-SUPPORT-0-11
RX-MCS-80-2-SUPPORT-0-11
RX-MCS-80-3-SUPPORT-0-11
TX-MCS-80: 0xffaa
TX-MCS-80-0-SUPPORT-0-11
TX-MCS-80-1-SUPPORT-0-11
TX-MCS-80-2-SUPPORT-0-11
TX-MCS-80-3-SUPPORT-0-11
RX-MCS-160: 0xfffa
RX-MCS-160-0-SUPPORT-0-11
RX-MCS-160-1-SUPPORT-0-11
RX-MCS-160-2-NOT-SUPPORTED
RX-MCS-160-3-NOT-SUPPORTED
TX-MCS-160: 0xfffa
TX-MCS-160-0-SUPPORT-0-11
TX-MCS-160-1-SUPPORT-0-11
TX-MCS-160-2-NOT-SUPPORTED
TX-MCS-160-3-NOT-SUPPORTED
RX-MCS-80P80: 0xfffa
RX-MCS-80P80-0-SUPPORT-0-11
RX-MCS-80P80-1-SUPPORT-0-11
RX-MCS-80P80-2-NOT-SUPPORTED
RX-MCS-80P80-3-NOT-SUPPORTED
TX-MCS-80P80: 0xfffa
TX-MCS-80P80-0-SUPPORT-0-11
TX-MCS-80P80-1-SUPPORT-0-11
TX-MCS-80P80-2-NOT-SUPPORTED
TX-MCS-80P80-3-NOT-SUPPORTED
PPE-THRESHOLDS: 0x3b 0x1c 0xc7 0x71 0x1c 0xc7 0x71 0x1c 0xc7 0x71
root@OpenWrt:/# iw dev mesh2 station dump
Station 00:03:7f:12:bb:97 (on mesh2)
inactive time: 310 ms
rx bytes: 161064
rx packets: 1619
tx bytes: 55454
tx packets: 477
tx retries: 405
tx failed: 0
rx drop misc: 6
signal: -95 dBm
signal avg: -67 dBm
tx bitrate: 1733.3 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 4
rx bitrate: 1733.3 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 4
rx duration: 0 us
mesh llid: 0
mesh plid: 0
mesh plink: ESTAB
mesh local PS mode: ACTIVE
mesh peer PS mode: ACTIVE
mesh non-peer PS mode: ACTIVE
authorized: yes
authenticated: yes
associated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
DTIM period: 2
beacon interval:1000
connected time: 536 seconds
drivers/net/wireless/ath/ath11k/mac.c | 56 +++++++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
index 13da2e8262ba..7dcf4bb896b5 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -3274,6 +3274,7 @@ static int ath11k_mac_copy_he_cap(struct ath11k *ar,
switch (i) {
case NL80211_IFTYPE_STATION:
case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_MESH_POINT:
break;
default:
@@ -3314,6 +3315,61 @@ static int ath11k_mac_copy_he_cap(struct ath11k *ar,
he_cap_elem->phy_cap_info[9] |=
IEEE80211_HE_PHY_CAP9_TX_1024_QAM_LESS_THAN_242_TONE_RU;
break;
+ case NL80211_IFTYPE_MESH_POINT:
+ he_cap_elem->mac_cap_info[0] &=
+ ~(IEEE80211_HE_MAC_CAP0_TWT_RES |
+ IEEE80211_HE_MAC_CAP0_TWT_REQ);
+ he_cap_elem->mac_cap_info[2] &=
+ ~(IEEE80211_HE_MAC_CAP2_TRS |
+ IEEE80211_HE_MAC_CAP2_BCAST_TWT |
+ IEEE80211_HE_MAC_CAP2_MU_CASCADING);
+ he_cap_elem->mac_cap_info[3] &=
+ ~(IEEE80211_HE_MAC_CAP3_FLEX_TWT_SCHED |
+ IEEE80211_HE_MAC_CAP2_BCAST_TWT |
+ IEEE80211_HE_MAC_CAP2_MU_CASCADING);
+ he_cap_elem->mac_cap_info[4] &=
+ ~(IEEE80211_HE_MAC_CAP4_BSRP_BQRP_A_MPDU_AGG |
+ IEEE80211_HE_MAC_CAP4_BQR);
+ he_cap_elem->mac_cap_info[5] &=
+ ~(IEEE80211_HE_MAC_CAP5_SUBCHAN_SELECVITE_TRANSMISSION |
+ IEEE80211_HE_MAC_CAP5_UL_2x996_TONE_RU |
+ IEEE80211_HE_MAC_CAP5_PUNCTURED_SOUNDING |
+ IEEE80211_HE_MAC_CAP5_HT_VHT_TRIG_FRAME_RX);
+
+ he_cap_elem->phy_cap_info[2] &=
+ ~(IEEE80211_HE_PHY_CAP2_UL_MU_FULL_MU_MIMO |
+ IEEE80211_HE_PHY_CAP2_UL_MU_PARTIAL_MU_MIMO);
+ he_cap_elem->phy_cap_info[3] &=
+ ~(IEEE80211_HE_PHY_CAP3_RX_HE_MU_PPDU_FROM_NON_AP_STA |
+ IEEE80211_HE_PHY_CAP3_DCM_MAX_CONST_TX_MASK |
+ IEEE80211_HE_PHY_CAP3_DCM_MAX_CONST_RX_MASK);
+ he_cap_elem->phy_cap_info[4] &=
+ ~IEEE80211_HE_PHY_CAP4_MU_BEAMFORMER;
+ he_cap_elem->phy_cap_info[5] &=
+ ~IEEE80211_HE_PHY_CAP5_NG16_MU_FEEDBACK;
+ he_cap_elem->phy_cap_info[6] &=
+ ~(IEEE80211_HE_PHY_CAP6_CODEBOOK_SIZE_75_MU |
+ IEEE80211_HE_PHY_CAP6_TRIG_MU_BEAMFORMER_FB |
+ IEEE80211_HE_PHY_CAP6_TRIG_CQI_FB |
+ IEEE80211_HE_PHY_CAP6_PARTIAL_BANDWIDTH_DL_MUMIMO);
+ he_cap_elem->phy_cap_info[7] &=
+ ~(IEEE80211_HE_PHY_CAP7_SRP_BASED_SR |
+ IEEE80211_HE_PHY_CAP7_POWER_BOOST_FACTOR_AR |
+ IEEE80211_HE_PHY_CAP7_STBC_TX_ABOVE_80MHZ |
+ IEEE80211_HE_PHY_CAP7_STBC_RX_ABOVE_80MHZ);
+ he_cap_elem->phy_cap_info[8] &=
+ ~(IEEE80211_HE_PHY_CAP8_HE_ER_SU_PPDU_4XLTF_AND_08_US_GI |
+ IEEE80211_HE_PHY_CAP8_20MHZ_IN_40MHZ_HE_PPDU_IN_2G |
+ IEEE80211_HE_PHY_CAP8_20MHZ_IN_160MHZ_HE_PPDU |
+ IEEE80211_HE_PHY_CAP8_80MHZ_IN_160MHZ_HE_PPDU);
+ he_cap_elem->phy_cap_info[9] &=
+ ~(IEEE80211_HE_PHY_CAP9_LONGER_THAN_16_SIGB_OFDM_SYM |
+ IEEE80211_HE_PHY_CAP9_NON_TRIGGERED_CQI_FEEDBACK |
+ IEEE80211_HE_PHY_CAP9_RX_1024_QAM_LESS_THAN_242_TONE_RU |
+ IEEE80211_HE_PHY_CAP9_TX_1024_QAM_LESS_THAN_242_TONE_RU |
+ IEEE80211_HE_PHY_CAP9_RX_FULL_BW_SU_USING_MU_WITH_COMP_SIGB |
+ IEEE80211_HE_PHY_CAP9_RX_FULL_BW_SU_USING_MU_WITH_NON_COMP_SIGB);
+ break;
}
he_cap->he_mcs_nss_supp.rx_mcs_80 =
--
2.20.1
^ permalink raw reply related
* [RFC PATCH v2 2/3] mac80211: implement HE support for mesh
From: Sven Eckelmann @ 2019-06-11 18:02 UTC (permalink / raw)
To: linux-wireless; +Cc: ath11k, Sven Eckelmann
In-Reply-To: <20190611180247.19524-1-sven@narfation.org>
From: Sven Eckelmann <seckelmann@datto.com>
Implement the basics required for supporting high efficiency with mesh:
include HE information elements in beacons, probe responses, and peering
action frames, and check for compatible HE configurations when peering.
Signed-off-by: Sven Eckelmann <seckelmann@datto.com>
---
include/net/cfg80211.h | 19 ++++++++++++
net/mac80211/ieee80211_i.h | 2 ++
net/mac80211/mesh.c | 61 ++++++++++++++++++++++++++++++++++++++
net/mac80211/mesh.h | 4 +++
net/mac80211/mesh_plink.c | 11 ++++++-
net/mac80211/util.c | 52 ++++++++++++++++++++++++++++++++
6 files changed, 148 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 13bfeb712d36..9caa0ca5020d 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -399,6 +399,25 @@ ieee80211_get_he_sta_cap(const struct ieee80211_supported_band *sband)
return NULL;
}
+/**
+ * ieee80211_get_he_mesh_cap - return HE capabilities for an sband's mesh STA
+ * @sband: the sband to search for the mesh STA on
+ *
+ * Return: pointer to the struct ieee80211_sta_he_cap, or NULL is none found
+ */
+static inline const struct ieee80211_sta_he_cap *
+ieee80211_get_he_mesh_cap(const struct ieee80211_supported_band *sband)
+{
+ const struct ieee80211_sband_iftype_data *data =
+ ieee80211_get_sband_iftype_data(sband,
+ NL80211_IFTYPE_MESH_POINT);
+
+ if (data && data->he_cap.has_he)
+ return &data->he_cap;
+
+ return NULL;
+}
+
/**
* wiphy_read_of_freq_limits - read frequency limits from device tree
*
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 159eb9506bdc..8a3b74b3f356 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -2130,9 +2130,11 @@ u8 *ieee80211_ie_build_vht_cap(u8 *pos, struct ieee80211_sta_vht_cap *vht_cap,
u32 cap);
u8 *ieee80211_ie_build_vht_oper(u8 *pos, struct ieee80211_sta_vht_cap *vht_cap,
const struct cfg80211_chan_def *chandef);
+u8 ieee80211_ie_len_he_cap(struct ieee80211_sub_if_data *sdata);
u8 *ieee80211_ie_build_he_cap(u8 *pos,
const struct ieee80211_sta_he_cap *he_cap,
u8 *end);
+u8 *ieee80211_ie_build_he_oper(u8 *pos);
int ieee80211_parse_bitrates(struct cfg80211_chan_def *chandef,
const struct ieee80211_supported_band *sband,
const u8 *srates, int srates_len, u32 *rates);
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 766e5e5bab8a..47ef885c4060 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -535,6 +535,61 @@ int mesh_add_vht_oper_ie(struct ieee80211_sub_if_data *sdata,
return 0;
}
+int mesh_add_he_cap_ie(struct ieee80211_sub_if_data *sdata,
+ struct sk_buff *skb, u8 ie_len)
+{
+ const struct ieee80211_sta_he_cap *he_cap;
+ struct ieee80211_supported_band *sband;
+ u8 *pos;
+
+ sband = ieee80211_get_sband(sdata);
+ if (!sband)
+ return -EINVAL;
+
+ he_cap = ieee80211_get_he_mesh_cap(sband);
+
+ if (!he_cap ||
+ sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20_NOHT ||
+ sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_5 ||
+ sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_10)
+ return 0;
+
+ if (skb_tailroom(skb) < ie_len)
+ return -ENOMEM;
+
+ pos = skb_put(skb, ie_len);
+ ieee80211_ie_build_he_cap(pos, he_cap, pos + ie_len);
+
+ return 0;
+}
+
+int mesh_add_he_oper_ie(struct ieee80211_sub_if_data *sdata,
+ struct sk_buff *skb)
+{
+ const struct ieee80211_sta_he_cap *he_cap;
+ struct ieee80211_supported_band *sband;
+ u8 *pos;
+
+ sband = ieee80211_get_sband(sdata);
+ if (!sband)
+ return -EINVAL;
+
+ he_cap = ieee80211_get_he_mesh_cap(sband);
+ if (!he_cap ||
+ sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20_NOHT ||
+ sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_5 ||
+ sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_10)
+ return 0;
+
+ if (skb_tailroom(skb) < 2 + 1 + sizeof(struct ieee80211_he_operation))
+ return -ENOMEM;
+
+ pos = skb_put(skb, 2 + 1 + sizeof(struct ieee80211_he_operation));
+ ieee80211_ie_build_he_oper(pos);
+
+ return 0;
+}
+
static void ieee80211_mesh_path_timer(struct timer_list *t)
{
struct ieee80211_sub_if_data *sdata =
@@ -680,6 +735,7 @@ ieee80211_mesh_build_beacon(struct ieee80211_if_mesh *ifmsh)
struct ieee80211_chanctx_conf *chanctx_conf;
struct mesh_csa_settings *csa;
enum nl80211_band band;
+ u8 ie_len_he_cap;
u8 *pos;
struct ieee80211_sub_if_data *sdata;
int hdr_len = offsetofend(struct ieee80211_mgmt, u.beacon);
@@ -690,6 +746,7 @@ ieee80211_mesh_build_beacon(struct ieee80211_if_mesh *ifmsh)
band = chanctx_conf->def.chan->band;
rcu_read_unlock();
+ ie_len_he_cap = ieee80211_ie_len_he_cap(sdata);
head_len = hdr_len +
2 + /* NULL SSID */
/* Channel Switch Announcement */
@@ -709,6 +766,8 @@ ieee80211_mesh_build_beacon(struct ieee80211_if_mesh *ifmsh)
2 + sizeof(__le16) + /* awake window */
2 + sizeof(struct ieee80211_vht_cap) +
2 + sizeof(struct ieee80211_vht_operation) +
+ ie_len_he_cap +
+ 2 + 1 + sizeof(struct ieee80211_he_operation) +
ifmsh->ie_len;
bcn = kzalloc(sizeof(*bcn) + head_len + tail_len, GFP_KERNEL);
@@ -826,6 +885,8 @@ ieee80211_mesh_build_beacon(struct ieee80211_if_mesh *ifmsh)
mesh_add_awake_window_ie(sdata, skb) ||
mesh_add_vht_cap_ie(sdata, skb) ||
mesh_add_vht_oper_ie(sdata, skb) ||
+ mesh_add_he_cap_ie(sdata, skb, ie_len_he_cap) ||
+ mesh_add_he_oper_ie(sdata, skb) ||
mesh_add_vendor_ies(sdata, skb))
goto out_free;
diff --git a/net/mac80211/mesh.h b/net/mac80211/mesh.h
index 574c3891c4b2..af1d9154b255 100644
--- a/net/mac80211/mesh.h
+++ b/net/mac80211/mesh.h
@@ -221,6 +221,10 @@ int mesh_add_vht_cap_ie(struct ieee80211_sub_if_data *sdata,
struct sk_buff *skb);
int mesh_add_vht_oper_ie(struct ieee80211_sub_if_data *sdata,
struct sk_buff *skb);
+int mesh_add_he_cap_ie(struct ieee80211_sub_if_data *sdata,
+ struct sk_buff *skb, u8 ie_len);
+int mesh_add_he_oper_ie(struct ieee80211_sub_if_data *sdata,
+ struct sk_buff *skb);
void mesh_rmc_free(struct ieee80211_sub_if_data *sdata);
int mesh_rmc_init(struct ieee80211_sub_if_data *sdata);
void ieee80211s_init(void);
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 8afd0ece94c9..e18e433fde29 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -221,9 +221,11 @@ static int mesh_plink_frame_tx(struct ieee80211_sub_if_data *sdata,
bool include_plid = false;
u16 peering_proto = 0;
u8 *pos, ie_len = 4;
+ u8 ie_len_he_cap;
int hdr_len = offsetofend(struct ieee80211_mgmt, u.action.u.self_prot);
int err = -ENOMEM;
+ ie_len_he_cap = ieee80211_ie_len_he_cap(sdata);
skb = dev_alloc_skb(local->tx_headroom +
hdr_len +
2 + /* capability info */
@@ -236,6 +238,8 @@ static int mesh_plink_frame_tx(struct ieee80211_sub_if_data *sdata,
2 + sizeof(struct ieee80211_ht_operation) +
2 + sizeof(struct ieee80211_vht_cap) +
2 + sizeof(struct ieee80211_vht_operation) +
+ ie_len_he_cap +
+ 2 + 1 + sizeof(struct ieee80211_he_operation) +
2 + 8 + /* peering IE */
sdata->u.mesh.ie_len);
if (!skb)
@@ -324,7 +328,9 @@ static int mesh_plink_frame_tx(struct ieee80211_sub_if_data *sdata,
if (mesh_add_ht_cap_ie(sdata, skb) ||
mesh_add_ht_oper_ie(sdata, skb) ||
mesh_add_vht_cap_ie(sdata, skb) ||
- mesh_add_vht_oper_ie(sdata, skb))
+ mesh_add_vht_oper_ie(sdata, skb) ||
+ mesh_add_he_cap_ie(sdata, skb, ie_len_he_cap) ||
+ mesh_add_he_oper_ie(sdata, skb))
goto free;
}
@@ -436,6 +442,9 @@ static void mesh_sta_info_init(struct ieee80211_sub_if_data *sdata,
ieee80211_vht_cap_ie_to_sta_vht_cap(sdata, sband,
elems->vht_cap_elem, sta);
+ ieee80211_he_cap_ie_to_sta_he_cap(sdata, sband, elems->he_cap,
+ elems->he_cap_len, sta);
+
if (bw != sta->sta.bandwidth)
changed |= IEEE80211_RC_BW_CHANGED;
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 4c1655972565..d86925438b5f 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -2663,6 +2663,30 @@ u8 *ieee80211_ie_build_vht_cap(u8 *pos, struct ieee80211_sta_vht_cap *vht_cap,
return pos;
}
+u8 ieee80211_ie_len_he_cap(struct ieee80211_sub_if_data *sdata)
+{
+ const struct ieee80211_sta_he_cap *he_cap;
+ struct ieee80211_supported_band *sband;
+ u8 ie_len;
+ u8 n;
+
+ sband = ieee80211_get_sband(sdata);
+ if (!sband)
+ return 0;
+
+ he_cap = ieee80211_get_he_mesh_cap(sband);
+ if (!he_cap)
+ return 0;
+
+ n = ieee80211_he_mcs_nss_size(&he_cap->he_cap_elem);
+ ie_len = 2 + 1 +
+ sizeof(he_cap->he_cap_elem) + n +
+ ieee80211_he_ppe_size(he_cap->ppe_thres[0],
+ he_cap->he_cap_elem.phy_cap_info);
+
+ return ie_len;
+}
+
u8 *ieee80211_ie_build_he_cap(u8 *pos,
const struct ieee80211_sta_he_cap *he_cap,
u8 *end)
@@ -2852,6 +2876,34 @@ u8 *ieee80211_ie_build_vht_oper(u8 *pos, struct ieee80211_sta_vht_cap *vht_cap,
return pos + sizeof(struct ieee80211_vht_operation);
}
+u8 *ieee80211_ie_build_he_oper(u8 *pos)
+{
+ struct ieee80211_he_operation *he_oper;
+ u32 he_oper_params;
+
+ *pos++ = WLAN_EID_EXTENSION;
+ *pos++ = 1 + sizeof(struct ieee80211_he_operation);
+ *pos++ = WLAN_EID_EXT_HE_OPERATION;
+
+ he_oper_params = 0;
+ he_oper_params |= u32_encode_bits(1023, /* disabled */
+ IEEE80211_HE_OPERATION_RTS_THRESHOLD_MASK);
+ he_oper_params |= u32_encode_bits(1,
+ IEEE80211_HE_OPERATION_ER_SU_DISABLE);
+ he_oper_params |= u32_encode_bits(1,
+ IEEE80211_HE_OPERATION_BSS_COLOR_DISABLED);
+
+ he_oper = (struct ieee80211_he_operation *)pos;
+ he_oper->he_oper_params = cpu_to_le32(he_oper_params);
+
+ /* don't require special HE peer rates */
+ he_oper->he_mcs_nss_set = cpu_to_le16(0xffff);
+
+ /* TODO add VHT operational and 6GHz operational subelement? */
+
+ return pos + sizeof(struct ieee80211_vht_operation);
+}
+
bool ieee80211_chandef_ht_oper(const struct ieee80211_ht_operation *ht_oper,
struct cfg80211_chan_def *chandef)
{
--
2.20.1
^ permalink raw reply related
* [RFC PATCH v2 1/3] mac80211_hwsim: Register support for HE meshpoint
From: Sven Eckelmann @ 2019-06-11 18:02 UTC (permalink / raw)
To: linux-wireless; +Cc: ath11k, Sven Eckelmann
In-Reply-To: <20190611180247.19524-1-sven@narfation.org>
From: Sven Eckelmann <seckelmann@datto.com>
Some features of 802.11ax without central organizing (AP) STA can also be
used in mesh mode. hwsim can be used to assist initial development of these
features without having access to HW.
Signed-off-by: Sven Eckelmann <seckelmann@datto.com>
---
drivers/net/wireless/mac80211_hwsim.c | 283 +++++++++++++++++---------
1 file changed, 189 insertions(+), 94 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 524eb5805995..e4d542f08b7c 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -2501,116 +2501,211 @@ static void hwsim_mcast_new_radio(int id, struct genl_info *info,
nlmsg_free(mcast_skb);
}
-static const struct ieee80211_sband_iftype_data he_capa_2ghz = {
- /* TODO: should we support other types, e.g., P2P?*/
- .types_mask = BIT(NL80211_IFTYPE_STATION) | BIT(NL80211_IFTYPE_AP),
- .he_cap = {
- .has_he = true,
- .he_cap_elem = {
- .mac_cap_info[0] =
- IEEE80211_HE_MAC_CAP0_HTC_HE,
- .mac_cap_info[1] =
- IEEE80211_HE_MAC_CAP1_TF_MAC_PAD_DUR_16US |
- IEEE80211_HE_MAC_CAP1_MULTI_TID_AGG_RX_QOS_8,
- .mac_cap_info[2] =
- IEEE80211_HE_MAC_CAP2_BSR |
- IEEE80211_HE_MAC_CAP2_MU_CASCADING |
- IEEE80211_HE_MAC_CAP2_ACK_EN,
- .mac_cap_info[3] =
- IEEE80211_HE_MAC_CAP3_OMI_CONTROL |
- IEEE80211_HE_MAC_CAP3_MAX_AMPDU_LEN_EXP_VHT_2,
- .mac_cap_info[4] = IEEE80211_HE_MAC_CAP4_AMDSU_IN_AMPDU,
- .phy_cap_info[1] =
- IEEE80211_HE_PHY_CAP1_PREAMBLE_PUNC_RX_MASK |
- IEEE80211_HE_PHY_CAP1_DEVICE_CLASS_A |
- IEEE80211_HE_PHY_CAP1_LDPC_CODING_IN_PAYLOAD |
- IEEE80211_HE_PHY_CAP1_MIDAMBLE_RX_TX_MAX_NSTS,
- .phy_cap_info[2] =
- IEEE80211_HE_PHY_CAP2_NDP_4x_LTF_AND_3_2US |
- IEEE80211_HE_PHY_CAP2_STBC_TX_UNDER_80MHZ |
- IEEE80211_HE_PHY_CAP2_STBC_RX_UNDER_80MHZ |
- IEEE80211_HE_PHY_CAP2_UL_MU_FULL_MU_MIMO |
- IEEE80211_HE_PHY_CAP2_UL_MU_PARTIAL_MU_MIMO,
-
- /* Leave all the other PHY capability bytes unset, as
- * DCM, beam forming, RU and PPE threshold information
- * are not supported
- */
+static const struct ieee80211_sband_iftype_data he_capa_2ghz[] = {
+ {
+ /* TODO: should we support other types, e.g., P2P?*/
+ .types_mask = BIT(NL80211_IFTYPE_STATION) |
+ BIT(NL80211_IFTYPE_AP),
+ .he_cap = {
+ .has_he = true,
+ .he_cap_elem = {
+ .mac_cap_info[0] =
+ IEEE80211_HE_MAC_CAP0_HTC_HE,
+ .mac_cap_info[1] =
+ IEEE80211_HE_MAC_CAP1_TF_MAC_PAD_DUR_16US |
+ IEEE80211_HE_MAC_CAP1_MULTI_TID_AGG_RX_QOS_8,
+ .mac_cap_info[2] =
+ IEEE80211_HE_MAC_CAP2_BSR |
+ IEEE80211_HE_MAC_CAP2_MU_CASCADING |
+ IEEE80211_HE_MAC_CAP2_ACK_EN,
+ .mac_cap_info[3] =
+ IEEE80211_HE_MAC_CAP3_OMI_CONTROL |
+ IEEE80211_HE_MAC_CAP3_MAX_AMPDU_LEN_EXP_VHT_2,
+ .mac_cap_info[4] = IEEE80211_HE_MAC_CAP4_AMDSU_IN_AMPDU,
+ .phy_cap_info[1] =
+ IEEE80211_HE_PHY_CAP1_PREAMBLE_PUNC_RX_MASK |
+ IEEE80211_HE_PHY_CAP1_DEVICE_CLASS_A |
+ IEEE80211_HE_PHY_CAP1_LDPC_CODING_IN_PAYLOAD |
+ IEEE80211_HE_PHY_CAP1_MIDAMBLE_RX_TX_MAX_NSTS,
+ .phy_cap_info[2] =
+ IEEE80211_HE_PHY_CAP2_NDP_4x_LTF_AND_3_2US |
+ IEEE80211_HE_PHY_CAP2_STBC_TX_UNDER_80MHZ |
+ IEEE80211_HE_PHY_CAP2_STBC_RX_UNDER_80MHZ |
+ IEEE80211_HE_PHY_CAP2_UL_MU_FULL_MU_MIMO |
+ IEEE80211_HE_PHY_CAP2_UL_MU_PARTIAL_MU_MIMO,
+
+ /* Leave all the other PHY capability bytes
+ * unset, as DCM, beam forming, RU and PPE
+ * threshold information are not supported
+ */
+ },
+ .he_mcs_nss_supp = {
+ .rx_mcs_80 = cpu_to_le16(0xfffa),
+ .tx_mcs_80 = cpu_to_le16(0xfffa),
+ .rx_mcs_160 = cpu_to_le16(0xffff),
+ .tx_mcs_160 = cpu_to_le16(0xffff),
+ .rx_mcs_80p80 = cpu_to_le16(0xffff),
+ .tx_mcs_80p80 = cpu_to_le16(0xffff),
+ },
},
- .he_mcs_nss_supp = {
- .rx_mcs_80 = cpu_to_le16(0xfffa),
- .tx_mcs_80 = cpu_to_le16(0xfffa),
- .rx_mcs_160 = cpu_to_le16(0xffff),
- .tx_mcs_160 = cpu_to_le16(0xffff),
- .rx_mcs_80p80 = cpu_to_le16(0xffff),
- .tx_mcs_80p80 = cpu_to_le16(0xffff),
+ },
+#ifdef CONFIG_MAC80211_MESH
+ {
+ /* TODO: should we support other types, e.g., IBSS?*/
+ .types_mask = BIT(NL80211_IFTYPE_MESH_POINT),
+ .he_cap = {
+ .has_he = true,
+ .he_cap_elem = {
+ .mac_cap_info[0] =
+ IEEE80211_HE_MAC_CAP0_HTC_HE,
+ .mac_cap_info[1] =
+ IEEE80211_HE_MAC_CAP1_MULTI_TID_AGG_RX_QOS_8,
+ .mac_cap_info[2] =
+ IEEE80211_HE_MAC_CAP2_ACK_EN,
+ .mac_cap_info[3] =
+ IEEE80211_HE_MAC_CAP3_OMI_CONTROL |
+ IEEE80211_HE_MAC_CAP3_MAX_AMPDU_LEN_EXP_VHT_2,
+ .mac_cap_info[4] = IEEE80211_HE_MAC_CAP4_AMDSU_IN_AMPDU,
+ .phy_cap_info[1] =
+ IEEE80211_HE_PHY_CAP1_PREAMBLE_PUNC_RX_MASK |
+ IEEE80211_HE_PHY_CAP1_DEVICE_CLASS_A |
+ IEEE80211_HE_PHY_CAP1_LDPC_CODING_IN_PAYLOAD |
+ IEEE80211_HE_PHY_CAP1_MIDAMBLE_RX_TX_MAX_NSTS,
+ .phy_cap_info[2] = 0,
+
+ /* Leave all the other PHY capability bytes
+ * unset, as DCM, beam forming, RU and PPE
+ * threshold information are not supported
+ */
+ },
+ .he_mcs_nss_supp = {
+ .rx_mcs_80 = cpu_to_le16(0xfffa),
+ .tx_mcs_80 = cpu_to_le16(0xfffa),
+ .rx_mcs_160 = cpu_to_le16(0xffff),
+ .tx_mcs_160 = cpu_to_le16(0xffff),
+ .rx_mcs_80p80 = cpu_to_le16(0xffff),
+ .tx_mcs_80p80 = cpu_to_le16(0xffff),
+ },
},
},
+#endif
};
-static const struct ieee80211_sband_iftype_data he_capa_5ghz = {
- /* TODO: should we support other types, e.g., P2P?*/
- .types_mask = BIT(NL80211_IFTYPE_STATION) | BIT(NL80211_IFTYPE_AP),
- .he_cap = {
- .has_he = true,
- .he_cap_elem = {
- .mac_cap_info[0] =
- IEEE80211_HE_MAC_CAP0_HTC_HE,
- .mac_cap_info[1] =
- IEEE80211_HE_MAC_CAP1_TF_MAC_PAD_DUR_16US |
- IEEE80211_HE_MAC_CAP1_MULTI_TID_AGG_RX_QOS_8,
- .mac_cap_info[2] =
- IEEE80211_HE_MAC_CAP2_BSR |
- IEEE80211_HE_MAC_CAP2_MU_CASCADING |
- IEEE80211_HE_MAC_CAP2_ACK_EN,
- .mac_cap_info[3] =
- IEEE80211_HE_MAC_CAP3_OMI_CONTROL |
- IEEE80211_HE_MAC_CAP3_MAX_AMPDU_LEN_EXP_VHT_2,
- .mac_cap_info[4] = IEEE80211_HE_MAC_CAP4_AMDSU_IN_AMPDU,
- .phy_cap_info[0] =
- IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_40MHZ_80MHZ_IN_5G |
- IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_160MHZ_IN_5G |
- IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_80PLUS80_MHZ_IN_5G,
- .phy_cap_info[1] =
- IEEE80211_HE_PHY_CAP1_PREAMBLE_PUNC_RX_MASK |
- IEEE80211_HE_PHY_CAP1_DEVICE_CLASS_A |
- IEEE80211_HE_PHY_CAP1_LDPC_CODING_IN_PAYLOAD |
- IEEE80211_HE_PHY_CAP1_MIDAMBLE_RX_TX_MAX_NSTS,
- .phy_cap_info[2] =
- IEEE80211_HE_PHY_CAP2_NDP_4x_LTF_AND_3_2US |
- IEEE80211_HE_PHY_CAP2_STBC_TX_UNDER_80MHZ |
- IEEE80211_HE_PHY_CAP2_STBC_RX_UNDER_80MHZ |
- IEEE80211_HE_PHY_CAP2_UL_MU_FULL_MU_MIMO |
- IEEE80211_HE_PHY_CAP2_UL_MU_PARTIAL_MU_MIMO,
-
- /* Leave all the other PHY capability bytes unset, as
- * DCM, beam forming, RU and PPE threshold information
- * are not supported
- */
+static const struct ieee80211_sband_iftype_data he_capa_5ghz[] = {
+ {
+ /* TODO: should we support other types, e.g., P2P?*/
+ .types_mask = BIT(NL80211_IFTYPE_STATION) |
+ BIT(NL80211_IFTYPE_AP),
+ .he_cap = {
+ .has_he = true,
+ .he_cap_elem = {
+ .mac_cap_info[0] =
+ IEEE80211_HE_MAC_CAP0_HTC_HE,
+ .mac_cap_info[1] =
+ IEEE80211_HE_MAC_CAP1_TF_MAC_PAD_DUR_16US |
+ IEEE80211_HE_MAC_CAP1_MULTI_TID_AGG_RX_QOS_8,
+ .mac_cap_info[2] =
+ IEEE80211_HE_MAC_CAP2_BSR |
+ IEEE80211_HE_MAC_CAP2_MU_CASCADING |
+ IEEE80211_HE_MAC_CAP2_ACK_EN,
+ .mac_cap_info[3] =
+ IEEE80211_HE_MAC_CAP3_OMI_CONTROL |
+ IEEE80211_HE_MAC_CAP3_MAX_AMPDU_LEN_EXP_VHT_2,
+ .mac_cap_info[4] = IEEE80211_HE_MAC_CAP4_AMDSU_IN_AMPDU,
+ .phy_cap_info[0] =
+ IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_40MHZ_80MHZ_IN_5G |
+ IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_160MHZ_IN_5G |
+ IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_80PLUS80_MHZ_IN_5G,
+ .phy_cap_info[1] =
+ IEEE80211_HE_PHY_CAP1_PREAMBLE_PUNC_RX_MASK |
+ IEEE80211_HE_PHY_CAP1_DEVICE_CLASS_A |
+ IEEE80211_HE_PHY_CAP1_LDPC_CODING_IN_PAYLOAD |
+ IEEE80211_HE_PHY_CAP1_MIDAMBLE_RX_TX_MAX_NSTS,
+ .phy_cap_info[2] =
+ IEEE80211_HE_PHY_CAP2_NDP_4x_LTF_AND_3_2US |
+ IEEE80211_HE_PHY_CAP2_STBC_TX_UNDER_80MHZ |
+ IEEE80211_HE_PHY_CAP2_STBC_RX_UNDER_80MHZ |
+ IEEE80211_HE_PHY_CAP2_UL_MU_FULL_MU_MIMO |
+ IEEE80211_HE_PHY_CAP2_UL_MU_PARTIAL_MU_MIMO,
+
+ /* Leave all the other PHY capability bytes
+ * unset, as DCM, beam forming, RU and PPE
+ * threshold information are not supported
+ */
+ },
+ .he_mcs_nss_supp = {
+ .rx_mcs_80 = cpu_to_le16(0xfffa),
+ .tx_mcs_80 = cpu_to_le16(0xfffa),
+ .rx_mcs_160 = cpu_to_le16(0xfffa),
+ .tx_mcs_160 = cpu_to_le16(0xfffa),
+ .rx_mcs_80p80 = cpu_to_le16(0xfffa),
+ .tx_mcs_80p80 = cpu_to_le16(0xfffa),
+ },
},
- .he_mcs_nss_supp = {
- .rx_mcs_80 = cpu_to_le16(0xfffa),
- .tx_mcs_80 = cpu_to_le16(0xfffa),
- .rx_mcs_160 = cpu_to_le16(0xfffa),
- .tx_mcs_160 = cpu_to_le16(0xfffa),
- .rx_mcs_80p80 = cpu_to_le16(0xfffa),
- .tx_mcs_80p80 = cpu_to_le16(0xfffa),
+ },
+#ifdef CONFIG_MAC80211_MESH
+ {
+ /* TODO: should we support other types, e.g., IBSS?*/
+ .types_mask = BIT(NL80211_IFTYPE_MESH_POINT),
+ .he_cap = {
+ .has_he = true,
+ .he_cap_elem = {
+ .mac_cap_info[0] =
+ IEEE80211_HE_MAC_CAP0_HTC_HE,
+ .mac_cap_info[1] =
+ IEEE80211_HE_MAC_CAP1_MULTI_TID_AGG_RX_QOS_8,
+ .mac_cap_info[2] =
+ IEEE80211_HE_MAC_CAP2_ACK_EN,
+ .mac_cap_info[3] =
+ IEEE80211_HE_MAC_CAP3_OMI_CONTROL |
+ IEEE80211_HE_MAC_CAP3_MAX_AMPDU_LEN_EXP_VHT_2,
+ .mac_cap_info[4] = IEEE80211_HE_MAC_CAP4_AMDSU_IN_AMPDU,
+ .phy_cap_info[0] =
+ IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_40MHZ_80MHZ_IN_5G |
+ IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_160MHZ_IN_5G |
+ IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_80PLUS80_MHZ_IN_5G,
+ .phy_cap_info[1] =
+ IEEE80211_HE_PHY_CAP1_PREAMBLE_PUNC_RX_MASK |
+ IEEE80211_HE_PHY_CAP1_DEVICE_CLASS_A |
+ IEEE80211_HE_PHY_CAP1_LDPC_CODING_IN_PAYLOAD |
+ IEEE80211_HE_PHY_CAP1_MIDAMBLE_RX_TX_MAX_NSTS,
+ .phy_cap_info[2] = 0,
+
+ /* Leave all the other PHY capability bytes
+ * unset, as DCM, beam forming, RU and PPE
+ * threshold information are not supported
+ */
+ },
+ .he_mcs_nss_supp = {
+ .rx_mcs_80 = cpu_to_le16(0xfffa),
+ .tx_mcs_80 = cpu_to_le16(0xfffa),
+ .rx_mcs_160 = cpu_to_le16(0xfffa),
+ .tx_mcs_160 = cpu_to_le16(0xfffa),
+ .rx_mcs_80p80 = cpu_to_le16(0xfffa),
+ .tx_mcs_80p80 = cpu_to_le16(0xfffa),
+ },
},
},
+#endif
};
static void mac80211_hswim_he_capab(struct ieee80211_supported_band *sband)
{
- if (sband->band == NL80211_BAND_2GHZ)
+ u16 n_iftype_data;
+
+ if (sband->band == NL80211_BAND_2GHZ) {
+ n_iftype_data = ARRAY_SIZE(he_capa_2ghz);
sband->iftype_data =
- (struct ieee80211_sband_iftype_data *)&he_capa_2ghz;
- else if (sband->band == NL80211_BAND_5GHZ)
+ (struct ieee80211_sband_iftype_data *)he_capa_2ghz;
+ } else if (sband->band == NL80211_BAND_5GHZ) {
+ n_iftype_data = ARRAY_SIZE(he_capa_5ghz);
sband->iftype_data =
- (struct ieee80211_sband_iftype_data *)&he_capa_5ghz;
- else
+ (struct ieee80211_sband_iftype_data *)he_capa_5ghz;
+ } else {
return;
+ }
- sband->n_iftype_data = 1;
+ sband->n_iftype_data = n_iftype_data;
}
#ifdef CONFIG_MAC80211_MESH
--
2.20.1
^ permalink raw reply related
* [RFC PATCH v2 0/3] mac80211/ath11k: HE mesh support
From: Sven Eckelmann @ 2019-06-11 18:02 UTC (permalink / raw)
To: linux-wireless; +Cc: ath11k, Sven Eckelmann
Hi,
Some features of 802.11ax without central organizing (AP) STA can also be
used in mesh mode. The main goal is to get this working for ath11k. But
there are various problems at the moment with the firmware. I hangs
from time to time during assoc (especially when using HE) or just doesn't
enable HE rates when communicating with peers. Even when the peer was
successfully detected as HE capable by the upper layers:
root@OpenWrt:/# cat /sys/kernel/debug/ieee80211/phy2/netdev:mesh2/stations/00:03:7f:12:bb:97/he_capa
HE supported
MAC-CAP: 0x09 0x0d 0x08 0x0a 0x40 0x00
HTC-HE
DYNAMIC-FRAG-LEVEL-1
MAX-NUM-FRAG-MSDU-1
MIN-FRAG-SIZE-128
TF-MAC-PAD-DUR-24US
MULTI-TID-AGG-RX-QOS-1
LINK-ADAPTATION-NO-FEEDBACK
BSR
OMI-CONTROL
MAX-AMPDU-LEN-EXP-VHT-1
AMSDU-IN-AMPDU
MULTI-TID-AGG-TX-QOS-0
PHY CAP: 0x1c 0x70 0x0c 0x80 0x0d 0x43 0x81 0x1c 0x00 0x00 0x00
CHANNEL-WIDTH-SET-40MHZ-80MHZ-IN-5G
CHANNEL-WIDTH-SET-160MHZ-IN-5G
CHANNEL-WIDTH-SET-80PLUS80-MHZ-IN-5G
IEEE80211-HE-PHY-CAP1-DEVICE-CLASS-A
LDPC-CODING-IN-PAYLOAD
HY-CAP1-HE-LTF-AND-GI-FOR-HE-PPDUS-0-8US
MIDAMBLE-RX-MAX-NSTS-0
STBC-TX-UNDER-80MHZ
STBC-RX-UNDER-80MHZ
DCM-MAX-CONST-TX-NO-DCM
DCM-MAX-CONST-RX-NO-DCM
SU-BEAMFORMER
SU-BEAMFORMEE
BEAMFORMEE-MAX-STS-UNDER-7
BEAMFORMEE-MAX-STS-ABOVE-4
NUM-SND-DIM-UNDER-80MHZ-4
NUM-SND-DIM-ABOVE-80MHZ-1
NG16-SU-FEEDBACK
CODEBOOK-SIZE-42-SU
PPE-THRESHOLD-PRESENT
HE-SU-MU-PPDU-4XLTF-AND-08-US-GI
MAX-NC-4
DCM-MAX-RU-242
NOMINAL-PACKET-PADDING-0US
RX-MCS-80: 0xffaa
RX-MCS-80-0-SUPPORT-0-11
RX-MCS-80-1-SUPPORT-0-11
RX-MCS-80-2-SUPPORT-0-11
RX-MCS-80-3-SUPPORT-0-11
TX-MCS-80: 0xffaa
TX-MCS-80-0-SUPPORT-0-11
TX-MCS-80-1-SUPPORT-0-11
TX-MCS-80-2-SUPPORT-0-11
TX-MCS-80-3-SUPPORT-0-11
RX-MCS-160: 0xfffa
RX-MCS-160-0-SUPPORT-0-11
RX-MCS-160-1-SUPPORT-0-11
RX-MCS-160-2-NOT-SUPPORTED
RX-MCS-160-3-NOT-SUPPORTED
TX-MCS-160: 0xfffa
TX-MCS-160-0-SUPPORT-0-11
TX-MCS-160-1-SUPPORT-0-11
TX-MCS-160-2-NOT-SUPPORTED
TX-MCS-160-3-NOT-SUPPORTED
RX-MCS-80P80: 0xfffa
RX-MCS-80P80-0-SUPPORT-0-11
RX-MCS-80P80-1-SUPPORT-0-11
RX-MCS-80P80-2-NOT-SUPPORTED
RX-MCS-80P80-3-NOT-SUPPORTED
TX-MCS-80P80: 0xfffa
TX-MCS-80P80-0-SUPPORT-0-11
TX-MCS-80P80-1-SUPPORT-0-11
TX-MCS-80P80-2-NOT-SUPPORTED
TX-MCS-80P80-3-NOT-SUPPORTED
PPE-THRESHOLDS: 0x3b 0x1c 0xc7 0x71 0x1c 0xc7 0x71 0x1c 0xc7 0x71
root@OpenWrt:/# iw dev mesh2 station dump
Station 00:03:7f:12:bb:97 (on mesh2)
inactive time: 310 ms
rx bytes: 161064
rx packets: 1619
tx bytes: 55454
tx packets: 477
tx retries: 405
tx failed: 0
rx drop misc: 6
signal: -95 dBm
signal avg: -67 dBm
tx bitrate: 1733.3 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 4
rx bitrate: 1733.3 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 4
rx duration: 0 us
mesh llid: 0
mesh plid: 0
mesh plink: ESTAB
mesh local PS mode: ACTIVE
mesh peer PS mode: ACTIVE
mesh non-peer PS mode: ACTIVE
authorized: yes
authenticated: yes
associated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
DTIM period: 2
beacon interval:1000
connected time: 536 seconds
But there is currently no documentation what the firmware requires (next to
the already existing things for AP/managed) to enable HE for mesh.
hwsim can be used in the meantime as basis for initial development of these
features without having access to HW.
Kind regards,
Sven
Sven Eckelmann (3):
mac80211_hwsim: Register support for HE meshpoint
mac80211: implement HE support for mesh
ath11k: register HE mesh capabilities
drivers/net/wireless/ath/ath11k/mac.c | 56 +++++
drivers/net/wireless/mac80211_hwsim.c | 283 +++++++++++++++++---------
include/net/cfg80211.h | 19 ++
net/mac80211/ieee80211_i.h | 2 +
net/mac80211/mesh.c | 61 ++++++
net/mac80211/mesh.h | 4 +
net/mac80211/mesh_plink.c | 11 +-
net/mac80211/util.c | 52 +++++
8 files changed, 393 insertions(+), 95 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook
From: Andreas Schwab @ 2019-06-11 17:48 UTC (permalink / raw)
To: Larry Finger
Cc: Christoph Hellwig, Aaro Koskinen, Christian Zigotzky,
Michael Ellerman, linux-kernel, linux-wireless, linuxppc-dev
In-Reply-To: <153c13f5-a829-1eab-a3c5-fecfb84127ff@lwfinger.net>
On Jun 10 2019, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> I do not understand why the if statement returns true as neither of the
> values is zero.
That's because the format string does not make any sense. You are
printing garbage.
> diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
> index f7afdad..ba2489d 100644
> --- a/kernel/dma/mapping.c
> +++ b/kernel/dma/mapping.c
> @@ -317,9 +317,12 @@ int dma_supported(struct device *dev, u64 mask)
>
> int dma_set_mask(struct device *dev, u64 mask)
> {
> + pr_info("mask 0x%llx, dma_mask 0x%llx, dma_supported 0x%llx\n",
> mask, dev->dma_mask,
> + dma_supported(dev, mask));
None of the format directives match the type of the arguments.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* [PATCH v2] ath10k: fix max antenna gain unit
From: Sven Eckelmann @ 2019-06-11 17:21 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Sven Eckelmann
From: Sven Eckelmann <seckelmann@datto.com>
Most of the txpower for the ath10k firmware is stored as twicepower (0.5 dB
steps). This isn't the case for max_antenna_gain - which is still expected
by the firmware as dB.
The firmware is converting it from dB to the internal (twicepower)
representation when it calculates the limits of a channel. This can be seen
in tpc_stats when configuring "12" as max_antenna_gain. Instead of the
expected 12 (6 dB), the tpc_stats shows 24 (12 dB).
Tested on QCA9888 and IPQ4019 with firmware 10.4-3.5.3-00057.
Fixes: 02256930d9b8 ("ath10k: use proper tx power unit")
Signed-off-by: Sven Eckelmann <seckelmann@datto.com>
---
v2:
* Add comments to wmi.h regarding the power unit
drivers/net/wireless/ath/ath10k/mac.c | 6 +++---
drivers/net/wireless/ath/ath10k/wmi.h | 3 +++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 9c703d287333..35d026a2772a 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1008,7 +1008,7 @@ static int ath10k_monitor_vdev_start(struct ath10k *ar, int vdev_id)
arg.channel.min_power = 0;
arg.channel.max_power = channel->max_power * 2;
arg.channel.max_reg_power = channel->max_reg_power * 2;
- arg.channel.max_antenna_gain = channel->max_antenna_gain * 2;
+ arg.channel.max_antenna_gain = channel->max_antenna_gain;
reinit_completion(&ar->vdev_setup_done);
@@ -1450,7 +1450,7 @@ static int ath10k_vdev_start_restart(struct ath10k_vif *arvif,
arg.channel.min_power = 0;
arg.channel.max_power = chandef->chan->max_power * 2;
arg.channel.max_reg_power = chandef->chan->max_reg_power * 2;
- arg.channel.max_antenna_gain = chandef->chan->max_antenna_gain * 2;
+ arg.channel.max_antenna_gain = chandef->chan->max_antenna_gain;
if (arvif->vdev_type == WMI_VDEV_TYPE_AP) {
arg.ssid = arvif->u.ap.ssid;
@@ -3105,7 +3105,7 @@ static int ath10k_update_channel_list(struct ath10k *ar)
ch->min_power = 0;
ch->max_power = channel->max_power * 2;
ch->max_reg_power = channel->max_reg_power * 2;
- ch->max_antenna_gain = channel->max_antenna_gain * 2;
+ ch->max_antenna_gain = channel->max_antenna_gain;
ch->reg_class_id = 0; /* FIXME */
/* FIXME: why use only legacy modes, why not any
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index e1c40bb69932..9cc0ef47deb7 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -2038,7 +2038,9 @@ struct wmi_channel {
union {
__le32 reginfo1;
struct {
+ /* note: power unit is 1 dBm */
u8 antenna_max;
+ /* note: power unit is 0.5 dBm */
u8 max_tx_power;
} __packed;
} __packed;
@@ -2058,6 +2060,7 @@ struct wmi_channel_arg {
u32 min_power;
u32 max_power;
u32 max_reg_power;
+ /* note: power unit is 1 dBm */
u32 max_antenna_gain;
u32 reg_class_id;
enum wmi_phy_mode mode;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] ath10k: fix max antenna gain unit
From: Ben Greear @ 2019-06-11 16:29 UTC (permalink / raw)
To: Sven Eckelmann, ath10k; +Cc: linux-wireless, Sven Eckelmann, Michal Kazior
In-Reply-To: <20190611121910.27643-1-sven@narfation.org>
On 6/11/19 5:19 AM, Sven Eckelmann wrote:
> From: Sven Eckelmann <seckelmann@datto.com>
>
> Most of the txpower for the ath10k firmware is stored as twicepower (0.5 dB
> steps). This isn't the case for max_antenna_gain - which is still expected
> by the firmware as dB.
>
> The firmware is converting it from dB to the internal (twicepower)
> representation when it calculates the limits of a channel. This can be seen
> in tpc_stats when configuring "12" as max_antenna_gain. Instead of the
> expected 12 (6 dB), the tpc_stats shows 24 (12 dB).
>
> Tested on QCA9888 and IPQ4019 with firmware 10.4-3.5.3-00057.
I did a visual inspection of wave-1 firmware source and it appears this change would be correct
for it as well.
I would also suggest updating the comments in the wmi.h structure to document the
units.
Thanks,
Ben
>
> Fixes: 02256930d9b8 ("ath10k: use proper tx power unit")
> Signed-off-by: Sven Eckelmann <seckelmann@datto.com>
> ---
> Cc: Michal Kazior <michal@plume.com>
>
> drivers/net/wireless/ath/ath10k/mac.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index 9c703d287333..35d026a2772a 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -1008,7 +1008,7 @@ static int ath10k_monitor_vdev_start(struct ath10k *ar, int vdev_id)
> arg.channel.min_power = 0;
> arg.channel.max_power = channel->max_power * 2;
> arg.channel.max_reg_power = channel->max_reg_power * 2;
> - arg.channel.max_antenna_gain = channel->max_antenna_gain * 2;
> + arg.channel.max_antenna_gain = channel->max_antenna_gain;
>
> reinit_completion(&ar->vdev_setup_done);
>
> @@ -1450,7 +1450,7 @@ static int ath10k_vdev_start_restart(struct ath10k_vif *arvif,
> arg.channel.min_power = 0;
> arg.channel.max_power = chandef->chan->max_power * 2;
> arg.channel.max_reg_power = chandef->chan->max_reg_power * 2;
> - arg.channel.max_antenna_gain = chandef->chan->max_antenna_gain * 2;
> + arg.channel.max_antenna_gain = chandef->chan->max_antenna_gain;
>
> if (arvif->vdev_type == WMI_VDEV_TYPE_AP) {
> arg.ssid = arvif->u.ap.ssid;
> @@ -3105,7 +3105,7 @@ static int ath10k_update_channel_list(struct ath10k *ar)
> ch->min_power = 0;
> ch->max_power = channel->max_power * 2;
> ch->max_reg_power = channel->max_reg_power * 2;
> - ch->max_antenna_gain = channel->max_antenna_gain * 2;
> + ch->max_antenna_gain = channel->max_antenna_gain;
> ch->reg_class_id = 0; /* FIXME */
>
> /* FIXME: why use only legacy modes, why not any
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2] ath9k: correctly handle short radar pulses (fixes 3c0efb745a)
From: Kalle Valo @ 2019-06-11 14:08 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: linux-wireless, nbd
In-Reply-To: <f3ec61f2-2b63-4d20-b9f4-d85cc2d44073@neratec.com>
Zefir Kurtisi <zefir.kurtisi@neratec.com> writes:
> On 6/11/19 3:43 PM, Kalle Valo wrote:
>> Zefir Kurtisi <zefir.kurtisi@neratec.com> writes:
>>
>>> Changes to v1:
>>> * typos fixed in commit-message
>>> --
>>>
>>> In commit '3c0efb745a17 ("ath9k: discard undersized packets")'
>>> the lower bound of RX packets was set to 10 (min ACK size) to
>>> filter those that would otherwise be treated as invalid at
>>> mac80211.
>>>
>>> Alas, short radar pulses are reported as PHY_ERROR frames
>>> with length set to 3. Therefore their detection stopped
>>> working after that commit.
>>>
>>> NOTE: ath9k drivers built thereafter will not pass DFS
>>> certification.
>>>
>>> This extends the criteria for short packets to explicitly
>>> handle PHY_ERROR frames.
>>>
>>> Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
>>
>> Forgot to mention that the Fixes line should be before s-o-b, not in the
>> title:
>>
>> Fixes: 3c0efb745a17 ("ath9k: discard undersized packets")
>>
>> I'll fix (no pun intended) that as well.
>>
> Thanks. Was unsure about that, checkpatch warned about format (mandatory 12 digit
> hash), but not the proper location. Will keep in mind.
I have tried to document the most important parts to the wiki:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#fixes_line_is_incorrect
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2] ath9k: correctly handle short radar pulses (fixes 3c0efb745a)
From: Zefir Kurtisi @ 2019-06-11 13:48 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, nbd
In-Reply-To: <87h88wgrui.fsf@kamboji.qca.qualcomm.com>
On 6/11/19 3:43 PM, Kalle Valo wrote:
> Zefir Kurtisi <zefir.kurtisi@neratec.com> writes:
>
>> Changes to v1:
>> * typos fixed in commit-message
>> --
>>
>> In commit '3c0efb745a17 ("ath9k: discard undersized packets")'
>> the lower bound of RX packets was set to 10 (min ACK size) to
>> filter those that would otherwise be treated as invalid at
>> mac80211.
>>
>> Alas, short radar pulses are reported as PHY_ERROR frames
>> with length set to 3. Therefore their detection stopped
>> working after that commit.
>>
>> NOTE: ath9k drivers built thereafter will not pass DFS
>> certification.
>>
>> This extends the criteria for short packets to explicitly
>> handle PHY_ERROR frames.
>>
>> Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
>
> Forgot to mention that the Fixes line should be before s-o-b, not in the
> title:
>
> Fixes: 3c0efb745a17 ("ath9k: discard undersized packets")
>
> I'll fix (no pun intended) that as well.
>
Thanks. Was unsure about that, checkpatch warned about format (mandatory 12 digit
hash), but not the proper location. Will keep in mind.
^ permalink raw reply
* Re: [PATCH v2] ath9k: correctly handle short radar pulses (fixes 3c0efb745a)
From: Kalle Valo @ 2019-06-11 13:43 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: linux-wireless, nbd
In-Reply-To: <20190611133656.16964-1-zefir.kurtisi@neratec.com>
Zefir Kurtisi <zefir.kurtisi@neratec.com> writes:
> Changes to v1:
> * typos fixed in commit-message
> --
>
> In commit '3c0efb745a17 ("ath9k: discard undersized packets")'
> the lower bound of RX packets was set to 10 (min ACK size) to
> filter those that would otherwise be treated as invalid at
> mac80211.
>
> Alas, short radar pulses are reported as PHY_ERROR frames
> with length set to 3. Therefore their detection stopped
> working after that commit.
>
> NOTE: ath9k drivers built thereafter will not pass DFS
> certification.
>
> This extends the criteria for short packets to explicitly
> handle PHY_ERROR frames.
>
> Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Forgot to mention that the Fixes line should be before s-o-b, not in the
title:
Fixes: 3c0efb745a17 ("ath9k: discard undersized packets")
I'll fix (no pun intended) that as well.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2] ath9k: correctly handle short radar pulses (fixes 3c0efb745a)
From: Kalle Valo @ 2019-06-11 13:42 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: linux-wireless, nbd
In-Reply-To: <20190611133656.16964-1-zefir.kurtisi@neratec.com>
Zefir Kurtisi <zefir.kurtisi@neratec.com> writes:
> Changes to v1:
> * typos fixed in commit-message
> --
This in the wrong place.
> In commit '3c0efb745a17 ("ath9k: discard undersized packets")'
> the lower bound of RX packets was set to 10 (min ACK size) to
> filter those that would otherwise be treated as invalid at
> mac80211.
>
> Alas, short radar pulses are reported as PHY_ERROR frames
> with length set to 3. Therefore their detection stopped
> working after that commit.
>
> NOTE: ath9k drivers built thereafter will not pass DFS
> certification.
>
> This extends the criteria for short packets to explicitly
> handle PHY_ERROR frames.
>
> Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
> ---
The changelog should be here. But I can fix it manually this time.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 00/11] rtw88: power index setting routine updates and fixes
From: Kalle Valo @ 2019-06-11 13:39 UTC (permalink / raw)
To: Tony Chuang; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <F7CD281DE3E379468C6D07993EA72F84D1803B44@RTITMBSVM04.realtek.com.tw>
Tony Chuang <yhchuang@realtek.com> writes:
>> -----Original Message-----
>> From: linux-wireless-owner@vger.kernel.org
>> [mailto:linux-wireless-owner@vger.kernel.org] On Behalf Of
>> yhchuang@realtek.com
>> Sent: Wednesday, May 29, 2019 3:55 PM
>> To: kvalo@codeaurora.org
>> Cc: linux-wireless@vger.kernel.org
>> Subject: [PATCH 00/11] rtw88: power index setting routine updates and fixes
>>
>
> ...
>
>> drivers/net/wireless/realtek/rtw88/debug.c | 112 ++
>> drivers/net/wireless/realtek/rtw88/main.c | 26 +-
>> drivers/net/wireless/realtek/rtw88/main.h | 27 +-
>> drivers/net/wireless/realtek/rtw88/phy.c | 1298
>> +++++++++++---------
>> drivers/net/wireless/realtek/rtw88/phy.h | 18 +-
>> drivers/net/wireless/realtek/rtw88/regd.c | 69 +-
>> drivers/net/wireless/realtek/rtw88/regd.h | 4 +
>> .../net/wireless/realtek/rtw88/rtw8822c_table.c | 799 +++++++++++-
>> 8 files changed, 1653 insertions(+), 700 deletions(-)
>>
>> --
>
> Hi Kalle
>
> I am going to submit a v2 for this.
> Will you suggest me to format the patches based on
> wireless-drivers or wireless-drivers-next?
Please use wireless-drivers-next as the baseline. I recommend to split
the set, submit now the patches which apply right now and submit the
rest after the dependencies are in w-d-next.
But do note that I haven't had a chance to review your patches yet.
--
Kalle Valo
^ permalink raw reply
* [PATCH v2] ath9k: correctly handle short radar pulses (fixes 3c0efb745a)
From: Zefir Kurtisi @ 2019-06-11 13:36 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, nbd
In-Reply-To: <20190611131006.29715-1-zefir.kurtisi@neratec.com>
Changes to v1:
* typos fixed in commit-message
--
In commit '3c0efb745a17 ("ath9k: discard undersized packets")'
the lower bound of RX packets was set to 10 (min ACK size) to
filter those that would otherwise be treated as invalid at
mac80211.
Alas, short radar pulses are reported as PHY_ERROR frames
with length set to 3. Therefore their detection stopped
working after that commit.
NOTE: ath9k drivers built thereafter will not pass DFS
certification.
This extends the criteria for short packets to explicitly
handle PHY_ERROR frames.
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
---
drivers/net/wireless/ath/ath9k/recv.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 4e97f7f3b2a3..5519c144d1f1 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -815,6 +815,7 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
struct ath_common *common = ath9k_hw_common(ah);
struct ieee80211_hdr *hdr;
bool discard_current = sc->rx.discard_next;
+ bool is_phyerr;
/*
* Discard corrupt descriptors which are marked in
@@ -827,8 +828,11 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
/*
* Discard zero-length packets and packets smaller than an ACK
+ * which are not PHY_ERROR (short radar pulses have a length of 3)
*/
- if (rx_stats->rs_datalen < 10) {
+ is_phyerr = rx_stats->rs_status & ATH9K_RXERR_PHY;
+ if (!rx_stats->rs_datalen ||
+ (rx_stats->rs_datalen < 10 && !is_phyerr)) {
RX_STAT_INC(sc, rx_len_err);
goto corrupt;
}
--
2.17.1
^ permalink raw reply related
* [PATCH] ath9k: corrctly handle short radar pulses (fixes 3c0efb745a)
From: Zefir Kurtisi @ 2019-06-11 13:10 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, nbd
In commit '3c0efb745a17 ("ath9k: discard undersized packets")'
the lower bound of RX packets was set to 10 (min ACK size) to
filter those that would otherwise be treated as invalid at
mac80211.
Alas, short radar pulses are reported as PHY_ERROR frames
with length set to 3. Therefore their detection stopped
working after that commit.
NOTE: ath9k drivers built thereafter will not pass DFS
certification.
This extends the criteria for short packages to explicitly
handle PHY_ERROR frames.
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
---
drivers/net/wireless/ath/ath9k/recv.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 4e97f7f3b2a3..5519c144d1f1 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -815,6 +815,7 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
struct ath_common *common = ath9k_hw_common(ah);
struct ieee80211_hdr *hdr;
bool discard_current = sc->rx.discard_next;
+ bool is_phyerr;
/*
* Discard corrupt descriptors which are marked in
@@ -827,8 +828,11 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
/*
* Discard zero-length packets and packets smaller than an ACK
+ * which are not PHY_ERROR (short radar pulses have a length of 3)
*/
- if (rx_stats->rs_datalen < 10) {
+ is_phyerr = rx_stats->rs_status & ATH9K_RXERR_PHY;
+ if (!rx_stats->rs_datalen ||
+ (rx_stats->rs_datalen < 10 && !is_phyerr)) {
RX_STAT_INC(sc, rx_len_err);
goto corrupt;
}
--
2.17.1
^ permalink raw reply related
* [PATCH] mmc: core: Prevent processing SDIO IRQs when the card is suspended
From: Ulf Hansson @ 2019-06-11 12:32 UTC (permalink / raw)
To: linux-mmc, Ulf Hansson, Douglas Anderson
Cc: Adrian Hunter, Brian Norris, Shawn Lin, Guenter Roeck,
Heiko Stuebner, Kalle Valo, linux-wireless, stable
Processing of SDIO IRQs must obviously be prevented while the card is
system suspended, otherwise we may end up trying to communicate with an
uninitialized SDIO card.
Reports throughout the years shows that this is not only a theoretical
problem, but a real issue. So, let's finally fix this problem, by keeping
track of the state for the card and bail out before processing the SDIO
IRQ, in case the card is suspended.
Cc: stable@vger.kernel.org
Reported-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
This has only been compile tested so far, any help for real test on HW is
greatly appreciated.
Note that, this is only the initial part of what is needed to make power
management of SDIO card more robust, but let's start somewhere and continue to
improve things.
The next step I am looking at right now, is to make sure the SDIO IRQ is turned
off during system suspend, unless it's supported as a system wakeup (and enabled
to be used).
---
drivers/mmc/core/sdio.c | 7 +++++++
drivers/mmc/core/sdio_irq.c | 4 ++++
2 files changed, 11 insertions(+)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index d1aa1c7577bb..9951295d3220 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -937,6 +937,10 @@ static int mmc_sdio_pre_suspend(struct mmc_host *host)
*/
static int mmc_sdio_suspend(struct mmc_host *host)
{
+ /* Prevent processing of SDIO IRQs in suspended state. */
+ mmc_card_set_suspended(host->card);
+ cancel_delayed_work_sync(&host->sdio_irq_work);
+
mmc_claim_host(host);
if (mmc_card_keep_power(host) && mmc_card_wake_sdio_irq(host))
@@ -985,6 +989,9 @@ static int mmc_sdio_resume(struct mmc_host *host)
err = sdio_enable_4bit_bus(host->card);
}
+ /* Allow SDIO IRQs to be processed again. */
+ mmc_card_clr_suspended(host->card);
+
if (!err && host->sdio_irqs) {
if (!(host->caps2 & MMC_CAP2_SDIO_IRQ_NOTHREAD))
wake_up_process(host->sdio_irq_thread);
diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
index 931e6226c0b3..9f54a259a1b3 100644
--- a/drivers/mmc/core/sdio_irq.c
+++ b/drivers/mmc/core/sdio_irq.c
@@ -34,6 +34,10 @@ static int process_sdio_pending_irqs(struct mmc_host *host)
unsigned char pending;
struct sdio_func *func;
+ /* Don't process SDIO IRQs if the card is suspended. */
+ if (mmc_card_suspended(card))
+ return 0;
+
/*
* Optimization, if there is only 1 function interrupt registered
* and we know an IRQ was signaled then call irq handler directly.
--
2.17.1
^ permalink raw reply related
* [PATCH] ath10k: fix max antenna gain unit
From: Sven Eckelmann @ 2019-06-11 12:19 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Sven Eckelmann, Michal Kazior
From: Sven Eckelmann <seckelmann@datto.com>
Most of the txpower for the ath10k firmware is stored as twicepower (0.5 dB
steps). This isn't the case for max_antenna_gain - which is still expected
by the firmware as dB.
The firmware is converting it from dB to the internal (twicepower)
representation when it calculates the limits of a channel. This can be seen
in tpc_stats when configuring "12" as max_antenna_gain. Instead of the
expected 12 (6 dB), the tpc_stats shows 24 (12 dB).
Tested on QCA9888 and IPQ4019 with firmware 10.4-3.5.3-00057.
Fixes: 02256930d9b8 ("ath10k: use proper tx power unit")
Signed-off-by: Sven Eckelmann <seckelmann@datto.com>
---
Cc: Michal Kazior <michal@plume.com>
drivers/net/wireless/ath/ath10k/mac.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 9c703d287333..35d026a2772a 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1008,7 +1008,7 @@ static int ath10k_monitor_vdev_start(struct ath10k *ar, int vdev_id)
arg.channel.min_power = 0;
arg.channel.max_power = channel->max_power * 2;
arg.channel.max_reg_power = channel->max_reg_power * 2;
- arg.channel.max_antenna_gain = channel->max_antenna_gain * 2;
+ arg.channel.max_antenna_gain = channel->max_antenna_gain;
reinit_completion(&ar->vdev_setup_done);
@@ -1450,7 +1450,7 @@ static int ath10k_vdev_start_restart(struct ath10k_vif *arvif,
arg.channel.min_power = 0;
arg.channel.max_power = chandef->chan->max_power * 2;
arg.channel.max_reg_power = chandef->chan->max_reg_power * 2;
- arg.channel.max_antenna_gain = chandef->chan->max_antenna_gain * 2;
+ arg.channel.max_antenna_gain = chandef->chan->max_antenna_gain;
if (arvif->vdev_type == WMI_VDEV_TYPE_AP) {
arg.ssid = arvif->u.ap.ssid;
@@ -3105,7 +3105,7 @@ static int ath10k_update_channel_list(struct ath10k *ar)
ch->min_power = 0;
ch->max_power = channel->max_power * 2;
ch->max_reg_power = channel->max_reg_power * 2;
- ch->max_antenna_gain = channel->max_antenna_gain * 2;
+ ch->max_antenna_gain = channel->max_antenna_gain;
ch->reg_class_id = 0; /* FIXME */
/* FIXME: why use only legacy modes, why not any
--
2.20.1
^ permalink raw reply related
* RE: [PATCH 00/11] rtw88: power index setting routine updates and fixes
From: Tony Chuang @ 2019-06-11 10:07 UTC (permalink / raw)
To: Tony Chuang, kvalo@codeaurora.org; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1559116487-5244-1-git-send-email-yhchuang@realtek.com>
> -----Original Message-----
> From: linux-wireless-owner@vger.kernel.org
> [mailto:linux-wireless-owner@vger.kernel.org] On Behalf Of
> yhchuang@realtek.com
> Sent: Wednesday, May 29, 2019 3:55 PM
> To: kvalo@codeaurora.org
> Cc: linux-wireless@vger.kernel.org
> Subject: [PATCH 00/11] rtw88: power index setting routine updates and fixes
>
...
> drivers/net/wireless/realtek/rtw88/debug.c | 112 ++
> drivers/net/wireless/realtek/rtw88/main.c | 26 +-
> drivers/net/wireless/realtek/rtw88/main.h | 27 +-
> drivers/net/wireless/realtek/rtw88/phy.c | 1298
> +++++++++++---------
> drivers/net/wireless/realtek/rtw88/phy.h | 18 +-
> drivers/net/wireless/realtek/rtw88/regd.c | 69 +-
> drivers/net/wireless/realtek/rtw88/regd.h | 4 +
> .../net/wireless/realtek/rtw88/rtw8822c_table.c | 799 +++++++++++-
> 8 files changed, 1653 insertions(+), 700 deletions(-)
>
> --
Hi Kalle
I am going to submit a v2 for this.
Will you suggest me to format the patches based on
wireless-drivers or wireless-drivers-next?
Thanks
Yan-Hsuan
^ permalink raw reply
* Re: [RESEND] brcmfmac support for BCM4359 sdio on arm64 ??
From: Arend Van Spriel @ 2019-06-11 9:45 UTC (permalink / raw)
To: Christian Hewitt
Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
Wright.Feng, Neil Armstrong, Christoph Muellner
In-Reply-To: <F5C2858A-498E-4AD3-859D-FA9D14BF6B37@gmail.com>
On 6/8/2019 5:39 AM, Christian Hewitt wrote:
> Hello Arend,
>
> Last October Christoph Müllner reported BCM4359 SDIO issues here: https://www.spinics.net/lists/linux-wireless/msg178783.html but the investigation stalled after the needs/timescale of his project forced a change to a different (working) module.
>
> BCM4359 is being used in an increasing number of Amlogic devices the Kodi focussed distro LibreELEC supports. I’m one of the maintainers for the distro and I’d like to assist/resume the investigation.
>
> To recap: using changes from Wright Feng that can be found here https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/65f17112e1c883d3c9f3fa68837e5f9b5eb7cfad/patches/cypress/v4.14.52-2018_0928/cypress-patch/0050-brcmfmac-Add-support-for-BCM4359-SDIO-chipset.patch result in the BCM4359 device being identified but firmware/nvram loading fails:
>
> [ 8.557929] brcmfmac: F1 signature read @0x18000000=0x17294359
> [ 8.562087] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4359-sdio for chip BCM4359/9
> [ 8.775655] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
> [ 8.775667] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 membytes at 0x0025f0c0
> [ 8.775670] brcmfmac: brcmf_sdio_download_firmware: dongle nvram file download failed
It seems to fail when reading back the nvram file to assure it was
downloaded properly.
> See: http://ix.io/1KfY for the full dmesg output on 5.1-rc1 kernel including a splat that may or may not be related/relevant. I am using firmware and nvram files from https://github.com/LibreELEC/brcmfmac_sdio-firmware which match files found in several other github and public repo locations. The firmware/nvram are reported working in Android.
The splat could be relevant. Maybe try the patch below to get actual
values that are checked in the WARN_ON.
> BCMDHD is also reported working with commits here: https://gitlab.com/baylibre/amlogic/atv/linux/commits/narmstrong/v5.1/aml/integ-5.1-bcmdhd but LibreELEC needs to support many different boards (with many different SDIO modules) from a single OS image, so BCMDHD is not the solution we need.
>
> One additional patch I spotted mentioning BCM4359 (also from Wright Feng) was https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/65f17112e1c883d3c9f3fa68837e5f9b5eb7cfad/patches/cypress/v4.14.52-2018_0928/cypress-patch/0073-non-upstream-reset-two-D11-cores-if-chip-has-two-D11.patch but it makes no difference (the dmesg log above is with this patch applied).
>
> I don’t write code but am happy to build test kernels with suggested patches or explicit instructions. I’ve also CC’d LibreELEC colleague and linux-amlogic maintainer Neil Armstrong who can assist. NB: If direct access to hardware would help progress things I can easily organise remote access or get board samples shipped.
>
> How can we resume the investigation?
Let's try one step at a time ;-)
Regards,
Arend
---
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
b/driver
index fc12598..e9b0986 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -772,7 +772,8 @@ void brcmf_sdiod_sgtable_alloc(struct brcmf_sdio_dev
*sdiod
sdiodev->settings->bus.sdio.txglomsz);
nents += (nents >> 4) + 1;
- WARN_ON(nents > sdiodev->max_segment_count);
+ WARN(nents > sdiodev->max_segment_count, "max_seg_cnt=%u,
host_max_seg=
+ sdiodev->max_segment_count, host->max_segs, nents);
brcmf_dbg(TRACE, "nents=%d\n", nents);
err = sg_alloc_table(&sdiodev->sgtable, nents, GFP_KERNEL);
q
^ permalink raw reply related
* Trace with softblocked wireless card during startup on v5.1.x
From: Julian Wollrath @ 2019-06-11 9:37 UTC (permalink / raw)
To: linux-wireless
Hi,
I have an Intel Corporation Wireless 8265 / 8275 [8086:24fd] card which
is softblocked during startup and I get the following reproducable
trace:
wpa_supplicant[580]: rfkill: WLAN soft blocked
kernel: [ 10.881037] WARNING: CPU: 0 PID: 580 at net/wireless/nl80211.c:6714 nl80211_get_reg_do+0x1d9/0x240 [cfg802
kernel: [ 10.881038] Modules linked in: arc4 snd_hda_codec_hdmi iwlmvm mac80211 snd_hda_codec_realtek snd_hda_codec
m btintel bluetooth nft_counter iwlwifi nft_limit drbg snd_hda_intel uvcvideo snd_hda_codec snd_usb_audio(+) videobuf
s intel_rapl snd_usbmidi_lib ansi_cprng x86_pkg_temp_thermal snd_hwdep snd_hda_core intel_powerclamp coretemp snd_pcm
odev snd_rawmidi snd_timer snd_seq_device videobuf2_common evdev serio_raw snd soundcore cfg80211 i2c_algo_bit nft_ct
per crc16 rfkill syscopyarea sysfillrect sysimgblt fb_sys_fops nf_conntrack idma64 drm nf_defrag_ipv6 nf_defrag_ipv4
b fujitsu_laptop tpm sparse_keymap acpi_pad video ac nf_tables_set nf_tables nfnetlink sch_fq autofs4 algif_skcipher
hid dm_crypt dm_mod sd_mod crct10dif_pclmul crc32_pclmul crc32c_intel i2c_designware_platform i2c_designware_core gh
psmouse ptp pps_core
kernel: [ 10.881066] ahci libahci i2c_i801 sdhci_pci cqhci xhci_pci sdhci libata xhci_hcd mmc_core scsi_mod usbcor
ss usb_common
kernel: [ 10.881073] CPU: 0 PID: 580 Comm: wpa_supplicant Not tainted 5.1.8 #4
kernel: [ 10.881074] Hardware name: FUJITSU LIFEBOOK U747/FJNB2A5, BIOS Version 1.17 09/11/2017
kernel: [ 10.881082] RIP: 0010:nl80211_get_reg_do+0x1d9/0x240 [cfg80211]
kernel: [ 10.881083] Code: 9a 00 00 00 c7 44 24 0c 01 00 00 00 48 89 df e8 ed ff 24 cf 85 c0 74 c3 48 89 df e8 91 1
73 ff ff ff <0f> 0b 48 89 df e8 7d 18 3c cf b8 ea ff ff ff e9 5f ff ff ff b8 97
kernel: [ 10.881084] RSP: 0018:ffffb6b5c1ce7ad8 EFLAGS: 00010202
kernel: [ 10.881085] RAX: 0000000000000000 RBX: ffff8ef0951e3e00 RCX: 0000000000000000
kernel: [ 10.881086] RDX: ffff8ef09331c008 RSI: 0000000000000000 RDI: ffff8ef09331c300
kernel: [ 10.881086] RBP: ffffb6b5c1ce7b68 R08: 0000000000000004 R09: ffff8ef093ad2014
kernel: [ 10.881087] R10: ffffffffc07da5e0 R11: 0000000000000004 R12: ffff8ef093ad2014
kernel: [ 10.881088] R13: 0000000000000000 R14: ffff8ef09331c300 R15: 0000000000000001
kernel: [ 10.881089] FS: 00007f689cc7a800(0000) GS:ffff8ef09dc00000(0000) knlGS:0000000000000000
kernel: [ 10.881090] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: [ 10.881091] CR2: 000055d5cdb69000 CR3: 000000024bc50001 CR4: 00000000003606f0
kernel: [ 10.881091] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
kernel: [ 10.881092] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
kernel: [ 10.881093] Call Trace:
kernel: [ 10.881098] ? _cond_resched+0x10/0x20
kernel: [ 10.881100] genl_family_rcv_msg+0x1c5/0x3b0
kernel: [ 10.881103] genl_rcv_msg+0x42/0x87
kernel: [ 10.881104] ? genl_family_rcv_msg+0x3b0/0x3b0
kernel: [ 10.881106] netlink_rcv_skb+0x44/0x110
kernel: [ 10.881108] genl_rcv+0x1f/0x30
kernel: [ 10.881111] netlink_unicast+0x194/0x250
kernel: [ 10.881113] netlink_sendmsg+0x1c7/0x3f0
kernel: [ 10.881115] ? netlink_unicast+0x250/0x250
kernel: [ 10.881117] ___sys_sendmsg+0x291/0x2e0
kernel: [ 10.881122] ? alloc_set_pte+0xe7/0x530
kernel: [ 10.881133] ? filemap_map_pages+0x1ae/0x390
kernel: [ 10.881134] ? __handle_mm_fault+0x100d/0x1240
kernel: [ 10.881136] __sys_sendmsg+0x52/0xa0
kernel: [ 10.881139] do_syscall_64+0x43/0xf0
kernel: [ 10.881142] entry_SYSCALL_64_after_hwframe+0x44/0xa9
kernel: [ 10.881144] RIP: 0033:0x7f689cfc5914
kernel: [ 10.881145] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 48 8d 05 e9 5d 0c 00 8
00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 41 89 d4 55 48 89 f5 53
kernel: [ 10.881146] RSP: 002b:00007fff25f0fac8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
kernel: [ 10.881147] RAX: ffffffffffffffda RBX: 000055d5cdb5c480 RCX: 00007f689cfc5914
kernel: [ 10.881148] RDX: 0000000000000000 RSI: 00007fff25f0fb00 RDI: 0000000000000005
kernel: [ 10.881148] RBP: 000055d5cdb5cbb0 R08: 0000000000000004 R09: 000000000000000d
kernel: [ 10.881149] R10: 00007fff25f0fbd4 R11: 0000000000000246 R12: 000055d5cdb5c390
kernel: [ 10.881150] R13: 00007fff25f0fb00 R14: 00007fff25f0fc30 R15: 00007fff25f0fbd4
kernel: [ 10.881151] ---[ end trace dfad2d1ce058f730 ]---
Best regards,
Julian Wollrath
--
() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments
^ permalink raw reply
* Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook
From: Benjamin Herrenschmidt @ 2019-06-11 9:04 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Larry Finger, Aaro Koskinen, Christian Zigotzky, Michael Ellerman,
linuxppc-dev, linux-wireless, linux-kernel
In-Reply-To: <20190611075439.GB21815@lst.de>
On Tue, 2019-06-11 at 09:54 +0200, Christoph Hellwig wrote:
> On Tue, Jun 11, 2019 at 04:59:54PM +1000, Benjamin Herrenschmidt
> wrote:
> > Ah stupid me ... it's dma_set_mask that failed, since it has no
> > idea
> > that the calling driver is limited to lowmem.
> >
> > That's also why the "wrong" patch worked.
> >
> > So yes, a ZONE_DMA at 30-bits will work, though it's somewhat
> > overkill.
>
> Well, according to Larry it doesn't actually work, which is odd.
Oh I assume that's just a glitch in the patch :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] wlcore/wl18xx: Add invert-irq OF property for physically inverted IRQ
From: Marc Zyngier @ 2019-06-11 9:00 UTC (permalink / raw)
To: Geert Uytterhoeven, Tony Lindgren
Cc: Kalle Valo, Eugeniu Rosca, Simon Horman, David S. Miller,
Greg Kroah-Hartman, Randy Dunlap, Ulf Hansson, John Stultz,
linux-wireless, netdev, Linux Kernel Mailing List,
Spyridon Papageorgiou, Joshua Frkuska, George G . Davis,
Andrey Gusakov, Linux-Renesas, Eugeniu Rosca, eyalr,
Thomas Gleixner, Jason Cooper
In-Reply-To: <CAMuHMdUOc17ocqmt=oNmyN1UT_K7_y=af1pwjwr5PTgQL2o2OQ@mail.gmail.com>
On 11/06/2019 09:45, Geert Uytterhoeven wrote:
> CC irqchip
>
> Original thread at
> https://lore.kernel.org/lkml/20190607172958.20745-1-erosca@de.adit-jv.com/
>
> On Mon, Jun 10, 2019 at 10:30 AM Tony Lindgren <tony@atomide.com> wrote:
>> * Kalle Valo <kvalo@codeaurora.org> [190610 07:01]:
>>> Eugeniu Rosca <erosca@de.adit-jv.com> writes:
>>>
>>>> The wl1837mod datasheet [1] says about the WL_IRQ pin:
>>>>
>>>> ---8<---
>>>> SDIO available, interrupt out. Active high. [..]
>>>> Set to rising edge (active high) on powerup.
>>>> ---8<---
>>>>
>>>> That's the reason of seeing the interrupt configured as:
>>>> - IRQ_TYPE_EDGE_RISING on HiKey 960/970
>>>> - IRQ_TYPE_LEVEL_HIGH on a number of i.MX6 platforms
>>>>
>>>> We assert that all those platforms have the WL_IRQ pin connected
>>>> to the SoC _directly_ (confirmed on HiKey 970 [2]).
>>>>
>>>> That's not the case for R-Car Kingfisher extension target, which carries
>>>> a WL1837MODGIMOCT IC. There is an SN74LV1T04DBVR inverter present
>>>> between the WLAN_IRQ pin of the WL18* chip and the SoC, effectively
>>>> reversing the requirement quoted from [1]. IOW, in Kingfisher DTS
>>>> configuration we would need to use IRQ_TYPE_EDGE_FALLING or
>>>> IRQ_TYPE_LEVEL_LOW.
>>>>
>>>> Unfortunately, v4.2-rc1 commit bd763482c82ea2 ("wl18xx: wlan_irq:
>>>> support platform dependent interrupt types") made a special case out
>>>> of these interrupt types. After this commit, it is impossible to provide
>>>> an IRQ configuration via DTS which would describe an inverter present
>>>> between the WL18* chip and the SoC, generating the need for workarounds
>>>> like [3].
>>>>
>>>> Create a boolean OF property, called "invert-irq" to specify that
>>>> the WLAN_IRQ pin of WL18* is connected to the SoC via an inverter.
>>>>
>>>> This solution has been successfully tested on R-Car H3ULCB-KF-M06 using
>>>> the DTS configuration [4] combined with the "invert-irq" property.
>>>>
>>>> [1] http://www.ti.com/lit/ds/symlink/wl1837mod.pdf
>>>> [2] https://www.96boards.org/documentation/consumer/hikey/hikey970/hardware-docs/
>>>> [3] https://github.com/CogentEmbedded/meta-rcar/blob/289fbd4f8354/meta-rcar-gen3-adas/recipes-kernel/linux/linux-renesas/0024-wl18xx-do-not-invert-IRQ-on-WLxxxx-side.patch
>>>> [4] https://patchwork.kernel.org/patch/10895879/
>>>> ("arm64: dts: ulcb-kf: Add support for TI WL1837")
>>>>
>>>> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
>>>
>>> Tony&Eyal, do you agree with this?
>>
>> Yeah if there's some hardware between the WLAN device and the SoC
>> inverting the interrupt, I don't think we have clear a way to deal
>> with it short of setting up a separate irqchip that does the
>> translation.
>
> Yeah, inverting the interrupt type in DT works only for simple devices,
> that don't need configuration.
> A simple irqchip driver that just inverts the type sounds like a good
> solution to me. Does something like that already exists?
We already have plenty of that in the tree, the canonical example
probably being drivers/irqchip/irq-mtk-sysirq.c. It should be pretty
easy to turn this driver into something more generic.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH] wlcore/wl18xx: Add invert-irq OF property for physically inverted IRQ
From: Geert Uytterhoeven @ 2019-06-11 8:45 UTC (permalink / raw)
To: Tony Lindgren
Cc: Kalle Valo, Eugeniu Rosca, Simon Horman, David S. Miller,
Greg Kroah-Hartman, Randy Dunlap, Ulf Hansson, John Stultz,
linux-wireless, netdev, Linux Kernel Mailing List,
Spyridon Papageorgiou, Joshua Frkuska, George G . Davis,
Andrey Gusakov, Linux-Renesas, Eugeniu Rosca, eyalr,
Thomas Gleixner, Jason Cooper, Marc Zyngier
In-Reply-To: <20190610083012.GV5447@atomide.com>
CC irqchip
Original thread at
https://lore.kernel.org/lkml/20190607172958.20745-1-erosca@de.adit-jv.com/
On Mon, Jun 10, 2019 at 10:30 AM Tony Lindgren <tony@atomide.com> wrote:
> * Kalle Valo <kvalo@codeaurora.org> [190610 07:01]:
> > Eugeniu Rosca <erosca@de.adit-jv.com> writes:
> >
> > > The wl1837mod datasheet [1] says about the WL_IRQ pin:
> > >
> > > ---8<---
> > > SDIO available, interrupt out. Active high. [..]
> > > Set to rising edge (active high) on powerup.
> > > ---8<---
> > >
> > > That's the reason of seeing the interrupt configured as:
> > > - IRQ_TYPE_EDGE_RISING on HiKey 960/970
> > > - IRQ_TYPE_LEVEL_HIGH on a number of i.MX6 platforms
> > >
> > > We assert that all those platforms have the WL_IRQ pin connected
> > > to the SoC _directly_ (confirmed on HiKey 970 [2]).
> > >
> > > That's not the case for R-Car Kingfisher extension target, which carries
> > > a WL1837MODGIMOCT IC. There is an SN74LV1T04DBVR inverter present
> > > between the WLAN_IRQ pin of the WL18* chip and the SoC, effectively
> > > reversing the requirement quoted from [1]. IOW, in Kingfisher DTS
> > > configuration we would need to use IRQ_TYPE_EDGE_FALLING or
> > > IRQ_TYPE_LEVEL_LOW.
> > >
> > > Unfortunately, v4.2-rc1 commit bd763482c82ea2 ("wl18xx: wlan_irq:
> > > support platform dependent interrupt types") made a special case out
> > > of these interrupt types. After this commit, it is impossible to provide
> > > an IRQ configuration via DTS which would describe an inverter present
> > > between the WL18* chip and the SoC, generating the need for workarounds
> > > like [3].
> > >
> > > Create a boolean OF property, called "invert-irq" to specify that
> > > the WLAN_IRQ pin of WL18* is connected to the SoC via an inverter.
> > >
> > > This solution has been successfully tested on R-Car H3ULCB-KF-M06 using
> > > the DTS configuration [4] combined with the "invert-irq" property.
> > >
> > > [1] http://www.ti.com/lit/ds/symlink/wl1837mod.pdf
> > > [2] https://www.96boards.org/documentation/consumer/hikey/hikey970/hardware-docs/
> > > [3] https://github.com/CogentEmbedded/meta-rcar/blob/289fbd4f8354/meta-rcar-gen3-adas/recipes-kernel/linux/linux-renesas/0024-wl18xx-do-not-invert-IRQ-on-WLxxxx-side.patch
> > > [4] https://patchwork.kernel.org/patch/10895879/
> > > ("arm64: dts: ulcb-kf: Add support for TI WL1837")
> > >
> > > Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> >
> > Tony&Eyal, do you agree with this?
>
> Yeah if there's some hardware between the WLAN device and the SoC
> inverting the interrupt, I don't think we have clear a way to deal
> with it short of setting up a separate irqchip that does the
> translation.
Yeah, inverting the interrupt type in DT works only for simple devices,
that don't need configuration.
A simple irqchip driver that just inverts the type sounds like a good
solution to me. Does something like that already exists?
> But in some cases we also do not want to invert the interrupt, so
> I think this property should take IRQ_TYPE_EDGE_RISING and
> IRQ_TYPE_EDGE_RISING values to override the setting for
> the WLAN end of the hardware?
>
> Let's wait a bit longer for comments from Eyal too.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/2] mt76: mt7615: init per-channel target power
From: Lorenzo Bianconi @ 2019-06-11 7:56 UTC (permalink / raw)
To: Sven Eckelmann; +Cc: Lorenzo Bianconi, nbd, linux-wireless, ryder.lee, royluo
In-Reply-To: <3556594.76tU91ddA5@bentobox>
[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]
> On Tuesday, 11 June 2019 08:38:52 CEST Lorenzo Bianconi wrote:
> > + switch (n_chains) {
> > + case 4:
> > + target_power += 6;
> > + break;
> > + case 3:
> > + target_power += 4;
> > + break;
> > + case 2:
> > + target_power += 3;
> > + break;
> > + default:
> > + break;
> > + }
>
> Any reason why you use different value for 3 chains than ath9k? Following
> values are used in ath9k:
>
> * 1 chain: 0 dB
> * 2 chains: 3 dB (max combined gain ~3.010299956639812 dB)
> * 3 chains: 5 dB (max combined gain ~4.771212547196624 dB)
Hi Sven,
I just rounded down the values, but we can use 5db (in this case we need to fix
it even in mt76_get_power(), so I will do it in a different patch)
Regards,
Lorenzo
> * 4 chains: not supported (max combined gain 6.020599913279624 dB)
>
> Here are the definitions from ath9k (values are saved in .5 dB steps)
>
> drivers/net/wireless/ath/ath9k/eeprom.h:#define POWER_CORRECTION_FOR_TWO_CHAIN 6 /* 10*log10(2)*2 */
> drivers/net/wireless/ath/ath9k/eeprom.h:#define POWER_CORRECTION_FOR_THREE_CHAIN 10 /* 10*log10(3)*2 */
>
> Kind regards,
> Sven
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook
From: Christoph Hellwig @ 2019-06-11 7:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Christoph Hellwig, Larry Finger, Aaro Koskinen,
Christian Zigotzky, Michael Ellerman, linuxppc-dev,
linux-wireless, linux-kernel
In-Reply-To: <b30ced162fa96d0ca63b8b9629d6fe9bc5c78746.camel@kernel.crashing.org>
On Tue, Jun 11, 2019 at 04:59:54PM +1000, Benjamin Herrenschmidt wrote:
> Ah stupid me ... it's dma_set_mask that failed, since it has no idea
> that the calling driver is limited to lowmem.
>
> That's also why the "wrong" patch worked.
>
> So yes, a ZONE_DMA at 30-bits will work, though it's somewhat overkill.
Well, according to Larry it doesn't actually work, which is odd.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox