Rename current wait_tx_queue_empty to wait_tx_queues_empty since
it waits for multiple queues (up to 32).
Next patch will add a wait for single TX queue which is needed for
gen2 to be scalable for 512.
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>

Support change to ADD_STA API to support station types.
Each station is assigned its type.
This simplifies FW handling of the broadcast and multicast
stations:
* broadcast station is identified by its type and not the mac
  address.
* multicast queue is no longer treated differently. The opening
  and closing of it is done by referring to its station.
  There is no need to specify it in the MAC command.
* When disabling TX to all station driver can disable the traffic
  on multicast station, so FW doesn't have to do it.
Change is backward compatible.
Change the order of adding and removing the stations according to
FW requirements.
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>

For gen2 there is a new register.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When CONFIG_DEBUG_TEST_DRIVER_REMOVE is set, iwlwifi crashes
when the opmode module cannot be loaded, due to completing
the completion before using drv->dev, which can then already
be freed.

Fix this by removing the (fairly useless) message. Moving the
completion later causes a deadlock instead, so that's not an
option.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

If we fail to allocate the small chunk of memory for the
pieces of the firmware file, we leak the whole firmware
image instead...

Since the allocation failure is really unlikely, just bail
out at that point instead.

Remove the error message at the label since we now (and
actually have been) use it for various reasons.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

This struct member is already assigned in the previous
call to iwl_trans_alloc(), so assigning the same value
again is superfluous - remove it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Most of the dwells are constant across different scan types.
Use defines instead of depending on scan type.
This is needed as preparation to having different scan type per
band.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We use the full station field as sta_id, and never
use the color.
FW are about to clean the color out, so those defines
are incorrect now (and were redundant before).
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>

The reserved queue is never used, save the trouble.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Allow configuring debug destination on a000 HW.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Remove an extra variable 'queue' that already exists.
Also, since there are no code paths that use 'queue'
without intializing it, remove the unnecessary zero
initialization.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

iwl7265D and iwl3168 are frozen on API version 29.
Set the MAX API allowed level to 29 from now on.
Signed-off-by: NDor Shaish <dor.shaish@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In iwl_mvm_sar_get_ewrd_table() In case of a BIOS bug, n_profiles
might be 0 thus we need to return an error value.  Found by Klocwork.
Signed-off-by: NSharon Dvir <sharon.dvir@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Delete the scanned channel results.
No need in it we get it any way when logging.
The print only clogs up the ftrace print buffer.
Signed-off-by: NMordechai Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

While freeing inactive queue, check mvmsta to be valid before
dereferencing it.  Found by Klocwork.
Signed-off-by: NSharon Dvir <sharon.dvir@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>

Rates were changed to adapt to HE. Change is backward compatible.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

If iwl_pcie_ctxt_info_init_fw_sec() fails, the previous allocated DMA
memory needs to be freed (it even goes out of scope immediately.)
Do that to prevent the leak.

Fixes: eda50cde ("iwlwifi: pcie: add context information support")
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

If the context info fails to be allocated, the mutex
isn't unlocked properly, fix that.

Fixes: eda50cde ("iwlwifi: pcie: add context information support")
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When FW fails to get block ack, it will send the notification with
0 items in the TFD queue elements. Allow this and handle accordingly.

Fixes: c46e7724 ("iwlwifi: mvm: support new BA notification response")
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Memory offsets and lengths for A000 HW is different
than currently specified.

Fixes: e34d975e ("iwlwifi: Add a000 HW family support")
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In a000 CDB firmware, we cannot update phy context to a
different band - we must first remove it and add it
again. Support this flow for all a000 devices since
we may have various combinations that cause us to fail
regardless if CDB is active.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Address 4 is reversed as well.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The notification infrastructure (iwl_notification_wait_*
functions) allows to wait until a list of notifications
will come up from the firmware and to run a special handler
(notif_wait handler) when those are received.

The operation mode notifies the notification infrastructure
about any Rx being received by the mean of
iwl_notification_wait_notify() which will do two things:
1) call the notif_wait handler
2) wakeup the thread that was waiting for the notification

Typically, only after those two steps happened, the
operation mode will run its own handler for the notification
that was received from the firmware. This means that the
thread that was waiting for that notification can be
running before the operation mode's handler was called.

When the operation mode's handler is ASYNC, things get even
worse since the thread that was waiting for the
notification isn't even guaranteed that the ASYNC callback
was added to async_handlers_list before it starts to run.
This means that even calling
iwl_mvm_wait_for_async_handlers() can't guarantee that
absolutely everything related to that notification has run.
The following can happen:

Thread sending the command        Operation mode's Rx path
--------------------------        ------------------------
iwl_init_notification_wait()
iwl_mvm_send_cmd()
                                  iwl_mvm_rx_common()
                                  iwl_notification_wait_notify()
iwl_mvm_wait_for_async_handlers()
// Possibly free some data
// structure
                                  list_add_tail(async_handlers_list);
                                  schedule_work(async_handlers_wk);
                                  // Access the freed structure

Split the 'run notif_wait's handler' and the 'wake up the
thread' parts to fix this. This allows the operation mode
to do the following:

Thread sending the command        Operation mode's Rx path
--------------------------        ------------------------
iwl_init_notification_wait()
iwl_mvm_send_cmd()
                                  iwl_mvm_rx_common()
                                  iwl_notification_wait()
                                  // Will run the notif_wait's handler
                                  list_add_tail(async_handlers_list);
                                  schedule_work(async_handlers_wk);
                                  iwl_notification_notify()
iwl_mvm_wait_for_async_handlers()

This way, the waiter is guaranteed that all the handlers
have been run (if SYNC), or at least enqueued (if ASYNC)
by the time it wakes up.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Currently when rate isn't found (invalid rate or CCK rate in high
band) driver is assigning rate -1, which causes mac80211 to dump
it later with the cryptic rate value of 0xFF.
Instead, warn early and dump the frame in mvm.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

For a000 devices, we don't really have multi RX queue for now,
until we have the RX queue configuration API.
Disable RX queue notification for now.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When we load firmware in extended mode (as we do by default for
now) driver should send a command what kind of commands ucode
should stop and wait for before proceeding with phy calibrations.
Support this command. Currently we only do NVM access - so mark
this bit only.
Signed-off-by: NSara Sharon <sara.sharon@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>

This workaround is not needed anymore.  Remove it.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Identify and load FW for a000 CDB product.
Signed-off-by: NSara Sharon <sara.sharon@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>

Add one new PCI ID for the 8265 series.
Add three new PCI ID for the 8275 series.
Signed-off-by: NTzipi Peres <tzipi.peres@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In the end, the firmware doesn't want the SP len as present
in the WMM IE, but rather the actual number of frames.

Fixes: bd3c6cf901a8 ("iwlwifi: mvm: tell the firmware about the U-APSD parameters")
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@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>

Change the value of TX_CMD_SEC_KEY_FROM_TABLE flag
in TX_CMD security flags to accommodate a FW API change.

Bump min API for 9000 series devices to 30 to keep the driver aligned
aligned the FW.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>