The NO_160 flag specifies if the device doesn't have 160 MHz support,
but we errorneously assumed the opposite.  If the flag was set, we
were considering that 160 MHz was supported, but it's actually the
opposite.  Fix it by inverting the bits, i.e. NO_160 is 0x1 and 160
is 0x0.

Fixes: d6f2134a ("iwlwifi: add mac/rf types and 160MHz to the device tables")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201202143859.375bec857ccb.I83884286b688965293e9810381808039bd7eedae@changeid

The 0x0024 subsytem device ID was missing from the list, so some AX210
devices were not recognized.  Add it.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201202143859.308eab4db42c.I3763196cd3f7bb36f3dcabf02ec4e7c4fe859c0f@changeid

During CSA, we briefly nullify the phy context, in __iwl_mvm_unassign_vif_chanctx.
In case we have a FW assert right after it, it remains NULL though.
We end up running into endless loop due to mac80211 trying repeatedly to
move us to ASSOC state, and we keep returning -EINVAL. Later down the road
we hit a kernel panic.

Detect and avoid this endless loop.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.d64de2c17bff.Iedd0d2afa20a2aacba5259a5cae31cb3a119a4eb@changeid

On some platforms, the preset values aren't correct and then we may
get a completion timeout in the firmware. Change the LTR configuration
to avoid that. The firmware will do some more complex reinit of this
later, but for the boot process we use ~250usec.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.d83d591c05ba.I42885c9fb500bc08b9a4c07c4ff3d436cc7a3c84@changeid

We use mvm->queue_sync_state to wait for synchronous queue sync
messages, but if an async one happens inbetween we shouldn't
clear mvm->queue_sync_state after sending the async one, that
can run concurrently (at least from the CPU POV) with another
synchronous queue sync.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Fixes: 3c514bf8 ("iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.51a3148f2c14.I0772171dbaec87433a11513e9586d98b5d920b5f@changeid

We need to feed the configuration id to remove  session protection
properly.
Remember the conf_id when we add the session protection so that we
can give it back when we want to remove the session protection.
While at it, slightly improve the kernel doc for the conf_id
of the notification.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Fixes: fe959c7b ("iwlwifi: mvm: use the new session protection command")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.3642f730333d.I01a98ecde62096d00d171cf34ad775bf80cb0277@changeid

The ROC that runs on the AUX ROC (meaning an ROC on the STA vif),
was added with the HOT_SPOT_CMD firmware command and must be
cancelled with that same command.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Fixes: fe959c7b ("iwlwifi: mvm: use the new session protection command")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.a317376154da.I44fa3637373ba4bd421cdff2cabc761bffc0735f@changeid

Currently, our max tpt is limited to max HT A-MPDU for LB,
and max VHT A-MPDU for HB. Configure HE exponent value correctly to
achieve HE max A-MPDU, both on LB and HB.
Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.4486852ebb56.I9eb0d028e31f183597fb90120e7d4ca87e0dd6cb@changeid

When we read device memory, we lock a spinlock, write the address we
want to read from the device and then spin in a loop reading the data
in 32-bit quantities from another register.

As the description makes clear, this is rather inefficient, incurring
a PCIe bus transaction for every read. In a typical device today, we
want to read 786k SMEM if it crashes, leading to 192k register reads.
Occasionally, we've seen the whole loop take over 20 seconds and then
triggering the soft lockup detector.

Clearly, it is unreasonable to spin here for such extended periods of
time.

To fix this, break the loop down into an outer and an inner loop, and
break out of the inner loop if more than half a second elapsed. To
avoid too much overhead, check for that only every 128 reads, though
there's no particular reason for that number. Then, unlock and relock
to obtain NIC access again, reprogram the start address and continue.

This will keep (interrupt) latencies on the CPU down to a reasonable
time.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201022165103.45878a7e49aa.I3b9b9c5a10002915072312ce75b68ed5b3dc6e14@changeid

The clang build reports this warning

fw.c:1485:21: warning: address of array 'rtwdev->chip->fw_fifo_addr'
  will always evaluate to 'true'
        if (!rtwdev->chip->fw_fifo_addr) {

fw_fifo_addr is an array in rtw_chip_info so it is always
nonzero.  A better check is if the first element of the array is
nonzero.  In the cases where fw_fifo_addr is initialized by rtw88b
and rtw88c, the first array element is 0x780.

Fixes: 0fbc2f0f ("rtw88: add dump firmware fifo support")
Signed-off-by: NTom Rix <trix@redhat.com>
Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
Acked-by: NTzu-En Huang <tehuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201011155438.15892-1-trix@redhat.com

Simplify the code by using new function dev_fetch_sw_netstats().
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Acked-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/166259f2-084c-45d7-e610-2de2a0bdae06@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

This reverts commit 0a8159cb.

It turns out that this flag is used by iwldvm, so we can't get rid of
it.  This broke iwldvm devices with BAD_COMMAND errors.

Fixes: 0a8159cb ("iwlwifi: remove wide_cmd_header field")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201009122123.3e4ee0ad7a71.Id6d95ae601f048aeb4d2ed63a1712e469da84369@changeid

Start supporting API version 59 for AX devices.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.0359498107fe.I559b5140be6abbee5eb759ec6e5ca046f7178f8f@changeid

The driver looks for a PNVM file that contains FW configuration data
for each different HW combination.  The FW requests the data for a
certain SKU_ID and the driver tries to find it in the PNVM file.

Read the file, parse its contents and send it to the trans.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.826bc607e57a.I1d93dd6e6651586878db57fac3e7c3f09d742c42@changeid

Implement the set_pnvm op to store the PNVM settings to the context
info and the corresponding code to free the DRAM block when the
context is freed.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.85847cfb0972.I202d90e99779f722df14b2d4102d3e466343a6f6@changeid

Add an op to allow setting the PNVM data in the trans.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.77300b00d3ce.I89d7e45e71f19fd36d89f363a28b4759b59b8765@changeid

The PNVM code is generic and can be used by other opmodes.  Move it to
a common file and include it in the relevant opmodes.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.232aa310693b.I03a18ffa4162753af38e759d88e27509007c7bca@changeid

The new API adds 4 bytes at end of the struct.  We just need to make
sure that we don't break compatibility with old FWs.
Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.bb31ce80fc55.I8a272d1da1334b1805761c0731e5d0c76ca2ef29@changeid

When adding support for version 3 of the GEO_TX_POWER_LIMIT command,
the table argument of iwl_sar_geo_init was changed from a pointer a 1d
array of now-removed iwl_per_chain_offset_group_v1 to a pointer to a 2d
array of iwl_per_chain_offset (iwl_per_chain_offset_group_v1 was a
struct containing 2 copies of iwl_per_chain_offset).

So even for version 2 where the second dimension is of length 2, which
means that the underlying memory layout of the array didn't change, this
requires a small change in the way we loop over it, and this was missed.

Additionally, for the case of version 3 where the second dimension is now
3, in order to fill the first two elements of each row correctly (lb and
hb), iwl_sar_geo_init must get the true number of bands supported.
But because we don't yet store any values for the 3rd (uhb) band, skip
that band.
Signed-off-by: NNaftali Goldstein <naftali.goldstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.73605b6e0548.Id0ec98333277ff9e017e3938ae413b34acc68947@changeid

The new API uses TLV format for statistics to enable fast changes
and debug on the fly.
Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.a45fd1a34a39.I7709305a6dc7b88d0c5119b12c9251fa6c740262@changeid

mvm mutex isn't held by iwl_mvm_set_aes_rx_seq or it caller.
iee80211_local->key_mtx is held, but that is internal to mac80211.

The same applies to iwl_mvm_wowlan_program_keys.

Just hold rcu_read_lock, even though we are protected, the penalty
isn't that bad.

Warnings fixed are:

[ 4143.788196] WARNING: suspicious RCU usage
[ 4143.788211] -----------------------------
[ 4143.788220] suspicious rcu_dereference_protected() usage!
[ 4143.788227]
[ 4143.788234] rcu_scheduler_active = 2, debug_locks = 1
[ 4143.788242] 5 locks held by kworker/u8:9/5921:
[ 4143.788331]  #4: ffff88804e69ad08 (&local->key_mtx){+.+.}, at ie80211_iter_keys+0x46/0x380 [mac80211]
[ 4143.788441]
[ 4143.788441] Call Trace:
[ 4143.788455]  dump_stack+0xc1/0x11a
[ 4143.788471]  lockdep_rcu_suspicious+0x14a/0x153
[ 4143.788515]  iwl_mvm_set_aes_rx_seq+0x4a9/0x570 [iwlmvm]
[ 4143.788657]  iwl_mvm_d3_update_keys+0x2ac/0x600 [iwlmvm]
[ 4143.788784]  ieee80211_iter_keys+0x10e/0x380 [mac80211]
[ 4143.788838]  iwl_mvm_setup_connection_keep+0x287/0x8d0 [iwlmvm]

[ 7243.206556] WARNING: suspicious RCU usage
[ 7243.206811] -----------------------------
[ 7243.206926] /suspicious rcu_dereference_protected() usage!
[ 7243.207086]
[ 7243.207204] rcu_scheduler_active = 2, debug_locks = 1
[ 7243.207321] 2 locks held by cat/15952:
[ 7243.207564]  #1: ffff888008c8ad08 (&local->key_mtx){+.+.}, at:
ieee80211_iter_keys+0x46/0x380 [mac80211]
[ 7243.207751]
[ 7243.208094] Call Trace:
[ 7243.208211]  dump_stack+0xc1/0x11a
[ 7243.208355]  lockdep_rcu_suspicious+0x14a/0x153
[ 7243.208509]  iwl_mvm_wowlan_program_keys+0x1db7/0x2340 [iwlmvm]
[ 7243.209852]  ieee80211_iter_keys+0x10e/0x380 [mac80211]
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.65872d5f1670.I0b2fb2a65904ae686c3c7c05f881a1e3634dc900@changeid

iwl_mvm_wowlan_program_keys is now setting data directly in
the KEK_KCK command, and the memset is clearing this later,
causing the data to be incomplete.

Just remove the memory clearing, the structure is local and
cleared in the declaration.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.0f355b4578c5.Ifbb76a2814925f215a2c889c1792d46d5bd66ab8@changeid

We introduced a new flow to remove an on-going CSA but we
assumed the firwmare understands the
CHANNEL_SWITCH_TIME_EVENT_CMD. This is not true for 7265 and down.

Don't send this command for those devices, but rather use the older
command.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.2574e3e47927.Ic0c56411da1096e9a45ee5c3383edf777c5baca0@changeid

We were using 5 s for some qu devices, but their xtal stabilizes
much faster than that.  Reduce the value to 500 ms.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.d0e2253c282f.Icd2ff00adff52f6c96fb261c34fbf129ce67a00d@changeid

We were using a very high latency for all 9560 devices so they all
would have time to stabilize.  But this causes the system to be
slighly slower, so we can use the best values for each device.

This requires a new trans cfg struct for devices with longer latency
and some adjustments to the other structs.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.34392f98fdb1.I3d3db14f6d1a8ecc547ca6afce8488816bd26081@changeid

The 0x271B and 0x271C devices are part of the 9000 series (discrete),
and not 9560 (integrated).  Fix it accordingly.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008180656.5cc1809940d2.If0d1e0b91fa99486403d276cf7c0fe7680a7ca2a@changeid

When adding a PASN station, the station is added to the list only
if a TK is configured. Otherwise the station pointer should not be
used.
Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008180656.b8a493c168a7.Ie9a0f9dfd9e9c58c603dd06e45151119467a7804@changeid

ADD_STA_CMD_API_S ver 12 was added in order to properly support
auxiliary activities in CDB NICs. In the new version we don't need
to allocate an aux station at initialization, instead we add an
aux station only when an auxiliary activity that requires a dedicated Tx
queue is needed. For now the only case we need this kind of activity is
when using hot spot 2.0
Signed-off-by: NNathan Errera <nathan.errera@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008180656.700e6e2e3077.Icdd807b6a3ad3fed806449ea0a13f856aa20e632@changeid

As some functions need to check which lmac id to use, add
a new function to find the lmac id instead of open coding it
in every function.
Signed-off-by: NNathan Errera <nathan.errera@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008180656.ac3b43e97aa8.I308f8ed2238e32d5eef9c35ad7962f0e8b9c1902@changeid

As part of changes made to properly support auxiliary activities in CDB
NICs, an aux sta will be added when using hot spot 2.0 and will need
to be removed when roc flow is done.
In order to do so, prepare the roc_done_wk to work synchronously as the
rm_aux_sta is a SYNC command.

Since now all of th iwl_mvm_flush_sta function are using it sync,
removed the flag argument from the function.
Signed-off-by: NNathan Errera <nathan.errera@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008180656.71b441c8b682.Ia1d216cb680308b91d6da9f73e23ae9f4baac79f@changeid

The FW relies on the re-enablement of the TX in order to know
it can exit quiet mode. Currently in case of CSA with quiet mode,
the quiet mode is never cancelled, resulting in a complete traffic
hang.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008180656.fee389c83ded.I09550fdadb61f899242d7e7b7578672372e2b7fe@changeid

If we have only a single RX queue, such as when MSI-X is not
available, we should not send the RFH_QUEUEU_CONFIG_CMD, because our
only queue is the same as the command queue and will be configured as
part of the context info.  Our code was actually trying to send the
command with 0 queues, which caused UMAC assert 0x1D04.

Fix that by not sending the command when we have a single queue.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008180656.c35eeb3299f8.I08f79a6ebe150a7d180b7005b24504bfdba6d8b5@changeid

Add PCI subsystem ID 0x6074 for Qu family.
Signed-off-by: NGolan Ben Ami <golan.ben.ami@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008180656.fba1c29fc217.I7d47c8de078d48cfc1c98ce1086e71d8d2ebb980@changeid

We've removed the code that handles it appropriately, so stop
claiming we support it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008180656.3b8936035273.I7799caa225295de44558e9da093b720afe606359@changeid

When we receive a non-zero SKU_ID in the alive notification, we need
to ring the doorbell and wait for the FW to send us a PNVM load
complete notification before we continue the init phase.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008180656.a10e8b6bbcf9.Ib5d10b3d508a4d2d4e6b7b629af89d76f4f03d81@changeid

The ROR structure was replaced by the PNVM structure.  They are
functionally identical, only the names have changed.  For now we keep
them set to 0, which means that the PNVM was not found and should not
be loaded.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008180656.065c5abcb913.Ifebf7fe47025d720ed58dda0b7ba389b473fe590@changeid

In v5 of the ALIVE notification, we may receive the SKU ID of the
device in use.  Read and store it locally for future access.  This
will be needed to find the correct PNVM (platform NVM) to pass to the
firmware.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008180656.798744ad514e.Ibb0d88586a34acc904bf319974d791faafb7a905@changeid

FW is changing the max number of supported stations. To adapt to the
change we get the max number from the TLV and act according to the new
number.
Signed-off-by: NNathan Errera <nathan.errera@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008180656.863ab470babc.I393223392f36436663c4e66add03fefe77b74e60@changeid

The legacy_httxpowerdiff in rtl8192se is pretty much the same as
the legacy_ht_txpowerdiff for other chips. Use the same name to
keep the consistency.
Signed-off-by: NChris Chiu <chiu@endlessos.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201006035928.5566-1-chiu@endlessm.com

clang static analysis reports this problem:

sdio.c:2403:3: warning: Attempt to free released memory
        kfree(card->mpa_rx.buf);
        ^~~~~~~~~~~~~~~~~~~~~~~

When mwifiex_init_sdio() fails in its first call to
mwifiex_alloc_sdio_mpa_buffer, it falls back to calling it
again.  If the second alloc of mpa_tx.buf fails, the error
handler will try to free the old, previously freed mpa_rx.buf.
Reviewing the code, it looks like a second double free would
happen with mwifiex_cleanup_sdio().

So set both pointers to NULL when they are freed.

Fixes: 5e6e3a92 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Signed-off-by: NTom Rix <trix@redhat.com>
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201004131931.29782-1-trix@redhat.com