Miri Korenblit
6ebd42a7b7
wifi: iwlwifi: Use FW rate for non-data frames
...
[ Upstream commit 499d02790495958506a64f37ceda7e97345a50a8 ]
Currently we are setting the rate in the tx cmd for
mgmt frames (e.g. during connection establishment).
This was problematic when sending mgmt frames in eSR mode,
as we don't know what link this frame will be sent on
(This is decided by the FW), so we don't know what is the
lowest rate.
Fix this by not setting the rate in tx cmd and rely
on FW to choose the right one.
Set rate only for injected frames with fixed rate,
or when no sta is given.
Also set for important frames (EAPOL etc.) the High Priority flag.
Fixes: 055b22e770miriam.rachel.korenblit@intel.com >
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com >
Link: https://lore.kernel.org/r/20230913145231.6c7e59620ee0.I6eaed3ccdd6dd62b9e664facc484081fc5275843@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2023-11-28 16:54:53 +00:00
Johannes Berg
a956c3af70
wifi: iwlwifi: mvm: avoid baid size integer overflow
...
[ Upstream commit 1a528ab1da324d078ec60283c34c17848580df24 ]
Roee reported various hard-to-debug crashes with pings in
EHT aggregation scenarios. Enabling KASAN showed that we
access the BAID allocation out of bounds, and looking at
the code a bit shows that since the reorder buffer entry
(struct iwl_mvm_reorder_buf_entry) is 128 bytes if debug
such as lockdep is enabled, then staring from an agg size
512 we overflow the size calculation, and allocate a much
smaller structure than we should, causing slab corruption
once we initialize this.
Fix this by simply using u32 instead of u16.
Reported-by: Roee Goldfiner <roee.h.goldfiner@intel.com >
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com >
Link: https://lore.kernel.org/r/20230620125813.f428c856030d.I2c2bb808e945adb71bc15f5b2bac2d8957ea90eb@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2023-07-27 08:44:38 +02:00
Johannes Berg
4e321c18ef
wifi: iwlwifi: pull from TXQs with softirqs disabled
...
[ Upstream commit 96fb6f47db24a712d650b0a9b9074873f273fb0e ]
In mac80211, it's required that we pull from TXQs by calling
ieee80211_tx_dequeue() only with softirqs disabled. However,
in iwl_mvm_queue_state_change() we're often called with them
enabled, e.g. from flush if anything was flushed, triggering
a mac80211 warning.
Fix that by disabling the softirqs across the TX call.
Fixes: cfbc6c4c5bjohannes.berg@intel.com >
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com >
Link: https://lore.kernel.org/r/20230614123446.0feef7fa81db.I4dd62542d955b40dd8f0af34fa4accb9d0d17c7e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2023-07-27 08:43:41 +02:00
Johannes Berg
d0d39bed9e
wifi: iwlwifi: mvm: don't trust firmware n_channels
...
[ Upstream commit 682b6dc29d98e857e6ca4bbc077c7dc2899b7473 ]
If the firmware sends us a corrupted MCC response with
n_channels much larger than the command response can be,
we might copy far too much (uninitialized) memory and
even crash if the n_channels is large enough to make it
run out of the one page allocated for the FW response.
Fix that by checking the lengths. Doing a < comparison
would be sufficient, but the firmware should be doing
it correctly, so check more strictly.
Fixes: dcaf9f5ecbjohannes.berg@intel.com >
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com >
Link: https://lore.kernel.org/r/20230514120631.d7b233139eb4.I51fd319df8e9d41881fc8450e83d78049518a79a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2023-05-30 12:57:53 +01:00
Johannes Berg
f4eb14d261
wifi: iwlwifi: mvm: check firmware response size
...
[ Upstream commit 13513cec93ac9902d0b896976d8bab3758a9881c ]
Check the firmware response size for responses to the
memory read/write command in debugfs before using it.
Fixes: 2b55f43f8ejohannes.berg@intel.com >
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com >
Link: https://lore.kernel.org/r/20230417113648.0d56fcaf68ee.I70e9571f3ed7263929b04f8fabad23c9b999e4ea@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2023-05-17 11:47:53 +02:00
Ben Greear
ae966649f6
wifi: iwlwifi: mvm: fix double free on tx path.
...
[ Upstream commit 0473cbae2137b963bd0eaa74336131cb1d3bc6c3 ]
We see kernel crashes and lockups and KASAN errors related to ax210
firmware crashes. One of the KASAN dumps pointed at the tx path,
and it appears there is indeed a way to double-free an skb.
If iwl_mvm_tx_skb_sta returns non-zero, then the 'skb' sent into the
method will be freed. But, in case where we build TSO skb buffer,
the skb may also be freed in error case. So, return 0 in that particular
error case and do cleanup manually.
BUG: KASAN: use-after-free in __list_del_entry_valid+0x12/0x90
iwlwifi 0000:06:00.0: 0x00000000 | tsf hi
Read of size 8 at addr ffff88813cfa4ba0 by task btserver/9650
CPU: 4 PID: 9650 Comm: btserver Tainted: G W 5.19.8+ #5
iwlwifi 0000:06:00.0: 0x00000000 | time gp1
Hardware name: Default string Default string/SKYBAY, BIOS 5.12 02/19/2019
Call Trace:
<TASK>
dump_stack_lvl+0x55/0x6d
print_report.cold.12+0xf2/0x684
iwlwifi 0000:06:00.0: 0x1D0915A8 | time gp2
? __list_del_entry_valid+0x12/0x90
kasan_report+0x8b/0x180
iwlwifi 0000:06:00.0: 0x00000001 | uCode revision type
? __list_del_entry_valid+0x12/0x90
__list_del_entry_valid+0x12/0x90
iwlwifi 0000:06:00.0: 0x00000048 | uCode version major
tcp_update_skb_after_send+0x5d/0x170
__tcp_transmit_skb+0xb61/0x15c0
iwlwifi 0000:06:00.0: 0xDAA05125 | uCode version minor
? __tcp_select_window+0x490/0x490
iwlwifi 0000:06:00.0: 0x00000420 | hw version
? trace_kmalloc_node+0x29/0xd0
? __kmalloc_node_track_caller+0x12a/0x260
? memset+0x1f/0x40
? __build_skb_around+0x125/0x150
? __alloc_skb+0x1d4/0x220
? skb_zerocopy_clone+0x55/0x230
iwlwifi 0000:06:00.0: 0x00489002 | board version
? kmalloc_reserve+0x80/0x80
? rcu_read_lock_bh_held+0x60/0xb0
tcp_write_xmit+0x3f1/0x24d0
iwlwifi 0000:06:00.0: 0x034E001C | hcmd
? __check_object_size+0x180/0x350
iwlwifi 0000:06:00.0: 0x24020000 | isr0
tcp_sendmsg_locked+0x8a9/0x1520
iwlwifi 0000:06:00.0: 0x01400000 | isr1
? tcp_sendpage+0x50/0x50
iwlwifi 0000:06:00.0: 0x48F0000A | isr2
? lock_release+0xb9/0x400
? tcp_sendmsg+0x14/0x40
iwlwifi 0000:06:00.0: 0x00C3080C | isr3
? lock_downgrade+0x390/0x390
? do_raw_spin_lock+0x114/0x1d0
iwlwifi 0000:06:00.0: 0x00200000 | isr4
? rwlock_bug.part.2+0x50/0x50
iwlwifi 0000:06:00.0: 0x034A001C | last cmd Id
? rwlock_bug.part.2+0x50/0x50
? lockdep_hardirqs_on_prepare+0xe/0x200
iwlwifi 0000:06:00.0: 0x0000C2F0 | wait_event
? __local_bh_enable_ip+0x87/0xe0
? inet_send_prepare+0x220/0x220
iwlwifi 0000:06:00.0: 0x000000C4 | l2p_control
tcp_sendmsg+0x22/0x40
sock_sendmsg+0x5f/0x70
iwlwifi 0000:06:00.0: 0x00010034 | l2p_duration
__sys_sendto+0x19d/0x250
iwlwifi 0000:06:00.0: 0x00000007 | l2p_mhvalid
? __ia32_sys_getpeername+0x40/0x40
iwlwifi 0000:06:00.0: 0x00000000 | l2p_addr_match
? rcu_read_lock_held_common+0x12/0x50
? rcu_read_lock_sched_held+0x5a/0xd0
? rcu_read_lock_bh_held+0xb0/0xb0
? rcu_read_lock_sched_held+0x5a/0xd0
? rcu_read_lock_sched_held+0x5a/0xd0
? lock_release+0xb9/0x400
? lock_downgrade+0x390/0x390
? ktime_get+0x64/0x130
? ktime_get+0x8d/0x130
? rcu_read_lock_held_common+0x12/0x50
? rcu_read_lock_sched_held+0x5a/0xd0
? rcu_read_lock_held_common+0x12/0x50
? rcu_read_lock_sched_held+0x5a/0xd0
? rcu_read_lock_bh_held+0xb0/0xb0
? rcu_read_lock_bh_held+0xb0/0xb0
__x64_sys_sendto+0x6f/0x80
do_syscall_64+0x34/0xb0
entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033:0x7f1d126e4531
Code: 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 35 80 0c 00 41 89 ca 8b 00 85 c0 75 1c 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 67 c3 66 0f 1f 44 00 00 55 48 83 ec 20 48 89
RSP: 002b:00007ffe21a679d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 000000000000ffdc RCX: 00007f1d126e4531
RDX: 0000000000010000 RSI: 000000000374acf0 RDI: 0000000000000014
RBP: 00007ffe21a67ac0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000010
R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000000
</TASK>
Allocated by task 9650:
kasan_save_stack+0x1c/0x40
__kasan_slab_alloc+0x6d/0x90
kmem_cache_alloc_node+0xf3/0x2b0
__alloc_skb+0x191/0x220
tcp_stream_alloc_skb+0x3f/0x330
tcp_sendmsg_locked+0x67c/0x1520
tcp_sendmsg+0x22/0x40
sock_sendmsg+0x5f/0x70
__sys_sendto+0x19d/0x250
__x64_sys_sendto+0x6f/0x80
do_syscall_64+0x34/0xb0
entry_SYSCALL_64_after_hwframe+0x46/0xb0
Freed by task 9650:
kasan_save_stack+0x1c/0x40
kasan_set_track+0x21/0x30
kasan_set_free_info+0x20/0x30
__kasan_slab_free+0x102/0x170
kmem_cache_free+0xc8/0x3e0
iwl_mvm_mac_itxq_xmit+0x124/0x270 [iwlmvm]
ieee80211_queue_skb+0x874/0xd10 [mac80211]
ieee80211_xmit_fast+0xf80/0x1180 [mac80211]
__ieee80211_subif_start_xmit+0x287/0x680 [mac80211]
ieee80211_subif_start_xmit+0xcd/0x730 [mac80211]
dev_hard_start_xmit+0xf6/0x420
__dev_queue_xmit+0x165b/0x1b50
ip_finish_output2+0x66e/0xfb0
__ip_finish_output+0x487/0x6d0
ip_output+0x11c/0x350
__ip_queue_xmit+0x36b/0x9d0
__tcp_transmit_skb+0xb35/0x15c0
tcp_write_xmit+0x3f1/0x24d0
tcp_sendmsg_locked+0x8a9/0x1520
tcp_sendmsg+0x22/0x40
sock_sendmsg+0x5f/0x70
__sys_sendto+0x19d/0x250
__x64_sys_sendto+0x6f/0x80
do_syscall_64+0x34/0xb0
entry_SYSCALL_64_after_hwframe+0x46/0xb0
The buggy address belongs to the object at ffff88813cfa4b40
which belongs to the cache skbuff_fclone_cache of size 472
The buggy address is located 96 bytes inside of
472-byte region [ffff88813cfa4b40, ffff88813cfa4d18)
The buggy address belongs to the physical page:
page:ffffea0004f3e900 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88813cfa6c40 pfn:0x13cfa4
head:ffffea0004f3e900 order:2 compound_mapcount:0 compound_pincount:0
flags: 0x5fff8000010200(slab|head|node=0|zone=2|lastcpupid=0x3fff)
raw: 005fff8000010200 ffffea0004656b08 ffffea0008e8cf08 ffff8881081a5240
raw: ffff88813cfa6c40 0000000000170015 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88813cfa4a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88813cfa4b00: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
>ffff88813cfa4b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88813cfa4c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88813cfa4c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Fixes: 08f7d8b69ahttps://lore.kernel.org/linux-wireless/20220928193057.16132-1-greearb@candelatech.com/
Tested-by: Amol Jawale <amol.jawale@candelatech.com >
Signed-off-by: Ben Greear <greearb@candelatech.com >
Link: https://lore.kernel.org/r/20221123225313.21b1ee31d666.I3b3ba184433dd2a544d91eeeda29b467021824ae@changeid
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2023-01-14 10:15:34 +01:00
Jose Ignacio Tornos Martinez
38d71acc15
wifi: iwlwifi: mvm: fix double list_add at iwl_mvm_mac_wake_tx_queue
...
[ Upstream commit 14a3aacf517a9de725dd3219dbbcf741e31763c4 ]
After successfull station association, if station queues are disabled for
some reason, the related lists are not emptied. So if some new element is
added to the list in iwl_mvm_mac_wake_tx_queue, it can match with the old
one and produce a BUG like this:
[ 46.535263] list_add corruption. prev->next should be next (ffff94c1c318a360), but was 0000000000000000. (prev=ffff94c1d02d3388).
[ 46.535283] ------------[ cut here ]------------
[ 46.535284] kernel BUG at lib/list_debug.c:26!
[ 46.535290] invalid opcode: 0000 [#1 ] PREEMPT SMP PTI
[ 46.585304] CPU: 0 PID: 623 Comm: wpa_supplicant Not tainted 5.19.0-rc3+ #1
[ 46.592380] Hardware name: Dell Inc. Inspiron 660s/0478VN , BIOS A07 08/24/2012
[ 46.600336] RIP: 0010:__list_add_valid.cold+0x3d/0x3f
[ 46.605475] Code: f2 4c 89 c1 48 89 fe 48 c7 c7 c8 40 67 93 e8 20 cc fd ff 0f 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 70 40 67 93 e8 09 cc fd ff <0f> 0b 48 89 fe 48 c7 c7 00 41 67 93 e8 f8 cb fd ff 0f 0b 48 89 d1
[ 46.624469] RSP: 0018:ffffb20800ab76d8 EFLAGS: 00010286
[ 46.629854] RAX: 0000000000000075 RBX: ffff94c1c318a0e0 RCX: 0000000000000000
[ 46.637105] RDX: 0000000000000201 RSI: ffffffff9365e100 RDI: 00000000ffffffff
[ 46.644356] RBP: ffff94c1c5f43370 R08: 0000000000000075 R09: 3064316334396666
[ 46.651607] R10: 3364323064316334 R11: 39666666663d7665 R12: ffff94c1c5f43388
[ 46.658857] R13: ffff94c1d02d3388 R14: ffff94c1c318a360 R15: ffff94c1cf2289c0
[ 46.666108] FS: 00007f65634ff7c0(0000) GS:ffff94c1da200000(0000) knlGS:0000000000000000
[ 46.674331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 46.680170] CR2: 00007f7dfe984460 CR3: 000000010e894003 CR4: 00000000000606f0
[ 46.687422] Call Trace:
[ 46.689906] <TASK>
[ 46.691950] iwl_mvm_mac_wake_tx_queue+0xec/0x15c [iwlmvm]
[ 46.697601] ieee80211_queue_skb+0x4b3/0x720 [mac80211]
[ 46.702973] ? sta_info_get+0x46/0x60 [mac80211]
[ 46.707703] ieee80211_tx+0xad/0x110 [mac80211]
[ 46.712355] __ieee80211_tx_skb_tid_band+0x71/0x90 [mac80211]
...
In order to avoid this problem, we must also remove the related lists when
station queues are disabled.
Fixes: cfbc6c4c5btnagata@redhat.com >
Reported-by: Petr Stourac <pstourac@redhat.com >
Tested-by: Petr Stourac <pstourac@redhat.com >
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com >
Signed-off-by: Kalle Valo <kvalo@kernel.org >
Link: https://lore.kernel.org/r/20220719153542.81466-1-jtornosm@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org >
2022-08-21 15:15:49 +02:00
Emmanuel Grumbach
c1ad58de13
iwlwifi: mvm: fix assert 1F04 upon reconfig
...
commit 9d096e3d3061dbf4ee10e2b59fc2c06e05bdb997 upstream.
When we reconfig we must not send the MAC_POWER command that relates to
a MAC that was not yet added to the firmware.
Ignore those in the iterator.
Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com >
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com >
Link: https://lore.kernel.org/r/20220517120044.ed2ffc8ce732.If786e19512d0da4334a6382ea6148703422c7d7b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2022-06-09 10:21:22 +02:00
Ilan Peer
bae03957e8
iwlwifi: mvm: Correctly set fragmented EBS
...
[ Upstream commit d8d4dd26b9e0469baf5017f0544d852fd4e3fb6d ]
Currently, fragmented EBS was set for a channel only if the 'hb_type'
was set to fragmented or balanced scan. However, 'hb_type' is set only
in case of CDB, and thus fragmented EBS is never set for a channel for
non-CDB devices. Fix it.
Signed-off-by: Ilan Peer <ilan.peer@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20220204122220.a6165ac9b9d5.I654eafa62fd647030ae6d4f07f32c96c3171decb@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2022-04-13 21:00:57 +02:00
Dan Carpenter
441a83ff27
iwlwifi: mvm: Fix an error code in iwl_mvm_up()
...
[ Upstream commit 583d18336abdfb1b355270289ff8f6a2608ba905 ]
Return -ENODEV instead of success on this error path.
Fixes: dd36a507c8dan.carpenter@oracle.com >
Link: https://lore.kernel.org/r/20210816183930.GA2068@kili
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2022-04-08 14:40:16 +02:00
Golan Ben Ami
9a8e4a5c5b
iwlwifi: don't advertise TWT support
...
[ Upstream commit 1db5fcbba2631277b78d7f8aff99c9607d29f6d8 ]
Some APs misbehave when TWT is used and cause our firmware to crash.
We don't know a reasonable way to detect and work around this problem
in the FW yet. To prevent these crashes, disable TWT in the driver by
stopping to advertise TWT support.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215523
Signed-off-by: Golan Ben Ami <golan.ben.ami@intel.com >
[reworded the commit message]
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/20220301072926.153969-1-luca@coelho.fi
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2022-03-19 13:44:45 +01:00
Ilan Peer
798754ba48
iwlwifi: mvm: Increase the scan timeout guard to 30 seconds
...
commit ced50f1133af12f7521bb777fcf4046ca908fb77 upstream.
With the introduction of 6GHz channels the scan guard timeout should
be adjusted to account for the following extreme case:
- All 6GHz channels are scanned passively: 58 channels.
- The scan is fragmented with the following parameters: 3 fragments,
95 TUs suspend time, 44 TUs maximal out of channel time.
The above would result with scan time of more than 24 seconds. Thus,
set the timeout to 30 seconds.
Cc: stable@vger.kernel.org
Signed-off-by: Ilan Peer <ilan.peer@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20211210090244.3c851b93aef5.I346fa2e1d79220a6770496e773c6f87a2ad9e6c4@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2022-01-27 10:54:25 +01:00
Ilan Peer
f266e1c5bf
iwlwifi: mvm: Fix calculation of frame length
...
[ Upstream commit 40a0b38d7a7f91a6027287e0df54f5f547e8d27e ]
The RADA might include in the Rx frame the MIC and CRC bytes.
These bytes should be removed for non monitor interfaces and
should not be passed to mac80211.
Fix the Rx processing to remove the extra bytes on non monitor
cases.
Signed-off-by: Ilan Peer <ilan.peer@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.098be12c801e.I1d81733d8a75b84c3b20eb6e0d14ab3405ca6a86@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2022-01-27 10:54:18 +01:00
Shaul Triebitz
93a108d466
iwlwifi: mvm: avoid clearing a just saved session protection id
...
[ Upstream commit 8e967c137df3b236d2075f9538cb888129425d1a ]
When scheduling a session protection the id is saved but
then it may be cleared when calling iwl_mvm_te_clear_data
(if a previous session protection is currently active).
Fix it by saving the id after calling iwl_mvm_te_clear_data.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20211204130722.b0743a588d14.I098fef6677d0dab3ef1b6183ed206a10bab01eb2@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2022-01-27 10:54:15 +01:00
Johannes Berg
ec01e0fe21
iwlwifi: mvm: synchronize with FW after multicast commands
...
[ Upstream commit db66abeea3aefed481391ecc564fb7b7fb31d742 ]
If userspace installs a lot of multicast groups very quickly, then
we may run out of command queue space as we send the updates in an
asynchronous fashion (due to locking concerns), and the CPU can
create them faster than the firmware can process them. This is true
even when mac80211 has a work struct that gets scheduled.
Fix this by synchronizing with the firmware after sending all those
commands - outside of the iteration we can send a synchronous echo
command that just has the effect of the CPU waiting for the prior
asynchronous commands to finish. This also will cause fewer of the
commands to be sent to the firmware overall, because the work will
only run once when rescheduled multiple times while it's running.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=213649
Suggested-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com >
Reported-by: Maximilian Ernestus <maximilian@ernestus.de >
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20211204083238.51aea5b79ea4.I88a44798efda16e9fe480fb3e94224931d311b29@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2022-01-27 10:54:14 +01:00
Nathan Chancellor
2b948524ae
iwlwifi: mvm: Use div_s64 instead of do_div in iwl_mvm_ftm_rtt_smoothing()
...
[ Upstream commit 4ccdcc8ffd955490feec05380223db6a48961eb5 ]
When building ARCH=arm allmodconfig:
drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c: In function ‘iwl_mvm_ftm_rtt_smoothing’:
./include/asm-generic/div64.h:222:35: error: comparison of distinct pointer types lacks a cast [-Werror]
222 | (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
| ^~
drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:1070:9: note: in expansion of macro ‘do_div’
1070 | do_div(rtt_avg, 100);
| ^~~~~~
do_div() has to be used with an unsigned 64-bit integer dividend but
rtt_avg is a signed 64-bit integer.
div_s64() expects a signed 64-bit integer dividend and signed 32-bit
divisor, which fits this scenario, so use that function here to fix the
warning.
Fixes: 8b0f92549f2c ("iwlwifi: mvm: fix 32-bit build in FTM")
Signed-off-by: Nathan Chancellor <nathan@kernel.org >
Link: https://lore.kernel.org/r/20211227191757.2354329-1-nathan@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2022-01-27 10:54:03 +01:00
Nathan Errera
bdc6c9fc5f
iwlwifi: mvm: test roc running status bits before removing the sta
...
[ Upstream commit 998e1aba6e5eb35370eaf30ccc1823426ec11f90 ]
In some cases the sta is being removed twice since we do not test the
roc aux running before removing it. Start looking at the bit before
removing the sta.
Signed-off-by: Nathan Errera <nathan.errera@intel.com >
Fixes: 2c2c3647cdluciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.d5376ac6bcb0.Ic5f8470ea60c072bde9d1503e5f528b65e301e20@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2022-01-27 10:53:58 +01:00
Johannes Berg
a750fcd604
iwlwifi: mvm: fix 32-bit build in FTM
...
[ Upstream commit 8b0f92549f2c2458200935c12a2e2a6e80234cf5 ]
On a 32-bit build, the division here needs to be done
using do_div(), otherwise the compiler will try to call
a function that doesn't exist, thus failing to build.
Fixes: b68bd2e314johannes.berg@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20211219111352.e56cbf614a4d.Ib98004ccd2c7a55fd883a8ea7eebd810f406dec6@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2022-01-27 10:53:58 +01:00
Mordechay Goodstein
01300d2150
iwlwifi: mvm: retry init flow if failed
...
commit 5283dd677e52af9db6fe6ad11b2f12220d519d0c upstream.
In some very rare cases the init flow may fail. In many cases, this is
recoverable, so we can retry. Implement a loop to retry two more times
after the first attempt failed.
This can happen in two different situations, namely during probe and
during mac80211 start. For the first case, a simple loop is enough.
For the second case, we need to add a flag to prevent mac80211 from
trying to restart it as well, leaving full control with the driver.
Cc: <stable@vger.kernel.org >
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20211110150132.57514296ecab.I52a0411774b700bdc7dedb124d8b59bf99456eb2@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2021-12-08 09:03:29 +01:00
Johannes Berg
32a9a8fdba
iwlwifi: mvm: disable RX-diversity in powersave
...
[ Upstream commit e5322b9ab5f63536c41301150b7ce64605ce52cc ]
Just like we have default SMPS mode as dynamic in powersave,
we should not enable RX-diversity in powersave, to reduce
power consumption when connected to a non-MIMO AP.
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20211017113927.fc896bc5cdaa.I1d11da71b8a5cbe921a37058d5f578f1b14a2023@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-11-18 14:03:59 +01:00
Ilan Peer
4bbf0a9d90
iwlwifi: mvm: Fix scan channel flags settings
...
[ Upstream commit 090f1be3abf3069ef856b29761f181808bf55917 ]
The iwl_mvm_scan_ch_n_aps_flag() is called with a variable
before the value of the variable is set. Fix it.
Signed-off-by: Ilan Peer <ilan.peer@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20210826224715.f6f188980a5e.Ie7331a8b94004d308f6cbde44e519155a5be91dd@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-09-18 13:40:34 +02:00
Johannes Berg
4ed6510e05
iwlwifi: mvm: fix access to BSS elements
...
[ Upstream commit 6c608cd6962ebdf84fd3de6d42f88ed64d2f4e1b ]
BSS elements are protected using RCU, so we need to use
RCU properly to access them, fix that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20210805130823.fd8b5791ab44.Iba26800a6301078d3782fb249c476dd8ac2bf3c6@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-09-18 13:40:33 +02:00
Johannes Berg
9e80a3d88f
iwlwifi: mvm: avoid static queue number aliasing
...
[ Upstream commit c6ce1c74ef2923b8ffd85f7f8b486f804f343b39 ]
When TVQM is enabled (iwl_mvm_has_new_tx_api() is true), then
queue numbers are just sequentially assigned 0, 1, 2, ...
Prior to TVQM, in DQA, there were some statically allocated
queue numbers:
* IWL_MVM_DQA_AUX_QUEUE == 1,
* both IWL_MVM_DQA_INJECT_MONITOR_QUEUE and
IWL_MVM_DQA_P2P_DEVICE_QUEUE == 2, and
* IWL_MVM_DQA_AP_PROBE_RESP_QUEUE == 9.
Now, these values are assigned to the members mvm->aux_queue,
mvm->snif_queue, mvm->probe_queue and mvm->p2p_dev_queue by
default. Normally, this doesn't really matter, and if TVQM is
in fact available we override them to the real values after
allocating a queue for use there.
However, this allocation doesn't always happen. For example,
for mvm->p2p_dev_queue (== 2) it only happens when the P2P
Device interface is started, if any. If it's not started, the
value in mvm->p2p_dev_queue remains 2. This wouldn't really
matter all that much if it weren't for iwl_mvm_is_static_queue()
which checks a queue number against one of those four static
numbers.
Now, if no P2P Device or monitor interface is added then queue
2 may be dynamically allocated, yet alias mvm->p2p_dev_queue or
mvm->snif_queue, and thus iwl_mvm_is_static_queue() erroneously
returns true for it. If it then gets full, all interface queues
are stopped, instead of just backpressuring against the one TXQ
that's really the only affected one.
This clearly can lead to issues, as everything is stopped even
if just a single TXQ filled its corresponding HW queue, if it
happens to have an appropriate number (2 or 9, AUX is always
reassigned.) Due to a mac80211 bug, this also led to a situation
in which the queues remained stopped across a deauthentication
and then attempts to connect to a new AP started failing, but
that's fixed separately.
Fix all of this by simply initializing the queue numbers to
the invalid value until they're used, if TVQM is enabled, and
also setting them back to that value when the queues are later
freed again.
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20210802172232.2e47e623f9e2.I9b0830dafbb68ef35b7b8f0f46160abec02ac7d0@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-09-18 13:40:33 +02:00
Zhang Qilong
3ed8982df5
iwlwifi: mvm: fix a memory leak in iwl_mvm_mac_ctxt_beacon_changed
...
[ Upstream commit 0f5d44ac6e55551798dd3da0ff847c8df5990822 ]
If beacon_inject_active is true, we will return without freeing
beacon. Fid that by freeing it before returning.
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com >
[reworded the commit message]
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20210802172232.d16206ca60fc.I9984a9b442c84814c307cee3213044e24d26f38a@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-09-18 13:40:33 +02:00
Emmanuel Grumbach
4c4f868082
iwlwifi: follow the new inclusive terminology
...
[ Upstream commit cdaba917268d7b58bf02fcc587cb2a7a277dc931 ]
The new inclusive terminology requires to change a few
terms that were used in iwlwifi.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20201209231352.1eb4c8625f36.I1b17b68d4a8e77071da3e15ffbd902d15c1d4938@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-09-15 09:50:45 +02:00
Shaul Triebitz
78eadadff3
iwlwifi: mvm: fix error print when session protection ends
...
[ Upstream commit 976ac0af7ba2c5424bc305b926c0807d96fdcc83 ]
When the session protection ends and the Driver is not
associated or a beacon was not heard, the Driver
prints "No beacons heard...".
That's confusing for the case where not associated.
Change the print when not associated to "Not associated...".
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20210617100544.41a5a5a894fa.I9eabb76e7a3a7f4abbed8f2ef918f1df8e825726@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-07-19 09:44:52 +02:00
Johannes Berg
1e1bb1efd6
iwlwifi: mvm: don't change band on bound PHY contexts
...
[ Upstream commit 8835a64f74c46baebfc946cd5a2c861b866ebcee ]
When we have a P2P Device active, we attempt to only change the
PHY context it uses when we get a new remain-on-channel, if the
P2P Device is the only user of the PHY context.
This is fine if we're switching within a band, but if we're
switching bands then the switch implies a removal and re-add
of the PHY context, which isn't permitted by the firmware while
it's bound to an interface.
Fix the code to skip the unbind/release/... cycle only if the
band doesn't change (or we have old devices that can switch the
band on the fly as well.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20210612142637.e9ac313f70f3.I713b9d109957df7e7d9ed0861d5377ce3f8fccd3@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-07-19 09:44:52 +02:00
Felix Fietkau
c6d864601e
mac80211: remove iwlwifi specific workaround that broke sta NDP tx
...
commit e41eb3e408de27982a5f8f50b2dd8002bed96908 upstream.
Sending nulldata packets is important for sw AP link probing and detecting
4-address mode links. The checks that dropped these packets were apparently
added to work around an iwlwifi firmware bug with multi-TID aggregation.
Fixes: 41cbb0f5a2stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name >
Link: https://lore.kernel.org/r/20210619101517.90806-1-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2021-07-14 16:55:42 +02:00
Sara Sharon
6f304a8d61
iwlwifi: mvm: don't check if CSA event is running before removing
...
[ Upstream commit b8a86164454aa745ecb534d7477d50d440ea05b6 ]
We may want to remove it before it started (i.e. before the
actual switch time).
Signed-off-by: Sara Sharon <sara.sharon@intel.com >
Fixes: 58ddd9b6d1luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20210210171218.835db8987b8a.Ic6c5d28d744302db1bc6c4314bd3138ba472f834@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-03-04 11:37:29 +01:00
Luca Coelho
caa32dc6ab
iwlwifi: mvm: assign SAR table revision to the command later
...
[ Upstream commit 28db1862067cb09ebfdccfbc129a52c6fdb4c4d7 ]
The call to iwl_sar_geo_init() was moved to the end of the
iwl_mvm_sar_geo_init() function, after the table revision is assigned
to the FW command. But the revision is only known after
iwl_sar_geo_init() is called, so we were always assigning zero to it.
Fix that by moving the assignment code after the iwl_sar_geo_init()
function is called.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Fixes: 45acebf8d6luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20210210135352.cef55ef3a065.If96c60f08d24c2262c287168a6f0dbd7cf0f8f5c@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-03-04 11:37:29 +01:00
Luca Coelho
207bb27562
iwlwifi: mvm: send stored PPAG command instead of local
...
[ Upstream commit 659844d391826bfc5c8b4d9a06869ed51d859c76 ]
Some change conflicts apparently cause a confusion between a local
variable being used to send the PPAG command and the introduction of a
union for this command. Most parts of the local command were never
copied from the stored data, so the FW was getting garbage in the
tables instead of getting valid values.
Fix this by completely removing the local and using only the union
that we have stored in fwrt.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Fixes: f2134f66f4luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20210210135352.d090e0301023.I7d57f4d7da9a3297734c51cf988199323c76916d@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-03-04 11:37:29 +01:00
Luca Coelho
600c03b4e9
iwlwifi: mvm: store PPAG enabled/disabled flag properly
...
[ Upstream commit 551d793f65364c904921ac168d4b4028bb51be69 ]
When reading the PPAG table from ACPI, we should store everything in
our fwrt structure, so it can be accessed later. But we had a local
ppag_table variable in the function and were erroneously storing the
enabled/disabled flag in it instead of storing it in the fwrt. Fix
this by removing the local variable and storing everything directly in
fwrt.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Fixes: f2134f66f4luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20210210135352.889862e6d393.I8b894c1b2b3fe0ad2fb39bf438273ea47eb5afa4@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-03-04 11:37:29 +01:00
Luca Coelho
39d8f5db9c
iwlwifi: mvm: fix the type we use in the PPAG table validity checks
...
[ Upstream commit 5a6842455c113920001df83cffa28accceeb0927 ]
The value we receive from ACPI is a long long unsigned integer but the
values should be treated as signed char. When comparing the received
value with ACPI_PPAG_MIN_LB/HB, we were doing an unsigned comparison,
so the negative value would actually be treated as a very high number.
To solve this issue, assign the value to our table of s8's before
making the comparison, so the value is already converted when we do
so.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20210210135352.b0ec69f312bc.If77fd9c61a96aa7ef2ac96d935b7efd7df502399@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-03-04 11:37:29 +01:00
Luca Coelho
480f1e5d5c
iwlwifi: mvm: set enabled in the PPAG command properly
...
[ Upstream commit efaa85cf2294d5e10a724e24356507eeb3836f72 ]
When version 2 of the PER_PLATFORM_ANT_GAIN_CMD was implemented, we
started copying the values from the command that we have stored into a
local instance. But we accidentally forgot to copy the enabled flag,
so in practice PPAG is never really enabled. Fix this by copying the
flag from our stored data a we should.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Fixes: f2134f66f4luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20210131201908.24d7bf754ad5.I0e8abc2b8747508b6118242533d68c856ca6dffb@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-03-04 11:37:27 +01:00
Johannes Berg
38da9b033b
iwlwifi: mvm: guard against device removal in reprobe
...
[ Upstream commit 7a21b1d4a728a483f07c638ccd8610d4b4f12684 ]
If we get into a problem severe enough to attempt a reprobe,
we schedule a worker to do that. However, if the problem gets
more severe and the device is actually destroyed before this
worker has a chance to run, we use a free device. Bump up the
reference count of the device until the worker runs to avoid
this situation.
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20210122144849.871f0892e4b2.I94819e11afd68d875f3e242b98bef724b8236f1e@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-02-13 13:55:11 +01:00
Gregory Greenman
492f762b9c
iwlwifi: mvm: invalidate IDs of internal stations at mvm start
...
[ Upstream commit e223e42aac30bf81f9302c676cdf58cf2bf36950 ]
Having sta_id not set for aux_sta and snif_sta can potentially lead to a
hard to debug issue in case remove station is called without an add. In
this case sta_id 0, an unrelated regular station, will be removed.
In fact, we do have a FW assert that occures rarely and from the debug
data analysis it looks like sta_id 0 is removed by mistake, though it's
hard to pinpoint the exact flow. The WARN_ON in this patch should help
to find it.
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20210122144849.5dc6dd9b22d5.I2add1b5ad24d0d0a221de79d439c09f88fcaf15d@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-02-13 13:55:09 +01:00
Johannes Berg
cc1d805aa5
iwlwifi: mvm: take mutex for calling iwl_mvm_get_sync_time()
...
[ Upstream commit 5c56d862c749669d45c256f581eac4244be00d4d ]
We need to take the mutex to call iwl_mvm_get_sync_time(), do it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20210115130252.4bb5ccf881a6.I62973cbb081e80aa5b0447a5c3b9c3251a65cf6b@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-02-13 13:55:08 +01:00
Sara Sharon
a90e8588f7
iwlwifi: mvm: skip power command when unbinding vif during CSA
...
[ Upstream commit bf544e9aa570034e094a8a40d5f9e1e2c4916d18 ]
In the new CSA flow, we remain associated during CSA, but
still do a unbind-bind to the vif. However, sending the power
command right after when vif is unbound but still associated
causes FW to assert (0x3400) since it cannot tell the LMAC id.
Just skip this command, we will send it again in a bit, when
assigning the new context.
Signed-off-by: Sara Sharon <sara.sharon@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20210115130252.64a2254ac5c3.Iaa3a9050bf3d7c9cd5beaf561e932e6defc12ec3@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-02-13 13:55:07 +01:00
Eric Dumazet
51f58c4882
iwlwifi: provide gso_type to GSO packets
...
commit 81a86e1bd8e7060ebba1718b284d54f1238e9bf9 upstream.
net/core/tso.c got recent support for USO, and this broke iwlfifi
because the driver implemented a limited form of GSO.
Providing ->gso_type allows for skb_is_gso_tcp() to provide
a correct result.
Fixes: 3d5b459ba0edumazet@google.com >
Reported-by: Ben Greear <greearb@candelatech.com >
Tested-by: Ben Greear <greearb@candelatech.com >
Cc: Luca Coelho <luciano.coelho@intel.com >
Cc: Johannes Berg <johannes@sipsolutions.net >
Link: https://bugzilla.kernel.org/show_bug.cgi?id=209913
Link: https://lore.kernel.org/r/20210125150949.619309-1-eric.dumazet@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org >
Cc: Robert Hancock <hancockrwd@gmail.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2021-02-03 23:28:36 +01:00
Johannes Berg
82d87b59df
iwlwifi: mvm: hook up missing RX handlers
...
[ Upstream commit 8a59d39033c35bb484f6bd91891db86ebe07fdc2 ]
The RX handlers for probe response data and channel switch weren't
hooked up properly, fix that.
Fixes: 86e177d80fd3a108a48djohannes.berg@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20201209231352.2d07dcee0d35.I07a61b5d734478db57d9434ff303e4c90bf6c32b@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2020-12-30 11:53:46 +01:00
Sara Sharon
fe56d05ee6
iwlwifi: mvm: fix kernel panic in case of assert during CSA
...
During CSA, we briefly nullify the phy context, in __iwl_mvm_unassign_vif_chanctx.
In case we have a FW assert right after it, it remains NULL though.
We end up running into endless loop due to mac80211 trying repeatedly to
move us to ASSOC state, and we keep returning -EINVAL. Later down the road
we hit a kernel panic.
Detect and avoid this endless loop.
Signed-off-by: Sara Sharon <sara.sharon@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.d64de2c17bff.Iedd0d2afa20a2aacba5259a5cae31cb3a119a4eb@changeid
2020-11-10 20:45:36 +02:00
Avraham Stern
97cc16943f
iwlwifi: mvm: write queue_sync_state only for sync
...
We use mvm->queue_sync_state to wait for synchronous queue sync
messages, but if an async one happens inbetween we shouldn't
clear mvm->queue_sync_state after sending the async one, that
can run concurrently (at least from the CPU POV) with another
synchronous queue sync.
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Fixes: 3c514bf831luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.51a3148f2c14.I0772171dbaec87433a11513e9586d98b5d920b5f@changeid
2020-11-10 20:45:34 +02:00
Emmanuel Grumbach
1cf260e3a7
iwlwifi: mvm: properly cancel a session protection for P2P
...
We need to feed the configuration id to remove session protection
properly.
Remember the conf_id when we add the session protection so that we
can give it back when we want to remove the session protection.
While at it, slightly improve the kernel doc for the conf_id
of the notification.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com >
Fixes: fe959c7b20luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.3642f730333d.I01a98ecde62096d00d171cf34ad775bf80cb0277@changeid
2020-11-10 20:45:32 +02:00
Emmanuel Grumbach
fb8d1b6e97
iwlwifi: mvm: use the HOT_SPOT_CMD to cancel an AUX ROC
...
The ROC that runs on the AUX ROC (meaning an ROC on the STA vif),
was added with the HOT_SPOT_CMD firmware command and must be
cancelled with that same command.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com >
Fixes: fe959c7b20luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.a317376154da.I44fa3637373ba4bd421cdff2cabc761bffc0735f@changeid
2020-11-10 20:45:31 +02:00
Mordechay Goodstein
c8a2e7a297
iwlwifi: sta: set max HE max A-MPDU according to HE capa
...
Currently, our max tpt is limited to max HT A-MPDU for LB,
and max VHT A-MPDU for HB. Configure HE exponent value correctly to
achieve HE max A-MPDU, both on LB and HB.
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.4486852ebb56.I9eb0d028e31f183597fb90120e7d4ca87e0dd6cb@changeid
2020-11-10 20:45:29 +02:00
Luca Coelho
b7d96bca1f
Revert "iwlwifi: remove wide_cmd_header field"
...
This reverts commit 0a8159cbd10a8159cbd1luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20201009122123.3e4ee0ad7a71.Id6d95ae601f048aeb4d2ed63a1712e469da84369@changeid
2020-10-09 18:04:50 +03:00
Luca Coelho
b3e4c0f34c
iwlwifi: move PNVM implementation to common code
...
The PNVM code is generic and can be used by other opmodes. Move it to
a common file and include it in the relevant opmodes.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.232aa310693b.I03a18ffa4162753af38e759d88e27509007c7bca@changeid
2020-10-08 20:14:58 +03:00
Mordechay Goodstein
0fafaa97ef
iwlwifi: rs: align to new TLC config command API
...
The new API adds 4 bytes at end of the struct. We just need to make
sure that we don't break compatibility with old FWs.
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.bb31ce80fc55.I8a272d1da1334b1805761c0731e5d0c76ca2ef29@changeid
2020-10-08 20:14:57 +03:00
Naftali Goldstein
45acebf8d6
iwlwifi: fix sar geo table initialization
...
When adding support for version 3 of the GEO_TX_POWER_LIMIT command,
the table argument of iwl_sar_geo_init was changed from a pointer a 1d
array of now-removed iwl_per_chain_offset_group_v1 to a pointer to a 2d
array of iwl_per_chain_offset (iwl_per_chain_offset_group_v1 was a
struct containing 2 copies of iwl_per_chain_offset).
So even for version 2 where the second dimension is of length 2, which
means that the underlying memory layout of the array didn't change, this
requires a small change in the way we loop over it, and this was missed.
Additionally, for the case of version 3 where the second dimension is now
3, in order to fill the first two elements of each row correctly (lb and
hb), iwl_sar_geo_init must get the true number of bands supported.
But because we don't yet store any values for the 3rd (uhb) band, skip
that band.
Signed-off-by: Naftali Goldstein <naftali.goldstein@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.73605b6e0548.Id0ec98333277ff9e017e3938ae413b34acc68947@changeid
2020-10-08 20:14:55 +03:00
Mordechay Goodstein
853f4954ba
iwlwifi: stats: add new api fields for statistics cmd/ntfy
...
The new API uses TLV format for statistics to enable fast changes
and debug on the fly.
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.a45fd1a34a39.I7709305a6dc7b88d0c5119b12c9251fa6c740262@changeid
2020-10-08 20:14:54 +03:00
