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

Use module_pci_driver for drivers whose init and exit functions
only register and unregister, respectively.
Signed-off-by: NAmey Narkhede <ameynarkhede03@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201221075735.197255-1-ameynarkhede03@gmail.com

When the usb device being plugged out, before ieee80211 gets to know the
hw being removed, it gets to know that the association status changed,
and thus ask for the device to do the calibration. This causes error as
the hw is absent.

This can be avoid by checking the status of the device before sending
the calibration request to the device.
Signed-off-by: NZhi Han <z.han@gmx.net>
Acked-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201217161657.GB12562@E480

When the usb device being plugged out, before the usb_driver:disconnect
called by e.g workqueue, it is possible that some URBs are still in
processing, and being marked as EPROTO in host controller.

Those URBs should not be scheduled in complete_rx callback function to
get further processing.
Signed-off-by: NZhi Han <z.han@gmx.net>
Acked-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201217161302.GA12562@E480

This adds support for the BCM43666/4 which seems to be using the same
firmware as BCM4366 (4366c0). I found it in the Netgear R8000P router.
Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
Acked-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201214101553.32097-1-zajec5@gmail.com

There is a spelling mistake in the Kconfig help text. Fix it.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201216115808.12987-1-colin.king@canonical.com

As the Marvell PCIE WiFi-Ex driver does not have any code or data
located in initmem, there is no need to annotate the mwifiex_pcie
structure with __refdata.  Drop the annotation, to avoid suppressing
future section warnings.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201211133835.2970384-1-geert+renesas@glider.be

Fix the following coccicheck warning:
 ./drivers/net/wireless/realtek/rtw88/debug.c:800:17-23: WARNING:
Comparison of 0/1 to bool variable
Reported-by: NAbaci Robot <abaci@linux.alibaba.com>
Signed-off-by: NYANG LI <abaci-bugfix@linux.alibaba.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1610445040-23599-1-git-send-email-abaci-bugfix@linux.alibaba.com

To protect both of WL/BT performance while BT is under re-link state.
4-slot mode TDMA can make the re-link more sensitive and mitigate the WL
throughput drop.
Signed-off-by: NChing-Te Ku <ku920601@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/20210112021135.3823-1-pkshih@realtek.com

Hal function must follow the value that calculates from dynamic mechanism.
Force to set new_lvl to 4 damages receiving ability. System will not able
to reconnect to the AP if wifi unexpected disconnecting at this moment.
Signed-off-by: NVincent Fann <vincent_fann@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/20201228082516.16488-1-pkshih@realtek.com

Sometimes driver does not get tx report from firmware because wifi
environment is too noisy to get ack from AP about a TX frame,
or firmware is too busy to report driver in a estimated time.
But the condition will not affect wifi function or throughput.
So we reduce the log level to rtw_debug instead of scary backtrace.
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/20201228082433.16431-1-pkshih@realtek.com

The parameter of kfree function is NULL, so kfree code is useless, delete it.
Signed-off-by: NZheng Yongjun <zhengyongjun3@huawei.com>
Acked-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201216130442.13869-1-zhengyongjun3@huawei.com

Without crc32, the driver fails to link:

arm-linux-gnueabi-ld: drivers/net/wireless/ath/wil6210/fw.o: in function `wil_fw_verify':
fw.c:(.text+0x74c): undefined reference to `crc32_le'
arm-linux-gnueabi-ld: drivers/net/wireless/ath/wil6210/fw.o:fw.c:(.text+0x758): more undefined references to `crc32_le' follow

Fixes: 151a9706 ("wil6210: firmware download")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix a build error when CONFIG_MAC80211_MESH is not enabled:

../drivers/net/wireless/mediatek/mt76/mt7915/init.c:47:2: error: expected expression before '}' token
  }, {
  ^

Fixes: af901eb4 ("mt76: mt7915: get rid of dbdc debugfs knob")
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Cc: Shayne Chen <shayne.chen@mediatek.com>
Cc: Ryder Lee <ryder.lee@mediatek.com>
Cc: Lorenzo Bianconi <lorenzo@kernel.org>
Cc: Felix Fietkau <nbd@nbd.name>
Cc: linux-wireless@vger.kernel.org
Cc: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201218173202.23159-1-rdunlap@infradead.org

Fix a possible NULL pointer dereference in mt76s_process_tx_queue that
can occur if status thread runs before allocating tx queues

Fixes: 6a618acb ("mt76: sdio: convert {status/net}_work to mt76_worker")
Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/b49c1b4edacd87b2241a9fd0431dd4864c8963f6.1607418933.git.lorenzo@kernel.org

Similar to mmio/usb code path, remove wake logic in mt76s_process_tx_queue
routine. Starting from commit 90d494c9 ("mt76: improve tx queue
stop/wake"), the wake queue logic on the sdio status path is no longer
necessary since the hw queues are no longer stopped on the mt76 tx path.
Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/d2d7d9d437f4dec2ef1df0ed070b9cf299f021ad.1607164041.git.lorenzo@kernel.org

Similar to mmio code path, remove wake logic in mt76u_status_worker handler.
Starting from commit 90d494c9 ("mt76: improve tx queue stop/wake")', the
wake queue logic on the usb status path is no longer necessary since the hw
queues are no longer stopped on the mt76 tx path.
Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/00009bf0cfdc9565e4432cad3ed51888c667c25d.1607164041.git.lorenzo@kernel.org

The "&ar->ab->base_lock" and "&ab->base_lock" locks are the same lock
but it's nicer to use the same name consistently everywhere.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/X9s7QAHDM2OTIo3a@mwanda

0x10 is a leftover and unnecessary, GCC_GCC_PCIE_HOT_RST_VAL is already defined
to 0x10.

No functional changes, compile tested only.
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1608143051-5386-1-git-send-email-kvalo@codeaurora.org

Sometimes QCA6390 doesn't switch to amss state as device enters
L1ss state, so disable L0sL1s during firmware downloading.
Driver recovers the ASPM to default value in start callback
or powerdown callback.

Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: NCarl Huang <cjhuang@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1608218530-15426-1-git-send-email-kvalo@codeaurora.org

Not all firmware versions support allocating DMA memory in smaller blocks so
first try to allocate big block of DMA memory for QMI. If the allocation fails,
let firmware request multiple blocks of DMA memory with smaller size.

This also fixes an unnecessary error message seen during ath11k probe on
QCA6390:

ath11k_pci 0000:06:00.0: Respond mem req failed, result: 1, err: 0
ath11k_pci 0000:06:00.0: qmi failed to respond fw mem req:-22

Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: NCarl Huang <cjhuang@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1608127593-15192-1-git-send-email-kvalo@codeaurora.org