| Age | Commit message (Collapse) | Author |
|---|
|
Different queue can have different behavior. While it can be
unacceptable for a certain queue to be stuck for 2 seconds
(e.g. the command queue), it can happen that another queue
will stay stuck for even longer (a queue servicing a power
saving client in GO).
The op_mode can even make the timeout be a function of the
listen interval.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
This watchdog allows to monitor the transmit queues. When a
queue doesn't progress for a too long time, a timer fires
and then, debug data can be collected.
This watchdog has never been enabled on dvm controlled
devices, so don't enable it there.
In order to have it running on mvm controlled devices, we
need to fix a small issue in the transport layer: mvm
controlled devices use the shadow registers optimization.
In this case, the watchdog wasn't running at all, even if
enabled by the module parameter. Fix that on the way.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
The base address of the scheduler in the device's memory
(SRAM) comes from two different sources. The periphery
register and the alive notification from the firmware.
We have a check in iwl_pcie_tx_start that ensures that
they are the same.
When we resume from WoWLAN, the firmware may have crashed
for whatever reason. In that case, the whole device may be
reset which means that the periphery register will hold a
meaningless value. When we come to compare
trans_pcie->scd_base_addr (which really holds the value we
had when we loaded the WoWLAN firmware upon suspend) and
the current value of the register, we don't see a match
unsurprisingly.
Trick the check to avoid a loud yet harmless WARN.
Note that when the WoWLAN has crashed, we will see that
in iwl_trans_pcie_d3_resume which will let the op_mode
know. Once the op_mode is informed that the WowLAN firmware
has crashed, it can't do much besides resetting the whole
device.
CC: <stable@vger.kernel.org>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Some devices have 31 TFD queues. Don't enable it yet since
there are still issues with it, but at least prepare the
code for it. There was a bug in the read pointer assignment,
fix that. Also, move the inline functions to iwl-scd.h which
is the right place.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Printing all the scratch data of the TFDs of that queue is
useless and stuffed the kernel log with data. Remove that.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
The driver loads the 2 CPU sections, then it needs to let
the firmware know to start the authentication of the
sections. This is done by writing the relevants bits to
FH_UCODE_LOAD_STATUS.
For CPU1, the driver sets the lower 16 bits. For both CPUs,
the driver sets all the 32 bits.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
C step functionality in the driver is exactly the same as
B step besides the ucode name that present as iwlwifi-8000C-xx.ucode
instead of iwlwifi-8000B-xx.ucode
Signed-off-by: Eran Harary <eran.harary@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
The ref_lock that was recently added is missing initialization
which makes lockdep unhappy and is generally a bad idea.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Conflicts:
drivers/net/wireless/iwlwifi/iwl-fw-file.h
drivers/net/wireless/iwlwifi/mvm/scan.c
|
|
A new host command can be used to configure the scheduler
instead of accessing the scheduler's registers from the
driver. This is easier and less error prone since accessing
the hardware at certain moments can lead to races with the
firmware.
Prefer to use the host command whenever it is available.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Add a new config for 4165 series over PCI and insert support
for two new 4165 series PCI IDs.
Signed-off-by: Oren Givon <oren.givon@intel.com>
Reviewed-by: Liad Kaufman <liad.kaufman@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
The trans cfg was not replaced for 7265-D cards. This led to a check of
the min-NVM version against a 7265-C card, causing very-old 7265-D cards
to operate incorrectly with the driver.
Fixes: 3fd0d3c170ad ("iwlwifi: pcie: support 7265-D devices")
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
In order to config the FW and to allocate monitor buffer driver should
run the function iwl_pcie_apply_destination immediately after FW sections
are loaded.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Reviewed-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Enter d0i3 on suspend, and exit d0i3. Wait for the
command responses in both cases.
Use this mode in case of pcie trans.
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Implement the ref/unref trans ops and track both tx and
host command queues (and hold references while they
are not empty).
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
When the driver is unload, the Manageability Engine should
know about that - send an event to inform it about this
event.
Reviewed-by: Reuven Borok <reuven.borok@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
New FW has chunks that are larger than the size limit of the
FH's DMA. To make sure we don't crash it - actively limit the
max size of each chunk.
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
A few device IDs were added, reflect this change in the
driver.
Cc; <stable@vger.kernel.org> [3.13+]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
When we reset the device, the CSR_INT gets cleared as well
as CSR_INT_MASK. Meaning that we shouldn't get any interrupt
but, due to a hardware bug, recent devices will keep sending
interrupts. This leads to an interrupt storm while stopping
the device.
The way to fix this is to ACK all the interrupts after the
device is reset so that the value of CSR_INT will stay
0xffffffff.
Fixes: 522713c81e4e ("iwlwifi: pcie: properly reset the device")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Until this patch, dumping the monitor data could be done only
for PCIe external (DRAM) mode in 7000 HW family. This patch
allows to pull the monitor data also on other families, and
also to pull the monitor data if an internal buffer is used.
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Sometimes there is a need to configure some registers for
setting some FW properties, such as the FW monitor mode
(internal/external). This patch supports setting this for
PCIe mode.
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Adds all FH registers between FH_MEM_UPPER_BOUND and
FH_MEM_LOWER_BOUND (which should be readable to the driver)
to the dump data when it is collected.
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
The ucode load flow changed for B0 hardware step.
Change the code accordingly.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Not doing so would allow other possible users of the device
to take ownership and prevent normal WiFi operation.
This fixes the second part of:
https://bugzilla.kernel.org/show_bug.cgi?id=87191
Reviewed-by: Moshe Harel <moshe.harel@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
A following patche will use trans_pcie->cmd_in_flight
for reference accounting as well. get ready for it.
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Identify 7265-D devices using the hardware revision (they have the
same PCI IDs as 7265) and change the configuration for them taking
the differences (currently only the firmware image) into account.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Toggle the LMPM_CHICK register when writing chunks into the FW's extended
SRAM. This tells the FW to put the chunk into a different memory space.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
We were toggling the wrong bit when we reset the device,
fix that. Moreover, since the reset can take time, we need
to wait before we set the rfkill interrupt. Not doing so
can be racy since the driver is enabling the rfkill
interrupt while the device is resetting which will clear
all the registers including the CSR_INT_MASK.
This can basically lead to a situation where we don't
enable the rfkill interrupt. If that happens, the user will
not be able to re-enable the device when de-asserting
rfkill.
This scenario happened to the submitter of:
https://bugzilla.kernel.org/show_bug.cgi?id=87191
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
|
|
This is fully backward compatible with older platforms.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
In some rare cases, the firmware can put the device to
sleep after the driver requested the access. This is
because the access request can take a short time to be
propagated to the firmware.
If that happens, the driver may think that it has access
since the firmware hasn't put the device to sleep yet, but
right after the driver's check, the firmware might put the
device to sleep.
Warn when this happens by allowing the firmware to finish
the "put the device sleep" flow so that the driver will
not get access to the device. This will make the issue
visible.
This still doesn't fix the race, but at least it makes
it more visible.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
The length counting previously done had an error in it, causing
the length down the data dumping function to be shorter than it
should be, causing the end of the data to get truncated off and
lost.
Cc: <stable@vger.kernel.org> [3.17+]
Fixes: 67c65f2cf710 ("iwlwifi: dump periphery registers to fw-error-dump")
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
If the RFkill interrupt fires while we calibrate, it would
make the firmware fail and the driver wasn't able to recover.
Change the flow so that the driver will kill the firmware
in that case.
Since we have now two flows that are calling
trans_stop_device (the RFkill interrupt and the
op_mode_mvm_start function) - we need to better sync this.
Use the STATUS_DEVICE_ENABLED in the pcie transport in an
atomic way to achieve this.
This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=86231
CC: <stable@vger.kernel.org> [3.10+]
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
iwlwifi features a debug mechanism that allows to dump
binary data which is helpful to debug the firmware.
Until now, this data was made available for the userspace
through debugfs. For this exact purpose, devcoredump was
created. Move to the new infrastructure.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
In the new format the "CSS section" has the same TLV type
as the "mem section". So we need to run the secured flow
for all the 8000 products.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
When the ARC is reset when we exit from Sx in case we had
WoWLAN running, we can't access the prph before we reset
the NIC.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Otherwise we have no way to know that the buffer hasn't been
allocated.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
iwl_poll_bit may return a strictly positive value when the
poll doesn't match on the first try.
This was caught when WoWLAN started failing upon resume
even if the poll_bit actually succeeded.
Also change a wrong print. If we reach the end of
iwl_pcie_prepare_card_hw, it means that we couldn't
get the devices.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
The LTR is the handshake between the device and the root
complex about the latency allowed when the bus exits power
save. This configuration was missing and this led to high
latency in the link power up. The end user could experience
high latency in the network because of this.
Cc: <stable@vger.kernel.org> [3.10+]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Align the trans->hw_rev variable format with previous series
format.
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Add 4 missing PCI IDs for the 7260 series.
Cc: <stable@vger.kernel.org> [3.10+]
Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
When freeing the structures used for command data, clear their
memory as they may have contained key material at some point.
Also clear the duplicated buffer when freeing it to be safe;
currently key material is never put there but that may change.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Rather than ANDing with a mask - use existing macros, which
are more readable.
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
This configuration is not needed for dvm, and it actually
broke it.
Reported-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Edit some 8000 series PCI IDs and add configuration to
Dual Band Wireless N 8260 devices.
Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
|
|
This change does the following:
1) Add a new 7265 series PCI ID
2) Add two new 3160 series PCI IDs
3) Add the new 3165 series PCI IDs and configurations
Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Our legal structure changed at some point (see wikipedia), but
we forgot to immediately switch over to the new copyright
notice.
For files that we have modified in the time since the change,
add the proper copyright notice now.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Currently the firmware is handling this, but that is wrong as it then
needs to assume a certain command queue, therefore this should be in
the driver; add it here so it can be removed from the firmware in the
future.
Signed-off-by: Avri Altman <avri.altman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
