The commits below broke compilation when
CONFIG_IWLWIFI_DEBUGFS is not set.
FIx that.
Fixes: ddf89ab10a ("iwlwifi: mvm: allow to force the Rx chains from debugfs")
Fixes: 9d761fd8a5 ("iwlwifi: mvm: add trigger for firmware dump upon missed beacons")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
brcmfmac:
* sdio improvements
* add a debugfs file so users can provide us all the revinfo we could
ask for
iwlwifi:
* add triggers for firmware dump collection
* remove support for -9.ucode
* new statitics API
* rate control improvements
ath9k:
* add per-vif TX power capability
* BT coexistance fixes
ath10k:
* qca6174: enable STA transmit beamforming (TxBF) support
* disable multi-vif power save by default
bcma:
* enable support for PCIe Gen 2 host devices
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJU+dliAAoJEG4XJFUm622bsqQH/RO1Gxuw6hmiHPeeIcoDmlvt
MZKvy6xcAiFqREfGwDxjVminlTZ7/MB9bABeaoQKzpQFpCJW/ftjIqwfbRqZWsvG
3IC0s2nPTwWU8YSsZTbifnyXCVNQDJuE+5nQ3hMO2rE/dZDi1zt1fS2hiSXtlASS
kgBJcfXgoVxvhZ1WI+uVpbU0RtwXmI7tVylREE1sbgCrg7AuJx4Q2QmZ1GioPRLy
20HnFVFcIcbHk4eXVwAJOspdjctujoR858pg/oxlcVXWb7MOOCV/Fk8WMursZxFh
qj/I/kbDcFYh3H5uC+6qL/kRByY80/yckLDiMbghA0QR5/PSx2nvp/UfkqIf008=
=qgVl
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2015-03-06' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Major changes:
brcmfmac:
* sdio improvements
* add a debugfs file so users can provide us all the revinfo we could
ask for
iwlwifi:
* add triggers for firmware dump collection
* remove support for -9.ucode
* new statitics API
* rate control improvements
ath9k:
* add per-vif TX power capability
* BT coexistance fixes
ath10k:
* qca6174: enable STA transmit beamforming (TxBF) support
* disable multi-vif power save by default
bcma:
* enable support for PCIe Gen 2 host devices
Signed-off-by: David S. Miller <davem@davemloft.net>
Use the built-in function instead of memset.
Miscellanea:
Add #include <linux/etherdevice.h> where appropriate
Use ETH_ALEN instead of 6
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently scan params structure has only active or passive dwell time
fields, passive one is used for fragmented scans too. FW needs the
passive dwell time even when performing fragmented scan for calculating
time between channels. Add a separate parameter for fragmented dwell time
and pass both fragmented and passive to FW.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Lots of issues can be caught when the RSSI drops. Add the
ability to collect the firmware data at that point.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
It can be very useful to monitor the statistics and trigger
a firmware dump when a certain value hits a certain offset.
Since the statistics are huge, add a generic trigger. When
the DWORD at offset X reaches value Y.
Since there is another trigger before this one I can't add
right now because of a dependency on mac80211, add a
reserved entry to keep the enum in place.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Sometimes the firmware will have a hard coded configuration.
In this case, the driver won't find any configuration
in the firmware file, and it will have to re-start
recording in case it has been stopped. This can't be done
by the configuration host command since there is no such
host command configured. Do that with the registers instead.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This will allow to collect the data as soon the firmware
sends a specific notification of command response.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
We fire the trigger when the channel switch starts, but
the delay is configurable. That makes is easier to catch
channel switches that fail.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Missing beacons is a good indication that something is going
wrong in the firmware. Add a trigger to be able to collect
data when we start missing beacons with a configurable
threshold.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Now that the firmware dump can be triggered by events in
the code and not only the user or an firmware ASSERT, we
need a way to know why the firmware dump was triggered.
Add a section in the dump file for that.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Most of the time, the issues we want to debug with the
firmware dump mechanism are transient. It is then very
hard to stop the recording on time and get meaningful
data.
In order to solve this, I add here an infrastucture
of triggers. The user will supply a list of triggers
that will start / stop the recording. We have two types
of triggers: start and stop. Start triggers can start a
specific configuration. The stop triggers will be able to
kick the collection of the data with the currently running
configuration. These triggers are given to the driver by
the .ucode file - just like the configuration.
In the next patches, I'll add triggers in the code.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
20 ms fragments are no longer required by system.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Packet Level Co-Running is a BT Coex feature which is
supported on certain devices only, hence the need for
a TLV flag for it.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
We shouldn't call iwl_mvm_d3_disconnect_iter() on the running
interfaces when we are woken up due to net-detect, because it doesn't
make sense. Additionally, this seems to set the
IEEE80211_SDATA_DISCONNECT_RESUME flag that will cause a disconnection
on the next resume (if a normal WoWLAN is used).
To solve this, skip the iteration loop when net-detect is set.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Reported-by: Samuel Tan <samueltan@chromium.org>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The new API slightly changes the layout of the version of
the firmware - prepare for that.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Report the average beacon signal and the number of received beacons as
measured by the firmware.
Since the firmware just counts, and doesn't reset the counter at all,
clear it in the firmware whenever we associate. However, accumulate it
over firmware restart.
Since clearing the statistics in the firmware will also clear the ones
for the radio statistics, add those to the accumulator when cleared.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Due to HW bug in the DBGC when driver want to stop the dbg recording it
should wait 100us before collecting the data instead of write 0 to
DBGC_OUT_CTRL.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The legacy scan API is deprecated and not used anymore with 10 and
higher firmware versions. Since we deprecated firmware version 9, we
can remove a whole lot of unused code.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This firmware is not supported anymore. Stop loading this firmware.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Export the radio statistics from the statistics v10 API (if the
firmware also has the capability to fill these statistics) using
the global survey data facility.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
New firmware versions will report statistics using a new version 10
of the API, instead of the current version 8. Add support for this.
This enables getting beacon and radio statistics.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This allows to use the firmware debugging system even when
the configuration values are set hard coded in the firmware.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The shared antenna should be forbidden to use only if there's
high BT activity. Comparing to BT_OFF was effectively causing
us to always forbid using the shared antenna for SISO. This
leads to degraded performance in scenarios where the shared
antenna would have better performance.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Add this to the info printed when reading rate_scale_table.
Useful for debugging.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
ss_force is a debugging option to force a certain single stream
tx mode. It's not useful if it gets reset after tx idle. Fix that.
While at it also make sure any code touching ss_force will only
get compiled if debugfs support is configured.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Newer devices have more PAPD channel groups.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
When a TDLS station is being drained its Tx queues are still in use. Don't
allocate them to a different station in the meantime.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Due to issues with Miracast adapters MIMO reception disable
use of MIMO when for low latency P2P traffic.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Once the FW supports autonomous decision between STBC/BFER/SISO
we no longer set the STBC bit and ANT_AB in the rate table.
However the FW rate in the tx response will have the STBC
or BFER bit set and the antennas set to ANT_AB in case these
were chosen by it. This will cause us to discard any such
response as unmatching the current LQ table and thus break
the rs search cycle completely.
Fix this by relaxing the rate matching in case we're working
with the new API and STBC/BFER are used.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The check to avoid the shared antenna was passed the wrong
antenna parameter. It should have checked whether the antenna of
the next column we're considering is allowed and instead it was
passed the current antenna.
This could lead to a wrong choice of the next column in the rs
algorithm and non optimal performance.
Fixes: commit 219fb66b49 ("iwlwifi: mvm: rs - don't use the shared antenna when BT load is high")
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Currently rs uses the info in mac80211 tx status which is
a translation of the actual rate coming up from the FW in
the tx response. This is matched up against the LQ table first
rate to make sure this tx frame used the current LQ table.
Instead of using the translated mac80211 info it's easier and
cleaner to just pass the actual tx response rate in the driver
private data and use that for matching.
This becomes even more important once the FW begins to
decide on its own whether to use STBC/BFER/SISO.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The quota threshold should be reduced to 4 to update the
firmware more frequently.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Use the chanel hw_value and not the center frequency when
building channel array for scan_config_cmd.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Enable EBS on one shot scans if supported by FW.
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Reviewed-by: Alexander Bondar <alexander.bondar@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
When iwl_mvm_power_update_mac() is called, we have already added the
mac context, so if this call fails we should remove the mac.
CC: <stable@vger.kernel.org> [3.15+]
Fixes: commit e5e7aa8e25 ('iwlwifi: mvm: refactor power code')
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Last EBS status wasn't set to success in the initialization, which
caused the first scan to be without EBS. Fix that.
When EBS is not enabled by the driver, the FW still sends ebs_status success,
which can override EBS failure state. Consider only EBS failures, to avoid
such override. Last_ebs_success is set back to true upon disconnection.
Last_ebs_success wasn't set in umac scan abort flow, fix that too.
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Reviewed-by: Alexander Bondar <alexander.bondar@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Different queue can have different behavior. While it can be
unacceptable for a certain queue to be stuck for 2 seconds
(e.g. the command queue), it can happen that another queue
will stay stuck for even longer (a queue servicing a power
saving client in GO).
The op_mode can even make the timeout be a function of the
listen interval.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This watchdog allows to monitor the transmit queues. When a
queue doesn't progress for a too long time, a timer fires
and then, debug data can be collected.
This watchdog has never been enabled on dvm controlled
devices, so don't enable it there.
In order to have it running on mvm controlled devices, we
need to fix a small issue in the transport layer: mvm
controlled devices use the shadow registers optimization.
In this case, the watchdog wasn't running at all, even if
enabled by the module parameter. Fix that on the way.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
During out-of-channel activities (e.g. scan) TDLS ch-switch responses from
a peer are kept in FW. These packets arrive only after the out-of-channel
activity is complete, which can be in the order of several seconds.
Since TDLS ch-sw has no dialog-token-like mechanism for distinguishing
sessions, use the GP2 time of the incoming ch-switch response to discern
validity. For this purpose record the GP2 time of an outgoing TDLS ch-sw
request and compare to the Rx time of the ch-sw response.
The methods works in practice since the GP2 time of FW-deferred Rx is
accurate and contains the real Rx timestamp.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Add a response-received state and add more limits on allowed requests
in each state of the connection. Previously ch-switch requests from
other peers could interrupt an outgoing active ch-switch. Also stale
packets from the current peer could disrupt the channel switch state.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The base address of the scheduler in the device's memory
(SRAM) comes from two different sources. The periphery
register and the alive notification from the firmware.
We have a check in iwl_pcie_tx_start that ensures that
they are the same.
When we resume from WoWLAN, the firmware may have crashed
for whatever reason. In that case, the whole device may be
reset which means that the periphery register will hold a
meaningless value. When we come to compare
trans_pcie->scd_base_addr (which really holds the value we
had when we loaded the WoWLAN firmware upon suspend) and
the current value of the register, we don't see a match
unsurprisingly.
Trick the check to avoid a loud yet harmless WARN.
Note that when the WoWLAN has crashed, we will see that
in iwl_trans_pcie_d3_resume which will let the op_mode
know. Once the op_mode is informed that the WowLAN firmware
has crashed, it can't do much besides resetting the whole
device.
CC: <stable@vger.kernel.org>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Some devices have 31 TFD queues. Don't enable it yet since
there are still issues with it, but at least prepare the
code for it. There was a bug in the read pointer assignment,
fix that. Also, move the inline functions to iwl-scd.h which
is the right place.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
In certain testing scenarios we'd like to force a decision
between STBC/BFER/SISO. In the normal scenario this decision
is done by the FW. Enable this option vis debugfs.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
VHT Beamformer (BFER) will be used if the peer supports it
and there's a benefit to use it vs. STBC or SISO.
The driver now tells the FW whether BFER and/or STBC are
allowed but the FW will make the decision to use either
or stick to SISO on its own.
BFER is limited to a single remote peer. The driver takes
care of ensuring this to the FW and prioritizes with which
peer BFER will be used.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Printing all the scratch data of the TFDs of that queue is
useless and stuffed the kernel log with data. Remove that.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
