With just %16, it means 16 characters padding, but we really
don't want to print "0x         1F4547B", but instead want to
have this filled with zeroes, so we need the 0.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In case there are bugs in this area, this data can
help with debugging.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Take the NSS value from 'rx_vec' rather than from 'rate_n_flags'.
The rate_n_flags has only 2 bits for the NSS giving a max of 4SS
(0 = 1SS etc.). Since there may be up to 8SS use the rx_vec which
has 3 bits for the NSS.
While at it, fix the rx_vec array to length of 2.
Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When setting the EOF bit in Rx flags (propagated
to radiotap) do not depend it on the PPDU type (SU/MU/TB)
since it doesn't.
Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The code checks that we haven't exceeded the maximum number of
TBs by comparing to a define of gen1 instead of gen2, fix it.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Merge tag 'iwlwifi-next-for-kalle-2019-01-25' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next

First batch of iwlwifi patches intended for v5.1

* Support for Target Wakeup Time (TWT) -- a feature that allows the AP
  to specify when individual stations can access the medium;
* Support for mac80211 AMSDU handling;
* Debugging infrastructure work;
* Preparations for improvements in the device selection code;
* Some new PCI IDs;
* Some updates in the documentation;
* A bunch of fixes for issues found with static analyzers;
* A couple of janitorial fixes from the community;
* Some fixes in P2P;
* Other cleanups and small fixes;

Document the WoWLAN patterns command structure.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

These are unused by both firmware and driver, remove them.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The value in num_lmac can be bigger than mem_cfg->lmac array,
warn in case it's bigger.
Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com>
Fixes: 68025d5f ("iwlwifi: dbg: refactor dump code to improve readability")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The value in txq_id can be out of array scope,
validate it before accessing the array.
Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com>
Fixes: cf961e16 ("iwlwifi: mvm: support dqa-mode agg on non-shared queue")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Klocwork complains about copying from dev_cmd->hdr if
copying more than 4 bytes since it means part of the
copy is from the next field. This isn't a real bug,
but for not failing Klocwork next time - fix this.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The driver assumes certain sizes and lengths aren't crossed in some
places.  Make sure this indeed happens.

Found by Klocwork.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

There is no point in having num_active_macs signed
since it should never be negative. Set it to be an
unsigned variable to ensure this.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

A few commands refer to a struct that no longer exists
in the mentioned name. Our trace-cmd parsing scripts
rely on these mentioned names and can't find them,
resulting in these commands not being parsed nicely.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

As this is not needed and might cause interoperability issues
during pairing with devices that would not reply to RTS frames.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When a frame is transmitted without a station, need to set the rate
and flags in the Tx command, as the FW does not have any information as
to what rate and flags should be used for this frame.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When a time event for a P2P Device interface is done, it is possible
that there is still a frame pending for transmission that should be
flushed.

Set the IWL_MVM_STATUS_NEED_FLUSH_P2P to indicate to the ROC worker
that P2P Device station queue need also to be flushed.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We have a slightly better TCP performance with GSO.
Add it back, it can co-exist with the code that builds
AMSDUs in mac80211.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Trivial fix to spelling mistake in IWL_ERR error message
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Use kmemdup rather than duplicating its implementation in
iwl_parse_nvm_mcc_info().
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We erroneously had some values for NGI in the table we give as an
example in rs_fill_rates_for_column(), when they should be SGI.
Change them so that they match what we say.
Reported-by: NRémy Grünblatt <remy@grunblatt.org>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Support getting mac80211 building AMSDUs for us. Remove GSO
support from mvm - we don't need it anymore.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Move to use the new mac80211 TXQs implementation. This has
quite a few benefits for us. We can get rid of the awkward
mapping of DQA to mac80211 queues. We can stop buffering
traffic while waiting for the queue to be allocated. We can
also use mac80211 AMSDUs instead of building it ourselves.

The usage is pretty simple:
Each ieee80211_txq contains iwl_mvm_txq. There is such a
queue for each TID, and one for management frames. We keep
having static AP queues for probes and non-bufferable MMPDUs,
along with broadcast and multicast queues. Those are being
used from the "old" TX invocation path - iwl_mvm_mac_tx.

When there is a new frame in a TXQ, iwl_mvm_mac_wake_tx is
being called, and either invokes the TX path, or allocates
the queue if it does not exist.

Most of the TX path is left untouched, although we can consider
cleaning it up some more, for example get rid of the duplication
of txq_id in both iwl_mvm_txq and iwl_mvm_dqa_txq_info.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

On any failure, including if we crash the firmware or get garbage
data, we currently ignore this and pretend the OTP was empty.
Clearly, this isn't typically the case.

In cases other than the firmware saying it can't read the requested
section, or the section having ended, make the access actually fail
and trickle the error up through the layers to fail init.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add prph dump addresses to support prph dump in 22000 HW.
Signed-off-by: NShahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We don't support 9000 A-step devices anymore, so we can remove the
suspend/resume workaround.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

This function was only used by 9000 A-step devices, which we don't
support anymore, so it can be removed.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We don't support 9000 A-step devices anymore, so we can remove support
for loading both the a0/a0 and a0/b0 FWs.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The new (CDB) statistics API is used by non-CDB devices
as well. Look at the right TLV flag to know which version
of the statistics notification to use.
To avoid confusion, remove the _cdb suffix from the
structure name.
While at it, remove a structure that was never used.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Fixes: 678d9b6d ("iwlwifi: mvm: update rx statistics cmd api")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

add few PCI ID'S for 22560, 9260 and killer series.
Signed-off-by: NIhab Zhaika <ihab.zhaika@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

One of the cfg struct names is mistakenly "iwl22000", when it should
be "iwl22560".

Chage-Id: If9fbfa4bceef81d028c90c98d47115fbe39da547
Signed-off-by: NIhab Zhaika <ihab.zhaika@intel.com>
Fixes: 2f7a3863 ("iwlwifi: rename the temporary name of A000 to the official 22000")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When configuring TLC DCM flag:
1. check the peer's RX DCM capabilities (since we TX)
2. do not set DCM_NSS_2 since we do not support it
Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
Fixes: 423584dd ("iwlwifi: rs-fw: support dcm")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Some devices with PCI ID 0x2723, which is supposed to be 22260, are
actually not.  So we need to differentiate them by checking the hw_rev
and change the cfg accordingly.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add new structs and PCI IDs for 22260 devices.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Mac80211 will check both the HE Capability IE and the
Extended Capability IE, so set the TWT support bit when
mac80211 tells us to.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We want to advertise support for TWT in the Extended
Capability IE. Since we don't want to set the bits for all
the interface types, define an interface specific
configuration.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add to the dump the number of lmacs, the error id of the umac
and the error id of lmac1, if supported.
In case the reason for the dump trigger is not an assert
the error id is zero.
Signed-off-by: NShahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Don't populate the array prop on the stack but instead make it static.
Makes the object code smaller by 30 bytes:

Before:
   text	   data	    bss	    dec	    hex	filename
  80138	  15382	    576	  96096	  17760	drivers/net/wireless/intel/iwlwifi/pcie/trans.o

After:
   text	   data	    bss	    dec	    hex	filename
  79948	  15542	    576	  96066	  17742	drivers/net/wireless/intel/iwlwifi/pcie/trans.o

(gcc version 8.2.0 x86_64)
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The linux-firmware brcmfmac firmware files contain an embedded table with
per country allowed channels and strength info.

For recent hardware these versions of the firmware are specially build for
linux-firmware, the firmware files directly available from Cypress rely on
a separate clm_blob file for this info.

For some unknown reason Cypress refuses to provide the standard firmware
files + clm_blob files it uses elsewhere for inclusion into linux-firmware,
instead relying on these special builds with the clm_blob info embedded.
This means that the linux-firmware firmware versions often lag behind,
but I digress.

The brcmfmac driver does support the separate clm_blob file and always
tries to load this. Currently we use request_firmware for this. This means
that on any standard install, using the standard combo of linux-kernel +
linux-firmware, we will get a warning:
"Direct firmware load for ... failed with error -2"

On top of this, brcmfmac itself prints: "no clm_blob available (err=-2),
device may have limited channels available".

This commit switches to firmware_request_nowarn, fixing almost any brcmfmac
device logging the warning (it leaves the brcmfmac info message in place).
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

There is a system warning message, warn_slowpath-fmt, during suspend
while using supplicant join AP and enable wowl feature by IW command.
It's caused by brcmf_pno_remove_request path can't find the reqid.
This fix will not go to remove pno request function if there is no
pno scan.
Acked-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NLo-Hsiang Lo <double.lo@cypress.com>
Signed-off-by: NChi-Hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>