* [RFC/RFT 5/7] rt2800: do not nullify initialization vector data
From: Stanislaw Gruszka @ 2019-04-29 10:54 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin
In-Reply-To: <1556535270-3551-1-git-send-email-sgruszka@redhat.com>
If we restart hw we should keep existing IV (initialization vector)
otherwise HW encryption will be broken after restart.
Also fix some coding style issues on the way.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 9a49bb44197c..4a2e15b5aba4 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -1650,14 +1650,15 @@ static void rt2800_config_wcid_attr_cipher(struct rt2x00_dev *rt2x00dev,
offset = MAC_IVEIV_ENTRY(key->hw_key_idx);
- memset(&iveiv_entry, 0, sizeof(iveiv_entry));
+ rt2800_register_multiread(rt2x00dev, offset,
+ &iveiv_entry, sizeof(iveiv_entry));
if ((crypto->cipher == CIPHER_TKIP) ||
(crypto->cipher == CIPHER_TKIP_NO_MIC) ||
(crypto->cipher == CIPHER_AES))
iveiv_entry.iv[3] |= 0x20;
iveiv_entry.iv[3] |= key->keyidx << 6;
rt2800_register_multiwrite(rt2x00dev, offset,
- &iveiv_entry, sizeof(iveiv_entry));
+ &iveiv_entry, sizeof(iveiv_entry));
}
int rt2800_config_shared_key(struct rt2x00_dev *rt2x00dev,
@@ -6082,13 +6083,11 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
* ASIC will keep garbage value after boot, clear encryption keys.
*/
for (i = 0; i < 4; i++)
- rt2800_register_write(rt2x00dev,
- SHARED_KEY_MODE_ENTRY(i), 0);
+ rt2800_register_write(rt2x00dev, SHARED_KEY_MODE_ENTRY(i), 0);
for (i = 0; i < 256; i++) {
rt2800_config_wcid(rt2x00dev, NULL, i);
rt2800_delete_wcid_attr(rt2x00dev, i);
- rt2800_register_write(rt2x00dev, MAC_IVEIV_ENTRY(i), 0);
}
/*
--
2.7.5
^ permalink raw reply related
* [RFC/RFT 6/7] rt2x00: add restart hw
From: Stanislaw Gruszka @ 2019-04-29 10:54 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin
In-Reply-To: <1556535270-3551-1-git-send-email-sgruszka@redhat.com>
Add ieee80211_restart_hw() to watchdog and debugfs file for testing
if restart works as expected.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 4 +++
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 7 +++++
drivers/net/wireless/ralink/rt2x00/rt2x00debug.c | 35 ++++++++++++++++++++++++
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 10 +++++--
4 files changed, 54 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 4a2e15b5aba4..7d488fa8ef05 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -1266,6 +1266,9 @@ void rt2800_watchdog(struct rt2x00_dev *rt2x00dev)
if (hung_rx)
rt2x00_warn(rt2x00dev, "Watchdog RX hung detected\n");
+
+ if (hung_tx || hung_rx)
+ ieee80211_restart_hw(rt2x00dev->hw);
}
EXPORT_SYMBOL_GPL(rt2800_watchdog);
@@ -10286,6 +10289,7 @@ int rt2800_probe_hw(struct rt2x00_dev *rt2x00dev)
__set_bit(REQUIRE_TASKLET_CONTEXT, &rt2x00dev->cap_flags);
}
+ __set_bit(CAPABILITY_RESTART_HW, &rt2x00dev->cap_flags);
rt2x00dev->link.watchdog_interval = msecs_to_jiffies(100);
/*
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00.h b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
index cdf496c55b9d..1d7eaa9ecffb 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
@@ -724,6 +724,7 @@ enum rt2x00_capability_flags {
CAPABILITY_VCO_RECALIBRATION,
CAPABILITY_EXTERNAL_PA_TX0,
CAPABILITY_EXTERNAL_PA_TX1,
+ CAPABILITY_RESTART_HW,
};
/*
@@ -1281,6 +1282,12 @@ rt2x00_has_cap_vco_recalibration(struct rt2x00_dev *rt2x00dev)
return rt2x00_has_cap_flag(rt2x00dev, CAPABILITY_VCO_RECALIBRATION);
}
+static inline bool
+rt2x00_has_cap_restart_hw(struct rt2x00_dev *rt2x00dev)
+{
+ return rt2x00_has_cap_flag(rt2x00dev, CAPABILITY_RESTART_HW);
+}
+
/**
* rt2x00queue_map_txskb - Map a skb into DMA for TX purposes.
* @entry: Pointer to &struct queue_entry
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c b/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
index 05a2e8da412c..860a19cae3e5 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
@@ -63,6 +63,7 @@ struct rt2x00debug_intf {
* - chipset file
* - device state flags file
* - device capability flags file
+ * - hardware restart file
* - register folder
* - csr offset/value files
* - eeprom offset/value files
@@ -79,6 +80,7 @@ struct rt2x00debug_intf {
struct dentry *chipset_entry;
struct dentry *dev_flags;
struct dentry *cap_flags;
+ struct dentry *restart_hw;
struct dentry *register_folder;
struct dentry *csr_off_entry;
struct dentry *csr_val_entry;
@@ -577,6 +579,34 @@ static const struct file_operations rt2x00debug_fop_cap_flags = {
.llseek = default_llseek,
};
+static ssize_t rt2x00debug_write_restart_hw(struct file *file,
+ const char __user *buf,
+ size_t length,
+ loff_t *offset)
+{
+ struct rt2x00debug_intf *intf = file->private_data;
+ struct rt2x00_dev *rt2x00dev = intf->rt2x00dev;
+ static unsigned long last_reset;
+
+ if (!rt2x00_has_cap_restart_hw(rt2x00dev))
+ return -EOPNOTSUPP;
+
+ if (time_before(jiffies, last_reset + msecs_to_jiffies(2000)))
+ return -EBUSY;
+
+ last_reset = jiffies;
+
+ ieee80211_restart_hw(rt2x00dev->hw);
+ return length;
+}
+
+static const struct file_operations rt2x00debug_restart_hw = {
+ .owner = THIS_MODULE,
+ .write = rt2x00debug_write_restart_hw,
+ .open = simple_open,
+ .llseek = generic_file_llseek,
+};
+
static struct dentry *rt2x00debug_create_file_driver(const char *name,
struct rt2x00debug_intf
*intf,
@@ -672,6 +702,10 @@ void rt2x00debug_register(struct rt2x00_dev *rt2x00dev)
intf->driver_folder, intf,
&rt2x00debug_fop_cap_flags);
+ intf->restart_hw = debugfs_create_file("restart_hw", 0200,
+ intf->driver_folder, intf,
+ &rt2x00debug_restart_hw);
+
intf->register_folder =
debugfs_create_dir("register", intf->driver_folder);
@@ -753,6 +787,7 @@ void rt2x00debug_deregister(struct rt2x00_dev *rt2x00dev)
debugfs_remove(intf->csr_off_entry);
debugfs_remove(intf->register_folder);
debugfs_remove(intf->dev_flags);
+ debugfs_remove(intf->restart_hw);
debugfs_remove(intf->cap_flags);
debugfs_remove(intf->chipset_entry);
debugfs_remove(intf->driver_entry);
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
index 357c0941aaad..93ab4d089b21 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
@@ -1269,8 +1269,14 @@ int rt2x00lib_start(struct rt2x00_dev *rt2x00dev)
{
int retval;
- if (test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags))
- return 0;
+ if (test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags)) {
+ /*
+ * This is special case for ieee80211_restart_hw(), otherwise
+ * mac80211 never call start() two times in row without stop();
+ */
+ rt2x00dev->ops->lib->pre_reset_hw(rt2x00dev);
+ rt2x00lib_stop(rt2x00dev);
+ }
/*
* If this is the first interface which is added,
--
2.7.5
^ permalink raw reply related
* [RFC/RFT 7/7] rt2800: do not enable watchdog by default
From: Stanislaw Gruszka @ 2019-04-29 10:54 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin
In-Reply-To: <1556535270-3551-1-git-send-email-sgruszka@redhat.com>
Make watchdog disabled by default and add module parameter to enable it.
User will have to create file in /etc/modprobe.d/ with
options rt2800lib watchdog=1
to enable the watchdog or load "rt2800lib watchdog=1" module manually
before loading rt2800{soc,pci,usb} module.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 12 ++++++++++--
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 1 +
drivers/net/wireless/ralink/rt2x00/rt2x00link.c | 2 +-
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 7d488fa8ef05..0de7d9b509bc 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -41,6 +41,10 @@
#include "rt2800lib.h"
#include "rt2800.h"
+static bool modparam_watchdog;
+module_param_named(watchdog, modparam_watchdog, bool, S_IRUGO);
+MODULE_PARM_DESC(watchdog, "Enable watchdog.");
+
/*
* Register access.
* All access to the CSR registers will go through the methods
@@ -10289,8 +10293,12 @@ int rt2800_probe_hw(struct rt2x00_dev *rt2x00dev)
__set_bit(REQUIRE_TASKLET_CONTEXT, &rt2x00dev->cap_flags);
}
- __set_bit(CAPABILITY_RESTART_HW, &rt2x00dev->cap_flags);
- rt2x00dev->link.watchdog_interval = msecs_to_jiffies(100);
+ if (modparam_watchdog) {
+ __set_bit(CAPABILITY_RESTART_HW, &rt2x00dev->cap_flags);
+ rt2x00dev->link.watchdog_interval = msecs_to_jiffies(100);
+ } else {
+ rt2x00dev->link.watchdog_disabled = true;
+ }
/*
* Set the rssi offset.
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00.h b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
index 1d7eaa9ecffb..c76d41272b03 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
@@ -337,6 +337,7 @@ struct link {
*/
struct delayed_work watchdog_work;
unsigned int watchdog_interval;
+ bool watchdog_disabled;
/*
* Work structure for scheduling periodic AGC adjustments.
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00link.c b/drivers/net/wireless/ralink/rt2x00/rt2x00link.c
index fcc59553918f..db4b164ac848 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00link.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00link.c
@@ -395,7 +395,7 @@ void rt2x00link_start_watchdog(struct rt2x00_dev *rt2x00dev)
struct link *link = &rt2x00dev->link;
if (test_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags) &&
- rt2x00dev->ops->lib->watchdog)
+ rt2x00dev->ops->lib->watchdog && !link->watchdog_disabled)
ieee80211_queue_delayed_work(rt2x00dev->hw,
&link->watchdog_work,
link->watchdog_interval);
--
2.7.5
^ permalink raw reply related
* [PATCH v2] ath10k: add peer id check in ath10k_peer_find_by_id
From: Wen Gong @ 2019-04-29 11:17 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
For some SDIO chip, the peer id is 65535 for MPDU with error status,
then test_bit will trigger buffer overflow for peer's memory, if kasan
enabled, it will report error.
Reason is when station is in disconnecting status, firmware do not delete
the peer info since it not disconnected completely, meanwhile some AP will
still send data packet to station, then hardware will receive the packet
and send to firmware, firmware's logic will report peer id of 65535 for
MPDU with error status.
Add check for overflow the size of peer's peer_ids will avoid the buffer
overflow access.
Call trace of kasan:
dump_backtrace+0x0/0x2ec
show_stack+0x20/0x2c
__dump_stack+0x20/0x28
dump_stack+0xc8/0xec
print_address_description+0x74/0x240
kasan_report+0x250/0x26c
__asan_report_load8_noabort+0x20/0x2c
ath10k_peer_find_by_id+0x180/0x1e4 [ath10k_core]
ath10k_htt_t2h_msg_handler+0x100c/0x2fd4 [ath10k_core]
ath10k_htt_htc_t2h_msg_handler+0x20/0x34 [ath10k_core]
ath10k_sdio_irq_handler+0xcc8/0x1678 [ath10k_sdio]
process_sdio_pending_irqs+0xec/0x370
sdio_run_irqs+0x68/0xe4
sdio_irq_work+0x1c/0x28
process_one_work+0x3d8/0x8b0
worker_thread+0x508/0x7cc
kthread+0x24c/0x264
ret_from_fork+0x10/0x18
Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00007-QCARMSWP-1.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
---
v2: changed from BITS_PER_BYTE to BITS_PER_TYPE
drivers/net/wireless/ath/ath10k/txrx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/txrx.c b/drivers/net/wireless/ath/ath10k/txrx.c
index 23606b6..3b837b8 100644
--- a/drivers/net/wireless/ath/ath10k/txrx.c
+++ b/drivers/net/wireless/ath/ath10k/txrx.c
@@ -157,6 +157,9 @@ struct ath10k_peer *ath10k_peer_find_by_id(struct ath10k *ar, int peer_id)
{
struct ath10k_peer *peer;
+ if (peer_id >= BITS_PER_TYPE(peer->peer_ids))
+ return NULL;
+
lockdep_assert_held(&ar->data_lock);
list_for_each_entry(peer, &ar->peers, list)
--
1.9.1
^ permalink raw reply related
* Re: pull-request: mac80211 2019-04-26
From: Johannes Berg @ 2019-04-29 11:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
In-Reply-To: <20190426090747.20949-1-johannes@sipsolutions.net>
Hi Dave,
Sorry to nag, and maybe I'm missing something, but I didn't see this
show up in your tree, yet you marked it as accepted in patchwork:
https://patchwork.ozlabs.org/patch/1091413/
But maybe there's a gap that I should expect here, like you mark it as
accepted when you start some kind of testing and then push it out later?
Really the only reason I'm asking is that I wanted to forward to apply
another patch, but maybe I'll ask you to apply that one patch directly.
Thanks,
johannes
^ permalink raw reply
* Re: [wireless-drivers-next:master 21/45] drivers/net/wireless/rsi/rsi_91x_usb.c:774:17-26: ERROR: id is NULL but dereferenced. (fwd)
From: Siva Rebbagondla @ 2019-04-29 11:43 UTC (permalink / raw)
To: Kalle Valo; +Cc: Julia Lawall, kbuild-all, Linux Wireless
In-Reply-To: <87r29ou6td.fsf@kamboji.qca.qualcomm.com>
Hi kalle,
On Fri, Apr 26, 2019 at 8:55 PM Kalle Valo <kvalo@codeaurora.org> wrote:
>
> Siva Rebbagondla <siva8118@gmail.com> writes:
>
> > On Fri, Apr 26, 2019 at 8:28 PM Kalle Valo <kvalo@codeaurora.org> wrote:
> >
> >> Julia Lawall <julia.lawall@lip6.fr> writes:
> >>
> >> > The ifs starting on line 766 can fail because id is NULL.
> >
> > I don't think id will be NULL here. id is coming from probe.
> > Is there any other opinions?.
>
> The code in question:
>
> if (id && id->idProduct == RSI_USB_PID_9113) {
> rsi_dbg(INIT_ZONE, "%s: 9113 module detected\n", __func__);
> adapter->device_model = RSI_DEV_9113;
> } else if (id && id->idProduct == RSI_USB_PID_9116) {
> rsi_dbg(INIT_ZONE, "%s: 9116 module detected\n", __func__);
> adapter->device_model = RSI_DEV_9116;
> } else {
> rsi_dbg(ERR_ZONE, "%s: Unsupported RSI device id 0x%x\n",
> __func__, id->idProduct);
> goto err1;
> }
>
> I think the fact that you are checking if id is NULL is confusing the
> static checkers. If it's never NULL why check for that anyway? So if
> it's guaranteed that id is never NULL (I didn't check that from USB
> core) I would recommend to remove the NULL checks from the driver.
Yes Kalle. I agree. I will make the change and send you for the review.
---
Siva Rebbagondla
^ permalink raw reply
* [PATCH] mac80211: remove set but not used variable 'old'
From: YueHaibing @ 2019-04-29 14:07 UTC (permalink / raw)
To: Johannes Berg, alexander
Cc: YueHaibing, linux-wireless, kernel-janitors, netdev
Fixes gcc '-Wunused-but-set-variable' warning:
net/mac80211/key.c: In function 'ieee80211_set_tx_key':
net/mac80211/key.c:271:24: warning:
variable 'old' set but not used [-Wunused-but-set-variable]
It is not used since introduction in
commit 96fc6efb9ad9 ("mac80211: IEEE 802.11 Extended Key ID support")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/mac80211/key.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index 20bf9db7a388..89f09a09efdb 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -268,11 +268,9 @@ int ieee80211_set_tx_key(struct ieee80211_key *key)
{
struct sta_info *sta = key->sta;
struct ieee80211_local *local = key->local;
- struct ieee80211_key *old;
assert_key_lock(local);
- old = key_mtx_dereference(local, sta->ptk[sta->ptk_idx]);
sta->ptk_idx = key->conf.keyidx;
ieee80211_check_fast_xmit(sta);
^ permalink raw reply related
* Re: [PATCH] ath10k: Drop WARN_ON()s that always trigger during system resume
From: Kalle Valo @ 2019-04-29 14:10 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Brian Norris, Rafael J. Wysocki, Claire Chang, Sriram R, Linux PM,
Pradeep Kumar Chitrapu, open list:NETWORKING DRIVERS (WIRELESS),
ath10k, Srinivas Pandruvada, Todd Brandt
In-Reply-To: <CAJZ5v0ifD=DATprUeeO2_LGs04aEEhPB6AcGVPxWUdQaOma+ww@mail.gmail.com>
"Rafael J. Wysocki" <rafael@kernel.org> writes:
> On Fri, Apr 26, 2019 at 9:18 AM Kalle Valo <kvalo@codeaurora.org> wrote:
>>
>> Brian Norris <briannorris@chromium.org> writes:
>>
>> > + Sriram, Pradeep, Claire
>> >
>> > On Sun, Mar 03, 2019 at 06:24:33PM +0100, Rafael J. Wysocki wrote:
>> >
>> > Ooh, exactly 1 month ago!
>> >
>> >> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> >>
>> >> ath10k_mac_vif_chan() always returns an error for the given vif
>> >> during system-wide resume which reliably triggers two WARN_ON()s
>> >> in ath10k_bss_info_changed() and they are not particularly
>> >> useful in that code path, so drop them.
>> >>
>> >
>> > Particularly, when WOWLAN isn't enabled, we get called during resume via
>> > ieee80211_reconfig(), where we're not associated and don't have any
>> > channel contexts. AFAICT, we shouldn't need to communicate anything in
>> > particular to the firmware here, and so failing the 'if' is definitely
>> > not worth WARN-ing about.
>> >
>> > I'd love to see this get applied with:
>> >
>> > Fixes: cd93b83ad927 ("ath10k: support for multicast rate control")
>> > Fixes: f279294e9ee2 ("ath10k: add support for configuring management packet rate")
>> >
>> > and sent to stable. This has been bugging people since 4.19. Spurious
>> > WARN_ON()s can trigger reports to various crash trackers, and on some
>> > systems appear as user-visible warnings ("System problem detected").
>> >
>> >> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> >
>> > Reviewed-by: Brian Norris <briannorris@chromium.org>
>> > Tested-by: Brian Norris <briannorris@chromium.org>
>>
>> I added these now to the commit log, thanks Brian.
>>
>> Rafael, could you please provide the hardware and firmware versions you
>> tested this on? We have so many different firmware branches to support
>> that I prefer to have that documented in the commit log. Providing
>> ath10k startup messages in dmesg are enough,
>
> There you go:
>
> [ 4.695349] ath10k_pci 0000:3a:00.0: enabling device (0000 -> 0002)
> [ 4.698165] ath10k_pci 0000:3a:00.0: pci irq msi oper_irq_mode 2
> irq_mode 0 reset_mode 0
> [ 4.912240] ath10k_pci 0000:3a:00.0: qca6174 hw3.2 target
> 0x05030000 chip_id 0x00340aff sub 1a56:1535
> [ 4.912255] ath10k_pci 0000:3a:00.0: kconfig debug 0 debugfs 0
> tracing 0 dfs 0 testmode 0
> [ 4.912716] ath10k_pci 0000:3a:00.0: firmware ver
> WLAN.RM.2.0-00180-QCARMSWPZ-1 api 4 features
> wowlan,ignore-otp,no-4addr-pad crc32 75dee6c5
> [ 4.982563] ath10k_pci 0000:3a:00.0: board_file api 2 bmi_id N/A
> crc32 19644295
Thanks, I added the info to the commit log.
>> I can then add it to the commit log.
>
> Still, I'm quite sure that the WARN_ON()s trigger during system resume
> regardless of the hw/fw combination.
Sure, I'm not claiming anything else. We just have so many different
hw/fw combos that I want to have the environment documented in the
commit log in case we need to investigate history in the future.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath10k: Drop WARN_ON()s that always trigger during system resume
From: Kalle Valo @ 2019-04-29 14:12 UTC (permalink / raw)
To: Claire Chang
Cc: Rafael J. Wysocki, Brian Norris, Rafael J. Wysocki, Sriram R,
Linux PM, Pradeep Kumar Chitrapu,
open list:NETWORKING DRIVERS (WIRELESS), ath10k,
Srinivas Pandruvada, Todd Brandt
In-Reply-To: <CALiNf2_qV+iViHbS0tQquTMZfu6XfFvQCH14mdT5bixn94DZ2Q@mail.gmail.com>
Claire Chang <tientzu@chromium.org> writes:
> Tested-by: Claire Chang <tientzu@chromium.org>
>
>> Still, I'm quite sure that the WARN_ON()s trigger during system resume
>> regardless of the hw/fw combination.
>
> Also see this on sido:
>
> [ 4.925278] ath10k_sdio mmc1:0001:1: qca6174 hw3.2 sdio target
> 0x05030000 chip_id 0x00000000 sub 0000:0000
> [ 4.935721] ath10k_sdio mmc1:0001:1: kconfig debug 1 debugfs 1
> tracing 1 dfs 0 testmode 1
> [ 4.948750] ath10k_sdio mmc1:0001:1: firmware ver
> WLAN.RMH.4.4.1-00007-QCARMSWP-1 api 6 features wowlan,ignore-otp crc32
> b98adaf8
> [ 5.132728] ath10k_sdio mmc1:0001:1: board_file api 2 bmi_id 0:4
> crc32 6364cfcc
Great, thanks. I added your Tested-by as well.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH for-5.1] ath10k: perform crash dump collection in workqueue
From: Kalle Valo @ 2019-04-29 14:25 UTC (permalink / raw)
To: Brian Norris
Cc: linux-wireless, ath10k, Carl Huang, Wen Gong, Michał Kazior,
Brian Norris
In-Reply-To: <20190326205728.168973-1-briannorris@chromium.org>
Brian Norris <briannorris@chromium.org> wrote:
> Commit 25733c4e67df ("ath10k: pci: use mutex for diagnostic window CE
> polling") introduced a regression where we try to sleep (grab a mutex)
> in an atomic context:
>
> [ 233.602619] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:254
> [ 233.602626] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
> [ 233.602636] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.1.0-rc2 #4
> [ 233.602642] Hardware name: Google Scarlet (DT)
> [ 233.602647] Call trace:
> [ 233.602663] dump_backtrace+0x0/0x11c
> [ 233.602672] show_stack+0x20/0x28
> [ 233.602681] dump_stack+0x98/0xbc
> [ 233.602690] ___might_sleep+0x154/0x16c
> [ 233.602696] __might_sleep+0x78/0x88
> [ 233.602704] mutex_lock+0x2c/0x5c
> [ 233.602717] ath10k_pci_diag_read_mem+0x68/0x21c [ath10k_pci]
> [ 233.602725] ath10k_pci_diag_read32+0x48/0x74 [ath10k_pci]
> [ 233.602733] ath10k_pci_dump_registers+0x5c/0x16c [ath10k_pci]
> [ 233.602741] ath10k_pci_fw_crashed_dump+0xb8/0x548 [ath10k_pci]
> [ 233.602749] ath10k_pci_napi_poll+0x60/0x128 [ath10k_pci]
> [ 233.602757] net_rx_action+0x140/0x388
> [ 233.602766] __do_softirq+0x1b0/0x35c
> [...]
>
> ath10k_pci_fw_crashed_dump() is called from NAPI contexts, and firmware
> memory dumps are retrieved using the diag memory interface.
>
> A simple reproduction case is to run this on QCA6174A /
> WLAN.RM.4.4.1-00132-QCARMSWP-1, which happens to be a way to b0rk the
> firmware:
>
> dd if=/sys/kernel/debug/ieee80211/phy0/ath10k/mem_value bs=4K count=1
> of=/dev/null
>
> (NB: simulated firmware crashes, via debugfs, don't trigger firmware
> dumps.)
>
> The fix is to move the crash-dump into a workqueue context, and avoid
> relying on 'data_lock' for most mutual exclusion. We only keep using it
> here for protecting 'fw_crash_counter', while the rest of the coredump
> buffers are protected by a new 'dump_mutex'.
>
> I've tested the above with simulated firmware crashes (debugfs 'reset'
> file), real firmware crashes (the 'dd' command above), and a variety of
> reboot and suspend/resume configurations on QCA6174A.
>
> Reported here:
> http://lkml.kernel.org/linux-wireless/20190325202706.GA68720@google.com
>
> Fixes: 25733c4e67df ("ath10k: pci: use mutex for diagnostic window CE polling")
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-current branch of ath.git, thanks.
38faed150438 ath10k: perform crash dump collection in workqueue
--
https://patchwork.kernel.org/patch/10872181/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: Drop WARN_ON()s that always trigger during system resume
From: Kalle Valo @ 2019-04-29 14:26 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux PM, Srinivas Pandruvada, ath10k, Todd Brandt,
linux-wireless
In-Reply-To: <2884043.Jv1Mn93hE8@aspire.rjw.lan>
"Rafael J. Wysocki" <rjw@rjwysocki.net> wrote:
> ath10k_mac_vif_chan() always returns an error for the given vif
> during system-wide resume which reliably triggers two WARN_ON()s
> in ath10k_bss_info_changed() and they are not particularly
> useful in that code path, so drop them.
>
> Tested: QCA6174 hw3.2 PCI with WLAN.RM.2.0-00180-QCARMSWPZ-1
> Tested: QCA6174 hw3.2 SDIO with WLAN.RMH.4.4.1-00007-QCARMSWP-1
>
> Fixes: cd93b83ad927 ("ath10k: support for multicast rate control")
> Fixes: f279294e9ee2 ("ath10k: add support for configuring management packet rate")
> Cc: stable@vger.kernel.org
> Reviewed-by: Brian Norris <briannorris@chromium.org>
> Tested-by: Brian Norris <briannorris@chromium.org>
> Tested-by: Claire Chang <tientzu@chromium.org>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-current branch of ath.git, thanks.
9e80ad37f678 ath10k: Drop WARN_ON()s that always trigger during system resume
--
https://patchwork.kernel.org/patch/10837139/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/5] ath10k: add struct for high latency PN replay protection
From: Kalle Valo @ 2019-04-29 14:39 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless, Wen Gong
In-Reply-To: <1556260871-2919-2-git-send-email-kvalo@codeaurora.org>
Kalle Valo <kvalo@codeaurora.org> wrote:
> Add the struct for PN replay protection and fragment packet
> handler.
>
> Also fix the bitmask of HTT_RX_DESC_HL_INFO_MCAST_BCAST to match what's currently
> used by SDIO firmware. The defines are not used yet so it's safe to modify
> them. Remove the conflicting HTT_RX_DESC_HL_INFO_FRAGMENT as
> it's not either used in ath10k.
>
> Tested on 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>
5 patches applied to ath-next branch of ath.git, thanks.
e1bddde9737a ath10k: add struct for high latency PN replay protection
28ce53b6cfda ath10k: add handler for HTT_T2H_MSG_TYPE_SEC_IND event
130c77495708 ath10k: add PN replay protection for high latency devices
33f9747291ff ath10k: add fragmentation handler for high latency devices
a8b10da05cbe ath10k: enable QCA6174 hw3.2 SDIO hardware
--
https://patchwork.kernel.org/patch/10918335/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: fix incorrect multicast/broadcast rate setting
From: Kalle Valo @ 2019-04-29 14:43 UTC (permalink / raw)
To: Pradeep Kumar Chitrapu
Cc: ath10k, linux-wireless, Pradeep kumar Chitrapu, Zhi Chen
In-Reply-To: <1544504171-19810-1-git-send-email-pradeepc@codeaurora.org>
Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> wrote:
> 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>
Patch applied to ath-next branch of ath.git, thanks.
93ee3d108fc7 ath10k: fix incorrect multicast/broadcast rate setting
--
https://patchwork.kernel.org/patch/10723033/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH][next] ath6kl: debug: Use struct_size() helper
From: Kalle Valo @ 2019-04-29 14:46 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: David S. Miller, linux-wireless, netdev, linux-kernel,
Gustavo A. R. Silva
In-Reply-To: <20190403154835.GA20955@embeddedor>
"Gustavo A. R. Silva" <gustavo@embeddedor.com> wrote:
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes, in particular in the
> context in which this code is being used.
>
> So, change the following form:
>
> sizeof(*tbl) + num_entries * sizeof(struct wmi_bss_roam_info)
>
> to :
>
> struct_size(tbl, info, num_entries)
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
df75786b9233 ath6kl: debug: Use struct_size() helper
--
https://patchwork.kernel.org/patch/10884039/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH][next] ath6kl: wmi: use struct_size() helper
From: Kalle Valo @ 2019-04-29 14:48 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: David S. Miller, linux-wireless, netdev, linux-kernel,
Gustavo A. R. Silva
In-Reply-To: <20190403184949.GA7597@embeddedor>
"Gustavo A. R. Silva" <gustavo@embeddedor.com> wrote:
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes, in particular in the
> context in which this code is being used.
>
> So, replace code of the following form:
>
> sizeof(*ev) + ev->num_neighbors * sizeof(struct wmi_neighbor_info)
>
> with:
>
> struct_size(ev, neighbor, ev->num_neighbors)
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
83d9562b6478 ath6kl: wmi: use struct_size() helper
--
https://patchwork.kernel.org/patch/10884343/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath6kl: add some bounds checking
From: Kalle Valo @ 2019-04-29 14:49 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-wireless, kernel-janitors
In-Reply-To: <20190404085651.GC20193@kadam>
Dan Carpenter <dan.carpenter@oracle.com> wrote:
> 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>
Patch applied to ath-next branch of ath.git, thanks.
5d6751eaff67 ath6kl: add some bounds checking
--
https://patchwork.kernel.org/patch/10885299/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath6kl: remove redundant check of status != 0
From: Kalle Valo @ 2019-04-29 14:50 UTC (permalink / raw)
To: Colin King
Cc: David S . Miller, linux-wireless, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20190404134723.24667-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> The check on status not being zero is redundant as previous code
> paths that set status to an error value break out of the while
> loop and hence status is never non-zero at the check. Remove
> this redundant code.
>
> Addresses-Coverity: ("Logically dead code")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
e643da21e19a ath6kl: remove redundant check of status != 0
--
https://patchwork.kernel.org/patch/10885625/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath9k: Don't trust TX status TID number when reporting airtime
From: Kalle Valo @ 2019-04-29 14:52 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: linux-wireless, Toke Høiland-Jørgensen,
Miguel Catalan Cid
In-Reply-To: <20190307183944.11190-1-toke@redhat.com>
Toke Høiland-Jørgensen wrote:
> 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>
Patch applied to ath-next branch of ath.git, thanks.
389b72e58259 ath9k: Don't trust TX status TID number when reporting airtime
--
https://patchwork.kernel.org/patch/10843731/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath9k: Check for errors when reading SREV register
From: Kalle Valo @ 2019-04-29 14:53 UTC (permalink / raw)
To: Tim Schumacher
In-Reply-To: <20190318190557.21599-1-timschumi@gmx.de>
Tim Schumacher <timschumi@gmx.de> wrote:
> 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>
Patch applied to ath-next branch of ath.git, thanks.
2f90c7e5d094 ath9k: Check for errors when reading SREV register
--
https://patchwork.kernel.org/patch/10858399/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath9k: Differentiate between max combined and per chain power
From: Kalle Valo @ 2019-04-29 14:54 UTC (permalink / raw)
To: Sven Eckelmann; +Cc: linux-wireless, QCA ath9k Development, Sven Eckelmann
In-Reply-To: <20190320103723.27228-1-sven@narfation.org>
Sven Eckelmann <sven@narfation.org> wrote:
> The ath9k driver uses as maximum allowed txpower the constant
> MAX_RATE_POWER. It is used to set a maximum txpower limit for the PHY
> (which is combined txpower) and also the maximum txpower for per chain
> rates. Its value 63 is derived from the maximum number the registers can
> store for the per chain txpower.
>
> The max txpower a user can set because of this is 31 dBm (floor(63 / 2)).
> This also means that a device with multiple tx chains is even limited
> further:
>
> * 1 chain: 31 dBm per chain
> * 2 chains: 28 dBm per chain
> * 3 chains: 26 dBm per chain
>
> This combined txpower limit of 31 dBm becomes even more problematic when
> some extra antenna gain is set in the EEPROM. A high power device is then
> no longer able to reach its potential limits.
>
> Instead the code dealing with the combined txpower must use a higher limit
> than 63 and only the code dealing with the per chain txpower have to use
> the limit of 63. Since the antenna gain can be quite large and 8 bit
> variables are often used in ath9k for txpower, a large, divisible by two
> number like 254 is a good choice for this new limit.
>
> Signed-off-by: Sven Eckelmann <sven@narfation.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
b037b107565f ath9k: Differentiate between max combined and per chain power
--
https://patchwork.kernel.org/patch/10861389/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath9k: Remove some set but not used variables
From: Kalle Valo @ 2019-04-29 14:55 UTC (permalink / raw)
To: Yue Haibing
Cc: linux-kernel, netdev, linux-wireless, ath9k-devel, davem,
YueHaibing
In-Reply-To: <20190417025745.24044-1-yuehaibing@huawei.com>
Yue Haibing <yuehaibing@huawei.com> wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/ath/ath9k/xmit.c: In function 'ath_tx_count_frames':
> drivers/net/wireless/ath/ath9k/xmit.c:413:25: warning: variable 'fi' set but not used [-Wunused-but-set-variable]
> drivers/net/wireless/ath/ath9k/xmit.c: In function 'ath_tx_complete_aggr':
> drivers/net/wireless/ath/ath9k/xmit.c:449:24: warning: variable 'hdr' set but not used [-Wunused-but-set-variable]
> drivers/net/wireless/ath/ath9k/xmit.c: In function 'ath_tx_start':
> drivers/net/wireless/ath/ath9k/xmit.c:2274:18: warning: variable 'avp' set but not used [-Wunused-but-set-variable]
> drivers/net/wireless/ath/ath9k/xmit.c:2269:24: warning: variable 'hdr' set but not used [-Wunused-but-set-variable]
>
> These variables are not used any more
> and can be removed.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
05039f01e630 ath9k: Remove some set but not used variables
--
https://patchwork.kernel.org/patch/10904395/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2 1/2] ath: drop duplicated define
From: Kalle Valo @ 2019-04-29 14:58 UTC (permalink / raw)
To: Tomislav Požega; +Cc: linux-wireless
In-Reply-To: <1552572470-2656-1-git-send-email-pozega.tomislav@gmail.com>
Tomislav Požega wrote:
> Remove duplicate NO_CTL that is just 2 lines below.
>
> Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2 patches applied to ath-next branch of ath.git, thanks.
b50fd29c5268 ath: drop duplicated define
d3c2be9022d6 ath9k: drop redundant code in ar9003_hw_set_channel
--
https://patchwork.kernel.org/patch/10852929/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath: DFS JP domain W56 fixed pulse type 3 RADAR detection
From: Kalle Valo @ 2019-04-29 14:59 UTC (permalink / raw)
To: Tamizh chelvam; +Cc: ath10k, linux-wireless, Anilkumar Kolli, Tamizh chelvam
In-Reply-To: <1551893771-22485-1-git-send-email-tamizhr@codeaurora.org>
Tamizh chelvam <tamizhr@codeaurora.org> wrote:
> 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>
Patch applied to ath-next branch of ath.git, thanks.
d8792393a783 ath: DFS JP domain W56 fixed pulse type 3 RADAR detection
--
https://patchwork.kernel.org/patch/10841487/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] wil6210: fix potential out-of-bounds read
From: Kalle Valo @ 2019-04-29 15:00 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Maya Erez, David S. Miller, Vladimir Kondratiev, linux-wireless,
wil6210, netdev, linux-kernel, Gustavo A. R. Silva
In-Reply-To: <20190415145646.GA16597@embeddedor>
"Gustavo A. R. Silva" <gustavo@embeddedor.com> wrote:
> 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>
Patch applied to ath-next branch of ath.git, thanks.
bfabdd699732 wil6210: fix potential out-of-bounds read
--
https://patchwork.kernel.org/patch/10901053/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] wireless: carl9170: fix clang build warning
From: Kalle Valo @ 2019-04-29 15:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Christian Lamparter, David S. Miller, clang-built-linux,
Nick Desaulniers, Nathan Chancellor, Arnd Bergmann, Dan Carpenter,
Gustavo A. R. Silva, linux-wireless, netdev, linux-kernel
In-Reply-To: <20190325124354.1413529-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> clang fails to eliminate some dead code with always-taken branches
> when CONFIG_PROFILE_ANNOTATED_BRANCHES is set, leading to a false-positive
> warning:
>
> drivers/net/wireless/ath/carl9170/mac.c:522:3: error: variable 'power' is used uninitialized whenever 'if' condition is
> false [-Werror,-Wsometimes-uninitialized]
> BUG_ON(1);
> ^~~~~~~~~
>
> Change both instances of BUG_ON(1) in carl9170 to the simpler BUG()
> to avoid the warning.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Christian Lamparter <chunkeey@gmail.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
62acdcfa8b7a wireless: carl9170: fix clang build warning
--
https://patchwork.kernel.org/patch/10869053/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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