* [PATCH 14/17] mt7615: mcu: use standard signature for mt7615_mcu_msg_send
From: Lorenzo Bianconi @ 2019-05-04 15:29 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
In-Reply-To: <cover.1556981521.git.lorenzo@kernel.org>
Use mt76 common signature for mt7615_mcu_msg_send. Move skb allocation
in mt7615_mcu_msg_send and remove duplicated code. Remove
__mt7615_mcu_set_wtbl and __mt7615_mcu_set_sta_rec since now are used
just to send mcu msgs. This is a preliminary patch for mt7615-mt7603 mcu
code unification
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
.../net/wireless/mediatek/mt76/mt7615/mcu.c | 614 +++++++++---------
.../net/wireless/mediatek/mt76/mt7615/mcu.h | 19 +-
2 files changed, 337 insertions(+), 296 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index 0632b506dd57..841631987eee 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -57,9 +57,6 @@ static int __mt7615_mcu_msg_send(struct mt7615_dev *dev, struct sk_buff *skb,
u32 val;
__le32 *txd;
- if (!skb)
- return -EINVAL;
-
seq = ++dev->mt76.mmio.mcu.msg_seq & 0xf;
if (!seq)
seq = ++dev->mt76.mmio.mcu.msg_seq & 0xf;
@@ -116,19 +113,25 @@ static int __mt7615_mcu_msg_send(struct mt7615_dev *dev, struct sk_buff *skb,
}
static int
-mt7615_mcu_msg_send(struct mt7615_dev *dev, struct sk_buff *skb, int cmd)
+mt7615_mcu_msg_send(struct mt7615_dev *dev, int cmd, const void *data,
+ int len, bool wait_resp)
{
unsigned long expires = jiffies + 10 * HZ;
struct mt7615_mcu_rxd *rxd;
+ struct sk_buff *skb;
int ret, seq;
+ skb = mt7615_mcu_msg_alloc(data, len);
+ if (!skb)
+ return -ENOMEM;
+
mutex_lock(&dev->mt76.mmio.mcu.mutex);
ret = __mt7615_mcu_msg_send(dev, skb, cmd, &seq);
if (ret)
goto out;
- while (1) {
+ while (wait_resp) {
skb = mt76_mcu_get_response(&dev->mt76, expires);
if (!skb) {
dev_err(dev->mt76.dev, "Message %d (seq %d) timeout\n",
@@ -167,9 +170,9 @@ static int mt7615_mcu_init_download(struct mt7615_dev *dev, u32 addr,
.len = cpu_to_le32(len),
.mode = cpu_to_le32(mode),
};
- struct sk_buff *skb = mt7615_mcu_msg_alloc(&req, sizeof(req));
- return mt7615_mcu_msg_send(dev, skb, -MCU_CMD_TARGET_ADDRESS_LEN_REQ);
+ return mt7615_mcu_msg_send(dev, -MCU_CMD_TARGET_ADDRESS_LEN_REQ,
+ &req, sizeof(req), true);
}
static int mt7615_mcu_send_firmware(struct mt7615_dev *dev, const void *data,
@@ -208,16 +211,15 @@ static int mt7615_mcu_start_firmware(struct mt7615_dev *dev, u32 addr,
.option = cpu_to_le32(option),
.addr = cpu_to_le32(addr),
};
- struct sk_buff *skb = mt7615_mcu_msg_alloc(&req, sizeof(req));
- return mt7615_mcu_msg_send(dev, skb, -MCU_CMD_FW_START_REQ);
+ return mt7615_mcu_msg_send(dev, -MCU_CMD_FW_START_REQ,
+ &req, sizeof(req), true);
}
static int mt7615_mcu_restart(struct mt7615_dev *dev)
{
- struct sk_buff *skb = mt7615_mcu_msg_alloc(NULL, 0);
-
- return mt7615_mcu_msg_send(dev, skb, -MCU_CMD_RESTART_DL_REQ);
+ return mt7615_mcu_msg_send(dev, -MCU_CMD_RESTART_DL_REQ,
+ NULL, 0, true);
}
static int mt7615_mcu_patch_sem_ctrl(struct mt7615_dev *dev, bool get)
@@ -227,9 +229,9 @@ static int mt7615_mcu_patch_sem_ctrl(struct mt7615_dev *dev, bool get)
} req = {
.op = cpu_to_le32(get ? PATCH_SEM_GET : PATCH_SEM_RELEASE),
};
- struct sk_buff *skb = mt7615_mcu_msg_alloc(&req, sizeof(req));
- return mt7615_mcu_msg_send(dev, skb, -MCU_CMD_PATCH_SEM_CONTROL);
+ return mt7615_mcu_msg_send(dev, -MCU_CMD_PATCH_SEM_CONTROL,
+ &req, sizeof(req), true);
}
static int mt7615_mcu_start_patch(struct mt7615_dev *dev)
@@ -240,9 +242,9 @@ static int mt7615_mcu_start_patch(struct mt7615_dev *dev)
} req = {
.check_crc = 0,
};
- struct sk_buff *skb = mt7615_mcu_msg_alloc(&req, sizeof(req));
- return mt7615_mcu_msg_send(dev, skb, -MCU_CMD_PATCH_FINISH_REQ);
+ return mt7615_mcu_msg_send(dev, -MCU_CMD_PATCH_FINISH_REQ,
+ &req, sizeof(req), true);
}
static int mt7615_driver_own(struct mt7615_dev *dev)
@@ -502,9 +504,6 @@ void mt7615_mcu_exit(struct mt7615_dev *dev)
int mt7615_mcu_set_eeprom(struct mt7615_dev *dev)
{
- struct req_data {
- u8 val;
- } __packed;
struct {
u8 buffer_mode;
u8 pad;
@@ -513,22 +512,22 @@ int mt7615_mcu_set_eeprom(struct mt7615_dev *dev)
.buffer_mode = 1,
.len = __MT_EE_MAX - MT_EE_NIC_CONF_0,
};
- struct sk_buff *skb;
- struct req_data *data;
- const int size = (__MT_EE_MAX - MT_EE_NIC_CONF_0) *
- sizeof(struct req_data);
- u8 *eep = (u8 *)dev->mt76.eeprom.data;
- u16 off;
+ int ret, len = sizeof(req_hdr) + __MT_EE_MAX - MT_EE_NIC_CONF_0;
+ u8 *req, *eep = (u8 *)dev->mt76.eeprom.data;
+
+ req = kzalloc(len, GFP_KERNEL);
+ if (!req)
+ return -ENOMEM;
- skb = mt7615_mcu_msg_alloc(NULL, size + sizeof(req_hdr));
- memcpy(skb_put(skb, sizeof(req_hdr)), &req_hdr, sizeof(req_hdr));
- data = (struct req_data *)skb_put(skb, size);
- memset(data, 0, size);
+ memcpy(req, &req_hdr, sizeof(req_hdr));
+ memcpy(req + sizeof(req_hdr), eep + MT_EE_NIC_CONF_0,
+ __MT_EE_MAX - MT_EE_NIC_CONF_0);
- for (off = MT_EE_NIC_CONF_0; off < __MT_EE_MAX; off++)
- data[off - MT_EE_NIC_CONF_0].val = eep[off];
+ ret = mt7615_mcu_msg_send(dev, MCU_EXT_CMD_EFUSE_BUFFER_MODE,
+ req, len, true);
+ kfree(req);
- return mt7615_mcu_msg_send(dev, skb, MCU_EXT_CMD_EFUSE_BUFFER_MODE);
+ return ret;
}
int mt7615_mcu_init_mac(struct mt7615_dev *dev)
@@ -541,9 +540,9 @@ int mt7615_mcu_init_mac(struct mt7615_dev *dev)
.enable = 1,
.band = 0,
};
- struct sk_buff *skb = mt7615_mcu_msg_alloc(&req, sizeof(req));
- return mt7615_mcu_msg_send(dev, skb, MCU_EXT_CMD_MAC_INIT_CTRL);
+ return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_MAC_INIT_CTRL,
+ &req, sizeof(req), true);
}
int mt7615_mcu_set_rts_thresh(struct mt7615_dev *dev, u32 val)
@@ -560,9 +559,9 @@ int mt7615_mcu_set_rts_thresh(struct mt7615_dev *dev, u32 val)
.len_thresh = cpu_to_le32(val),
.pkt_thresh = cpu_to_le32(0x2),
};
- struct sk_buff *skb = mt7615_mcu_msg_alloc(&req, sizeof(req));
- return mt7615_mcu_msg_send(dev, skb, MCU_EXT_CMD_PROTECT_CTRL);
+ return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_PROTECT_CTRL,
+ &req, sizeof(req), true);
}
int mt7615_mcu_set_wmm(struct mt7615_dev *dev, u8 queue,
@@ -588,7 +587,6 @@ int mt7615_mcu_set_wmm(struct mt7615_dev *dev, u8 queue,
.aifs = params->aifs,
.txop = cpu_to_le16(params->txop),
};
- struct sk_buff *skb;
if (params->cw_min) {
req.valid |= WMM_CW_MIN_SET;
@@ -599,8 +597,8 @@ int mt7615_mcu_set_wmm(struct mt7615_dev *dev, u8 queue,
req.cw_max = cpu_to_le16(params->cw_max);
}
- skb = mt7615_mcu_msg_alloc(&req, sizeof(req));
- return mt7615_mcu_msg_send(dev, skb, MCU_EXT_CMD_EDCA_UPDATE);
+ return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_EDCA_UPDATE,
+ &req, sizeof(req), true);
}
int mt7615_mcu_ctrl_pm_state(struct mt7615_dev *dev, int enter)
@@ -628,9 +626,9 @@ int mt7615_mcu_ctrl_pm_state(struct mt7615_dev *dev, int enter)
.pm_state = (enter) ? ENTER_PM_STATE : EXIT_PM_STATE,
.band_idx = 0,
};
- struct sk_buff *skb = mt7615_mcu_msg_alloc(&req, sizeof(req));
- return mt7615_mcu_msg_send(dev, skb, MCU_EXT_CMD_PM_STATE_CTRL);
+ return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_PM_STATE_CTRL,
+ &req, sizeof(req), true);
}
int mt7615_mcu_set_dev_info(struct mt7615_dev *dev,
@@ -666,14 +664,10 @@ int mt7615_mcu_set_dev_info(struct mt7615_dev *dev,
.band_idx = mvif->band_idx,
},
};
- struct sk_buff *skb;
memcpy(data.tlv.omac_addr, vif->addr, ETH_ALEN);
- skb = mt7615_mcu_msg_alloc(&data, sizeof(data));
- if (!skb)
- return -ENOMEM;
-
- return mt7615_mcu_msg_send(dev, skb, MCU_EXT_CMD_DEV_INFO_UPDATE);
+ return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_DEV_INFO_UPDATE,
+ &data, sizeof(data), true);
}
static void
@@ -744,7 +738,6 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
u32 conn_type = 0, net_type = NETWORK_INFRA;
u8 *buf, *data, tx_wlan_idx = 0;
struct req_hdr *hdr;
- struct sk_buff *skb;
if (en) {
len += sizeof(struct bss_info_omac);
@@ -819,46 +812,13 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
}
}
- skb = mt7615_mcu_msg_alloc(buf, len);
- if (!skb) {
- ret = -ENOMEM;
- goto out;
- }
-
- ret = mt7615_mcu_msg_send(dev, skb, MCU_EXT_CMD_BSS_INFO_UPDATE);
-
-out:
+ ret = mt7615_mcu_msg_send(dev, MCU_EXT_CMD_BSS_INFO_UPDATE,
+ buf, len, true);
kfree(buf);
return ret;
}
-static int
-__mt7615_mcu_set_wtbl(struct mt7615_dev *dev, int wlan_idx,
- int operation, int ntlv, void *buf,
- int buf_len)
-{
- struct req_hdr {
- u8 wlan_idx;
- u8 operation;
- __le16 tlv_num;
- u8 rsv[4];
- } __packed req_hdr = {
- .wlan_idx = wlan_idx,
- .operation = operation,
- .tlv_num = cpu_to_le16(ntlv),
- };
- struct sk_buff *skb;
-
- skb = mt7615_mcu_msg_alloc(NULL, sizeof(req_hdr) + buf_len);
- memcpy(skb_put(skb, sizeof(req_hdr)), &req_hdr, sizeof(req_hdr));
-
- if (buf && buf_len)
- memcpy(skb_put(skb, buf_len), buf, buf_len);
-
- return mt7615_mcu_msg_send(dev, skb, MCU_EXT_CMD_WTBL_UPDATE);
-}
-
static enum mt7615_cipher_type
mt7615_get_key_info(struct ieee80211_key_conf *key, u8 *key_data)
{
@@ -896,28 +856,38 @@ int mt7615_mcu_set_wtbl_key(struct mt7615_dev *dev, int wcid,
struct ieee80211_key_conf *key,
enum set_key_cmd cmd)
{
- struct wtbl_sec_key wtbl_sec_key = {0};
- int buf_len = sizeof(struct wtbl_sec_key);
- u8 cipher;
-
- wtbl_sec_key.tag = cpu_to_le16(WTBL_SEC_KEY);
- wtbl_sec_key.len = cpu_to_le16(buf_len);
- wtbl_sec_key.add = cmd;
+ struct {
+ struct wtbl_req_hdr hdr;
+ struct wtbl_sec_key key;
+ } req = {
+ .hdr = {
+ .wlan_idx = wcid,
+ .operation = WTBL_SET,
+ .tlv_num = cpu_to_le16(1),
+ },
+ .key = {
+ .tag = cpu_to_le16(WTBL_SEC_KEY),
+ .len = cpu_to_le16(sizeof(struct wtbl_sec_key)),
+ .add = cmd,
+ },
+ };
if (cmd == SET_KEY) {
- cipher = mt7615_get_key_info(key, wtbl_sec_key.key_material);
+ u8 cipher;
+
+ cipher = mt7615_get_key_info(key, req.key.key_material);
if (cipher == MT_CIPHER_NONE && key)
return -EOPNOTSUPP;
- wtbl_sec_key.cipher_id = cipher;
- wtbl_sec_key.key_id = key->keyidx;
- wtbl_sec_key.key_len = key->keylen;
+ req.key.cipher_id = cipher;
+ req.key.key_id = key->keyidx;
+ req.key.key_len = key->keylen;
} else {
- wtbl_sec_key.key_len = sizeof(wtbl_sec_key.key_material);
+ req.key.key_len = sizeof(req.key.key_material);
}
- return __mt7615_mcu_set_wtbl(dev, wcid, WTBL_SET, 1,
- &wtbl_sec_key, buf_len);
+ return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_WTBL_UPDATE,
+ &req, sizeof(req), true);
}
static int
@@ -925,9 +895,15 @@ mt7615_mcu_add_wtbl_bmc(struct mt7615_dev *dev,
struct mt7615_vif *mvif)
{
struct {
+ struct wtbl_req_hdr hdr;
struct wtbl_generic g_wtbl;
struct wtbl_rx rx_wtbl;
- } data = {
+ } req = {
+ .hdr = {
+ .wlan_idx = mvif->sta.wcid.idx,
+ .operation = WTBL_RESET_AND_SET,
+ .tlv_num = cpu_to_le16(2),
+ },
.g_wtbl = {
.tag = cpu_to_le16(WTBL_GENERIC),
.len = cpu_to_le16(sizeof(struct wtbl_generic)),
@@ -941,12 +917,10 @@ mt7615_mcu_add_wtbl_bmc(struct mt7615_dev *dev,
.rv = 1,
},
};
- eth_broadcast_addr(data.g_wtbl.peer_addr);
+ eth_broadcast_addr(req.g_wtbl.peer_addr);
- return __mt7615_mcu_set_wtbl(dev, mvif->sta.wcid.idx,
- WTBL_RESET_AND_SET, 2, &data,
- sizeof(struct wtbl_generic) +
- sizeof(struct wtbl_rx));
+ return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_WTBL_UPDATE,
+ &req, sizeof(req), true);
}
int mt7615_mcu_wtbl_bmc(struct mt7615_dev *dev,
@@ -954,11 +928,17 @@ int mt7615_mcu_wtbl_bmc(struct mt7615_dev *dev,
{
struct mt7615_vif *mvif = (struct mt7615_vif *)vif->drv_priv;
- if (enable)
- return mt7615_mcu_add_wtbl_bmc(dev, mvif);
+ if (!enable) {
+ struct wtbl_req_hdr req = {
+ .wlan_idx = mvif->sta.wcid.idx,
+ .operation = WTBL_RESET_AND_SET,
+ };
- return __mt7615_mcu_set_wtbl(dev, mvif->sta.wcid.idx,
- WTBL_RESET_AND_SET, 0, NULL, 0);
+ return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_WTBL_UPDATE,
+ &req, sizeof(req), true);
+ }
+
+ return mt7615_mcu_add_wtbl_bmc(dev, mvif);
}
int mt7615_mcu_add_wtbl(struct mt7615_dev *dev, struct ieee80211_vif *vif,
@@ -967,9 +947,15 @@ int mt7615_mcu_add_wtbl(struct mt7615_dev *dev, struct ieee80211_vif *vif,
struct mt7615_vif *mvif = (struct mt7615_vif *)vif->drv_priv;
struct mt7615_sta *msta = (struct mt7615_sta *)sta->drv_priv;
struct {
+ struct wtbl_req_hdr hdr;
struct wtbl_generic g_wtbl;
struct wtbl_rx rx_wtbl;
- } data = {
+ } req = {
+ .hdr = {
+ .wlan_idx = msta->wcid.idx,
+ .operation = WTBL_RESET_AND_SET,
+ .tlv_num = cpu_to_le16(2),
+ },
.g_wtbl = {
.tag = cpu_to_le16(WTBL_GENERIC),
.len = cpu_to_le16(sizeof(struct wtbl_generic)),
@@ -985,81 +971,69 @@ int mt7615_mcu_add_wtbl(struct mt7615_dev *dev, struct ieee80211_vif *vif,
.rv = 1,
},
};
- memcpy(data.g_wtbl.peer_addr, sta->addr, ETH_ALEN);
+ memcpy(req.g_wtbl.peer_addr, sta->addr, ETH_ALEN);
- return __mt7615_mcu_set_wtbl(dev, msta->wcid.idx,
- WTBL_RESET_AND_SET, 2, &data,
- sizeof(struct wtbl_generic) +
- sizeof(struct wtbl_rx));
+ return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_WTBL_UPDATE,
+ &req, sizeof(req), true);
}
int mt7615_mcu_del_wtbl(struct mt7615_dev *dev,
struct ieee80211_sta *sta)
{
struct mt7615_sta *msta = (struct mt7615_sta *)sta->drv_priv;
+ struct wtbl_req_hdr req = {
+ .wlan_idx = msta->wcid.idx,
+ .operation = WTBL_RESET_AND_SET,
+ };
- return __mt7615_mcu_set_wtbl(dev, msta->wcid.idx,
- WTBL_RESET_AND_SET, 0, NULL, 0);
+ return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_WTBL_UPDATE,
+ &req, sizeof(req), true);
}
int mt7615_mcu_del_wtbl_all(struct mt7615_dev *dev)
{
- return __mt7615_mcu_set_wtbl(dev, 0, WTBL_RESET_ALL, 0, NULL, 0);
-}
-
-static int
-__mt7615_mcu_set_sta_rec(struct mt7615_dev *dev, int bss_idx,
- int wlan_idx, int muar_idx, int ntlv,
- void *buf, int buf_len)
-{
- struct req_hdr {
- u8 bss_idx;
- u8 wlan_idx;
- __le16 tlv_num;
- u8 is_tlv_append;
- u8 muar_idx;
- u8 rsv[2];
- } __packed req_hdr = {
- .bss_idx = bss_idx,
- .wlan_idx = wlan_idx,
- .tlv_num = cpu_to_le16(ntlv),
- .is_tlv_append = !!ntlv,
- .muar_idx = muar_idx,
+ struct wtbl_req_hdr req = {
+ .operation = WTBL_RESET_ALL,
};
- struct sk_buff *skb;
-
- skb = mt7615_mcu_msg_alloc(NULL, sizeof(req_hdr) + buf_len);
- memcpy(skb_put(skb, sizeof(req_hdr)), &req_hdr, sizeof(req_hdr));
-
- if (buf && buf_len)
- memcpy(skb_put(skb, buf_len), buf, buf_len);
- return mt7615_mcu_msg_send(dev, skb, MCU_EXT_CMD_STA_REC_UPDATE);
+ return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_WTBL_UPDATE,
+ &req, sizeof(req), true);
}
int mt7615_mcu_set_sta_rec_bmc(struct mt7615_dev *dev,
struct ieee80211_vif *vif, bool en)
{
struct mt7615_vif *mvif = (struct mt7615_vif *)vif->drv_priv;
- struct sta_rec_basic sta_rec_basic = {0};
- int buf_len = sizeof(struct sta_rec_basic);
+ struct {
+ struct sta_req_hdr hdr;
+ struct sta_rec_basic basic;
+ } req = {
+ .hdr = {
+ .bss_idx = mvif->idx,
+ .wlan_idx = mvif->sta.wcid.idx,
+ .tlv_num = cpu_to_le16(1),
+ .is_tlv_append = 1,
+ .muar_idx = mvif->omac_idx,
+ },
+ .basic = {
+ .tag = cpu_to_le16(STA_REC_BASIC),
+ .len = cpu_to_le16(sizeof(struct sta_rec_basic)),
+ .conn_type = cpu_to_le32(CONNECTION_INFRA_BC),
+ },
+ };
+ eth_broadcast_addr(req.basic.peer_addr);
- sta_rec_basic.tag = cpu_to_le16(STA_REC_BASIC);
- sta_rec_basic.len = cpu_to_le16(buf_len);
- sta_rec_basic.conn_type = cpu_to_le32(CONNECTION_INFRA_BC);
- eth_broadcast_addr(sta_rec_basic.peer_addr);
if (en) {
- sta_rec_basic.conn_state = CONN_STATE_PORT_SECURE;
- sta_rec_basic.extra_info =
- cpu_to_le16(EXTRA_INFO_VER | EXTRA_INFO_NEW);
+ req.basic.conn_state = CONN_STATE_PORT_SECURE;
+ req.basic.extra_info = cpu_to_le16(EXTRA_INFO_VER |
+ EXTRA_INFO_NEW);
} else {
- sta_rec_basic.conn_state = CONN_STATE_DISCONNECT;
- sta_rec_basic.extra_info = cpu_to_le16(EXTRA_INFO_VER);
+ req.basic.conn_state = CONN_STATE_DISCONNECT;
+ req.basic.extra_info = cpu_to_le16(EXTRA_INFO_VER);
}
- return __mt7615_mcu_set_sta_rec(dev, mvif->idx, mvif->sta.wcid.idx,
- mvif->omac_idx, 1, &sta_rec_basic,
- buf_len);
+ return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_STA_REC_UPDATE,
+ &req, sizeof(req), true);
}
static void sta_rec_convert_vif_type(enum nl80211_iftype type, u32 *conn_type)
@@ -1084,36 +1058,49 @@ int mt7615_mcu_set_sta_rec(struct mt7615_dev *dev, struct ieee80211_vif *vif,
{
struct mt7615_vif *mvif = (struct mt7615_vif *)vif->drv_priv;
struct mt7615_sta *msta = (struct mt7615_sta *)sta->drv_priv;
- struct sta_rec_basic sta_rec_basic = {0};
- int buf_len = sizeof(struct sta_rec_basic);
u32 conn_type = 0;
- sta_rec_convert_vif_type(vif->type, &conn_type);
+ struct {
+ struct sta_req_hdr hdr;
+ struct sta_rec_basic basic;
+ } req = {
+ .hdr = {
+ .bss_idx = mvif->idx,
+ .wlan_idx = msta->wcid.idx,
+ .tlv_num = cpu_to_le16(1),
+ .is_tlv_append = 1,
+ .muar_idx = mvif->omac_idx,
+ },
+ .basic = {
+ .tag = cpu_to_le16(STA_REC_BASIC),
+ .len = cpu_to_le16(sizeof(struct sta_rec_basic)),
+ .qos = sta->wme,
+ .aid = cpu_to_le16(sta->aid),
+ },
+ };
+ memcpy(req.basic.peer_addr, sta->addr, ETH_ALEN);
- sta_rec_basic.tag = cpu_to_le16(STA_REC_BASIC);
- sta_rec_basic.len = cpu_to_le16(buf_len);
- sta_rec_basic.conn_type = cpu_to_le32(conn_type);
- sta_rec_basic.qos = sta->wme;
- sta_rec_basic.aid = cpu_to_le16(sta->aid);
- memcpy(sta_rec_basic.peer_addr, sta->addr, ETH_ALEN);
+ sta_rec_convert_vif_type(vif->type, &conn_type);
+ req.basic.conn_type = cpu_to_le32(conn_type);
if (en) {
- sta_rec_basic.conn_state = CONN_STATE_PORT_SECURE;
- sta_rec_basic.extra_info =
- cpu_to_le16(EXTRA_INFO_VER | EXTRA_INFO_NEW);
+ req.basic.conn_state = CONN_STATE_PORT_SECURE;
+ req.basic.extra_info = cpu_to_le16(EXTRA_INFO_VER |
+ EXTRA_INFO_NEW);
} else {
- sta_rec_basic.conn_state = CONN_STATE_DISCONNECT;
- sta_rec_basic.extra_info = cpu_to_le16(EXTRA_INFO_VER);
+ req.basic.conn_state = CONN_STATE_DISCONNECT;
+ req.basic.extra_info = cpu_to_le16(EXTRA_INFO_VER);
}
- return __mt7615_mcu_set_sta_rec(dev, mvif->idx, msta->wcid.idx,
- mvif->omac_idx, 1, &sta_rec_basic,
- buf_len);
+ return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_STA_REC_UPDATE,
+ &req, sizeof(req), true);
}
int mt7615_mcu_set_bcn(struct mt7615_dev *dev, struct ieee80211_vif *vif,
int en)
{
+ struct mt7615_vif *mvif = (struct mt7615_vif *)vif->drv_priv;
+ struct mt76_wcid *wcid = &dev->mt76.global_wcid;
struct req {
u8 omac_idx;
u8 enable;
@@ -1129,14 +1116,18 @@ int mt7615_mcu_set_bcn(struct mt7615_dev *dev, struct ieee80211_vif *vif,
/* bss color change */
u8 bcc_cnt;
__le16 bcc_ie_pos;
- } __packed req = {0};
- struct mt7615_vif *mvif = (struct mt7615_vif *)vif->drv_priv;
- struct mt76_wcid *wcid = &dev->mt76.global_wcid;
- struct sk_buff *skb;
+ } __packed req = {
+ .omac_idx = mvif->omac_idx,
+ .enable = en,
+ .wlan_idx = wcid->idx,
+ .band_idx = mvif->band_idx,
+ /* pky_type: 0 for bcn, 1 for tim */
+ .pkt_type = 0,
+ };
u16 tim_off, tim_len;
+ struct sk_buff *skb;
skb = ieee80211_beacon_get_tim(mt76_hw(dev), vif, &tim_off, &tim_len);
-
if (!skb)
return -EINVAL;
@@ -1149,20 +1140,13 @@ int mt7615_mcu_set_bcn(struct mt7615_dev *dev, struct ieee80211_vif *vif,
mt7615_mac_write_txwi(dev, (__le32 *)(req.pkt), skb, wcid, NULL,
0, NULL);
memcpy(req.pkt + MT_TXD_SIZE, skb->data, skb->len);
-
- req.omac_idx = mvif->omac_idx;
- req.enable = en;
- req.wlan_idx = wcid->idx;
- req.band_idx = mvif->band_idx;
- /* pky_type: 0 for bcn, 1 for tim */
- req.pkt_type = 0;
req.pkt_len = cpu_to_le16(MT_TXD_SIZE + skb->len);
req.tim_ie_pos = cpu_to_le16(MT_TXD_SIZE + tim_off);
dev_kfree_skb(skb);
- skb = mt7615_mcu_msg_alloc(&req, sizeof(req));
- return mt7615_mcu_msg_send(dev, skb, MCU_EXT_CMD_BCN_OFFLOAD);
+ return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_BCN_OFFLOAD,
+ &req, sizeof(req), true);
}
int mt7615_mcu_set_channel(struct mt7615_dev *dev)
@@ -1187,7 +1171,6 @@ int mt7615_mcu_set_channel(struct mt7615_dev *dev)
u8 txpower_sku[53];
u8 rsv2[3];
} req = {0};
- struct sk_buff *skb;
int ret;
req.control_chan = chdef->chan->hw_value;
@@ -1223,16 +1206,15 @@ int mt7615_mcu_set_channel(struct mt7615_dev *dev)
default:
req.bw = CMD_CBW_20MHZ;
}
-
memset(req.txpower_sku, 0x3f, 49);
- skb = mt7615_mcu_msg_alloc(&req, sizeof(req));
- ret = mt7615_mcu_msg_send(dev, skb, MCU_EXT_CMD_CHANNEL_SWITCH);
+ ret = mt7615_mcu_msg_send(dev, MCU_EXT_CMD_CHANNEL_SWITCH,
+ &req, sizeof(req), true);
if (ret)
return ret;
- skb = mt7615_mcu_msg_alloc(&req, sizeof(req));
- return mt7615_mcu_msg_send(dev, skb, MCU_EXT_CMD_SET_RX_PATH);
+ return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_SET_RX_PATH,
+ &req, sizeof(req), true);
}
int mt7615_mcu_set_ht_cap(struct mt7615_dev *dev, struct ieee80211_vif *vif,
@@ -1240,9 +1222,11 @@ int mt7615_mcu_set_ht_cap(struct mt7615_dev *dev, struct ieee80211_vif *vif,
{
struct mt7615_sta *msta = (struct mt7615_sta *)sta->drv_priv;
struct mt7615_vif *mvif = (struct mt7615_vif *)vif->drv_priv;
- struct wtbl_ht *wtbl_ht;
+ struct wtbl_req_hdr *wtbl_hdr;
+ struct sta_req_hdr *sta_hdr;
struct wtbl_raw *wtbl_raw;
- struct sta_rec_ht *sta_rec_ht;
+ struct sta_rec_ht *sta_ht;
+ struct wtbl_ht *wtbl_ht;
int buf_len, ret, ntlv = 2;
u32 msk, val = 0;
u8 *buf;
@@ -1251,15 +1235,20 @@ int mt7615_mcu_set_ht_cap(struct mt7615_dev *dev, struct ieee80211_vif *vif,
if (!buf)
return -ENOMEM;
+ wtbl_hdr = (struct wtbl_req_hdr *)buf;
+ wtbl_hdr->wlan_idx = msta->wcid.idx;
+ wtbl_hdr->operation = WTBL_SET;
+ buf_len = sizeof(*wtbl_hdr);
+
/* ht basic */
- buf_len = sizeof(*wtbl_ht);
- wtbl_ht = (struct wtbl_ht *)buf;
+ wtbl_ht = (struct wtbl_ht *)(buf + buf_len);
wtbl_ht->tag = cpu_to_le16(WTBL_HT);
wtbl_ht->len = cpu_to_le16(sizeof(*wtbl_ht));
wtbl_ht->ht = 1;
wtbl_ht->ldpc = sta->ht_cap.cap & IEEE80211_HT_CAP_LDPC_CODING;
wtbl_ht->af = sta->ht_cap.ampdu_factor;
wtbl_ht->mm = sta->ht_cap.ampdu_density;
+ buf_len += sizeof(*wtbl_ht);
if (sta->ht_cap.cap & IEEE80211_HT_CAP_SGI_20)
val |= MT_WTBL_W5_SHORT_GI_20;
@@ -1309,41 +1298,48 @@ int mt7615_mcu_set_ht_cap(struct mt7615_dev *dev, struct ieee80211_vif *vif,
wtbl_raw->msk = cpu_to_le32(~msk);
wtbl_raw->val = cpu_to_le32(val);
- ret = __mt7615_mcu_set_wtbl(dev, msta->wcid.idx, WTBL_SET, ntlv,
- buf, buf_len);
- if (ret) {
- kfree(buf);
- return ret;
- }
+ wtbl_hdr->tlv_num = cpu_to_le16(ntlv);
+ ret = mt7615_mcu_msg_send(dev, MCU_EXT_CMD_WTBL_UPDATE,
+ buf, buf_len, true);
+ if (ret)
+ goto out;
memset(buf, 0, MT7615_WTBL_UPDATE_MAX_SIZE);
- buf_len = sizeof(*sta_rec_ht);
- sta_rec_ht = (struct sta_rec_ht *)buf;
- sta_rec_ht->tag = cpu_to_le16(STA_REC_HT);
- sta_rec_ht->len = cpu_to_le16(sizeof(*sta_rec_ht));
- sta_rec_ht->ht_cap = cpu_to_le16(sta->ht_cap.cap);
- ntlv = 1;
+ sta_hdr = (struct sta_req_hdr *)buf;
+ sta_hdr->bss_idx = mvif->idx;
+ sta_hdr->wlan_idx = msta->wcid.idx;
+ sta_hdr->is_tlv_append = 1;
+ ntlv = sta->vht_cap.vht_supported ? 2 : 1;
+ sta_hdr->tlv_num = cpu_to_le16(ntlv);
+ sta_hdr->muar_idx = mvif->omac_idx;
+ buf_len = sizeof(*sta_hdr);
+
+ sta_ht = (struct sta_rec_ht *)(buf + buf_len);
+ sta_ht->tag = cpu_to_le16(STA_REC_HT);
+ sta_ht->len = cpu_to_le16(sizeof(*sta_ht));
+ sta_ht->ht_cap = cpu_to_le16(sta->ht_cap.cap);
+ buf_len += sizeof(*sta_ht);
if (sta->vht_cap.vht_supported) {
- struct sta_rec_vht *sta_rec_vht;
-
- sta_rec_vht = (struct sta_rec_vht *)(buf + buf_len);
- buf_len += sizeof(*sta_rec_vht);
- sta_rec_vht->tag = cpu_to_le16(STA_REC_VHT);
- sta_rec_vht->len = cpu_to_le16(sizeof(*sta_rec_vht));
- sta_rec_vht->vht_cap = cpu_to_le32(sta->vht_cap.cap);
- sta_rec_vht->vht_rx_mcs_map =
+ struct sta_rec_vht *sta_vht;
+
+ sta_vht = (struct sta_rec_vht *)(buf + buf_len);
+ buf_len += sizeof(*sta_vht);
+ sta_vht->tag = cpu_to_le16(STA_REC_VHT);
+ sta_vht->len = cpu_to_le16(sizeof(*sta_vht));
+ sta_vht->vht_cap = cpu_to_le32(sta->vht_cap.cap);
+ sta_vht->vht_rx_mcs_map =
cpu_to_le16(sta->vht_cap.vht_mcs.rx_mcs_map);
- sta_rec_vht->vht_tx_mcs_map =
+ sta_vht->vht_tx_mcs_map =
cpu_to_le16(sta->vht_cap.vht_mcs.tx_mcs_map);
- ntlv++;
}
- ret = __mt7615_mcu_set_sta_rec(dev, mvif->idx, msta->wcid.idx,
- mvif->omac_idx, ntlv, buf,
- buf_len);
+ ret = mt7615_mcu_msg_send(dev, MCU_EXT_CMD_STA_REC_UPDATE,
+ buf, buf_len, true);
+out:
kfree(buf);
+
return ret;
}
@@ -1351,100 +1347,128 @@ int mt7615_mcu_set_tx_ba(struct mt7615_dev *dev,
struct ieee80211_ampdu_params *params,
bool add)
{
- struct ieee80211_sta *sta = params->sta;
- struct mt7615_sta *msta = (struct mt7615_sta *)sta->drv_priv;
+ struct mt7615_sta *msta = (struct mt7615_sta *)params->sta->drv_priv;
struct mt7615_vif *mvif = msta->vif;
- u8 ba_range[8] = {4, 8, 12, 24, 36, 48, 54, 64};
- u16 tid = params->tid;
- u16 ba_size = params->buf_size;
- u16 ssn = params->ssn;
- struct wtbl_ba wtbl_ba = {0};
- struct sta_rec_ba sta_rec_ba = {0};
- int ret, buf_len;
-
- buf_len = sizeof(struct wtbl_ba);
-
- wtbl_ba.tag = cpu_to_le16(WTBL_BA);
- wtbl_ba.len = cpu_to_le16(buf_len);
- wtbl_ba.tid = tid;
- wtbl_ba.ba_type = MT_BA_TYPE_ORIGINATOR;
+ struct {
+ struct wtbl_req_hdr hdr;
+ struct wtbl_ba ba;
+ } wtbl_req = {
+ .hdr = {
+ .wlan_idx = msta->wcid.idx,
+ .operation = WTBL_SET,
+ .tlv_num = cpu_to_le16(1),
+ },
+ .ba = {
+ .tag = cpu_to_le16(WTBL_BA),
+ .len = cpu_to_le16(sizeof(struct wtbl_ba)),
+ .tid = params->tid,
+ .ba_type = MT_BA_TYPE_ORIGINATOR,
+ .sn = add ? cpu_to_le16(params->ssn) : 0,
+ .ba_en = add,
+ },
+ };
+ struct {
+ struct sta_req_hdr hdr;
+ struct sta_rec_ba ba;
+ } sta_req = {
+ .hdr = {
+ .bss_idx = mvif->idx,
+ .wlan_idx = msta->wcid.idx,
+ .tlv_num = cpu_to_le16(1),
+ .is_tlv_append = 1,
+ .muar_idx = mvif->omac_idx,
+ },
+ .ba = {
+ .tag = cpu_to_le16(STA_REC_BA),
+ .len = cpu_to_le16(sizeof(struct sta_rec_ba)),
+ .tid = params->tid,
+ .ba_type = MT_BA_TYPE_ORIGINATOR,
+ .amsdu = params->amsdu,
+ .ba_en = add << params->tid,
+ .ssn = cpu_to_le16(params->ssn),
+ .winsize = cpu_to_le16(params->buf_size),
+ },
+ };
+ int ret;
if (add) {
- u8 idx;
+ u8 idx, ba_range[] = { 4, 8, 12, 24, 36, 48, 54, 64 };
for (idx = 7; idx > 0; idx--) {
- if (ba_size >= ba_range[idx])
+ if (params->buf_size >= ba_range[idx])
break;
}
- wtbl_ba.sn = cpu_to_le16(ssn);
- wtbl_ba.ba_en = 1;
- wtbl_ba.ba_winsize_idx = idx;
+ wtbl_req.ba.ba_winsize_idx = idx;
}
- ret = __mt7615_mcu_set_wtbl(dev, msta->wcid.idx, WTBL_SET, 1,
- &wtbl_ba, buf_len);
+ ret = mt7615_mcu_msg_send(dev, MCU_EXT_CMD_WTBL_UPDATE,
+ &wtbl_req, sizeof(wtbl_req), true);
if (ret)
return ret;
- buf_len = sizeof(struct sta_rec_ba);
-
- sta_rec_ba.tag = cpu_to_le16(STA_REC_BA);
- sta_rec_ba.len = cpu_to_le16(buf_len);
- sta_rec_ba.tid = tid;
- sta_rec_ba.ba_type = MT_BA_TYPE_ORIGINATOR;
- sta_rec_ba.amsdu = params->amsdu;
- sta_rec_ba.ba_en = add << tid;
- sta_rec_ba.ssn = cpu_to_le16(ssn);
- sta_rec_ba.winsize = cpu_to_le16(ba_size);
-
- return __mt7615_mcu_set_sta_rec(dev, mvif->idx, msta->wcid.idx,
- mvif->omac_idx, 1, &sta_rec_ba,
- buf_len);
+ return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_STA_REC_UPDATE,
+ &sta_req, sizeof(sta_req), true);
}
int mt7615_mcu_set_rx_ba(struct mt7615_dev *dev,
struct ieee80211_ampdu_params *params,
bool add)
{
- struct ieee80211_sta *sta = params->sta;
- struct mt7615_sta *msta = (struct mt7615_sta *)sta->drv_priv;
+ struct mt7615_sta *msta = (struct mt7615_sta *)params->sta->drv_priv;
struct mt7615_vif *mvif = msta->vif;
- u16 tid = params->tid;
- struct wtbl_ba wtbl_ba = {0};
- struct sta_rec_ba sta_rec_ba = {0};
- int ret, buf_len;
-
- buf_len = sizeof(struct sta_rec_ba);
-
- sta_rec_ba.tag = cpu_to_le16(STA_REC_BA);
- sta_rec_ba.len = cpu_to_le16(buf_len);
- sta_rec_ba.tid = tid;
- sta_rec_ba.ba_type = MT_BA_TYPE_RECIPIENT;
- sta_rec_ba.amsdu = params->amsdu;
- sta_rec_ba.ba_en = add << tid;
- sta_rec_ba.ssn = cpu_to_le16(params->ssn);
- sta_rec_ba.winsize = cpu_to_le16(params->buf_size);
-
- ret = __mt7615_mcu_set_sta_rec(dev, mvif->idx, msta->wcid.idx,
- mvif->omac_idx, 1, &sta_rec_ba,
- buf_len);
- if (ret || !add)
- return ret;
+ struct {
+ struct wtbl_req_hdr hdr;
+ struct wtbl_ba ba;
+ } wtbl_req = {
+ .hdr = {
+ .wlan_idx = msta->wcid.idx,
+ .operation = WTBL_SET,
+ .tlv_num = cpu_to_le16(1),
+ },
+ .ba = {
+ .tag = cpu_to_le16(WTBL_BA),
+ .len = cpu_to_le16(sizeof(struct wtbl_ba)),
+ .tid = params->tid,
+ .ba_type = MT_BA_TYPE_RECIPIENT,
+ .rst_ba_tid = params->tid,
+ .rst_ba_sel = RST_BA_MAC_TID_MATCH,
+ .rst_ba_sb = 1,
+ },
+ };
+ struct {
+ struct sta_req_hdr hdr;
+ struct sta_rec_ba ba;
+ } sta_req = {
+ .hdr = {
+ .bss_idx = mvif->idx,
+ .wlan_idx = msta->wcid.idx,
+ .tlv_num = cpu_to_le16(1),
+ .is_tlv_append = 1,
+ .muar_idx = mvif->omac_idx,
+ },
+ .ba = {
+ .tag = cpu_to_le16(STA_REC_BA),
+ .len = cpu_to_le16(sizeof(struct sta_rec_ba)),
+ .tid = params->tid,
+ .ba_type = MT_BA_TYPE_RECIPIENT,
+ .amsdu = params->amsdu,
+ .ba_en = add << params->tid,
+ .ssn = cpu_to_le16(params->ssn),
+ .winsize = cpu_to_le16(params->buf_size),
+ },
+ };
+ int ret;
- buf_len = sizeof(struct wtbl_ba);
+ memcpy(wtbl_req.ba.peer_addr, params->sta->addr, ETH_ALEN);
- wtbl_ba.tag = cpu_to_le16(WTBL_BA);
- wtbl_ba.len = cpu_to_le16(buf_len);
- wtbl_ba.tid = tid;
- wtbl_ba.ba_type = MT_BA_TYPE_RECIPIENT;
- memcpy(wtbl_ba.peer_addr, sta->addr, ETH_ALEN);
- wtbl_ba.rst_ba_tid = tid;
- wtbl_ba.rst_ba_sel = RST_BA_MAC_TID_MATCH;
- wtbl_ba.rst_ba_sb = 1;
+ ret = mt7615_mcu_msg_send(dev, MCU_EXT_CMD_STA_REC_UPDATE,
+ &sta_req, sizeof(sta_req), true);
+ if (ret || !add)
+ return ret;
- return __mt7615_mcu_set_wtbl(dev, msta->wcid.idx, WTBL_SET,
- 1, &wtbl_ba, buf_len);
+ return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_WTBL_UPDATE,
+ &wtbl_req, sizeof(wtbl_req), true);
}
void mt7615_mcu_set_rates(struct mt7615_dev *dev, struct mt7615_sta *sta,
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
index 2d3f88ed8dc9..e96efb13fa4d 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
@@ -201,6 +201,13 @@ enum {
WTBL_RESET_ALL
};
+struct wtbl_req_hdr {
+ u8 wlan_idx;
+ u8 operation;
+ __le16 tlv_num;
+ u8 rsv[4];
+} __packed;
+
struct wtbl_generic {
__le16 tag;
__le16 len;
@@ -366,7 +373,8 @@ struct wtbl_raw {
__le32 val;
} __packed;
-#define MT7615_WTBL_UPDATE_MAX_SIZE (sizeof(struct wtbl_generic) + \
+#define MT7615_WTBL_UPDATE_MAX_SIZE (sizeof(struct wtbl_req_hdr) + \
+ sizeof(struct wtbl_generic) + \
sizeof(struct wtbl_rx) + \
sizeof(struct wtbl_ht) + \
sizeof(struct wtbl_vht) + \
@@ -400,6 +408,15 @@ enum {
WTBL_MAX_NUM
};
+struct sta_req_hdr {
+ u8 bss_idx;
+ u8 wlan_idx;
+ __le16 tlv_num;
+ u8 is_tlv_append;
+ u8 muar_idx;
+ u8 rsv[2];
+} __packed;
+
struct sta_rec_basic {
__le16 tag;
__le16 len;
--
2.20.1
^ permalink raw reply related
* [PATCH 16/17] mt7615: mcu: init mcu_restart function pointer
From: Lorenzo Bianconi @ 2019-05-04 15:29 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
In-Reply-To: <cover.1556981521.git.lorenzo@kernel.org>
Use common function wrapper in mt7615_mcu_exit since the code is shared
with m7603 driver
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index 775421fddb7c..4fa41e2c5f77 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -217,10 +217,10 @@ static int mt7615_mcu_start_firmware(struct mt7615_dev *dev, u32 addr,
&req, sizeof(req), true);
}
-static int mt7615_mcu_restart(struct mt7615_dev *dev)
+static int mt7615_mcu_restart(struct mt76_dev *dev)
{
- return __mt76_mcu_send_msg(&dev->mt76, -MCU_CMD_RESTART_DL_REQ,
- NULL, 0, true);
+ return __mt76_mcu_send_msg(dev, -MCU_CMD_RESTART_DL_REQ, NULL,
+ 0, true);
}
static int mt7615_mcu_patch_sem_ctrl(struct mt7615_dev *dev, bool get)
@@ -483,6 +483,7 @@ int mt7615_mcu_init(struct mt7615_dev *dev)
{
static const struct mt76_mcu_ops mt7615_mcu_ops = {
.mcu_send_msg = mt7615_mcu_msg_send,
+ .mcu_restart = mt7615_mcu_restart,
};
int ret;
@@ -503,7 +504,7 @@ int mt7615_mcu_init(struct mt7615_dev *dev)
void mt7615_mcu_exit(struct mt7615_dev *dev)
{
- mt7615_mcu_restart(dev);
+ __mt76_mcu_restart(&dev->mt76);
mt76_wr(dev, MT_CFG_LPCR_HOST, MT_CFG_LPCR_HOST_FW_OWN);
skb_queue_purge(&dev->mt76.mmio.mcu.res_q);
}
--
2.20.1
^ permalink raw reply related
* [PATCH 15/17] mt7615: initialize mt76_mcu_ops data structure
From: Lorenzo Bianconi @ 2019-05-04 15:29 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
In-Reply-To: <cover.1556981521.git.lorenzo@kernel.org>
Use __mt76_mcu_send_msg wrapper instead of mt7615_mcu_msg_send.
This is a preliminary patch for mt7615-mt7603 mcu code unification
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
.../net/wireless/mediatek/mt76/mt7615/mcu.c | 74 ++++++++++---------
1 file changed, 40 insertions(+), 34 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index 841631987eee..775421fddb7c 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -113,9 +113,10 @@ static int __mt7615_mcu_msg_send(struct mt7615_dev *dev, struct sk_buff *skb,
}
static int
-mt7615_mcu_msg_send(struct mt7615_dev *dev, int cmd, const void *data,
+mt7615_mcu_msg_send(struct mt76_dev *mdev, int cmd, const void *data,
int len, bool wait_resp)
{
+ struct mt7615_dev *dev = container_of(mdev, struct mt7615_dev, mt76);
unsigned long expires = jiffies + 10 * HZ;
struct mt7615_mcu_rxd *rxd;
struct sk_buff *skb;
@@ -125,16 +126,16 @@ mt7615_mcu_msg_send(struct mt7615_dev *dev, int cmd, const void *data,
if (!skb)
return -ENOMEM;
- mutex_lock(&dev->mt76.mmio.mcu.mutex);
+ mutex_lock(&mdev->mmio.mcu.mutex);
ret = __mt7615_mcu_msg_send(dev, skb, cmd, &seq);
if (ret)
goto out;
while (wait_resp) {
- skb = mt76_mcu_get_response(&dev->mt76, expires);
+ skb = mt76_mcu_get_response(mdev, expires);
if (!skb) {
- dev_err(dev->mt76.dev, "Message %d (seq %d) timeout\n",
+ dev_err(mdev->dev, "Message %d (seq %d) timeout\n",
cmd, seq);
ret = -ETIMEDOUT;
break;
@@ -153,7 +154,7 @@ mt7615_mcu_msg_send(struct mt7615_dev *dev, int cmd, const void *data,
}
out:
- mutex_unlock(&dev->mt76.mmio.mcu.mutex);
+ mutex_unlock(&mdev->mmio.mcu.mutex);
return ret;
}
@@ -171,7 +172,7 @@ static int mt7615_mcu_init_download(struct mt7615_dev *dev, u32 addr,
.mode = cpu_to_le32(mode),
};
- return mt7615_mcu_msg_send(dev, -MCU_CMD_TARGET_ADDRESS_LEN_REQ,
+ return __mt76_mcu_send_msg(&dev->mt76, -MCU_CMD_TARGET_ADDRESS_LEN_REQ,
&req, sizeof(req), true);
}
@@ -212,13 +213,13 @@ static int mt7615_mcu_start_firmware(struct mt7615_dev *dev, u32 addr,
.addr = cpu_to_le32(addr),
};
- return mt7615_mcu_msg_send(dev, -MCU_CMD_FW_START_REQ,
+ return __mt76_mcu_send_msg(&dev->mt76, -MCU_CMD_FW_START_REQ,
&req, sizeof(req), true);
}
static int mt7615_mcu_restart(struct mt7615_dev *dev)
{
- return mt7615_mcu_msg_send(dev, -MCU_CMD_RESTART_DL_REQ,
+ return __mt76_mcu_send_msg(&dev->mt76, -MCU_CMD_RESTART_DL_REQ,
NULL, 0, true);
}
@@ -230,7 +231,7 @@ static int mt7615_mcu_patch_sem_ctrl(struct mt7615_dev *dev, bool get)
.op = cpu_to_le32(get ? PATCH_SEM_GET : PATCH_SEM_RELEASE),
};
- return mt7615_mcu_msg_send(dev, -MCU_CMD_PATCH_SEM_CONTROL,
+ return __mt76_mcu_send_msg(&dev->mt76, -MCU_CMD_PATCH_SEM_CONTROL,
&req, sizeof(req), true);
}
@@ -243,7 +244,7 @@ static int mt7615_mcu_start_patch(struct mt7615_dev *dev)
.check_crc = 0,
};
- return mt7615_mcu_msg_send(dev, -MCU_CMD_PATCH_FINISH_REQ,
+ return __mt76_mcu_send_msg(&dev->mt76, -MCU_CMD_PATCH_FINISH_REQ,
&req, sizeof(req), true);
}
@@ -480,8 +481,13 @@ static int mt7615_load_firmware(struct mt7615_dev *dev)
int mt7615_mcu_init(struct mt7615_dev *dev)
{
+ static const struct mt76_mcu_ops mt7615_mcu_ops = {
+ .mcu_send_msg = mt7615_mcu_msg_send,
+ };
int ret;
+ dev->mt76.mcu_ops = &mt7615_mcu_ops,
+
ret = mt7615_driver_own(dev);
if (ret)
return ret;
@@ -523,7 +529,7 @@ int mt7615_mcu_set_eeprom(struct mt7615_dev *dev)
memcpy(req + sizeof(req_hdr), eep + MT_EE_NIC_CONF_0,
__MT_EE_MAX - MT_EE_NIC_CONF_0);
- ret = mt7615_mcu_msg_send(dev, MCU_EXT_CMD_EFUSE_BUFFER_MODE,
+ ret = __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_EFUSE_BUFFER_MODE,
req, len, true);
kfree(req);
@@ -541,7 +547,7 @@ int mt7615_mcu_init_mac(struct mt7615_dev *dev)
.band = 0,
};
- return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_MAC_INIT_CTRL,
+ return __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_MAC_INIT_CTRL,
&req, sizeof(req), true);
}
@@ -560,7 +566,7 @@ int mt7615_mcu_set_rts_thresh(struct mt7615_dev *dev, u32 val)
.pkt_thresh = cpu_to_le32(0x2),
};
- return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_PROTECT_CTRL,
+ return __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_PROTECT_CTRL,
&req, sizeof(req), true);
}
@@ -597,7 +603,7 @@ int mt7615_mcu_set_wmm(struct mt7615_dev *dev, u8 queue,
req.cw_max = cpu_to_le16(params->cw_max);
}
- return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_EDCA_UPDATE,
+ return __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_EDCA_UPDATE,
&req, sizeof(req), true);
}
@@ -627,7 +633,7 @@ int mt7615_mcu_ctrl_pm_state(struct mt7615_dev *dev, int enter)
.band_idx = 0,
};
- return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_PM_STATE_CTRL,
+ return __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_PM_STATE_CTRL,
&req, sizeof(req), true);
}
@@ -666,7 +672,7 @@ int mt7615_mcu_set_dev_info(struct mt7615_dev *dev,
};
memcpy(data.tlv.omac_addr, vif->addr, ETH_ALEN);
- return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_DEV_INFO_UPDATE,
+ return __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_DEV_INFO_UPDATE,
&data, sizeof(data), true);
}
@@ -812,7 +818,7 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
}
}
- ret = mt7615_mcu_msg_send(dev, MCU_EXT_CMD_BSS_INFO_UPDATE,
+ ret = __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_BSS_INFO_UPDATE,
buf, len, true);
kfree(buf);
@@ -886,7 +892,7 @@ int mt7615_mcu_set_wtbl_key(struct mt7615_dev *dev, int wcid,
req.key.key_len = sizeof(req.key.key_material);
}
- return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_WTBL_UPDATE,
+ return __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_WTBL_UPDATE,
&req, sizeof(req), true);
}
@@ -919,7 +925,7 @@ mt7615_mcu_add_wtbl_bmc(struct mt7615_dev *dev,
};
eth_broadcast_addr(req.g_wtbl.peer_addr);
- return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_WTBL_UPDATE,
+ return __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_WTBL_UPDATE,
&req, sizeof(req), true);
}
@@ -934,7 +940,7 @@ int mt7615_mcu_wtbl_bmc(struct mt7615_dev *dev,
.operation = WTBL_RESET_AND_SET,
};
- return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_WTBL_UPDATE,
+ return __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_WTBL_UPDATE,
&req, sizeof(req), true);
}
@@ -973,7 +979,7 @@ int mt7615_mcu_add_wtbl(struct mt7615_dev *dev, struct ieee80211_vif *vif,
};
memcpy(req.g_wtbl.peer_addr, sta->addr, ETH_ALEN);
- return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_WTBL_UPDATE,
+ return __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_WTBL_UPDATE,
&req, sizeof(req), true);
}
@@ -986,7 +992,7 @@ int mt7615_mcu_del_wtbl(struct mt7615_dev *dev,
.operation = WTBL_RESET_AND_SET,
};
- return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_WTBL_UPDATE,
+ return __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_WTBL_UPDATE,
&req, sizeof(req), true);
}
@@ -996,7 +1002,7 @@ int mt7615_mcu_del_wtbl_all(struct mt7615_dev *dev)
.operation = WTBL_RESET_ALL,
};
- return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_WTBL_UPDATE,
+ return __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_WTBL_UPDATE,
&req, sizeof(req), true);
}
@@ -1032,7 +1038,7 @@ int mt7615_mcu_set_sta_rec_bmc(struct mt7615_dev *dev,
req.basic.extra_info = cpu_to_le16(EXTRA_INFO_VER);
}
- return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_STA_REC_UPDATE,
+ return __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_STA_REC_UPDATE,
&req, sizeof(req), true);
}
@@ -1092,7 +1098,7 @@ int mt7615_mcu_set_sta_rec(struct mt7615_dev *dev, struct ieee80211_vif *vif,
req.basic.extra_info = cpu_to_le16(EXTRA_INFO_VER);
}
- return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_STA_REC_UPDATE,
+ return __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_STA_REC_UPDATE,
&req, sizeof(req), true);
}
@@ -1145,7 +1151,7 @@ int mt7615_mcu_set_bcn(struct mt7615_dev *dev, struct ieee80211_vif *vif,
dev_kfree_skb(skb);
- return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_BCN_OFFLOAD,
+ return __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_BCN_OFFLOAD,
&req, sizeof(req), true);
}
@@ -1208,12 +1214,12 @@ int mt7615_mcu_set_channel(struct mt7615_dev *dev)
}
memset(req.txpower_sku, 0x3f, 49);
- ret = mt7615_mcu_msg_send(dev, MCU_EXT_CMD_CHANNEL_SWITCH,
+ ret = __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_CHANNEL_SWITCH,
&req, sizeof(req), true);
if (ret)
return ret;
- return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_SET_RX_PATH,
+ return __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_SET_RX_PATH,
&req, sizeof(req), true);
}
@@ -1299,7 +1305,7 @@ int mt7615_mcu_set_ht_cap(struct mt7615_dev *dev, struct ieee80211_vif *vif,
wtbl_raw->val = cpu_to_le32(val);
wtbl_hdr->tlv_num = cpu_to_le16(ntlv);
- ret = mt7615_mcu_msg_send(dev, MCU_EXT_CMD_WTBL_UPDATE,
+ ret = __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_WTBL_UPDATE,
buf, buf_len, true);
if (ret)
goto out;
@@ -1335,7 +1341,7 @@ int mt7615_mcu_set_ht_cap(struct mt7615_dev *dev, struct ieee80211_vif *vif,
cpu_to_le16(sta->vht_cap.vht_mcs.tx_mcs_map);
}
- ret = mt7615_mcu_msg_send(dev, MCU_EXT_CMD_STA_REC_UPDATE,
+ ret = __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_STA_REC_UPDATE,
buf, buf_len, true);
out:
kfree(buf);
@@ -1402,12 +1408,12 @@ int mt7615_mcu_set_tx_ba(struct mt7615_dev *dev,
wtbl_req.ba.ba_winsize_idx = idx;
}
- ret = mt7615_mcu_msg_send(dev, MCU_EXT_CMD_WTBL_UPDATE,
+ ret = __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_WTBL_UPDATE,
&wtbl_req, sizeof(wtbl_req), true);
if (ret)
return ret;
- return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_STA_REC_UPDATE,
+ return __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_STA_REC_UPDATE,
&sta_req, sizeof(sta_req), true);
}
@@ -1462,12 +1468,12 @@ int mt7615_mcu_set_rx_ba(struct mt7615_dev *dev,
memcpy(wtbl_req.ba.peer_addr, params->sta->addr, ETH_ALEN);
- ret = mt7615_mcu_msg_send(dev, MCU_EXT_CMD_STA_REC_UPDATE,
+ ret = __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_STA_REC_UPDATE,
&sta_req, sizeof(sta_req), true);
if (ret || !add)
return ret;
- return mt7615_mcu_msg_send(dev, MCU_EXT_CMD_WTBL_UPDATE,
+ return __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_WTBL_UPDATE,
&wtbl_req, sizeof(wtbl_req), true);
}
--
2.20.1
^ permalink raw reply related
* [PATCH 17/17] mt7615: mcu: run __mt76_mcu_send_msg in mt7615_mcu_send_firmware
From: Lorenzo Bianconi @ 2019-05-04 15:29 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
In-Reply-To: <cover.1556981521.git.lorenzo@kernel.org>
Run __mt76_mcu_send_msg instead of __mt7615_mcu_msg_send and remove
duplicated code.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index 4fa41e2c5f77..5b01abe7aecf 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -179,19 +179,14 @@ static int mt7615_mcu_init_download(struct mt7615_dev *dev, u32 addr,
static int mt7615_mcu_send_firmware(struct mt7615_dev *dev, const void *data,
int len)
{
- struct sk_buff *skb;
- int ret = 0;
+ int ret = 0, cur_len;
while (len > 0) {
- int cur_len = min_t(int, 4096 - sizeof(struct mt7615_mcu_txd),
- len);
-
- skb = mt7615_mcu_msg_alloc(data, cur_len);
- if (!skb)
- return -ENOMEM;
+ cur_len = min_t(int, 4096 - sizeof(struct mt7615_mcu_txd),
+ len);
- ret = __mt7615_mcu_msg_send(dev, skb, -MCU_CMD_FW_SCATTER,
- NULL);
+ ret = __mt76_mcu_send_msg(&dev->mt76, -MCU_CMD_FW_SCATTER,
+ data, cur_len, false);
if (ret)
break;
--
2.20.1
^ permalink raw reply related
* PROBLEM: brcmfmac's DMI-based fw file names break built-in fw loader
From: Victor Bravo @ 2019-05-04 16:26 UTC (permalink / raw)
To: Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, David S. Miller, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, linux-kernel
The brcmfmac driver seems to have partially fixed problems which
prevented it to be used in shared system/kernel images for multiple
hardware by trying to load it's <config>.txt as
<config>.<dmi_sys_vendor>.<dmi_product_name>.txt first and then
falling back to <config>.txt. Real-life example:
brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43340-sdio.ASUSTeK COMPUTER INC.-T100HAN.txt failed with
error -2
brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43340-sdio for chip
BCM43340/2
Unfortunately this doesn't really help on systems which use static
kernel with firmware blobs (and also text configuration files in case of
brcmfmac) built-in using CONFIG_EXTRA_FIRMWARE, as CONFIG_EXTRA_FIRMWARE
doesn't support spaces in file names - kernel build fails with
CONFIG_EXTRA_FIRMWARE="brcm/brcmfmac43340-sdio.bin brcm/brcmfmac43340-sdio.ASUSTeK COMPUTER INC.-T100HAN.txt"
for obvious reasons. So the only way here is to stay with good old
brcmfmac43340-sdio.txt and support at most one brcmfmac-equipped machine
per kernel image.
Please consider filtering the DMI strings and replacing spaces and
possibly other invalid characters with underscores, and/or adding module
parameter to allow passing the string from command line (using
brcmfmac.tag=t100 or brcmfmac.board=t100 to make the module load
brcmfmac43340-sdio.t100.txt seems nicer to me, and isn't prone to
breaking when DMI strings change on BIOS update).
My brief grep-based research also suggest that strings retrieved
by dmi_get_system_info() are passed to firmware loader without any
checks for special character, /../ etc. I'm not sure whether this is
considered to be proper & safe use, but if it's not, it may also have
some security implications, as it allows attacker with access to DMI
strings (using root rights/other OS/BIOS/physical access) to mess
with kernel space or secure boot.
I would also really appreciate not allowing future brcm (and other)
drivers to leave staging area before they fully support =y.
Regards,
v.b.
^ permalink raw reply
* Re: PROBLEM: brcmfmac's DMI-based fw file names break built-in fw loader
From: Arend Van Spriel @ 2019-05-04 19:11 UTC (permalink / raw)
To: Victor Bravo, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, David S. Miller, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, linux-kernel,
Hans de Goede
In-Reply-To: <20190504162633.ldrz2nqfocg55grb@localhost>
+ Hans, Luis
On 5/4/2019 6:26 PM, Victor Bravo wrote:
> The brcmfmac driver seems to have partially fixed problems which
> prevented it to be used in shared system/kernel images for multiple
> hardware by trying to load it's <config>.txt as
> <config>.<dmi_sys_vendor>.<dmi_product_name>.txt first and then
> falling back to <config>.txt. Real-life example:
>
> brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43340-sdio.ASUSTeK COMPUTER INC.-T100HAN.txt failed with
> error -2
> brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43340-sdio for chip
> BCM43340/2
>
> Unfortunately this doesn't really help on systems which use static
> kernel with firmware blobs (and also text configuration files in case of
> brcmfmac) built-in using CONFIG_EXTRA_FIRMWARE, as CONFIG_EXTRA_FIRMWARE
> doesn't support spaces in file names - kernel build fails with
>
> CONFIG_EXTRA_FIRMWARE="brcm/brcmfmac43340-sdio.bin brcm/brcmfmac43340-sdio.ASUSTeK COMPUTER INC.-T100HAN.txt"
>
> for obvious reasons. So the only way here is to stay with good old
> brcmfmac43340-sdio.txt and support at most one brcmfmac-equipped machine
> per kernel image.
>
> Please consider filtering the DMI strings and replacing spaces and
> possibly other invalid characters with underscores, and/or adding module
> parameter to allow passing the string from command line (using
> brcmfmac.tag=t100 or brcmfmac.board=t100 to make the module load
> brcmfmac43340-sdio.t100.txt seems nicer to me, and isn't prone to
> breaking when DMI strings change on BIOS update).
The intent of the DMI approach was to avoid end-users from passing
module parameters for this. As to fixing DMI string usage patches are
welcome.
> My brief grep-based research also suggest that strings retrieved
> by dmi_get_system_info() are passed to firmware loader without any
> checks for special character, /../ etc. I'm not sure whether this is
> considered to be proper & safe use, but if it's not, it may also have
> some security implications, as it allows attacker with access to DMI
> strings (using root rights/other OS/BIOS/physical access) to mess
> with kernel space or secure boot.
Hmm. Attackers with that kind of access can do bad is a gazillion ways.
> I would also really appreciate not allowing future brcm (and other)
> drivers to leave staging area before they fully support =y.
Define fully support. At the time we moved into the wireless tree
(almost a decade ago) we did support =y. As such you could consider the
DMI approach a regression, but I find that a bit harsh to say. Hans made
a honest attempt and it is something that can be fixed. It can be you
providing just that ;-)
Regards,
Arend
^ permalink raw reply
* [PATCH] wireless-regdb: update source of information for ES
From: Xose Vazquez Perez @ 2019-05-04 19:18 UTC (permalink / raw)
Cc: Xose Vazquez Perez, Seth Forshee, WIRELESS ML, REGDB ML
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: WIRELESS ML <linux-wireless@vger.kernel.org>
Cc: REGDB ML <wireless-regdb@lists.infradead.org>
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
---
db.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/db.txt b/db.txt
index 4fb1948..fe909a8 100644
--- a/db.txt
+++ b/db.txt
@@ -432,7 +432,7 @@ country EG: DFS-ETSI
# Source:
# Cuadro nacional de atribución de frecuencias (CNAF)
-# http://www.mincotur.gob.es/telecomunicaciones/espectro/paginas/cnaf.aspx
+# https://avancedigital.gob.es/espectro/Paginas/cnaf.aspx
country ES: DFS-ETSI
(2400 - 2483.5 @ 40), (100 mW)
(5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
--
2.21.0
^ permalink raw reply related
* Re: PROBLEM: brcmfmac's DMI-based fw file names break built-in fw loader
From: Victor Bravo @ 2019-05-04 19:44 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Franky Lin, Hante Meuleman, Chi-Hsien Lin, Wright Feng,
Kalle Valo, David S. Miller, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, linux-kernel,
Hans de Goede
In-Reply-To: <cce7604e-2b02-80ed-1df5-6f304cada0cb@broadcom.com>
On Sat, May 04, 2019 at 09:11:09PM +0200, Arend Van Spriel wrote:
> + Hans, Luis
>
> On 5/4/2019 6:26 PM, Victor Bravo wrote:
> > The brcmfmac driver seems to have partially fixed problems which
> > prevented it to be used in shared system/kernel images for multiple
> > hardware by trying to load it's <config>.txt as
> > <config>.<dmi_sys_vendor>.<dmi_product_name>.txt first and then
> > falling back to <config>.txt. Real-life example:
> >
> > brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43340-sdio.ASUSTeK COMPUTER INC.-T100HAN.txt failed with
> > error -2
> > brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43340-sdio for chip
> > BCM43340/2
> >
> > Unfortunately this doesn't really help on systems which use static
> > kernel with firmware blobs (and also text configuration files in case of
> > brcmfmac) built-in using CONFIG_EXTRA_FIRMWARE, as CONFIG_EXTRA_FIRMWARE
> > doesn't support spaces in file names - kernel build fails with
> >
> > CONFIG_EXTRA_FIRMWARE="brcm/brcmfmac43340-sdio.bin brcm/brcmfmac43340-sdio.ASUSTeK COMPUTER INC.-T100HAN.txt"
> >
> > for obvious reasons. So the only way here is to stay with good old
> > brcmfmac43340-sdio.txt and support at most one brcmfmac-equipped machine
> > per kernel image.
> >
> > Please consider filtering the DMI strings and replacing spaces and
> > possibly other invalid characters with underscores, and/or adding module
> > parameter to allow passing the string from command line (using
> > brcmfmac.tag=t100 or brcmfmac.board=t100 to make the module load
> > brcmfmac43340-sdio.t100.txt seems nicer to me, and isn't prone to
> > breaking when DMI strings change on BIOS update).
>
> The intent of the DMI approach was to avoid end-users from passing module
> parameters for this. As to fixing DMI string usage patches are welcome.
Well I think I could also provide a patch to fix, this can be easily
done by adding a string of allowed characters and then replacing
unknown ones with underscores.
> > My brief grep-based research also suggest that strings retrieved
> > by dmi_get_system_info() are passed to firmware loader without any
> > checks for special character, /../ etc. I'm not sure whether this is
> > considered to be proper & safe use, but if it's not, it may also have
> > some security implications, as it allows attacker with access to DMI
> > strings (using root rights/other OS/BIOS/physical access) to mess
> > with kernel space or secure boot.
>
> Hmm. Attackers with that kind of access can do bad is a gazillion ways.
Agreed. It will be definitely easier to make filenames contain only safe
characters than to discuss those ways.
> > I would also really appreciate not allowing future brcm (and other)
> > drivers to leave staging area before they fully support =y.
>
> Define fully support. At the time we moved into the wireless tree (almost a
> decade ago) we did support =y. As such you could consider the DMI approach a
> regression, but I find that a bit harsh to say. Hans made a honest attempt
> and it is something that can be fixed. It can be you providing just that ;-)
Well... I agree that the idea wasn't really complete ;).
As for the patches, I also realized that the txt config file actually
comes from EFI/BIOS, so it's quite possible that it may differ between
BIOS versions. So I'm thinking of 3 patches here:
1) Character filtering as described above.
2) Adding bios_version next to board_type, and changing load order to
<config>.<dmi_sys_vendor>.<dmi_product_name>.<dmi_bios_version>.txt
<config>.<dmi_sys_vendor>.<dmi_product_name>.txt
<config>.txt
3) Adding command-line parameters to override these on problems.
1) breaks backward compatibility, but the DMI code seems to be quite
new so hopefully many people don't rely on it yet.
2) & 3) are backward compatible.
Regards,
v.
^ permalink raw reply
* static analysis issue in rtl8188de driver
From: Colin Ian King @ 2019-05-04 21:50 UTC (permalink / raw)
To: Ping-Ke Shih, Kalle Valo, Larry Finger, linux-wireless
Cc: linux-kernel@vger.kernel.org
Hi,
Static analysis with Coverity has found an issue in the rtl8188de
wireless driver in drivers/net/wireless/realtek/rtlwifi/rtl8192de/dm.c
in function tl92d_dm_txpower_tracking_callback_thermalmeter.
The issue is that u8 array ofdm_index[3] is never initialized, however
it is decremented and incremented in two places resulting in garbage
value from the stack being updated in the following code:
if (thermalvalue > rtlpriv->dm.thermalvalue) {
for (i = 0; i < rf; i++)
ofdm_index[i] -= delta;
cck_index -= delta;
} else {
for (i = 0; i < rf; i++)
ofdm_index[i] += index;
cck_index += index;
}
At my first look at the code I believe ofdm_index should be just
zero-initialized at declaration time, but I suspect that I'm overlooking
something maybe a bit deeper. Any ideas?
Colin
^ permalink raw reply
* [PATCH] mt76: mt7603: stop mac80211 queues before setting the channel
From: Lorenzo Bianconi @ 2019-05-05 0:53 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless
In-Reply-To: <cover.1557016660.git.lorenzo@kernel.org>
Suspend data transmission during channel switch
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt7603/main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/main.c b/drivers/net/wireless/mediatek/mt76/mt7603/main.c
index 0a0334dc40d5..172687a1cb15 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/main.c
@@ -207,8 +207,11 @@ mt7603_config(struct ieee80211_hw *hw, u32 changed)
int ret = 0;
if (changed & (IEEE80211_CONF_CHANGE_CHANNEL |
- IEEE80211_CONF_CHANGE_POWER))
+ IEEE80211_CONF_CHANGE_POWER)) {
+ ieee80211_stop_queues(hw);
ret = mt7603_set_channel(dev, &hw->conf.chandef);
+ ieee80211_wake_queues(hw);
+ }
if (changed & IEEE80211_CONF_CHANGE_MONITOR) {
mutex_lock(&dev->mt76.mutex);
--
2.20.1
^ permalink raw reply related
* Re: pull-request: wireless-drivers 2019-04-30
From: David Miller @ 2019-05-05 7:51 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87r29jo2jy.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Tue, 30 Apr 2019 19:55:45 +0300
> David Miller <davem@davemloft.net> writes:
>
>> Thanks for the conflict resolution information, it is very helpful.
>>
>> However, can you put it into the merge commit text next time as well?
>> I cut and pasted it in there when I pulled this stuff in.
>
> A good idea, I'll do that. Just to be sure, do you mean that I should
> add it only with conflicts between net and net-next (like in this case)?
> Or should I add it everytime I see a conflict, for example between
> wireless-drivers-next and net-next? I hope my question is not too
> confusing...
When there is a major conflict for me to resolve when I pull in your
pull reqeust, please place the conflict resolution help text into the
merge commit message.
I hope this is now clear :-)
^ permalink raw reply
* Re: PROBLEM: brcmfmac's DMI-based fw file names break built-in fw loader
From: Arend Van Spriel @ 2019-05-05 8:20 UTC (permalink / raw)
To: Victor Bravo
Cc: Franky Lin, Hante Meuleman, Chi-Hsien Lin, Wright Feng,
Kalle Valo, David S. Miller, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, linux-kernel,
Hans de Goede
In-Reply-To: <20190504194440.4zcxjrtj2aft3ka4@localhost>
On May 4, 2019 9:44:51 PM Victor Bravo <1905@spmblk.com> wrote:
> On Sat, May 04, 2019 at 09:11:09PM +0200, Arend Van Spriel wrote:
>> + Hans, Luis
>>
>> On 5/4/2019 6:26 PM, Victor Bravo wrote:
>> > The brcmfmac driver seems to have partially fixed problems which
>> > prevented it to be used in shared system/kernel images for multiple
>> > hardware by trying to load it's <config>.txt as
>> > <config>.<dmi_sys_vendor>.<dmi_product_name>.txt first and then
>> > falling back to <config>.txt. Real-life example:
>> >
>> > brcmfmac mmc1:0001:1: Direct firmware load for
>> brcm/brcmfmac43340-sdio.ASUSTeK COMPUTER INC.-T100HAN.txt failed with
>> > error -2
>> > brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43340-sdio for chip
>> > BCM43340/2
>> >
>> > Unfortunately this doesn't really help on systems which use static
>> > kernel with firmware blobs (and also text configuration files in case of
>> > brcmfmac) built-in using CONFIG_EXTRA_FIRMWARE, as CONFIG_EXTRA_FIRMWARE
>> > doesn't support spaces in file names - kernel build fails with
>> >
>> > CONFIG_EXTRA_FIRMWARE="brcm/brcmfmac43340-sdio.bin
>> brcm/brcmfmac43340-sdio.ASUSTeK COMPUTER INC.-T100HAN.txt"
>> >
>> > for obvious reasons. So the only way here is to stay with good old
>> > brcmfmac43340-sdio.txt and support at most one brcmfmac-equipped machine
>> > per kernel image.
>> >
>> > Please consider filtering the DMI strings and replacing spaces and
>> > possibly other invalid characters with underscores, and/or adding module
>> > parameter to allow passing the string from command line (using
>> > brcmfmac.tag=t100 or brcmfmac.board=t100 to make the module load
>> > brcmfmac43340-sdio.t100.txt seems nicer to me, and isn't prone to
>> > breaking when DMI strings change on BIOS update).
>>
>> The intent of the DMI approach was to avoid end-users from passing module
>> parameters for this. As to fixing DMI string usage patches are welcome.
>
> Well I think I could also provide a patch to fix, this can be easily
> done by adding a string of allowed characters and then replacing
> unknown ones with underscores.
>
>> > My brief grep-based research also suggest that strings retrieved
>> > by dmi_get_system_info() are passed to firmware loader without any
>> > checks for special character, /../ etc. I'm not sure whether this is
>> > considered to be proper & safe use, but if it's not, it may also have
>> > some security implications, as it allows attacker with access to DMI
>> > strings (using root rights/other OS/BIOS/physical access) to mess
>> > with kernel space or secure boot.
>>
>> Hmm. Attackers with that kind of access can do bad is a gazillion ways.
>
> Agreed. It will be definitely easier to make filenames contain only safe
> characters than to discuss those ways.
>
>> > I would also really appreciate not allowing future brcm (and other)
>> > drivers to leave staging area before they fully support =y.
>>
>> Define fully support. At the time we moved into the wireless tree (almost a
>> decade ago) we did support =y. As such you could consider the DMI approach a
>> regression, but I find that a bit harsh to say. Hans made a honest attempt
>> and it is something that can be fixed. It can be you providing just that ;-)
>
> Well... I agree that the idea wasn't really complete ;).
>
> As for the patches, I also realized that the txt config file actually
> comes from EFI/BIOS, so it's quite possible that it may differ between
> BIOS versions. So I'm thinking of 3 patches here:
>
> 1) Character filtering as described above.
>
> 2) Adding bios_version next to board_type, and changing load order to
>
> <config>.<dmi_sys_vendor>.<dmi_product_name>.<dmi_bios_version>.txt
> <config>.<dmi_sys_vendor>.<dmi_product_name>.txt
> <config>.txt
>
> 3) Adding command-line parameters to override these on problems.
>
> 1) breaks backward compatibility, but the DMI code seems to be quite
> new so hopefully many people don't rely on it yet.
>
> 2) & 3) are backward compatible.
Actually, the configuration file, or nvram file as we tend to call it, does
not come from EFI/BIOS. There are a few platforms that have the nvram file
stored in EFI and it's name is well-defined. It does assume there is only
one brcmfmac device in the system.
Regards,
Arend
^ permalink raw reply
* Re: PROBLEM: brcmfmac's DMI-based fw file names break built-in fw loader
From: Victor Bravo @ 2019-05-05 14:36 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Franky Lin, Hante Meuleman, Chi-Hsien Lin, Wright Feng,
Kalle Valo, David S. Miller, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, linux-kernel,
Hans de Goede
In-Reply-To: <16a87149068.2764.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com>
On Sun, May 05, 2019 at 10:20:33AM +0200, Arend Van Spriel wrote:
> On May 4, 2019 9:44:51 PM Victor Bravo <1905@spmblk.com> wrote:
>
> > On Sat, May 04, 2019 at 09:11:09PM +0200, Arend Van Spriel wrote:
> > > + Hans, Luis
> > >
> > > On 5/4/2019 6:26 PM, Victor Bravo wrote:
> > > > The brcmfmac driver seems to have partially fixed problems which
> > > > prevented it to be used in shared system/kernel images for multiple
> > > > hardware by trying to load it's <config>.txt as
> > > > <config>.<dmi_sys_vendor>.<dmi_product_name>.txt first and then
> > > > falling back to <config>.txt. Real-life example:
> > > >
> > > > brcmfmac mmc1:0001:1: Direct firmware load for
> > > brcm/brcmfmac43340-sdio.ASUSTeK COMPUTER INC.-T100HAN.txt failed
> > > with
> > > > error -2
> > > > brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43340-sdio for chip
> > > > BCM43340/2
> > > >
> > > > Unfortunately this doesn't really help on systems which use static
> > > > kernel with firmware blobs (and also text configuration files in case of
> > > > brcmfmac) built-in using CONFIG_EXTRA_FIRMWARE, as CONFIG_EXTRA_FIRMWARE
> > > > doesn't support spaces in file names - kernel build fails with
> > > >
> > > > CONFIG_EXTRA_FIRMWARE="brcm/brcmfmac43340-sdio.bin
> > > brcm/brcmfmac43340-sdio.ASUSTeK COMPUTER INC.-T100HAN.txt"
> > > >
> > > > for obvious reasons. So the only way here is to stay with good old
> > > > brcmfmac43340-sdio.txt and support at most one brcmfmac-equipped machine
> > > > per kernel image.
> > > >
> > > > Please consider filtering the DMI strings and replacing spaces and
> > > > possibly other invalid characters with underscores, and/or adding module
> > > > parameter to allow passing the string from command line (using
> > > > brcmfmac.tag=t100 or brcmfmac.board=t100 to make the module load
> > > > brcmfmac43340-sdio.t100.txt seems nicer to me, and isn't prone to
> > > > breaking when DMI strings change on BIOS update).
> > >
> > > The intent of the DMI approach was to avoid end-users from passing module
> > > parameters for this. As to fixing DMI string usage patches are welcome.
> >
> > Well I think I could also provide a patch to fix, this can be easily
> > done by adding a string of allowed characters and then replacing
> > unknown ones with underscores.
> >
> > > > My brief grep-based research also suggest that strings retrieved
> > > > by dmi_get_system_info() are passed to firmware loader without any
> > > > checks for special character, /../ etc. I'm not sure whether this is
> > > > considered to be proper & safe use, but if it's not, it may also have
> > > > some security implications, as it allows attacker with access to DMI
> > > > strings (using root rights/other OS/BIOS/physical access) to mess
> > > > with kernel space or secure boot.
> > >
> > > Hmm. Attackers with that kind of access can do bad is a gazillion ways.
> >
> > Agreed. It will be definitely easier to make filenames contain only safe
> > characters than to discuss those ways.
> >
> > > > I would also really appreciate not allowing future brcm (and other)
> > > > drivers to leave staging area before they fully support =y.
> > >
> > > Define fully support. At the time we moved into the wireless tree (almost a
> > > decade ago) we did support =y. As such you could consider the DMI approach a
> > > regression, but I find that a bit harsh to say. Hans made a honest attempt
> > > and it is something that can be fixed. It can be you providing just that ;-)
> >
> > Well... I agree that the idea wasn't really complete ;).
> >
> > As for the patches, I also realized that the txt config file actually
> > comes from EFI/BIOS, so it's quite possible that it may differ between
> > BIOS versions. So I'm thinking of 3 patches here:
> >
> > 1) Character filtering as described above.
> >
> > 2) Adding bios_version next to board_type, and changing load order to
> >
> > <config>.<dmi_sys_vendor>.<dmi_product_name>.<dmi_bios_version>.txt
> > <config>.<dmi_sys_vendor>.<dmi_product_name>.txt
> > <config>.txt
> >
> > 3) Adding command-line parameters to override these on problems.
> >
> > 1) breaks backward compatibility, but the DMI code seems to be quite
> > new so hopefully many people don't rely on it yet.
> >
> > 2) & 3) are backward compatible.
>
> Actually, the configuration file, or nvram file as we tend to call it, does
> not come from EFI/BIOS. There are a few platforms that have the nvram file
> stored in EFI and it's name is well-defined. It does assume there is only
> one brcmfmac device in the system.
Good to know. Sounds like working nvram file should never need update
and changes related to BIOS version are not needed.
I've meanwhile prepared patch for character filtering, will post in
new thread w/ better subject.
Regards,
v.
^ permalink raw reply
* [PATCH RFC] brcmfmac: sanitize DMI strings
From: Victor Bravo @ 2019-05-05 14:48 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Franky Lin, Hante Meuleman, Chi-Hsien Lin, Wright Feng,
Kalle Valo, David S. Miller, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, linux-kernel,
Hans de Goede
In-Reply-To: <16a87149068.2764.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com>
Sanitize DMI strings in brcmfmac driver to make resulting filenames
contain only safe characters. This version replaces all non-printable
characters incl. delete (0-31, 127-255), spaces and slashes with
underscores.
This change breaks backward compatibility, but adds control over strings
passed to firmware loader and compatibility with CONFIG_EXTRA_FIRMWARE
which doesn't support spaces in filenames.
Signed-off-by: Victor Bravo <1905@spmblk.com>
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c
index 7535cb0d4ac0..fa654ce7172b 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c
@@ -23,6 +23,14 @@
/* The DMI data never changes so we can use a static buf for this */
static char dmi_board_type[128];
+/* Array of 128 bits representing 7-bit characters allowed in DMI strings. */
+static unsigned char brcmf_dmi_allowed_chars[] = {
+ 0x00, 0x00, 0x00, 0x00, 0xfe, 0x7f, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x7f
+};
+
+#define BRCMF_DMI_SAFE_CHAR '_'
+
struct brcmf_dmi_data {
u32 chip;
u32 chiprev;
@@ -43,10 +51,6 @@ static const struct brcmf_dmi_data meegopad_t08_data = {
BRCM_CC_43340_CHIP_ID, 2, "meegopad-t08"
};
-static const struct brcmf_dmi_data pov_tab_p1006w_data = {
- BRCM_CC_43340_CHIP_ID, 2, "pov-tab-p1006w-data"
-};
-
static const struct dmi_system_id dmi_platform_data[] = {
{
/* Match for the GPDwin which unfortunately uses somewhat
@@ -85,20 +89,18 @@ static const struct dmi_system_id dmi_platform_data[] = {
},
.driver_data = (void *)&meegopad_t08_data,
},
- {
- /* Point of View TAB-P1006W-232 */
- .matches = {
- DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Insyde"),
- DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "BayTrail"),
- /* Note 105b is Foxcon's USB/PCI vendor id */
- DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "105B"),
- DMI_EXACT_MATCH(DMI_BOARD_NAME, "0E57"),
- },
- .driver_data = (void *)&pov_tab_p1006w_data,
- },
{}
};
+void brcmf_dmi_sanitize(char *dst, const unsigned char *allowed, char safe)
+{
+ while (*dst) {
+ if ((*dst < 0) || !(allowed[*dst / 8] & (1 << (*dst % 8))))
+ *dst = safe;
+ dst++;
+ }
+}
+
void brcmf_dmi_probe(struct brcmf_mp_device *settings, u32 chip, u32 chiprev)
{
const struct dmi_system_id *match;
@@ -126,6 +128,9 @@ void brcmf_dmi_probe(struct brcmf_mp_device *settings, u32 chip, u32 chiprev)
if (sys_vendor && product_name) {
snprintf(dmi_board_type, sizeof(dmi_board_type), "%s-%s",
sys_vendor, product_name);
+ brcmf_dmi_sanitize(dmi_board_type,
+ brcmf_dmi_allowed_chars,
+ BRCMF_DMI_SAFE_CHAR);
settings->board_type = dmi_board_type;
}
}
^ permalink raw reply related
* Re: [PATCH RFC] brcmfmac: sanitize DMI strings
From: Victor Bravo @ 2019-05-05 14:52 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Franky Lin, Hante Meuleman, Chi-Hsien Lin, Wright Feng,
Kalle Valo, David S. Miller, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, linux-kernel,
Hans de Goede
In-Reply-To: <20190505144852.addbdluel7edoevm@localhost>
Didn't notice that the patch removes some fresh changes which got in
while I was tuning it. Please wait for v2. Sorry for the noise.
v.
On Sun, May 05, 2019 at 04:48:52PM +0200, Victor Bravo wrote:
> Sanitize DMI strings in brcmfmac driver to make resulting filenames
> contain only safe characters. This version replaces all non-printable
> characters incl. delete (0-31, 127-255), spaces and slashes with
> underscores.
>
> This change breaks backward compatibility, but adds control over strings
> passed to firmware loader and compatibility with CONFIG_EXTRA_FIRMWARE
> which doesn't support spaces in filenames.
>
> Signed-off-by: Victor Bravo <1905@spmblk.com>
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c
> index 7535cb0d4ac0..fa654ce7172b 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c
> @@ -23,6 +23,14 @@
> /* The DMI data never changes so we can use a static buf for this */
> static char dmi_board_type[128];
>
> +/* Array of 128 bits representing 7-bit characters allowed in DMI strings. */
> +static unsigned char brcmf_dmi_allowed_chars[] = {
> + 0x00, 0x00, 0x00, 0x00, 0xfe, 0x7f, 0xff, 0xff,
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x7f
> +};
> +
> +#define BRCMF_DMI_SAFE_CHAR '_'
> +
> struct brcmf_dmi_data {
> u32 chip;
> u32 chiprev;
> @@ -43,10 +51,6 @@ static const struct brcmf_dmi_data meegopad_t08_data = {
> BRCM_CC_43340_CHIP_ID, 2, "meegopad-t08"
> };
>
> -static const struct brcmf_dmi_data pov_tab_p1006w_data = {
> - BRCM_CC_43340_CHIP_ID, 2, "pov-tab-p1006w-data"
> -};
> -
> static const struct dmi_system_id dmi_platform_data[] = {
> {
> /* Match for the GPDwin which unfortunately uses somewhat
> @@ -85,20 +89,18 @@ static const struct dmi_system_id dmi_platform_data[] = {
> },
> .driver_data = (void *)&meegopad_t08_data,
> },
> - {
> - /* Point of View TAB-P1006W-232 */
> - .matches = {
> - DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Insyde"),
> - DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "BayTrail"),
> - /* Note 105b is Foxcon's USB/PCI vendor id */
> - DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "105B"),
> - DMI_EXACT_MATCH(DMI_BOARD_NAME, "0E57"),
> - },
> - .driver_data = (void *)&pov_tab_p1006w_data,
> - },
> {}
> };
>
> +void brcmf_dmi_sanitize(char *dst, const unsigned char *allowed, char safe)
> +{
> + while (*dst) {
> + if ((*dst < 0) || !(allowed[*dst / 8] & (1 << (*dst % 8))))
> + *dst = safe;
> + dst++;
> + }
> +}
> +
> void brcmf_dmi_probe(struct brcmf_mp_device *settings, u32 chip, u32 chiprev)
> {
> const struct dmi_system_id *match;
> @@ -126,6 +128,9 @@ void brcmf_dmi_probe(struct brcmf_mp_device *settings, u32 chip, u32 chiprev)
> if (sys_vendor && product_name) {
> snprintf(dmi_board_type, sizeof(dmi_board_type), "%s-%s",
> sys_vendor, product_name);
> + brcmf_dmi_sanitize(dmi_board_type,
> + brcmf_dmi_allowed_chars,
> + BRCMF_DMI_SAFE_CHAR);
> settings->board_type = dmi_board_type;
> }
> }
>
--
NOTE FOR WINDOWS (TM) USERS: IN NO EVENT UNLESS REQUIRED BY APPLICABLE
LAW WILL I BE LIABLE TO YOU FOR ANY SW OR HW DAMAGE, SYSTEM MALFUNCTION,
DATA LOSS AND/OR DATA BREACH ARISING OUT WHILE YOU ARE READING THIS NOTE.
^ permalink raw reply
* [PATCH RFC] brcmfmac: sanitize DMI strings v2
From: Victor Bravo @ 2019-05-05 15:03 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Franky Lin, Hante Meuleman, Chi-Hsien Lin, Wright Feng,
Kalle Valo, David S. Miller, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, linux-kernel,
Hans de Goede
In-Reply-To: <16a87149068.2764.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com>
Sanitize DMI strings in brcmfmac driver to make resulting filenames
contain only safe characters. This version replaces all non-printable
characters incl. delete (0-31, 127-255), spaces and slashes with
underscores.
This change breaks backward compatibility, but adds control over strings
passed to firmware loader and compatibility with CONFIG_EXTRA_FIRMWARE
which doesn't support spaces in filenames.
Changes from v1: don't revert fresh commit by someone else
Signed-off-by: Victor Bravo <1905@spmblk.com>
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c
index 7535cb0d4ac0..84571e09b465 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c
@@ -23,6 +23,14 @@
/* The DMI data never changes so we can use a static buf for this */
static char dmi_board_type[128];
+/* Array of 128 bits representing 7-bit characters allowed in DMI strings. */
+static unsigned char brcmf_dmi_allowed_chars[] = {
+ 0x00, 0x00, 0x00, 0x00, 0xfe, 0x7f, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x7f
+};
+
+#define BRCMF_DMI_SAFE_CHAR '_'
+
struct brcmf_dmi_data {
u32 chip;
u32 chiprev;
@@ -99,6 +107,15 @@ static const struct dmi_system_id dmi_platform_data[] = {
{}
};
+void brcmf_dmi_sanitize(char *dst, const unsigned char *allowed, char safe)
+{
+ while (*dst) {
+ if ((*dst < 0) || !(allowed[*dst / 8] & (1 << (*dst % 8))))
+ *dst = safe;
+ dst++;
+ }
+}
+
void brcmf_dmi_probe(struct brcmf_mp_device *settings, u32 chip, u32 chiprev)
{
const struct dmi_system_id *match;
@@ -126,6 +143,9 @@ void brcmf_dmi_probe(struct brcmf_mp_device *settings, u32 chip, u32 chiprev)
if (sys_vendor && product_name) {
snprintf(dmi_board_type, sizeof(dmi_board_type), "%s-%s",
sys_vendor, product_name);
+ brcmf_dmi_sanitize(dmi_board_type,
+ brcmf_dmi_allowed_chars,
+ BRCMF_DMI_SAFE_CHAR);
settings->board_type = dmi_board_type;
}
}
^ permalink raw reply related
* [PATCH] mt76: mt7615: rearrange cleanup operations in mt7615_unregister_device
From: Lorenzo Bianconi @ 2019-05-05 15:17 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
In-Reply-To: <cover.1557059004.git.lorenzo@kernel.org>
Cleanup tx/rx napi before releasing pending idrs.
Moreover unmap txwi_cache running mt76_free_device routine
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt7615/init.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
index 3ab3ff553ef2..59f604f3161f 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -212,6 +212,10 @@ void mt7615_unregister_device(struct mt7615_dev *dev)
struct mt76_txwi_cache *txwi;
int id;
+ mt76_unregister_device(&dev->mt76);
+ mt7615_dma_cleanup(dev);
+ mt7615_mcu_exit(dev);
+
spin_lock_bh(&dev->token_lock);
idr_for_each_entry(&dev->token, txwi, id) {
mt7615_txp_skb_unmap(&dev->mt76, txwi);
@@ -221,9 +225,6 @@ void mt7615_unregister_device(struct mt7615_dev *dev)
}
spin_unlock_bh(&dev->token_lock);
idr_destroy(&dev->token);
- mt76_unregister_device(&dev->mt76);
- mt7615_mcu_exit(dev);
- mt7615_dma_cleanup(dev);
- ieee80211_free_hw(mt76_hw(dev));
+ mt76_free_device(&dev->mt76);
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 12/17] mt7615: mcu: do not use function pointers whenever possible
From: Lorenzo Bianconi @ 2019-05-05 15:21 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Ryder Lee, royluo
In-Reply-To: <de228dd80ba394aeb79ed9987e34cb37b495509a.1556981521.git.lorenzo@kernel.org>
>
> Remove function pointers in mt7615_mcu_set_bss_info and run function
> directly. Moreover remove __mt7615_mcu_set_bss_info since it is run just
> by mt7615_mcu_set_bss_info and remove duplicated istructions
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> .../net/wireless/mediatek/mt76/mt7615/mcu.c | 220 +++++++++---------
> 1 file changed, 105 insertions(+), 115 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> index 0e82fcb34e07..0632b506dd57 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> @@ -676,154 +676,107 @@ int mt7615_mcu_set_dev_info(struct mt7615_dev *dev,
> return mt7615_mcu_msg_send(dev, skb, MCU_EXT_CMD_DEV_INFO_UPDATE);
> }
>
[...]
> @@ -832,15 +785,52 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
> WARN_ON(1);
> break;
> }
> - memcpy(bss_info.bssid, vif->bss_conf.bssid, ETH_ALEN);
>
> - if (en) {
> - bss_info.feature |= BIT(BSS_INFO_OMAC);
> - if (mvif->omac_idx > EXT_BSSID_START)
> - bss_info.feature |= BIT(BSS_INFO_EXT_BSS);
> + buf = kzalloc(len, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + hdr = (struct req_hdr *)buf;
> + hdr->bss_idx = mvif->idx;
> + hdr->tlv_num = cpu_to_le16(ntlv);
> + hdr->is_tlv_append = 1;
> +
> + data = buf + sizeof(*hdr);
> + for (i = 0; i < BSS_INFO_MAX_NUM; i++) {
> + int tag = max_t(int, ffs(features & BIT(i)) - 1, 0);
> +
Ops, I found an issue here, it should be:
int tag = ffs(features & BIT(i)) - 1;
@Felix: do I need to resubmit the whole series or just a fix for this patch?
Regards,
Lorenzo
> + switch (tag) {
> + case BSS_INFO_OMAC:
> + mt7615_mcu_bss_info_omac_header(mvif, data,
> + conn_type);
> + data += sizeof(struct bss_info_omac);
> + break;
> + case BSS_INFO_BASIC:
> + mt7615_mcu_bss_info_basic_header(vif, data, net_type,
> + tx_wlan_idx, en);
> + data += sizeof(struct bss_info_basic);
> + break;
> + case BSS_INFO_EXT_BSS:
> + mt7615_mcu_bss_info_ext_header(mvif, data);
> + data += sizeof(struct bss_info_ext_bss);
> + break;
> + default:
> + break;
> + }
> + }
> +
> + skb = mt7615_mcu_msg_alloc(buf, len);
> + if (!skb) {
> + ret = -ENOMEM;
> + goto out;
> }
>
> - return __mt7615_mcu_set_bss_info(dev, &bss_info);
> + ret = mt7615_mcu_msg_send(dev, skb, MCU_EXT_CMD_BSS_INFO_UPDATE);
> +
> +out:
> + kfree(buf);
> +
> + return ret;
> }
>
> static int
> --
> 2.20.1
>
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2019-05-03
From: David Miller @ 2019-05-05 17:21 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87bm0jk9tv.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Fri, 03 May 2019 15:21:16 +0300
> here's a pull request to net-next for 5.2, more information below. Also
> there's a conflict in iwlwifi again and this time I added the conflict
> resolution to the signed tag based on our discussion earlier this week.
> Please let me know what you think or there are any problems.
Pulled, looks great, thanks Kalle.
^ permalink raw reply
* [PATCH][next] brcmfmac: remove redundant u32 comparison with less than zero
From: Colin King @ 2019-05-05 21:16 UTC (permalink / raw)
To: Franky Lin, Hante Meuleman, Chi-Hsien Lin, Wright Feng,
Kalle Valo, David S . Miller, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The check for the u32 variable idx being less than zero is
always false and is redundant. Remove it.
Addresses-Coverity: ("Unsigned compared against 0")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
index 9d1f9ff25bfa..e874dddc7b7f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
@@ -375,7 +375,7 @@ brcmf_msgbuf_get_pktid(struct device *dev, struct brcmf_msgbuf_pktids *pktids,
struct brcmf_msgbuf_pktid *pktid;
struct sk_buff *skb;
- if (idx < 0 || idx >= pktids->array_size) {
+ if (idx >= pktids->array_size) {
brcmf_err("Invalid packet id %d (max %d)\n", idx,
pktids->array_size);
return NULL;
--
2.20.1
^ permalink raw reply related
* [PATCH][next] mt76: fix less than zero check on a u8 variable
From: Colin King @ 2019-05-05 21:31 UTC (permalink / raw)
To: Felix Fietkau, Roy Luo, Kalle Valo, David S . Miller,
Matthias Brugger, linux-wireless, netdev, linux-arm-kernel,
linux-mediatek
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The signed return from the call to get_omac_idx is being assigned to the
u8 variable mac_idx and then checked for a negative error condition
which is always going to be false. Fix this by assigning the return to
the int variable ret and checking this instead.
Addresses-Coverity: ("Unsigned compared against 0")
Fixes: 04b8e65922f6 ("mt76: add mac80211 driver for MT7615 PCIe-based chipsets")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/mediatek/mt76/mt7615/main.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index 80e6b211f60b..460d90d5ed6d 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -77,11 +77,12 @@ static int mt7615_add_interface(struct ieee80211_hw *hw,
goto out;
}
- mvif->omac_idx = get_omac_idx(vif->type, dev->omac_mask);
- if (mvif->omac_idx < 0) {
+ ret = get_omac_idx(vif->type, dev->omac_mask);
+ if (ret < 0) {
ret = -ENOSPC;
goto out;
}
+ mvif->omac_idx = ret;
/* TODO: DBDC support. Use band 0 and wmm 0 for now */
mvif->band_idx = 0;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v8 05/15] x86/msr-index: Define MSR_IA32_CORE_CAPABILITY and split lock detection bit
From: Fenghua Yu @ 2019-05-06 0:12 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Xiaoyao Li, Christopherson Sean J, Kalle Valo,
Michael Chan, linux-kernel, x86, kvm, netdev, linux-wireless
In-Reply-To: <20190426060010.GB122831@gmail.com>
On Fri, Apr 26, 2019 at 08:00:10AM +0200, Ingo Molnar wrote:
>
> * Fenghua Yu <fenghua.yu@intel.com> wrote:
>
> > On Thu, Apr 25, 2019 at 10:08:30PM +0200, Ingo Molnar wrote:
> > >
> > > * Fenghua Yu <fenghua.yu@intel.com> wrote:
> > >
> > > > On Thu, Apr 25, 2019 at 09:47:14PM +0200, Ingo Molnar wrote:
> > > > >
> > > > > * Fenghua Yu <fenghua.yu@intel.com> wrote:
> > > > >
> > > > > > On Thu, Apr 25, 2019 at 07:45:11AM +0200, Ingo Molnar wrote:
> > > > > > >
> > > > > > > * Fenghua Yu <fenghua.yu@intel.com> wrote:
> > > > > > >
> > > > > > > > A new MSR_IA32_CORE_CAPABILITY (0xcf) is defined. Each bit in the MSR
> > > > > > > > enumerates a model specific feature. Currently bit 5 enumerates split
> > > > > > > > lock detection. When bit 5 is 1, split lock detection is supported.
> > > > > > > > When the bit is 0, split lock detection is not supported.
> > > > > > > >
> > > > > > > > Please check the latest Intel 64 and IA-32 Architectures Software
> > > > > > > > Developer's Manual for more detailed information on the MSR and the
> > > > > > > > split lock detection bit.
> > > > > > > >
> > > > > > > > Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> > > > > > > > ---
> > > > > > > > arch/x86/include/asm/msr-index.h | 3 +++
> > > > > > > > 1 file changed, 3 insertions(+)
> > > > > > > >
> > > > > > > > diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> > > > > > > > index ca5bc0eacb95..f65ef6f783d2 100644
> > > > > > > > --- a/arch/x86/include/asm/msr-index.h
> > > > > > > > +++ b/arch/x86/include/asm/msr-index.h
> > > > > > > > @@ -59,6 +59,9 @@
> > > > > > > > #define MSR_PLATFORM_INFO_CPUID_FAULT_BIT 31
> > > > > > > > #define MSR_PLATFORM_INFO_CPUID_FAULT BIT_ULL(MSR_PLATFORM_INFO_CPUID_FAULT_BIT)
> > > > > > > >
> > > > > > > > +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> > > > > > > > +#define CORE_CAP_SPLIT_LOCK_DETECT BIT(5) /* Detect split lock */
> > > > > > >
> > > > > > > Please don't put comments into definitions.
> > > > > >
> > > > > > I'll remove the comment and change definitions of the MSR and the split lock
> > > > > > detection bit as following:
> > > > > >
> > > > > > +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> > > > > > +#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT 5
> > > > > > +#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT BIT(MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT)
> > > > > >
> > > > > > Are these right changes?
> > > > >
> > > > > I suspect it could be shortened to CORE_CAP as you (partly) did it
> > > > > originally.
> > > >
> > > > IA32_CORE_CAPABILITY is the MSR's exact name in the latest SDM (in Table 2-14):
> > > > https://software.intel.com/en-us/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4
> > > >
> > > > So can I define the MSR and the bits as follows?
> > > >
> > > > +#define MSR_IA32_CORE_CAP 0x000000cf
> > > > +#define MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT_BIT 5
> > > > +#define MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT BIT(MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT_BIT)
> > >
> > > Yeah, I suppose that looks OK.
> >
> > Should I also change the feature definition 'X86_FEATURE_CORE_CAPABILITY' to
> > 'X86_FEATURE_CORE_CAP' in cpufeatures.h in patch #0006 to match the
> > MSR definition here? Or should I still keep the current feature definition?
> >
> > Thanks.
>
> Hm, no, for CPU features it's good to follow the vendor convention.
>
> So I guess the long-form CPU_CAPABILITY for all of these is the best
> after all.
Since MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT_BIT is not used anywhere else
except in this patch, is it OK not to define this macro?
So this patch will only has two shorter lines:
+#define MSR_IA32_CORE_CAP 0x000000cf
+#define MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT BIT(5)
Is this OK for this patch to only define these two macros?
Thanks.
-Fenghua
^ permalink raw reply
* Re: [PATCH v8 15/15] x86/split_lock: Add a sysfs interface to enable/disable split lock detection during run time
From: Fenghua Yu @ 2019-05-06 0:21 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Xiaoyao Li, Christopherson Sean J, Kalle Valo,
Michael Chan, linux-kernel, x86, kvm, netdev, linux-wireless
In-Reply-To: <20190425063115.GD40105@gmail.com>
On Thu, Apr 25, 2019 at 08:31:15AM +0200, Ingo Molnar wrote:
>
> * Fenghua Yu <fenghua.yu@intel.com> wrote:
>
> > + disabled if split lock operation in kernel code happens on
> > + the CPU. The interface doesn't show or control split lock
> > + detection on individual CPU.
>
> I.e. implementation and possible actual state are out of sync. Why?
>
> Also, if it's a global flag, why waste memory on putting a sysfs knob
> into every CPU's sysfs file?
>
> Finally, why is a debugging facility in sysfs, why not a debugfs knob?
> Using a sysctl would solve the percpu vs. global confusion as well ...
Can I put the interface in /sys/kernel/debug/x86/split_lock_detect?
>
> > --- a/arch/x86/kernel/cpu/intel.c
> > +++ b/arch/x86/kernel/cpu/intel.c
> > @@ -35,6 +35,7 @@
> > DEFINE_PER_CPU(u64, msr_test_ctl_cache);
> > EXPORT_PER_CPU_SYMBOL_GPL(msr_test_ctl_cache);
> >
> > +static DEFINE_MUTEX(split_lock_detect_mutex);
> > static bool split_lock_detect_enable;
>
> 'enable' is a verb in plain form - which we use for function names.
>
> For variable names that denotes current state we typically use past
> tense, i.e. 'enabled'.
>
> (The only case where we'd us the split_lock_detect_enable name for a flag
> if it's a flag to trigger some sort of enabling action - which this
> isn't.)
>
> Please review the whole series for various naming mishaps.
OK.
>
> > + mutex_lock(&split_lock_detect_mutex);
> > +
> > + split_lock_detect_enable = val;
> > +
> > + /* Update the split lock detection setting in MSR on all online CPUs. */
> > + on_each_cpu(split_lock_update_msr, NULL, 1);
> > +
> > + if (split_lock_detect_enable)
> > + pr_info("enabled\n");
> > + else
> > + pr_info("disabled\n");
> > +
> > + mutex_unlock(&split_lock_detect_mutex);
>
> Instead of a mutex, please just use the global atomic debug flag which
> controls the warning printout. By using that flag both for the WARN()ing
> and for controlling MSR state all the races are solved and the code is
> simplified.
So is it OK to define split_lock_debug and use it in #AC handler and in
here?
static atomic_t split_lock_debug;
in #AC handler:
+ if (atomic_cmpxchg(&split_lock_debug, 0, 1) == 0) {
+ /* Only warn split lock once */
+ WARN_ONCE(1, "split lock operation detected\n");
+ atomic_set(&split_lock_debug, 0);
+ }
And in split_lock_detect_store(), replace the mutex with split_lock_debug
like this:
- mutex_lock(&split_lock_detect_mutex);
+ while (atomic_cmpxchg(&split_lock_debug, 1, 0))
+ cpu_relax();
....
- mutex_unlock(&split_lock_detect_mutex);
+ atomic_set(&split_lock_debug, 0);
Is this right code for sync in both #AC handler and in
split_lock_detect_store()?
Thanks.
-Fenghua
^ permalink raw reply
* RE: [RFC] rtw88: fix subscript above array bounds compiler warning
From: Tony Chuang @ 2019-05-06 3:42 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20190503122426.GA4423@redhat.com>
> Subject: Re: [RFC] rtw88: fix subscript above array bounds compiler warning
>
> On Fri, May 03, 2019 at 12:01:05PM +0000, Tony Chuang wrote:
> > > Subject: [RFC] rtw88: fix subscript above array bounds compiler warning
> > >
> > > My compiler complain about:
> > >
> > > drivers/net/wireless/realtek/rtw88/phy.c: In function
> > > ‘rtw_phy_rf_power_2_rssi’:
> > > drivers/net/wireless/realtek/rtw88/phy.c:430:26: warning: array subscript is
> > > above array bounds [-Warray-bounds]
> > > linear = db_invert_table[i][j];
> > >
> > > According to comment power_db should be in range 1 ~ 96 .
> > > Correct rtw_phy_power_2_db() to make max power 96 db
> > > (still min is 0). This make the warning gone.
> > >
> > > However power >= 20 check still looks somewhat suspicious to me.
> > >
> > > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> > > ---
> > > drivers/net/wireless/realtek/rtw88/phy.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/realtek/rtw88/phy.c
> > > b/drivers/net/wireless/realtek/rtw88/phy.c
> > > index 35a35dbca85f..a716a44d78b0 100644
> > > --- a/drivers/net/wireless/realtek/rtw88/phy.c
> > > +++ b/drivers/net/wireless/realtek/rtw88/phy.c
> > > @@ -410,12 +410,12 @@ void rtw_phy_dynamic_mechanism(struct
> rtw_dev
> > > *rtwdev)
> > >
> > > static u8 rtw_phy_power_2_db(s8 power)
> > > {
> > > - if (power <= -100 || power >= 20)
> > > + if (power <= -96 || power >= 20)
> > > return 0;
> > > else if (power >= 0)
> > > - return 100;
> > > + return 96;
> > > else
> > > - return 100 + power;
> > > + return 96 + power;
> > > }
> > >
> > > static u64 rtw_phy_db_2_linear(u8 power_db)
> > > --
> >
> > I think I should check with the radio team, that if the power from the
> > rx descriptor generated by hardware can possibly get >= 20
> >
> > And also check what the actual logic they expected to deal with the power.
> > Thanks for reporting it.
>
> Yeah, this could be just teoretical issue as we can not get power
> values >= 0 from HW. However I think compiler correctly complains, as
> for power_db=100 we get i = ((100 - 1) >> 3) = 12 , what exceed by one
> max first index of db_invert_table[][], which should be in range
> 0 - 11.
>
I checked it. The power sum could actually be like 20 or something.
And the recommended modification is to restrict the value used for array
subscript between 1~96 before access the array. Such as:
@@ -578,6 +578,11 @@ static u64 rtw_phy_db_2_linear(u8 power_db)
u8 i, j;
u64 linear;
+ if (power_db > 96)
+ power_db = 96;
+ else if (power_db < 1)
+ return 1;
+
/* 1dB ~ 96dB */
i = (power_db - 1) >> 3;
j = (power_db - 1) - (i << 3);
Yan-Hsuan
^ permalink raw reply
* Re: [PATCH][next] brcmfmac: remove redundant u32 comparison with less than zero
From: Rafał Miłecki @ 2019-05-06 4:11 UTC (permalink / raw)
To: Colin King, Wright Feng
Cc: Franky Lin, Hante Meuleman, Chi-Hsien Lin, Kalle Valo,
David S . Miller, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER <brcm80211-dev-list.pdl@broadcom.com>,,
Network Development, kernel-janitors, Linux Kernel Mailing List
In-Reply-To: <20190505211623.3153-1-colin.king@canonical.com>
On Sun, 5 May 2019 at 23:33, Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The check for the u32 variable idx being less than zero is
> always false and is redundant. Remove it.
>
> Addresses-Coverity: ("Unsigned compared against 0")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
> index 9d1f9ff25bfa..e874dddc7b7f 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
> @@ -375,7 +375,7 @@ brcmf_msgbuf_get_pktid(struct device *dev, struct brcmf_msgbuf_pktids *pktids,
> struct brcmf_msgbuf_pktid *pktid;
> struct sk_buff *skb;
>
> - if (idx < 0 || idx >= pktids->array_size) {
> + if (idx >= pktids->array_size) {
> brcmf_err("Invalid packet id %d (max %d)\n", idx,
> pktids->array_size);
> return NULL;
It was added in the commit 2d91c8ad068a ("brcmfmac: set txflow request
id from 1 to pktids array size") and was probably meant to handle a
following brcmf_msgbuf_process_txstatus() case:
idx = le32_to_cpu(tx_status->msg.request_id) - 1;
So this patch is wrong/incomplete.
You should change that to a signed value OR add an extra check in
brcmf_msgbuf_process_txstatus() to make sure it doesn't pass -1 as u32
argument.
--
Rafał
^ 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