This module parameter should not be mangled by users.
This relates to a very old driver and I doubt people can
really check the antenna coupling in a way that would make
the BT Coexistence work better with a real value.
Drop it.
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.20200424182644.6e566897ce0a.I8395a50c1c39522e542366064bff33a33009ce7b@changeid

Also we can only have one fid1 or fid2 set so no need to check
if the fid2 is set in case fid1 wasn't set.
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.20200424182644.34e74106bad3.Ic3a9f0a35fed47b02ebcd27c2dc2b50cb1e56bdf@changeid

The new version adds the information for RX2C FIFO addresses.

Use the new addresses to parse the FIFO info when dumping.
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.20200424182643.97cc25d96b53.I65fd0400d80f505bd6d7eed442f12db24b25bbe3@changeid

In AX210 devices, the PHY data wasn't actually reported, but now
that it's going to be reported it turns out that the position is
supposed to be the other way around, fix that.
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.20200424182643.06de959301f5.I544c353a8a811f107bd66d168e37920237ecf071@changeid

This function is dead for more than 10 years. Remove it.
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix the following coccicheck warning:

drivers/net/wireless/realtek/rtlwifi/rtl8188ee/rf.c:476:6-14: WARNING:
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/rf.c:54:5-22: WARNING:
Comparison to bool
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200504113321.41118-1-yanaijie@huawei.com

Fix the following coccicheck warning:

drivers/net/wireless/broadcom/b43/pio.c:768:10-25: WARNING: Comparison
of 0/1 to bool variable
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200504113311.41026-1-yanaijie@huawei.com

Fix the following coccicheck warning:

drivers/net/wireless/broadcom/b43/phy_n.c:5510:19-32: WARNING:
Comparison of 0/1 to bool variable
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200504113300.40895-1-yanaijie@huawei.com

Currently there is a check if priv is null when calling lbtf_remove_card
but not in a previous call to if_usb_reset_dev that can also dereference
priv.  Fix this by also only calling lbtf_remove_card if priv is null.

It is noteable that there don't seem to be any bugs reported that the
null pointer dereference has ever occurred, so I'm not sure if the null
check is required, but since we're doing a null check anyway it should
be done for both function calls.

Addresses-Coverity: ("Dereference before null check")
Fixes: baa0280f ("libertas_tf: don't defer firmware loading until start()")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200501173900.296658-1-colin.king@canonical.com

gcc-10 reports a warning for mwifiex_cmd_802_11_key_material_v1:

drivers/net/wireless/marvell/mwifiex/sta_cmd.c: In function 'mwifiex_cmd_802_11_key_material_v1':
cc1: warning: writing 16 bytes into a region of size 0 [-Wstringop-overflow=]
In file included from drivers/net/wireless/marvell/mwifiex/sta_cmd.c:23:
drivers/net/wireless/marvell/mwifiex/fw.h:993:9: note: at offset 0 to object 'action' with size 2 declared here
  993 |  __le16 action;
      |         ^~~~~~

As the warning makes no sense, I reported it as a bug for gcc. In the
meantime using a temporary pointer for the key data makes the code easier
to read and stops the warning.

Fixes: 5e6e3a92 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94881Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200430213101.135134-4-arnd@arndb.de

The variable 'rtlpriv->rfkill.rfkill_state' is bool and can directly
assigned to bool values.

Fix the following coccicheck warning:

drivers/net/wireless/realtek/rtlwifi/core.c:1725:14-42: WARNING:
Comparison of 0/1 to bool variable
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200429140924.7750-1-yanaijie@huawei.com

Fix the following coccicheck warning:

drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:1060:6-12:
WARNING: Comparison to bool
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200504113357.41422-1-yanaijie@huawei.com

It was observed that P2P Cert. 5.1.19: DEVUT responds to Service
Discovery request failed due to DUT did not send GAS Comeback Response
after receiving request from test bed P2P peer. To fix this issue,
we need to add P2P Action Frame retry delay to enhance P2P connection
under VSDB and noisy environment, since the peer can be in other
channels under VSDB.
Signed-off-by: NJustin Li <Justin.Li@cypress.com>
Signed-off-by: NChi-hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1588572453-194663-4-git-send-email-wright.feng@cypress.com

P2P group formation fails since either peer is not able to send go-neg
confirm or dut is not able to send go-neg response. To fix this, retry
limit should be increased and dwell time check should be added.
Signed-off-by: NJoseph Chuang <joseph.chuang@cypress.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1588572453-194663-3-git-send-email-wright.feng@cypress.com

With RSDB feature, firmware is able to support two P2P-AGO or two
P2P-GC at the same time. So we add the second p2p connection type
to map to the second P2P connection bsscfg.
Signed-off-by: NWright Feng <wright.feng@cypress.com>
Signed-off-by: NChi-hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1588572453-194663-2-git-send-email-wright.feng@cypress.com

the related system resources were not released when pci_iomap() return
error in the rtw_pci_io_mapping() function. add pci_release_regions() to
fix it.

Fixes: e3037485 ("rtw88: new Realtek 802.11ac driver")
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NDejin Zheng <zhengdejin5@gmail.com>
Acked-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200504083442.3033-1-zhengdejin5@gmail.com

Interface configuration table is used to configure PCI PHY that are
normally decided by design or bootstrap pin, and driver can do additional
settings by this table.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200504105010.10780-9-yhchuang@realtek.com

DIG sets only one IG register for most chips, but 8723D need to set
additional register for CCK rate.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200504105010.10780-8-yhchuang@realtek.com

This ops is used to do statistics of false alarm periodically, and then
fine tune RX initial gain to adaptive different circumstance.

There are three steps, hold/get/reset counter, to retrieve false alarm
counters that consist of CCK and OFDM. In addition to false alarm
counters, it also collects CRC ok/error counters of CCK, OFDM and HT.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200504105010.10780-7-yhchuang@realtek.com

Some chips are not able to receive LDPC packets. Add an attribute
to rtw_chip_info to determine if the LDPC capability in [ht/vht]_cap
should be advertised or not.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200504105010.10780-6-yhchuang@realtek.com

TX status report of 8723D differs from 8822B/8822C, it uses
C2H_CCX_TX_RPT (0x03) with different format. With sequence number
and TX status, driver can know if certain packet was transmitted
successfully.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200504105010.10780-5-yhchuang@realtek.com

Set MAC/BB/RF register according to specified channel. The function
rtw_set_channel_mac() is used to set MAC registers, but 8723D only need
some of them.

For channel 14, we need to set different CCK DFIR values, so restore the
values when channel 1 to 13 is selected.

Spur calibration is needed in channel 13 and 14, and we do notch if spur
is over threshold.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200504105010.10780-4-yhchuang@realtek.com

This ops is used to parse RX descriptor to know the length of received
packet and containing PHY status. If PHY status is existing, the order is
RX descriptor, PHY status and then packet.

There are two types of PHY status, named CCK and OFDM. Their size are the
same, but formats are different.

struct ieee80211_rx_status is also filled depends on above information.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200504105010.10780-3-yhchuang@realtek.com

To improve user experience in field, we need DIG to adjust RX initial gain
depends on field situation. Since each chip has its own register address,
this commit defines 8723d specific address.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200504105010.10780-2-yhchuang@realtek.com

Fix the following coccicheck warning:

drivers/net/wireless/ray_cs.c:2797:5-14: WARNING: Comparison of 0/1 to
bool variable
drivers/net/wireless/ray_cs.c:2798:2-11: WARNING: Assignment of 0/1 to
bool variable
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200426103709.6730-1-yanaijie@huawei.com

The 'blocked' is a bool variable, and '==' expression itself is bool
too. So no need to convert it to 0/1.

This fixes the following coccicheck warning:

drivers/net/wireless/realtek/rtlwifi/base.c:508:13-41: WARNING:
Comparison of 0/1 to bool variable
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200426094115.23294-1-yanaijie@huawei.com

Axe a memory allocation failure log message. This message is useless and
incorrect (vmalloc is not used here for the memory allocation)

This has been like that since the very beginning of this driver in
commit 43f66a6c ("Add ipw2200 wireless driver.")
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200424154527.27309-1-christophe.jaillet@wanadoo.fr

It's incorrect to use usleep in atomic context.

Switch to a macro which uses udelay instead of usleep to prevent the issue.

Fixes: 6343a6d4 ("rtw88: Add delay on polling h2c command status bit")
Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200423073007.3566-1-kai.heng.feng@canonical.com

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200504201224.GA32282@embeddedor

Some devices like TP-Link TL-WN722N produces this kind of messages
frequently.

kernel: ath: phy0: Short RX data len, dropping (dlen: 4)

This warning is useful for developers to recognize that the device
(Wi-Fi dongle or USB hub etc) is noisy but not for general users. So
this patch make this warning to debug message.
Reported-By: NDenis <pro.denis@protonmail.com>
Ref: https://bugzilla.kernel.org/show_bug.cgi?id=207539
Fixes: cd486e62 ("ath9k_htc: Discard undersized packets")
Signed-off-by: NMasashi Honma <masashi.honma@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200504214443.4485-1-masashi.honma@gmail.com

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200504200838.GA31974@embeddedor

In certain scenario host receives the packets with invalid length
which causes below kernel panic. Free up those msdus to avoid
this kernel panic.

 2270.028121:   <6> task: ffffffc0008306d0 ti: ffffffc0008306d0 task.ti: ffffffc0008306d0
 2270.035247:   <2> PC is at skb_panic+0x40/0x44
 2270.042784:   <2> LR is at skb_panic+0x40/0x44
 2270.521775:   <2> [<ffffffc0004a06e0>] skb_panic+0x40/0x44
 2270.524039:   <2> [<ffffffc0004a1278>] skb_put+0x54/0x5c
 2270.529264:   <2> [<ffffffbffcc373a8>] ath11k_dp_process_rx_err+0x320/0x5b0 [ath11k]
 2270.533860:   <2> [<ffffffbffcc30b68>] ath11k_dp_service_srng+0x80/0x268 [ath11k]
 2270.541063:   <2> [<ffffffbffcc1d554>] ath11k_hal_rx_reo_ent_buf_paddr_get+0x200/0xb64 [ath11k]
 2270.547917:   <2> [<ffffffc0004b1f74>] net_rx_action+0xf8/0x274
 2270.556247:   <2> [<ffffffc000099df4>] __do_softirq+0x128/0x228
 2270.561625:   <2> [<ffffffc00009a130>] irq_exit+0x84/0xcc
 2270.567008:   <2> [<ffffffc0000cfb28>] __handle_domain_irq+0x8c/0xb0
 2270.571695:   <2> [<ffffffc000082484>] gic_handle_irq+0x6c/0xbc
Signed-off-by: NTamizh Chelvam <tamizhr@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1588611568-20791-1-git-send-email-tamizhr@codeaurora.org

This patch add supports to reset the per peer htt stats.

Usage:

echo 1 > /sys/kernel/debug/ieee80211/phyX/netdev:wlanX/stations/<peer MAC addr>/htt_peer_stats_reset

While doing so, sync the wmi services between FW and host.
Signed-off-by: NAshok Raj Nagarajan <arnagara@codeaurora.org>
Signed-off-by: NTamizh Chelvam <tamizhr@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1588610147-20231-1-git-send-email-tamizhr@codeaurora.org

This patch follows up on a bug-report by Frank Schäfer that
discovered P2P GO wasn't working with wpa_supplicant.
This patch removes part of the broken P2P GO support but
keeps the vif switchover code in place.

Cc: <stable@vger.kernel.org>
Link: <https://lkml.kernel.org/r/3a9d86b6-744f-e670-8792-9167257edef8@googlemail.com>
Reported-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NChristian Lamparter <chunkeey@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200425092811.9494-1-chunkeey@gmail.com

This patch adds support for ethernet rxtx mode to the driver. The feature
is enabled via a new module parameter. If enabled to driver will enable
the feature on a per vif basis if all other requirements were met.
Signed-off-by: NShashidhar Lakkavalli <slakkavalli@datto.com>
Signed-off-by: NJohn Crispin <john@phrozen.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200430152814.18481-1-john@phrozen.org

htt stats are not working after htt peer stats display
and also after htt peer stats reset. Trying to dump htt
stats shows "Resource temporarily unavailable".
This is because of "ar->debug.htt_stats.stats_req" member is being
consecutively used for all htt stats without being reset
during the previous usage. Hence assigning NULL to this member
after freeing the allocated memory fixes the issue.

console logs below:
# echo 9 >/sys/kernel/debug/ath11k/ipq8074/mac1/htt_stats_type
# cat /sys/kernel/debug/ath11k/ipq8074/mac1/htt_stats_type
9
# cat /sys/kernel/debug/ath11k/ipq8074/mac1/htt_stats
cat: can't open '/sys/kernel/debug/ath11k/ipq8074/mac1/htt_stats'
: Resource temporarily unavailable
Signed-off-by: NSowmiya Sree Elavalagan <ssreeela@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1588592755-10427-1-git-send-email-ssreeela@codeaurora.org

Fix the following coccicheck warning:

drivers/net/wireless/ath/ath11k/dp_rx.c:2964:1-39: WARNING: Assignment
of 0/1 to bool variable
drivers/net/wireless/ath/ath11k/dp_rx.c:2965:1-38: WARNING: Assignment
of 0/1 to bool variable
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200504113336.41249-1-yanaijie@huawei.com

Add the support to attach and map iommu
domain for targets which do not have the
support of TrustZone.

Tested HW: WCN3990
Tested FW: WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1
Signed-off-by: NRakesh Pillai <pillair@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1586971906-20985-4-git-send-email-pillair@codeaurora.org

Move the msa resources setup out of qmi init and
setup the msa resources as a part of probe before
the qmi init is done.

Tested HW: WCN3990
Tested FW: WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1
Signed-off-by: NRakesh Pillai <pillair@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1586971906-20985-3-git-send-email-pillair@codeaurora.org

The struct cfg80211_wowlan of NET_DETECT WoWLAN feature share the same
struct cfg80211_sched_scan_request together with scheduled scan request
feature, and max_sched_scan_reqs of wiphy is only used for sched scan,
and ath10k does not support scheduled scan request feature, so ath10k
does not set flag NL80211_FEATURE_SCHED_SCAN_RANDOM_MAC_ADDR, but ath10k
set max_sched_scan_reqs of wiphy to a non zero value 1, then function
nl80211_add_commands_unsplit of cfg80211 will set it support command
NL80211_CMD_START_SCHED_SCAN because max_sched_scan_reqs is a non zero
value, but actually ath10k not support it, then it leads a mismatch result
for sched scan of cfg80211, then application shill found the mismatch and
stop running case of MAC random address scan and then the case fail.

After remove max_sched_scan_reqs value, it keeps match for sched scan and
case of MAC random address scan pass.

Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029.
Tested with QCA6174 PCIe with firmware WLAN.RM.4.4.1-00110-QCARMSWP-1.

Fixes: ce834e28 ("ath10k: support NET_DETECT WoWLAN feature")
Signed-off-by: NWen Gong <wgong@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20191114050001.4658-1-wgong@codeaurora.org