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're currently doing accounting on the queue sync with an
atomic variable that counts down the number of remaining
notifications that we still need.
As we've been hitting issues in this area, modify this to
track a bitmap of queues, not just the number of queues,
and print out the remaining bitmap in the warning.
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.0a3fa177cd6b.I7c69ff999419368266279ec27dd618eb450908b3@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Curretly we only mark HW error state "after" trying to collect HW data,
but if any HW error happens while colleting HW data we go into endless
loop. avoid this by setting HW error state "before" collecting HW data.
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.20201209231352.4c7e5a87da15.Ic35b2f28ff08f7ac23143c80f224d52eb97a0454@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Looks as if it's never been used.
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/mvm/ops.c:466:36: warning: ‘iwl_mvm_debug_names’ defined but not used [-Wunused-const-variable=]
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Luca Coelho <luciano.coelho@intel.com>
Cc: Intel Linux Wireless <linuxwifi@intel.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200910065431.657636-9-lee.jones@linaro.org
Add support for the new version of the alive notification, which
includes the SKU ID. We don't use the SKU ID yet, so we can just
handle the new notification as if it were version 4.
While at it, clean up a bit and rename the command and structure names
in the comments so that they are aligned with the ones used in the FW.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200930191738.6024b149e9e2.Ifcadb506e994ec352e9ce54399719926bc1bb7ee@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Add an option for adding a PASN responder, specifying the HLTK and
TK (if not associated). When a receiving a range request for a
PASN responder, the driver will ask for a secured measurement with
the specified HLTK and TK.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200930161256.28c5f5266000.I2d58b72ff92c47ac33a6aacc27fbf3790b6dfc51@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Version 11 of the range request command adds support for setting
the PN for secure ranging. For now, this is not yet supported.
The same functions that are used for version 9 and 10 are also
used for version 11 as the common part is the same.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200928121852.6f9ed4140e8c.I046e0d9f6dfaafda9794e5eb2ee1f02fcad2851a@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
A FTM responder may do PASN authentication with unassociated stations
to allow secure ranging. In this case, the driver will add an internal
station and install the TK so the FW will accept protected FTM
request frames from this station and will send a protected FTM
response frame.
In addition, the driver needs to configure the HLTK to the FW so
the FW can derive the secure LTF bits. This is left for a later
patch since it is not yet supported by the FW.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200911204056.c915b44ad7dd.I72ef7f9753964555561c27ec503241105eddb14e@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
The API version lookup is parsed from a TLV and should be in shared code
make make it reusable across all opmodes.
Also change the function names from mvm to fw, since this is not
mvm-specific anymore.
Additionally, since this function is not just a single line of code, it
shouldn't be inline. Convert them to actual functions.
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.20200421133326.cf94672dfcdb.I5ede9cc25ee8de7b8d2b5c574f917a18971da734@changeid
We have a lot of mostly duplicated data structures that are repeated
only because the device name string is different. To avoid this, move
the string from the cfg to the trans structure and add it
independently from the rest of the configuration to the PCI mapping
tables.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
This field isn't set by any configuration, remove it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
This is dead code, nothing uses the IWL_DEVICE_22560 macro and
thus nothing every uses IWL_DEVICE_FAMILY_22560. Remove it all.
While at it, remove some code and definitions used only in this
case, and clean up some comments/names that still refer to 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>
The firmware has now a new session protection command.
This new API allows the firmware to manage the protection
needed for association. It'll also remove the event when
the association is complete.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
During D3 state there are some flows which requires FW reset.
Add new API to support it.
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Remove periodic trigger functionality.
After moving to the new API we will add periodic trigger functionality
that matches the new API.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Add support code to be able to use the DRAM buffer allocation command,
which allows us to send information about a buffer to the firmware
to use it with the DBGC hardware.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Remove the "apply points" mechanism as preparation for the changed
debug API where this is now a "time point" instead. Use a new API
across the code at the trigger points ("time points"), but don't
yet implement it since that requires some more preparation.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
In prior hardware generations (e.g. 9000 series), we received the BAR
frame with fake NSSN information to handle releasing frames from the
reorder buffer for the default queue, the other queues were getting
the FRAME_RELEASE notification in this case.
With multi-TID block-ack, the firmware no longer sends us the BAR
frame because the fake RX is quite big (just the metadata is around
48 bytes or so). Instead, it now sends us one (or multiple) special
release notifications (0xc2). The hardware consumes these as well,
but only generates the FRAME_RELEASE (0xc3) for queues other than
the default queue. We thus need to handle them in the same way we
handle the normal FRAME_RELEASE.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Add a pointer to the iwl_trans structure and point it to the trans
part of the cfg. This is the first step in disassociating the trans
configuration from the rest of the configuration.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
In order to be able to select the cfg depending on the HW revision or
on the RF ID, we need to set up the trans before selecting the cfg.
To do so, move the elements from cfg that are needed by
iwl_trans_alloc() to a separate struct at the top of the cfg, so it
can be used by other cfg types as well, before selecting the rest of
the configuration.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
add support to print ldbg command in mvm and xvt mode
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Support the new DBGC_SUSPEND_RESUME command to change the recording state.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
If mvm->fwrt.cur_fw_img != IWL_UCODE_INIT, then
rfkill_safe_init_done must be true since
rfkill_safe_init_done is set to true before we start to load
the runtime image.
Remove the redundant condition.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
We will soon be using a new notification that will be
initiated by the driver, sent to the firmware and sent
back to all the RSS queues by the firmware. This new
notification will be useful to synchronize the NSSN across
all the queues.
For now, don't send the notification, just add the code to
handle it. Later patch will add the code to actually send
it.
While at it, validate the baid coming from the firmware to
avoid accessing an array with a bad index in the driver.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Unite iwl_trans debug related fields under iwl_trans_debug struct to
increase readability and keep iwl_trans clean.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When a dump trigger is fired, the driver sets IWL_FWRT_STATUS_DUMPING and
aborts any consecutive dump collection.
To allow consecutive triggers firing, use 5 dump workers and allocate
them upon incoming dump collection requests.
This functionality is needed since in ini debug mode each trigger may
have entirely different memory regions to collect unlike the legacy
mode in which all the triggers dump the same memory regions.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When we have a single image (same firmware image for INIT and
OPERATIONAL), we couldn't load the driver and register to the
stack if we had hardware RF-Kill asserted.
Fix this. This required a few changes:
1) Run the firmware as part of the INIT phase even if its
ucode_type is not IWL_UCODE_INIT.
2) Send the commands that are sent to the unified image in
INIT flow even in RF-Kill.
3) Don't ask the transport to stop the hardware upon RF-Kill
interrupt if the RF-Kill is asserted.
4) Allow the RF-Kill interrupt to take us out of L1A so that
the RF-Kill interrupt will be received by the host (to
enable the radio).
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>
This debugfs file is really old, and cannot work properly since
the unified image support. Rather than trying to make it work,
which is difficult now due to multiple images (LMAC/UMAC etc.)
just remove it - we no longer need it since we properly do a FW
coredump even in D3 cases.
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>
Most likely the last patchset of new feature for 5.2, and this time we
have quite a lot of new features. Most obvious being rtw88 from
Realtek which supports RTL8822BE and RTL8822CE 802.11ac devices. We
have also new hardware support for existing drivers and improvements.
There's one conflict in iwlwifi, my example conflict resolution below.
Major changes:
iwlwifi
* bump the 20000-series FW API version
* work on new hardware continues
* RTT confidence indication support for Fine Timing Measurement (FTM)
* an improvement in HE (802.11ax) rate-scaling
* add command version parsing from the fimware TLVs
* add support for a new WoWLAN patterns firmware API
rsi
* add support for rs9116
mwifiex
* add support for SD8987
brcmfmac
* add quirk for ACEPC T8 and T11 mini PCs
rt2x00
* add RT3883 support
qtnfmac
* fix debugfs interface to support multiple cards
rtw88
* new driver
mt76
* share more code across drivers
* add support for MT7615 chipset
* rework DMA API
* tx/rx performance optimizations
* use NAPI for tx cleanup on mt76x02
* AP mode support for USB devices
* USB stability fixes
* tx power handling fixes for 76x2
* endian fixes
Conflicts:
There's a trivial conflict in
drivers/net/wireless/intel/iwlwifi/fw/file.h, just leave
IWL_UCODE_TLV_FW_FSEQ_VERSION to the file. 'git diff' output should be
just empty:
diff --cc drivers/net/wireless/intel/iwlwifi/fw/file.h
index cd622af90077,b0671e16e1ce..000000000000
--- a/drivers/net/wireless/intel/iwlwifi/fw/file.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/file.h
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJczDAZAAoJEG4XJFUm622blLgH/jdBKEq9i1m5dtLi48u4sgPV
NsnPhR5XQjpbYpmvgPslKLxWzZq6A0P+lo9QqTXkP/QRyJLu7RnoY1c2wVsQbWaK
VTXc0cROzWt0ihAt8Mc/rEsZpISVnQ9mJbTd/kSJM9WlDeIg0jcJvnEAdQiEmM5t
2t+zZ5CupUXYbGE3zWHL1GSjBD9f0v7zyrNxYNGfvqhDEXhTFWAmVuRtfoAVlRU+
dt1HMv+qdxgoF6Uvaw/kgY09mDvdrfy2EVL0q7S3TKceute60SWf7de2sToI/rMQ
snUnVqTIIUnWPl6g+C3Bp2TbdZhy6XCSRsMFOVa2i1Lt+z1qe3dTr3hjxTQWRhE=
=uLaP
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2019-05-03' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 5.2
Most likely the last patchset of new feature for 5.2, and this time we
have quite a lot of new features. Most obvious being rtw88 from
Realtek which supports RTL8822BE and RTL8822CE 802.11ac devices. We
have also new hardware support for existing drivers and improvements.
There's one conflict in iwlwifi, my example conflict resolution below.
Major changes:
iwlwifi
* bump the 20000-series FW API version
* work on new hardware continues
* RTT confidence indication support for Fine Timing Measurement (FTM)
* an improvement in HE (802.11ax) rate-scaling
* add command version parsing from the fimware TLVs
* add support for a new WoWLAN patterns firmware API
rsi
* add support for rs9116
mwifiex
* add support for SD8987
brcmfmac
* add quirk for ACEPC T8 and T11 mini PCs
rt2x00
* add RT3883 support
qtnfmac
* fix debugfs interface to support multiple cards
rtw88
* new driver
mt76
* share more code across drivers
* add support for MT7615 chipset
* rework DMA API
* tx/rx performance optimizations
* use NAPI for tx cleanup on mt76x02
* AP mode support for USB devices
* USB stability fixes
* tx power handling fixes for 76x2
* endian fixes
Conflicts:
There's a trivial conflict in
drivers/net/wireless/intel/iwlwifi/fw/file.h, just leave
IWL_UCODE_TLV_FW_FSEQ_VERSION to the file. 'git diff' output should be
just empty:
diff --cc drivers/net/wireless/intel/iwlwifi/fw/file.h
index cd622af90077,b0671e16e1ce..000000000000
--- a/drivers/net/wireless/intel/iwlwifi/fw/file.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/file.h
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Allows to configure a periodic data collection
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
If we fail to initialize because rfkill is enabled, then trying
to do debug collection currently just fails. Prevent that in the
high-level code, although we should probably also fix the lower
level code to do things more carefully.
It's not 100% clear that it fixes this commit, as the original
dump code at the time might've been more careful. In any case,
we don't really need to dump anything in this expected scenario.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fixes: 7125648074 ("iwlwifi: add fw dump upon RT ucode start failure")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Luca Coelho <luciano.coelho@intel.com>
Cc: Intel Linux Wireless <linuxwifi@intel.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Differentiate between SW and HW error interrupts and support ini HW
error trigger.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
In restart flow, the driver requests HW restart from mac80211
and then mac80211 uses a worker to do the restart flow. In that flow a
sync dump is performed. Instead, schedule the dump worker before
requesting HW restart from mac80211. This approach simplifies the
restart flow.
Also, it is neeeded in order to differentiate between the handling of SW
and HW errors in a future commit.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
