Add support for different combinations of Bz
and CRFs.
Note: As of now we do not know the exact values
for ltr_delay and xtal_latency, so for now use the
worst case scenario values until the actual values
are clarified.
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.20210330162204.caac8d996532.I6a22d6decb106cd50d7954b19236b69d685dcc39@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
We currently have a special, separate, code path to acquire NIC
access for the in-flight host-command workaround on 7000 series
hardware. However, the normal code path here has grown a number
of additional workarounds/semantics over time, such as reprobing
the device if things fail.
Rather than try to replicate any of this logic, call the normal
grab_nic_access logic for the workaround.
This changes the spinlock to _bh, but that's OK since it's just
redundant, we already have soft-IRQs disabled when we get here,
and so didn't (have to) do it again. Since it's only for commands
there's however no point in making the code more complex just to
not use _bh here.
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.d196fc6ffb23.Idc1ce3ce9fed9178beee7e5409bc669f79b06a0d@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Most devices don't set the apmg_wake_up_wa flag, so we don't do
anything for them. Avoid taking the spinlock for every command
unless the device needs this workaround.
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.1ab60af3f318.I51cc202f68a2a953223e70c3e8610343412961b6@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
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: ed0022da8b ("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
Randy reported an error on his randconfig builds:
ERROR: modpost: "iwl_so_trans_cfg" [drivers/net/wireless/intel/iwlwifi/iwlwifi.ko] undefined!
The problem was that when CONFIG_IWLMVM was disabled we were still accessing
iwl_so_trans_cfg. Fix it by moving IS_ENABLED() check before the access.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Fixes: 930be4e76f ("iwlwifi: add support for SnJ with Jf devices")
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Acked-by: Luca Coelho <luciano.coelho@intel.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1614236661-20274-1-git-send-email-kvalo@codeaurora.org
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: 6972592850 ("iwlwifi: read and parse PNVM file")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210210172142.622546a3566f.I659a8b9aa944d213c4ba446e142d74f3f6db9c64@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Some new devices contain an extra bit in the CRF ID register to denote
that they support CDB. Add definitions and macros to be able to
support it and add the "NO_CDB" to all existing entired.
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.20210210142629.7b40184d9899.I3bb2cf9b9afb0457583f786dc52d4d1b1ad75ffc@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Remember that those pointers have been freed by setting them
to NULL. Otherwise, we'd keep rxq pointing to random memory
which would prevent us from trying to re-allocate the Rx
resources if we call rx_alloc again.
Also, propagate the allocation failure to the caller of
iwl_pcie_nic_init so that we won't go further in the
start flow.
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.20210210135352.996b400d2f1c.I630379c504644700322f57b259383ae0af8d1975@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
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>
* Check FW notification sizes for robustness;
* Improvements in the NAPI implementation;
* Implement a workaround for CCA-EXT;
* Add new FW API support;
* Fix a CSA bug;
* Implement PHY integration version parsing;
* A bit of refactoring;
* One more CSA bug fix, this time in the AP side;
* Support for new So devices and a bit of reorg;
* Per Platform Antenna Gain (PPAG) fixes and improvements;
* Improvements in the debug framework;
* Some other clean-ups and small fixes.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEF3LNfgb2BPWm68smoUecoho8xfoFAmAdGCUACgkQoUecoho8
xfqbGxAAlKXsYDTey4bCNbG3aimBGyNkmOBrAAcsH/zxZ4UHzUGLl0xflMZwpT9S
XXYBnR/q8lb7lZ+0zj/Jc4R2D8DKGhKwQ1Q+ZINRm7pEgJ3hZZlgvPgWeyOi+z0Y
DnCD8Ga2lJPmyqwxipMgL1wi5POKOTFjWwTe8cCQ5xy6EkGVpNi+PdZitFubq0Oj
oAOe6st6v/GgtqGHh8TNX11pWadoBhqkkdlPEnuSvx9MAxSYtrued4vs8MowNP9i
tkak8+eeEfLbfyY/sxvgClFR4T072/QvUoofPMyoCyo+cBa42EMXHRzk6fAUxZ1t
brjJFOUnuACCmU2CfzoZTdZPMDB/x4vk6UWIf2p0kL7paRt/IVMb2/DNuTo042Z1
6xPBoUXyPzL7sH2leZ/Pj9aNMxfK5mhLVMn/htedaMfjdNX52MfgVmyAR2zcq0iC
r4xtq1xi/+GFmT1AYXIYGVqkwE/aSTNqi+0oTRK8u2g5CbokRVJnWnUido0Hnlg0
yS2l0gU7UyNFj9LHOVR8UP0oD7myDkkrqTeY9Us+ncLtYXmqx0dnFbvWucIrSHvL
BVKZzgYXnFbCghSlHb2ZJN4nxKzq8rxkBBv7CZMPneK1VYEyTichUo3b4gzFTfIy
9EP0GzKPQStxaDzAfr9cju0IvvCW1O0vA6gGAe0D+bHVYhqi/TA=
=c570
-----END PGP SIGNATURE-----
Merge tag 'iwlwifi-next-for-kalle-2021-02-05' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
iwlwifi patches intended for v5.12
* Check FW notification sizes for robustness;
* Improvements in the NAPI implementation;
* Implement a workaround for CCA-EXT;
* Add new FW API support;
* Fix a CSA bug;
* Implement PHY integration version parsing;
* A bit of refactoring;
* One more CSA bug fix, this time in the AP side;
* Support for new So devices and a bit of reorg;
* Per Platform Antenna Gain (PPAG) fixes and improvements;
* Improvements in the debug framework;
* Some other clean-ups and small fixes.
# gpg: Signature made Fri 05 Feb 2021 12:04:21 PM EET using RSA key ID 1A3CC5FA
# gpg: Good signature from "Luciano Roth Coelho (Luca) <luca@coelho.fi>"
# gpg: aka "Luciano Roth Coelho (Intel) <luciano.coelho@intel.com>"
When Rx queues are configured during module init, NAPI is enabled
while the Rx queue lock is held. However, since softirqs are not
disabled, it is possible that and IRQ would fire and call
iwl_pcie_rx_handle() which would also try to acquire the Rx lock.
Prevent this by disabling softirqs during Rx queue configuration,
as part of module init flow.
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.20210205110447.d206ac428823.Ia19339efb09f9d80143f0d0e398a158180754cfa@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Handling host commands in a sync way is not directly related to PCIe
transport, and can serve as common logic for any transport, so move
it to trans layer.
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117164916.fde99af4e0f7.I4cab95919eb35cc5bfb26d32dcf5e15419d0e0ef@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
D3_CONFIG_CMD and D0I3_END_CMD should be the last\first
command upon suspend\resume correspondingly, otherwise,
FW will raise an assert (0x342).
There are firmware notifications that cause the driver to
send a command back to the firmware. If such a notification
is sent to the driver while the the driver prepares the
firmware for D3, operation, what is likely to happen is that
the handling of the notification will try to get the mutex
and will wait unil the driver finished configuring the
firmware for D3. Then the handling notification will get
the mutex and handle the notification which will lead to
the aforementioned ASSERT 342.
To avoid this, we need to prevent any command to be sent to
the firmware between the D3_CONFIG_CMD and the D0I3_END_CMD.
Check this in the utility layer that sends the host commands
and in the transport layer as well.
Flag the D3_CONFIG_CMD and the D0I3_END_CMD commands as
commands that must be sent even if the firmware has already
been configured for D3 operation.
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117164916.1935a993b471.I3192c93c030576ca16773c01b009c4d93610d6ea@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Instead of pretending to have NAPI and then relying entirely on
interrupts anyway, properly implement NAPI and schedule the poll
when we get an interrupt, re-enabling the interrupt only after
the poll completed.
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.20210117130510.a5951ac4fc06.I9c84a147288fcfb1b019572c6758f2d92949f5d7@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
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: 04516706bb ("iwlwifi: pcie: limit memory read spin time")
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.217a9d6a6a12.If964cb582ab0aaa94e81c4ff3b279eaafda0fd3f@changeid
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
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: edb625208d ("iwlwifi: pcie: set LTR to avoid completion timeout")
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.fb819e19530b.I0396f82922db66426f52fbb70d32a29c8fd66951@changeid
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: 6972592850 ("iwlwifi: read and parse PNVM file")
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.929c2d680429.I086b9490e6c005f3bcaa881b617e9f61908160f3@changeid
There are some races in the hardware that can possibly lead to
a bus lockup later during a restart when we manage to kill the
firmware at a bad time (while it's accessing the bus).
To work around this, add support for a new handshake between
firmware and driver to ensure that the firmware is in a well-
known state before we kill it.
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.20201209231352.7756fcc9865c.I13de65e0ffcb4186dd4c1a465f66df2e98c9a947@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
We don't need the sequence/index/cmd_index unless we're doing
reclaim, they're not even valid in the other cases. Move the
variables and their assignments into the right if statement
and combine the two if statements into a single one 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.20201209231352.6207fdcc91a9.Ia71e766ead7560262f4bc6ad3da6f1117c498cd6@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
We set this here, but don't really use it until we've
enabled interrupts. But when enabling interrupts we
always overwrite this value anyway, so remove setting
it here, mostly in order not to have some additional
code duplicated later.
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.20201209231352.135d96297aca.Id2d26fff60b6c31202bb0a36e46948bda6a39d33@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
This is actually wrong, the bit used here by the image loader
is BIT(1), not BIT(2). The latter will be reused by the new
reset flow soon.
However, as we never had any complaints about not printing
the IML status or not handling the IML error interrupt (and
I suspect the code handling it was incorrectly anyway) just
remove the code for it.
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.20201209231352.9a323f4a3493.Ic7aee4dbbf4be42287c338c2fa1b111473724116@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
If 12k A-MSDU size is requested, we will actually allocate 16k
due to page allocation. Thus, change it to actually mean 16k,
which is useful for certain sniffer use cases.
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.20201209231352.84ae405829d4.I31184f4be31f7c3feb9a29aef3a111e70d15c64a@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
We no longer need code that was introduced to differentiate
between two early versions of 8260.
We can remove this convoluted way to get the hardware version
that was needed because of a bug in the register's
configuration.
Moreover, since we no longer need to access the PRPH
registers, we no longer need to wake up the device,
request ownership, etc...
Remove all that.
This allows us to get the rid of the obsolete comment
about the AUX bus MISC address space which should have
been moved when this code was moved away from here.
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.4a5665ccd8a6.Iff3879405c15758ba661c430e77dc2160ddada1c@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
