For a000 FW moved to 15 as management TID.
The change for us is fairly local - translate old TID to 15
when enabling and disabling a queue, and make sure to cover
it also on TX responses.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
a000 devices queue management is going to change significantly.
We will have 512 queues. Those queues will be assigned number
by the firmware and not by the driver.
In addition, due to SN offload having TX queue shared between TIDs
is impossible
Also, the ADD_STA command no longer updates queues status.
The only point of changing queue in the SCD queue config API.
From driver perspective we have here a new design:
Queue sharing and inactivity checks are disabled.
Once this is done, the only paths that call scd_queue_cfg command
are paths that alloc and release TX queues - which will make future
accommodation to queue number assignment by FW easier.
Since allocating 512 queues statically is not advisable, transport
will allocate the queue on demand, fill the command with DRAM data
and send it. This is reflected in the new transport API.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Support the new TX command API for a000 devices.
Command is a very slim version of current TX command.
Generalize iwl_mvm_tx_mpdu to get rid of TX command dependencies.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca 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: Luca 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: Luca 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: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Firmware isn't configuring multi RX queue hardware yet in
the self init mode.
Disable it for now until we have an API that enables it.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
API will be the same regardless of FW compilation.
CDB related values will be filled in only for CDB.
Cahneg code and names accordingly.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca 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: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Currently aux & broadcast queues are added before calling add
station, which results with a SCD_QUEUE_CFG command sent with
a station id unknown yet to fw.
While this works for pre-a000 firmware, the a000 fw requires
the order to be reversed.
The reason the change is only for a000 devices and not for
previous devices is that we cannot reverse the order since
the tfd_queue_mask containing the aux queue will cause FW to
assert on adding a queue mask with a queue that is not enabled.
This is not a problem in a000 fw since the tfd_queue_mask was
removed from the add sta API.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
* Some small fixes here and there;
* The usual cleanups and small improvements;
* Work to support A000 devices continues;
* New FW API version;
* Some debugging improvements;
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEF3LNfgb2BPWm68smoUecoho8xfoFAljvb0UACgkQoUecoho8
xfoBYRAAshN9NSZK7Q4OlXkb5sVrhz6Q2HaH490Nby+nzSx7C5ZAR+q6PU/U963b
/fqnD5EMTjQA57hoVElgmEGj7JZAqvZrTOvhTVTk7U3znoVBhbmXQxLJRsJLqrQ1
vx8RCqa6XOD90cMBr5sZ4qzPDiRxpAaxJ/VcJ78ER3yNIu4fSBoyF5lLc+Ao0pdy
2/E8dr3LBSqEHUEeLDdB1/VXWUnBLlWR+L4WHNNrnoBaDO+azuGaD0GxHifdw+sP
BgdhlypbnVmeDGSZktegfdAvfaLQKtsG31sxyUDmgqgp9Coev1WSlzYd16sajmrP
e6YKBmlVJFIMJ3sriVozRj1eNhuULbq1w6yxBORRnZ5ertgYyoAZ5TUqKu0ssiFj
zb2xT4rT/b1iRKDtYJSgSa1EyxEw6hwMyo0PW5KWfsH8SOeWro12jweqQuEKgKqR
jVcBPb0q7OxjRkiRjxBkxQj0n6zYIkapdldpwHk8eXh/keRyWz2Ns+AcyYOxgOkk
ioX6MzTaMCXMsQnXRcl1MiM2oP24r5T6Sds1NSGvSZ759KD/S0l/ge0UUAoDxsoy
pE1CxsHZwCvqMGNICsPUbti4VkLu7wHss9W50SdHh42GuGyp0+tpU41Sv2KL6HyN
OoPA6rrCuME99vrUYblAT7U8GDb3mNjiIu064ovPSP4nvLHqIuc=
=iKI9
-----END PGP SIGNATURE-----
Merge tag 'iwlwifi-next-for-kalle-2017-04-13' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
Patches intended for v4.12:
* Some small fixes here and there;
* The usual cleanups and small improvements;
* Work to support A000 devices continues;
* New FW API version;
* Some debugging improvements;
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: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
As preparation for a000 different queue management, separate
mapping of queues from actual enablement.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Now that transport inits the paging in the context info -
remove the call in mvm.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca 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: Golan Ben-Ami <golan.ben.ami@intel.com>
Signed-off-by: Luca 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: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Currently we release up to the last expired frame.
However, if there are consecutive frames after it - we can
optimize it further and release them as well - until the next
hole.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
The command was changed to support PN offload and TKIP offload.
The FW will do TKIP calculations in D0 only for a000 devices,
but API is aligned anyway.
However, for all devices we can stop sending the wowlan tkip
command.
Firmware will fetch the keys from the station key command.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca 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: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca 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: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When receiving a frame, we currently pull in sizeof(*hdr) plus
some extra (crypto/snap), which is too much, most headers aren't
actually sizeof(*hdr) since that takes into account the 4-address
format but doesn't take into account QoS. As a result, a typical
frame will have 4 bytes of the payload in the SKB header already.
Fix this by calculating the correct header length, and now that
we have that, align the end of the SKB header to a multiple of 4
so that the IP header will be aligned properly when pulled in.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Final API has a reserved field - adjust accordingly.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
This will allow to print the name of the commands in the
logs when we sent it.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
For a000 devices the binding API needs to include relevant
lmac ID - support the new API.
The new API should be used regardless if the device had CDB or
not. If there is no actual CDB support the binding is bound
to first lmac regardless of the band.
There are some functionality changes in binding restrictions
and quota allocations that will be handled in future patches.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Allow working IBSS also when working in DQA mode.
This is done by setting it to treat the queues the
same as a BSS AP treats the queues.
Fixes: 7948b87308 ("iwlwifi: mvm: enable dynamic queue allocation mode")
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
This is a static analysis fix. The warning is:
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c:912 iwl_mvm_fw_dbg_collect()
warn: integer overflows 'sizeof(*desc) + len'
I guess this code is supposed to take a NUL character, but if we write
zero bytes then it tries to write -1 characters and crashes.
Fixes: c91b865cb1 ("iwlwifi: mvm: support description for user triggered fw dbg collection")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Access should be by rcu_dereference. Issue was found by sparse.
Fixes: 65e254821c ("iwlwifi: mvm: use firmware station PM notification for AP_LINK_PS")
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca 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: Jens Axboe <axboe@kernel.dk>
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* use shash in mac80211 crypto code where applicable
* some documentation fixes
* pass RSSI levels up in change notifications
* remove unused rfkill-regulator
* various other cleanups
-----BEGIN PGP SIGNATURE-----
iQIcBAABCgAGBQJYnHuZAAoJEGt7eEactAAdorYP/iIfEZjLblLZNui+93OHpmsq
QgXeQ9Vl/Xgq8g6vEb6jpHE6pvT/xoW/jt0s5rpYpPDzP7WRgkFQI144Jflx9gE+
7KRHYc7k9XqugbFGFakjT+DyduxrGkEhZ7Vpd39D+zlPaf+p/31Jk6C4MNwk2oG3
AA7ARUJfOKGpct3+l+cpnWQPUYQQKrSnjnMIwHL3Tu5pvGPDapdDWXbfn6T75Aof
3oVQSNtbEtdzW/Ty+HgDn/boOCRXzXlOCxFlE7OiH2AXfe2mqGU/hkcm/wZ0QxOf
9m3CxVjKH10tY6nsjDiXTOzFn+Zkzuum9/gcKtsgx+6BZ4qod2XuhtzmTeXggI8F
b7nGeadSfSS6/unUu5Fibdn+X4Cw8+Yu5Qyiwo+jLL6yyTLUg6aKN6N9HWddhBfa
pIjWAZVA1iB2m2XqUqRB/asEhslndSSfDmZK8nruYJSZWtQBNkNUdHXqqbqbBSHv
KtKbHMOKoLU4zKmV2vMWGy0qypZCxtZkNF6GURhMh2m89qBcIAApFwQMzK09MwmP
d5TcMwfi8YcKRb1Gw6n7gnJsC8e+tFDGXMi9w6z0FDGZvMbOlnO3ctSd/BY3B01H
DWimkX8Ev3kt6KKTgbJ/n0lR/vEmDGdKo2ahH1uHOTPudrjpOHUg0cdDzS/VPZqi
Qw4+FbVArISNrI2skTrA
=sqkq
-----END PGP SIGNATURE-----
Merge tag 'mac80211-next-for-davem-2017-02-09' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
Johannes Berg says:
====================
Some more updates:
* use shash in mac80211 crypto code where applicable
* some documentation fixes
* pass RSSI levels up in change notifications
* remove unused rfkill-regulator
* various other cleanups
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Mostly smaller changeds and fixes all over, nothing really major
standing out.
Major changes:
iwlwifi
* work on support for new A000 devices continues
* fix 802.11w, which was failing to due an IGTK bug
ath10k
* add debugfs file peer_debug_trigger for debugging firmware
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJYnHNpAAoJEG4XJFUm622b48QH/iQ7eCZMSYBOb3QIqJnpEkD/
k1xtch60J/JBTw11mS8TvvqyA19BnLZmLIIbbVWLTPeL5S4MJBGmEISHE9dc3FmY
CP//GjQYdxSm7VgZJSUKolQOIsY4kj/WuY4eoJzWiOfaloXHk0ascNrigdXCUSec
lRM8sX77KY/30qKJGN/Yc1ccT8zmRa/Skdt7JSHzNKakHiykqvR6NgRa6stf3g5K
NJAIrZO7K1Yndr187EsX4mr3ataAeo5+YHxoIReuYq2pcrZ6uSDsO3tJfC+4upqR
SrN/x6ds5SUYCKfwy0i/oxwuzYb8hWFH0m+yXhdkNPoaIyhgGHqzCVzdzbaqcDw=
=IyB5
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2017-02-09' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.11
Mostly smaller changeds and fixes all over, nothing really major
standing out.
Major changes:
iwlwifi
* work on support for new A000 devices continues
* fix 802.11w, which was failing to due an IGTK bug
ath10k
* add debugfs file peer_debug_trigger for debugging firmware
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Divide a mfuart related print so it won't exceed the allowed
MAX_MSG_LEN (110 bytes) per print.
Fixes: 19f63c531b ("iwlwifi: mvm: support v2 of mfuart load notification")
Signed-off-by: Golan Ben-Ami <golan.ben.ami@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When removing an IGTK, iwl_mvm_send_sta_igtk() was
called before station ID was retrieved, so the function
was invoked with an invalid station ID. Fix this by first
getting the station ID.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=192411
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
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: Mordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Luca 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: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
In https://bugzilla.kernel.org/show_bug.cgi?id=177341 Bob
reported a UBSAN WARNING on rs.c in iwldvm.
Fix the same bug in iwlmvm.
This because
i = index - 1;
for (mask = (1 << i); i >= 0; i--, mask >>= 1)
is unsafe: i could be negative and hence we can call <<
on a negative value.
This bug doesn't have any real impact since the condition
of the for loop will prevent any usage of mask.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177341
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When we send a deauth to a station we don't know about, we
need to use the PROBE_RESP queue. This can happen when we
send a deauth to a station that is not associated to us.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When NSSN is behind the reorder buffer due to timeout
the reorder timer isn't getting re-armed until NSSN
catches up. Fix it.
Fixes: 0690405fef ("iwlwifi: mvm: add reorder timeout per frame")
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
In DQA mode, first_agg_queue is initialized to
IWL_MVM_DQA_MIN_DATA_QUEUE. This causes two bugs in the tx response
flow:
1. When TX fails, we set IEEE80211_TX_STAT_AMPDU_NO_BACK regardless
if we actually have aggregation open on the queue. This causes
mac80211 to send a BAR frame even though there is no aggregation
open.
Fix that by simply checking the AMPDU flag that is set on by
mac80211 for AMPDU packets.
2. When reclaiming frames in aggregation mode, we reclaim based on
scheduler ssn and not the SN.
The reason is that scheduler ssn may be ahead of SN due to a hole
in the BA window that was filled.
However, if we have aggregations open on IWL_MVM_DQA_BSS_CLIENT_QUEUE
the reclaim flow will still go to the code of non-aggregation
instead of the aggregation code since IWL_MVM_DQA_BSS_CLIENT_QUEUE
is smaller than IWL_MVM_DQA_MIN_DATA_QUEUE, although it is a valid
aggregation queue.
Fix that by always using the aggregation reclaim code by default in
DQA mode (currently it is implicitly used by default for all queues
except the reserved BSS queue).
Fixes: cf961e1662 ("iwlwifi: mvm: support dqa-mode agg on non-shared queue")
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Handling of the number of space time streams was missing for HT rate in
rate printing function. Fix it.
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Extend ieee80211_cqm_rssi_notify with a rssi_level parameter so that
this information can be passed to netlink clients in the next patch, if
available. Most drivers will have this value at hand. wl1251 receives
events from the firmware that only tell it whether latest measurement
is above or below threshold so we don't pass any value at this time
(parameter is 0).
Signed-off-by: Andrew Zaborowski <andrew.zaborowski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Support new version of beacon template command which deprecates
the use of the tx command inside.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When a small frame is copied completely into the skb->head, the code
doesn't take alignment into account, making mac80211 copy it again
later on architectures that need the alignment. Avoid this by taking
the PAD flag from the device into account when copying.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
In DQA mode the check whether to decrement the pending frames
counter relies on the tid status and not on the txq id.
This may result in an inconsistent state of the pending frames
counter in case frame is queued on a non aggregation queue but
with this TID, and will be followed by a failure to remove the
station and later on SYSASSERT 0x3421 when trying to remove the
MAC.
Such frames are for example bar and qos NDPs.
Fix it by aligning the condition of incrementing the counter
with the condition of decrementing it - rely on TID state for
DQA mode.
Also, avoid internal error like this affecting station removal
for DQA mode - since we can know for sure it is an internal
error.
Fixes: cf961e1662 ("iwlwifi: mvm: support dqa-mode agg on non-shared queue")
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca 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: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Instead of setting the tx_cmd length in the mvm code, which is
complicated by the fact that DQA may want to temporarily store
the SKB on the side, adjust the length in the PCIe code which
also knows about this since it's responsible for duplicating
all those headers that are account for in this code.
As the PCIe code already relies on the tx_cmd->len field, this
doesn't really introduce any new dependencies.
To make this possible we need to move the memcpy() of the TX
command until after it was updated.
This does even simplify the code though, since the PCIe code
already does a lot of manipulations to build A-MSDUs correctly
and changing the length becomes a simple operation to see how
much was added/removed, rather than predicting it.
Fixes: 24afba7690 ("iwlwifi: mvm: support bss dynamic alloc/dealloc of queues")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
We don't really need clear the skb's status area nor store the
dev_cmd into it until we really commit to the frame by handing
it to the transport - defer those operations until just before
we do that.
This doesn't entirely fix the bug with frames not getting sent
out after having been deferred due to DQA, because it doesn't
restore the info->driver_data[0] place that was already set to
zero (or another value) by the A-MSDU logic.
Fixes: 24afba7690 ("iwlwifi: mvm: support bss dynamic alloc/dealloc of queues")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
The firmware will soon actually look at the AID field, and
when it does that it'll try to ensure that the AID is never
changing. Due to the way the station is added, it may start
with an invalid AID before it's associated, so to ensure a
constant AID (once it becomes non-zero), track the station
state and set the AID only when the station is associated
and when it disassociates.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
This fixes a long-standing bug that was introduced when this code
was introduced: cfg80211 passes a pointer, but we treat it as if
it was passing a value. The result is that we pass the pointer to
the firmware, instead of the value. It's not clear how this could
ever have worked, unless the firmware is ignoring this value.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
