* [PATCH 3/6] mt76: mt7615: do not perform txcalibration before cac is complited
From: Lorenzo Bianconi @ 2019-06-29 10:36 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo, yf.luo
In-Reply-To: <cover.1561804422.git.lorenzo@kernel.org>
Delay channel calibration after Channel Availability Check. Add some
code cleanup to mt7615_mcu_set_channel
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
.../net/wireless/mediatek/mt76/mt7615/mcu.c | 25 +++++++++++--------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index c3fefccf3d5b..397ae4f95db8 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -1280,7 +1280,8 @@ int mt7615_mcu_rdd_cmd(struct mt7615_dev *dev,
int mt7615_mcu_set_channel(struct mt7615_dev *dev)
{
- struct cfg80211_chan_def *chdef = &dev->mt76.chandef;
+ struct cfg80211_chan_def *chandef = &dev->mt76.chandef;
+ int freq1 = chandef->center_freq1, freq2 = chandef->center_freq2;
struct {
u8 control_chan;
u8 center_chan;
@@ -1299,17 +1300,20 @@ int mt7615_mcu_set_channel(struct mt7615_dev *dev)
u8 rsv1[3];
u8 txpower_sku[53];
u8 rsv2[3];
- } req = {0};
+ } req = {
+ .control_chan = chandef->chan->hw_value,
+ .center_chan = ieee80211_frequency_to_channel(freq1),
+ .tx_streams = (dev->mt76.chainmask >> 8) & 0xf,
+ .rx_streams_mask = dev->mt76.antenna_mask,
+ .center_chan2 = ieee80211_frequency_to_channel(freq2),
+ };
int ret;
- req.control_chan = chdef->chan->hw_value;
- req.center_chan = ieee80211_frequency_to_channel(chdef->center_freq1);
- req.tx_streams = (dev->mt76.chainmask >> 8) & 0xf;
- req.rx_streams_mask = dev->mt76.antenna_mask;
- req.switch_reason = CH_SWITCH_NORMAL;
- req.band_idx = 0;
- req.center_chan2 = ieee80211_frequency_to_channel(chdef->center_freq2);
- req.txpower_drop = 0;
+ if ((chandef->chan->flags & IEEE80211_CHAN_RADAR) &&
+ chandef->chan->dfs_state != NL80211_DFS_AVAILABLE)
+ req.switch_reason = CH_SWITCH_DFS;
+ else
+ req.switch_reason = CH_SWITCH_NORMAL;
switch (dev->mt76.chandef.width) {
case NL80211_CHAN_WIDTH_40:
@@ -1334,6 +1338,7 @@ int mt7615_mcu_set_channel(struct mt7615_dev *dev)
case NL80211_CHAN_WIDTH_20:
default:
req.bw = CMD_CBW_20MHZ;
+ break;
}
memset(req.txpower_sku, 0x3f, 49);
--
2.21.0
^ permalink raw reply related
* [PATCH 2/6] mt76: mt7615: add hw dfs pattern detector support
From: Lorenzo Bianconi @ 2019-06-29 10:36 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo, yf.luo
In-Reply-To: <cover.1561804422.git.lorenzo@kernel.org>
Add hw radar detection support to mt7615 driver in order to
unlock dfs channels on 5GHz band
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
.../net/wireless/mediatek/mt76/mt7615/dma.c | 2 +-
.../net/wireless/mediatek/mt76/mt7615/init.c | 17 ++++
.../net/wireless/mediatek/mt76/mt7615/mac.c | 88 +++++++++++++++++++
.../net/wireless/mediatek/mt76/mt7615/main.c | 6 ++
.../net/wireless/mediatek/mt76/mt7615/mcu.c | 65 ++++++++++++++
.../net/wireless/mediatek/mt76/mt7615/mcu.h | 22 +++++
.../wireless/mediatek/mt76/mt7615/mt7615.h | 46 ++++++++++
7 files changed, 245 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/dma.c b/drivers/net/wireless/mediatek/mt76/mt7615/dma.c
index 6a70273d4a69..3fe24d92d4fa 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/dma.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/dma.c
@@ -76,7 +76,7 @@ void mt7615_queue_rx_skb(struct mt76_dev *mdev, enum mt76_rxq_id q,
mt7615_mac_tx_free(dev, skb);
break;
case PKT_TYPE_RX_EVENT:
- mt76_mcu_rx_event(&dev->mt76, skb);
+ mt7615_mcu_rx_event(dev, skb);
break;
case PKT_TYPE_NORMAL:
if (!mt7615_mac_fill_rx(dev, skb)) {
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
index edce96ce79a4..5dc4cced5789 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -163,6 +163,8 @@ static int mt7615_init_debugfs(struct mt7615_dev *dev)
if (!dir)
return -ENOMEM;
+ debugfs_create_u32("dfs_hw_pattern", 0400, dir, &dev->hw_pattern);
+
return 0;
}
@@ -214,8 +216,22 @@ mt7615_regd_notifier(struct wiphy *wiphy,
{
struct ieee80211_hw *hw = wiphy_to_ieee80211_hw(wiphy);
struct mt7615_dev *dev = hw->priv;
+ struct cfg80211_chan_def *chandef = &dev->mt76.chandef;
+
+ if (request->dfs_region == dev->mt76.region)
+ return;
dev->mt76.region = request->dfs_region;
+
+ if (!(chandef->chan->flags & IEEE80211_CHAN_RADAR))
+ return;
+
+ mt7615_dfs_stop_radar_detector(dev);
+ if (request->dfs_region == NL80211_DFS_UNSET)
+ mt7615_mcu_rdd_cmd(dev, RDD_CAC_END, MT_HW_RDD0,
+ MT_RX_SEL0, 0);
+ else
+ mt7615_dfs_start_radar_detector(dev);
}
int mt7615_register_device(struct mt7615_dev *dev)
@@ -254,6 +270,7 @@ int mt7615_register_device(struct mt7615_dev *dev)
IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ;
dev->mt76.chainmask = 0x404;
dev->mt76.antenna_mask = 0xf;
+ dev->dfs_state = -1;
wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
#ifdef CONFIG_MAC80211_MESH
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
index 1eb0e9c9970c..08cc3f46b011 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
@@ -746,3 +746,91 @@ void mt7615_mac_work(struct work_struct *work)
ieee80211_queue_delayed_work(mt76_hw(dev), &dev->mt76.mac_work,
MT7615_WATCHDOG_TIME);
}
+
+int mt7615_dfs_stop_radar_detector(struct mt7615_dev *dev)
+{
+ struct cfg80211_chan_def *chandef = &dev->mt76.chandef;
+ int err;
+
+ err = mt7615_mcu_rdd_cmd(dev, RDD_STOP, MT_HW_RDD0,
+ MT_RX_SEL0, 0);
+ if (err < 0)
+ return err;
+
+ if (chandef->width == NL80211_CHAN_WIDTH_160 ||
+ chandef->width == NL80211_CHAN_WIDTH_80P80)
+ err = mt7615_mcu_rdd_cmd(dev, RDD_STOP, MT_HW_RDD1,
+ MT_RX_SEL0, 0);
+ return err;
+}
+
+static int mt7615_dfs_start_rdd(struct mt7615_dev *dev, int chain)
+{
+ int err;
+
+ err = mt7615_mcu_rdd_cmd(dev, RDD_START, chain, MT_RX_SEL0, 0);
+ if (err < 0)
+ return err;
+
+ return mt7615_mcu_rdd_cmd(dev, RDD_DET_MODE, chain,
+ MT_RX_SEL0, 1);
+}
+
+int mt7615_dfs_start_radar_detector(struct mt7615_dev *dev)
+{
+ struct cfg80211_chan_def *chandef = &dev->mt76.chandef;
+ int err;
+
+ /* start CAC */
+ err = mt7615_mcu_rdd_cmd(dev, RDD_CAC_START, MT_HW_RDD0,
+ MT_RX_SEL0, 0);
+ if (err < 0)
+ return err;
+
+ /* TODO: DBDC support */
+
+ err = mt7615_dfs_start_rdd(dev, MT_HW_RDD0);
+ if (err < 0)
+ return err;
+
+ if (chandef->width == NL80211_CHAN_WIDTH_160 ||
+ chandef->width == NL80211_CHAN_WIDTH_80P80) {
+ err = mt7615_dfs_start_rdd(dev, MT_HW_RDD1);
+ if (err < 0)
+ return err;
+ }
+
+ return 0;
+}
+
+int mt7615_dfs_init_radar_detector(struct mt7615_dev *dev)
+{
+ struct cfg80211_chan_def *chandef = &dev->mt76.chandef;
+ int err;
+
+ if (dev->mt76.region == NL80211_DFS_UNSET)
+ return 0;
+
+ if (test_bit(MT76_SCANNING, &dev->mt76.state))
+ return 0;
+
+ if (dev->dfs_state == chandef->chan->dfs_state)
+ return 0;
+
+ dev->dfs_state = chandef->chan->dfs_state;
+
+ if (chandef->chan->flags & IEEE80211_CHAN_RADAR) {
+ if (chandef->chan->dfs_state != NL80211_DFS_AVAILABLE)
+ return mt7615_dfs_start_radar_detector(dev);
+ else
+ return mt7615_mcu_rdd_cmd(dev, RDD_CAC_END, MT_HW_RDD0,
+ MT_RX_SEL0, 0);
+ } else {
+ err = mt7615_mcu_rdd_cmd(dev, RDD_NORMAL_START,
+ MT_HW_RDD0, MT_RX_SEL0, 0);
+ if (err < 0)
+ return err;
+
+ return mt7615_dfs_stop_radar_detector(dev);
+ }
+}
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index b4d6af812c54..cf9be4944cf7 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -137,12 +137,18 @@ static int mt7615_set_channel(struct mt7615_dev *dev)
cancel_delayed_work_sync(&dev->mt76.mac_work);
set_bit(MT76_RESET, &dev->mt76.state);
+ mt7615_dfs_check_channel(dev);
+
mt76_set_channel(&dev->mt76);
ret = mt7615_mcu_set_channel(dev);
if (ret)
return ret;
+ ret = mt7615_dfs_init_radar_detector(dev);
+ if (ret < 0)
+ return ret;
+
clear_bit(MT76_RESET, &dev->mt76.state);
mt76_txq_schedule_all(&dev->mt76);
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index 282b46c6d33d..c3fefccf3d5b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -159,6 +159,50 @@ mt7615_mcu_msg_send(struct mt76_dev *mdev, int cmd, const void *data,
return ret;
}
+static void
+mt7615_mcu_rx_ext_event(struct mt7615_dev *dev, struct sk_buff *skb)
+{
+ struct mt7615_mcu_rxd *rxd = (struct mt7615_mcu_rxd *)skb->data;
+
+ switch (rxd->ext_eid) {
+ case MCU_EXT_EVENT_RDD_REPORT:
+ ieee80211_radar_detected(dev->mt76.hw);
+ dev->hw_pattern++;
+ break;
+ default:
+ break;
+ }
+}
+
+static void
+mt7615_mcu_rx_unsolicited_event(struct mt7615_dev *dev, struct sk_buff *skb)
+{
+ struct mt7615_mcu_rxd *rxd = (struct mt7615_mcu_rxd *)skb->data;
+
+ switch (rxd->eid) {
+ case MCU_EVENT_EXT:
+ mt7615_mcu_rx_ext_event(dev, skb);
+ break;
+ default:
+ break;
+ }
+ dev_kfree_skb(skb);
+}
+
+void mt7615_mcu_rx_event(struct mt7615_dev *dev, struct sk_buff *skb)
+{
+ struct mt7615_mcu_rxd *rxd = (struct mt7615_mcu_rxd *)skb->data;
+
+ if (rxd->ext_eid == MCU_EXT_EVENT_THERMAL_PROTECT ||
+ rxd->ext_eid == MCU_EXT_EVENT_FW_LOG_2_HOST ||
+ rxd->ext_eid == MCU_EXT_EVENT_ASSERT_DUMP ||
+ rxd->ext_eid == MCU_EXT_EVENT_PS_SYNC ||
+ !rxd->seq)
+ mt7615_mcu_rx_unsolicited_event(dev, skb);
+ else
+ mt76_mcu_rx_event(&dev->mt76, skb);
+}
+
static int mt7615_mcu_init_download(struct mt7615_dev *dev, u32 addr,
u32 len, u32 mode)
{
@@ -1213,6 +1257,27 @@ int mt7615_mcu_set_tx_power(struct mt7615_dev *dev)
return ret;
}
+int mt7615_mcu_rdd_cmd(struct mt7615_dev *dev,
+ enum mt7615_rdd_cmd cmd, u8 index,
+ u8 rx_sel, u8 val)
+{
+ struct {
+ u8 ctrl;
+ u8 rdd_idx;
+ u8 rdd_rx_sel;
+ u8 val;
+ u8 rsv[4];
+ } req = {
+ .ctrl = cmd,
+ .rdd_idx = index,
+ .rdd_rx_sel = rx_sel,
+ .val = val,
+ };
+
+ return __mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD_SET_RDD_CTRL,
+ &req, sizeof(req), true);
+}
+
int mt7615_mcu_set_channel(struct mt7615_dev *dev)
{
struct cfg80211_chan_def *chdef = &dev->mt76.chandef;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
index f8b51ad25220..5fe492189f56 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
@@ -23,6 +23,27 @@ struct mt7615_mcu_txd {
u32 reserved[5];
} __packed __aligned(4);
+/* event table */
+enum {
+ MCU_EVENT_TARGET_ADDRESS_LEN = 0x01,
+ MCU_EVENT_FW_START = 0x01,
+ MCU_EVENT_GENERIC = 0x01,
+ MCU_EVENT_ACCESS_REG = 0x02,
+ MCU_EVENT_MT_PATCH_SEM = 0x04,
+ MCU_EVENT_CH_PRIVILEGE = 0x18,
+ MCU_EVENT_EXT = 0xed,
+ MCU_EVENT_RESTART_DL = 0xef,
+};
+
+/* ext event table */
+enum {
+ MCU_EXT_EVENT_PS_SYNC = 0x5,
+ MCU_EXT_EVENT_FW_LOG_2_HOST = 0x13,
+ MCU_EXT_EVENT_THERMAL_PROTECT = 0x22,
+ MCU_EXT_EVENT_ASSERT_DUMP = 0x23,
+ MCU_EXT_EVENT_RDD_REPORT = 0x3a,
+};
+
struct mt7615_mcu_rxd {
__le32 rxd[4];
@@ -77,6 +98,7 @@ enum {
MCU_EXT_CMD_EDCA_UPDATE = 0x27,
MCU_EXT_CMD_DEV_INFO_UPDATE = 0x2A,
MCU_EXT_CMD_WTBL_UPDATE = 0x32,
+ MCU_EXT_CMD_SET_RDD_CTRL = 0x3a,
MCU_EXT_CMD_PROTECT_CTRL = 0x3e,
MCU_EXT_CMD_MAC_INIT_CTRL = 0x46,
MCU_EXT_CMD_BCN_OFFLOAD = 0x49,
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h b/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h
index f02ffcffe637..d113fa30115e 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h
@@ -68,6 +68,9 @@ struct mt7615_dev {
u32 vif_mask;
u32 omac_mask;
+ u32 hw_pattern;
+ int dfs_state;
+
spinlock_t token_lock;
struct idr token;
};
@@ -97,6 +100,30 @@ enum {
EXT_BSSID_END
};
+enum {
+ MT_HW_RDD0,
+ MT_HW_RDD1,
+};
+
+enum {
+ MT_RX_SEL0,
+ MT_RX_SEL1,
+};
+
+enum mt7615_rdd_cmd {
+ RDD_STOP,
+ RDD_START,
+ RDD_DET_MODE,
+ RDD_DET_STOP,
+ RDD_CAC_START,
+ RDD_CAC_END,
+ RDD_NORMAL_START,
+ RDD_DISABLE_DFS_CAL,
+ RDD_PULSE_DBG,
+ RDD_READ_PULSE,
+ RDD_RESUME_BF,
+};
+
extern const struct ieee80211_ops mt7615_ops;
extern struct pci_driver mt7615_pci_driver;
@@ -144,6 +171,23 @@ int mt7615_mcu_set_rx_ba(struct mt7615_dev *dev,
bool add);
int mt7615_mcu_set_ht_cap(struct mt7615_dev *dev, struct ieee80211_vif *vif,
struct ieee80211_sta *sta);
+void mt7615_mcu_rx_event(struct mt7615_dev *dev, struct sk_buff *skb);
+int mt7615_mcu_rdd_cmd(struct mt7615_dev *dev,
+ enum mt7615_rdd_cmd cmd, u8 index,
+ u8 rx_sel, u8 val);
+int mt7615_dfs_start_radar_detector(struct mt7615_dev *dev);
+int mt7615_dfs_stop_radar_detector(struct mt7615_dev *dev);
+
+static inline void mt7615_dfs_check_channel(struct mt7615_dev *dev)
+{
+ enum nl80211_chan_width width = dev->mt76.chandef.width;
+ u32 freq = dev->mt76.chandef.chan->center_freq;
+ struct ieee80211_hw *hw = mt76_hw(dev);
+
+ if (hw->conf.chandef.chan->center_freq != freq ||
+ hw->conf.chandef.width != width)
+ dev->dfs_state = -1;
+}
static inline void mt7615_irq_enable(struct mt7615_dev *dev, u32 mask)
{
@@ -193,5 +237,7 @@ void mt7615_sta_remove(struct mt76_dev *mdev, struct ieee80211_vif *vif,
void mt7615_mac_work(struct work_struct *work);
void mt7615_txp_skb_unmap(struct mt76_dev *dev,
struct mt76_txwi_cache *txwi);
+int mt76_dfs_start_rdd(struct mt7615_dev *dev, bool force);
+int mt7615_dfs_init_radar_detector(struct mt7615_dev *dev);
#endif
--
2.21.0
^ permalink raw reply related
* [PATCH 1/6] mt76: mt7615: introduce mt7615_regd_notifier
From: Lorenzo Bianconi @ 2019-06-29 10:36 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo, yf.luo
In-Reply-To: <cover.1561804422.git.lorenzo@kernel.org>
Introduce mt7615_regd_notifier callback. This is a preliminary patch to
add radar detection support to mt7615 driver
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt7615/init.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
index 859de2454ec6..edce96ce79a4 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -208,6 +208,16 @@ mt7615_init_txpower(struct mt7615_dev *dev,
}
}
+static void
+mt7615_regd_notifier(struct wiphy *wiphy,
+ struct regulatory_request *request)
+{
+ struct ieee80211_hw *hw = wiphy_to_ieee80211_hw(wiphy);
+ struct mt7615_dev *dev = hw->priv;
+
+ dev->mt76.region = request->dfs_region;
+}
+
int mt7615_register_device(struct mt7615_dev *dev)
{
struct ieee80211_hw *hw = mt76_hw(dev);
@@ -230,6 +240,7 @@ int mt7615_register_device(struct mt7615_dev *dev)
wiphy->iface_combinations = if_comb;
wiphy->n_iface_combinations = ARRAY_SIZE(if_comb);
+ wiphy->reg_notifier = mt7615_regd_notifier;
ieee80211_hw_set(hw, SUPPORTS_REORDERING_BUFFER);
ieee80211_hw_set(hw, TX_STATUS_NO_AMPDU_LEN);
--
2.21.0
^ permalink raw reply related
* [PATCH 0/6] add hw dfs pattern detector support to mt7615 driver
From: Lorenzo Bianconi @ 2019-06-29 10:36 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo, yf.luo
Introduce radar pattern detection support to mt7615 driver.
Add Channel Switch Announcement support updating beacon template with
CSA IE received from mac80211.
Please note I have tested this series just through the radar pattern test
knob added to debugfs and not through I real radar signal generator.
Lorenzo Bianconi (6):
mt76: mt7615: introduce mt7615_regd_notifier
mt76: mt7615: add hw dfs pattern detector support
mt76: mt7615: do not perform txcalibration before cac is complited
mt76: mt7615: unlock dfs bands
mt76: mt7615: add csa support
mt76: mt7615: add radar pattern test knob to debugfs
.../wireless/mediatek/mt76/mt7615/Makefile | 3 +-
.../wireless/mediatek/mt76/mt7615/debugfs.c | 38 +++++
.../net/wireless/mediatek/mt76/mt7615/dma.c | 2 +-
.../net/wireless/mediatek/mt76/mt7615/init.c | 44 ++++--
.../net/wireless/mediatek/mt76/mt7615/mac.c | 88 +++++++++++
.../net/wireless/mediatek/mt76/mt7615/main.c | 19 +++
.../net/wireless/mediatek/mt76/mt7615/mcu.c | 147 ++++++++++++++++--
.../net/wireless/mediatek/mt76/mt7615/mcu.h | 24 +++
.../wireless/mediatek/mt76/mt7615/mt7615.h | 55 +++++++
9 files changed, 392 insertions(+), 28 deletions(-)
create mode 100644 drivers/net/wireless/mediatek/mt76/mt7615/debugfs.c
--
2.21.0
^ permalink raw reply
* Re: [PATCH] rt2x00: fix rx queue hang
From: Stanislaw Gruszka @ 2019-06-29 8:50 UTC (permalink / raw)
To: Soeren Moch
Cc: Helmut Schaa, Kalle Valo, David S. Miller, linux-wireless, netdev,
linux-kernel, stable
In-Reply-To: <8d7da251-8218-ff4b-2cf3-8ed69c97275e@web.de>
Hello
On Wed, Jun 26, 2019 at 03:28:00PM +0200, Soeren Moch wrote:
> Hi Stanislaw,
>
> the good news is: your patch below also solves the issue for me. But
> removing the ENTRY_DATA_STATUS_PENDING check in
> rt2x00usb_kick_rx_entry() alone does not help, while removing this check
> in rt2x00usb_work_rxdone() alone does the trick.
>
> So the real race seems to be that the flags set in the completion
> handler are not yet visible on the cpu core running the workqueue. And
> because the worker is not rescheduled when aborted, the entry can just
> wait forever.
> Do you think this could make sense?
Yes.
> > I'm somewhat reluctant to change the order, because TX processing
> > might relay on it (we first mark we wait for TX status and
> > then mark entry is no longer owned by hardware).
> OK, maybe it's just good luck that changing the order solves the rx
> problem. Or can memory barriers associated with the spinlock in
> rt2x00lib_dmadone() be responsible for that?
> (I'm testing on a armv7 system, Cortex-A9 quadcore.)
I'm not sure, rt2x00queue_index_inc() also disable/enable interrupts,
so maybe that make race not reproducible.
> While looking at it, why we double-clear ENTRY_OWNER_DEVICE_DATA in
> rt2x00usb_interrupt_rxdone() directly and in rt2x00lib_dmadone() again,
rt2x00lib_dmadone() is called also on other palaces (error paths)
when we have to clear flags.
> while not doing the same for tx?
If I remember correctly we have some races on rx (not happened on tx)
that was solved by using test_and_clear_bit(ENTRY_OWNER_DEVICE_DATA).
> Would it make more sense to possibly
> set ENTRY_DATA_IO_FAILED before clearing ENTRY_OWNER_DEVICE_DATA in
> rt2x00usb_interrupt_rxdone() as for tx?
I don't think so, ENTRY_DATA_IO_FAILED should be only set on error
case.
> > However on RX
> > side ENTRY_DATA_STATUS_PENDING bit make no sense as we do not
> > wait for status. We should remove ENTRY_DATA_STATUS_PENDING on
> > RX side and perhaps this also will solve issue you observe.
> I agree that removing the unnecessary checks is a good idea in any case.
> > Could you please check below patch, if it fixes the problem as well?
> At least I could not trigger the problem within transferring 10GB of
> data. But maybe the probability for triggering this bug is just lower
> because ENTRY_OWNER_DEVICE_DATA is cleared some time before
> ENTRY_DATA_STATUS_PENDING is set?
Not sure. Anyway, could you post patch removing not needed checks
with proper description/changelog ?
Stanislaw
^ permalink raw reply
* Re: [PATCH v3] ath9k: add loader for AR92XX (and older) pci(e)
From: Christian Lamparter @ 2019-06-29 8:44 UTC (permalink / raw)
To: Kalle Valo, martin.blumenstingl, chrisrblake93, jonas.gorski
Cc: linux-wireless, QCA ath9k Development, Julian Calaby, dev, juhosg,
john, hauke, jow
In-Reply-To: <87tvcasxpg.fsf@purkki.adurom.net>
Hello,
(Sorry for the delay. I only have time for dealing with this
on the weekends. Thanks!)
On Thursday, June 27, 2019 8:13:47 PM CEST Kalle Valo wrote:
> Christian Lamparter <chunkeey@gmail.com> writes:
> > Atheros cards with a AR92XX generation (and older) chip usually
> > store their pci(e) initialization vectors on an external eeprom chip.
> > However these chips technically don't need the eeprom chip attached,
> > the AR9280 Datasheet in section "6.1.2 DEVICE_ID" describes that
> > "... if the EEPROM content is not valid, a value of 0xFF1C returns
> > when read from the register". So, they will show up on the system's
> > pci bus. However in that state, ath9k can't load, since it relies
> > on having the correct pci-id, otherwise it doesn't know what chip it
> > actually is. This happens on many embedded devices like routers
> > and accesspoint since they want to keep the BOM low and store the
> > pci(e) initialization vectors together with the calibration data
> > on the system's FLASH, which is out of reach of the ath9k chip.
> >
> > Furthermore, Some devices (like the Cisco Meraki Z1 Cloud Managed
> > Teleworker Gateway) need to be able to initialize the PCIe wifi device.
> > Normally, this should be done as a pci quirk during the early stages of
> > booting linux. However, this isn't possible for devices which have the
> > init code for the Atheros chip stored on NAND in an UBI volume.
> > Hence, this module can be used to initialize the chip when the
> > user-space is ready to extract the init code.
> >
> > Martin Blumenstingl prodived the following fixes:
> > owl-loader: add support for OWL emulation PCI devices
> > owl-loader: don't re-scan the bus when ath9k_pci_fixup failed
> > owl-loader: use dev_* instead of pr_* logging functions
> > owl-loader: auto-generate the eeprom filename as fallback
> > owl-loader: add a debug message when swapping the eeprom data
> > owl-loader: add missing newlines in log messages
> >
> > Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
> > Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>
> [...]
>
> > --- /dev/null
> > +++ b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
> > @@ -0,0 +1,215 @@
> > +// SPDX-License-Identifier: GPL-2.0
>
> [...]
>
> > +MODULE_LICENSE("GPL v2");
>
> ath9k has ISC license, is there a specific reason why you chose GPLv2
> here instead of ISC? I don't like mixing licenses within a driver,
> that's why I'm asking.
About that: The commit message hints The owl-loader was written because
Chris Blake needed it for the Cisco Meraki Z1 (Atheros based SoC) because
the existing methods in the OpenWrt project were designed to work with
straight-from-SPI-NOR. OpenWrt already had multiple different versions for
each platform (ar71xx = Atheros SoCs, lantiq, brcm63xx) of the
pci-ath9k-fixup.c which are all licensed under GPLv2 and they predated
owl-loader initiative by about 8 years.
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/files/arch/mips/ath79/pci-ath9k-fixup.c
(lantiq's version has been since replaced by the owl-loader)
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/brcm63xx/patches-4.14/416-BCM63XX-add-a-fixup-for-ath9k-devices.patch
(ar71xx has been deprecated and will be dropped in favor of the upstream
DeviceTree ath79 which relies on the owl-loader exclusivly)
So this is were the license comes from: Existing code looks similar.
And while the owl-loader was written from scratch as it needed:
- to get the via firmware_request to make it as universal as possible
- be able to support all platforms (no fixed pci(e) addresses)
- separate driver as a module (and not a pci fixup)
I went for the safer "GPLv2" as it is the standard OpenWrt License:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=LICENSE
That said: I have no problem relicensing my code under the ISC, if it
helps with the upstreaming process. I've added Chris, Martin and
Mathias as they both were consultants, as well as the previous
authors of three targets to "let them know".
Best Regards,
Christian
(Yeah, I think this might take a while longer. So please don't delete
it just yet.)
^ permalink raw reply
* pull-request: iwlwifi-next 2019-06-29
From: Luca Coelho @ 2019-06-29 7:29 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, linuxwifi, david.e.box, joe.konno
[-- Attachment #1: Type: text/plain, Size: 7149 bytes --]
Hi Kalle,
Here's a batch of patches intended for v5.3. This includes the last
patchset 2 patchsets I sent intender for v5.3 and the one I sent with
fixes for v5.2, because we failed to put them in time for your last
pull-request (as we discussed on IRC). Usual development work and 6
important fixes. More details about the contents in the tag
description.
I pushed this to my tree, but I didn't get any results from kbuildbot
for quite a while, as we discussed. I'll let you know if I get any
results in the next couple of days.
Please let me know if there are any issues.
Cheers,
Luca.
The following changes since commit b741422218efeb76389a307b72ed3afe41671cf7:
rtw88: refine flow to get tx power index (2019-06-27 20:24:29 +0300)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2019-06-29
for you to fetch changes up to 940225628652b340b2bfe99f42f3d2db9fd9ce6c:
iwlwifi: mvm: clear rfkill_safe_init_done when we start the firmware (2019-06-29 10:14:45 +0300)
----------------------------------------------------------------
Patches intended for v5.3
* Work on the new debugging framework continues;
* Update the FW API for CSI;
* Special SAR implementation for South Korea;
* Fixes in the module init error paths;
* Debugging infra work continues;
* A bunch of RF-kill fixes by Emmanuel;
* A fix for AP mode, also related to RF-kill, by Johannes.
* A few clean-ups;
* Other small fixes and improvements;
----------------------------------------------------------------
Andrei Otcheretianski (1):
iwlwifi: mvm: Drop large non sta frames
Dan Carpenter (1):
iwlwifi: remove some unnecessary NULL checks
Emmanuel Grumbach (7):
iwlwifi: support FSEQ TLV even when FMAC is not compiled
iwlwifi: mvm: make the usage of TWT configurable
iwlwifi: pcie: fix ALIVE interrupt handling for gen2 devices w/o MSI-X
iwlwifi: fix RF-Kill interrupt while FW load for gen2 devices
iwlwifi: pcie: don't service an interrupt that was masked
iwlwifi: don't WARN when calling iwl_get_shared_mem_conf with RF-Kill
iwlwifi: mvm: clear rfkill_safe_init_done when we start the firmware
Gustavo A. R. Silva (2):
iwlwifi: lib: Use struct_size() helper
iwlwifi: d3: Use struct_size() helper
Haim Dreyfuss (2):
iwlwifi: Add support for SAR South Korea limitation
iwlwifi: mvm: Add log information about SAR status
Jiri Kosina (1):
iwlwifi: iwl_mvm_tx_mpdu() must be called with BH disabled
Johannes Berg (3):
iwlwifi: update CSI API
iwlwifi: fix module init error paths
iwlwifi: mvm: delay GTK setting in FW in AP mode
Luca Coelho (2):
iwlwifi: pcie: increase the size of PCI dumps
iwlwifi: mvm: remove MAC_FILTER_IN_11AX for AP mode
Mordechay Goodstein (2):
iwlwifi: mvm: add a debugfs entry to set a fixed size AMSDU for all TX packets
iwlwifi: mvm: remove multiple debugfs entries
Naftali Goldstein (1):
iwlwifi: mvm: correctly fill the ac array in the iwl_mac_ctx_cmd
Shahar S Matityahu (15):
iwlwifi: dbg: allow dump collection in case of an early error
iwlwifi: dbg_ini: dump headers cleanup
iwlwifi: dbg_ini: abort region collection in case the size is 0
iwlwifi: dbg_ini: add consecutive trigger firing support
iwlwifi: dbg_ini: use different barker for ini dump
iwlwifi: dbg_ini: support debug info TLV
iwlwifi: dbg_ini: implement dump info collection
iwlwifi: fw api: support adwell HB default APs number api
iwlwifi: dbg: fix debug monitor stop and restart delays
iwlwifi: dbg_ini: enforce apply point early on buffer allocation tlv
iwlwifi: dbg_ini: remove redundant checking of ini mode
iwlwifi: dbg: move trans debug fields to a separate struct
iwlwifi: dbg_ini: fix debug monitor stop and restart in ini mode
iwlwifi: dbg: don't stop dbg recording before entering D3 from 9000 devices
iwlwifi: dbg: debug recording stop and restart command remove
Shaul Triebitz (1):
iwlwifi: mvm: convert to FW AC when configuring MU EDCA
drivers/net/wireless/intel/iwlwifi/dvm/lib.c | 3 +-
drivers/net/wireless/intel/iwlwifi/fw/acpi.c | 28 ++++---
drivers/net/wireless/intel/iwlwifi/fw/acpi.h | 5 +-
drivers/net/wireless/intel/iwlwifi/fw/api/dbg-tlv.h | 22 +++++
drivers/net/wireless/intel/iwlwifi/fw/api/location.h | 11 ++-
drivers/net/wireless/intel/iwlwifi/fw/api/power.h | 12 +++
drivers/net/wireless/intel/iwlwifi/fw/api/scan.h | 15 ++++
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 427 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------
drivers/net/wireless/intel/iwlwifi/fw/dbg.h | 133 ++++++++++++++++++-----------
drivers/net/wireless/intel/iwlwifi/fw/error-dump.h | 111 ++++++++++++++++++------
drivers/net/wireless/intel/iwlwifi/fw/file.h | 17 ++--
drivers/net/wireless/intel/iwlwifi/fw/init.c | 7 +-
drivers/net/wireless/intel/iwlwifi/fw/runtime.h | 28 +++++--
drivers/net/wireless/intel/iwlwifi/fw/smem.c | 12 ++-
drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c | 33 ++++----
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 35 ++++++--
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 75 ++++++++++-------
drivers/net/wireless/intel/iwlwifi/mvm/constants.h | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 14 ++--
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 66 ++++++++++-----
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 72 +++++++++++-----
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 16 ++--
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 66 +++++++++++++--
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 12 ++-
drivers/net/wireless/intel/iwlwifi/mvm/nvm.c | 9 ++
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 26 +++---
drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c | 25 +++---
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 12 ++-
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 4 +
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 16 ++--
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 20 ++++-
drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c | 10 +--
drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info.c | 2 +-
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 29 ++++++-
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 68 +++++++++------
drivers/net/wireless/intel/iwlwifi/pcie/trans-gen2.c | 11 ++-
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 187 ++++++++++++++++++++++-------------------
37 files changed, 1110 insertions(+), 530 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH AUTOSEL 4.19 14/60] mwifiex: Abort at too short BSS descriptor element
From: Brian Norris @ 2019-06-28 22:58 UTC (permalink / raw)
To: Sasha Levin
Cc: Linux Kernel, stable, Takashi Iwai, Kalle Valo, linux-wireless,
<netdev@vger.kernel.org>
In-Reply-To: <20190627003616.20767-14-sashal@kernel.org>
On Wed, Jun 26, 2019 at 5:49 PM Sasha Levin <sashal@kernel.org> wrote:
>
> From: Takashi Iwai <tiwai@suse.de>
>
> [ Upstream commit 685c9b7750bfacd6fc1db50d86579980593b7869 ]
>
> Currently mwifiex_update_bss_desc_with_ie() implicitly assumes that
> the source descriptor entries contain the enough size for each type
> and performs copying without checking the source size. This may lead
> to read over boundary.
>
> Fix this by putting the source size check in appropriate places.
>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
For the record, this fixup is still aiming for 5.2, correcting some
potential mistakes in this patch:
63d7ef36103d mwifiex: Don't abort on small, spec-compliant vendor IEs
So you might want to hold off a bit, and grab them both.
Brian
^ permalink raw reply
* Re: [RFC V2 7/8] cfg80211: ibss: use 11a mandatory rates for 6GHz band operation
From: Igor Mitsyanko @ 2019-06-28 21:36 UTC (permalink / raw)
To: Johannes Berg, Arend van Spriel; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <0e261a8a1200a7e55e94d8260ef8cfbaf03b2bd7.camel@sipsolutions.net>
On 6/28/19 6:04 AM, Johannes Berg wrote:
>> The default mandatory rates, ie. when not specified by user-space, is
>> determined by the band. Select 11a rateset for 6GHz band.
> Hmm. Again, didn't you just say that 6 GHz didn't allow legacy rates,
> and so these shouldn't be mandatory?
>
> johannes
>
I believe 6GHz allows only HE and non-HT rates (for beacons etc).
^ permalink raw reply
* Re: [PATCH 1/2] ath10k: remove unnecessary 'out of memory' message
From: Kalle Valo @ 2019-06-28 19:14 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <1561661250-30528-1-git-send-email-kvalo@codeaurora.org>
Kalle Valo <kvalo@codeaurora.org> wrote:
> Fixes checkpatch warning:
>
> drivers/net/wireless/ath/ath10k/swap.c:110: Possible unnecessary 'out of memory' message
>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2 patches applied to ath-next branch of ath.git, thanks.
2189135437d0 ath10k: remove unnecessary 'out of memory' message
d44c732cffe5 ath10k: pci: remove unnecessary casts
--
https://patchwork.kernel.org/patch/11020277/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: destroy sdio workqueue while remove sdio module
From: Kalle Valo @ 2019-06-28 19:13 UTC (permalink / raw)
To: Wen Gong; +Cc: ath10k, linux-wireless
In-Reply-To: <1561515940-13748-1-git-send-email-wgong@codeaurora.org>
Wen Gong <wgong@codeaurora.org> wrote:
> The workqueue need to flush and destory while remove sdio module,
> otherwise it will have thread which is not destory after remove
> sdio modules.
>
> Tested with QCA6174 SDIO with firmware
> WLAN.RMH.4.4.1-00007-QCARMSWP-1.
>
> Signed-off-by: Wen Gong <wgong@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
3ed39f8e747a ath10k: destroy sdio workqueue while remove sdio module
--
https://patchwork.kernel.org/patch/11016767/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: Move non-fatal warn logs to dbg level for SDIO chip
From: Kalle Valo @ 2019-06-28 19:12 UTC (permalink / raw)
To: Wen Gong; +Cc: ath10k, linux-wireless
In-Reply-To: <1561516175-13873-1-git-send-email-wgong@codeaurora.org>
Wen Gong <wgong@codeaurora.org> wrote:
> ath10k will receive some message with invalid peer id from firmware.
> reason is:
> There are incoming frames to MAC hardware that NOT find relative
> address search table, then peer id is invalid set by MAC hardware,
> it is hardware's logic, so fix it in ath10k will be more convenient.
>
> log:
> ath10k_sdio mmc1:0001:1: Got RX ind from invalid peer: 65535
>
> Tested with QCA6174 SDIO with firmware
> WLAN.RMH.4.4.1-00007-QCARMSWP-1.
>
> Signed-off-by: Wen Gong <wgong@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
bd1a4ac556df ath10k: Move non-fatal warn logs to dbg level for SDIO chip
--
https://patchwork.kernel.org/patch/11016771/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: Fix memory leak in qmi
From: Kalle Valo @ 2019-06-28 19:11 UTC (permalink / raw)
To: Dundi Raviteja; +Cc: ath10k, linux-wireless, Dundi Raviteja
In-Reply-To: <1561472748-28467-1-git-send-email-dundi@codeaurora.org>
Dundi Raviteja <dundi@codeaurora.org> wrote:
> Currently the memory allocated for qmi handle is
> not being freed during de-init which leads to memory leak.
>
> Free the allocated qmi memory in qmi deinit
> to avoid memory leak.
>
> Tested HW: WCN3990
> Tested FW: WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1
>
> Fixes: fda6fee0001e ("ath10k: add QMI message handshake for wcn3990 client")
> Signed-off-by: Dundi Raviteja <dundi@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
c709df58832c ath10k: Fix memory leak in qmi
--
https://patchwork.kernel.org/patch/11015647/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: pull-request: mac80211 2019-06-28
From: David Miller @ 2019-06-28 16:50 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20190628144444.25092-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 28 Jun 2019 16:44:43 +0200
> Just a single patch still for the current RC cycle, I debated
> whether to send a pull request at all or just ask you to apply
> the patch, but did it this way now.
>
> Please pull and let me know if there's any problem.
Either way works for me :)
Pulled, thanks.
^ permalink raw reply
* Re: pull-request: wireless-drivers 2019-06-28
From: David Miller @ 2019-06-28 16:15 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87woh6fa93.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Fri, 28 Jun 2019 10:18:48 +0300
> here's a pull request to net tree for 5.2, more info below. Please let
> me know if there are any problems.
Pulled, thanks Kalle.
^ permalink raw reply
* Re: [Linux-kernel-mentees][PATCH v2] nl80211: Fix undefined behavior in bit shift
From: Shuah Khan @ 2019-06-28 15:27 UTC (permalink / raw)
To: Johannes Berg, Jiunn Chang
Cc: linux-kernel-mentees, linux-wireless, linux-kernel, Shuah Khan
In-Reply-To: <b5a247aa3bb21094c0a6ef1d8e3281d701bb6200.camel@sipsolutions.net>
On 6/28/19 9:17 AM, Johannes Berg wrote:
> Hi Shuah,
>
>> I went looking in the git log. Looks like there are several commits with
>> "Changes since" included in the commit log. It still appears to be
>> maintainer preference. Probably from networking and networking related
>> areas - wireless being one of them. This trend is recent it appears in
>> any case.
>
> Yeah. I was really just observing that I'd seen this, and some people (I
> guess 'many' was an exaggeration) actively request it to be in the
> commit log. I "grew up" with "changelog after ---" too ;-)
>
>> There is a value to seeing changes as the work evolves. However, there
>> is the concern that how log should it be.
>
> That doesn't parse, what did you mean?
Say we are on version 16 of a patch series, when does the commit log
become too long to be useful?
>
>> This example commit has history from RFC stage and no doubt very useful
>> since this is a new driver.
>>
>> 8ef988b914bd449458eb2174febb67b0f137b33c
>>
This commit has a very long commit log starting from RFC stage. It is
very informative.
>> If we make this more of a norm, we do want to make sure, we evolve
>> from informal nature of these "Changes since", to "Commit log" text.
>
> Not sure it's really worth it, but I guess some recommendations could be
> useful. If it is indeed to become the norm, and there aren't some people
> who strongly feel it should *not* be included.
>
Yeah. If it becomes a norm, we probably will have to set some limits how
long, and reads like part of the commit log as opposed to something
slapped on at the end.
thanks,
-- Shuah
^ permalink raw reply
* Re: [Linux-kernel-mentees][PATCH v2] nl80211: Fix undefined behavior in bit shift
From: Johannes Berg @ 2019-06-28 15:17 UTC (permalink / raw)
To: Shuah Khan, Jiunn Chang
Cc: linux-kernel-mentees, linux-wireless, linux-kernel
In-Reply-To: <9e17c585-bd42-8c65-a37a-add6aa4d5ca4@linuxfoundation.org>
Hi Shuah,
> I went looking in the git log. Looks like there are several commits with
> "Changes since" included in the commit log. It still appears to be
> maintainer preference. Probably from networking and networking related
> areas - wireless being one of them. This trend is recent it appears in
> any case.
Yeah. I was really just observing that I'd seen this, and some people (I
guess 'many' was an exaggeration) actively request it to be in the
commit log. I "grew up" with "changelog after ---" too ;-)
> There is a value to seeing changes as the work evolves. However, there
> is the concern that how log should it be.
That doesn't parse, what did you mean?
> This example commit has history from RFC stage and no doubt very useful
> since this is a new driver.
>
> 8ef988b914bd449458eb2174febb67b0f137b33c
>
> If we make this more of a norm, we do want to make sure, we evolve
> from informal nature of these "Changes since", to "Commit log" text.
Not sure it's really worth it, but I guess some recommendations could be
useful. If it is indeed to become the norm, and there aren't some people
who strongly feel it should *not* be included.
johannes
^ permalink raw reply
* Re: [Linux-kernel-mentees][PATCH v2] nl80211: Fix undefined behavior in bit shift
From: Shuah Khan @ 2019-06-28 15:04 UTC (permalink / raw)
To: Johannes Berg, Jiunn Chang
Cc: linux-kernel-mentees, linux-wireless, linux-kernel, Shuah Khan
In-Reply-To: <8b8c44c3ecb8626d9bb5a8f786b1d2b7488df86b.camel@sipsolutions.net>
On 6/28/19 7:57 AM, Johannes Berg wrote:
> On Wed, 2019-06-26 at 21:34 -0600, Shuah Khan wrote:
>> On 6/26/19 9:25 PM, Jiunn Chang wrote:
>>> Shifting signed 32-bit value by 31 bits is undefined. Changing most
>>> significant bit to unsigned.
>>>
>>> Changes included in v2:
>>> - use subsystem specific subject lines
>>> - CC required mailing lists
>>>
>>> Signed-off-by: Jiunn Chang <c0d1n61at3@gmail.com>
>>> ---
>>
>> Move version change lines here. They don't belong in the commit log.
>
> FWIW, in many cases people (maintainers) now *do* want them in the
> commit log. Here, they're just editorial, so agree, but if real
> technical changes were made due to reviews, they can indeed be useful.
>
> johannes
>
I went looking in the git log. Looks like there are several commits with
"Changes since" included in the commit log. It still appears to be
maintainer preference. Probably from networking and networking related
areas - wireless being one of them. This trend is recent it appears in
any case.
There is a value to seeing changes as the work evolves. However, there
is the concern that how log should it be.
This example commit has history from RFC stage and no doubt very useful
since this is a new driver.
8ef988b914bd449458eb2174febb67b0f137b33c
If we make this more of a norm, we do want to make sure, we evolve
from informal nature of these "Changes since", to "Commit log" text.
thanks,
-- Shuah
^ permalink raw reply
* pull-request: mac80211 2019-06-28
From: Johannes Berg @ 2019-06-28 14:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Just a single patch still for the current RC cycle, I debated
whether to send a pull request at all or just ask you to apply
the patch, but did it this way now.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 556e2f6020bf90f63c5dd65e9a2254be6db3185b:
Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux (2019-06-28 08:50:09 +0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2019-06-28
for you to fetch changes up to d2ce8d6bfcfed014fd281e06c9b1d4638ddf3f1e:
nl80211: Fix undefined behavior in bit shift (2019-06-28 16:07:54 +0200)
----------------------------------------------------------------
Just a single patch:
* 1<<31 is undefined, use 1U<<31 in nl80211.h UAPI
----------------------------------------------------------------
Jiunn Chang (1):
nl80211: Fix undefined behavior in bit shift
include/uapi/linux/nl80211.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* Re: [RFC PATCH] cfg80211: fix duplicated scan entries after channel switch
From: Johannes Berg @ 2019-06-28 14:39 UTC (permalink / raw)
To: Sergey Matyukevich, linux-wireless@vger.kernel.org
Cc: Igor Mitsyanko, Mikhail Karpenko
In-Reply-To: <20190613112128.834-1-sergey.matyukevich.os@quantenna.com>
On Thu, 2019-06-13 at 11:21 +0000, Sergey Matyukevich wrote:
> When associated BSS completes channel switch procedure, its channel record
> needs to be updated. The existing mac80211 solution was extended to
> cfg80211 in commit 5dc8cdce1d72 ("mac80211/cfg80211: update bss
> channel on channel switch")
>
> However this solution appears to be incomplete as it may lead to
> duplicated scan entries for associated BSS after channel switch.
> The root cause of the problem is as follows. Each BSS entry is
> included into the following data structures:
> - bss list rdev->bss_list
> - bss search tree rdev->bss_tree
> Updating BSS channel record without rebuilding bss_tree may break
> tree search since cmp_bss considers all of the following: channel,
> bssid, ssid. When BSS channel is updated, but its location in bss_tree
> is not updated, then subsequent search operations may fail to locate
> this BSS since they will be traversing bss_tree in wrong direction.
> As a result, for scan performed after associated BSS channel switch,
> cfg80211_bss_update may add the second entry for the same BSS to both
> bss_list and bss_tree, rather then update the existing one.
>
> To summarize, if BSS channel needs to be updated, then bss_tree should
> be rebuilt in order to put updated BSS entry into a proper location.
Good catch!
> This commit suggests the following straightforward solution:
> - if new entry has been already created for BSS after channel switch,
> then remove it completely
Shouldn't we prefer the new entry?
OTOH, the old entry will likely have a "hold", so it doesn't get removed
while we're connected ... and the driver etc. might be referencing it.
So I guess the old entry should be updated with info from the newer one?
> Finally, next scan operation will find BSS entry in expected location
> in rb_tree. So all the IEs, including HT/VHT operation IEs,
> will be properly updated.
Right. Although if it was there before, then it already has been updated
in a sense... But I guess it's a corner case to even get there?
> 1. Tested using iwlwifi and qtnfmac drivers, looks good
Great.
> 2. Alternative approach: remove old BSS entry and keep new a one
> This approach may have certain benefits for mac80211 drivers.
> For instance, in this case HT/VHT operation IEs are going to be
> valid from the start, no need to wait for the next scan.
> However the following procedure for replacing current_bss, protected
> by wdev->mtx and rdev->bss_lock locks, seems to be insufficient:
>
> bss_ref_get(rdev, new);
> cfg80211_hold_bss(new);
> wdev->current_bss = new;
>
> cfg80211_unhold_bss(old);
> bss_ref_put(rdev, old);
> __cfg80211_unlink_bss(rdev, old);
>
> When testing this alternative approach using iwlwifi driver,
> occasional general protection fault crashes have been observed
> on ieee80211_rx_mgmt_beacon/ieee80211_bss_info_update code paths.
> So far I haven't yet root caused them.
At the very least you'd also have to update ifmgd->associated in
mac80211, and that's basically not really possible? Well, I guess we
could change the channel switch API to return the new one or something.
I guess the better thing would be to go update the old entry with the
new one's data, before killing the new one.
Not sure it's worth the extra complexity though.
johannes
^ permalink raw reply
* Re: [PATCH v3] {nl,mac}80211: allow 4addr AP operation on crypto controlled devices
From: Johannes Berg @ 2019-06-28 14:02 UTC (permalink / raw)
To: Tom Psyborg, Stefan Lippers-Hollmann; +Cc: Manikanta Pubbisetty, linux-wireless
In-Reply-To: <CAKR_QVJ9EkhcG893SjVMgDb5S-W2=jas5JG+VQyLDx-R5MMK5w@mail.gmail.com>
Hi Tom,
> Checked out r10011 from openwrt git on May, 15; built images and
> flashed devices; tried to set up WDS (AP) + WDS (Client); got this in
> logs: https://forum.openwrt.org/t/ath10k-wds-support-missing/30346/15?u=psyborg
I'm not sure ... this is saying -ENOENT??
> Saw this patch in my inbox and checked openwrt sources, to find out
> there was v1 used:
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/kernel/mac80211/patches/subsys/390-nl-mac-80211-allow-4addr-AP-operation-on-crypto-cont.patch
>
> Reverted v1 of the patch and patched manually to v3 (double checked),
> did not help.
>
> Found patch that fixes problem and applied;
> https://github.com/openwrt/openwrt/pull/2048
I don't see how that's related.
> Now I got this in logs:
> https://forum.openwrt.org/t/wds-client-wont-stay-connected-prev-auth-not-valid-using-recent-snapshot-builds/38194/20?u=psyborg
Again, I don't see how that's related. This is telling you something
about keys etc.
All this stuff about openwrt etc. is very confusing.
Can you at least collect some tracing (trace-cmd) to show what's going
on?
johannes
^ permalink raw reply
* Re: [PATCH] Add SPDX identifiers
From: Johannes Berg @ 2019-06-28 13:58 UTC (permalink / raw)
To: Yegor Yefremov; +Cc: linux-wireless
In-Reply-To: <CAGm1_kvK3eWnZk7eDOoqoAiedReJLunKfb4tvhqXU-hriO3itg@mail.gmail.com>
On Mon, 2019-06-24 at 22:32 +0200, Yegor Yefremov wrote:
>
> I have asked SPDX and this is their answer:
> https://lists.spdx.org/g/Spdx-legal/message/2631
Alright, thanks. I guess I can apply that then.
johannes
^ permalink raw reply
* Re: [Linux-kernel-mentees][PATCH v2] nl80211: Fix undefined behavior in bit shift
From: Johannes Berg @ 2019-06-28 13:57 UTC (permalink / raw)
To: Shuah Khan, Jiunn Chang
Cc: linux-kernel-mentees, linux-wireless, linux-kernel
In-Reply-To: <c20a0a94-ab50-bb85-7c78-e02a465c5a40@linuxfoundation.org>
On Wed, 2019-06-26 at 21:34 -0600, Shuah Khan wrote:
> On 6/26/19 9:25 PM, Jiunn Chang wrote:
> > Shifting signed 32-bit value by 31 bits is undefined. Changing most
> > significant bit to unsigned.
> >
> > Changes included in v2:
> > - use subsystem specific subject lines
> > - CC required mailing lists
> >
> > Signed-off-by: Jiunn Chang <c0d1n61at3@gmail.com>
> > ---
>
> Move version change lines here. They don't belong in the commit log.
FWIW, in many cases people (maintainers) now *do* want them in the
commit log. Here, they're just editorial, so agree, but if real
technical changes were made due to reviews, they can indeed be useful.
johannes
^ permalink raw reply
* Re: [PATCH v3 1/2] nl80211: Add support for EDMG channels
From: Johannes Berg @ 2019-06-28 13:21 UTC (permalink / raw)
To: Alexei Avshalom Lazar; +Cc: linux-wireless, wil6210
In-Reply-To: <1561458567-31866-2-git-send-email-ailizaro@codeaurora.org>
On Tue, 2019-06-25 at 13:29 +0300, Alexei Avshalom Lazar wrote:
>
> /**
> + * struct ieee80211_sta_edmg_cap - EDMG capabilities
> + *
> + * This structure describes most essential parameters needed
> + * to describe 802.11ay EDMG capabilities
> + *
> + * @channels: bitmap that indicates the 2.16 GHz channel(s)
> + * that are allowed to be used for transmissions.
> + * Bit 0 indicates channel 1, bit 1 indicates channel 2, etc.
> + * Set to 0 indicate EDMG not supported.
> + * @bw_config: Channel BW Configuration subfield encodes
> + * the allowed channel bandwidth configurations
> + */
> +struct ieee80211_sta_edmg_cap {
> + u8 channels;
> + u8 bw_config;
> +};
[...]
> + * @edmg: define the EDMG channels configuration.
> + * If edmg is set, chan will define the primary channel and all other
> + * parameters are ignored.
>
> struct cfg80211_chan_def {
Thinking out loud, maybe this should say "If edmg is requested (i.e. the
.channels member is non-zero) [...]" or so?
> @@ -1192,6 +1218,7 @@ enum rate_info_bw {
> * @he_dcm: HE DCM value
> * @he_ru_alloc: HE RU allocation (from &enum nl80211_he_ru_alloc,
> * only valid if bw is %RATE_INFO_BW_HE_RU)
> + * @n_bonded_ch: In case of EDMG the number of bonded channels (1-4)
So, just for the stupid me because I didn't really read the spec.
You have N channels (can only be 8 since you use a u8, looking at the
code further it looks like there are only 7) and edmg_cap::channels
indicates which are supported/requested, and then edmg_cap::bw_config
indicates how the channels are used?
I'm not sure I understand this part, because if you, say, request
channels 1 and 2 (channels=0x3) then what configurations could be
possible below that?
Oh, something about the primary channel maybe?
I guess I would've expected something like a list of bitmaps that the
device supports, and then at runtime you select only one bitmap.
If I have channels 1 and 2 enabled, how do the configurations differ?
Clearly they don't differ enough to make capturing them in the rate
worthwhile, here n_bonded_ch would presumably only be 2, and that's
enough to tell the rate. What then does the configuration mean?
It seems to me that you should, however, expose n_bonded_ch to
userspace? We do expose all the details about the bitrate normally, see
nl80211_put_sta_rate(). We do calculate the bitrate to expose that too,
but do expose all the details too.
Hmm. Looking at that, it looks like DMG doesn't actually do that. So
perhaps not, though it seems to me that it ought to be possible?
> @@ -2436,6 +2467,7 @@ struct cfg80211_connect_params {
> const u8 *fils_erp_rrk;
> size_t fils_erp_rrk_len;
> bool want_1x;
> + struct ieee80211_sta_edmg_cap edmg;
Maybe we really should rename this struct type? It's not a "capability"
here.
> +static bool cfg80211_edmg_chandef_valid(const struct cfg80211_chan_def *chandef)
> +{
> + int max_continuous = 0;
> + int num_of_enabled = 0;
> + int contiguous = 0;
max_continuous vs. contiguous is even more confusing now :-)
> + max_continuous = max(contiguous, max_continuous);
See? :)
> + /* basic verification of edmg configuration according to
> + * IEEE802.11 section 9.4.2.251
All the IEEE 802.11 references (more than just this one) ... please
qualify them with a version. I'm thinking these are not in -2016, so
probably 802.11ay (perhaps even draft?)
> + */
> + /* check bw_config against contiguous edmg channels */
> + switch (chandef->edmg.bw_config) {
> + case 4:
> + case 8:
> + case 12:
> + if (max_continuous < 1)
> + return false;
> + break;
I guess I really should try to find a copy of the appropriate spec ...
johannes
^ permalink raw reply
* Re: [PATCH v3 1/2] nl80211: Add support for EDMG channels
From: Johannes Berg @ 2019-06-28 13:07 UTC (permalink / raw)
To: Alexei Lazar; +Cc: linux-wireless, wil6210
In-Reply-To: <40d70ed94b1d79d481511031e8f4ea45@codeaurora.org>
On Tue, 2019-06-25 at 13:21 +0300, Alexei Lazar wrote:
>
> > > * @NL80211_BAND_ATTR_VHT_CAPA: VHT capabilities, as in the HT
> > > information IE
> > > * @NL80211_BAND_ATTR_IFTYPE_DATA: nested array attribute, with each
> > > entry using
> > > * attributes from &enum nl80211_band_iftype_attr
> > > + * @NL80211_BAND_ATTR_EDMG_CHANNELS: bitmap that indicates the 2.16
> > > GHz
> > > + * channel(s) that are allowed to be used for EDMG transmissions in
> > > the
> > > + * BSS as defined by IEEE 802.11 section 9.4.2.251.
> > > + * @NL80211_BAND_ATTR_EDMG_BW_CONFIG: Channel BW Configuration
> > > subfield
> > > + * encodes the allowed channel bandwidth configurations as defined by
> > > + * IEEE 802.11 section 9.4.2.251, Table 13.
> > > * @NL80211_BAND_ATTR_MAX: highest band attribute currently defined
> > > * @__NL80211_BAND_ATTR_AFTER_LAST: internal use
> >
> > And ... that makes more sense than the global attribute I guess?
>
> We feel it belongs to the BAND attributes because for example also VHT
> capability is there. There are however 2 other options:
> 1. Move the attribute to the NL80211_FREQUENCY_ATTR
> 2. Move them to the global attributes
> Any preference?
I think I just got confused. Is this used for capability reporting then?
I guess that'd make sense here, yeah.
johannes
^ 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