Conflicts:
drivers/net/ethernet/emulex/benet/be_main.c
net/core/sysctl_net_core.c
net/ipv4/inet_diag.c
The be_main.c conflict resolution was really tricky. The conflict
hunks generated by GIT were very unhelpful, to say the least. It
split functions in half and moved them around, when the real actual
conflict only existed solely inside of one function, that being
be_map_pci_bars().
So instead, to resolve this, I checked out be_main.c from the top
of net-next, then I applied the be_main.c changes from 'net' since
the last time I merged. And this worked beautifully.
The inet_diag.c and sysctl_net_core.c conflicts were simple
overlapping changes, and were easily to resolve.
Signed-off-by: David S. Miller <davem@davemloft.net>
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>
The commit below introduced an unsafe dereference of
mvmvif->phy_ctxt. It can be NULL even if we hold the mutex.
We can be handling a BT Coex notification while the vif has
already been unassigned. This can happen since the BT Coex
notification is hanled asynchronuously: we can have started
to handle the BT Coex notification trying to acquire the
mutex while the unassign flow already got it. The BT Coex
notification handling will wait for the mutext. I'll get it
later, but then mvmvif->phy_ctxt will be NULL.
Panic log:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<f985180d>] iwl_mvm_bt_notif_iterator+0x9d/0x340 [iwlmvm]
*pdpt = 0000000000000000 *pde = f000eef300000007
Oops: 0000 [#1] SMP
Workqueue: events iwl_mvm_async_handlers_wk [iwlmvm]
task: ed719b20 ti: ec03e000 task.ti: ec03e000
EIP: 0060:[<f985180d>] EFLAGS: 00010202 CPU: 2
EIP is at iwl_mvm_bt_notif_iterator+0x9d/0x340 [iwlmvm]
EAX: 00000000 EBX: f6d3cb70 ECX: f6d3cb70 EDX: 00000000
ESI: ec03fe40 EDI: efeb8810 EBP: ec03fdf0 ESP: ec03fdac
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
CR0: 80050033 CR2: 00000000 CR3: 01a1a000 CR4: 001407f0
Stack:
f743ca80 f744a404 ec03fdcc c10e3952 00003aba f743ca80 00000246 f743ca80
00000246 00000000 00000001 00000000 ebd45ff6 ebd458a4 f6d3c500 ebd45578
ebd44b01 ec03fe18 f99e1bc2 00000002 ebd44bc0 f9851770 00000000 f6d3c500
Call Trace:
[<c10e3952>] ? ring_buffer_unlock_commit+0xa2/0xd0
[<f99e1bc2>] __iterate_interfaces+0x82/0x110 [mac80211]
[<f9851770>] ? iwl_mvm_bt_coex_reduced_txp+0x140/0x140 [iwlmvm]
[<f99e1c6a>] ieee80211_iterate_active_interfaces_atomic+0x1a/0x20 [mac80211]
[<f9851427>] iwl_mvm_bt_coex_notif_handle+0x77/0x280 [iwlmvm]
[<f9852161>] iwl_mvm_rx_bt_coex_notif_old+0x211/0x220 [iwlmvm]
[<f9850b8b>] iwl_mvm_rx_bt_coex_notif+0x19b/0x1b0 [iwlmvm]
[<f983944f>] iwl_mvm_async_handlers_wk+0x7f/0xe0 [iwlmvm]
CC: <stable@vger.kernel.org> [3.19+]
Fixes: 123f515635 ("iwlwifi: mvm: BT Coex - add support for TTC / RRC")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
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>
The commit below didn't update the max_ht_ampdu_exponent
for the devices listed in iwl-[1-6]000.c which, in result,
became 0 instead of 8K. This reduced the size of the Rx
AMPDU from 64K to 8K which had an impact in the Rx
throughput. One user reported that because of this, his
downstream throughput droppped by a half.
CC: <stable@vger.kernel.org> [3.19]
Fixes: c064ddf318 ("iwlwifi: change max HT and VHT A-MPDU exponent")
Reported-and-tested-by: Valentin Manea <linux-wireless@mrs.ro>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Current FW is declaring support for BFER in ucode_capa.capa
but it doesn't really support it unless the new LQ_SS_PARAMS API
is supported as well. Avoid publishing BFER in our VHT caps
if FW doesn't support.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
iwl_mvm_stop_roc removes TE only if running flag is set. This is not correct
since this flag is only set when the TE is started.
This resulted in a TE not being removed, when mac80211 believes that there are
no active ROCs.
Fixes: bf5da87f60 ("iwlwifi: mvm: add remove flow for AUX ROC time events")
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: Matti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
In certain conditions, mac80211 may ask us to stop a scan (scheduled
or normal) that is not running anymore. This can also happen when we
are doing a different type of scan, for instance, mac80211 can ask us
to stop a scheduled scan when we are running a normal scan, due to
some race conditions. In this case, we would stop the wrong type of
scan and leave everything everything in a wrong state.
To fix this, simply ignore scan stop requests for scans types that are
not running.
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>
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")
CC: <stable@vger.kernel.org> [3.19]
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>
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>
A scan abort command failure is not that unusual, since we may try to
send it after the scan has actually completed but before we received
the completed notification from the firmware. The scan abort can also
fail for other reasons, such as a timeout. In such cases, we should
clear things up so the next scans will work again. To do so, don't
return immediately in case of failures, but call
ieee80211_scan_completed() and clear the scan_status flags.
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>
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>
