Statistics should be collected according to the actual rate a
frame/aggregation was transmitted and not according to the initial rate
from the last LQ command (these rates are different if the frames were
retransmitted at a lower rate from the rate scale table).

This is needed to remove throughput degradation.
Signed-off-by: NGregory Greenman <gregory.greenman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The bit was set only if there was at least one reclaimed frame in an
aggregation. It's important to set it also in the case that the whole
A-MPDU was lost, otherwise rate scaling statistics will not be
updated correctly. Thus, set it always in ba notification handler.

This fixes a throughput degradation of about 20% in certain scenarios
with multiple streams on 11ac.
Signed-off-by: NGregory Greenman <gregory.greenman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When we create a regulatory domain out of an MCC
notification, we need to make sure that all the channels
in the rule have the exact same properties.
The current code mixes channel 36 and 40 although 36 can be
a control channel with HT40+ (36, 40) whereas 40 can't be
a control channel with HT40+ since  (40, 44) is invalid.

Because of that, cfg80211 would allow to connect in 40MHz
to APs that are configured to channel 40 HT40+ and that made
our firmware assert.

Fix this by checking the bandwidth flags before taking the
decision if the rule should be split.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=195299 partly.

Fixes: af45a900 ("iwlwifi: create regdomain from mcc_update_cmd response")
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The firmware now adds a new DWORD for the MLME offload's
capability even on firmware versions that don't support
it.
Add the TLV bit to avoid getting the print:
capa flags index 3 larger than supported by driver.

This fixes the bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=196195Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When we enabled TCP checksum offload, we need to tell the
firmware where the IP header starts. If we have an IV, then
we need to adapt that value since the IV is placed before
the SNAP header. This is true only for cases where the
driver adds the IV, not the WEP case in which the IV is
added by the firmware itself.

On A000 devices series, the IV is always added by the
device.

Fix this.

Fixes: 5e6a98dc ("iwlwifi: mvm: enable TCP/UDP checksum support for 9000 family")
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Due to a bugfix in wireless tree and the commit mentioned below a merge
was needed which went haywire. So the submitted change resulted in the
function brcmf_sdiod_sgtable_alloc() being called twice during the probe
thus leaking the memory of the first call.

Cc: stable@vger.kernel.org # 4.6.x
Fixes: 4d792895 ("brcmfmac: switch to new platform data")
Reported-by: NStefan Wahren <stefan.wahren@i2se.com>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: NHante Meuleman <hante.meuleman@broadcom.com>
Signed-off-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The commit to rework the headroom check in start_xmit() now calls
pxskb_expand_head() unconditionally if the header is CoW. Unfortunately,
it does so with the delta between the extant headroom and the header
length, which may be negative if there is already sufficient headroom.

pskb_expand_head() does allow for size being 0, in which case it just
copies, so clamp the header delta to zero.

Opening Chrome (and all my tabs) on a PCIE device was enough to reliably
hit this.

Fixes: 270a6c1f ("brcmfmac: rework headroom check in .start_xmit()")
Signed-off-by: NDaniel Stone <daniels@collabora.com>
Cc: Arend Van Spriel <arend.vanspriel@broadcom.com>
Cc: James Hughes <james.hughes@raspberrypi.org>
Cc: Hante Meuleman <hante.meuleman@broadcom.com>
Cc: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Cc: Franky Lin <franky.lin@broadcom.com>
Tested-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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>

When IBSS was implemented for DQA, we missid a few places where it
should be handled in the same way as AP.

Fixes: ee48b722 ("iwlwifi: mvm: support ibss in dqa mode")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

iwl_trace_data is somewhat confusing. It returns a bool
that tells if the payload of the skb should be added to
the tx_data event. If it returns false, then the payload
of the skb is added to the tx event.

The purpose is to be able to start tracing with
-e iwlwifi
and record non-data packets only which saves bandwidth.

Since EAPOLs are important, seldom and not real data
packet (despite being WiFi data packets), they are
included in tx event and thus iwl_trace_data returns false
on those. This last part was buggy, and because of that,
all the data packets were included in the tx event.

Fix that.

Fixes: 0c4cb731 ("iwlwifi: tracing: decouple from mac80211")
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We don't set the error code here so we end up returning ERR_PTR(0) which
is NULL.  The caller doesn't expect that so it results in a NULL
dereference.

Fixes: 2e5d4a8f ("iwlwifi: pcie: Add new configuration to enable MSIX")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Sometimes, we can have an firmware crash while trying to
recover from a previous firmware problem.
When that happens, lots of things can go wrong. For example
the stations don't get added properly to mvm->fw_id_to_mac_id.

Mac80211 tries to stop A-MPDU upon reconfig but in case of
a firmware crash we will bail out fairly early and in the
end, we won't delete the A-MPDU Rx timeout.
When that timer expired after a double firmware crash,
we end up dereferencing mvm->fw_id_to_mac_id[sta_id]
which is NULL.

Fixes: 10b2b201 ("iwlwifi: mvm: add infrastructure for tracking BA session in driver")
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Before TVQM, all TX queues were allocated straight at init.
With TVQM, queues are allocated on demand and hence we need
to check if a queue exists before dereferencing it.

Fixes: 66128fa08806 ("iwlwifi: move to TVQM mode")
Signed-off-by: NMordechai Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

iwlagn_check_ratid_empty takes the tid as a parameter, but
it doesn't check that it is not IWL_TID_NON_QOS.
Since IWL_TID_NON_QOS = 8 and iwl_priv::tid_data is an array
with 8 entries, accessing iwl_priv::tid_data[IWL_TID_NON_QOS]
is a bad idea.
This happened in iwlagn_rx_reply_tx. Since
iwlagn_check_ratid_empty is relevant only to check whether
we can open A-MPDU, this flow is irrelevant if tid is
IWL_TID_NON_QOS. Call iwlagn_check_ratid_empty only inside
the
	if (tid != IWL_TID_NON_QOS)

a few lines earlier in the function.

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

This reverts commit f95d95a7.

With commit f95d95a7 ("rtlwifi: btcoex: rtl8723be: fix ant_sel not
work"), the kernel has a NULL pointer dereference oops. This content and
the proper fix will be included in a later patch.

Fixes: f95d95a7 ("rtlwifi: btcoex: rtl8723be: fix ant_sel not work")
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Ping-Ke Shih <pkshih@realtek.com>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Birming Chiu <birming@realtek.com>
Cc: Shaofu <shaofu@realtek.com>
Cc: Steven Ting <steventing@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Recent change in brcmf_sdio_txpkt_hdalign() changed the
behavior and now always returns 0. This resulted in a
regression which basically renders the device useless.

Fixes: 270a6c1f ("brcmfmac: rework headroom check in .start_xmit()")
Reported-by: NS. Gilles <sgilles@math.umd.edu>
Tested-by: NS. Gilles <sgilles@math.umd.edu>
Signed-off-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Don't populate array glrt_table on the stack but make it static.
Makes the object code a smaller by over 670 bytes:

Before:
   text	   data	    bss	    dec	    hex	filename
 131772	   4733	      0	 136505	  21539	rt2800lib.o

After:
   text	   data	    bss	    dec	    hex	filename
 131043	   4789	      0	 135832	  21298	rt2800lib.o
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Acked-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The lower level nl80211 code in cfg80211 ensures that "len" is between
25 and NL80211_ATTR_FRAME (2304).  We subtract DOT11_MGMT_HDR_LEN (24) from
"len" so thats's max of 2280.  However, the action_frame->data[] buffer is
only BRCMF_FIL_ACTION_FRAME_SIZE (1800) bytes long so this memcpy() can
overflow.

	memcpy(action_frame->data, &buf[DOT11_MGMT_HDR_LEN],
	       le16_to_cpu(action_frame->len));

Cc: stable@vger.kernel.org # 3.9.x
Fixes: 18e2f61d ("brcmfmac: P2P action frame tx.")
Reported-by: N"freenerguo(郭大兴)" <freenerguo@tencent.com>
Signed-off-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The pci_error_handlers->reset_notify() method had a flag to indicate
whether to prepare for or clean up after a reset.  The prepare and done
cases have no shared functionality whatsoever, so split them into separate
methods.

[bhelgaas: changelog, update locking comments]
Link: http://lkml.kernel.org/r/20170601111039.8913-3-hch@lst.deSigned-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

We should not copy the MCS set from hostapd RX-STBC. We
have to just use the MCS set supported by the hardware.
This fixes an issue, where mwifiex is advertising wrong
MCS sets in beacons.

Fixes: 474a41e9 ("mwifiex: update MCS set as per RX-STBC bit from hostapd")
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The driver used cfg80211_connect_result() which is basically a wrapper
around cfg80211_connect_done() passing a subset of the information that
can be passed. For upcoming functionality this is not sufficient so
switching to use cfg80211_connect_done().
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>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Adding callbacks for PMK provisioning. If firmware supports offloading
it is indicated to user-space that 802.1X offload is supported.
Signed-off-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The firmware may have supplicant code built-in. This is detected
by the driver and indicated in the wiphy features flags. User-space
can use this flag to determine whether or not to provide the
pre-shared key material in the nl80211 CONNECT command.
Reviewed-by: NGautam (Gautam Kumar) Shukla <gautams@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Bump the maximum API supported by these device families to 33.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The newest devices need a longer time to reset because of
their more complex hardware. Wait 5ms after device reset.
Consolidate all the places that reset the device in the
PCIe transport to avoid future bugs.

While at it, unify the flow to use set_bit instead of full
write as requested by the hardware designers.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

iwl_pcie_apm_init can fail so make sure that the caller
takes the status into account.
Also, ensure that the error that iwl_pcie_apm_init can emit
will appear in the kernel log by default.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When a station that's not associated sends a data frame (e.g. an NDP)
hostapd will respond with a disassoc frame, telling it that it's not
associated. The station might also not be authenticated, in which case
there will not be a station entry for it, and as a result we need to
accept such frames without a station.

Fixes: 3ee0f0e2 ("iwlwifi: mvm: fix DQA AP mode station assumption")
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The API has changed - update the code.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When we get a non-STA frame to transmit in client mode, we try to use
the IWL_MVM_DQA_BSS_CLIENT_QUEUE queue (queue #4). However, at this
point, the queue might not be allocated at all, causing warnings. The
scenario on which this happened was a race condition between mac80211
and our queue allocation work:
 * mac80211 sends auth
 * we stop mac80211 queues to allocate a hw queue
 * authentication is aborted
 * we allocate HW queue and start mac80211 queues
 * mac80211 removes station
 * mac80211 hands us the auth frame from the pending queue

At this point, since mac80211 has already removed the station, we try
to transmit the frame through this special non-station case on queue
4 anyway.

In order to really use it properly, we'd have to again go through the
hw queue allocation work, and attach it to a station, etc. In this
case that isn't possible (there's no station anymore), but if this
special case were needed, then we'd have to do it this way.

However, the special case is documented to exist for TDLS, but can't
trigger there because the TDLS setup frames etc. are normal to-DS
frames going to the peer through the AP. Testing also confirms that
this code path isn't triggered in TDLS.

Therefore, remove the code path to avoid using an unused queue. The
erroneous frame described above will still be transmitted on the AUX
queue, but arguably that's a mac80211 problem, which will eventually
be fixed by moving everything there to TXQs.

Fixes: e3118ad7 ("iwlwifi: mvm: support tdls in dqa mode")
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When we get large sends on non-QoS association, we had a
bug that mangled the SNAP header. Fix that.

Fixes: a6d5e32f ("iwlwifi: mvm: send large SKBs to the transport")
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When going into suspend, the HW configuration for MSI-X will
likely be lost. As a consequence, after waking up, all IRQ
causes will be mapped to interrupt 0, and as a consequence we
don't notice the interrupt because in most cases this is an
interrupt for a queue, and getting it doesn't read the other
cause registers.

Fixes: 2e5d4a8f ("iwlwifi: pcie: Add new configuration to enable MSIX")
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Getting the TID of a packet before we know it is a QoS data
packet isn't a good idea. Delay the TID retrieval until
we know the packet is a QoS data packet.

Fixes: bb81bb68 ("iwlwifi: mvm: add Tx A-MSDU inside A-MPDU")
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When in non-DQA mode, mac80211 actually gets a pretty much perfect
idea (in vif->hw_queue/cab_queue) of which queues we're using. But
in DQA mode, this isn't true - nonetheless, we were adding all the
queues, even the ones stations are using, to the queue allocation
bitmap.

Fix this, we should only add the queues we really are using in DQA
mode:
 * IWL_MVM_OFFCHANNEL_QUEUE, as we use this in both modes
 * mvm->aux_queue, as we use this in both modes - mac80211
   never really knows about it but we use it as a cookie
   internally, so can't reuse it
 * possibly the GCAST queue (cab_queue)
 * all the "queues" we told mac80211 about we were using on each
   interface (vif->hw_queue), these are entirely virtual in this
   mode

Also add back the failure now when we can't allocate any more of
these - now virtual - queues; this was skipped in DQA mode and
would lead to having multiple ACs or even interfaces use the same
queue number in mac80211 (10, since that's the limit), which would
stop far too many queues if stopped.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

There may be a difference between the mac80211 vif->cab_queue and
mvmvif->cab_queue, particularly with TVQM. Make the code map this
earlier, instead of first returning the mac80211 one again from
iwl_mvm_get_ctrl_vif_queue().
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In the driver, we track which hardware queue is associated with
which mac80211 "hw_queue", in order to be able to stop and wake
it. When moving these bitmaps out of the queue_info structures,
the type of the bitmap was erroneously changed from u32 to u8,
presumably in order to save memory.

Turns out that u32 isn't needed, because the highest queue we
can ever tell mac80211 is always < 16, but a u16 definitely is
needed, queues >=8 do happen.

While at it, throw a BUILD_BUG_ON() into the place where we set
the limit (mvm->first_agg_queue) and a warning when it actually
gets put into the bitmap.

The consequence of this bug is that full HW queues associated
with such a too-high mac80211 number never stop higher layer
queues when full, and thus would simply drop all packets that
couldn't be enqueued to the hardware queue.

Fixes: 34e10860 ("iwlwifi: mvm: remove references to queue_info in new TX path")
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The code was intended to enable IP header checksumming on AMSDUs, but
failed to really do so because the A-MSDU bit was set after all the
checksumming bits, and thus checking for A-MSDU could never be true.

Fix this by setting the A-MSDU bit before the offload bits.

Fixes: 5e6a98dc ("iwlwifi: mvm: enable TCP/UDP checksum support for 9000 family")
Reported-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We have tracing for both pre-ICT and ICT interrupts, including all
the data read there. Extend the tracing to MSI-X interrupts.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When hostapd adds a station, it does so before sending the association
response frame, so that it can indicate the correct status code in the
response.

However, when this then fails, or the association response already is
a reject for some other reason, then there's no station entry and thus
no per-station management queue to send the response on and it must be
sent on the probe response queue. The code should therefore not warn.

In theory, we could check and warn if the status code is success, but
that seems excessive, so just relax the check to allow any association
response frames.

Fixes: 3ee0f0e2 ("iwlwifi: mvm: fix DQA AP mode station assumption")
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Only a000-series devices were going to use this, but actually
initialize using the context info, which includes paging, so
this code is never invoked; remove it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Since we now support 8 device families, move their configuration
files into a new subdirectory "cfg".
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>