Add support for SnJ devices with Jf and a workaround for some cases
where the devices erroneously show as QnJ devices.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210205110447.ae6ed654e557.Ic11ed4df410328359b6a2c997456692901d99468@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

We were hardcoding the SnJ and So IDs already at the trans_cfg
selection, instead of doing it in a more generic way.  Use the generic
trans_cfg selection for these devices and move the hardcoded IDs to
the new table.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210205110447.7e11dcb7b04e.I6f65126175d54b73834c2896013d00ce114ff601@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

The "supp" variable doesn't need to be unsigned long, only
"tmp" is used with for_each_set_bit(). "supp" should just
be a u16, since that's how it's sent to the firmware.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210205110447.762e50704a39.I014bc7898f90c734f8e9be2a3efaf9bf8b7db6db@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

In struct iwl_tx_cmd, there's no risk (as Arnd implied) that we
might access this as an array, as it's really not an array and
cannot be - there's only a single 802.11 header per frame. The
only reason for this member is for being able to access it a
bit more nicely.

On the other hand, this structure is used as a sub-struct in a
few places, and then some compilers (e.g. clang with certain
options) complain as you shouldn't have structs with variable-
length fields embedded in other structs.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210205110447.46cd538c90bf.I92179567d96938598806b560be59d787c2a8cc16@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Start supporting API version 60 for AX devices.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210205110447.7b908f5dd970.Id2aec0d7d33921aba77ba9853196f81d5950c31c@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

If the firmware has support, then advertise it to the stack and
send the key down. Since we re-check the protection in the host
anyway, we don't really need to do anything on RX except that we
should drop frames that the firmware _knows_ are replay errors,
since beacon filtering might otherwise result in replays being
possible.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210205110447.f5a3d53301b3.I23e84c9bb0b039d9106a07e9d6847776757f9029@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

On devices starting from 9000 series, always allow maximum A-MSDU
sizes regardless of the amsdu_size module parameter, which really
hasn't meant that for a long time but just controls the receive
buffer size.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117164916.ebf6efb380a9.I237be6ec70bee6ec52a2f379ee1f15b1196488d0@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

When we check the length, we only check that the advertised
data length fits into the data we have, but currently not
that it actually matches correctly.

This should be harmless, but if the first two bytes are zero,
then the iwl_rx_packet_payload_len() ends up negative, and
that might later cause issues if unsigned variables are used,
as this is not something that's normally expected.

Change the validation here to precisely validate the lengths
match, to avoid such issues.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117164916.5184dfc2a445.I0631d2e4f6ffb93cf06618edb035c45bd6d1d7b9@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

There's no need to double this code, just put it into the common
code that's called in all the cases.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117164916.1f75d426ebe4.I58f6612f7e168c655bdef206a53e5bc117c84cf5@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Handling host commands in a sync way is not directly related to PCIe
transport, and can serve as common logic for any transport, so move
it to trans layer.
Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117164916.fde99af4e0f7.I4cab95919eb35cc5bfb26d32dcf5e15419d0e0ef@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

In roaming flows and during reassociation, its possible that data frames
such as EAPOLs for 4 way handshake/ 802.1x authentication are initially set
to higher MCS rate. Though these are pruned down to a lower legacy rate
before sending to the FW, driver also emits a kernel warning - intended for
non-data frames. Add checks to avoid such warnings for data frames, while
also enhancing the debug data printed.
Signed-off-by: NKrishnanand Prabhu <krishnanand.prabhu@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117164916.d9ded010c4ce.Ie1d5a33d7175c0bcb35c10b5729748646671da31@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add debugfs file to print the PHY integration version.
File name is: phy_integration_ver
Signed-off-by: NDror Moshe <drorx.moshe@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117164916.f5127d919656.Ib714f444390b39cbbf7eb143c5440cc890385981@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Parse phy integration string from FW TLV.
Signed-off-by: NDror Moshe <drorx.moshe@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117164916.0c790e930484.I23ef2cb9c871e6adc4aab6be378f3811cb531155@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

While disconnecting from the AP due to bad channel switch
params (e.g. too long Tx block), do not send the firmware
'CSA abort' before disconnecting. That causes canceling the
immediate quiet and can cause transmitting data before the
disconnection happens.
Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117164916.b9af359a675f.I996fc7eb3d94e9539f8b117017c428448c42c7ad@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

D3_CONFIG_CMD and D0I3_END_CMD should be the last\first
command upon suspend\resume correspondingly, otherwise,
FW will raise an assert (0x342).

There are firmware notifications that cause the driver to
send a command back to the firmware. If such a notification
is sent to the driver while the the driver prepares the
firmware for D3, operation, what is likely to happen is that
the handling of the notification will try to get the mutex
and will wait unil the driver finished configuring the
firmware for D3. Then the handling notification will get
the mutex and handle the notification which will lead to
the aforementioned ASSERT 342.

To avoid this, we need to prevent any command to be sent to
the firmware between the D3_CONFIG_CMD and the D0I3_END_CMD.
Check this in the utility layer that sends the host commands
and in the transport layer as well.
Flag the D3_CONFIG_CMD and the D0I3_END_CMD commands as
commands that must be sent even if the firmware has already
been configured for D3 operation.
Signed-off-by: NHaim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117164916.1935a993b471.I3192c93c030576ca16773c01b009c4d93610d6ea@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

When we want to stop TX'ing because we are suspending, we
have two options: either we check system_pm_mode or we
check the mvm's status that has a bit for the suspend
flow.
The latter is better because test_bit is atomic. Also
add a call to synchronize_net after we set the bit to
make sure that all the new Tx see the bit before we
actually complete the suspend flow.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117130510.243c88781302.I5c0379c5a7e5d49410569e7fcd2fff7a419c6dea@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Those were needed for a slave bus that is not longer supported.
Remove code that is mainly useless stubs.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117130510.8f8a735f39dd.If5716eaae0df5e6295a2af927bf3ab0ee074f0a0@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

We skip index 0 that holds CSS section which isn't relevant for paged
memory.
Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117130510.ad2df68fccbc.I381f931c6e7606c21935ec6667619b209224e408@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

The code is not directly related to PCIe transport, and it will help
moving sync/async commands logic out of PCIe in the next patches.
Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117130510.271f59887fd1.I8ff41236f4e11a25df83d76c982a2a30ba2b9903@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Instead of pretending to have NAPI and then relying entirely on
interrupts anyway, properly implement NAPI and schedule the poll
when we get an interrupt, re-enabling the interrupt only after
the poll completed.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117130510.a5951ac4fc06.I9c84a147288fcfb1b019572c6758f2d92949f5d7@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

In the new api all the flush in the FW is done before we
get the response and in the response we only get the updated
read pointer and all queued packets don't get anymore rx_tx
per packet to free the queued packet, so driver needs to free
all queued packets on flushed queue at once after flush response.
Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117130510.4bd0eca8c0ef.I1601aad2eb2cc83f6f73b8ca52be57bb9fd626ab@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

If there are frequent CCA delays due to the extension channel
as detected by the firmware, and we're on 2.4 GHz, then handle
this by disconnecting (with a reconnect hint).

When we disconnect, we'll also update our capabilities to use
only 20 MHz on the next connection (if it's on 2.4 GHz) as to
avoid the use of the extension channel that has too much noise.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117130510.4de9c363b0b5.I709b7e6f73a7537c53f22d7418927691259de8a8@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

When restarting firmware with an ongoing scheduled scan, we
don't (and shouldn't) mark it as aborted as mac80211 will be
restarting it, and so no event should go out to userspace.
The appropriate comment regarding this wasn't moved to this
place, so add it.

However, we _do_ need to clean up our internal state, since
mac80211 will restart the scan, and we'll otherwise get to
the WARN_ON() a few lines below for no reason whatsoever.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117130510.4ddc9b017268.Ie869b628ae56a5d776eba0e7b7f05f42fc566f2e@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

For testing features where the firmware may send some
notifications it can often be a lot easier to do that
from a test script. Remove most injection limitations
from debugfs to be able to do this.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117130510.9aff3c6b4607.I03b0ae7df094734451445ffcb7f9f0274969f1c0@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Some notifications aren't handled by the general RX handler
code, due to multi-queue. Add size checks for them explicitly.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117130510.1370c776cb31.Ic536bd1aee5368969fbf65db85b9b9b5dc9c6034@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

We shouldn't trust the firmware with the sizes (or contents)
of notifications, accessing too much data could cause page
faults if the data doesn't fit into the allocated space. This
applies more on older NICs where multiple notifications can
be in a single RX buffer.

Add a general framework for checking a minimum size of any
notification in the RX handlers and use it for most. Some RX
handlers were already checking and I've moved the checks,
some more complex checks I left and made them _NO_SIZE for
the RX handlers.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117130510.3e155d5e5f90.I2121fa4ac7cd7eb98970d84b793796646afa3eed@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

We have already WARN_ON(!qc) for non-QOS frame on txq->sched_retry path,
but we continue to process, what makes no sense since tid is not
initialized. Non QOS frame should never happen when aggregation
is enabled on queue, so do not process that.

Patch should fix smatch warning:
drivers/net/wireless/intel/iwlegacy/4965-mac.c:2822 il4965_hdl_tx() error: uninitialized symbol 'tid'.
Reported-by: Nkernel test robot <lkp@intel.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NStanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210119100621.439134-1-stf_xl@wp.pl

Similar to commit 0e40dbd5 ("mt7601u: process URBs in status EPROTO
properly"), do not process tx URBs if marked with status set to EPROTO.
Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
Acked-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/72392e8341aa8591c0b9962661a6ca26b1198f32.1610919534.git.lorenzo@kernel.org

We can currently get a "command execute failure 19" error on beacon loss
if the signal is weak:

wlcore: Beacon loss detected. roles:0xff
wlcore: Connection loss work (role_id: 0).
...
wlcore: ERROR command execute failure 19
...
WARNING: CPU: 0 PID: 1552 at drivers/net/wireless/ti/wlcore/main.c:803
...
(wl12xx_queue_recovery_work.part.0 [wlcore])
(wl12xx_cmd_role_start_sta [wlcore])
(wl1271_op_bss_info_changed [wlcore])
(ieee80211_prep_connection [mac80211])

Error 19 is defined as CMD_STATUS_WRONG_NESTING from the wlcore firmware,
and seems to mean that the firmware no longer wants to see the quirk
handling for WLCORE_QUIRK_START_STA_FAILS done.

This quirk got added with commit 18eab430 ("wlcore: workaround
start_sta problem in wl12xx fw"), and it seems that this already got fixed
in the firmware long time ago back in 2012 as wl18xx never had this quirk
in place to start with.

As we no longer even support firmware that early, to me it seems that it's
safe to just drop WLCORE_QUIRK_START_STA_FAILS to fix the error. Looks
like earlier firmware got disabled back in 2013 with commit 0e284c07
("wl12xx: increase minimum singlerole firmware version required").

If it turns out we still need WLCORE_QUIRK_START_STA_FAILS with any
firmware that the driver works with, we can simply revert this patch and
add extra checks for firmware version used.

With this fix wlcore reconnects properly after a beacon loss.

Cc: Raz Bouganim <r-bouganim@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210115065613.7731-1-tony@atomide.com

Similar to mt76 driver, rely on ieee80211_rx_list in order to
improve icache footprint
Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
Acked-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/5c72fa2dda45c1ae3f285af80c02f3db23341d85.1610580222.git.lorenzo@kernel.org

The LTR mechanism enables PCIE Endpoints to report the service latency
requirements and CPU will enter appropriate sleep state to save power
based on the LTR value.

8723de provides two registers to config the LTR, and the original setting
is too short for CPU to ente sleep state. The patch adjust the LTR setting.
Signed-off-by: NChin-Yen Lee <timlee@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210113014342.3615-1-pkshih@realtek.com

There are certain conditional expressions in rtl8821ae, where a boolean
variable is compared with true/false, in forms such as (foo == true) or
(false != bar), which does not comply with checkpatch.pl (CHECK:
BOOL_COMPARISON), according to which boolean variables should be
themselves used in the condition, rather than comparing with true/false

E.g., in drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c,
"if (rtlefuse->autoload_failflag == false)" can be replaced with
"if (!rtlefuse->autoload_failflag)"

Replace all such expressions with the bool variables appropriately
Signed-off-by: NAditya Srivastava <yashsri421@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210110121525.2407-6-yashsri421@gmail.com

There are certain conditional expressions in rtl8192se, where a boolean
variable is compared with true/false, in forms such as (foo == true) or
(false != bar), which does not comply with checkpatch.pl (CHECK:
BOOL_COMPARISON), according to which boolean variables should be
themselves used in the condition, rather than comparing with true/false

Replace all such expressions with the bool variables appropriately
Signed-off-by: NAditya Srivastava <yashsri421@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210110121525.2407-5-yashsri421@gmail.com

There are certain conditional expressions in rtl8188ee, where a boolean
variable is compared with true/false, in forms such as (foo == true) or
(false != bar), which does not comply with checkpatch.pl (CHECK:
BOOL_COMPARISON), according to which boolean variables should be
themselves used in the condition, rather than comparing with true/false

E.g., in drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c,
"if (mac->act_scanning == true)" can be replaced with
"if (mac->act_scanning)"

Replace all such expressions with the bool variables appropriately
Signed-off-by: NAditya Srivastava <yashsri421@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210110121525.2407-4-yashsri421@gmail.com

There are certain conditional expressions in rtl8192c-common, where a
boolean variable is compared with true/false, in forms such as
(foo == true) or (false != bar), which does not comply with checkpatch.pl
(CHECK: BOOL_COMPARISON), according to which boolean variables should be
themselves used in the condition, rather than comparing with true/false

E.g., in drivers/net/wireless/realtek/rtlwifi/rtl8192c/dm_common.c,
"else if (initialized == false) {" can be replaced with
"else if (!initialized) {"

Replace all such expressions with the bool variables appropriately
Signed-off-by: NAditya Srivastava <yashsri421@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210110121525.2407-3-yashsri421@gmail.com

There are certain conditional expressions in rtl_pci, where a boolean
variable is compared with true/false, in forms such as (foo == true) or
(false != bar), which does not comply with checkpatch.pl (CHECK:
BOOL_COMPARISON), according to which boolean variables should be
themselves used in the condition, rather than comparing with true/false

E.g., in drivers/net/wireless/realtek/rtlwifi/ps.c,
"if (find_p2p_ie == true)" can be replaced with "if (find_p2p_ie)"

Replace all such expressions with the bool variables appropriately
Signed-off-by: NAditya Srivastava <yashsri421@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210110121525.2407-2-yashsri421@gmail.com

We can get the following in the logs every few minutes or so:

wlcore: ERROR exceeded max RX BA sessions

Let's downgrade the message to a debug message as suggested by the TI
support folks at:

https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/p/352435/1244754

"The WL127x firmware supports max of 3 BA sessions. It cannot be increased.
 I think the problem here is the peer trying to initiate a 4th BA session
 (ADDBA request)."
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210101065955.63386-1-tony@atomide.com

Use flexible-array member introduced in C99 instead of zero-length
array. Most of zero-length array was already taken care in previous
patch [1].

[1]. https://patchwork.kernel.org/patch/11394197/Signed-off-by: NTian Tao <tiantao6@hisilicon.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1608881703-37060-1-git-send-email-tiantao6@hisilicon.com

This ensure that previous association attempts do not leave stale statuses
on subsequent attempts.

This fixes the WARN_ON(!cr->bss)) from __cfg80211_connect_result() when
connecting to an AP after a previous connection failure (e.g. where EAP fails
due to incorrect psk but association succeeded). In some scenarios, indeed,
brcmf_is_linkup() was reporting a link up event too early due to stale
BRCMF_VIF_STATUS_ASSOC_SUCCESS bit, thus reporting to cfg80211 a connection
result with a zeroed bssid (vif->profile.bssid is still empty), causing the
WARN_ON due to the call to cfg80211_get_bss() with the empty bssid.
Signed-off-by: NLuca Pesce <luca.pesce@vimar.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1608807119-21785-1-git-send-email-luca.pesce@vimar.com

A null pointer will be passed to a kfree() call after a kzalloc() call failed.
This code is useless. Thus delete the extra function call.

A goto statement is also no longer needed. Thus adjust an if branch.
Signed-off-by: NZheng Yongjun <zhengyongjun3@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201222135113.20680-1-zhengyongjun3@huawei.com