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
Johannes Berg
6bd4e82292
iwlwifi: pcie: properly set LTR workarounds on 22000 devices
...
commit 25628bc08d4526d3673ca7d039eb636aa9006076 upstream.
As the context info gen3 code is only called for >=AX210 devices
(from iwl_trans_pcie_gen2_start_fw()) the code there to set LTR
on 22000 devices cannot actually do anything (22000 < AX210).
Fix this by moving the LTR code to iwl_trans_pcie_gen2_start_fw()
where it can handle both devices. This then requires that we kick
the firmware only after that rather than doing it from the context
info code.
Note that this again had a dead branch in gen3 code, which I've
removed here.
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Fixes: ed0022da8bd9 ("iwlwifi: pcie: set LTR on more devices")
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.675486178ed1.Ib61463aba6920645059e366dcdca4c4c77f0ff58@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2021-04-14 08:42:00 +02:00
Johannes Berg
221528c20e
iwlwifi: pcie: don't disable interrupts for reg_lock
...
[ Upstream commit 874020f8adce535cd318af1768ffe744251b6593 ]
The only thing we do touching the device in hard interrupt context
is, at most, writing an interrupt ACK register, which isn't racing
in with anything protected by the reg_lock.
Thus, avoid disabling interrupts here for potentially long periods
of time, particularly long periods have been observed with dumping
of firmware memory (leading to lockup warnings on some devices.)
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.20210210135352.da916ab91298.I064c3e7823b616647293ed97da98edefb9ce9435@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-04-07 15:00:07 +02:00
Matti Gottlieb
e1a69079ed
iwlwifi: Add a new card for MA family
...
[ Upstream commit ac1a98e1e924e7e8d7c7e5b1ca8ddc522e10ddd0 ]
Add a PCI ID for snj with mr in AX family.
Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com >
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20201209231352.101ac3058c04.Idd28706b122cdc8103956f8e72bb062fe4adb54e@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-03-25 09:04:13 +01:00
Luca Coelho
45c720ca5d
iwlwifi: pnvm: increment the pointer before checking the TLV
...
[ Upstream commit ff11a8ee2d2d0f78514ac9b42fb50c525ca695c7 ]
If the SKU_ID doesn't match, we don't increment the pointer and keep
checking the same TLV over and over again.
We need to increment the pointer in all situtations, namely if the TLV
is not a SKU_ID, if the SKU_ID matched or if the SKU_ID didn't match.
So we can increment the pointer already before checking for these
conditions to solve the problem.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Fixes: 6972592850luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20210210172142.de94d366f3ff.I9a5a54906cf0f4ec8af981d6066bfd771152ffb9@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-03-04 11:37:30 +01:00
Luca Coelho
47708895c9
iwlwifi: pnvm: set the PNVM again if it was already loaded
...
[ Upstream commit 4a81598f0f39cffbf1c29c4a184063d513661c4a ]
When the interface goes up, we have already loaded the PNVM during
init, so we don't load it anymore. But we still need to set the PNVM
values in the context so that the FW can load it again.
Call set_pnvm when the PNVM is already loaded and change the
trans_pcie implementation to accept a second call to set_pnvm when we
have already allocated and, in this case, only set the values without
allocating again.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Fixes: 6972592850luciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20210210172142.622546a3566f.I659a8b9aa944d213c4ba446e142d74f3f6db9c64@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-03-04 11:37:30 +01: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
6fb6d5410e
iwlwifi: queue: bail out on invalid freeing
...
[ Upstream commit 0bed6a2a14afaae240cc431e49c260568488b51c ]
If we find an entry without an SKB, we currently continue, but
that will just result in an infinite loop since we won't increment
the read pointer, and will try the same thing over and over again.
Fix this.
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.abe2dedcc3ac.Ia6b03f9eeb617fd819e56dd5376f4bb8edc7b98a@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-02-13 13:55:11 +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
Luca Coelho
2262294d42
iwlwifi: pcie: add rules to match Qu with Hr2
...
[ Upstream commit 16062c12edb8ed2dfb15e6a914ff4edf858ab9e0 ]
Until now we have been relying on matching the PCI ID and subsystem
device ID in order to recognize Qu devices with Hr2. Add rules to
match these devices, so that we don't have to add a new rule for every
new ID we get.
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.591ce253ddd8.Ia4b9cc2c535625890c6d6b560db97ee9f2d5ca3b@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-02-13 13:55:10 +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
05132a72cc
iwlwifi: pcie: fix context info memory leak
...
[ Upstream commit 2d6bc752cc2806366d9a4fd577b3f6c1f7a7e04e ]
If the image loader allocation fails, we leak all the previously
allocated memory. Fix this.
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.97172cbaa67c.I3473233d0ad01a71aa9400832fb2b9f494d88a11@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-02-13 13:55:09 +01:00
Emmanuel Grumbach
fbdf0bf97c
iwlwifi: pcie: add a NULL check in iwl_pcie_txq_unmap
...
[ Upstream commit 98c7d21f957b10d9c07a3a60a3a5a8f326a197e5 ]
I hit a NULL pointer exception in this function when the
init flow went really bad.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@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.2e8da9f2c132.I0234d4b8ddaf70aaa5028a20c863255e05bc1f84@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
Johannes Berg
a59a7b96dc
iwlwifi: pcie: reschedule in long-running memory reads
...
[ Upstream commit 3d372c4edfd4dffb7dea71c6b096fb414782b776 ]
If we spin for a long time in memory reads that (for some reason in
hardware) take a long time, then we'll eventually get messages such
as
watchdog: BUG: soft lockup - CPU#2 stuck for 24s! [kworker/2:2:272]
This is because the reading really does take a very long time, and
we don't schedule, so we're hogging the CPU with this task, at least
if CONFIG_PREEMPT is not set, e.g. with CONFIG_PREEMPT_VOLUNTARY=y.
Previously I misinterpreted the situation and thought that this was
only going to happen if we had interrupts disabled, and then fixed
this (which is good anyway, however), but that didn't always help;
looking at it again now I realized that the spin unlock will only
reschedule if CONFIG_PREEMPT is used.
In order to avoid this issue, change the code to cond_resched() if
we've been spinning for too long here.
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Fixes: 04516706bbluciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20210115130253.217a9d6a6a12.If964cb582ab0aaa94e81c4ff3b279eaafda0fd3f@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-02-03 23:28:47 +01:00
Johannes Berg
bcb9c40096
iwlwifi: pcie: use jiffies for memory read spin time limit
...
[ Upstream commit 6701317476bbfb1f341aa935ddf75eb73af784f9 ]
There's no reason to use ktime_get() since we don't need any better
precision than jiffies, and since we no longer disable interrupts
around this code (when grabbing NIC access), jiffies will work fine.
Use jiffies instead of ktime_get().
This cleanup is preparation for the following patch "iwlwifi: pcie: reschedule
in long-running memory reads". The code gets simpler with the weird clock use
etc. removed before we add cond_resched().
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.20210115130253.621c948b1fad.I3ee9f4bc4e74a0c9125d42fb7c35cd80df4698a1@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-02-03 23:28:47 +01:00
Johannes Berg
05bb42538d
iwlwifi: pcie: set LTR on more devices
...
[ Upstream commit ed0022da8bd9a3ba1c0e1497457be28d52afa7e1 ]
To avoid completion timeouts during device boot, set up the
LTR timeouts on more devices - similar to what we had before
for AX210.
This also corrects the AX210 workaround to be done only on
discrete (non-integrated) devices, otherwise the registers
have no effect.
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Fixes: edb625208dluciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20210115130252.fb819e19530b.I0396f82922db66426f52fbb70d32a29c8fd66951@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-02-03 23:28:47 +01:00
Johannes Berg
92044488a8
iwlwifi: pnvm: don't try to load after failures
...
[ Upstream commit 82a08d0cd7b503be426fb856a0fb73c9c976aae1 ]
If loading the PNVM file failed on the first try during the
interface up, the file is unlikely to show up later, and we
already don't try to reload it if it changes, so just don't
try loading it again and again.
This also fixes some issues where we may try to load it at
resume time, which may not be possible yet.
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Fixes: 6972592850luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20210115130252.5ac6828a0bbe.I7d308358b21d3c0c84b1086999dbc7267f86e219@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-02-03 23:28:47 +01:00
Johannes Berg
fb1e501d8a
iwlwifi: pnvm: don't skip everything when not reloading
...
[ Upstream commit 1c58bed4b7f7551239b9005ad0a9a6566a3d9fbe ]
Even if we don't reload the file from disk, we still need to
trigger the PNVM load flow with the device; fix that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Fixes: 6972592850luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20210115130252.85ef56c4ef8c.I3b853ce041a0755d45e448035bef1837995d191b@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-02-03 23:28:47 +01:00
Johannes Berg
c00b0b65b3
iwlwifi: pcie: avoid potential PNVM leaks
...
[ Upstream commit 34b9434cd0d425330a0467e767f8d047ef62964d ]
If we erroneously try to set the PNVM data again after it has
already been set, we could leak the old DMA memory. Avoid that
and warn, we shouldn't be doing this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Fixes: 6972592850luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20210115130252.929c2d680429.I086b9490e6c005f3bcaa881b617e9f61908160f3@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org >
2021-02-03 23:28:47 +01:00
Matti Gottlieb
800ca7687c
iwlwifi: Fix IWL_SUBDEVICE_NO_160 macro to use the correct bit.
...
commit 4886460c4d1576e85b12601b8b328278a483df86 upstream.
The bit that indicates if the device supports 160MHZ
is bit #9 . The macro checks bit #8 .
Fix IWL_SUBDEVICE_NO_160 macro to use the correct bit.
Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com >
Fixes: d6f2134a38luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20210122144849.bddbf9b57a75.I16e09e2b1404b16bfff70852a5a654aa468579e2@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2021-02-03 23:28:42 +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
Takashi Iwai
08a922a6fd
iwlwifi: dbg: Don't touch the tlv data
...
commit a6616bc9a0af7c65c0b0856a7508870a4a40c4ac upstream.
The commit ba8f6f4ae2ba8f6f4ae2https://bugzilla.suse.com/show_bug.cgi?id=1180344
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=210733
Cc: stable@vger.kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de >
Acked-by: Luca Coelho <luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/20210112132449.22243-2-tiwai@suse.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2021-01-30 13:55:18 +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
Johannes Berg
31269e6ac0
iwlwifi: dbg-tlv: fix old length in is_trig_data_contained()
...
[ Upstream commit 58a1c9f9a9b6b9092ae10b84f6b571a06596e296 ]
There's a bug in the lengths - the 'old length' needs to be calculated
using the 'old' pointer, of course, likely a copy/paste mistake. Fix
this.
Reported-by: Daniel Gabay <daniel.gabay@intel.com >
Signed-off-by: Johannes Berg <johannes.berg@intel.com >
Fixes: cf29c5b66bluciano.coelho@intel.com >
Link: https://lore.kernel.org/r/iwlwifi.20201209231352.c0105ddffa74.I1ddb243053ff763c91b663748b6a593ecc3b5634@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
Golan Ben Ami
9b15596c50
iwlwifi: pcie: add some missing entries for AX210
...
Some subsytem device IDs were missing from the list, so some AX210
devices were not recognized. Add them.
Signed-off-by: Golan Ben Ami <golan.ben.ami@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.20201202143859.a06ba7540449.I7390305d088a49c1043c9b489154fe057989c18f@changeid
Link: https://lore.kernel.org/r/20201121003411.9450-1-ikegami.t@gmail.com
2020-12-02 21:01:35 +02:00
Luca Coelho
568d343417
iwlwifi: pcie: invert values of NO_160 device config entries
...
The NO_160 flag specifies if the device doesn't have 160 MHz support,
but we errorneously assumed the opposite. If the flag was set, we
were considering that 160 MHz was supported, but it's actually the
opposite. Fix it by inverting the bits, i.e. NO_160 is 0x1 and 160
is 0x0.
Fixes: d6f2134a38luciano.coelho@intel.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/iwlwifi.20201202143859.375bec857ccb.I83884286b688965293e9810381808039bd7eedae@changeid
2020-12-02 21:01:33 +02:00
