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
Stanislaw Gruszka
2946d2ae5a
wifi: iwlegacy: 4965: corrected fix for potential off-by-one overflow in il4965_rs_fill_link_cmd()
...
commit 6d0ef7241553f3553a0a2764c69b07892705924c upstream.
This reverts commit a8eb8e6f7159c7c20c0ddac428bde3d110890aa7 as
it can cause invalid link quality command sent to the firmware
and address the off-by-one issue by fixing condition of while loop.
Cc: stable@vger.kernel.org
Fixes: a8eb8e6f7159 ("wifi: iwlegacy: 4965: fix potential off-by-one overflow in il4965_rs_fill_link_cmd()")
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl >
Signed-off-by: Kalle Valo <kvalo@kernel.org >
Link: https://lore.kernel.org/r/20220815073737.GA999388@wp.pl
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2022-09-15 11:32:02 +02: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
Alexey Kodanev
e7d6cac696
wifi: iwlegacy: 4965: fix potential off-by-one overflow in il4965_rs_fill_link_cmd()
...
[ Upstream commit a8eb8e6f7159c7c20c0ddac428bde3d110890aa7 ]
As a result of the execution of the inner while loop, the value
of 'idx' can be equal to LINK_QUAL_MAX_RETRY_NUM. However, this
is not checked after the loop and 'idx' is used to write the
LINK_QUAL_MAX_RETRY_NUM size array 'lq_cmd->rs_table[idx]' below
in the outer loop.
The fix is to check the new value of 'idx' inside the nested loop,
and break both loops if index equals the size. Checking it at the
start is now pointless, so let's remove it.
Detected using the static analysis tool - Svace.
Fixes: be663ab670aleksei.kodanev@bell-sw.com >
Signed-off-by: Kalle Valo <kvalo@kernel.org >
Link: https://lore.kernel.org/r/20220608171614.28891-1-aleksei.kodanev@bell-sw.com
Signed-off-by: Sasha Levin <sashal@kernel.org >
2022-08-21 15:15:40 +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
Haowen Bai
98d1dc32f8
ipw2x00: Fix potential NULL dereference in libipw_xmit()
...
[ Upstream commit e8366bbabe1d207cf7c5b11ae50e223ae6fc278b ]
crypt and crypt->ops could be null, so we need to checking null
before dereference
Signed-off-by: Haowen Bai <baihaowen@meizu.com >
Signed-off-by: Kalle Valo <kvalo@kernel.org >
Link: https://lore.kernel.org/r/1648797055-25730-1-git-send-email-baihaowen@meizu.com
Signed-off-by: Sasha Levin <sashal@kernel.org >
2022-06-09 10:20:50 +02:00
Guenter Roeck
85eba08be2
iwlwifi: iwl-dbg: Use del_timer_sync() before freeing
...
[ Upstream commit 7635a1ad8d92dcc8247b53f949e37795154b5b6f ]
In Chrome OS, a large number of crashes is observed due to corrupted timer
lists. Steven Rostedt pointed out that this usually happens when a timer
is freed while still active, and that the problem is often triggered
by code calling del_timer() instead of del_timer_sync() just before
freeing.
Steven also identified the iwlwifi driver as one of the possible culprits
since it does exactly that.
Reported-by: Steven Rostedt <rostedt@goodmis.org >
Cc: Steven Rostedt <rostedt@goodmis.org >
Cc: Johannes Berg <johannes.berg@intel.com >
Cc: Gregory Greenman <gregory.greenman@intel.com >
Fixes: 60e8abd9d3linux@roeck-us.net >
Acked-by: Gregory Greenman <gregory.greenman@intel.com >
Tested-by: Sedat Dilek <sedat.dilek@gmail.com > # Linux v5.17.3-rc1 and Debian LLVM-14
Signed-off-by: Kalle Valo <kvalo@kernel.org >
Link: https://lore.kernel.org/r/20220411154210.1870008-1-linux@roeck-us.net
Signed-off-by: Sasha Levin <sashal@kernel.org >
2022-05-18 10:23:42 +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
Colin Ian King
c12692c3e9
iwlwifi: Fix -EIO error code that is never returned
...
[ Upstream commit c305c94bdc18e45b5ad1db54da4269f8cbfdff6b ]
Currently the error -EIO is being assinged to variable ret when
the READY_BIT is not set but the function iwlagn_mac_start returns
0 rather than ret. Fix this by returning ret instead of 0.
Addresses-Coverity: ("Unused value")
Fixes: 7335613ae2colin.king@canonical.com >
Link: https://lore.kernel.org/r/20210907104658.14706-1-colin.king@canonical.com
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
Johannes Berg
b26ea3f6b7
iwlwifi: pcie: gen2: fix locking when "HW not ready"
...
commit 4c29c1e27a1e178a219b3877d055e6dd643bdfda upstream.
If we run into this error path, we shouldn't unlock the mutex
since it's not locked since. Fix this in the gen2 code as well.
Fixes: eda50cde58johannes.berg@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@kernel.org >
Link: https://lore.kernel.org/r/iwlwifi.20220128142706.b8b0dfce16ef.Ie20f0f7b23e5911350a2766524300d2915e7b677@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2022-02-23 12:01:01 +01:00
Johannes Berg
8867f99379
iwlwifi: pcie: fix locking when "HW not ready"
...
commit e9848aed147708a06193b40d78493b0ef6abccf2 upstream.
If we run into this error path, we shouldn't unlock the mutex
since it's not locked since. Fix this.
Fixes: a6bd005fe9johannes.berg@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@kernel.org >
Link: https://lore.kernel.org/r/iwlwifi.20220128142706.5d16821d1433.Id259699ddf9806459856d6aefbdbe54477aecffd@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2022-02-23 12:01:01 +01:00
Johannes Berg
008508c16a
iwlwifi: fix use-after-free
...
commit bea2662e7818e15d7607d17d57912ac984275d94 upstream.
If no firmware was present at all (or, presumably, all of the
firmware files failed to parse), we end up unbinding by calling
device_release_driver(), which calls remove(), which then in
iwlwifi calls iwl_drv_stop(), freeing the 'drv' struct. However
the new code I added will still erroneously access it after it
was freed.
Set 'failure=false' in this case to avoid the access, all data
was already freed anyway.
Cc: stable@vger.kernel.org
Reported-by: Stefan Agner <stefan@agner.ch >
Reported-by: Wolfgang Walter <linux@stwm.de >
Reported-by: Jason Self <jason@bluehome.net >
Reported-by: Dominik Behr <dominik@dominikbehr.com >
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com >
Fixes: ab07506b0454 ("iwlwifi: fix leaks/bad data after failed firmware load")
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Signed-off-by: Kalle Valo <kvalo@kernel.org >
Link: https://lore.kernel.org/r/20220208114728.e6b514cf4c85.Iffb575ca2a623d7859b542c33b2a507d01554251@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2022-02-23 12:01:00 +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
Luca Coelho
d817d10f7a
iwlwifi: pcie: make sure prph_info is set when treating wakeup IRQ
...
[ Upstream commit 459fc0f2c6b0f6e280bfa0f230c100c9dfe3a199 ]
In some rare cases when the HW is in a bad state, we may get this
interrupt when prph_info is not set yet. Then we will try to
dereference it to check the sleep_notif element, which will cause an
oops.
Fix that by ignoring the interrupt if prph_info is not set yet.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.0537aa562313.I183bb336345b9b3da196ba9e596a6f189fbcbd09@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
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
Johannes Berg
6e44b60054
iwlwifi: remove module loading failure message
...
[ Upstream commit 6518f83ffa51131daaf439b66094f684da3fb0ae ]
When CONFIG_DEBUG_TEST_DRIVER_REMOVE is set, iwlwifi crashes
when the opmode module cannot be loaded, due to completing
the completion before using drv->dev, which can then already
be freed.
Fix this by removing the (fairly useless) message. Moving the
completion later causes a deadlock instead, so that's not an
option.
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/20211210091245.289008-2-luca@coelho.fi
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2022-01-27 10:54:17 +01:00
Johannes Berg
febab6b60d
iwlwifi: fix leaks/bad data after failed firmware load
...
[ Upstream commit ab07506b0454bea606095951e19e72c282bfbb42 ]
If firmware load fails after having loaded some parts of the
firmware, e.g. the IML image, then this would leak. For the
host command list we'd end up running into a WARN on the next
attempt to load another firmware image.
Fix this by calling iwl_dealloc_ucode() on failures, and make
that also clear the data so we start fresh on the next round.
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.20211210110539.1f742f0eb58a.I1315f22f6aa632d94ae2069f85e1bca5e734dce0@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2022-01-27 10:54:17 +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
Lv Yunlong
bb0579ab50
wireless: iwlwifi: Fix a double free in iwl_txq_dyn_alloc_dma
...
[ Upstream commit f973795a8d19cbf3d03807704eb7c6ff65788d5a ]
In iwl_txq_dyn_alloc_dma, txq->tfds is freed at first time by:
iwl_txq_alloc()->goto err_free_tfds->dma_free_coherent(). But
it forgot to set txq->tfds to NULL.
Then the txq->tfds is freed again in iwl_txq_dyn_alloc_dma by:
goto error->iwl_txq_gen2_free_memory()->dma_free_coherent().
My patch sets txq->tfds to NULL after the first free to avoid the
double free.
Fixes: 0cd1ad2d7flyl2019@mail.ustc.edu.cn >
Link: https://lore.kernel.org/r/20210403054755.4781-1-lyl2019@mail.ustc.edu.cn
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2022-01-27 10:53:54 +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
Vladimir Zapolskiy
29a19eaeb2
iwlwifi: pcie: add configuration of a Wi-Fi adapter on Dell XPS 15
...
[ Upstream commit fe5c735d0d47b495be6753d6aea4f8f78c909a0a ]
There is a Killer AX1650 2x2 Wi-Fi 6 and Bluetooth 5.1 wireless adapter
found on Dell XPS 15 (9510) laptop, its configuration was present on
Linux v5.7, however accidentally it has been removed from the list of
supported devices, let's add it back.
The problem is manifested on driver initialization:
Intel(R) Wireless WiFi driver for Linux
iwlwifi 0000:00:14.3: enabling device (0000 -> 0002)
iwlwifi: No config found for PCI dev 43f0/1651, rev=0x354, rfid=0x10a100
iwlwifi: probe of 0000:00:14.3 failed with error -22
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=213939
Fixes: 3f910a2583felash@gmail.com >
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org >
Acked-by: Luca Coelho <luca@coelho.fi >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/20210924122154.2376577-1-vladimir.zapolskiy@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-10-13 10:04:26 +02: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
a693aff5e8
iwlwifi: fw: correctly limit to monitor dump
...
[ Upstream commit e6344c060209ef4e970cac18adeac1676a2a73cd ]
In commit 79f033f6f2johannes.berg@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20210805141826.774fd8729a33.Ic985a787071d1c0b127ef0ba8367da896ee11f57@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
Johannes Berg
608c8359c5
iwlwifi: pcie: free RBs during configure
...
[ Upstream commit 6ac5720086c8b176794eb74c5cc09f8b79017f38 ]
When switching op-modes, or more generally when reconfiguring,
we might switch the RB size. In _iwl_pcie_rx_init() we have a
comment saying we must free all RBs since we might switch the
size, but this is actually too late: the switch has been done
and we'll free the buffers with the wrong size.
Fix this by always freeing the buffers, if any, at the start
of configure, instead of only after the size may have changed.
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.20210802170640.42d7c93279c4.I07f74e65aab0e3d965a81206fcb289dc92d74878@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
Justin M. Forbes
75ffcd85df
iwlwifi Add support for ax201 in Samsung Galaxy Book Flex2 Alpha
...
commit 2f32c147a3816d789722c0bd242a9431332ec3ed upstream.
The Samsung Galaxy Book Flex2 Alpha uses an ax201 with the ID a0f0/6074.
This works fine with the existing driver once it knows to claim it.
Simple patch to add the device.
Signed-off-by: Justin M. Forbes <jforbes@fedoraproject.org >
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/20210702223155.1981510-1-jforbes@fedoraproject.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2021-09-15 09:50:46 +02:00
Abhishek Naik
bd6d9c83f4
iwlwifi: skip first element in the WTAS ACPI table
...
[ Upstream commit 19426d54302e199b3fd2d575f926a13af66be2b9 ]
By mistake we were considering the first element of the WTAS wifi
package as part of the data we want to rid, but that element is the wifi
package signature (always 0x07), so it should be skipped.
Change the code to read the data starting from element 1 instead.
Signed-off-by: Abhishek Naik <abhishek.naik@intel.com >
Fixes: 28dd7ccdc5luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20210805141826.ff8148197b15.I70636c04e37b2b57a5df3ce611511f62203d27a7@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
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
Johannes Berg
be37f7dbcd
iwlwifi: pnvm: accept multiple HW-type TLVs
...
[ Upstream commit 0f673c16c850250db386537a422c11d248fb123c ]
Some products (So) may have two different types of products
with different mac-type that are otherwise equivalent, and
have the same PNVM data, so the PNVM file will contain two
(or perhaps later more) HW-type TLVs. Accept the file and
use the data section that contains any matching entry.
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/20210719140154.a6a86e903035.Ic0b1b75c45d386698859f251518e8a5144431938@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-09-03 10:09:26 +02:00
Johannes Berg
7cd6986f2d
iwlwifi: pcie: fix context info freeing
...
[ Upstream commit 26d18c75a7496c4c52b0b6789e713dc76ebfbc87 ]
After firmware alive, iwl_trans_pcie_gen2_fw_alive() is called
to free the context info. However, on gen3 that will then free
the context info with the wrong size.
Since we free this allocation later, let it stick around until
the device is stopped for now, freeing some of it earlier is a
separate change.
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.20210618105614.afb63fb8cbc1.If4968db8e09f4ce2a1d27a6d750bca3d132d7d70@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
b98ec6d8b3
iwlwifi: pcie: free IML DMA memory allocation
...
[ Upstream commit 310f60f53a86eba680d9bc20a371e13b06a5f903 ]
In the case of gen3 devices with image loader (IML) support,
we were leaking the IML DMA allocation and never freeing it.
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.20210618105614.07e117dbedb7.I7bb9ebbe0617656986c2a598ea5e827b533bd3b9@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
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
Luca Coelho
db2386fa43
iwlwifi: increase PNVM load timeout
...
[ Upstream commit 5cc816ef9db1fe03f73e56e9d8f118add9c6efe4 ]
The FW has a watchdog of 200ms in the PNVM load flow, so the driver
should have a slightly higher timeout. Change the timeout from 100ms
to 250ms.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Fixes: 70d3ca86b0luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20210612142637.ba22aec1e2be.I36bfadc28c480f4fc57266c075a79e8ea4a6934f@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-07-14 16:56:25 +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
Johannes Berg
26f98b2d97
iwlwifi: pcie: make cfg vs. trans_cfg more robust
...
[ Upstream commit 48a5494d6a4cb5812f0640d9515f1876ffc7a013 ]
If we (for example) have a trans_cfg entry in the PCI IDs table,
but then don't find a full cfg entry for it in the info table,
we fall through to the code that treats the PCI ID table entry
as a full cfg entry. This obviously causes crashes later, e.g.
when trying to build the firmware name string.
Avoid such crashes by using the low bit of the pointer as a tag
for trans_cfg entries (automatically using a macro that checks
the type when assigning) and then checking that before trying to
use the data as a full entry - if it's just a partial entry at
that point, fail.
Since we're adding some macro magic, also check that the type is
in fact either struct iwl_cfg_trans_params or struct iwl_cfg,
failing compilation ("initializer element is not constant") if
it isn't.
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.20210330162204.6f69fe6e4128.I921d4ae20ef5276716baeeeda0b001cf25b9b968@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-05-19 10:12:56 +02:00
Dan Carpenter
c9996845ff
ipw2x00: potential buffer overflow in libipw_wx_set_encodeext()
...
commit 260a9ad9446723d4063ed802989758852809714d upstream.
The "ext->key_len" is a u16 that comes from the user. If it's over
SCM_KEY_LEN (32) that could lead to memory corruption.
Fixes: e0d369d1d9stable@vger.kernel.org
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com >
Acked-by: Stanislav Yakovlev <stas.yakovlev@gmail.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/YHaoA1i+8uT4ir4h@mwanda
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2021-05-14 09:50:00 +02:00
Jiri Kosina
2a442f1140
iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_gen2_enqueue_hcmd()
...
commit e7020bb068d8be50a92f48e36b236a1a1ef9282e upstream.
Analogically to what we did in 2800aadc18a6 ("iwlwifi: Fix softirq/hardirq
disabling in iwl_pcie_enqueue_hcmd()"), we must apply the same fix to
iwl_pcie_gen2_enqueue_hcmd(), as it's being called from exactly the same
contexts.
Reported-by: Heiner Kallweit <hkallweit1@gmail.com
Signed-off-by: Jiri Kosina <jkosina@suse.cz >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2104171112390.18270@cbobk.fhfr.pm
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2021-05-02 11:06:08 +02:00
Matt Chen
8b9485b651
iwlwifi: add support for Qu with AX201 device
...
[ Upstream commit 97195d3cad852063208a1cd4f4d073459547a415 ]
Add this specific Samsung AX201 sku to driver so it can be
detected and initialized successfully.
Signed-off-by: Matt Chen <matt.chen@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.20210326125611.30b622037714.Id9fd709cf1c8261c097bbfd7453f6476077dcafc@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-04-21 13:00:52 +02:00
Jiri Kosina
806addaf8d
iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_enqueue_hcmd()
...
[ Upstream commit 2800aadc18a64c96b051bcb7da8a7df7d505db3f ]
It's possible for iwl_pcie_enqueue_hcmd() to be called with hard IRQs
disabled (e.g. from LED core). We can't enable BHs in such a situation.
Turn the unconditional BH-enable/BH-disable code into
hardirq-disable/conditional-enable.
This fixes the warning below.
WARNING: CPU: 1 PID: 1139 at kernel/softirq.c:178 __local_bh_enable_ip+0xa5/0xf0
CPU: 1 PID: 1139 Comm: NetworkManager Not tainted 5.12.0-rc1-00004-gb4ded168af79 #7
Hardware name: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16 ) 05/31/2017
RIP: 0010:__local_bh_enable_ip+0xa5/0xf0
Code: f7 69 e8 ee 23 14 00 fb 66 0f 1f 44 00 00 65 8b 05 f0 f4 f7 69 85 c0 74 3f 48 83 c4 08 5b c3 65 8b 05 9b fe f7 69 85 c0 75 8e <0f> 0b eb 8a 48 89 3c 24 e8 4e 20 14 00 48 8b 3c 24 eb 91 e8 13 4e
RSP: 0018:ffffafd580b13298 EFLAGS: 00010046
RAX: 0000000000000000 RBX: 0000000000000201 RCX: 0000000000000000
RDX: 0000000000000003 RSI: 0000000000000201 RDI: ffffffffc1272389
RBP: ffff96517ae4c018 R08: 0000000000000001 R09: 0000000000000000
R10: ffffafd580b13178 R11: 0000000000000001 R12: ffff96517b060000
R13: 0000000000000000 R14: ffffffff80000000 R15: 0000000000000001
FS: 00007fc604ebefc0(0000) GS:ffff965267480000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055fb3fef13b2 CR3: 0000000109112004 CR4: 00000000003706e0
Call Trace:
? _raw_spin_unlock_bh+0x1f/0x30
iwl_pcie_enqueue_hcmd+0x5d9/0xa00 [iwlwifi]
iwl_trans_txq_send_hcmd+0x6c/0x430 [iwlwifi]
iwl_trans_send_cmd+0x88/0x170 [iwlwifi]
? lock_acquire+0x277/0x3d0
iwl_mvm_send_cmd+0x32/0x80 [iwlmvm]
iwl_mvm_led_set+0xc2/0xe0 [iwlmvm]
? led_trigger_event+0x46/0x70
led_trigger_event+0x46/0x70
ieee80211_do_open+0x5c5/0xa20 [mac80211]
ieee80211_open+0x67/0x90 [mac80211]
__dev_open+0xd4/0x150
__dev_change_flags+0x19e/0x1f0
dev_change_flags+0x23/0x60
do_setlink+0x30d/0x1230
? lock_is_held_type+0xb4/0x120
? __nla_validate_parse.part.7+0x57/0xcb0
? __lock_acquire+0x2e1/0x1a50
__rtnl_newlink+0x560/0x910
? __lock_acquire+0x2e1/0x1a50
? __lock_acquire+0x2e1/0x1a50
? lock_acquire+0x277/0x3d0
? sock_def_readable+0x5/0x290
? lock_is_held_type+0xb4/0x120
? find_held_lock+0x2d/0x90
? sock_def_readable+0xb3/0x290
? lock_release+0x166/0x2a0
? lock_is_held_type+0x90/0x120
rtnl_newlink+0x47/0x70
rtnetlink_rcv_msg+0x25c/0x470
? netlink_deliver_tap+0x97/0x3e0
? validate_linkmsg+0x350/0x350
netlink_rcv_skb+0x50/0x100
netlink_unicast+0x1b2/0x280
netlink_sendmsg+0x336/0x450
sock_sendmsg+0x5b/0x60
____sys_sendmsg+0x1ed/0x250
? copy_msghdr_from_user+0x5c/0x90
___sys_sendmsg+0x88/0xd0
? lock_is_held_type+0xb4/0x120
? find_held_lock+0x2d/0x90
? lock_release+0x166/0x2a0
? __fget_files+0xfe/0x1d0
? __sys_sendmsg+0x5e/0xa0
__sys_sendmsg+0x5e/0xa0
? lockdep_hardirqs_on_prepare+0xd9/0x170
do_syscall_64+0x33/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fc605c9572d
Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 da ee ff ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 2e ef ff ff 48
RSP: 002b:00007fffc83789f0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 000055ef468570c0 RCX: 00007fc605c9572d
RDX: 0000000000000000 RSI: 00007fffc8378a30 RDI: 000000000000000c
RBP: 0000000000000010 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
R13: 00007fffc8378b80 R14: 00007fffc8378b7c R15: 0000000000000000
irq event stamp: 170785
hardirqs last enabled at (170783): [<ffffffff9609a8c2>] __local_bh_enable_ip+0x82/0xf0
hardirqs last disabled at (170784): [<ffffffff96a8613d>] _raw_read_lock_irqsave+0x8d/0x90
softirqs last enabled at (170782): [<ffffffffc1272389>] iwl_pcie_enqueue_hcmd+0x5d9/0xa00 [iwlwifi]
softirqs last disabled at (170785): [<ffffffffc1271ec6>] iwl_pcie_enqueue_hcmd+0x116/0xa00 [iwlwifi]
Signed-off-by: Jiri Kosina <jkosina@suse.cz >
Tested-by: Sedat Dilek <sedat.dilek@gmail.com > # LLVM/Clang v12.0.0-rc3
Acked-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2103021125430.12405@cbobk.fhfr.pm
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-04-21 13:00:51 +02:00
Luca Coelho
a96f1ed709
iwlwifi: fix 11ax disabled bit in the regulatory capability flags
...
[ Upstream commit 07cc40fec9a85e669ea12e161a438d2cbd76f1ed ]
When version 2 of the regulatory capability flags API was implemented,
the flag to disable 11ax was defined as bit 13, but this was later
changed and the bit remained as bit 10, like in version 1. This was
never changed in the driver, so we were checking for the wrong bit in
newer devices. Fix it.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Fixes: e27c506a98luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20210326125611.6d28516b59cd.Id0248d5e4662695254f49ce37b0268834ed52918@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-04-14 08:42:11 +02:00
