Newer firmware don't clean the RFKILL interrupt in APMG, do
it in driver instead.
If we forget to do so, we can't send HCMD to firmware while
the NIC is in RFKILL state.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes 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: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NJohannes 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: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJohannes 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: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Instead of having the same code sequentially, fall-through.
Signed-off-by: NIdo Yariv <ido@wizery.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Simplify iwl_rxq_space to improve readability and reduce
the ambiguity spares to a single element.
Signed-off-by: NIdo Yariv <ido@wizery.com>
Signed-off-by: NJohannes 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: NIdo Yariv <ido@wizery.com>
Signed-off-by: NJohannes 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: NGregory Greenman <gregory.greenman@intel.com>
Signed-off-by: NJohannes 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: NEliad Peller <eliad@wizery.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Fix some typos.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NJohannes 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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This reverts commit a53ee0a3.

This fix causes a worse HW Error when entering RF-Kill.
Signed-off-by: NGuy Cohen <guy.cohen@intel.com>
Signed-off-by: NDor Shaish <dor.shaish@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes 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: Neytan lifshitz <eytan.lifshitz@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes 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: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes 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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes 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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes 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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes 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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In newest NICs (7000 family and up), L1 is supported, so
avoid to disable it.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes 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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>

This means it can be shared for different transport
layers in the future.
Signed-off-by: NInbal Hacohen <Inbal.Hacohen@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>

A few places use 'pcie_trans' which is a bit non-standard,
use 'trans_pcie' there as well.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

A few places use just 'q', use 'rxq' there like all
other places.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes 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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes 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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes 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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes 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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes 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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes 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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Accessing the device in Tx path is not a good idea.
Mirror the data in DRAM.
Signed-off-by: NJohannes 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: NEran Harary <eran.harary@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes 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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes 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: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NEmmanuel 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: NEran Harary <eran.harary@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

mac80211 and the Intel drivers all define crypto
constants, move them to ieee80211.h instead.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add new device IDs and configurations to support
all the devices.
Signed-off-by: NOren Givon <oren.givon@intel.com>
Signed-off-by: NJohannes 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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes 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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: NMoshe Island <moshe.island@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

It has nothing to do in FW API.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>