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>

Use bcast station for all non bufferable frames on AP and AD-HOC.

The host is no longer aware of STAs PS status because of buffer
station offload, so we can't rely on mac80211 to toggle on
IEEE80211_TX_CTL_NO_PS_BUFFER bit.

A possible issue with buffering such frames, beside the obvious spec
violation, is when a station disconnects while in PS but the AP isn't
aware of that. In such scenarios the AP won't be able to send probe
responses or auth frames so the STA won't be able to reconnect and
the AP will have a queue hang.

Fixes: 3e56eadf ("iwlwifi: mvm: implement AP/GO uAPSD support")
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The code did not consider the case that the channel switch counter
is <= 1, which would result with an inaccurate calculation of the
time event apply time.

As the specification states that in case of counter == 0 the switch
occurs at any time after the reception the frame, and for counter == 1
the switch would happens before the next TBTT, schedule the time
event immediately.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

If a time event is already scheduled when trying to schedule one for
channel switch, the code assumes the channel switch is already
scheduled and no further action is required.
However, it is possible that the scheduled time event is actually
for session protection (e.g. when the first beacon after association
contains the CSA IE). In this case the channel switch will not be
scheduled which will finally lead to disconnection.

Fix this by removing the old time event and schduling a new one for
the channel switch.
Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In AP mode, if a station is removed just as it is adding a new stream,
the queue in question will remain stopped and no more TX will happen
in this queue, leading to connection failures and other problems.

This is because under DQA, when tx is deferred because a queue needs
to be allocated, the mac queue for that TID is stopped until the new
stream is added.  If at this point the station that this stream
belongs to is removed, all the deferred tx frames are purged, but the
mac queue is not restarted. As a result, all following tx on this
queue will not be transmitted.

Fix this by starting the relevant mac queues when the deferred tx
frames are purged.

Fixes: 24afba76 ("iwlwifi: mvm: support bss dynamic alloc/dealloc of queues")
Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We already have a such a pointer.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

All the firmware versions the driver supports enable DQA, and thus
the only way to get non-DQA mode is to modify the source. Remove
this mode to simplify the code.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The iwl_mvm_add_bcast_sta() and the iwl_mvm_rm_bcast_sta() functions
are only called in P2P flows.  Add _p2p_ to the function names to make
this explicit.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

There's no need to spell out the cases when we can just
use ieee80211_is_bufferable_mmpdu().
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Since the TXQ timer freeze code will not properly handle the
large TVQM queue numbers, warn if we get into that code when
we have TVQM. Also, just to catch this earlier, warn if the
firmware image doesn't support AP_LINK_PS but we're running
on HW using TVQM.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

There are two workarounds because RSS is currently broken on A000
devices due to firmware issues, but checking for the new TX API
doesn't really make sense. Check the hardware family instead of
the new TX API - there's nothing better to check since it's just
a temporary workaround.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Split out the firmware debug code to be more general, so that it
can be used by different subdrivers.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

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>

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>

There's no reason to pass mvm and trig as parameters to the macro,
since it will be expanded inside the function itself.  Also remove the
bogus buf parameter which doesn't exist and is not used.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In BSS mode in the disconnection flow, mac80211 removes
the AP station before the vif is set to unassociated.
Our firmware wants it the other way around: first set
the vif as unassociated, and then remove the AP station.

In order to bridge between those two different behaviors,
iwlmvm doesn't remove the station from the firmware when
mac80211 removes it, but only after the vif is set to
unassociated. The implementation is in
iwl_mvm_bss_info_changed_station:

if (assoc state was modified && mvmvif->ap_sta_id is VALID
    && assoc state is now UNASSC)
	remove_the_station_from_the_firmware()

During the recovery flow, mac80211 re-adds the AP station
and then reconfigures the vif. Since the vif is not
associated, and then, we enter the if above (which was
intended to be taken in the disconnection flow only) and
remove the station we just added. This defeats the
recovery flow.

Fix this by not removing the AP station in this flow if
we are in recovery flow.

Cc: stable@vger.kernel.org
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

On A000 HW, the SCD rdptr has only 8 bits allocated
for it, thus when checking if a queue is full, or
when checking if the SSN is equal to the TID's
next_reclaimed, A000 HW should trim the SSN.

Fix this by "normalizing" the SSN to wrap around
0xFF when comparing to the next_reclaimed on A000
HW.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

If we happen to be in or get into the queue sync when RF-kill
is asserted, we return from there and warn since there are
still queue sync notifications outstanding. These can't ever
come though, because we're in RF-kill, so don't WARN then.

While at it, also move the warning to the appropriate place,
if the request is not synchronous then we shouldn't warn, but
currently always will.

To make it fast, also trigger the waitq when on rfkill assert.

Fixes: 0636b938 ("iwlwifi: mvm: implement driver RX queues sync command")
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>

Install GTKs on AP side for new TX API.
Don't add IV space, it's added by the HW.

While at that fix GCMP abnd GCMP-256 GTK installation
which work similarly to the new TX API.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Clear the firmware running bit before flushing the FW (error) dump
work, because otherwise debugfs isn't blocked (previous patch) and
can cause a new work to be scheduled, which will then run after we
actually shut down the device, wreaking havoc. Clearing it ensures
that debugfs can't interfere anymore, and we can safely cancel or
flush the work struct.
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>

Now that we have 512 queues, add a wait for single TX
queue to gen2.
This replaces gen1 wait_tx_queues_empty, which was limited
to 32 queues.
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>

This patch implements the idea to have multiple scheduled scan requests
running concurrently. It mainly illustrates how to deal with the incoming
request from user-space in terms of backward compatibility. In order to
use multiple scheduled scans user-space needs to provide a flag attribute
NL80211_ATTR_SCHED_SCAN_MULTI to indicate support. If not the request is
treated as a legacy scan.

Drivers currently supporting scheduled scan are now indicating they support
a single scheduled scan request. This obsoletes WIPHY_FLAG_SUPPORTS_SCHED_SCAN.
Reviewed-by: NHante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: NFranky Lin <franky.lin@broadcom.com>
Signed-off-by: NArend van Spriel <arend.vanspriel@broadcom.com>
[clean up netlink destroy path to avoid allocations, code cleanups]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

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>

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>

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>

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>

In a000 devices we will support up to 32 stations.
The max station define is used also for invalid station marking
which makes finding usages of actual maximum station pretty hard
to sort through - change it to be a different define in order
to make future changes easier.
Use also ARRAY_SIZE intead of define when possible.
Do not move yet to 32 stations until firmware do it though.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Pass the new extended ACK reporting struct to all of the generic
netlink parsing functions. For now, pass NULL in almost all callers
(except for some in the core.)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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>

When a station is asleep, the fw will set it as "asleep".
All queues that are used only by one station will be stopped by
the fw.

In pre-DQA mode this was relevant for aggregation queues. However,
in DQA mode a queue is owned by one station only, so all queues
will be stopped.
As a result, we don't expect to get filtered frames back to
mac80211 and don't have to maintain the entire pending_frames
state logic, the same way as we do in aggregations.

The correct behavior is to align DQA behavior with the aggregation
queue behaviour pre-DQA:
- Don't count pending frames.
- Let mac80211 know we have frames in these queues so that it can
properly handle trigger frames.

When a trigger frame is received, mac80211 tells the driver to send
frames from the queues using release_buffered_frames.
The driver will tell the fw to let frames out even if the station
is asleep. This is done by iwl_mvm_sta_modify_sleep_tx_count.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Access should be by rcu_dereference. Issue was found by sparse.

Fixes: 65e25482 ("iwlwifi: mvm: use firmware station PM notification for AP_LINK_PS")
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When a station is asleep, the fw will set it as "asleep".
All queues that are used only by one station will be stopped by
the fw.

In pre-DQA mode this was relevant for aggregation queues. However,
in DQA mode a queue is owned by one station only, so all queues
will be stopped.
As a result, we don't expect to get filtered frames back to
mac80211 and don't have to maintain the entire pending_frames
state logic, the same way as we do in aggregations.

The correct behavior is to align DQA behavior with the aggregation
queue behaviour pre-DQA:
- Don't count pending frames.
- Let mac80211 know we have frames in these queues so that it can
properly handle trigger frames.

When a trigger frame is received, mac80211 tells the driver to send
frames from the queues using release_buffered_frames.
The driver will tell the fw to let frames out even if the station
is asleep. This is done by iwl_mvm_sta_modify_sleep_tx_count.
Reported-and-tested-by: NJens Axboe <axboe@kernel.dk>
Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The race happens when we send ADD_STA(auth->assoc) -> LQ_CMD
between the commands the FW sometimes loses the medium for AUX, and
sends a ndp to the AP and the flow becomes, ADD_STA -> send ndp -> LQ_CMD
the problem is that there's no rates yet defined for sending the ndp and
FW generates an assert.

The fix: change the order of the commands to LQ_CMD -> ADD_STA
Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The session protection set for association is only removed when
BSS_CHANGED_BEACON_INFO is set and BSS_CHANGED_ASSOC is not set.

However, mac80211 may set both on association (in case a beacon was
already received). In this case, mac80211 will not set
BSS_CHANGED_BEACON_INFO on the next beacons because it has already
notified the beacon change, so the session protection is never removed
(until the session protection ends).

When a CSA is received within this time, the station will fail to
folllow the channel switch because it cannot schedule the time event.

Fix this by removing the session protection when
BSS_CHANGED_BEACON_INFO and BSS_CHANGED_ASSOC are both set.
Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

A few of the static queues are enabled along with the bcast
STA. Make sure they are removed along with it, rather than
waiting for the mac ctxt release.

This is needed because we sometimes have a STA being removed
and then added again (either with the same sta_id or a
different one). If we wait for the mac ctxt release we will
try to allocate the queues again (as this is currently done
in the STA allocation and not in the MAC init) although
they weren't freed, and even if the sta_id of the STA has
changed.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>