* Re: [PATCH v6] mac80211_hwsim: Register support for HE meshpoint
From: Sven Eckelmann @ 2019-08-13 11:20 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless
In-Reply-To: <20190813105549.GA26160@w1.fi>
[-- Attachment #1: Type: text/plain, Size: 2277 bytes --]
Hi,
On Tuesday, 13 August 2019 12:55:49 CEST Jouni Malinen wrote:
[...]
> > [1] https://patchwork.ozlabs.org/patch/1131273/
> > [2] https://patchwork.ozlabs.org/patch/1116968/
> > [3] https://lore.kernel.org/r/2152977.f3ncjnVLFo@bentobox
>
> And with the exact same snapshot of hostap.git.
>
> Without [1] applied, this mac80211_hwsim patch to enable HE meshpoint
> results in the following test cases failing:
>
> mesh_secure_ocv_mix_legacy
> wpas_mesh_open_ht40
> wpas_mesh_max_peering
> mesh_secure_ocv_mix_ht
>
> [1] fixes wpas_mesh_max_peering
>
> This leaves following three test cases failing ("Test exception:
> Couldn't join mesh"):
>
> mesh_secure_ocv_mix_legacy
> wpas_mesh_open_ht40
> mesh_secure_ocv_mix_ht
>
> Am I missing a patch somewhere that would be needed to make those pass?
No, these also failed for me without the mac80211_hwsim patch [3] in a full
test run. And thus not analyzed further by me.
Interestingly, they don't fail (without the hwsim patch) when running them
without the full test suite.
[...]
> So is that missing of vht_enabled=1 from some configurations the problem
> here and if so, would you be able to point me to a hostap.git patch that
> addresses this?
No, there is no hostap.git patch here. There was one in the past in
patchwork [4] but there were concerns by John. So if you reapply the patch
then you will see that it doesn't fail anymore.
diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c
index d71511cb5..b54900bc4 100644
--- a/src/drivers/driver_nl80211.c
+++ b/src/drivers/driver_nl80211.c
@@ -4360,7 +4360,7 @@ static int nl80211_put_freq_params(struct nl_msg *msg,
is_24ghz = hw_mode == HOSTAPD_MODE_IEEE80211G ||
hw_mode == HOSTAPD_MODE_IEEE80211B;
- if (freq->vht_enabled || (freq->he_enabled && !is_24ghz)) {
+ if (freq->vht_enabled) {
enum nl80211_chan_width cw;
wpa_printf(MSG_DEBUG, " * bandwidth=%d", freq->bandwidth);
So as a compromise, I can can propose a patch which tries to replicate this
2.4GHz specific behavior from nl80211_put_freq_params also in
ibss_mesh_setup_freq
Btw. thanks for pointing me towards specific test cases.
Kind regards,
Sven
[4] https://patchwork.ozlabs.org/patch/1125305/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCHv2] zdnet: remove false assertion from zd_mac_clear()
From: Oliver Neukum @ 2019-08-13 12:01 UTC (permalink / raw)
To: davem, netdev, dsd, kune, kvalo, linux-wireless; +Cc: Oliver Neukum
The function is called before the lock which is asserted was ever used.
Just remove it.
V2: correct CCs
Reported-by: syzbot+74c65761783d66a9c97c@syzkaller.appspotmail.com
Signed-off-by: Oliver Neukum <oneukum@suse.com>
---
drivers/net/wireless/zydas/zd1211rw/zd_mac.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/zydas/zd1211rw/zd_mac.c b/drivers/net/wireless/zydas/zd1211rw/zd_mac.c
index da7e63fca9f5..a9999d10ae81 100644
--- a/drivers/net/wireless/zydas/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zydas/zd1211rw/zd_mac.c
@@ -223,7 +223,6 @@ void zd_mac_clear(struct zd_mac *mac)
{
flush_workqueue(zd_workqueue);
zd_chip_clear(&mac->chip);
- lockdep_assert_held(&mac->lock);
ZD_MEMCLEAR(mac, sizeof(struct zd_mac));
}
--
2.16.4
^ permalink raw reply related
* [PATCHv3] zd1211rw: remove false assertion from zd_mac_clear()
From: Oliver Neukum @ 2019-08-13 12:04 UTC (permalink / raw)
To: davem, netdev, dsd, kune, kvalo, linux-wireless; +Cc: Oliver Neukum
The function is called before the lock which is asserted was ever used.
Just remove it.
V2: correct CCs
V3: correct name
Reported-by: syzbot+74c65761783d66a9c97c@syzkaller.appspotmail.com
Signed-off-by: Oliver Neukum <oneukum@suse.com>
---
drivers/net/wireless/zydas/zd1211rw/zd_mac.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/zydas/zd1211rw/zd_mac.c b/drivers/net/wireless/zydas/zd1211rw/zd_mac.c
index da7e63fca9f5..a9999d10ae81 100644
--- a/drivers/net/wireless/zydas/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zydas/zd1211rw/zd_mac.c
@@ -223,7 +223,6 @@ void zd_mac_clear(struct zd_mac *mac)
{
flush_workqueue(zd_workqueue);
zd_chip_clear(&mac->chip);
- lockdep_assert_held(&mac->lock);
ZD_MEMCLEAR(mac, sizeof(struct zd_mac));
}
--
2.16.4
^ permalink raw reply related
* Re: KASAN: slab-out-of-bounds Read in p54u_load_firmware_cb
From: Andrey Konovalov @ 2019-08-13 13:27 UTC (permalink / raw)
Cc: syzbot, Christian Lamparter, David S. Miller, Kalle Valo,
Kernel development list, USB list, linux-wireless, netdev,
syzkaller-bugs, Alan Stern
In-Reply-To: <Pine.LNX.4.44L0.1906201544001.1346-100000@iolanthe.rowland.org>
On Thu, Jun 20, 2019 at 9:46 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Wed, 19 Jun 2019, syzbot wrote:
>
> > syzbot has found a reproducer for the following crash on:
> >
> > HEAD commit: 9939f56e usb-fuzzer: main usb gadget fuzzer driver
> > git tree: https://github.com/google/kasan.git usb-fuzzer
> > console output: https://syzkaller.appspot.com/x/log.txt?x=135e29faa00000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=df134eda130bb43a
> > dashboard link: https://syzkaller.appspot.com/bug?extid=6d237e74cdc13f036473
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=175d946ea00000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+6d237e74cdc13f036473@syzkaller.appspotmail.com
> >
> > usb 3-1: Direct firmware load for isl3887usb failed with error -2
> > usb 3-1: Firmware not found.
> > ==================================================================
> > BUG: KASAN: slab-out-of-bounds in p54u_load_firmware_cb.cold+0x97/0x13d
> > drivers/net/wireless/intersil/p54/p54usb.c:936
> > Read of size 8 at addr ffff8881c9cf7588 by task kworker/1:5/2759
> >
> > CPU: 1 PID: 2759 Comm: kworker/1:5 Not tainted 5.2.0-rc5+ #11
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Workqueue: events request_firmware_work_func
> > Call Trace:
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0xca/0x13e lib/dump_stack.c:113
> > print_address_description+0x67/0x231 mm/kasan/report.c:188
> > __kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317
> > kasan_report+0xe/0x20 mm/kasan/common.c:614
> > p54u_load_firmware_cb.cold+0x97/0x13d
> > drivers/net/wireless/intersil/p54/p54usb.c:936
> > request_firmware_work_func+0x126/0x242
> > drivers/base/firmware_loader/main.c:785
> > process_one_work+0x905/0x1570 kernel/workqueue.c:2269
> > worker_thread+0x96/0xe20 kernel/workqueue.c:2415
> > kthread+0x30b/0x410 kernel/kthread.c:255
> > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
> >
> > Allocated by task 1612:
> > save_stack+0x1b/0x80 mm/kasan/common.c:71
> > set_track mm/kasan/common.c:79 [inline]
> > __kasan_kmalloc mm/kasan/common.c:489 [inline]
> > __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:462
> > kmalloc include/linux/slab.h:547 [inline]
> > syslog_print kernel/printk/printk.c:1346 [inline]
> > do_syslog kernel/printk/printk.c:1519 [inline]
> > do_syslog+0x4f4/0x12e0 kernel/printk/printk.c:1493
> > kmsg_read+0x8a/0xb0 fs/proc/kmsg.c:40
> > proc_reg_read+0x1c1/0x280 fs/proc/inode.c:221
> > __vfs_read+0x76/0x100 fs/read_write.c:425
> > vfs_read+0x18e/0x3d0 fs/read_write.c:461
> > ksys_read+0x127/0x250 fs/read_write.c:587
> > do_syscall_64+0xb7/0x560 arch/x86/entry/common.c:301
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > Freed by task 1612:
> > save_stack+0x1b/0x80 mm/kasan/common.c:71
> > set_track mm/kasan/common.c:79 [inline]
> > __kasan_slab_free+0x130/0x180 mm/kasan/common.c:451
> > slab_free_hook mm/slub.c:1421 [inline]
> > slab_free_freelist_hook mm/slub.c:1448 [inline]
> > slab_free mm/slub.c:2994 [inline]
> > kfree+0xd7/0x280 mm/slub.c:3949
> > syslog_print kernel/printk/printk.c:1405 [inline]
> > do_syslog kernel/printk/printk.c:1519 [inline]
> > do_syslog+0xff3/0x12e0 kernel/printk/printk.c:1493
> > kmsg_read+0x8a/0xb0 fs/proc/kmsg.c:40
> > proc_reg_read+0x1c1/0x280 fs/proc/inode.c:221
> > __vfs_read+0x76/0x100 fs/read_write.c:425
> > vfs_read+0x18e/0x3d0 fs/read_write.c:461
> > ksys_read+0x127/0x250 fs/read_write.c:587
> > do_syscall_64+0xb7/0x560 arch/x86/entry/common.c:301
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > The buggy address belongs to the object at ffff8881c9cf7180
> > which belongs to the cache kmalloc-1k of size 1024
> > The buggy address is located 8 bytes to the right of
> > 1024-byte region [ffff8881c9cf7180, ffff8881c9cf7580)
> > The buggy address belongs to the page:
> > page:ffffea0007273d00 refcount:1 mapcount:0 mapping:ffff8881dac02a00
> > index:0x0 compound_mapcount: 0
> > flags: 0x200000000010200(slab|head)
> > raw: 0200000000010200 dead000000000100 dead000000000200 ffff8881dac02a00
> > raw: 0000000000000000 00000000000e000e 00000001ffffffff 0000000000000000
> > page dumped because: kasan: bad access detected
> >
> > Memory state around the buggy address:
> > ffff8881c9cf7480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ffff8881c9cf7500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > > ffff8881c9cf7580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ^
> > ffff8881c9cf7600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ffff8881c9cf7680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ==================================================================
>
> Isn't this the same as syzkaller bug 200d4bb11b23d929335f ? Doesn't
> the same patch fix it?
#syz dup: KASAN: use-after-free Read in p54u_load_firmware_cb
^ permalink raw reply
* [PATCH 5.3] mt76: mt76x0e: don't use hw encryption for MT7630E
From: Stanislaw Gruszka @ 2019-08-13 13:36 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Roy Luo
Since 41634aa8d6db ("mt76: only schedule txqs from the tx tasklet")
I can observe firmware hangs on MT7630E on station mode: tx stop
functioning after minor activity (rx keep working) and on module
unload device fail to stop with messages:
[ 5446.141413] mt76x0e 0000:06:00.0: TX DMA did not stop
[ 5449.176764] mt76x0e 0000:06:00.0: TX DMA did not stop
Loading module again results in failure to associate with AP.
Only machine power off / power on cycle can make device work again.
It's unclear why commit 41634aa8d6db causes the problem, but it is
related to HW encryption. Since issue is a firmware hang, that is super
hard to debug, just disable HW encryption as fix for the issue.
Fixes: 41634aa8d6db ("mt76: only schedule txqs from the tx tasklet")
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/mediatek/mt76/mt76x0/pci.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
index 4585e1b756c2..6117e6ca08cb 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
@@ -62,6 +62,19 @@ static void mt76x0e_stop(struct ieee80211_hw *hw)
mt76x0e_stop_hw(dev);
}
+static int
+mt76x0e_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
+ struct ieee80211_vif *vif, struct ieee80211_sta *sta,
+ struct ieee80211_key_conf *key)
+{
+ struct mt76x02_dev *dev = hw->priv;
+
+ if (is_mt7630(dev))
+ return -EOPNOTSUPP;
+
+ return mt76x02_set_key(hw, cmd, vif, sta, key);
+}
+
static void
mt76x0e_flush(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
u32 queues, bool drop)
@@ -78,7 +91,7 @@ static void mt76x0e_stop(struct ieee80211_hw *hw)
.configure_filter = mt76x02_configure_filter,
.bss_info_changed = mt76x02_bss_info_changed,
.sta_state = mt76_sta_state,
- .set_key = mt76x02_set_key,
+ .set_key = mt76x0e_set_key,
.conf_tx = mt76x02_conf_tx,
.sw_scan_start = mt76x02_sw_scan,
.sw_scan_complete = mt76x02_sw_scan_complete,
--
1.9.3
^ permalink raw reply related
* Re: [EXT] INFO: trying to register non-static key in del_timer_sync (2)
From: Andrey Konovalov @ 2019-08-13 13:36 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: Dmitry Vyukov, syzbot, amitkarwar@gmail.com, davem@davemloft.net,
huxinming820@gmail.com, kvalo@codeaurora.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
nishants@marvell.com, syzkaller-bugs@googlegroups.com
In-Reply-To: <MN2PR18MB263710E8F1F8FFA06B2EDB3CA0EC0@MN2PR18MB2637.namprd18.prod.outlook.com>
On Wed, Jun 12, 2019 at 6:03 PM Ganapathi Bhat <gbhat@marvell.com> wrote:
>
> Hi Dmitry,
>
> We have a patch to fix this: https://patchwork.kernel.org/patch/10990275/
Hi Ganapathi,
Has this patch been accepted anywhere? This bug is still open on syzbot.
Thanks!
^ permalink raw reply
* [PATCH 5.3] mt76: mt76x0e: disable 5GHz band for MT7630E
From: Stanislaw Gruszka @ 2019-08-13 13:36 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Roy Luo
MT7630E hardware does support 5GHz, but we do not properly configure phy
for 5GHz channels. Scanning at this band not only do not show any APs
but also can hang the firmware.
Since vendor reference driver do not support 5GHz we don't know how
properly configure 5GHz channels. So disable this band for MT7630E .
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c b/drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c
index ab6dfc026acb..36918b1bd653 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c
@@ -67,6 +67,11 @@ static void mt76x0_set_chip_cap(struct mt76x02_dev *dev)
dev_dbg(dev->mt76.dev, "mask out 2GHz support\n");
}
+ if (is_mt7630(dev)) {
+ dev->mt76.cap.has_5ghz = false;
+ dev_dbg(dev->mt76.dev, "mask out 5GHz support\n");
+ }
+
if (!mt76x02_field_valid(nic_conf1 & 0xff))
nic_conf1 &= 0xff00;
--
1.9.3
^ permalink raw reply related
* Re: [EXT] INFO: trying to register non-static key in del_timer_sync (2)
From: Kalle Valo @ 2019-08-13 13:58 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Ganapathi Bhat, Dmitry Vyukov, syzbot, amitkarwar@gmail.com,
davem@davemloft.net, huxinming820@gmail.com,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
nishants@marvell.com, syzkaller-bugs@googlegroups.com
In-Reply-To: <CAAeHK+z8MBNikw_x50Crf8ZhOhcF=uvPHakvBx44K77xHRUNfg@mail.gmail.com>
Andrey Konovalov <andreyknvl@google.com> writes:
> On Wed, Jun 12, 2019 at 6:03 PM Ganapathi Bhat <gbhat@marvell.com> wrote:
>>
>> Hi Dmitry,
>>
>> We have a patch to fix this: https://patchwork.kernel.org/patch/10990275/
>
> Hi Ganapathi,
>
> Has this patch been accepted anywhere? This bug is still open on syzbot.
The patch is in "Changes Requested" state which means that the author is
supposed to send a new version based on the review comments.
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH AUTOSEL 5.2 053/123] mac80211_hwsim: Fix possible null-pointer dereferences in hwsim_dump_radio_nl()
From: Sasha Levin @ 2019-08-14 2:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jia-Ju Bai, Johannes Berg, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190814021047.14828-1-sashal@kernel.org>
From: Jia-Ju Bai <baijiaju1990@gmail.com>
[ Upstream commit b55f3b841099e641bdb2701d361a4c304e2dbd6f ]
In hwsim_dump_radio_nl(), when genlmsg_put() on line 3617 fails, hdr is
assigned to NULL. Then hdr is used on lines 3622 and 3623:
genl_dump_check_consistent(cb, hdr);
genlmsg_end(skb, hdr);
Thus, possible null-pointer dereferences may occur.
To fix these bugs, hdr is used here when it is not NULL.
This bug is found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Link: https://lore.kernel.org/r/20190729082332.28895-1-baijiaju1990@gmail.com
[put braces on all branches]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mac80211_hwsim.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 1c699a9fa8661..faec05ab42754 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3615,10 +3615,12 @@ static int hwsim_dump_radio_nl(struct sk_buff *skb,
hdr = genlmsg_put(skb, NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq, &hwsim_genl_family,
NLM_F_MULTI, HWSIM_CMD_GET_RADIO);
- if (!hdr)
+ if (hdr) {
+ genl_dump_check_consistent(cb, hdr);
+ genlmsg_end(skb, hdr);
+ } else {
res = -EMSGSIZE;
- genl_dump_check_consistent(cb, hdr);
- genlmsg_end(skb, hdr);
+ }
}
done:
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 062/123] iwlwifi: mvm: avoid races in rate init and rate perform
From: Sasha Levin @ 2019-08-14 2:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Mordechay Goodstein, Luca Coelho, Johannes Berg, Sasha Levin,
linux-wireless, netdev
In-Reply-To: <20190814021047.14828-1-sashal@kernel.org>
From: Mordechay Goodstein <mordechay.goodstein@intel.com>
[ Upstream commit 0f8084cdc1f9d4a6693ef4168167febb0918c6f6 ]
Rate perform uses the lq_sta table to calculate the next rate to scale
while rate init resets the same table,
Rate perform is done in soft irq context in parallel to rate init
that can be called in case we are doing changes like AP changes BW
or moving state for auth to assoc.
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 42 ++++++++++++++++++--
drivers/net/wireless/intel/iwlwifi/mvm/rs.h | 7 +++-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 6 +++
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 1 +
4 files changed, 51 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
index 63fdb4e68e9d7..836541caa3167 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
@@ -1197,6 +1197,27 @@ static u8 rs_get_tid(struct ieee80211_hdr *hdr)
return tid;
}
+void iwl_mvm_rs_init_wk(struct work_struct *wk)
+{
+ struct iwl_mvm_sta *mvmsta = container_of(wk, struct iwl_mvm_sta,
+ rs_init_wk);
+ struct iwl_mvm_vif *mvmvif = iwl_mvm_vif_from_mac80211(mvmsta->vif);
+ struct ieee80211_sta *sta;
+
+ rcu_read_lock();
+
+ sta = rcu_dereference(mvmvif->mvm->fw_id_to_mac_id[mvmsta->sta_id]);
+ if (WARN_ON_ONCE(IS_ERR_OR_NULL(sta))) {
+ rcu_read_unlock();
+ return;
+ }
+
+ iwl_mvm_rs_rate_init(mvmvif->mvm, sta, mvmvif->phy_ctxt->channel->band,
+ true);
+
+ rcu_read_unlock();
+}
+
void iwl_mvm_rs_tx_status(struct iwl_mvm *mvm, struct ieee80211_sta *sta,
int tid, struct ieee80211_tx_info *info, bool ndp)
{
@@ -1269,7 +1290,7 @@ void iwl_mvm_rs_tx_status(struct iwl_mvm *mvm, struct ieee80211_sta *sta,
(unsigned long)(lq_sta->last_tx +
(IWL_MVM_RS_IDLE_TIMEOUT * HZ)))) {
IWL_DEBUG_RATE(mvm, "Tx idle for too long. reinit rs\n");
- iwl_mvm_rs_rate_init(mvm, sta, info->band, true);
+ schedule_work(&mvmsta->rs_init_wk);
return;
}
lq_sta->last_tx = jiffies;
@@ -1442,16 +1463,24 @@ static void rs_drv_mac80211_tx_status(void *mvm_r,
struct iwl_op_mode *op_mode = mvm_r;
struct iwl_mvm *mvm = IWL_OP_MODE_GET_MVM(op_mode);
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ struct iwl_mvm_sta *mvmsta = iwl_mvm_sta_from_mac80211(sta);
- if (!iwl_mvm_sta_from_mac80211(sta)->vif)
+ if (!mvmsta->vif)
return;
if (!ieee80211_is_data(hdr->frame_control) ||
info->flags & IEEE80211_TX_CTL_NO_ACK)
return;
+ /* If it's locked we are in middle of init flow
+ * just wait for next tx status to update the lq_sta data
+ */
+ if (!mutex_trylock(&mvmsta->lq_sta.rs_drv.mutex))
+ return;
+
iwl_mvm_rs_tx_status(mvm, sta, rs_get_tid(hdr), info,
ieee80211_is_qos_nullfunc(hdr->frame_control));
+ mutex_unlock(&mvmsta->lq_sta.rs_drv.mutex);
}
/*
@@ -4136,10 +4165,15 @@ static const struct rate_control_ops rs_mvm_ops_drv = {
void iwl_mvm_rs_rate_init(struct iwl_mvm *mvm, struct ieee80211_sta *sta,
enum nl80211_band band, bool update)
{
- if (iwl_mvm_has_tlc_offload(mvm))
+ if (iwl_mvm_has_tlc_offload(mvm)) {
rs_fw_rate_init(mvm, sta, band, update);
- else
+ } else {
+ struct iwl_mvm_sta *mvmsta = iwl_mvm_sta_from_mac80211(sta);
+
+ mutex_lock(&mvmsta->lq_sta.rs_drv.mutex);
rs_drv_rate_init(mvm, sta, band, update);
+ mutex_unlock(&mvmsta->lq_sta.rs_drv.mutex);
+ }
}
int iwl_mvm_rate_control_register(void)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rs.h b/drivers/net/wireless/intel/iwlwifi/mvm/rs.h
index f7eb60dbaf202..086f47e2a4f0c 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rs.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs.h
@@ -4,7 +4,7 @@
* Copyright(c) 2003 - 2014 Intel Corporation. All rights reserved.
* Copyright(c) 2015 Intel Mobile Communications GmbH
* Copyright(c) 2017 Intel Deutschland GmbH
- * Copyright(c) 2018 Intel Corporation
+ * Copyright(c) 2018 - 2019 Intel Corporation
*
* Contact Information:
* Intel Linux Wireless <linuxwifi@intel.com>
@@ -376,6 +376,9 @@ struct iwl_lq_sta {
/* tx power reduce for this sta */
int tpc_reduce;
+ /* avoid races of reinit and update table from rx_tx */
+ struct mutex mutex;
+
/* persistent fields - initialized only once - keep last! */
struct lq_sta_pers {
#ifdef CONFIG_MAC80211_DEBUGFS
@@ -440,6 +443,8 @@ struct iwl_mvm_sta;
int iwl_mvm_tx_protection(struct iwl_mvm *mvm, struct iwl_mvm_sta *mvmsta,
bool enable);
+void iwl_mvm_rs_init_wk(struct work_struct *wk);
+
#ifdef CONFIG_IWLWIFI_DEBUGFS
void iwl_mvm_reset_frame_stats(struct iwl_mvm *mvm);
#endif
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
index f545a737a92df..ac9bc65c4d156 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -1684,6 +1684,10 @@ int iwl_mvm_add_sta(struct iwl_mvm *mvm,
*/
if (iwl_mvm_has_tlc_offload(mvm))
iwl_mvm_rs_add_sta(mvm, mvm_sta);
+ else
+ mutex_init(&mvm_sta->lq_sta.rs_drv.mutex);
+
+ INIT_WORK(&mvm_sta->rs_init_wk, iwl_mvm_rs_init_wk);
iwl_mvm_toggle_tx_ant(mvm, &mvm_sta->tx_ant);
@@ -1846,6 +1850,8 @@ int iwl_mvm_rm_sta(struct iwl_mvm *mvm,
if (ret)
return ret;
+ cancel_work_sync(&mvm_sta->rs_init_wk);
+
/* flush its queues here since we are freeing mvm_sta */
ret = iwl_mvm_flush_sta(mvm, mvm_sta, false, 0);
if (ret)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.h b/drivers/net/wireless/intel/iwlwifi/mvm/sta.h
index b4d4071b865db..6e93c30492b78 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.h
@@ -421,6 +421,7 @@ struct iwl_mvm_sta {
struct iwl_lq_sta_rs_fw rs_fw;
struct iwl_lq_sta rs_drv;
} lq_sta;
+ struct work_struct rs_init_wk;
struct ieee80211_vif *vif;
struct iwl_mvm_key_pn __rcu *ptk_pn[4];
struct iwl_mvm_rxq_dup_data *dup_data;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 065/123] iwlwifi: fix locking in delayed GTK setting
From: Sasha Levin @ 2019-08-14 2:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Johannes Berg, Luca Coelho, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190814021047.14828-1-sashal@kernel.org>
From: Johannes Berg <johannes.berg@intel.com>
[ Upstream commit 6569e7d36773956298ec1d5f4e6a2487913d2752 ]
This code clearly never could have worked, since it locks
while already locked. Add an unlocked __iwl_mvm_mac_set_key()
variant that doesn't do locking to fix that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../net/wireless/intel/iwlwifi/mvm/mac80211.c | 39 ++++++++++++-------
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 964c7baabede3..edffae3741e00 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -207,11 +207,11 @@ static const struct cfg80211_pmsr_capabilities iwl_mvm_pmsr_capa = {
},
};
-static int iwl_mvm_mac_set_key(struct ieee80211_hw *hw,
- enum set_key_cmd cmd,
- struct ieee80211_vif *vif,
- struct ieee80211_sta *sta,
- struct ieee80211_key_conf *key);
+static int __iwl_mvm_mac_set_key(struct ieee80211_hw *hw,
+ enum set_key_cmd cmd,
+ struct ieee80211_vif *vif,
+ struct ieee80211_sta *sta,
+ struct ieee80211_key_conf *key);
void iwl_mvm_ref(struct iwl_mvm *mvm, enum iwl_mvm_ref_type ref_type)
{
@@ -2725,7 +2725,7 @@ static int iwl_mvm_start_ap_ibss(struct ieee80211_hw *hw,
mvmvif->ap_early_keys[i] = NULL;
- ret = iwl_mvm_mac_set_key(hw, SET_KEY, vif, NULL, key);
+ ret = __iwl_mvm_mac_set_key(hw, SET_KEY, vif, NULL, key);
if (ret)
goto out_quota_failed;
}
@@ -3493,11 +3493,11 @@ static int iwl_mvm_mac_sched_scan_stop(struct ieee80211_hw *hw,
return ret;
}
-static int iwl_mvm_mac_set_key(struct ieee80211_hw *hw,
- enum set_key_cmd cmd,
- struct ieee80211_vif *vif,
- struct ieee80211_sta *sta,
- struct ieee80211_key_conf *key)
+static int __iwl_mvm_mac_set_key(struct ieee80211_hw *hw,
+ enum set_key_cmd cmd,
+ struct ieee80211_vif *vif,
+ struct ieee80211_sta *sta,
+ struct ieee80211_key_conf *key)
{
struct iwl_mvm_vif *mvmvif = iwl_mvm_vif_from_mac80211(vif);
struct iwl_mvm *mvm = IWL_MAC80211_GET_MVM(hw);
@@ -3552,8 +3552,6 @@ static int iwl_mvm_mac_set_key(struct ieee80211_hw *hw,
return -EOPNOTSUPP;
}
- mutex_lock(&mvm->mutex);
-
switch (cmd) {
case SET_KEY:
if ((vif->type == NL80211_IFTYPE_ADHOC ||
@@ -3699,7 +3697,22 @@ static int iwl_mvm_mac_set_key(struct ieee80211_hw *hw,
ret = -EINVAL;
}
+ return ret;
+}
+
+static int iwl_mvm_mac_set_key(struct ieee80211_hw *hw,
+ enum set_key_cmd cmd,
+ struct ieee80211_vif *vif,
+ struct ieee80211_sta *sta,
+ struct ieee80211_key_conf *key)
+{
+ struct iwl_mvm *mvm = IWL_MAC80211_GET_MVM(hw);
+ int ret;
+
+ mutex_lock(&mvm->mutex);
+ ret = __iwl_mvm_mac_set_key(hw, cmd, vif, sta, key);
mutex_unlock(&mvm->mutex);
+
return ret;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 24/68] mac80211_hwsim: Fix possible null-pointer dereferences in hwsim_dump_radio_nl()
From: Sasha Levin @ 2019-08-14 2:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jia-Ju Bai, Johannes Berg, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190814021548.16001-1-sashal@kernel.org>
From: Jia-Ju Bai <baijiaju1990@gmail.com>
[ Upstream commit b55f3b841099e641bdb2701d361a4c304e2dbd6f ]
In hwsim_dump_radio_nl(), when genlmsg_put() on line 3617 fails, hdr is
assigned to NULL. Then hdr is used on lines 3622 and 3623:
genl_dump_check_consistent(cb, hdr);
genlmsg_end(skb, hdr);
Thus, possible null-pointer dereferences may occur.
To fix these bugs, hdr is used here when it is not NULL.
This bug is found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Link: https://lore.kernel.org/r/20190729082332.28895-1-baijiaju1990@gmail.com
[put braces on all branches]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mac80211_hwsim.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 7cd428c0af433..ce2dd06af62e8 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3502,10 +3502,12 @@ static int hwsim_dump_radio_nl(struct sk_buff *skb,
hdr = genlmsg_put(skb, NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq, &hwsim_genl_family,
NLM_F_MULTI, HWSIM_CMD_GET_RADIO);
- if (!hdr)
+ if (hdr) {
+ genl_dump_check_consistent(cb, hdr);
+ genlmsg_end(skb, hdr);
+ } else {
res = -EMSGSIZE;
- genl_dump_check_consistent(cb, hdr);
- genlmsg_end(skb, hdr);
+ }
}
done:
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 066/123] iwlwifi: mvm: send LQ command always ASYNC
From: Sasha Levin @ 2019-08-14 2:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Gregory Greenman, Luca Coelho, Johannes Berg, Sasha Levin,
linux-wireless, netdev
In-Reply-To: <20190814021047.14828-1-sashal@kernel.org>
From: Gregory Greenman <gregory.greenman@intel.com>
[ Upstream commit cd4d6b0bcd51580efda9ae54ab7b2d630b4147dc ]
The only place where the command was sent as SYNC is during
init and this is not really critical. This change is required
for replacing RS mutex with a spinlock (in the subsequent patch),
since SYNC comamnd requres sleeping and thus the flow cannot
be done when holding a spinlock.
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 23 ++++++++++---------
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 2 +-
.../net/wireless/intel/iwlwifi/mvm/utils.c | 4 ++--
4 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
index 88af1f0ba3f0f..31c8636b2a3f8 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
@@ -1806,7 +1806,7 @@ iwl_mvm_vif_dbgfs_clean(struct iwl_mvm *mvm, struct ieee80211_vif *vif)
#endif /* CONFIG_IWLWIFI_DEBUGFS */
/* rate scaling */
-int iwl_mvm_send_lq_cmd(struct iwl_mvm *mvm, struct iwl_lq_cmd *lq, bool sync);
+int iwl_mvm_send_lq_cmd(struct iwl_mvm *mvm, struct iwl_lq_cmd *lq);
void iwl_mvm_update_frame_stats(struct iwl_mvm *mvm, u32 rate, bool agg);
int rs_pretty_print_rate(char *buf, int bufsz, const u32 rate);
void rs_update_last_rssi(struct iwl_mvm *mvm,
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
index 836541caa3167..01b032f18bc8b 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
@@ -1326,7 +1326,7 @@ void iwl_mvm_rs_tx_status(struct iwl_mvm *mvm, struct ieee80211_sta *sta,
IWL_DEBUG_RATE(mvm,
"Too many rates mismatch. Send sync LQ. rs_state %d\n",
lq_sta->rs_state);
- iwl_mvm_send_lq_cmd(mvm, &lq_sta->lq, false);
+ iwl_mvm_send_lq_cmd(mvm, &lq_sta->lq);
}
/* Regardless, ignore this status info for outdated rate */
return;
@@ -1388,7 +1388,8 @@ void iwl_mvm_rs_tx_status(struct iwl_mvm *mvm, struct ieee80211_sta *sta,
if (info->status.ampdu_ack_len == 0)
info->status.ampdu_len = 1;
- rs_collect_tlc_data(mvm, mvmsta, tid, curr_tbl, tx_resp_rate.index,
+ rs_collect_tlc_data(mvm, mvmsta, tid, curr_tbl,
+ tx_resp_rate.index,
info->status.ampdu_len,
info->status.ampdu_ack_len);
@@ -1823,7 +1824,7 @@ static void rs_update_rate_tbl(struct iwl_mvm *mvm,
struct iwl_scale_tbl_info *tbl)
{
rs_fill_lq_cmd(mvm, sta, lq_sta, &tbl->rate);
- iwl_mvm_send_lq_cmd(mvm, &lq_sta->lq, false);
+ iwl_mvm_send_lq_cmd(mvm, &lq_sta->lq);
}
static bool rs_tweak_rate_tbl(struct iwl_mvm *mvm,
@@ -2925,7 +2926,7 @@ void rs_update_last_rssi(struct iwl_mvm *mvm,
static void rs_initialize_lq(struct iwl_mvm *mvm,
struct ieee80211_sta *sta,
struct iwl_lq_sta *lq_sta,
- enum nl80211_band band, bool update)
+ enum nl80211_band band)
{
struct iwl_scale_tbl_info *tbl;
struct rs_rate *rate;
@@ -2955,7 +2956,7 @@ static void rs_initialize_lq(struct iwl_mvm *mvm,
rs_set_expected_tpt_table(lq_sta, tbl);
rs_fill_lq_cmd(mvm, sta, lq_sta, rate);
/* TODO restore station should remember the lq cmd */
- iwl_mvm_send_lq_cmd(mvm, &lq_sta->lq, !update);
+ iwl_mvm_send_lq_cmd(mvm, &lq_sta->lq);
}
static void rs_drv_get_rate(void *mvm_r, struct ieee80211_sta *sta,
@@ -3208,7 +3209,7 @@ void iwl_mvm_update_frame_stats(struct iwl_mvm *mvm, u32 rate, bool agg)
* Called after adding a new station to initialize rate scaling
*/
static void rs_drv_rate_init(struct iwl_mvm *mvm, struct ieee80211_sta *sta,
- enum nl80211_band band, bool update)
+ enum nl80211_band band)
{
int i, j;
struct ieee80211_hw *hw = mvm->hw;
@@ -3288,7 +3289,7 @@ static void rs_drv_rate_init(struct iwl_mvm *mvm, struct ieee80211_sta *sta,
#ifdef CONFIG_IWLWIFI_DEBUGFS
iwl_mvm_reset_frame_stats(mvm);
#endif
- rs_initialize_lq(mvm, sta, lq_sta, band, update);
+ rs_initialize_lq(mvm, sta, lq_sta, band);
}
static void rs_drv_rate_update(void *mvm_r,
@@ -3602,7 +3603,7 @@ static void rs_set_lq_ss_params(struct iwl_mvm *mvm,
bfersta_ss_params &= ~LQ_SS_BFER_ALLOWED;
bfersta_lq_cmd->ss_params = cpu_to_le32(bfersta_ss_params);
- iwl_mvm_send_lq_cmd(mvm, bfersta_lq_cmd, false);
+ iwl_mvm_send_lq_cmd(mvm, bfersta_lq_cmd);
ss_params |= LQ_SS_BFER_ALLOWED;
IWL_DEBUG_RATE(mvm,
@@ -3768,7 +3769,7 @@ static void rs_program_fix_rate(struct iwl_mvm *mvm,
if (lq_sta->pers.dbg_fixed_rate) {
rs_fill_lq_cmd(mvm, NULL, lq_sta, NULL);
- iwl_mvm_send_lq_cmd(lq_sta->pers.drv, &lq_sta->lq, false);
+ iwl_mvm_send_lq_cmd(lq_sta->pers.drv, &lq_sta->lq);
}
}
@@ -4171,7 +4172,7 @@ void iwl_mvm_rs_rate_init(struct iwl_mvm *mvm, struct ieee80211_sta *sta,
struct iwl_mvm_sta *mvmsta = iwl_mvm_sta_from_mac80211(sta);
mutex_lock(&mvmsta->lq_sta.rs_drv.mutex);
- rs_drv_rate_init(mvm, sta, band, update);
+ rs_drv_rate_init(mvm, sta, band);
mutex_unlock(&mvmsta->lq_sta.rs_drv.mutex);
}
}
@@ -4203,7 +4204,7 @@ static int rs_drv_tx_protection(struct iwl_mvm *mvm, struct iwl_mvm_sta *mvmsta,
lq->flags &= ~LQ_FLAG_USE_RTS_MSK;
}
- return iwl_mvm_send_lq_cmd(mvm, lq, false);
+ return iwl_mvm_send_lq_cmd(mvm, lq);
}
/**
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
index ac9bc65c4d156..22715cdb83171 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -2978,7 +2978,7 @@ int iwl_mvm_sta_tx_agg_oper(struct iwl_mvm *mvm, struct ieee80211_vif *vif,
IWL_DEBUG_HT(mvm, "Tx aggregation enabled on ra = %pM tid = %d\n",
sta->addr, tid);
- return iwl_mvm_send_lq_cmd(mvm, &mvmsta->lq_sta.rs_drv.lq, false);
+ return iwl_mvm_send_lq_cmd(mvm, &mvmsta->lq_sta.rs_drv.lq);
}
static void iwl_mvm_unreserve_agg_queue(struct iwl_mvm *mvm,
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/utils.c b/drivers/net/wireless/intel/iwlwifi/mvm/utils.c
index cc56ab88fb439..a71277de2e0eb 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/utils.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/utils.c
@@ -641,12 +641,12 @@ int iwl_mvm_reconfig_scd(struct iwl_mvm *mvm, int queue, int fifo, int sta_id,
* this case to clear the state indicating that station creation is in
* progress.
*/
-int iwl_mvm_send_lq_cmd(struct iwl_mvm *mvm, struct iwl_lq_cmd *lq, bool sync)
+int iwl_mvm_send_lq_cmd(struct iwl_mvm *mvm, struct iwl_lq_cmd *lq)
{
struct iwl_host_cmd cmd = {
.id = LQ_CMD,
.len = { sizeof(struct iwl_lq_cmd), },
- .flags = sync ? 0 : CMD_ASYNC,
+ .flags = CMD_ASYNC,
.data = { lq, },
};
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 063/123] iwlwifi: dbg_ini: move iwl_dbg_tlv_load_bin out of debug override ifdef
From: Sasha Levin @ 2019-08-14 2:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Shahar S Matityahu, Luca Coelho, Johannes Berg, Sasha Levin,
linux-wireless, netdev
In-Reply-To: <20190814021047.14828-1-sashal@kernel.org>
From: Shahar S Matityahu <shahar.s.matityahu@intel.com>
[ Upstream commit 072b30642f90b01d139131ec7bf763778a3a3f41 ]
ini debug mode should work even if debug override is not defined.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Fixes: 68f6f492c4fa ("iwlwifi: trans: support loading ini TLVs from external file")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
index fba242284507b..efd4bf04d0162 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
@@ -1627,6 +1627,8 @@ struct iwl_drv *iwl_drv_start(struct iwl_trans *trans)
init_completion(&drv->request_firmware_complete);
INIT_LIST_HEAD(&drv->list);
+ iwl_load_fw_dbg_tlv(drv->trans->dev, drv->trans);
+
#ifdef CONFIG_IWLWIFI_DEBUGFS
/* Create the device debugfs entries. */
drv->dbgfs_drv = debugfs_create_dir(dev_name(trans->dev),
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 064/123] iwlwifi: dbg_ini: move iwl_dbg_tlv_free outside of debugfs ifdef
From: Sasha Levin @ 2019-08-14 2:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Shahar S Matityahu, Luca Coelho, Johannes Berg, Sasha Levin,
linux-wireless, netdev
In-Reply-To: <20190814021047.14828-1-sashal@kernel.org>
From: Shahar S Matityahu <shahar.s.matityahu@intel.com>
[ Upstream commit abcbef5977df1fb61026ba429964cd6b9a085699 ]
The driver should call iwl_dbg_tlv_free even if debugfs is not defined
since ini mode does not depend on debugfs ifdef.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Fixes: 68f6f492c4fa ("iwlwifi: trans: support loading ini TLVs from external file")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
index efd4bf04d0162..fa81ad67539f3 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
@@ -1649,8 +1649,8 @@ struct iwl_drv *iwl_drv_start(struct iwl_trans *trans)
err_fw:
#ifdef CONFIG_IWLWIFI_DEBUGFS
debugfs_remove_recursive(drv->dbgfs_drv);
- iwl_fw_dbg_free(drv->trans);
#endif
+ iwl_fw_dbg_free(drv->trans);
kfree(drv);
err:
return ERR_PTR(ret);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 045/123] {nl,mac}80211: fix interface combinations on crypto controlled devices
From: Sasha Levin @ 2019-08-14 2:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Manikanta Pubbisetty, Johannes Berg, Sasha Levin, linux-wireless,
netdev
In-Reply-To: <20190814021047.14828-1-sashal@kernel.org>
From: Manikanta Pubbisetty <mpubbise@codeaurora.org>
[ Upstream commit e6f4051123fd33901e9655a675b22aefcdc5d277 ]
Commit 33d915d9e8ce ("{nl,mac}80211: allow 4addr AP operation on
crypto controlled devices") has introduced a change which allows
4addr operation on crypto controlled devices (ex: ath10k). This
change has inadvertently impacted the interface combinations logic
on such devices.
General rule is that software interfaces like AP/VLAN should not be
listed under supported interface combinations and should not be
considered during validation of these combinations; because of the
aforementioned change, AP/VLAN interfaces(if present) will be checked
against interfaces supported by the device and blocks valid interface
combinations.
Consider a case where an AP and AP/VLAN are up and running; when a
second AP device is brought up on the same physical device, this AP
will be checked against the AP/VLAN interface (which will not be
part of supported interface combinations of the device) and blocks
second AP to come up.
Add a new API cfg80211_iftype_allowed() to fix the problem, this
API works for all devices with/without SW crypto control.
Signed-off-by: Manikanta Pubbisetty <mpubbise@codeaurora.org>
Fixes: 33d915d9e8ce ("{nl,mac}80211: allow 4addr AP operation on crypto controlled devices")
Link: https://lore.kernel.org/r/1563779690-9716-1-git-send-email-mpubbise@codeaurora.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/net/cfg80211.h | 15 +++++++++++++++
net/mac80211/util.c | 7 +++----
net/wireless/core.c | 6 ++----
net/wireless/nl80211.c | 4 +---
net/wireless/util.c | 27 +++++++++++++++++++++++++--
5 files changed, 46 insertions(+), 13 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 8fb5be3ca0ca8..8b13bd05befac 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -7254,6 +7254,21 @@ void cfg80211_pmsr_complete(struct wireless_dev *wdev,
struct cfg80211_pmsr_request *req,
gfp_t gfp);
+/**
+ * cfg80211_iftype_allowed - check whether the interface can be allowed
+ * @wiphy: the wiphy
+ * @iftype: interface type
+ * @is_4addr: use_4addr flag, must be '0' when check_swif is '1'
+ * @check_swif: check iftype against software interfaces
+ *
+ * Check whether the interface is allowed to operate; additionally, this API
+ * can be used to check iftype against the software interfaces when
+ * check_swif is '1'.
+ */
+bool cfg80211_iftype_allowed(struct wiphy *wiphy, enum nl80211_iftype iftype,
+ bool is_4addr, u8 check_swif);
+
+
/* Logging, debugging and troubleshooting/diagnostic helpers. */
/* wiphy_printk helpers, similar to dev_printk */
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 1b224fa27367f..ad1e58184c4e4 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -3796,9 +3796,7 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata,
}
/* Always allow software iftypes */
- if (local->hw.wiphy->software_iftypes & BIT(iftype) ||
- (iftype == NL80211_IFTYPE_AP_VLAN &&
- local->hw.wiphy->flags & WIPHY_FLAG_4ADDR_AP)) {
+ if (cfg80211_iftype_allowed(local->hw.wiphy, iftype, 0, 1)) {
if (radar_detect)
return -EINVAL;
return 0;
@@ -3833,7 +3831,8 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata,
if (sdata_iter == sdata ||
!ieee80211_sdata_running(sdata_iter) ||
- local->hw.wiphy->software_iftypes & BIT(wdev_iter->iftype))
+ cfg80211_iftype_allowed(local->hw.wiphy,
+ wdev_iter->iftype, 0, 1))
continue;
params.iftype_num[wdev_iter->iftype]++;
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 53ad3dbb76fe5..ed24a0b071c33 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -1397,10 +1397,8 @@ static int cfg80211_netdev_notifier_call(struct notifier_block *nb,
}
break;
case NETDEV_PRE_UP:
- if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype)) &&
- !(wdev->iftype == NL80211_IFTYPE_AP_VLAN &&
- rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP &&
- wdev->use_4addr))
+ if (!cfg80211_iftype_allowed(wdev->wiphy, wdev->iftype,
+ wdev->use_4addr, 0))
return notifier_from_errno(-EOPNOTSUPP);
if (rfkill_blocked(rdev->rfkill))
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 520d437aa8d15..88a1de9def115 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -3481,9 +3481,7 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
return err;
}
- if (!(rdev->wiphy.interface_modes & (1 << type)) &&
- !(type == NL80211_IFTYPE_AP_VLAN && params.use_4addr &&
- rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP))
+ if (!cfg80211_iftype_allowed(&rdev->wiphy, type, params.use_4addr, 0))
return -EOPNOTSUPP;
err = nl80211_parse_mon_options(rdev, type, info, ¶ms);
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 1c39d6a2e8501..d0e35b7b9e350 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1697,7 +1697,7 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
for (iftype = 0; iftype < NUM_NL80211_IFTYPES; iftype++) {
num_interfaces += params->iftype_num[iftype];
if (params->iftype_num[iftype] > 0 &&
- !(wiphy->software_iftypes & BIT(iftype)))
+ !cfg80211_iftype_allowed(wiphy, iftype, 0, 1))
used_iftypes |= BIT(iftype);
}
@@ -1719,7 +1719,7 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
return -ENOMEM;
for (iftype = 0; iftype < NUM_NL80211_IFTYPES; iftype++) {
- if (wiphy->software_iftypes & BIT(iftype))
+ if (cfg80211_iftype_allowed(wiphy, iftype, 0, 1))
continue;
for (j = 0; j < c->n_limits; j++) {
all_iftypes |= limits[j].types;
@@ -2072,3 +2072,26 @@ int ieee80211_get_vht_max_nss(struct ieee80211_vht_cap *cap,
return max_vht_nss;
}
EXPORT_SYMBOL(ieee80211_get_vht_max_nss);
+
+bool cfg80211_iftype_allowed(struct wiphy *wiphy, enum nl80211_iftype iftype,
+ bool is_4addr, u8 check_swif)
+
+{
+ bool is_vlan = iftype == NL80211_IFTYPE_AP_VLAN;
+
+ switch (check_swif) {
+ case 0:
+ if (is_vlan && is_4addr)
+ return wiphy->flags & WIPHY_FLAG_4ADDR_AP;
+ return wiphy->interface_modes & BIT(iftype);
+ case 1:
+ if (!(wiphy->software_iftypes & BIT(iftype)) && is_vlan)
+ return wiphy->flags & WIPHY_FLAG_4ADDR_AP;
+ return wiphy->software_iftypes & BIT(iftype);
+ default:
+ break;
+ }
+
+ return false;
+}
+EXPORT_SYMBOL(cfg80211_iftype_allowed);
--
2.20.1
^ permalink raw reply related
* Re: Ap mode regression in linux-5.3-rc1 in rt2800usb
From: Stanislaw Gruszka @ 2019-08-14 8:50 UTC (permalink / raw)
To: Emil Karlson; +Cc: Kalle Valo, linux-wireless
In-Reply-To: <20190813215000.6cc27ade@lettuce>
(cc linux-wireless mailing list)
On Tue, Aug 13, 2019 at 09:50:00PM +0300, Emil Karlson wrote:
> Greetings
>
> After upgrading my ap running rt2800usb to linux-5.3-rc1 I noticed an
> unusual problem of not being able to connect to my ap with my android
> devices (nexus7/flo and nexus5x/bullhead), from tcpdump it seemed ap
> was receiving packets from the android devices after successful
> association, but android devices were not seeing the dhcp replies.
>
> I reverted drivers/net/wireless/ralink to the state it is in v5.2.8 and
> android clients can connect again normally. I did not explicitly set
> watchdog parameter to any value.
>
> Do you have any insights or is this already fixed?
Most likely is not fixed. We have those new commits in 5.3:
41a531ffa4c5 rt2x00usb: fix rx queue hang
0f47aeeada2a rt2800: do not enable watchdog by default
e403fa31ed71 rt2x00: add restart hw
710e6cc1595e rt2800: do not nullify initialization vector data
09db3b000619 rt2800: add pre_reset_hw callback
759c5b599cf4 rt2800: initial watchdog implementation
2034afe4db4a rt2800: add helpers for reading dma done index
9f3e3323e996 rt2x00: allow to specify watchdog interval
Most suspicious are 710e6cc1595e and 41a531ffa4c5 .
Could you test by reverting one single commit on 5.3
(first 710e6cc1595e and if that not help 41a531ffa4c5)
and check if it makes the problem gone?
Stanislaw
^ permalink raw reply
* Re: [PATCH 5.3] mt76: mt76x0e: disable 5GHz band for MT7630E
From: Stanislaw Gruszka @ 2019-08-14 8:54 UTC (permalink / raw)
To: Sasha Levin; +Cc: linux-wireless, Felix Fietkau, stable
In-Reply-To: <20190813175526.CCBC220840@mail.kernel.org>
On Tue, Aug 13, 2019 at 05:55:26PM +0000, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v5.2.8, v4.19.66, v4.14.138, v4.9.189, v4.4.189.
>
> v5.2.8: Build OK!
> v4.19.66: Failed to apply! Possible dependencies:
> 86c71d3deefa ("mt76: move eeprom utility routines in mt76x02_eeprom.h")
> d6500cf3700f ("mt76x0: add quirk to disable 2.4GHz band for Archer T1U")
> eef40d209ad0 ("mt76: move common eeprom definitions in mt76x02-lib module")
<snip>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
mt76x0e support was added in 4.20 , so it's fine just to apply this
commit in 5.2 .
Stanislaw
^ permalink raw reply
* Re: [PATCH 5.3] mt76: mt76x0e: don't use hw encryption for MT7630E
From: Lorenzo Bianconi @ 2019-08-14 9:50 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Felix Fietkau, Ryder Lee, Roy Luo
In-Reply-To: <1565703400-10623-1-git-send-email-sgruszka@redhat.com>
>
> Since 41634aa8d6db ("mt76: only schedule txqs from the tx tasklet")
> I can observe firmware hangs on MT7630E on station mode: tx stop
> functioning after minor activity (rx keep working) and on module
> unload device fail to stop with messages:
>
> [ 5446.141413] mt76x0e 0000:06:00.0: TX DMA did not stop
> [ 5449.176764] mt76x0e 0000:06:00.0: TX DMA did not stop
>
> Loading module again results in failure to associate with AP.
> Only machine power off / power on cycle can make device work again.
>
> It's unclear why commit 41634aa8d6db causes the problem, but it is
> related to HW encryption. Since issue is a firmware hang, that is super
> hard to debug, just disable HW encryption as fix for the issue.
>
> Fixes: 41634aa8d6db ("mt76: only schedule txqs from the tx tasklet")
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
> drivers/net/wireless/mediatek/mt76/mt76x0/pci.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
> index 4585e1b756c2..6117e6ca08cb 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
> @@ -62,6 +62,19 @@ static void mt76x0e_stop(struct ieee80211_hw *hw)
> mt76x0e_stop_hw(dev);
> }
>
> +static int
> +mt76x0e_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
> + struct ieee80211_vif *vif, struct ieee80211_sta *sta,
> + struct ieee80211_key_conf *key)
> +{
> + struct mt76x02_dev *dev = hw->priv;
> +
> + if (is_mt7630(dev))
> + return -EOPNOTSUPP;
Hi Stanislaw,
Can you please try if disabling/enabling the tx tasklet during hw key
configuration fixes the issue?
Doing something like:
tasklet_disable(tx_tasklet)
mt76x02_set_key()
tasklet_enable(tx_tasklet)
Moreover, have you double checked if there is any performance impact
of not using hw encryption?
If so, I guess it is better to just redefine mt76_wake_tx_queue for
mt76x0e and run mt76_txq_schedule for 7630e:
void mt76x0e_wake_tx_queue(struct ieee80211_hw *hw, struct ieee80211_txq *txq)
{
if (is_mt7630(dev)) {
mt76_txq_schedule(dev, txq->ac);
} else {
tasklet_schedule(&dev->tx_tasklet);
}
}
Regards,
Lorenzo
> +
> + return mt76x02_set_key(hw, cmd, vif, sta, key);
> +}
> +
> static void
> mt76x0e_flush(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
> u32 queues, bool drop)
> @@ -78,7 +91,7 @@ static void mt76x0e_stop(struct ieee80211_hw *hw)
> .configure_filter = mt76x02_configure_filter,
> .bss_info_changed = mt76x02_bss_info_changed,
> .sta_state = mt76_sta_state,
> - .set_key = mt76x02_set_key,
> + .set_key = mt76x0e_set_key,
> .conf_tx = mt76x02_conf_tx,
> .sw_scan_start = mt76x02_sw_scan,
> .sw_scan_complete = mt76x02_sw_scan_complete,
> --
> 1.9.3
>
^ permalink raw reply
* [PATCH] rtw88: Fix an error message
From: Dan Carpenter @ 2019-08-14 10:46 UTC (permalink / raw)
To: Yan-Hsuan Chuang; +Cc: Kalle Valo, linux-wireless, kernel-janitors
The WARN_ON() macro takes a condition, not a warning message. I've
changed this to use WARN() instead.
Fixes: 4136214f7c46 ("rtw88: add BT co-existence support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
drivers/net/wireless/realtek/rtw88/coex.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtw88/coex.c b/drivers/net/wireless/realtek/rtw88/coex.c
index 4577fceddc5e..13701ec40302 100644
--- a/drivers/net/wireless/realtek/rtw88/coex.c
+++ b/drivers/net/wireless/realtek/rtw88/coex.c
@@ -1059,7 +1059,7 @@ static void rtw_coex_set_ant_path(struct rtw_dev *rtwdev, bool force, u8 phase)
pos_type = COEX_SWITCH_TO_WLG_BT;
break;
default:
- WARN_ON("unknown phase when setting antenna path\n");
+ WARN(1, "unknown phase when setting antenna path\n");
return;
}
--
2.20.1
^ permalink raw reply related
* RE: [EXT] INFO: trying to register non-static key in del_timer_sync (2)
From: Ganapathi Bhat @ 2019-08-14 14:08 UTC (permalink / raw)
To: Kalle Valo, Andrey Konovalov
Cc: Dmitry Vyukov, syzbot, amitkarwar@gmail.com, davem@davemloft.net,
huxinming820@gmail.com, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, nishants@marvell.com,
syzkaller-bugs@googlegroups.com
In-Reply-To: <87k1bhb20j.fsf@kamboji.qca.qualcomm.com>
Hi Dmitry/Kalle,
> >>
> >> Hi Dmitry,
> >>
> >> We have a patch to fix this:
> >> https://patchwork.kernel.org/patch/10990275/
> >
> > Hi Ganapathi,
> >
> > Has this patch been accepted anywhere? This bug is still open on syzbot.
>
> The patch is in "Changes Requested" state which means that the author is
> supposed to send a new version based on the review comments.
We will address the review comments and try to push the updated version soon;
Regards,
Ganapathi
^ permalink raw reply
* Re: [PATCH 5.3] mt76: mt76x0e: don't use hw encryption for MT7630E
From: Stanislaw Gruszka @ 2019-08-15 10:09 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: linux-wireless, Felix Fietkau, Ryder Lee, Roy Luo
In-Reply-To: <CAJ0CqmXM4NRMYU6Lt_a4f+DXE2bVmhYrjQbgxHG0g=N+o3TeQw@mail.gmail.com>
On Wed, Aug 14, 2019 at 11:50:12AM +0200, Lorenzo Bianconi wrote:
> >
> > Since 41634aa8d6db ("mt76: only schedule txqs from the tx tasklet")
> > I can observe firmware hangs on MT7630E on station mode: tx stop
> > functioning after minor activity (rx keep working) and on module
> > unload device fail to stop with messages:
> >
> > [ 5446.141413] mt76x0e 0000:06:00.0: TX DMA did not stop
> > [ 5449.176764] mt76x0e 0000:06:00.0: TX DMA did not stop
> >
> > Loading module again results in failure to associate with AP.
> > Only machine power off / power on cycle can make device work again.
> >
> > It's unclear why commit 41634aa8d6db causes the problem, but it is
> > related to HW encryption. Since issue is a firmware hang, that is super
> > hard to debug, just disable HW encryption as fix for the issue.
> >
> > Fixes: 41634aa8d6db ("mt76: only schedule txqs from the tx tasklet")
> > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> > ---
> > drivers/net/wireless/mediatek/mt76/mt76x0/pci.c | 15 ++++++++++++++-
> > 1 file changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
> > index 4585e1b756c2..6117e6ca08cb 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
> > @@ -62,6 +62,19 @@ static void mt76x0e_stop(struct ieee80211_hw *hw)
> > mt76x0e_stop_hw(dev);
> > }
> >
> > +static int
> > +mt76x0e_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
> > + struct ieee80211_vif *vif, struct ieee80211_sta *sta,
> > + struct ieee80211_key_conf *key)
> > +{
> > + struct mt76x02_dev *dev = hw->priv;
> > +
> > + if (is_mt7630(dev))
> > + return -EOPNOTSUPP;
>
> Hi Stanislaw,
>
> Can you please try if disabling/enabling the tx tasklet during hw key
> configuration fixes the issue?
> Doing something like:
>
> tasklet_disable(tx_tasklet)
> mt76x02_set_key()
> tasklet_enable(tx_tasklet)
It does not help with the problem.
> Moreover, have you double checked if there is any performance impact
> of not using hw encryption?
I didn't observe any, but realized on this machine I have
aesni_intel encryption accelerator. After rebuild kernel without
CONFIG_CRYPTO_AES_NI_INTEL, 'perf top' showed extra 20% of cpu usage
in aes_encrypt() when sending data with HW encryption disabled.
> If so, I guess it is better to just redefine mt76_wake_tx_queue for
> mt76x0e and run mt76_txq_schedule for 7630e:
>
> void mt76x0e_wake_tx_queue(struct ieee80211_hw *hw, struct ieee80211_txq *txq)
> {
> if (is_mt7630(dev)) {
> mt76_txq_schedule(dev, txq->ac);
> } else {
> tasklet_schedule(&dev->tx_tasklet);
> }
> }
Not sure about reduction of lock contention for which the tx_tasklet
was introduced here, but looks ok for me as fix.
Stanislaw
^ permalink raw reply
* Re: [PATCH 5.3] mt76: mt76x0e: don't use hw encryption for MT7630E
From: Felix Fietkau @ 2019-08-15 10:20 UTC (permalink / raw)
To: Stanislaw Gruszka, Lorenzo Bianconi; +Cc: linux-wireless, Ryder Lee, Roy Luo
In-Reply-To: <20190815100936.GA21775@redhat.com>
On 2019-08-15 12:09, Stanislaw Gruszka wrote:
>> Hi Stanislaw,
>>
>> Can you please try if disabling/enabling the tx tasklet during hw key
>> configuration fixes the issue?
>> Doing something like:
>>
>> tasklet_disable(tx_tasklet)
>> mt76x02_set_key()
>> tasklet_enable(tx_tasklet)
>
> It does not help with the problem.
>
>> Moreover, have you double checked if there is any performance impact
>> of not using hw encryption?
>
> I didn't observe any, but realized on this machine I have
> aesni_intel encryption accelerator. After rebuild kernel without
> CONFIG_CRYPTO_AES_NI_INTEL, 'perf top' showed extra 20% of cpu usage
> in aes_encrypt() when sending data with HW encryption disabled.
>
>> If so, I guess it is better to just redefine mt76_wake_tx_queue for
>> mt76x0e and run mt76_txq_schedule for 7630e:
>>
>> void mt76x0e_wake_tx_queue(struct ieee80211_hw *hw, struct ieee80211_txq *txq)
>> {
>> if (is_mt7630(dev)) {
>> mt76_txq_schedule(dev, txq->ac);
>> } else {
>> tasklet_schedule(&dev->tx_tasklet);
>> }
>> }
>
> Not sure about reduction of lock contention for which the tx_tasklet
> was introduced here, but looks ok for me as fix.
I think if we work around the bug like this, it can easily come back to
bite us again later. I don't see any logical explanation as to how this
makes a difference with hardware encryption.
Also, I think it would be helpful to figure out what key operation (if
any) triggers this, adding or removing keys.
Maybe it could also help if we change the order in which the WCID table
entries are updated, i.e. changing MT_WCID_ATTR first when removing keys.
Maybe temporarily clearing MT_MAC_SYS_CTRL_ENABLE_TX before the key
update and setting it again afterwards could also help.
- Felix
^ permalink raw reply
* Re: [PULL] ath10k firmware 20190808
From: Josh Boyer @ 2019-08-15 11:30 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-firmware@kernel.org, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <BYAPR02MB6006478A57983F5B4067F54392D70@BYAPR02MB6006.namprd02.prod.outlook.com>
On Thu, Aug 8, 2019 at 5:56 AM Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>
> Hi linux-firmware maintainers,
>
> here's a pull request to update some ath10k firmware images. Please let me know if there are any problems.
>
> Kalle
>
> The following changes since commit dff98c6c57383fe343407bcb7b6e775e0b87274f:
>
> Merge branch 'master' of git://github.com/skeggsb/linux-firmware (2019-07-26 07:32:37 -0400)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/linux-firmware.git ath10k-20190808
>
> for you to fetch changes up to 1f0a99f6b07e24449411ccf208836b6769a5a2a4:
>
> ath10k: QCA9984 hw1.0: update board-2.bin (2019-08-08 12:39:06 +0300)
>
> ----------------------------------------------------------------
> Kalle Valo (8):
> ath10k: QCA4019 hw1.0: update board-2.bin
> ath10k: QCA6174 hw3.0: update firmware-6.bin to WLAN.RM.4.4.1-00140-QCARMSWPZ-1
> ath10k: QCA9887 hw1.0: update firmware-5.bin to 10.2.4-1.0-00045
> ath10k: QCA9888 hw2.0: update firmware-5.bin to 10.4-3.9.0.2-00040
> ath10k: QCA9888 hw2.0: update board-2.bin
> ath10k: QCA988X hw2.0: update firmware-5.bin to 10.2.4-1.0-00045
> ath10k: QCA9984 hw1.0: update firmware-5.bin to 10.4-3.9.0.2-00046
> ath10k: QCA9984 hw1.0: update board-2.bin
>
> WHENCE | 10 +++++-----
> ath10k/QCA4019/hw1.0/board-2.bin | Bin 449316 -> 607304 bytes
> ath10k/QCA6174/hw3.0/firmware-6.bin | Bin 731276 -> 700988 bytes
> ath10k/QCA9887/hw1.0/firmware-5.bin | Bin 237660 -> 238484 bytes
> ath10k/QCA9888/hw2.0/board-2.bin | Bin 84928 -> 84928 bytes
> ath10k/QCA9888/hw2.0/firmware-5.bin | Bin 688536 -> 686996 bytes
> ath10k/QCA988X/hw2.0/firmware-5.bin | Bin 248840 -> 248984 bytes
> ath10k/QCA9984/hw1.0/board-2.bin | Bin 171916 -> 171916 bytes
> ath10k/QCA9984/hw1.0/firmware-5.bin | Bin 676316 -> 674940 bytes
> 9 files changed, 5 insertions(+), 5 deletions(-)
Pulled and pushed out. Thanks.
josh
^ permalink raw reply
* Re: [PATCH v3 0/3] rtw88: update 8822c firmware files
From: Josh Boyer @ 2019-08-15 11:42 UTC (permalink / raw)
To: Tony Chuang
Cc: Linux Firmware, Linux Wireless, Larry Finger, Brian Norris,
Arend van Spriel
In-Reply-To: <1565252549-25524-1-git-send-email-yhchuang@realtek.com>
On Thu, Aug 8, 2019 at 4:22 AM <yhchuang@realtek.com> wrote:
>
> From: Yan-Hsuan Chuang <yhchuang@realtek.com>
>
> Update 8822c firmware image, and add wowlan firmware.
> Also add a README to describe its usage.
>
> Yan-Hsuan Chuang (3):
> rtw88: RTL8822C: update rtw8822c_fw.bin to v7.3
> rtw88: RTL8822C: add WoW firmware v7.3
> rtw88: add a README file
>
> WHENCE | 1 +
> rtw88/README | 28 ++++++++++++++++++++++++++++
> rtw88/rtw8822c_fw.bin | Bin 184640 -> 189152 bytes
> rtw88/rtw8822c_wow_fw.bin | Bin 0 -> 138720 bytes
> 4 files changed, 29 insertions(+)
> create mode 100644 rtw88/README
> create mode 100755 rtw88/rtw8822c_wow_fw.bin
All three applied and pushed out. I edited the third patch to add the
README to WHENCE.
josh
^ 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