A hardware/firmware error may happen at any point in time. In
particular, it might happen while mac80211 is in the middle of
a flow. We observed the following situation:
 * mac80211 is in authentication flow, in ieee80211_prep_connection()
 * iwlwifi firmware crashes, but no error can be reported at this
   precise point (mostly because the driver method is void, but even
   if it wasn't we'd just shift to a race condition)
 * mac80211 continues the flow, trying to add the AP station
 * iwlwifi has already set its internal restart flag, and so thinks
   that adding the station is part of the restart and already set up,
   so it uses the information that's supposed to already be in the
   struct

This can happen with any flow in mac80211 and with any information
we try to preserve across hardware restarts.

To fix this, only set a new HW_RESTART_REQUESTED flag and translate
that to IN_HW_RESTART once mac80211 actually starts the restart by
calling our start() method. As a consequence, any mac80211 flow in
progress at the time of the restart will properly finish (certainly
with errors), before the restart is attempted.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=195299.
Reported-by: Ndjagoo <dev@djagoo.io>
Reported-by: NŁukasz Siudut <lsiudut@gmail.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The API has changed - update the code.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In the driver, we track which hardware queue is associated with
which mac80211 "hw_queue", in order to be able to stop and wake
it. When moving these bitmaps out of the queue_info structures,
the type of the bitmap was erroneously changed from u32 to u8,
presumably in order to save memory.

Turns out that u32 isn't needed, because the highest queue we
can ever tell mac80211 is always < 16, but a u16 definitely is
needed, queues >=8 do happen.

While at it, throw a BUILD_BUG_ON() into the place where we set
the limit (mvm->first_agg_queue) and a warning when it actually
gets put into the bitmap.

The consequence of this bug is that full HW queues associated
with such a too-high mac80211 number never stop higher layer
queues when full, and thus would simply drop all packets that
couldn't be enqueued to the hardware queue.

Fixes: 34e10860 ("iwlwifi: mvm: remove references to queue_info in new TX path")
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Move the notification wait code into the new fw interaction directory.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

There's a lot of mvm code that really should be more generic
and part of the iwlwifi module. Start by making a place to
keep such code - in the new "fw" subdirectory - and already
move the firmware related header files there.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Where possible (all except for "11n_disable", which isn't valid in C)
rename the internal names for module parameters to be the same as the
externally visible names, to aid finding their use etc.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The BT_COEX command should not be sent to the INIT
firmware image starting from 8000 family.
The firmware team also requested to send the BT_COEX
command after the PHY_DB_CMD and the PHY_CFG_CMD.

While at it:
s/iwl_send_bt_init_conf/iwl_mvm_send_bt_init_conf/
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We are going to add debugfs entry to retrieve the current geographic
profile being used in the FW. Currently the driver reads those tables
from the BIOS and passes them to the FW.
To prepare for this retrieving we want to store those
tables in the driver.
Signed-off-by: NHaim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

This new API allows flushing queues based on station ID and TID in A000
devices.  One reason for using this is that tfd_queue_mask is only good
for 32 queues, which is not enough for A000 devices.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NMordechai Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In case we need to move the scheduler write pointer by
steps of 0x40, 0x80 or 0xc0, the scheduler gets stuck.
This leads to hardware error interrupts with status:
0x5A5A5A5A or alike.

In order to work around this, detect in the transport
layer that we are going to hit this case and tell iwlmvm
to increment the sequence number of the packets. This
allows to keep the requirement that the WiFi sequence
number is in sync with the index in the scheduler Tx queue
and it also allows to avoid the problematic sequence.
This means that from time to time, we will start a queue
from ssn + 1, but that shouldn't be a problem since we
don't switch to new queues for AMPDU now that we have
DQA which allows to keep the same queue while toggling
the AMPDU state.

This bug has been fixed on 9000 devices and up.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

This improves documentation, since kernel-doc can't deal with the
union well.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Shaul reported that when iwlmvm was sending beacons, it didn't properly
also take ownership of the probe responses. This is because the whole
mac80211 callback (tx_last_beacon) wasn't implemented. Fix that to make
IBSS discovery work better.
Reported-by: NShaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Avoid one kind of symbol shadowing another in iwl_mvm_flush_sta()
by renaming the function parameter.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Convert ucode_loaded to a status bit called FIRMWARE_RUNNING.
This will make it easier to clear this earlier, to avoid any
spurious accesses while shutting down, for example through
debugfs.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

This will help refactor this later.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In case an assert happens on init flow, the current
driver powers down the NIC, except if iwlmvm modparam
init_dbg=1, and only on very specific flows.

Extend this capability to cover most failure cases
by keeping track of what init configurations have been
completed. This way, we can allow NOT powering down
the NIC, while making sure that when the driver is
removed we don't try to free resources that haven't
been allocated. (This can result in a kernel panic.)
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

NVM code is tightly coupled with 8000 family, while
it really refers to extended NVM format introduced
back then. Separate it to a configuration dependent
boolean, and rename defines accordingly.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When we want to stop the recording of the firmware debug
and restart it later without reloading the firmware we
don't need to resend the configuration that comes with
host commands.
Sending those commands confused the hardware and led to
an NMI 0x66.

Change the flow as following:
* read the relevant registers (DBGC_IN_SAMPLE, DBGC_OUT_CTRL)
* clear those registers
* wait for the hardware to complete its write to the buffer
* get the data
* restore the value of those registers (to restart the
  recording)

For early start (where the configuration is already
compiled in the firmware), we don't need to set those
registers after the firmware has been loaded, but only
when we want to restart the recording without having
restarted the firmware.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

During d0i3 flow we flush all the queue except from the command queue.
Currently, in this flow the command queue is hard coded to 9.
In DQA the command queue number has changed from 9 to 0.
Fix that.

This fixes a problem in runtime PM resume flow.

Fixes: 097129c9 ("iwlwifi: mvm: move cmd queue to be #0 in dqa mode")
Signed-off-by: NHaim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

This API replaces the complex NVM parsing of the iwlwifi module.
Instead, we get all needed data from firmware.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Avoid using the global flush and move to flush per
station whenever possible in DQA mode.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Avoid using the old define since it will enlarge necessary
structs for previous HW.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Most of the fields aren't needed in new TX path.
Enlarging the struct to 512 queues will consume a lot of memory.
Remove all references to the struct in the new TX path.
Move mac80211 queue mapping outside, since it will be needed per
queue for TVQM mode.
Add warning in paths that shouldn't be hit.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We can't use IEEE80211_INVAL_HW_QUEUE to mark a queue as
invalid since 255 will be a valid value for a TVQM queue
index.
Use IWL_MVM_INVALID_QUEUE instead for accessing txq_id.
reserved_queue can stay a u8 since reserved_queue is not
used when TVQM is enabled.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

cab_queue can now get bigger than u8, since in TVQM we will support
512 queues..
Support it by maintaining internal mapping between the actual number
and mac80211 queue (IWL_MVM_DQA_GCAST_QUEUE).
For pre-a000 the internal queue will be the same as the mac80211
queue.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Wifi mcc (mobile country code) update is forbidden while associated.
Currently, FW prevents these updates and the driver is unaware to
this logic. From now on, the FW sends every wifi mcc update to the
driver. The driver in his turn needs to decide whether to
ignore it or not, depends on the association state.
Signed-off-by: NHaim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

There's no need to have iwl_run_unified_mvm_ucode() be exposed
to other parts of the code since the logic to pick it over the
normal code in iwl_run_init_mvm_ucode() can just be done in
that function itself.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

To utilize the maximum allowed tx power, an additional table was added
to the BIOS. The table consists of up to seven different regions
(currently only three are in use). Each region contains per band:
1. Maximum allowed tx power on the band.
2. Tx power offset for chain A.
3. Tx power offset for chain B.
On init flow driver reads this table by means of ACPI and
passes it to the firmware with GEO_TX_POWER_LIMIT cmd.
The firmware will use this table to enhance tx power with
the offset in the relevant table as well as verifying it does not
violate the maximum allowed tx power.
Signed-off-by: NHaim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

API was changed once more to support 2 LMACs.
Adapt to change while preserving current functionality.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When we get SN that is smaller than SSN of the aggregation,
we shouldn't apply any reordering on them.
Further more, HW NSSN will be zeroed, which can cause us
to make some invalid decisions.
Detect the situation and invalidate the BAID.

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>

In TVQM firmware returns the value of the queue ID and code
should accept it.
The TX queue config API was changed. Move to new API.
This has to be done in parallel in mvm and pcie.
Do not move yet to 512 queues since there are some opens
with enabling it.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In TVQM mode the TX responses were changed to include
queue number since legacy TX queue number retrieval cannot
be scaled up to 512 queues.
Support this change.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Dynamic SAR allows changing TX power limits at runtime to comply with
SAR regulations on multiple form factors (e.g. tablet vs. clamshell
mode).  To support this, a new table was added to ACPI, which is
called Extended Wireless Regulatory Descriptor (EWRD).  This table
allows OEMs to define different TX power profiles for each form-factor
or usage mode.

Read this new table and store it in our SAR profiles table, in
preparation for Dynamic SAR support.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

For dynamic SAR, we will need to select the current profile from
different places.  In preparation for that, spin the profile selection
code out of iwl_mvm_sar_init().
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We are adding support for dynamic TX power tables for SAR (specific
absorption rate) compliance.  Currently, we only support a single
(static) TX power table, which is read from ACPI, and use it
statically.

To prepare for more tables that can be switched dynamically, refactor
the SAR init flow to allow reusage and add the current static table as
a single entry in an array of tables.
Signed-off-by: NHaim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Now that transport inits the paging in the context info -
remove the call in mvm.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In case of a MFUART assert, get a notification from the fw
that consists of the assert id and debug data.

The notification may be divided to multiple chunks, depending
on the size of the debug data sent to the driver, which would
be up to 1KB.

Get the notification, and if the debug info flag is enabled,
print the debug data to the dmesg.
Signed-off-by: NGolan Ben-Ami <golan.ben.ami@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In a000 devices FW will assign the queue number. Prepare for
that by getting rid of static defines and store them in variables.
Enlarge to u16 since we may have up to 512 queues.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Currently multicast queue is associated with the broadcast
station.

This raises quite a few issues:

The multicast queue has a special treatment:
- It is sent in the MAC context command
- It is excluded from tfd_queue_mask

In DQA mode we end up enabling two queues - the probe response
queue and the multicast queue - with the same station (broadcast)
and TID while in DQA mode it should be unique RA-TID.
Firmware will enforce it for a000 devices, so this allocation
will fail.

In addition, in a000 devices the FW will set the FIFO and not
the driver. So there is a need for FW to know when we enable
the queue that it is multicast queue so it will be bound to
the multicast FIFO. There is no such way in current design.

In order to simplify driver and firmware handling of this queue
create a multicast station.
This solves the unique RA-TID issue in the short term and serves
as preparation for the long term.

In the long term we will also add a flag marking this station for
the FW as the multicast station.
Once we will do that the FW will know this is the multicast queue
immediately when it is added and bind it to the correct FIFO.
It will also enable removing the special treatment of the
queue in the MAC context command.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>