Add some new PCI IDs to the table for 7000 & 3160 series
Cc: stable@vger.kernel.org
Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
A few NICs can get into trouble if we reset the TX queue
counters in certain very rare situation. To be on the safe
side, simply avoid to reset the TX queue counter.
This is relevant for non-AMPDU queues only since on AMPDU
we have no choice - we must start the TX queue at the right
index.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The callers of iwl_drv_start() are probe functions. If a probe
function returns 0, it means it succeeded. So if NULL was returned by
iwl_drv_start(), it would be considered as a success.
Fix this by returning -ENOMEM if the driver struct allocation fails in
iwl_drv_start().
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There is a missing '-' character here so we return positive 'ENOMEM'
instead of negative. The caller doesn't care. All non-zero returns
are translated to '-ENOMEM' in iwl_pcie_nic_init().
This is just a cleanup.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The iwl_trans_pcie_alloc() function doesn't pass up error codes
returned from functions it calls, swallowing them and returning NULL
in all failure cases. The caller checks if the return value is NULL
and returns -ENOMEM. This is not correct, because in certain cases
the failure was not due to an OOM situation.
To fix this, modify the iwl_trans_pcie_alloc() function to use
ERR_PTR() to return error codes and clean up the error handling code
a bit.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Instead of having the same code sequentially, fall-through.
Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Simplify iwl_rxq_space to improve readability and reduce
the ambiguity spares to a single element.
Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reduce the ambiguity spares to a single element if the window size is not
smaller than the queue size. If smaller, no spares are required at all.
Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's no reason for the transport to call itself through
indirect function pointers, inline the (little) code there
is and remove the indirection completely.
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
do some little cleanups in tx.c - eliminate duplicate checks,
use locally cached fields and predefined macros.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If no opmode is present during suspend/resume (i.e. if
the iwldvm or iwlmvm isn't loaded) the driver crashes
during resume, trying to call the rfkill notification.
Avoid that, and also don't enable the rfkill interrupt
in this case (to avoid crashing trying to handle the
interrupt later.)
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This reverts commit a53ee0a308.
This fix causes a worse HW Error when entering RF-Kill.
Signed-off-by: Guy Cohen <guy.cohen@intel.com>
Signed-off-by: Dor Shaish <dor.shaish@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When the NIC is expected to operate in high temperature,
it is advisable to put more aggresive thermal throttling
parameters, in order to prevent CT-kill.
Signed-off-by: eytan lifshitz <eytan.lifshitz@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
As Arjan pointed out, we mustn't do anything related to PCI
configuration until the device is properly enabled with
pci_enable_device().
Cc: stable@vger.kernel.org
Reported-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If we forget to do so, we can't send HCMD to firmware while
the NIC is in RFKILL state.
Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This allows to clean all kinds of bad state it might be in.
This solves situation where HW RFkill was switched while
the NIC was offline.
Until now, we relied on the firmware to do clean the
interrupt, but new firmwares don't do that any more.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This SKU was missing in the list of supported devices
https://bugzilla.kernel.org/show_bug.cgi?id=60577
Cc: <stable@vger.kernel.org> [all versions]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Use the return value of WARN_ONCE() and add a message with
the queue ID that's getting used.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In newest NICs (7000 family and up), L1 is supported, so
avoid to disable it.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
There's no need to have 'forward' debugfs function declarations
as part of the macros because the macros are always used after
the static functions are defined already, so remove them.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
This means it can be shared for different transport
layers in the future.
Signed-off-by: Inbal Hacohen <Inbal.Hacohen@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
A few places use 'pcie_trans' which is a bit non-standard,
use 'trans_pcie' there as well.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
A few places use just 'q', use 'rxq' there like all
other places.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The PCIe code has an array of buffer descriptors (RXBs) that have pages
and DMA mappings attached. In regular use, the array isn't used and the
buffers are either on the hardware receive queue or the rx_free/rx_used
lists for recycling.
Occasionally, during module unload, we'd see a warning from this:
WARNING: at lib/list_debug.c:32 __list_add+0x91/0xa0()
list_add corruption. prev->next should be next (c31c98cc), but was c31c80bc. (prev=c31c80bc).
Pid: 519, comm: rmmod Tainted: G W O 3.4.24-dev #3
Call Trace:
[<c10335b2>] warn_slowpath_common+0x72/0xa0
[<c1033683>] warn_slowpath_fmt+0x33/0x40
[<c12e31d1>] __list_add+0x91/0xa0
[<fdf2083c>] iwl_pcie_rxq_free_rbs+0xcc/0xe0 [iwlwifi]
[<fdf21b3f>] iwl_pcie_rx_free+0x3f/0x210 [iwlwifi]
[<fdf2dd7a>] iwl_trans_pcie_free+0x2a/0x90 [iwlwifi]
The reason for this seems to be that in iwl_pcie_rxq_free_rbs() we use
the array to free all buffers (the hardware receive queue isn't in use
any more at this point). The function also adds all buffers to rx_used
because it's also used during initialisation (when no freeing happens.)
This can cause the warning because it may add entries to the list that
are already on it. Luckily, this is harmless because it can only happen
when the entire data structure is freed anyway, since during init both
lists are initialized from scratch.
Disentangle this code and treat init and free separately. During init
we just need to put them onto the list after freeing all buffers (for
switching between 4k/8k buffers); during free no list manipulations
are necessary at all.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When the queue is unmapped while it was so loaded that
mac80211's was stopped, we need to wake the queue after
having freed all the packets in the queue.
Not doing so can result in weird stuff like:
* run lots of traffic (mac80211's queue gets stopped)
* RFKILL
* de-assert RFKILL
* no traffic
Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When a queue is disabled, it frees all its entries. Later,
the op_mode might still get notifications from the firmware
that triggers to free entries in the tx queue. The transport
should be prepared for these races and know to ignore
reclaim calls on queues that have been disabled and whose
entries have been freed.
Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The older devices (pre-7000/3000 series) all only work with the
DVM opmode due to firmware availability, while newer ones will
only work with the MVM opmode for the same reason.
When building a driver that only has one of MVM or DVM, there's
no reason to build the device support and have the PCIe IDs for
all devices since they can't be used anyway, so avoid that.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Instead of using #ifdef CONFIG_IWLWIFI_DEBUG, remove the
iwlwifi_mod_params.debug_level variable completely and
make iwl_have_debug_level() always return false in the
non-debug case. This way, the optimiser will elide all
code for it automatically without having to add #ifdefs.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's no reason to read the INTA register in the ICT IRQ
handler, this interrupt mechanism is designed to not have
to read as many registers as the regular one. Not reading
the INTA register gives a significant performance/CPU use
improvement.
Since we still want to get this info, fetch it only if
the ISR debug level is enabled.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When CMD_SEND_IN_RFKILL is set, it is perfectly legitimate
to send a host command while RFKILL is asserted. In this
case, the host command sending functions should return 0
even if RFKILL is asserted.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
For testing the D3 (WoWLAN) firmware, it is useful to be able
to run the firmware with instrumentation while the host isn't
sleeping and can poke at the firmware debug logging etc.
Implement this by a debugfs file. When the file is opened the
D3 firmware is loaded and all regular commands are blocked.
While the file is being read, poll the firmware's PME status
flag and report EOF once it changes to non-zero. When it is
closed, do (most of) the resume processing. This lets a user
just "cat" the file. Pressing Ctrl-C to kill the cat process
will resume the firwmare as though the platform resumed for
non-wireless reason and when the firmware wants to wake up
reading from the file automatically completes.
Unlike in real suspend, only disable interrupts and don't
reset the TX/RX hardware while in the test mode. This is a
workaround for some interrupt problems that happen only when
the PCIe link isn't fully reset (presumably by changing the
PCI config space registers which the core PCI code does.)
Note that while regular operations are blocked from sending
commands to the firmware, they could still be made and cause
strange mac80211 issues. Therefore, while using this testing
feature you need to be careful to not try to disconnect, roam
or similar, and will see warnings for such attempts.
Als note that this requires an upcoming firmware change to
tell the driver the location of the PME status flag in SRAM.
D3 test will fail if the firmware doesn't report the pointer.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The MVM firmware doesn't communicate this way, it instead
assumes D3 configuration is complete after a specific host
command (which must be last) has been sent. Handling this
bit thus belongs into the firmware API code, i.e. DVM.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
If RF-kill is asserted while a device is initialized, the
firmware INIT image can now be run to retrieve the NVM
data and register to mac80211 properly. Previously, the
initialisation would fail in this scenario and the driver
wouldn't register with mac80211 at all, making the device
unusable.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211 and the Intel drivers all define crypto
constants, move them to ieee80211.h instead.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add new device IDs and configurations to support
all the devices.
Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Many times, a NIC error is the result of a bad command sent
to the device. If the command was sent synchronously, then
we'll currently print a message when the command is aborted
containing the command. It can be very useful to also see
the stack dump though, so also print that.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Users complained about allocation failures, so we loaded
the firmware in small chunks (PAGE_SIZE). This makes the
firmware restart considerably slower.
So, always prefer to load it in one shot allocating a big
chunk of coherent, and use smaller chunks as a fallback
solution.
On my laptop, this reduces the fw loading time from 120ms
to 20ms.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Moshe Island <moshe.island@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Matti Gottlieb