* [PATCH 2/2] mwifiex: Make use of the new sdio_trigger_replug() API to reset
From: Douglas Anderson @ 2019-07-16 16:42 UTC (permalink / raw)
To: Ulf Hansson, Kalle Valo, Adrian Hunter
Cc: Ganapathi Bhat, linux-wireless, Brian Norris, Amitkumar Karwar,
linux-rockchip, Wolfram Sang, Nishant Sarmukadam, netdev,
Avri Altman, linux-mmc, davem, Xinming Hu, Douglas Anderson,
linux-kernel
In-Reply-To: <20190716164209.62320-1-dianders@chromium.org>
As described in the patch ("mmc: core: Add sdio_trigger_replug()
API"), the current mwifiex_sdio_card_reset() is broken in the cases
where we're running Bluetooth on a second SDIO func on the same card
as WiFi. The problem goes away if we just use the
sdio_trigger_replug() API call.
NOTE: Even though with this new solution there is less of a reason to
do our work from a workqueue (the unplug / plug mechanism we're using
is possible for a human to perform at any time so the stack is
supposed to handle it without it needing to be called from a special
context), we still need a workqueue because the Marvell reset function
could called from a context where sleeping is invalid and thus we
can't claim the host. One example is Marvell's wakeup_timer_fn().
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 14 +++-----------
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 24c041dad9f6..f77ad2615f08 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -2218,14 +2218,6 @@ static void mwifiex_sdio_card_reset_work(struct mwifiex_adapter *adapter)
{
struct sdio_mmc_card *card = adapter->card;
struct sdio_func *func = card->func;
- int ret;
-
- mwifiex_shutdown_sw(adapter);
-
- /* power cycle the adapter */
- sdio_claim_host(func);
- mmc_hw_reset(func->card->host);
- sdio_release_host(func);
/* Previous save_adapter won't be valid after this. We will cancel
* pending work requests.
@@ -2233,9 +2225,9 @@ static void mwifiex_sdio_card_reset_work(struct mwifiex_adapter *adapter)
clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, &card->work_flags);
clear_bit(MWIFIEX_IFACE_WORK_CARD_RESET, &card->work_flags);
- ret = mwifiex_reinit_sw(adapter);
- if (ret)
- dev_err(&func->dev, "reinit failed: %d\n", ret);
+ sdio_claim_host(func);
+ sdio_trigger_replug(func);
+ sdio_release_host(func);
}
/* This function read/write firmware */
--
2.22.0.510.g264f2c817a-goog
^ permalink raw reply related
* [PATCH v2] libertas_tf: Use correct channel range in lbtf_geo_init
From: YueHaibing @ 2019-07-16 14:42 UTC (permalink / raw)
To: kvalo, davem, lkundrak, derosier
Cc: linux-kernel, netdev, linux-wireless, YueHaibing
It seems we should use 'range' instead of 'priv->range'
in lbtf_geo_init(), because 'range' is the corret one
related to current regioncode.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 691cdb49388b ("libertas_tf: command helper functions for libertas_tf")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
v2: fix compile error
---
drivers/net/wireless/marvell/libertas_tf/cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/libertas_tf/cmd.c b/drivers/net/wireless/marvell/libertas_tf/cmd.c
index 1eacca0..a333172 100644
--- a/drivers/net/wireless/marvell/libertas_tf/cmd.c
+++ b/drivers/net/wireless/marvell/libertas_tf/cmd.c
@@ -65,7 +65,7 @@ static void lbtf_geo_init(struct lbtf_private *priv)
break;
}
- for (ch = priv->range.start; ch < priv->range.end; ch++)
+ for (ch = range->start; ch < range->end; ch++)
priv->channels[CHAN_TO_IDX(ch)].flags = 0;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] libertas_tf: Use correct channel range in lbtf_geo_init
From: Yuehaibing @ 2019-07-16 13:38 UTC (permalink / raw)
To: kvalo, davem, lkundrak, derosier; +Cc: linux-kernel, netdev, linux-wireless
In-Reply-To: <20190716132534.11256-1-yuehaibing@huawei.com>
Pls ignore this, sorry
On 2019/7/16 21:25, YueHaibing wrote:
> It seems we should use 'range' instead of 'priv->range'
> in lbtf_geo_init(), because 'range' is the corret one
> related to current regioncode.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Fixes: 691cdb49388b ("libertas_tf: command helper functions for libertas_tf")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/wireless/marvell/libertas_tf/cmd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/marvell/libertas_tf/cmd.c b/drivers/net/wireless/marvell/libertas_tf/cmd.c
> index 1eacca0..a333172 100644
> --- a/drivers/net/wireless/marvell/libertas_tf/cmd.c
> +++ b/drivers/net/wireless/marvell/libertas_tf/cmd.c
> @@ -65,7 +65,7 @@ static void lbtf_geo_init(struct lbtf_private *priv)
> break;
> }
>
> - for (ch = priv->range.start; ch < priv->range.end; ch++)
> + for (ch = range.start; ch < range.end; ch++)
> priv->channels[CHAN_TO_IDX(ch)].flags = 0;
> }
>
>
^ permalink raw reply
* [PATCH] libertas_tf: Use correct channel range in lbtf_geo_init
From: YueHaibing @ 2019-07-16 13:25 UTC (permalink / raw)
To: kvalo, davem, lkundrak, derosier
Cc: linux-kernel, netdev, linux-wireless, YueHaibing
It seems we should use 'range' instead of 'priv->range'
in lbtf_geo_init(), because 'range' is the corret one
related to current regioncode.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 691cdb49388b ("libertas_tf: command helper functions for libertas_tf")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/marvell/libertas_tf/cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/libertas_tf/cmd.c b/drivers/net/wireless/marvell/libertas_tf/cmd.c
index 1eacca0..a333172 100644
--- a/drivers/net/wireless/marvell/libertas_tf/cmd.c
+++ b/drivers/net/wireless/marvell/libertas_tf/cmd.c
@@ -65,7 +65,7 @@ static void lbtf_geo_init(struct lbtf_private *priv)
break;
}
- for (ch = priv->range.start; ch < priv->range.end; ch++)
+ for (ch = range.start; ch < range.end; ch++)
priv->channels[CHAN_TO_IDX(ch)].flags = 0;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 20/24] wireless: Remove call to memset after dma_alloc_coherent
From: Kalle Valo @ 2019-07-16 12:44 UTC (permalink / raw)
To: Fuqian Huang; +Cc: linux-wireless
In-Reply-To: <CABXRUiR0XAB8x9MkF=UH1KTojWDovEy9hGaUEuZnAhbfCAcD3w@mail.gmail.com>
(adding back linux-wireless, please don't drop CC)
> Kalle Valo <kvalo@codeaurora.org> 於 2019年7月15日週一 下午5:07寫道：
>>
>> Fuqian Huang <huangfq.daxian@gmail.com> writes:
>>
>> > In commit 518a2f1925c3
>> > ("dma-mapping: zero memory returned from dma_alloc_*"),
>> > dma_alloc_coherent has already zeroed the memory.
>> > So memset is not needed.
>> >
>> > Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
>> > ---
>> > Changes in v3:
>> > - Use actual commit rather than the merge commit in the commit message
>> >
>> > drivers/net/wireless/ath/ath10k/ce.c | 5 -----
>> > drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 2 --
>> > drivers/net/wireless/quantenna/qtnfmac/pcie/pearl_pcie.c | 2 --
>> > drivers/net/wireless/quantenna/qtnfmac/pcie/topaz_pcie.c | 2 --
>> > 4 files changed, 11 deletions(-)
>>
>> Via which tree is this supposed to go? Can I take this to
>> wireless-drivers-next?
>
> I think the wireless-drivers-next is fine.
Good, I'll then take these to my queue.
> The four file have similar changes. And they are both under wireless
> subsystem. How should i indicate which tree the patch should go to?
> Should I mark them in [patch v3 wireless] or after the Changes in v3?
> I should avoid this mistake next time.
As there's no dependency between patches to me the easiest is that you
send the wireless patches separately, that way I can take them directly
without asking anything, and not worry about dependencies or if someone
else is going to apply them. For example Colin King does that his
cleanup patches and I like it a lot.
But if I see patch 20/24 (and only that, no cover letter or over
patches) I have no clue what the plan is and need extra effort to
understand what I should do.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] mt76: mt76x0u: add support to TP-Link T2UHP
From: Kalle Valo @ 2019-07-16 11:11 UTC (permalink / raw)
To: Sid Hayn
Cc: Lorenzo Bianconi, Felix Fietkau, Lorenzo Bianconi, linux-wireless,
Stanislaw Gruszka
In-Reply-To: <CAM0KTbBU7-BTTR_R9b7VNQuqRpd=rMk8nAQANQ7shns+XGahdw@mail.gmail.com>
Sid Hayn <sidhayn@gmail.com> writes:
> I saw you accept this patch, thanks. Any chance of pushing this
> simple fix in 5.1.x and 5.2.x? I've tested and confirmed this
> hardware works fine.
Actually you can ask that yourself:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
Especially check option 2.
--
Kalle Valo
^ permalink raw reply
* RE: [PATCH 09/11] rtw88: remove all RTW_MAX_POWER_INDEX macro
From: Tony Chuang @ 2019-07-16 8:15 UTC (permalink / raw)
To: Brian Norris; +Cc: Kalle Valo, linux-wireless
In-Reply-To: <CA+ASDXMWYhORB7=bCh84BO1wuPdAa7dpTSyTWuUYzanfTYA=Pw@mail.gmail.com>
> Subject: Re: [PATCH 09/11] rtw88: remove all RTW_MAX_POWER_INDEX
> macro
>
> I realize this is already upstream, but I thought I'd ask here, since
> I was going back and reviewing some of this:
>
> On Wed, May 29, 2019 at 12:55 AM <yhchuang@realtek.com> wrote:
> >
> > From: Tzu-En Huang <tehuang@realtek.com>
> >
> > Since this macro definition has different values in different chipset,
> > the current defined macro value is for 8822b. This will cause the
> > settings of 8822c be incorrect.
>
> ^^ Is this actually correct, that 8822b was correct and 8822c was
> wrong? Because I see RTW_MAX_POWER_INDEX used to be defined as 0x7f,
> and rtw8822c_hw_spec.max_power_index also appears to be 0x7f. Which
> would sound like 8822b (*b*, not c) was wrong, as it lists 0x3f.
>
> Anyway, I'm going to assume you got the change right, and you just
> mis-spoke in the description.
Yes, I think he just mis-spoke it, and the code is right.
Thanks
Yan-Hsuan
^ permalink raw reply
* [PATCH v2] rtw88: debug: dump tx power indexes in use
From: yhchuang @ 2019-07-16 5:28 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, briannorris
From: Zong-Zhe Yang <kevin_yang@realtek.com>
Add a read entry in debugfs to dump current tx power
indexes in use for each path and each rate section.
The corresponding power bases, power by rate, and
power limit are also included.
Also this patch fixes unused function warning.
Fixes: b741422218ef ("rtw88: refine flow to get tx power index")
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
---
v1 -> v2
refine seq_printf format from such as
"%5s%-5s", "CCK_", cck_rate[idx]
to
" CCK_%-5s", cck_rate[idx]
drivers/net/wireless/realtek/rtw88/debug.c | 112 +++++++++++++++++++++++++++++
1 file changed, 112 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw88/debug.c b/drivers/net/wireless/realtek/rtw88/debug.c
index f0ae260..383b04c 100644
--- a/drivers/net/wireless/realtek/rtw88/debug.c
+++ b/drivers/net/wireless/realtek/rtw88/debug.c
@@ -8,6 +8,7 @@
#include "sec.h"
#include "fw.h"
#include "debug.h"
+#include "phy.h"
#ifdef CONFIG_RTW88_DEBUGFS
@@ -460,6 +461,112 @@ static int rtw_debug_get_rf_dump(struct seq_file *m, void *v)
return 0;
}
+static void rtw_print_cck_rate_txt(struct seq_file *m, u8 rate)
+{
+ static const char * const
+ cck_rate[] = {"1M", "2M", "5.5M", "11M"};
+ u8 idx = rate - DESC_RATE1M;
+
+ seq_printf(m, " CCK_%-5s", cck_rate[idx]);
+}
+
+static void rtw_print_ofdm_rate_txt(struct seq_file *m, u8 rate)
+{
+ static const char * const
+ ofdm_rate[] = {"6M", "9M", "12M", "18M", "24M", "36M", "48M", "54M"};
+ u8 idx = rate - DESC_RATE6M;
+
+ seq_printf(m, " OFDM_%-4s", ofdm_rate[idx]);
+}
+
+static void rtw_print_ht_rate_txt(struct seq_file *m, u8 rate)
+{
+ u8 mcs_n = rate - DESC_RATEMCS0;
+
+ seq_printf(m, " MCS%-6u", mcs_n);
+}
+
+static void rtw_print_vht_rate_txt(struct seq_file *m, u8 rate)
+{
+ u8 idx = rate - DESC_RATEVHT1SS_MCS0;
+ u8 n_ss, mcs_n;
+
+ /* n spatial stream */
+ n_ss = 1 + idx / 10;
+ /* MCS n */
+ mcs_n = idx % 10;
+ seq_printf(m, " VHT%uSMCS%u", n_ss, mcs_n);
+}
+
+static int rtw_debugfs_get_tx_pwr_tbl(struct seq_file *m, void *v)
+{
+ struct rtw_debugfs_priv *debugfs_priv = m->private;
+ struct rtw_dev *rtwdev = debugfs_priv->rtwdev;
+ struct rtw_hal *hal = &rtwdev->hal;
+ void (*print_rate)(struct seq_file *, u8) = NULL;
+ u8 path, rate;
+ struct rtw_power_params pwr_param = {0};
+ u8 bw = hal->current_band_width;
+ u8 ch = hal->current_channel;
+ u8 regd = rtwdev->regd.txpwr_regd;
+
+ seq_printf(m, "%-4s %-10s %-3s%6s %-4s %4s (%-4s %-4s)\n",
+ "path", "rate", "pwr", "", "base", "", "byr", "lmt");
+
+ mutex_lock(&hal->tx_power_mutex);
+ for (path = RF_PATH_A; path <= RF_PATH_B; path++) {
+ /* there is no CCK rates used in 5G */
+ if (hal->current_band_type == RTW_BAND_5G)
+ rate = DESC_RATE6M;
+ else
+ rate = DESC_RATE1M;
+
+ /* now, not support vht 3ss and vht 4ss*/
+ for (; rate <= DESC_RATEVHT2SS_MCS9; rate++) {
+ /* now, not support ht 3ss and ht 4ss*/
+ if (rate > DESC_RATEMCS15 &&
+ rate < DESC_RATEVHT1SS_MCS0)
+ continue;
+
+ switch (rate) {
+ case DESC_RATE1M...DESC_RATE11M:
+ print_rate = rtw_print_cck_rate_txt;
+ break;
+ case DESC_RATE6M...DESC_RATE54M:
+ print_rate = rtw_print_ofdm_rate_txt;
+ break;
+ case DESC_RATEMCS0...DESC_RATEMCS15:
+ print_rate = rtw_print_ht_rate_txt;
+ break;
+ case DESC_RATEVHT1SS_MCS0...DESC_RATEVHT2SS_MCS9:
+ print_rate = rtw_print_vht_rate_txt;
+ break;
+ default:
+ print_rate = NULL;
+ break;
+ }
+
+ rtw_get_tx_power_params(rtwdev, path, rate, bw,
+ ch, regd, &pwr_param);
+
+ seq_printf(m, "%4c ", path + 'A');
+ if (print_rate)
+ print_rate(m, rate);
+ seq_printf(m, " %3u(0x%02x) %4u %4d (%4d %4d)\n",
+ hal->tx_pwr_tbl[path][rate],
+ hal->tx_pwr_tbl[path][rate],
+ pwr_param.pwr_base,
+ min_t(s8, pwr_param.pwr_offset,
+ pwr_param.pwr_limit),
+ pwr_param.pwr_offset, pwr_param.pwr_limit);
+ }
+ }
+
+ mutex_unlock(&hal->tx_power_mutex);
+
+ return 0;
+}
+
#define rtw_debug_impl_mac(page, addr) \
static struct rtw_debugfs_priv rtw_debug_priv_mac_ ##page = { \
.cb_read = rtw_debug_get_mac_page, \
@@ -514,6 +621,10 @@ static struct rtw_debugfs_priv rtw_debug_priv_rf_dump = {
.cb_read = rtw_debug_get_rf_dump,
};
+static struct rtw_debugfs_priv rtw_debug_priv_tx_pwr_tbl = {
+ .cb_read = rtw_debugfs_get_tx_pwr_tbl,
+};
+
static struct rtw_debugfs_priv rtw_debug_priv_write_reg = {
.cb_write = rtw_debugfs_set_write_reg,
};
@@ -610,6 +721,7 @@ void rtw_debugfs_init(struct rtw_dev *rtwdev)
rtw_debugfs_add_r(bb_41);
}
rtw_debugfs_add_r(rf_dump);
+ rtw_debugfs_add_r(tx_pwr_tbl);
}
#endif /* CONFIG_RTW88_DEBUGFS */
--
2.7.4
^ permalink raw reply related
* [PATCH v2] mac80211: add IEEE80211_KEY_FLAG_GENERATE_MMIE to ieee80211_key_flags
From: Lorenzo Bianconi @ 2019-07-15 22:09 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, nbd
Add IEEE80211_KEY_FLAG_GENERATE_MMIE flag to ieee80211_key_flags in order
to allow the driver to notify mac80211 to generate MMIE and that it
requires sequence number generation only.
This is a preliminary patch to add BIP_CMAC_128 hw support to mt7615
driver
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
Changes since v1:
- rename IEEE80211_KEY_FLAG_PUT_MMIE_SPACE in IEEE80211_KEY_FLAG_GENERATE_MMIE
---
include/net/mac80211.h | 4 ++++
net/mac80211/wpa.c | 6 +++++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index d26da013f7c0..a655de2c65dd 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1702,6 +1702,9 @@ struct wireless_dev *ieee80211_vif_to_wdev(struct ieee80211_vif *vif);
* a TKIP key if it only requires MIC space. Do not set together with
* @IEEE80211_KEY_FLAG_GENERATE_MMIC on the same key.
* @IEEE80211_KEY_FLAG_NO_AUTO_TX: Key needs explicit Tx activation.
+ * @IEEE80211_KEY_FLAG_GENERATE_MMIE: This flag should be set by the driver
+ * for a AES_CMAC key to indicate that it requires sequence number
+ * generation only
*/
enum ieee80211_key_flags {
IEEE80211_KEY_FLAG_GENERATE_IV_MGMT = BIT(0),
@@ -1714,6 +1717,7 @@ enum ieee80211_key_flags {
IEEE80211_KEY_FLAG_RESERVE_TAILROOM = BIT(7),
IEEE80211_KEY_FLAG_PUT_MIC_SPACE = BIT(8),
IEEE80211_KEY_FLAG_NO_AUTO_TX = BIT(9),
+ IEEE80211_KEY_FLAG_GENERATE_MMIE = BIT(10),
};
/**
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index a51c7909366e..f5845af9a449 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -946,7 +946,8 @@ ieee80211_crypto_aes_cmac_encrypt(struct ieee80211_tx_data *tx)
info = IEEE80211_SKB_CB(skb);
- if (info->control.hw_key)
+ if (info->control.hw_key &&
+ !(key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_MMIE))
return TX_CONTINUE;
if (WARN_ON(skb_tailroom(skb) < sizeof(*mmie)))
@@ -962,6 +963,9 @@ ieee80211_crypto_aes_cmac_encrypt(struct ieee80211_tx_data *tx)
bip_ipn_set64(mmie->sequence_number, pn64);
+ if (info->control.hw_key)
+ return TX_CONTINUE;
+
bip_aad(skb, aad);
/*
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2 1/2] rt2x00usb: fix rx queue hang
From: Kalle Valo @ 2019-07-15 17:53 UTC (permalink / raw)
To: Soeren Moch
Cc: Stanislaw Gruszka, Soeren Moch, stable, Helmut Schaa,
David S. Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <20190701105314.9707-1-smoch@web.de>
Soeren Moch <smoch@web.de> wrote:
> Since commit ed194d136769 ("usb: core: remove local_irq_save() around
> ->complete() handler") the handler rt2x00usb_interrupt_rxdone() is
> not running with interrupts disabled anymore. So this completion handler
> is not guaranteed to run completely before workqueue processing starts
> for the same queue entry.
> Be sure to set all other flags in the entry correctly before marking
> this entry ready for workqueue processing. This way we cannot miss error
> conditions that need to be signalled from the completion handler to the
> worker thread.
> Note that rt2x00usb_work_rxdone() processes all available entries, not
> only such for which queue_work() was called.
>
> This patch is similar to what commit df71c9cfceea ("rt2x00: fix order
> of entry flags modification") did for TX processing.
>
> This fixes a regression on a RT5370 based wifi stick in AP mode, which
> suddenly stopped data transmission after some period of heavy load. Also
> stopping the hanging hostapd resulted in the error message "ieee80211
> phy0: rt2x00queue_flush_queue: Warning - Queue 14 failed to flush".
> Other operation modes are probably affected as well, this just was
> the used testcase.
>
> Fixes: ed194d136769 ("usb: core: remove local_irq_save() around ->complete() handler")
> Cc: stable@vger.kernel.org # 4.20+
> Signed-off-by: Soeren Moch <smoch@web.de>
> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers.git, thanks.
41a531ffa4c5 rt2x00usb: fix rx queue hang
--
https://patchwork.kernel.org/patch/11025561/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: work around uninitialized vht_pfr variable
From: Kalle Valo @ 2019-07-15 17:50 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Miaoqing Pan, David S. Miller, Rakesh Pillai,
Brian Norris, Balaji Pothunoori, Wen Gong, Pradeep kumar Chitrapu,
Sriram R, ath10k, linux-wireless, netdev, linux-kernel,
clang-built-linux
In-Reply-To: <20190708125050.3689133-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> As clang points out, the vht_pfr is assigned to a struct member
> without being initialized in one case:
>
> drivers/net/wireless/ath/ath10k/mac.c:7528:7: error: variable 'vht_pfr' is used uninitialized whenever 'if' condition
> is false [-Werror,-Wsometimes-uninitialized]
> if (!ath10k_mac_can_set_bitrate_mask(ar, band, mask,
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net/wireless/ath/ath10k/mac.c:7551:20: note: uninitialized use occurs here
> arvif->vht_pfr = vht_pfr;
> ^~~~~~~
> drivers/net/wireless/ath/ath10k/mac.c:7528:3: note: remove the 'if' if its condition is always true
> if (!ath10k_mac_can_set_bitrate_mask(ar, band, mask,
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net/wireless/ath/ath10k/mac.c:7483:12: note: initialize the variable 'vht_pfr' to silence this warning
> u8 vht_pfr;
>
> Add an explicit but probably incorrect initialization here.
> I suspect we want a better fix here, but chose this approach to
> illustrate the issue.
>
> Fixes: 8b97b055dc9d ("ath10k: fix failure to set multiple fixed rate")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Patch applied to wireless-drivers.git, thanks.
ff414f31ce37 ath10k: work around uninitialized vht_pfr variable
--
https://patchwork.kernel.org/patch/11034993/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/2] iwlwifi: add new cards for 9000 and 20000 series
From: Kalle Valo @ 2019-07-15 17:48 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Ihab Zhaika, stable, Luca Coelho
In-Reply-To: <20190708155534.18241-2-luca@coelho.fi>
Luca Coelho <luca@coelho.fi> wrote:
> From: Ihab Zhaika <ihab.zhaika@intel.com>
>
> add two new PCI ID's for 9000 and 20000 series
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Ihab Zhaika <ihab.zhaika@intel.com>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2 patches applied to wireless-drivers.git, thanks.
ffcb60a54f24 iwlwifi: add new cards for 9000 and 20000 series
a7d544d63120 iwlwifi: pcie: add support for qu c-step devices
--
https://patchwork.kernel.org/patch/11035359/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rtw88: make functions static
From: Brian Norris @ 2019-07-15 17:11 UTC (permalink / raw)
To: Tony Chuang; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <F7CD281DE3E379468C6D07993EA72F84D1867CEE@RTITMBSVM04.realtek.com.tw>
On Sun, Jul 14, 2019 at 7:24 PM Tony Chuang <yhchuang@realtek.com> wrote:
> I am sorry I have to NACK it.
>
> Nothing wrong about this patch. Because in the last patch set I sent has
> 11 patches, but one of them is not applied by Kalle.
> And I am going to resend it, which will use rtw_get_tx_power_params
> in debug.c
I suppose that's fine with me. I've marked it as Rejected in Patchwork.
(Normally, I would say: it's your fault for leaving these things
unused. But it was in the middle of the series, where you were aiming
to start using it by the end.)
It would still be nice to see the promised v2:
https://patchwork.kernel.org/patch/10966403/
Regards,
Brian
^ permalink raw reply
* Re: [PATCH] mt76: mt76x0u: add support to TP-Link T2UHP
From: Sid Hayn @ 2019-07-15 15:38 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Felix Fietkau, Lorenzo Bianconi, linux-wireless,
Stanislaw Gruszka
In-Reply-To: <dfb97adb52811bed530449c22a172724ed992771.1562353065.git.lorenzo@kernel.org>
Felix,
I saw you accept this patch, thanks. Any chance of pushing this
simple fix in 5.1.x and 5.2.x? I've tested and confirmed this
hardware works fine.
Thanks,
Zero
On Fri, Jul 5, 2019 at 3:01 PM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
>
> Introduce support to TP-Link T2UHP
> https://wikidevi.com/wiki/TP-LINK_Archer_T2UHP
>
> Tested-by: Sid Hayn <sidhayn@gmail.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/wireless/mediatek/mt76/mt76x0/usb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
> index 627ed1fc7b15..b007bcd2e999 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
> @@ -32,6 +32,7 @@ static struct usb_device_id mt76x0_device_table[] = {
> { USB_DEVICE(0x20f4, 0x806b) }, /* TRENDnet TEW-806UBH */
> { USB_DEVICE(0x7392, 0xc711) }, /* Devolo Wifi ac Stick */
> { USB_DEVICE(0x0df6, 0x0079) }, /* Sitecom Europe B.V. ac Stick */
> + { USB_DEVICE(0x2357, 0x0123) }, /* TP-LINK T2UHP */
> { USB_DEVICE(0x2357, 0x0105),
> .driver_info = 1, }, /* TP-LINK Archer T1U */
> { USB_DEVICE_AND_INTERFACE_INFO(0x0E8D, 0x7630, 0xff, 0x2, 0xff)}, /* MT7630U */
> --
> 2.21.0
>
^ permalink raw reply
* [PATCH AUTOSEL 5.2 002/249] ath10k: htt: don't use txdone_fifo with SDIO
From: Sasha Levin @ 2019-07-15 13:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alagu Sankar, Wen Gong, Kalle Valo, Sasha Levin, ath10k,
linux-wireless, netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Alagu Sankar <alagusankar@silex-india.com>
[ Upstream commit e2a6b711282a371c5153239e0468a48254f17ca6 ]
HTT High Latency (ATH10K_DEV_TYPE_HL) does not use txdone_fifo at all, we don't
even initialise it by skipping ath10k_htt_tx_alloc_buf() in
ath10k_htt_tx_start(). Because of this using QCA6174 SDIO
ath10k_htt_rx_tx_compl_ind() will crash when it accesses unitialised
txdone_fifo. So skip txdone_fifo when using High Latency mode.
Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1.
Co-developed-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Alagu Sankar <alagusankar@silex-india.com>
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 1acc622d2183..f22840bbc389 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2277,7 +2277,9 @@ static void ath10k_htt_rx_tx_compl_ind(struct ath10k *ar,
* Note that with only one concurrent reader and one concurrent
* writer, you don't need extra locking to use these macro.
*/
- if (!kfifo_put(&htt->txdone_fifo, tx_done)) {
+ if (ar->bus_param.dev_type == ATH10K_DEV_TYPE_HL) {
+ ath10k_txrx_tx_unref(htt, &tx_done);
+ } else if (!kfifo_put(&htt->txdone_fifo, tx_done)) {
ath10k_warn(ar, "txdone fifo overrun, msdu_id %d status %d\n",
tx_done.msdu_id, tx_done.status);
ath10k_txrx_tx_unref(htt, &tx_done);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 003/249] ath10k: fix incorrect multicast/broadcast rate setting
From: Sasha Levin @ 2019-07-15 13:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Pradeep kumar Chitrapu, Zhi Chen, Sven Eckelmann, Kalle Valo,
Sasha Levin, ath10k, linux-wireless, netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Pradeep kumar Chitrapu <pradeepc@codeaurora.org>
[ Upstream commit 93ee3d108fc77e19efeac3ec5aa7d5886711bfef ]
Invalid rate code is sent to firmware when multicast rate value of 0 is
sent to driver indicating disabled case, causing broken mesh path.
so fix that.
Tested on QCA9984 with firmware 10.4-3.6.1-00827
Sven tested on IPQ4019 with 10.4-3.5.3-00057 and QCA9888 with 10.4-3.5.3-00053
(ath10k-firmware) and 10.4-3.6-00140 (linux-firmware 2018-12-16-211de167).
Fixes: cd93b83ad92 ("ath10k: support for multicast rate control")
Co-developed-by: Zhi Chen <zhichen@codeaurora.org>
Signed-off-by: Zhi Chen <zhichen@codeaurora.org>
Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
Tested-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath10k/mac.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 9c703d287333..e8997e22ceec 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5588,8 +5588,8 @@ static void ath10k_bss_info_changed(struct ieee80211_hw *hw,
struct cfg80211_chan_def def;
u32 vdev_param, pdev_param, slottime, preamble;
u16 bitrate, hw_value;
- u8 rate, basic_rate_idx;
- int rateidx, ret = 0, hw_rate_code;
+ u8 rate, basic_rate_idx, rateidx;
+ int ret = 0, hw_rate_code, mcast_rate;
enum nl80211_band band;
const struct ieee80211_supported_band *sband;
@@ -5776,7 +5776,11 @@ static void ath10k_bss_info_changed(struct ieee80211_hw *hw,
if (changed & BSS_CHANGED_MCAST_RATE &&
!ath10k_mac_vif_chan(arvif->vif, &def)) {
band = def.chan->band;
- rateidx = vif->bss_conf.mcast_rate[band] - 1;
+ mcast_rate = vif->bss_conf.mcast_rate[band];
+ if (mcast_rate > 0)
+ rateidx = mcast_rate - 1;
+ else
+ rateidx = ffs(vif->bss_conf.basic_rates) - 1;
if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY)
rateidx += ATH10K_MAC_FIRST_OFDM_RATE_IDX;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 004/249] ath9k: Don't trust TX status TID number when reporting airtime
From: Sasha Levin @ 2019-07-15 13:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Toke Høiland-Jørgensen, Miguel Catalan Cid, Kalle Valo,
Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Toke Høiland-Jørgensen <toke@redhat.com>
[ Upstream commit 389b72e58259336c2d56d58b660b79cf4b9e0dcb ]
As already noted a comment in ath_tx_complete_aggr(), the hardware will
occasionally send a TX status with the wrong tid number. If we trust the
value, airtime usage will be reported to the wrong AC, which can cause the
deficit on that AC to become very low, blocking subsequent attempts to
transmit.
To fix this, account airtime usage to the TID number from the original skb,
instead of the one in the hardware TX status report.
Reported-by: Miguel Catalan Cid <miguel.catalan@i2cat.net>
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath9k/xmit.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index b17e1ca40995..3be0aeedb9b5 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -668,7 +668,8 @@ static bool bf_is_ampdu_not_probing(struct ath_buf *bf)
static void ath_tx_count_airtime(struct ath_softc *sc,
struct ieee80211_sta *sta,
struct ath_buf *bf,
- struct ath_tx_status *ts)
+ struct ath_tx_status *ts,
+ u8 tid)
{
u32 airtime = 0;
int i;
@@ -679,7 +680,7 @@ static void ath_tx_count_airtime(struct ath_softc *sc,
airtime += rate_dur * bf->rates[i].count;
}
- ieee80211_sta_register_airtime(sta, ts->tid, airtime, 0);
+ ieee80211_sta_register_airtime(sta, tid, airtime, 0);
}
static void ath_tx_process_buffer(struct ath_softc *sc, struct ath_txq *txq,
@@ -709,7 +710,7 @@ static void ath_tx_process_buffer(struct ath_softc *sc, struct ath_txq *txq,
if (sta) {
struct ath_node *an = (struct ath_node *)sta->drv_priv;
tid = ath_get_skb_tid(sc, an, bf->bf_mpdu);
- ath_tx_count_airtime(sc, sta, bf, ts);
+ ath_tx_count_airtime(sc, sta, bf, ts, tid->tidno);
if (ts->ts_status & (ATH9K_TXERR_FILT | ATH9K_TXERR_XRETRY))
tid->clear_ps_filter = true;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 005/249] wil6210: fix potential out-of-bounds read
From: Sasha Levin @ 2019-07-15 13:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Gustavo A. R. Silva, Maya Erez, Kalle Valo, Sasha Levin,
linux-wireless, wil6210, netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
[ Upstream commit bfabdd6997323adbedccb13a3fed1967fb8cf8f5 ]
Notice that *rc* can evaluate to up to 5, include/linux/netdevice.h:
enum gro_result {
GRO_MERGED,
GRO_MERGED_FREE,
GRO_HELD,
GRO_NORMAL,
GRO_DROP,
GRO_CONSUMED,
};
typedef enum gro_result gro_result_t;
In case *rc* evaluates to 5, we end up having an out-of-bounds read
at drivers/net/wireless/ath/wil6210/txrx.c:821:
wil_dbg_txrx(wil, "Rx complete %d bytes => %s\n",
len, gro_res_str[rc]);
Fix this by adding element "GRO_CONSUMED" to array gro_res_str.
Addresses-Coverity-ID: 1444666 ("Out-of-bounds read")
Fixes: 194b482b5055 ("wil6210: Debug print GRO Rx result")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/wil6210/txrx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ath/wil6210/txrx.c b/drivers/net/wireless/ath/wil6210/txrx.c
index 4ccfd1404458..d74837cce67f 100644
--- a/drivers/net/wireless/ath/wil6210/txrx.c
+++ b/drivers/net/wireless/ath/wil6210/txrx.c
@@ -750,6 +750,7 @@ void wil_netif_rx_any(struct sk_buff *skb, struct net_device *ndev)
[GRO_HELD] = "GRO_HELD",
[GRO_NORMAL] = "GRO_NORMAL",
[GRO_DROP] = "GRO_DROP",
+ [GRO_CONSUMED] = "GRO_CONSUMED",
};
wil->txrx_ops.get_netif_rx_params(skb, &cid, &security);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 006/249] ath10k: Do not send probe response template for mesh
From: Sasha Levin @ 2019-07-15 13:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Surabhi Vishnoi, Kalle Valo, Sasha Levin, ath10k, linux-wireless,
netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Surabhi Vishnoi <svishnoi@codeaurora.org>
[ Upstream commit 97354f2c432788e3163134df6bb144f4b6289d87 ]
Currently mac80211 do not support probe response template for
mesh point. When WMI_SERVICE_BEACON_OFFLOAD is enabled, host
driver tries to configure probe response template for mesh, but
it fails because the interface type is not NL80211_IFTYPE_AP but
NL80211_IFTYPE_MESH_POINT.
To avoid this failure, skip sending probe response template to
firmware for mesh point.
Tested HW: WCN3990/QCA6174/QCA9984
Signed-off-by: Surabhi Vishnoi <svishnoi@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath10k/mac.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index e8997e22ceec..b500fd427595 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1630,6 +1630,10 @@ static int ath10k_mac_setup_prb_tmpl(struct ath10k_vif *arvif)
if (arvif->vdev_type != WMI_VDEV_TYPE_AP)
return 0;
+ /* For mesh, probe response and beacon share the same template */
+ if (ieee80211_vif_is_mesh(vif))
+ return 0;
+
prb = ieee80211_proberesp_get(hw, vif);
if (!prb) {
ath10k_warn(ar, "failed to get probe resp template from mac80211\n");
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 008/249] ath9k: Check for errors when reading SREV register
From: Sasha Levin @ 2019-07-15 13:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Tim Schumacher, Kalle Valo, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Tim Schumacher <timschumi@gmx.de>
[ Upstream commit 2f90c7e5d09437a4d8d5546feaae9f1cf48cfbe1 ]
Right now, if an error is encountered during the SREV register
read (i.e. an EIO in ath9k_regread()), that error code gets
passed all the way to __ath9k_hw_init(), where it is visible
during the "Chip rev not supported" message.
ath9k_htc 1-1.4:1.0: ath9k_htc: HTC initialized with 33 credits
ath: phy2: Mac Chip Rev 0x0f.3 is not supported by this driver
ath: phy2: Unable to initialize hardware; initialization status: -95
ath: phy2: Unable to initialize hardware; initialization status: -95
ath9k_htc: Failed to initialize the device
Check for -EIO explicitly in ath9k_hw_read_revisions() and return
a boolean based on the success of the operation. Check for that in
__ath9k_hw_init() and abort with a more debugging-friendly message
if reading the revisions wasn't successful.
ath9k_htc 1-1.4:1.0: ath9k_htc: HTC initialized with 33 credits
ath: phy2: Failed to read SREV register
ath: phy2: Could not read hardware revision
ath: phy2: Unable to initialize hardware; initialization status: -95
ath: phy2: Unable to initialize hardware; initialization status: -95
ath9k_htc: Failed to initialize the device
This helps when debugging by directly showing the first point of
failure and it could prevent possible errors if a 0x0f.3 revision
is ever supported.
Signed-off-by: Tim Schumacher <timschumi@gmx.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath9k/hw.c | 32 +++++++++++++++++++++--------
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 8581d917635a..b6773d613f0c 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -252,8 +252,9 @@ void ath9k_hw_get_channel_centers(struct ath_hw *ah,
/* Chip Revisions */
/******************/
-static void ath9k_hw_read_revisions(struct ath_hw *ah)
+static bool ath9k_hw_read_revisions(struct ath_hw *ah)
{
+ u32 srev;
u32 val;
if (ah->get_mac_revision)
@@ -269,25 +270,33 @@ static void ath9k_hw_read_revisions(struct ath_hw *ah)
val = REG_READ(ah, AR_SREV);
ah->hw_version.macRev = MS(val, AR_SREV_REVISION2);
}
- return;
+ return true;
case AR9300_DEVID_AR9340:
ah->hw_version.macVersion = AR_SREV_VERSION_9340;
- return;
+ return true;
case AR9300_DEVID_QCA955X:
ah->hw_version.macVersion = AR_SREV_VERSION_9550;
- return;
+ return true;
case AR9300_DEVID_AR953X:
ah->hw_version.macVersion = AR_SREV_VERSION_9531;
- return;
+ return true;
case AR9300_DEVID_QCA956X:
ah->hw_version.macVersion = AR_SREV_VERSION_9561;
- return;
+ return true;
}
- val = REG_READ(ah, AR_SREV) & AR_SREV_ID;
+ srev = REG_READ(ah, AR_SREV);
+
+ if (srev == -EIO) {
+ ath_err(ath9k_hw_common(ah),
+ "Failed to read SREV register");
+ return false;
+ }
+
+ val = srev & AR_SREV_ID;
if (val == 0xFF) {
- val = REG_READ(ah, AR_SREV);
+ val = srev;
ah->hw_version.macVersion =
(val & AR_SREV_VERSION2) >> AR_SREV_TYPE2_S;
ah->hw_version.macRev = MS(val, AR_SREV_REVISION2);
@@ -306,6 +315,8 @@ static void ath9k_hw_read_revisions(struct ath_hw *ah)
if (ah->hw_version.macVersion == AR_SREV_VERSION_5416_PCIE)
ah->is_pciexpress = true;
}
+
+ return true;
}
/************************************/
@@ -559,7 +570,10 @@ static int __ath9k_hw_init(struct ath_hw *ah)
struct ath_common *common = ath9k_hw_common(ah);
int r = 0;
- ath9k_hw_read_revisions(ah);
+ if (!ath9k_hw_read_revisions(ah)) {
+ ath_err(common, "Could not read hardware revisions");
+ return -EOPNOTSUPP;
+ }
switch (ah->hw_version.macVersion) {
case AR_SREV_VERSION_5416_PCI:
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 009/249] ath10k: Fix the wrong value of enums for wmi tlv stats id
From: Sasha Levin @ 2019-07-15 13:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Surabhi Vishnoi, Kalle Valo, Sasha Levin, ath10k, linux-wireless,
netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Surabhi Vishnoi <svishnoi@codeaurora.org>
[ Upstream commit 9280f4fc06f44d0b4dc9e831f72d97b3d7cd35d3 ]
The enum value for WMI_TLV_STAT_PDEV, WMI_TLV_STAT_VDEV
and WMI_TLV_STAT_PEER is wrong, due to which the vdev stats
are not received from firmware in wmi_update_stats event.
Fix the enum values for above stats to receive all stats
from firmware in WMI_TLV_UPDATE_STATS_EVENTID.
Tested HW: WCN3990
Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
Fixes: f40a307eb92c ("ath10k: Fill rx duration for each peer in fw_stats for WCN3990)
Signed-off-by: Surabhi Vishnoi <svishnoi@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath10k/wmi.h | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index e1c40bb69932..12f57f9adbba 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4535,9 +4535,10 @@ enum wmi_10_4_stats_id {
};
enum wmi_tlv_stats_id {
- WMI_TLV_STAT_PDEV = BIT(0),
- WMI_TLV_STAT_VDEV = BIT(1),
- WMI_TLV_STAT_PEER = BIT(2),
+ WMI_TLV_STAT_PEER = BIT(0),
+ WMI_TLV_STAT_AP = BIT(1),
+ WMI_TLV_STAT_PDEV = BIT(2),
+ WMI_TLV_STAT_VDEV = BIT(3),
WMI_TLV_STAT_PEER_EXTD = BIT(10),
};
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 011/249] ath6kl: add some bounds checking
From: Sasha Levin @ 2019-07-15 13:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dan Carpenter, Kalle Valo, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit 5d6751eaff672ea77642e74e92e6c0ac7f9709ab ]
The "ev->traffic_class" and "reply->ac" variables come from the network
and they're used as an offset into the wmi->stream_exist_for_ac[] array.
Those variables are u8 so they can be 0-255 but the stream_exist_for_ac[]
array only has WMM_NUM_AC (4) elements. We need to add a couple bounds
checks to prevent array overflows.
I also modified one existing check from "if (traffic_class > 3) {" to
"if (traffic_class >= WMM_NUM_AC) {" just to make them all consistent.
Fixes: bdcd81707973 (" Add ath6kl cleaned up driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath6kl/wmi.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath6kl/wmi.c b/drivers/net/wireless/ath/ath6kl/wmi.c
index 68854c45d0a4..9ab6aa9ded5c 100644
--- a/drivers/net/wireless/ath/ath6kl/wmi.c
+++ b/drivers/net/wireless/ath/ath6kl/wmi.c
@@ -1176,6 +1176,10 @@ static int ath6kl_wmi_pstream_timeout_event_rx(struct wmi *wmi, u8 *datap,
return -EINVAL;
ev = (struct wmi_pstream_timeout_event *) datap;
+ if (ev->traffic_class >= WMM_NUM_AC) {
+ ath6kl_err("invalid traffic class: %d\n", ev->traffic_class);
+ return -EINVAL;
+ }
/*
* When the pstream (fat pipe == AC) timesout, it means there were
@@ -1517,6 +1521,10 @@ static int ath6kl_wmi_cac_event_rx(struct wmi *wmi, u8 *datap, int len,
return -EINVAL;
reply = (struct wmi_cac_event *) datap;
+ if (reply->ac >= WMM_NUM_AC) {
+ ath6kl_err("invalid AC: %d\n", reply->ac);
+ return -EINVAL;
+ }
if ((reply->cac_indication == CAC_INDICATION_ADMISSION_RESP) &&
(reply->status_code != IEEE80211_TSPEC_STATUS_ADMISS_ACCEPTED)) {
@@ -2633,7 +2641,7 @@ int ath6kl_wmi_delete_pstream_cmd(struct wmi *wmi, u8 if_idx, u8 traffic_class,
u16 active_tsids = 0;
int ret;
- if (traffic_class > 3) {
+ if (traffic_class >= WMM_NUM_AC) {
ath6kl_err("invalid traffic class: %d\n", traffic_class);
return -EINVAL;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 015/249] ath: DFS JP domain W56 fixed pulse type 3 RADAR detection
From: Sasha Levin @ 2019-07-15 13:43 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Anilkumar Kolli, Tamizh chelvam, Kalle Valo, Sasha Levin,
linux-wireless, netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Anilkumar Kolli <akolli@codeaurora.org>
[ Upstream commit d8792393a783158cbb2c39939cb897dc5e5299b6 ]
Increase pulse width range from 1-2usec to 0-4usec.
During data traffic HW occasionally fails detecting radar pulses,
so that SW cannot get enough radar reports to achieve the success rate.
Tested ath10k hw and fw:
* QCA9888(10.4-3.5.1-00052)
* QCA4019(10.4-3.2.1.1-00017)
* QCA9984(10.4-3.6-00104)
* QCA988X(10.2.4-1.0-00041)
Tested ath9k hw: AR9300
Tested-by: Tamizh chelvam <tamizhr@codeaurora.org>
Signed-off-by: Tamizh chelvam <tamizhr@codeaurora.org>
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/dfs_pattern_detector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.c b/drivers/net/wireless/ath/dfs_pattern_detector.c
index d52b31b45df7..a274eb0d1968 100644
--- a/drivers/net/wireless/ath/dfs_pattern_detector.c
+++ b/drivers/net/wireless/ath/dfs_pattern_detector.c
@@ -111,7 +111,7 @@ static const struct radar_detector_specs jp_radar_ref_types[] = {
JP_PATTERN(0, 0, 1, 1428, 1428, 1, 18, 29, false),
JP_PATTERN(1, 2, 3, 3846, 3846, 1, 18, 29, false),
JP_PATTERN(2, 0, 1, 1388, 1388, 1, 18, 50, false),
- JP_PATTERN(3, 1, 2, 4000, 4000, 1, 18, 50, false),
+ JP_PATTERN(3, 0, 4, 4000, 4000, 1, 18, 50, false),
JP_PATTERN(4, 0, 5, 150, 230, 1, 23, 50, false),
JP_PATTERN(5, 6, 10, 200, 500, 1, 16, 50, false),
JP_PATTERN(6, 11, 20, 200, 500, 1, 12, 50, false),
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 014/249] wil6210: fix spurious interrupts in 3-msi
From: Sasha Levin @ 2019-07-15 13:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Maya Erez, Kalle Valo, Sasha Levin, linux-wireless, wil6210,
netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Maya Erez <merez@codeaurora.org>
[ Upstream commit e10b0eddd5235aa5aef4e40b970e34e735611a80 ]
Interrupt is set in ICM (ICR & ~IMV) rising trigger.
As the driver masks the IRQ after clearing it, there can
be a race where an additional spurious interrupt is triggered
when the driver unmask the IRQ.
This can happen in case HW triggers an interrupt after the clear
and before the mask.
To prevent the second spurious interrupt the driver needs to mask the
IRQ before reading and clearing it.
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/wil6210/interrupt.c | 65 ++++++++++++--------
1 file changed, 40 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/interrupt.c b/drivers/net/wireless/ath/wil6210/interrupt.c
index e41ba24011d8..b00a13d6d530 100644
--- a/drivers/net/wireless/ath/wil6210/interrupt.c
+++ b/drivers/net/wireless/ath/wil6210/interrupt.c
@@ -296,21 +296,24 @@ void wil_configure_interrupt_moderation(struct wil6210_priv *wil)
static irqreturn_t wil6210_irq_rx(int irq, void *cookie)
{
struct wil6210_priv *wil = cookie;
- u32 isr = wil_ioread32_and_clear(wil->csr +
- HOSTADDR(RGF_DMA_EP_RX_ICR) +
- offsetof(struct RGF_ICR, ICR));
+ u32 isr;
bool need_unmask = true;
+ wil6210_mask_irq_rx(wil);
+
+ isr = wil_ioread32_and_clear(wil->csr +
+ HOSTADDR(RGF_DMA_EP_RX_ICR) +
+ offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_rx(isr);
wil_dbg_irq(wil, "ISR RX 0x%08x\n", isr);
if (unlikely(!isr)) {
wil_err_ratelimited(wil, "spurious IRQ: RX\n");
+ wil6210_unmask_irq_rx(wil);
return IRQ_NONE;
}
- wil6210_mask_irq_rx(wil);
-
/* RX_DONE and RX_HTRSH interrupts are the same if interrupt
* moderation is not used. Interrupt moderation may cause RX
* buffer overflow while RX_DONE is delayed. The required
@@ -355,21 +358,24 @@ static irqreturn_t wil6210_irq_rx(int irq, void *cookie)
static irqreturn_t wil6210_irq_rx_edma(int irq, void *cookie)
{
struct wil6210_priv *wil = cookie;
- u32 isr = wil_ioread32_and_clear(wil->csr +
- HOSTADDR(RGF_INT_GEN_RX_ICR) +
- offsetof(struct RGF_ICR, ICR));
+ u32 isr;
bool need_unmask = true;
+ wil6210_mask_irq_rx_edma(wil);
+
+ isr = wil_ioread32_and_clear(wil->csr +
+ HOSTADDR(RGF_INT_GEN_RX_ICR) +
+ offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_rx(isr);
wil_dbg_irq(wil, "ISR RX 0x%08x\n", isr);
if (unlikely(!isr)) {
wil_err(wil, "spurious IRQ: RX\n");
+ wil6210_unmask_irq_rx_edma(wil);
return IRQ_NONE;
}
- wil6210_mask_irq_rx_edma(wil);
-
if (likely(isr & BIT_RX_STATUS_IRQ)) {
wil_dbg_irq(wil, "RX status ring\n");
isr &= ~BIT_RX_STATUS_IRQ;
@@ -403,21 +409,24 @@ static irqreturn_t wil6210_irq_rx_edma(int irq, void *cookie)
static irqreturn_t wil6210_irq_tx_edma(int irq, void *cookie)
{
struct wil6210_priv *wil = cookie;
- u32 isr = wil_ioread32_and_clear(wil->csr +
- HOSTADDR(RGF_INT_GEN_TX_ICR) +
- offsetof(struct RGF_ICR, ICR));
+ u32 isr;
bool need_unmask = true;
+ wil6210_mask_irq_tx_edma(wil);
+
+ isr = wil_ioread32_and_clear(wil->csr +
+ HOSTADDR(RGF_INT_GEN_TX_ICR) +
+ offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_tx(isr);
wil_dbg_irq(wil, "ISR TX 0x%08x\n", isr);
if (unlikely(!isr)) {
wil_err(wil, "spurious IRQ: TX\n");
+ wil6210_unmask_irq_tx_edma(wil);
return IRQ_NONE;
}
- wil6210_mask_irq_tx_edma(wil);
-
if (likely(isr & BIT_TX_STATUS_IRQ)) {
wil_dbg_irq(wil, "TX status ring\n");
isr &= ~BIT_TX_STATUS_IRQ;
@@ -446,21 +455,24 @@ static irqreturn_t wil6210_irq_tx_edma(int irq, void *cookie)
static irqreturn_t wil6210_irq_tx(int irq, void *cookie)
{
struct wil6210_priv *wil = cookie;
- u32 isr = wil_ioread32_and_clear(wil->csr +
- HOSTADDR(RGF_DMA_EP_TX_ICR) +
- offsetof(struct RGF_ICR, ICR));
+ u32 isr;
bool need_unmask = true;
+ wil6210_mask_irq_tx(wil);
+
+ isr = wil_ioread32_and_clear(wil->csr +
+ HOSTADDR(RGF_DMA_EP_TX_ICR) +
+ offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_tx(isr);
wil_dbg_irq(wil, "ISR TX 0x%08x\n", isr);
if (unlikely(!isr)) {
wil_err_ratelimited(wil, "spurious IRQ: TX\n");
+ wil6210_unmask_irq_tx(wil);
return IRQ_NONE;
}
- wil6210_mask_irq_tx(wil);
-
if (likely(isr & BIT_DMA_EP_TX_ICR_TX_DONE)) {
wil_dbg_irq(wil, "TX done\n");
isr &= ~BIT_DMA_EP_TX_ICR_TX_DONE;
@@ -532,20 +544,23 @@ static bool wil_validate_mbox_regs(struct wil6210_priv *wil)
static irqreturn_t wil6210_irq_misc(int irq, void *cookie)
{
struct wil6210_priv *wil = cookie;
- u32 isr = wil_ioread32_and_clear(wil->csr +
- HOSTADDR(RGF_DMA_EP_MISC_ICR) +
- offsetof(struct RGF_ICR, ICR));
+ u32 isr;
+
+ wil6210_mask_irq_misc(wil, false);
+
+ isr = wil_ioread32_and_clear(wil->csr +
+ HOSTADDR(RGF_DMA_EP_MISC_ICR) +
+ offsetof(struct RGF_ICR, ICR));
trace_wil6210_irq_misc(isr);
wil_dbg_irq(wil, "ISR MISC 0x%08x\n", isr);
if (!isr) {
wil_err(wil, "spurious IRQ: MISC\n");
+ wil6210_unmask_irq_misc(wil, false);
return IRQ_NONE;
}
- wil6210_mask_irq_misc(wil, false);
-
if (isr & ISR_MISC_FW_ERROR) {
u32 fw_assert_code = wil_r(wil, wil->rgf_fw_assert_code_addr);
u32 ucode_assert_code =
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 016/249] ath10k: Fix encoding for protected management frames
From: Sasha Levin @ 2019-07-15 13:43 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Rakesh Pillai, Kalle Valo, Sasha Levin, ath10k, linux-wireless,
netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Rakesh Pillai <pillair@codeaurora.org>
[ Upstream commit 42f1bc43e6a97b9ddbe976eba9bd05306c990c75 ]
Currently the protected management frames are
not appended with the MIC_LEN which results in
the protected management frames being encoded
incorrectly.
Add the extra space at the end of the protected
management frames to fix this encoding error for
the protected management frames.
Tested HW: WCN3990
Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
Fixes: 1807da49733e ("ath10k: wmi: add management tx by reference support over wmi")
Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 582fb11f648a..02709fc99034 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -2840,8 +2840,10 @@ ath10k_wmi_tlv_op_gen_mgmt_tx_send(struct ath10k *ar, struct sk_buff *msdu,
if ((ieee80211_is_action(hdr->frame_control) ||
ieee80211_is_deauth(hdr->frame_control) ||
ieee80211_is_disassoc(hdr->frame_control)) &&
- ieee80211_has_protected(hdr->frame_control))
+ ieee80211_has_protected(hdr->frame_control)) {
+ skb_put(msdu, IEEE80211_CCMP_MIC_LEN);
buf_len += IEEE80211_CCMP_MIC_LEN;
+ }
buf_len = min_t(u32, buf_len, WMI_TLV_MGMT_TX_FRAME_MAX_LEN);
buf_len = round_up(buf_len, 4);
--
2.20.1
^ permalink raw reply related
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