This will allow to track how BT core updates the driver.
This is required to debug the BT Coexistence mechanism.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When BT traffic load gets higher, we want to avoid using the
shared antenna. In order to do so, we need to tell the AP
that we don't support MIMO any more, or at least not all
the time: in short, use the SMPS to achieve this.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The BT-Coex notification is sent by the fw when there are
updates wrt. BT activity. Driver action might be taken
based on the info in this notification.
For now, update the Ack/Cts_kill_msk if HID / SCO / A2DP
profiles are active.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Send the PRIO table before the calibrations. This table
tells the fw what priority to give to what (WiFi / BT)
according to events.
Send a hardcoded BT_COEX command to the fw to enable basic
BT coexistence.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is the API to tell the fw to handle the BT Coexistence.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Then the transport can print it nicely in its debug prints.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If all the pieces of iwlwifi are built into the kernel
then there's no need for it to export its symbols to
other modules, so prevent that.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Now that we have two drivers (DVM and MVM) stop selecting
the DVM one (but make it default) and allow enabling only
the MVM driver if so desired. Add a warning for the case
of having neither DVM nor MVM enabled -- that's useless.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When modifying a MAC, we update its beacon system time which
is taken as a base to calculate TBTT. The firmware doesn't use
the new timestamp because the time is never used after the MAC
and broadcast station were added, but it is safer to not rely
on this and avoids the overhead of reading the register every
time the MAC is updated.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Newer devices can work on different buses. This means that
their configuration can be shared between different buses.
Hence the configuration structures should exported to all
the buses and not only to PCIE. Change this.
Note that this requires all the fields to be the same
amongst the buses. If differences will appear, we can always
define a part that is bus dependent. Today, this is not
needed.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
All the data coming from the fw must have a length that is
multiple of 4.
This doesn't change anything to the way we handle the
notification.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Update the NVM parsing functions to add VHT capabilities;
they are only added for 5 GHz, of course. This assumes
that all devices with NVM reading (rather than EEPROM)
that support 5 GHz have VHT, which is true right now.
Signed-off-by: Eytan Lifshitz <eytan.lifshitz@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When a station is added, we need to tell the firmware what
the SMPS settings and number of streams are. After having
the initial data, the firmware will track future changes
by itself.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
With remote wake, the firmware creates a TCP connection
and sends some configurable data on it, until a special
TCP data packet from the server is received that triggers
a wakeup. The configuration is a bit tricky because it is
based on packet pattern matching but this is hidden in
the driver and the exposed API in cfg80211 is just based
on the required TCP connection parameters.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This removes an open coded simple_open() function and
replaces file operations references to the function
with simple_open() instead.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Instead of using (char *)__get_dynamic_array use
__get_str. The latter is actually a macro that
expands to the former in the code, but trace-cmd
in userspace can parse __get_str only.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
All hardware after 4965 supports this. It's likely that
it wasn't set because for 4965 it was irrelevant (HT is
only supported on 5 GHz there) and then never updated.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211 tells us when we need to dump the frames from the
AGG queue instead of releasing them as single MPDUs.
Being able to differentiate between the different cases
(IEEE80211_AMPDU_TX_STOP_*) allows us to handle races better.
When the station is removed, mac80211 asks to flush and
removes the station right away.
This allows to avoid a case where we still have frames in
AGG queues, but the station has been remove already.
Note that we can have frames on the shared queues, but this
is not a problem: the station in the fw will be kept until
all the frames on the shared queues have been drained.
AGG queues are a special case since they are dynamically
allocated.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Use the number of addresses (max 5) from the NVM
instead of limiting to 2 artificially.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's a bug that causes the rate scaling to get stuck
when it has to use single-stream rates with a peer that
can do GF and SGI; the two are incompatible so we can't
use them together, but that causes the algorithm to not
work at all, it always rejects updates.
Disable greenfield for now to prevent that problem. The
MVM driver currently only works on devices that don't
support greenfield anyway, but better be safe and not
allow us to forget about this.
Signed-off-by: Beni Lev <beni.lev@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The 7000 series devices don't support HT greenfield mode
so don't advertise or use it.
Signed-off-by: Beni Lev <beni.lev@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
1. For P2P Device filter in only probe requests.
2. For station mode filter in all group cast frames,
and in addition beacons as long as we are not associated.
3. For AP/GO filter in all group cast and in addition probe
requests.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The current fw doesn't currently support cts to self. There
is a bug in the fw that prevents us from using cts to self.
Use full protection (including RTS) for now.
Signed-off-by: Dor Shaish <dor.shaish@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When we stop an AGG session, we need to look at the sequence
numbers in in the private area of the ieee80211_sta struct.
This allows us to know is the queue is empty. To get access
to this private area, we use fw_id_to_mac_id that maps
sta_id (index of the STA in fw table) to ieee80211_sta.
When the STA exists in fw, but not in mac80211, we set
an ERR ptr in fw_id_to_mac_id.
But if we first set an ERR ptr to fw_id_to_mac_id, and only
then flush the queues, then we won't be able to access the
sequence numbers in ieee80211_sta from the reclaim flow.
This means that we will never be able to release an AGG
queue when a station is deleted.
So first, flush the queue. That will let the reclaim flow
call iwl_mvm_check_ratid_empty which will disable the AGG
queue as needed, and only then, remove the mapping in
fw_id_to_mac_id.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We didn't check that we allowed to start Tx AGG. This can
possibly be avoided by a module parameter. Fix that.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
7000.c was released as GPL only by mistake: it should be
dual licensed - GPL / BSD.
The file that contains the license in the kernel is COPYING
and not LICENSE.GPL.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is needed to resolve some conflicts that would otherwise
happen between wireless-next and the code here.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This flow happens when we get a failed single Tx response
on an AMPDU queue. In this case, the frame won't be sent
any more. So we need to move the window on the recipient
side. This is done by a BAR.
Now if we are in the following case: 10, 12 and 13 are ACKed
and 11 isn't.
10 11 12 13.
V X V V
Then, 11 will be sent 16 times as an MPDU (as oppsed to
A-MPDU). If this failed, we are entering the flow described
above. So we need to send a BAR with ssn = 12.
But in this case, the scheduler will tell us to free frames
up to 13 (included).
So, it is perfectly possible to get a failed single Tx
response on an AMPDU queue that makes the scheduler's ssn
jump by more than 1 single packet.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Make the rssi more accurate by taking in count per-chain AGC
values. Without this, the RSSI reports inaccurate values.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since the device is being restarted, all the Rx / Tx Block
Ack sessions are been wiped out by the driver. So ignore
the requests from mac80211 that stops Tx agg while
reconfiguring the device.
Note that stopping a non-existing Rx BA session is harmless,
so just honor mac80211's request.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This fix removes the override of calibration request values sent
to the FW.
Due to that, the sending of default values to now implemented
calibrations is removed.
Signed-off-by: Dor Shaish <dor.shaish@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The phy_cfg is given from the TLV value and does not have to be
built by us.
Signed-off-by: Dor Shaish <dor.shaish@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We must set the valid TX antennas number in the ucode before
sending the phy_cfg_cmd and request for calibrations.
Signed-off-by: Dor Shaish <dor.shaish@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This situation is clearly an error situation and the only
way to recover is to restart the driver / fw.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Recently in commit 8a964f44e0
("iwlwifi: always copy first 16 bytes of commands") we fixed
the problem that the hardware writes back to the command and
that could overwrite parts of the data that was still needed
and would thus be corrupted.
Investigating this problem more closely we found that this
write-back isn't really ordered very well with respect to
other DMA traffic. Therefore, it sometimes happened that the
write-back occurred after unmapping the command again which
is clearly an issue and could corrupt the next allocation
that goes to that spot, or (better) cause IOMMU faults.
To fix this, allocate coherent memory for the first 16 bytes
of each command, containing the write-back part, and use it
for all queues. All the dynamic DMA mappings only need to be
TO_DEVICE then. This ensures that even when the write-back
happens "too late" it can't hit memory that has been freed
or a mapping that doesn't exist any more.
Since now the actual command is no longer modified, we can
also remove CMD_WANT_HCMD and get rid of the DMA sync that
was necessary to update the scratch pointer.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Supporting 8K A-MSDU means that we need to allocate order 1
pages for every Rx packet. Even when there is no traffic.
This adds stress on the memory manager. The handling of
compound pages is also less trivial for the memory manager
and not using them will make the allocation code run faster
although I didn't really measure.
Eric also pointed out that having huge buffers with little
data in them is not very nice towards the TCP stack since
the truesize of the skb is huge. This doesn't allow TCP
to have a big Rx window.
See https://patchwork.kernel.org/patch/2167711/ for details.
Note that very few vendors will actually send A-MSDU.
Disable this feature by default.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The IWL_MAX_CMD_TFDS name for this constant is wrong, the
constant really indicates how many TBs we can use in the
driver for a single command TFD, rename the constant and
also add a comment explaining it.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The reason we mapped them bidirectionally was that not doing
so had caused IOMMU exceptions, due to the fact that the HW
writes back into the command. Now that the first part of the
command including the write-back part is always in the first
buffer, we don't need to map the remaining buffer(s) bidi
and can get rid of the special-casing for commands.
This is a requisite patch for another one to fix DMA mapping.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The PIC was supposed to be a small signature appended to the
PhyDB data, but the signature isn't really static and thus
attempting to check it just causes the warnings spuriously
so remove them.
Signed-off-by: Dor Shaish <dor.shaish@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The wakeup packet in the status response is padded out
to a multiple of 4 bytes by the firmware for transfer
to the host, take that into account when checking the
length of the command.
Also, the reported wakeup packet includes the FCS but
the userspace API doesn't, so remove that. If it is a
data packet it is reported as an 802.3 packet but I
forgot to take into account and remove the encryption
head/tail, fix all of that as well.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When stations are removed while packets are in the queue,
we drain the queues first, and then remove the stations.
If this happens in AP mode while the interface is removed
the MAC context might be removed from the firmware before
we removed the station(s), resulting in a SYSASSERT 3421.
This is because we remove the MAC context from the FW in
stop_ap(), but only flush the station drain work later in
remove_interface().
Refactor the code a bit to have a common MAC context
removal preparation first to solve this.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The FH hardware will always write back to the scratch field
in commands, even host commands not just TX commands, which
can overwrite parts of the command. This is problematic if
the command is re-used (with IWL_HCMD_DFL_NOCOPY) and can
cause calibration issues.
Address this problem by always putting at least the first
16 bytes into the buffer we also use for the command header
and therefore make the DMA engine write back into this.
For commands that are smaller than 16 bytes also always map
enough memory for the DMA engine to write back to.
Cc: stable@vger.kernel.org
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
I removed a bit too much info last time.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Theoretically, the card may not enter CTKILL:
In case the timer that iwl_prepare_ct_kill_task is setting,
will expire before tt->state revert to its previous state.
Signed-off-by: Eytan Lifshitz <eytan.lifshitz@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The time event data structures are required also for P2P Device
interface.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The FW can differentiate between scans, according to the interface
type on which the scan was issues. Supply the interfaces type
information to the FW.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Occasionally, we would run into this warning:
iwlwifi 0000:02:00.0: U iwl_mvm_protect_session extend 0x2601: only 200 ms left
iwlwifi 0000:02:00.0: U iwl_mvm_remove_time_event Removing TE 0x2601
iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command TIME_EVENT_CMD (#29), seq: 0x0925, 60 bytes at 37[5]:9
iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command TIME_EVENT_CMD
iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command TIME_EVENT_CMD
iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command TIME_EVENT_CMD (#29), seq: 0x0926, 60 bytes at 38[6]:9
iwlwifi 0000:02:00.0: U iwl_mvm_time_event_response TIME_EVENT_CMD response - UID = 0x2601
iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command TIME_EVENT_CMD
iwlwifi 0000:02:00.0: U iwl_mvm_rx_time_event_notif Time event notification - UID = 0x2701 action 1
wlan0: associate with 00:0a:b8:55:a8:30 (try 2/3)
------------[ cut here ]------------
WARNING: at drivers/net/wireless/iwlwifi/mvm/time-event.c:269 iwl_mvm_time_event_send_add+0x163/0x1a0 [iwlmvm]()
Modules linked in: [...]
Call Trace:
[<c1046e42>] warn_slowpath_common+0x72/0xa0
[<c1046e92>] warn_slowpath_null+0x22/0x30
[<f8cad913>] iwl_mvm_time_event_send_add+0x163/0x1a0 [iwlmvm]
[<f8cadead>] iwl_mvm_protect_session+0xcd/0x1c0 [iwlmvm]
[<f8ca2087>] iwl_mvm_mac_mgd_prepare_tx+0x67/0xa0 [iwlmvm]
[<f882a130>] ieee80211_sta_work+0x8f0/0x1070 [mac80211]
The reason is a problem with asynchronous vs. synchronous
commands, what happens here is the following:
* TE 0x2601 is removed, the TIME_EVENT_CMD for that is async
* a new TE (will be 0x2701) is created, the TIME_EVENT_CMD
for that is sync and also uses a notification wait for the
response (to avoid another race condition)
* the response for the TE 0x2601 removal comes from the
firmware, and is handled by the notification wait handler
that's really waiting for the second response, but can't
tell the difference, we therefore see the message
"TIME_EVENT_CMD response - UID = 0x2601" instead of
"TIME_EVENT_CMD response - UID = 0x2701".
Fix this issue by making the TE removal synchronous as well,
this means that we wait for the response to that command
first, before there's any chance of sending a new one.
Also, to detect such issues more easily in the future, add
a warning to the notification handler that detects them.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
