There's no point in checking the validity of the
umac_error_event_table pointer every time we generate a dump.  It's
cleaner to do so when we read the value, namely when we receive the
alive data.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Currently, UMAC error data reading is restricted to DCCM.
A000 NICs use SMEM for this data.
Signed-off-by: NBeni Lev <beni.lev@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

All callers of iwl_mvm_release_frames() already have the baid_data
pointer, so we don't need to (re)calculate it inside the function.
Just pass it instead.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The reason station id and tid fields are both in baid data and
in the reorder buffer per queue is that we couldn't access the
baid_data in the reorder timer functions.
Now that we do some pointer math and access it anyway, those
fields can be removed.
This save some space and some code.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Now that we may have up to 256 entries per reorder buffer, and possibly up
to 16 queues, we can use a LOT of memory for this (64k for each station).
Allocate it according to what we need, which is of course much less for HT
stations (only 16k at a max of 16 queues).

However, this comes at the expense of complicating the code a bit to
calculate the right entry structure to use for each frame.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The default power limit read from the SPLC method in ACPI doesn't
have anything to do with the transport and is only used in the opmode,
so we can remove it from the trans.  Additionally, this value is only
user when the opmode is starting, so we don't need to store it
anywhere.

Remove the dflt_pwr_limit element from the trans and move call to
iwl_acpi_get_pwr_limit() call to mvm.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Getting the wrong statistics size is a problem, having a warning
will help us catch it quicker during firmware/driver development.
In released firmware/driver versions, we obviously make sure this
won't happen.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Move most of the set_dflt_pwr_limit() function to acpi.c and make it
return the pwr_limit value instead of setting directly.  Also rename
it to iwl_acpi_get_pwr_limit().
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Fix the double indentation in the configuration structs
for a000 family devices.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The iwl_get_bios_mcc() function was in the iwl-nvm-parse.c file, but
it has nothing to do with the NVM.  Move it to fw/acpi.c and rename it
to iwl_acpi_get_mcc().
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Some of the #ifdef CONFIG_ACPI are not needed anymore, so they can be
removed.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The way iwl_get_bios_mcc() gets the WiFi package and checks for its
integrity is almost identical to the new iwl_acpi_get_wifi_pkg()
function.  Instead of having duplicate code, convert it to use the
common code.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Instead of finding the wifi package with its own code, we can reuse
the new iwl_acpi_get_wifi_pkg() function when reading the default
power limit from SPLC.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Move this function to acpi.c, renaming it to iwl_acpi_get_wifi_pkg(),
because it can also be used with other methods (i.e. SPLC and WRDD).
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The ACPI table size definitions were spread around the different files
that used them.  Move them all to a common place.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Instead of defining each method where they are used and re-defining
WIFI_DOMAIN in each one of them, move all the definitions to a central
place and define the domain only a single time.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

There are many places where the same process of invoking a method from
ACPI is used, causing a lot of duplicate code.  To improve this,
introduce a new function to get an ACPI object by invoking an ACPI
method that can be reused.

Additionally, since this function needs to be called when we only have
the trans, the opmode or the device, introduce a new debug macro that
gets the device as a parameter so it can be used in the new function.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In case there is a FW bug where the BAID value in the
metadata is not properly initialized we hit the warning for
every RX packet.
Change it to warn once and add elaborate message.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We conclude the HW became inaccessible when we timeout waiting for
a bit to be set in a memory mapped register (CSR_GP_CNTRL). This
conclusion may not be true because the bit may not get set due to:
- a firmware issue
- a driver issue
- a PCI bus issue
- a platform issue
There are a lot of such reports with really no good debug information
beyond this message to help us.

Add some debug information and attempt to dump the different register
spaces at such a failure:

* Dump some configuration space of device - this will tell us if
something very basic is broken in the PCIe bus (so that configuration
accesses are failing). If this works, the PCIe bus seems OK. If this
does not work, it is definitely an PCIe issue.

* Dump some memory mapped registers - if we're reading some sane'ish
values, this will tell us that the PCIe bus is OK, but may be a firmware
/ driver issue. If this does not work, it may be a PCI configuration
issue or a driver/firmware issue.

* Dump parent and device's AER registers, will give us some straws to
chew on.

This is the sample output:
[   13.082651] ------------[ cut here ]------------
[   13.086791] iwlwifi 0000:01:00.0: iwlwifi transaction failed, dumping registers
[   13.086793] iwlwifi 0000:01:00.0: iwlwifi device config registers:
[   13.086893] iwlwifi 0000:01:00.0: 00000000: 095a8086 00100406 02800059 00000000 00000004 00000000 00000000 00000000
[   13.086895] iwlwifi 0000:01:00.0: 00000020: 00000000 00000000 00000000 50108086 00000000 000000c8 00000000 00000100
[   13.086901] iwlwifi 0000:01:00.0: iwlwifi device memory mapped registers:
[   13.086989] iwlwifi 0000:01:00.0: 00000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
[   13.086991] iwlwifi 0000:01:00.0: 00000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
[   13.086999] iwlwifi 0000:01:00.0: iwlwifi device AER capability structure:
[   13.087033] iwlwifi 0000:01:00.0: 00000000: 14010001 00100000 00000000 00462031 00002000 00002000 00000014 40000001
[   13.087034] iwlwifi 0000:01:00.0: 00000020: 0000000f d140000c 00000000
[   13.087036] iwlwifi 0000:01:00.0: iwlwifi parent port (0000:00:1c.0) config registers:
[   13.087074] iwlwifi 0000:00:1c.0: 00000000: 9d108086 00100506 060400f1 00810010 00000000 00000000 00010100 200000f0
[   13.087075] iwlwifi 0000:00:1c.0: 00000020: d140d140 0001fff1 00000000 00000000 00000000 00000040 00000000 0006010b
[   13.087087] ------------[ cut here ]------------
[   13.087095] WARNING: CPU: 0 PID: 1759 at drivers/net/wireless/iwl7000/iwlwifi/pcie/trans.c:2082 iwl_trans_pcie_reclaim+0x1ee4/0x2b9a [iwlwifi]()
[   13.087096] Timeout waiting for hardware access (CSR_GP_CNTRL 0xffffffff)
Signed-off-by: NRajat Jain <rajatja@google.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Fixes three trivial issues as reported by checkpatch.pl, namely two
switch/case indentation issues and one alignment issue in a multiline
comment.
Signed-off-by: NChristoph Böhmwalder <christoph@boehmwalder.at>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

This helps for documentation and clarifies the code by defining the
exact response struct for the marker command.
Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

These enum values don't exist, so remove their documentation as well.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When we have an AP which supports HT and a single HT
station is connected, we change the min_width from
NL80211_CHAN_WIDTH_20_NOHT to NL80211_CHAN_WIDTH_20. This
of course has no implication on the channel width but still
sends a command to the firmware.
Remember the last width that was sent and refrain from
sending unnecessary commands to the firmware.

Sending a PHY_CTXT_CMD to the firmware has a cost since it
recalculates the presence on the medium and because of that
it closes the transmit queues for a short while.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The driver reads xtal_calib from NVM file, but actually never uses it.
This is only used in dvm driver.
Signed-off-by: NChaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Devices in the A000 family can use a different size for the command queue.
To allow this, make the command queue size configurable and set the size
for A000 devices to 32.
Signed-off-by: NShahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

This would enable to better catch timing issues with
cases that WRT dump takes too much time.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The trigger that collects data when a frame is released
because of the timer of the reordering buffer was not
implemented for 9000 devices.
Fix this.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

This was never used by any product. Remove it.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

New quota command adds a field indicating low latency
direction per quota.

A TLV API bit was added to indicate the new API.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add a new a000 device with PCI ID (0x2720, 0x0030).
Signed-off-by: NOren Givon <oren.givon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The PCI ID (0x2720, 0x0070) was set with the config struct
iwla000_2ax_cfg_hr instead of iwla000_2ac_cfg_hr_cdb.

Fixes: 175b87c6 ("iwlwifi: add the new a000_2ax series")
Signed-off-by: NOren Givon <oren.givon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

De-inline iwl_trans_ref/unref and move it to common transport code
in preparation for more common code to come to these functions.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add a dbgfs entry for an easy way during runtime to
check what FW file was loaded, and get some general
FW-related data.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The driver currently handles two NVM formats,
one for 7000 family and below, and one for 8000 family and above.
The 3168 series uses something in between,
so currently the driver uses incorrect offsets for it.
Fix the incorrect offsets.

Fixes: c4836b05 ("iwlwifi: Add PCI IDs for the new 3168 series")
Signed-off-by: NChaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The current channel flags printing is very strange and messy,
in LAR we sometimes print the channel number and sometimes the
frequency, in both we print a calculated value (whether ad-hoc
is supported or not) etc.

Unify all this to
 * print the channel number, not the frequency
 * remove the band print (2.4/5.2 GHz, it's obvious)
 * remove the calculated Ad-Hoc print

Doing all of this also gets the length of the string to a max
of 101 characters, which is below the max of 110 for tracing,
and thus avoids the warning that came up on certain channels
with certain flag combinations.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

It seems that libsensors treats -EIO as a special non-recoverable
failure when it tries to read the temperature while the firmware is
not running.  To solve that, change the error code to a milder
-ENODATA.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=196941

Fixes: c221daf2 ("iwlwifi: mvm: add registration to thermal zone")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Today we stop the device and the DMA without stopping the dbgc
recording before. This causes host crashes when the DMA
rate is high.

Stop dbgc recording when clearing the fw debug configuration
to fix this.
Signed-off-by: NGolan Ben Ami <golan.ben.ami@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In monitor mode we are not expected to decrypt encrypted
packets (not having the keys).
Hence we are expected to get an unknown rx security status.
Keeping the print in monitor mode causes a print for each
captured packet flooding the dmesg.
Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The condition to check if reorder buffer ran out of
space is faulty, as it takes into account only the
NSSN.
In case the head SN was too far behind the reorder
buffer should move forward, regardless of the NSSN
status.
This caused the driver to release packets out of order
in some scenarios.

Fixes: b915c101 ("iwlwifi: mvm: add reorder buffer per queue")
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We always must set the status to what we consider success before
calling iwl_mvm_send_cmd_status() (also iwl_mvm_send_cmd_pdu_status()
which calls it).  Fix a few places where initialization is missing.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>