pull-request: wireless-drivers-next-2021-04-18
up queue sync implementation iwlwifi: remove remaining software checksum code iwlwifi: mvm: don't lock mutex in RCU critical section iwlwifi: warn on SKB free w/o op-mode iwlwifi: trans/pcie: defer transport initialisation iwlwifi: fw: print out trigger delay when collecting data iwlwifi: pcie: don't enable BHs with IRQs disabled Kalle Valo (2): Merge tag 'mt76-for-kvalo-2021-04-12' of https://github.com/nbd168/wireless Merge tag 'iwlwifi-next-for-kalle-2021-04-12-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Lorenzo Bianconi (34): mt76: mt7915: enable hw rx-amsdu de-aggregation mt76: mt7921: enable random mac addr during scanning mt76: mt7921: removed unused definitions in mcu.h mt76: connac: always check return value from mt76_connac_mcu_alloc_wtbl_req mt76: mt7915: always check return value from mt7915_mcu_alloc_wtbl_req mt76: mt7615: fix memory leak in mt7615_coredump_work mt76: mt7921: fix aggr length histogram mt76: mt7915: fix aggr len debugfs node mt76: mt7921: fix stats register definitions mt76: mt7615: fix mib stats counter reporting to mac80211 mt76: connac: fix kernel warning adding monitor interface mt76: check return value of mt76_txq_send_burst in mt76_txq_schedule_list mt76: mt7921: get rid of mt7921_sta_rc_update routine mt76: mt7921: check mcu returned values in mt7921_start mt76: mt7921: reduce mcu timeouts for suspend, offload and hif_ctrl msg mt76: introduce mcu_reset function pointer in mt76_mcu_ops structure mt76: mt7921: introduce mt7921_run_firmware utility routine. mt76: mt7921: introduce __mt7921_start utility routine mt76: dma: introduce mt76_dma_queue_reset routine mt76: dma: export mt76_dma_rx_cleanup routine mt76: mt7921: add wifi reset support mt76: mt7921: remove leftovers from dbdc configuration mt76: mt7921: remove duplicated macros in mcu.h mt76: mt7921: get rid of mt7921_mac_wtbl_lmac_addr mt76: connac: introduce mt76_sta_cmd_info data structure mt76: mt7921: properly configure rcpi adding a sta to the fw dt-bindings:net:wireless:ieee80211: txt to yaml conversion dt-bindings:net:wireless:mediatek,mt76: txt to yaml conversion mt76: mt7921: fix key set/delete issue mt76: mt7921: always wake the device in mt7921_remove_interface mt76: mt7921: rework mt7921_mcu_debug_msg_event routine mt76: mt7921: introduce MT_WFDMA_DUMMY_CR definition mt76: mt7921: introduce MCU_EVENT_LP_INFO event parsing mt76: mt7921: add rcu section in mt7921_mcu_tx_rate_report Luca Coelho (1): iwlwifi: bump FW API to 63 for AX devices Lv Yunlong (1): mwl8k: Fix a double Free in mwl8k_probe_hw Marek Vasut (1): rsi: Use resume_noirq for SDIO Matti Gottlieb (2): iwlwifi: pcie: Add support for Bz Family iwlwifi: pcie: Change ma product string name Miri Korenblit (3): iwlwifi: mvm: enable PPAG in China iwlwifi: mvm: support BIOS enable/disable for 11ax in Ukraine iwlwifi: mvm: add support for version 3 of LARI_CONFIG_CHANGE command. Mordechay Goodstein (7): iwlwifi: pcie: clear only FH bits handle in the interrupt iwlwifi: move iwl_configure_rxq to be used by other op_modes iwlwifi: queue: avoid memory leak in reset flow iwlwifi: mvm: remove PS from lower rates. iwlwifi: pcie: merge napi_poll_msix functions iwlwifi: pcie: add ISR debug info for msix debug iwlwifi: rs-fw: don't support stbc for HE 160 Mukesh Sisodiya (1): iwlwifi: dbg: disable ini debug in 9000 family and below Nigel Christian (1): mt76: mt7921: remove unnecessary variable Ping-Ke Shih (2): rtlwifi: 8821ae: upgrade PHY and RF parameters rtw88: Fix array overrun in rtw_get_tx_power_params() Po-Hao Huang (2): rtw88: update statistics to fw for fine-tuning performance rtw88: 8822c: add CFO tracking Ravi Darsi (1): iwlwifi: mvm: Use IWL_INFO in fw_reset_handshake() Roee Goldfiner (1): iwlwifi: mvm: umac error table mismatch Ryder Lee (32): mt76: always use WTBL_MAX_SIZE for tlv allocation mt76: use PCI_VENDOR_ID_MEDIATEK to avoid open coded mt76: mt7615: enable hw rx-amsdu de-aggregation mt76: mt7615: add rx checksum offload support mt76: mt7615: add support for rx decapsulation offload mt76: mt7615: fix TSF configuration mt76: mt7615: remove hdr->fw_ver check mt76: mt7915: fix mib stats counter reporting to mac80211 mt76: mt7915: add missing capabilities for DBDC mt76: mt7615: fix CSA notification for DBDC mt76: mt7615: stop ext_phy queue when mac reset happens mt76: mt7915: fix CSA notification for DBDC mt76: mt7915: stop ext_phy queue when mac reset happens mt76: mt7915: fix PHY mode for DBDC
Re: [PATCH] wl1251: Fix possible buffer overflow in wl1251_cmd_scan
Lee Gibson writes:
> Function wl1251_cmd_scan calls memcpy without checking the length.
> A user could control that length and trigger a buffer overflow.
> Fix by checking the length is within the maximum allowed size.
>
> Signed-off-by: Lee Gibson
Please fix the commit log, the user cannot control this length as
cfg80211 checks it before handling it to wl1251. Unless I'm missing
something.
> ---
> drivers/net/wireless/ti/wl1251/cmd.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ti/wl1251/cmd.c
> b/drivers/net/wireless/ti/wl1251/cmd.c
> index 498c8db2eb48..e4d028a53d91 100644
> --- a/drivers/net/wireless/ti/wl1251/cmd.c
> +++ b/drivers/net/wireless/ti/wl1251/cmd.c
> @@ -455,8 +455,11 @@ int wl1251_cmd_scan(struct wl1251 *wl, u8 *ssid, size_t
> ssid_len,
> }
>
> cmd->params.ssid_len = ssid_len;
If you are checking the length, you should also check ssid_len here.
> - if (ssid)
> - memcpy(cmd->params.ssid, ssid, ssid_len);
> + if (ssid) {
> + int len = min_t(int, ssid_len, IEEE80211_MAX_SSID_LEN);
> +
> + memcpy(cmd->params.ssid, ssid, len);
> + }
Please use clamp_val().
Also another (and IMHO better) way to cleanup this is to provide a
pointer to struct cfg80211_ssid, which makes it clear that the length
can be trusted and not length checking is not needed. So something like
this:
int wl1251_cmd_scan(struct wl1251 *wl, const struct cfg80211_ssid *ssid,
struct ieee80211_channel *channels[],
unsigned int n_channels, unsigned int n_probes)
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] wil6210: wmi: Remove useless code
Jiapeng Chong wrote: > Fix the following whitescan warning: > > An unsigned value can never be less than 0. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong Patch applied to wireless-drivers-next.git, thanks. 5e6087559e85 wil6210: wmi: Remove useless code -- https://patchwork.kernel.org/project/linux-wireless/patch/1617788766-91433-1-git-send-email-jiapeng.ch...@linux.alibaba.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] carl9170: remove get_tid_h
Christophe JAILLET wrote: > 'get_tid_h()' is the same as 'ieee80211_get_tid()'. > So this function can be removed to save a few lines of code. > > Signed-off-by: Christophe JAILLET > Acked-by: Christian Lamparter Patch applied to wireless-drivers-next.git, thanks. cf366b154704 carl9170: remove get_tid_h -- https://patchwork.kernel.org/project/linux-wireless/patch/68efad7a597159e22771d37fc8b4a8a613866d60.1617399010.git.christophe.jail...@wanadoo.fr/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: mwl8k: Fix a double Free in mwl8k_probe_hw
Lv Yunlong wrote:
> In mwl8k_probe_hw, hw->priv->txq is freed at the first time by
> dma_free_coherent() in the call chain:
> if(!priv->ap_fw)->mwl8k_init_txqs(hw)->mwl8k_txq_init(hw, i).
>
> Then in err_free_queues of mwl8k_probe_hw, hw->priv->txq is freed
> at the second time by mwl8k_txq_deinit(hw, i)->dma_free_coherent().
>
> My patch set txq->txd to NULL after the first free to avoid the
> double free.
>
> Fixes: a66098daacee2 ("mwl8k: Marvell TOPDOG wireless driver")
> Signed-off-by: Lv Yunlong
Patch applied to wireless-drivers-next.git, thanks.
a8e083ee8e2a mwl8k: Fix a double Free in mwl8k_probe_hw
--
https://patchwork.kernel.org/project/linux-wireless/patch/20210402182627.4256-1-lyl2...@mail.ustc.edu.cn/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [1/4] brcmfmac: Remove duplicate struct declaration
Wan Jiabing wrote: > struct brcmf_bus is declared twice. One has been declared > at 37th line. Remove the duplicate. > > Signed-off-by: Wan Jiabing 2 patches applied to wireless-drivers-next.git, thanks. d663bc3317c9 brcmfmac: Remove duplicate struct declaration 444a9af68b5c wilc1000: Remove duplicate struct declaration -- https://patchwork.kernel.org/project/linux-wireless/patch/20210331023557.2804128-2-wanjiab...@vivo.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [2/2] wl3501: fix typo of 'Networks' in comment
Eric Lin wrote: > Signed-off-by: Eric Lin > Reported-by: Gustavo A. R. Silva Patch applied to wireless-drivers-next.git, thanks. 7f50ddc5d4fe wl3501: fix typo of 'Networks' in comment -- https://patchwork.kernel.org/project/linux-wireless/patch/20210331010418.1632816-2-dslin1...@gmail.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] rsi: Use resume_noirq for SDIO
Marek Vasut wrote:
> The rsi_resume() does access the bus to enable interrupts on the RSI
> SDIO WiFi card, however when calling sdio_claim_host() in the resume
> path, it is possible the bus is already claimed and sdio_claim_host()
> spins indefinitelly. Enable the SDIO card interrupts in resume_noirq
> instead to prevent anything else from claiming the SDIO bus first.
>
> Fixes: 20db07332736 ("rsi: sdio suspend and resume support")
> Signed-off-by: Marek Vasut
> Cc: Amitkumar Karwar
> Cc: Angus Ainslie
> Cc: David S. Miller
> Cc: Jakub Kicinski
> Cc: Kalle Valo
> Cc: Karun Eagalapati
> Cc: Martin Kepplinger
> Cc: Sebastian Krzyszkowiak
> Cc: Siva Rebbagondla
> Cc: netdev@vger.kernel.org
> Cc: sta...@vger.kernel.org
Patch applied to wireless-drivers-next.git, thanks.
c434e5e48dc4 rsi: Use resume_noirq for SDIO
--
https://patchwork.kernel.org/project/linux-wireless/patch/20210327235932.175896-1-ma...@denx.de/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: libertas: struct lbs_private is declared duplicately
Wan Jiabing wrote: > struct lbs_private has been declared at 22nd line. > Remove the duplicate. > > Signed-off-by: Wan Jiabing Patch applied to wireless-drivers-next.git, thanks. d3240418a662 libertas: struct lbs_private is declared duplicately -- https://patchwork.kernel.org/project/linux-wireless/patch/20210325064154.854245-1-wanjiab...@vivo.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] brcmfmac: A typo fix
Bhaskar Chowdhury wrote: > s/revsion/revision/ > > Signed-off-by: Bhaskar Chowdhury Patch applied to wireless-drivers-next.git, thanks. 705b5cfab183 brcmfmac: A typo fix -- https://patchwork.kernel.org/project/linux-wireless/patch/20210323043657.1466296-1-unixbhas...@gmail.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v2] rsi: fix comment syntax in file headers
Aditya Srivastava wrote: > The opening comment mark '/**' is used for highlighting the beginning of > kernel-doc comments. > There are some files in drivers/net/wireless/rsi which follow this syntax > in their file headers, i.e. start with '/**' like comments, which causes > unexpected warnings from kernel-doc. > > E.g., running scripts/kernel-doc -none on drivers/net/wireless/rsi/rsi_coex.h > causes this warning: > "warning: wrong kernel-doc identifier on line: > * Copyright (c) 2018 Redpine Signals Inc." > > Similarly for other files too. > > Provide a simple fix by replacing such occurrences with general comment > format, i.e., "/*", to prevent kernel-doc from parsing it. > > Signed-off-by: Aditya Srivastava > Reviewed-by: Randy Dunlap Patch applied to wireless-drivers-next.git, thanks. 3051946056c3 rsi: fix comment syntax in file headers -- https://patchwork.kernel.org/project/linux-wireless/patch/20210315173259.8757-1-yashsri...@gmail.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] hostap: Fix memleak in prism2_config
Dinghao Liu wrote: > When prism2_hw_config() fails, we just return an error code > without any resource release, which may lead to memleak. > > Signed-off-by: Dinghao Liu Nobody reviewed this, so dropping the patch. Patch set to Changes Requested. -- https://patchwork.kernel.org/project/linux-wireless/patch/20210329085246.24586-1-dinghao@zju.edu.cn/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] brcmsmac: fix shift on 4 bit masked value
Colin King wrote:
> From: Colin Ian King
>
> The calculation of offtune_val seems incorrect, the u16 value in
> pi->tx_rx_cal_radio_saveregs[2] is being masked with 0xf0 and then
> shifted 8 places right so that always ends up as a zero result. I
> believe the intended shift was 4 bits to the right. Fix this.
>
> [Note: not tested, I don't have the H/W]
>
> Addresses-Coverity: ("Operands don't affect result")
> Fixes: 5b435de0d786 ("net: wireless: add brcm80211 drivers")
> Signed-off-by: Colin Ian King
I think this needs review from someone familiar with the hardware.
Patch set to Changes Requested.
--
https://patchwork.kernel.org/project/linux-wireless/patch/20210318164513.19600-1-colin.k...@canonical.com/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] rsi: fix error return code of rsi_load_9116_firmware()
Jia-Ju Bai wrote: > When kmemdup() returns NULL to ta_firmware, no error return code of > rsi_load_9116_firmware() is assigned. > To fix this bug, status is assigned with -ENOMEM in this case. > > Reported-by: TOTE Robot > Signed-off-by: Jia-Ju Bai Someone needs to review this. Patch set to Changes Requested. -- https://patchwork.kernel.org/project/linux-wireless/patch/20210307083445.21322-1-baijiaju1...@gmail.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] ti: wlcore: fix error return code of wl1271_cmd_build_ps_poll()
Jia-Ju Bai wrote: > When ieee80211_pspoll_get() returns NULL to skb, no error return code of > wl1271_cmd_build_ps_poll() is assigned. > To fix this bug, ret is assigned with -ENOMEM in this case. > > Reported-by: TOTE Robot > Signed-off-by: Jia-Ju Bai Someone needs to review this. Patch set to Changes Requested. -- https://patchwork.kernel.org/project/linux-wireless/patch/20210307082906.20950-1-baijiaju1...@gmail.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] ti: wlcore: fix error return code of wl1271_suspend()
Jia-Ju Bai wrote: > When wl is NULL, no error return code of wl1271_suspend() is assigned. > To fix this bug, ret is assigned with -EINVAL in this case. > > Reported-by: TOTE Robot > Signed-off-by: Jia-Ju Bai Someone needs to review this. Patch set to Changes Requested. -- https://patchwork.kernel.org/project/linux-wireless/patch/20210306143600.19676-1-baijiaju1...@gmail.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] marvell: libertas_tf: fix error return code of if_usb_prog_firmware()
Jia-Ju Bai wrote: > When check_fwfile_format() fails, no error return code of > if_usb_prog_firmware() is assigned. > To fix this bug, ret is assigned with -EINVAL as error return code. > > Reported-by: TOTE Robot > Signed-off-by: Jia-Ju Bai Someone needs to review this. Patch set to Changes Requested. -- https://patchwork.kernel.org/project/linux-wireless/patch/20210305033115.6015-1-baijiaju1...@gmail.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH net-next] airo: work around stack usage warning
Arnd Bergmann wrote: > From: Arnd Bergmann > > gcc-11 with KASAN on 32-bit arm produces a warning about a function > that needs a lot of stack space: > > drivers/net/wireless/cisco/airo.c: In function 'setup_card.constprop': > drivers/net/wireless/cisco/airo.c:3960:1: error: the frame size of 1512 bytes > is larger than 1400 bytes [-Werror=frame-larger-than=] > > Most of this is from a single large structure that could be dynamically > allocated or moved into the per-device structure. However, as the callers > all seem to have a fairly well bounded call chain, the easiest change > is to pull out the part of the function that needs the large variables > into a separate function and mark that as noinline_for_stack. This does > not reduce the total stack usage, but it gets rid of the warning and > requires minimal changes otherwise. > > Signed-off-by: Arnd Bergmann Patch applied to wireless-drivers-next.git, thanks. 7909a590eba6 airo: work around stack usage warning -- https://patchwork.kernel.org/project/linux-wireless/patch/20210323131634.2669455-1-a...@kernel.org/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH net-next] wlcore: fix overlapping snprintf arguments in debugfs
Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> gcc complains about undefined behavior in calling snprintf()
> with the same buffer as input and output:
>
> drivers/net/wireless/ti/wl18xx/debugfs.c: In function
> 'diversity_num_of_packets_per_ant_read':
> drivers/net/wireless/ti/wl18xx/../wlcore/debugfs.h:86:3: error: 'snprintf'
> argument 4 overlaps destination object 'buf' [-Werror=restrict]
>86 | snprintf(buf, sizeof(buf), "%s[%d] = %d\n", \
> | ^~
>87 | buf, i, stats->sub.name[i]); \
> | ~~~
> drivers/net/wireless/ti/wl18xx/debugfs.c:24:2: note: in expansion of macro
> 'DEBUGFS_FWSTATS_FILE_ARRAY'
>24 | DEBUGFS_FWSTATS_FILE_ARRAY(a, b, c, wl18xx_acx_statistics)
> | ^~
> drivers/net/wireless/ti/wl18xx/debugfs.c:159:1: note: in expansion of macro
> 'WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY'
> 159 | WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY(diversity, num_of_packets_per_ant,
>
> There are probably other ways of handling the debugfs file, without
> using on-stack buffers, but a simple workaround here is to remember the
> current position in the buffer and just keep printing in there.
>
> Fixes: bcca1bbdd412 ("wlcore: add debugfs macro to help print fw statistics
> arrays")
> Signed-off-by: Arnd Bergmann
Patch applied to wireless-drivers-next.git, thanks.
7b0e2c4f6be3 wlcore: fix overlapping snprintf arguments in debugfs
--
https://patchwork.kernel.org/project/linux-wireless/patch/20210323125723.1961432-1-a...@kernel.org/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH net-next 4/5] libertas: avoid -Wempty-body warning
Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Building without mesh supports shows a couple of warnings with
> 'make W=1':
>
> drivers/net/wireless/marvell/libertas/main.c: In function 'lbs_start_card':
> drivers/net/wireless/marvell/libertas/main.c:1068:37: error: suggest braces
> around empty body in an 'if' statement [-Werror=empty-body]
> 1068 | lbs_start_mesh(priv);
>
> Change the macros to use the usual "do { } while (0)" instead to shut up
> the warnings and make the code a litte more robust.
>
> Signed-off-by: Arnd Bergmann
Patch applied to wireless-drivers-next.git, thanks.
01414f8882f9 libertas: avoid -Wempty-body warning
--
https://patchwork.kernel.org/project/linux-wireless/patch/20210322104343.948660-4-a...@kernel.org/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] rtl8xxxu: Simplify locking of a skb list accesses
Christophe JAILLET wrote: > The 'c2hcmd_lock' spinlock is only used to protect some __skb_queue_tail() > and __skb_dequeue() calls. > Use the lock provided in the skb itself and call skb_queue_tail() and > skb_dequeue(). These functions already include the correct locking. > > Signed-off-by: Christophe JAILLET Patch applied to wireless-drivers-next.git, thanks. 431eb49e87ed rtl8xxxu: Simplify locking of a skb list accesses -- https://patchwork.kernel.org/project/linux-wireless/patch/8bcec6429615aeb498482dc7e1955ce09b456585.1617613700.git.christophe.jail...@wanadoo.fr/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] mwifiex: Remove unneeded variable: "ret"
zuoqil...@163.com wrote: > From: zuoqilin > > Remove unneeded variable: "ret" > > Signed-off-by: zuoqilin Patch applied to wireless-drivers-next.git, thanks. c81852a48e13 mwifiex: Remove unneeded variable: "ret" -- https://patchwork.kernel.org/project/linux-wireless/patch/20210317063353.1055-1-zuoqil...@163.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH RESEND][next] rtl8xxxu: Fix fall-through warnings for Clang
"Gustavo A. R. Silva" wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix > multiple warnings by replacing /* fall through */ comments with > the new pseudo-keyword macro fallthrough; instead of letting the > code fall through to the next case. > > Notice that Clang doesn't recognize /* fall through */ comments as > implicit fall-through markings. > > Link: https://github.com/KSPP/linux/issues/115 > Signed-off-by: Gustavo A. R. Silva Patch applied to wireless-drivers-next.git, thanks. bf3365a856a1 rtl8xxxu: Fix fall-through warnings for Clang -- https://patchwork.kernel.org/project/linux-wireless/patch/20210305094850.GA141221@embeddedor/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH net-next] rtlwifi: rtl8192de: Use DEFINE_SPINLOCK() for spinlock
Huang Guobin wrote: > From: Guobin Huang > > spinlock can be initialized automatically with DEFINE_SPINLOCK() > rather than explicitly calling spin_lock_init(). > > Reported-by: Hulk Robot > Signed-off-by: Guobin Huang Patch applied to wireless-drivers-next.git, thanks. e9642be26a37 rtlwifi: rtl8192de: Use DEFINE_SPINLOCK() for spinlock -- https://patchwork.kernel.org/project/linux-wireless/patch/1617711406-49649-1-git-send-email-huangguob...@huawei.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v2] qtnfmac: remove meaningless goto statement and labels
samirweng1979 wrote: > From: wengjianfeng > > some function's label meaningless, the label statement follows > the goto statement, no other statements, so just remove it. > > Reported-by: kernel test robot > Signed-off-by: wengjianfeng Patch applied to wireless-drivers-next.git, thanks. fb98734f7936 qtnfmac: remove meaningless goto statement and labels -- https://patchwork.kernel.org/project/linux-wireless/patch/20210406025206.4924-1-samirweng1...@163.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] rtlwifi: Simplify locking of a skb list accesses
Christophe JAILLET wrote: > The 'c2hcmd_lock' spinlock is only used to protect some __skb_queue_tail() > and __skb_dequeue() calls. > Use the lock provided in the skb itself and call skb_queue_tail() and > skb_dequeue(). These functions already include the correct locking. > > Signed-off-by: Christophe JAILLET > Acked-by: Larry Finger Patch applied to wireless-drivers-next.git, thanks. 1186006adee9 rtlwifi: Simplify locking of a skb list accesses -- https://patchwork.kernel.org/project/linux-wireless/patch/99cf8894fd52202cb7ce2ec6e3200eef400bc071.1617609346.git.christophe.jail...@wanadoo.fr/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] rtlwifi: remove rtl_get_tid_h
Christophe JAILLET wrote: > 'rtl_get_tid_h()' is the same as 'ieee80211_get_tid()'. > So this function can be removed to save a line of code. > > Signed-off-by: Christophe JAILLET Patch applied to wireless-drivers-next.git, thanks. 987e9bcdd0b7 rtlwifi: remove rtl_get_tid_h -- https://patchwork.kernel.org/project/linux-wireless/patch/db340a67a95c119e4f9ba8fa99aea1c73d0dcfc9.1617383263.git.christophe.jail...@wanadoo.fr/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] rtlwifi: rtl8188ee: remove redundant assignment of variable rtlpriv->btcoexist.reg_bt_sco
Yang Li wrote: > Assigning value "3" to "rtlpriv->btcoexist.reg_bt_sco" here, but that > stored value is overwritten before it can be used. > > Coverity reports this problem as > CWE563: A value assigned to a variable is never used. > drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c: > rtl8188ee_bt_reg_init > > Reported-by: Abaci Robot > Signed-off-by: Yang Li Patch applied to wireless-drivers-next.git, thanks. 8e04a06530c6 rtlwifi: rtl8188ee: remove redundant assignment of variable rtlpriv->btcoexist.reg_bt_sco -- https://patchwork.kernel.org/project/linux-wireless/patch/1617182023-110950-1-git-send-email-yang@linux.alibaba.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] rtlwifi: remove redundant assignment to variable err
Colin King wrote:
> From: Colin Ian King
>
> Variable err is assigned -ENODEV followed by an error return path
> via label error_out that does not access the variable and returns
> with the -ENODEV error return code. The assignment to err is
> redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
Patch applied to wireless-drivers-next.git, thanks.
87431bc1f0f6 rtlwifi: remove redundant assignment to variable err
--
https://patchwork.kernel.org/project/linux-wireless/patch/20210327230014.25554-1-colin.k...@canonical.com/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] rtlwifi: Few mundane typo fixes
Bhaskar Chowdhury wrote: > s/resovle/resolve/ > s/broadcase/broadcast/ > s/sytem/system/ > > Signed-off-by: Bhaskar Chowdhury > Acked-by: Randy Dunlap Patch applied to wireless-drivers-next.git, thanks. 2377b1c49d48 rtlwifi: Few mundane typo fixes -- https://patchwork.kernel.org/project/linux-wireless/patch/20210320194426.21621-1-unixbhas...@gmail.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] qtnfmac: remove meaningless labels
samirweng1979 wrote: > From: wengjianfeng > > some function's label meaningless, the return statement follows > the goto statement, so just remove it. > > Signed-off-by: wengjianfeng > Reviewed-by: Sergey Matyukevich Patch applied to wireless-drivers-next.git, thanks. a221d0afbf39 qtnfmac: remove meaningless labels -- https://patchwork.kernel.org/project/linux-wireless/patch/20210223065754.34392-1-samirweng1...@163.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] cw1200: Remove unused function pointer typedef wsm_*
Chen Lin wrote: > From: Chen Lin > > Remove the 'wsm_*' typedef as it is not used. > > Signed-off-by: Chen Lin Patch applied to wireless-drivers-next.git, thanks. 9dc5fdc8c4f8 cw1200: Remove unused function pointer typedef wsm_* -- https://patchwork.kernel.org/project/linux-wireless/patch/1613449833-4910-1-git-send-email-chen45464...@163.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] cw1200: Remove unused function pointer typedef cw1200_wsm_handler
Chen Lin wrote: > From: Chen Lin > > Remove the 'cw1200_wsm_handler' typedef as it is not used. > > Signed-off-by: Chen Lin Patch applied to wireless-drivers-next.git, thanks. 1c22233a745e cw1200: Remove unused function pointer typedef cw1200_wsm_handler -- https://patchwork.kernel.org/project/linux-wireless/patch/1613446918-4532-1-git-send-email-chen45464...@163.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] qtnfmac: Fix possible buffer overflow in qtnf_event_handle_external_auth
Lee Gibson wrote: > Function qtnf_event_handle_external_auth calls memcpy without > checking the length. > A user could control that length and trigger a buffer overflow. > Fix by checking the length is within the maximum allowed size. > > Signed-off-by: Lee Gibson Please use clamp_val() instead, that's preferred over min_t(). Patch set to Changes Requested. -- https://patchwork.kernel.org/project/linux-wireless/patch/20210317121706.389058-1-lee...@gmail.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] mac80211_hwsim: indicate support for 60GHz channels
Ramon Fontes writes: > Advertise 60GHz channels to mac80211. SoB missing: https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#signed-off-by_missing -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v2 0/2][next] wl3501_cs: Fix out-of-bounds warnings
"Gustavo A. R. Silva" writes: > Friendly ping: could somebody give us some feedback or take > this series, please? First patch 2 comment needs to be resolved. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
pull-request: wireless-drivers-next-2021-04-13
Hi, here's a pull request to net-next tree, more info below. Please let me know if there are any problems. Kalle The following changes since commit 2117fce81f6b862aac0673abe8df0c60dca64bfa: Merge branch 'psample-Add-additional-metadata-attributes' (2021-03-14 15:00:44 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-2021-04-13 for you to fetch changes up to fa9f5d0e0b45a06802f7cb3afed237be6066821e: iwlegacy: avoid -Wempty-body warning (2021-04-11 12:31:01 +0300) wireless-drivers-next patches for v5.13 First set of patches for v5.13. I have been offline for a couple of and I have a smaller pull request this time. The next one will be bigger. Nothing really special standing out. ath11k * add initial support for QCN9074, but not enabled yet due to firmware problems * enable radar detection for 160MHz secondary segment * handle beacon misses in station mode rtw88 * 8822c: support firmware crash dump mt7601u * enable TDLS support Ajay Singh (1): wilc1000: use wilc handler as cookie in request_threaded_irq() Anilkumar Kolli (6): ath11k: Refactor ath11k_msi_config ath11k: Move qmi service_ins_id to hw_params ath11k: qmi: increase the number of fw segments ath11k: Update memory segment count for qcn9074 ath11k: Add qcn9074 mhi controller config ath11k: add qcn9074 pci device support Arnd Bergmann (1): iwlegacy: avoid -Wempty-body warning Ching-Te Ku (1): rtw88: coex: fix A2DP stutters while WL busy + WL scan Colin Ian King (2): ath11k: debugfs: Fix spelling mistake "Opportunies" -> "Opportunities" mt7601u: fix always true expression Dan Carpenter (1): rtw88: Fix an error code in rtw_debugfs_set_rsvd_page() David Mosberger-Tang (1): wilc1000: Support chip sleep over SPI Kalle Valo (4): ath11k: print hardware name and version during initialisation ath11k: qmi: add more debug messages ath11k: qmi: cosmetic changes to error messages Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git Karthikeyan Periyasamy (5): ath11k: add static window support for register access ath11k: add hal support for QCN9074 ath11k: add data path support for QCN9074 ath11k: add CE interrupt support for QCN9074 ath11k: add extended interrupt support for QCN9074 Lavanya Suresh (3): ath11k: Fix sounding dimension config in HE cap ath11k: Enable radar detection for 160MHz secondary segment ath11k: Add support for STA to handle beacon miss Lorenzo Bianconi (1): mt7601u: enable TDLS support Marcus Folkesson (1): wilc1000: write value to WILC_INTR2_ENABLE register Miaoqing Pan (1): ath11k: fix potential wmi_mgmt_tx_queue race condition Ping-Ke Shih (1): rtw88: coex: add power off setting Po-Hao Huang (1): rtw88: 8822c: add LC calibration for RTL8822C Pradeep Kumar Chitrapu (1): ath11k: fix thermal temperature read Shuah Khan (2): ath9k: fix ath_tx_process_buffer() potential null ptr dereference Revert "ath9k: fix ath_tx_process_buffer() potential null ptr dereference" Sriram R (1): ath11k: Update signal filled flag during sta_statistics drv op Youghandhar Chintala (1): ath10k: skip the wait for completion to recovery in shutdown path Zong-Zhe Yang (4): rtw88: 8822c: support FW crash dump when FW crash rtw88: add flush hci support rtw88: fix DIG min setting rtw88: 8822c: update tx power limit table to RF v40.1 wengjianfeng (1): rtw88: remove unnecessary variable drivers/net/wireless/ath/ath10k/snoc.c | 29 +- drivers/net/wireless/ath/ath11k/ahb.c | 2 +- drivers/net/wireless/ath/ath11k/ce.c | 58 +- drivers/net/wireless/ath/ath11k/ce.h | 1 + drivers/net/wireless/ath/ath11k/core.c | 45 +- drivers/net/wireless/ath/ath11k/core.h | 6 + .../net/wireless/ath/ath11k/debugfs_htt_stats.c| 2 +- drivers/net/wireless/ath/ath11k/dp_rx.c| 476 ++-- drivers/net/wireless/ath/ath11k/dp_tx.c| 6 +- drivers/net/wireless/ath/ath11k/hal.c | 96 ++- drivers/net/wireless/ath/ath11k/hal.h | 33 +- drivers/net/wireless/ath/ath11k/hal_desc.h | 13 +- drivers/net/wireless/ath/ath11k/hal_tx.c | 3 + drivers/net/wireless/ath/ath11k/hal_tx.h | 1 + drivers/net/wireless/ath/ath11k/hif.h | 10 + drivers/net/wireless/ath/ath11k/hw.c | 796 + drivers/net/wireless/ath/ath11k/hw.h | 53 ++ drivers/net/wireless/ath/ath11k/mac.c
Re: [PATCH 1/2] dt-binding: bcm43xx-fmac: add optional brcm,ccode-map
Shawn Guo writes:
> On Sun, Apr 11, 2021 at 10:57:54AM +0300, Kalle Valo wrote:
>> Shawn Guo writes:
>>
>> > Add optional brcm,ccode-map property to support translation from ISO3166
>> > country code to brcmfmac firmware country code and revision.
>> >
>> > Signed-off-by: Shawn Guo
>> > ---
>> > .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 7 +++
>> > 1 file changed, 7 insertions(+)
>> >
>> > diff --git
>> > a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>> > b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>> > index cffb2d6876e3..a65ac4384c04 100644
>> > --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>> > +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>> > @@ -15,6 +15,12 @@ Optional properties:
>> >When not specified the device will use in-band SDIO interrupts.
>> > - interrupt-names : name of the out-of-band interrupt, which must be set
>> >to "host-wake".
>> > + - brcm,ccode-map : multiple strings for translating ISO3166 country code
>> > to
>> > + brcmfmac firmware country code and revision. Each string must be in
>> > + format "AA-BB-num" where:
>> > +AA is the ISO3166 country code which must be 2 characters.
>> > +BB is the firmware country code which must be 2 characters.
>> > +num is the revision number which must fit into signed integer.
>> >
>> > Example:
>> >
>> > @@ -34,5 +40,6 @@ mmc3: mmc@1c12000 {
>> >interrupt-parent = <&pio>;
>> >interrupts = <10 8>; /* PH10 / EINT10 */
>> >interrupt-names = "host-wake";
>> > + brcm,ccode-map = "JP-JP-78", "US-Q2-86";
>>
>> The commit log does not answer "Why?". Why this needs to be in device
>> tree and, for example, not hard coded in the driver?
>
> Thanks for the comment, Kalle. Actually, this is something I need some
> input from driver maintainers. I can see this country code mapping
> table is chipset specific, and can be hard coded in driver per chip id
> and revision. But on the other hand, it makes some sense to have this
> table in device tree, as the country code that need to be supported
> could be a device specific configuration.
Could be? Does such a use case exist at the moment or are just guessing
future needs?
>From what I have learned so far I think this kind of data should be in
the driver, but of course I might be missing something.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH net-next 3/5] iwlegacy: avoid -Wempty-body warning
Arnd Bergmann wrote: > From: Arnd Bergmann > > There are a couple of warnings in this driver when building with W=1: > > drivers/net/wireless/intel/iwlegacy/common.c: In function 'il_power_set_mode': > drivers/net/wireless/intel/iwlegacy/common.c:1195:60: error: suggest braces > around empty body in an 'if' statement [-Werror=empty-body] > 1195 | il->chain_noise_data.state); > |^ > drivers/net/wireless/intel/iwlegacy/common.c: In function 'il_do_scan_abort': > drivers/net/wireless/intel/iwlegacy/common.c:1343:57: error: suggest braces > around empty body in an 'else' statement [-Werror=empty-body] > > Change the empty debug macros to no_printk(), which avoids the > warnings and adds useful format string checks. > > Signed-off-by: Arnd Bergmann > Acked-by: Stanislaw Gruszka Patch applied to wireless-drivers-next.git, thanks. fa9f5d0e0b45 iwlegacy: avoid -Wempty-body warning -- https://patchwork.kernel.org/project/linux-wireless/patch/20210322104343.948660-3-a...@kernel.org/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] mt7601u: fix always true expression
Colin King wrote:
> From: Colin Ian King
>
> Currently the expression ~nic_conf1 is always true because nic_conf1
> is a u16 and according to 6.5.3.3 of the C standard the ~ operator
> promotes the u16 to an integer before flipping all the bits. Thus
> the top 16 bits of the integer result are all set so the expression
> is always true. If the intention was to flip all the bits of nic_conf1
> then casting the integer result back to a u16 is a suitabel fix.
>
> Interestingly static analyzers seem to thing a bitwise ! should be
> used instead of ~ for this scenario, so I think the original intent
> of the expression may need some extra consideration.
>
> Addresses-Coverity: ("Logical vs. bitwise operator")
> Fixes: c869f77d6abb ("add mt7601u driver")
> Signed-off-by: Colin Ian King
> Acked-by: Jakub Kicinski
Patch applied to wireless-drivers-next.git, thanks.
87fce88658ba mt7601u: fix always true expression
--
https://patchwork.kernel.org/project/linux-wireless/patch/20210225183241.1002129-1-colin.k...@canonical.com/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 1/2] dt-binding: bcm43xx-fmac: add optional brcm,ccode-map
Shawn Guo writes:
> Add optional brcm,ccode-map property to support translation from ISO3166
> country code to brcmfmac firmware country code and revision.
>
> Signed-off-by: Shawn Guo
> ---
> .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> index cffb2d6876e3..a65ac4384c04 100644
> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> @@ -15,6 +15,12 @@ Optional properties:
> When not specified the device will use in-band SDIO interrupts.
> - interrupt-names : name of the out-of-band interrupt, which must be set
> to "host-wake".
> + - brcm,ccode-map : multiple strings for translating ISO3166 country code to
> + brcmfmac firmware country code and revision. Each string must be in
> + format "AA-BB-num" where:
> + AA is the ISO3166 country code which must be 2 characters.
> + BB is the firmware country code which must be 2 characters.
> + num is the revision number which must fit into signed integer.
>
> Example:
>
> @@ -34,5 +40,6 @@ mmc3: mmc@1c12000 {
> interrupt-parent = <&pio>;
> interrupts = <10 8>; /* PH10 / EINT10 */
> interrupt-names = "host-wake";
> + brcm,ccode-map = "JP-JP-78", "US-Q2-86";
The commit log does not answer "Why?". Why this needs to be in device
tree and, for example, not hard coded in the driver?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
pull-request: wireless-drivers-2021-04-07
Hi, here's a pull request to net tree, more info below. Please let me know if there are any problems. Kalle The following changes since commit 05a59d79793d482f628a31753c671f2e92178a21: Merge git://git.kernel.org:/pub/scm/linux/kernel/git/netdev/net (2021-03-09 17:15:56 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-2021-04-07 for you to fetch changes up to 65db391dd874db42279713405f29f4ac93682d13: iwlwifi: mvm: fix beacon protection checks (2021-04-06 13:26:36 +0300) wireless-drivers fixes for v5.12 Third, and last, set of fixes for v5.12. Small fixes, iwlwifi having most of them. brcmfmac regression caused by cfg80211 changes is the most important here. iwlwifi * fix a lockdep warning * fix regulatory feature detection in certain firmware versions * new hardware support * fix lockdep warning * mvm: fix beacon protection checks mt76 * mt7921: fix airtime reporting brcmfmac * fix a deadlock regression Gregory Greenman (1): iwlwifi: mvm: rfi: don't lock mvm->mutex when sending config command Hans de Goede (1): brcmfmac: p2p: Fix recently introduced deadlock issue Jiri Kosina (1): iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_enqueue_hcmd() Johannes Berg (3): iwlwifi: pcie: properly set LTR workarounds on 22000 devices iwlwifi: fw: fix notification wait locking iwlwifi: mvm: fix beacon protection checks Lorenzo Bianconi (1): mt76: mt7921: fix airtime reporting Luca Coelho (2): iwlwifi: fix 11ax disabled bit in the regulatory capability flags iwlwifi: pcie: add support for So-F devices Matt Chen (1): iwlwifi: add support for Qu with AX201 device .../net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 2 +- drivers/net/wireless/intel/iwlwifi/fw/notif-wait.c | 10 +++ drivers/net/wireless/intel/iwlwifi/iwl-config.h| 1 + drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 2 +- drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 7 +++-- drivers/net/wireless/intel/iwlwifi/mvm/rfi.c | 6 ++-- drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 17 +++ .../wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c | 31 +-- .../net/wireless/intel/iwlwifi/pcie/ctxt-info.c| 3 +- drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 27 - .../net/wireless/intel/iwlwifi/pcie/trans-gen2.c | 35 ++ drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 7 +++-- drivers/net/wireless/mediatek/mt76/mt7921/regs.h | 4 +-- 13 files changed, 97 insertions(+), 55 deletions(-)
Re: [PATCH v5 08/24] wfx: add bus_sdio.c
Ulf Hansson writes:
>> If I follow what has been done in other drivers I would write something
>> like:
>>
>> static int wfx_sdio_suspend(struct device *dev)
>> {
>> struct sdio_func *func = dev_to_sdio_func(dev);
>> struct wfx_sdio_priv *bus = sdio_get_drvdata(func);
>>
>> config_reg_write_bits(bus->core, CFG_IRQ_ENABLE_DATA, 0);
>> // Necessary to keep device firmware in RAM
>> return sdio_set_host_pm_flags(func, MMC_PM_KEEP_POWER);
>
> This will tell the mmc/sdio core to keep the SDIO card powered on
> during system suspend. Thus, it doesn't need to re-initialize it at
> system resume - and the firmware should not need to be re-programmed.
>
> On the other hand, if you don't plan to support system wakeups, it
> would probably be better to power off the card, to avoid wasting
> energy while the system is suspended. I assume that means you need to
> re-program the firmware as well. Normally, it's these kinds of things
> that need to be managed from a ->resume() callback.
Many mac80211 drivers do so that the device is powered off during
interface down (ifconfig wlan0 down), and as mac80211 does interface
down automatically during suspend, suspend then works without extra
handlers.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] hostap: Fix memleak in prism2_config
Dinghao Liu writes: > When prism2_hw_config() fails, we just return an error code > without any resource release, which may lead to memleak. > > Signed-off-by: Dinghao Liu > --- > drivers/net/wireless/intersil/hostap/hostap_cs.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/wireless/intersil/hostap/hostap_cs.c > b/drivers/net/wireless/intersil/hostap/hostap_cs.c > index ec7db2badc40..7dc16ab50ad6 100644 > --- a/drivers/net/wireless/intersil/hostap/hostap_cs.c > +++ b/drivers/net/wireless/intersil/hostap/hostap_cs.c > @@ -536,10 +536,10 @@ static int prism2_config(struct pcmcia_device *link) > sandisk_enable_wireless(dev); > > ret = prism2_hw_config(dev, 1); > - if (!ret) > - ret = hostap_hw_ready(dev); > + if (ret) > + goto failed; > > - return ret; > + return hostap_hw_ready(dev);; Two semicolons. But I'm not sure about this, can someone provide a Reviewed-by tag? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] drivers: net: wireless: struct lbs_private is declared duplicately
Wan Jiabing writes: > struct lbs_private has been declared at 22nd line. > Remove the duplicate. > > Signed-off-by: Wan Jiabing > --- > drivers/net/wireless/marvell/libertas/decl.h | 1 - > 1 file changed, 1 deletion(-) The prefix should be "libertas:", I can fix that during commit. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH net-next] wlcore: fix overlapping snprintf arguments in debugfs
Arnd Bergmann writes:
> From: Arnd Bergmann
>
> gcc complains about undefined behavior in calling snprintf()
> with the same buffer as input and output:
>
> drivers/net/wireless/ti/wl18xx/debugfs.c: In function
> 'diversity_num_of_packets_per_ant_read':
> drivers/net/wireless/ti/wl18xx/../wlcore/debugfs.h:86:3: error:
> 'snprintf' argument 4 overlaps destination object 'buf'
> [-Werror=restrict]
>86 | snprintf(buf, sizeof(buf), "%s[%d] = %d\n", \
> | ^~
>87 | buf, i, stats->sub.name[i]); \
> | ~~~
> drivers/net/wireless/ti/wl18xx/debugfs.c:24:2: note: in expansion of
> macro 'DEBUGFS_FWSTATS_FILE_ARRAY'
>24 | DEBUGFS_FWSTATS_FILE_ARRAY(a, b, c, wl18xx_acx_statistics)
> | ^~
> drivers/net/wireless/ti/wl18xx/debugfs.c:159:1: note: in expansion of macro
> 'WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY'
> 159 | WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY(diversity, num_of_packets_per_ant,
>
> There are probably other ways of handling the debugfs file, without
> using on-stack buffers, but a simple workaround here is to remember the
> current position in the buffer and just keep printing in there.
>
> Fixes: bcca1bbdd412 ("wlcore: add debugfs macro to help print fw statistics
> arrays")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/net/wireless/ti/wlcore/boot.c| 13 -
> drivers/net/wireless/ti/wlcore/debugfs.h | 7 ---
This should go to wireless-drivers-next, not net-next.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] brcmsmac: fix shift on 4 bit masked value
Colin King writes:
> From: Colin Ian King
>
> The calculation of offtune_val seems incorrect, the u16 value in
> pi->tx_rx_cal_radio_saveregs[2] is being masked with 0xf0 and then
> shifted 8 places right so that always ends up as a zero result. I
> believe the intended shift was 4 bits to the right. Fix this.
>
> [Note: not tested, I don't have the H/W]
>
> Addresses-Coverity: ("Operands don't affect result")
> Fixes: 5b435de0d786 ("net: wireless: add brcm80211 drivers")
> Signed-off-by: Colin Ian King
Can someone ack this?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH net-next] mt76: mt7921: remove unneeded semicolon
Qiheng Lin writes: > Eliminate the following coccicheck warning: > drivers/net/wireless/mediatek/mt76/mt7921/mac.c:1402:2-3: Unneeded semicolon > > Signed-off-by: Qiheng Lin mt76 patches go to the mt76 tree maintained by Felix, not to net-next. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: rtlwifi/rtl8192cu AP mode broken with PS STA
"Maciej S. Szmigiero" writes: > On 29.03.2021 00:54, Maciej S. Szmigiero wrote: >> Hi, >> >> It looks like rtlwifi/rtl8192cu AP mode is broken when a STA is using PS, >> since the driver does not update its beacon to account for TIM changes, >> so a station that is sleeping will never learn that it has packets >> buffered at the AP. >> >> Looking at the code, the rtl8192cu driver implements neither the set_tim() >> callback, nor does it explicitly update beacon data periodically, so it >> has no way to learn that it had changed. >> >> This results in the AP mode being virtually unusable with STAs that do >> PS and don't allow for it to be disabled (IoT devices, mobile phones, >> etc.). >> >> I think the easiest fix here would be to implement set_tim() for example >> the way rt2x00 driver does: queue a work or schedule a tasklet to update >> the beacon data on the device. > > Are there any plans to fix this? > The driver is listed as maintained by Ping-Ke. Yeah, power save is hard and I'm not surprised that there are drivers with broken power save mode support. If there's no fix available we should stop supporting AP mode in the driver. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 00/10] rsi: fix comment syntax in file headers
Lukas Bulwahn writes: > On Sun, Mar 14, 2021 at 9:18 PM Aditya Srivastava > wrote: >> >> The opening comment mark '/**' is used for highlighting the beginning of >> kernel-doc comments. >> There are files in drivers/net/wireless/rsi which follow this syntax in >> their file headers, i.e. start with '/**' like comments, which causes >> unexpected warnings from kernel-doc. >> >> E.g., running scripts/kernel-doc -none on drivers/net/wireless/rsi/rsi_coex.h >> causes this warning: >> "warning: wrong kernel-doc identifier on line: >> * Copyright (c) 2018 Redpine Signals Inc." >> >> Similarly for other files too. >> >> Provide a simple fix by replacing the kernel-doc like comment syntax with >> general format, i.e. "/*", to prevent kernel-doc from parsing it. >> > > Aditya, thanks for starting to clean up the repository following your > investigation on kernel-doc warnings. > > The changes to all those files look sound. > > However I think these ten patches are really just _one change_, and > hence, all can be put into a single commit. I agree, this is one logical change to a single driver so one patch will suffice. I think for cleanup changes like this one patch per driver is a good approach. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: wilc1000: write value to WILC_INTR2_ENABLE register
Marcus Folkesson wrote:
> Write the value instead of reading it twice.
>
> Fixes: c5c77ba18ea6 ("staging: wilc1000: Add SDIO/SPI 802.11 driver")
> Signed-off-by: Marcus Folkesson
Patch applied to wireless-drivers-next.git, thanks.
e21b6e5a5462 wilc1000: write value to WILC_INTR2_ENABLE register
--
https://patchwork.kernel.org/project/linux-wireless/patch/20210224163706.519658-1-marcus.folkes...@gmail.com/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] rtw88: remove unnecessary variable
samirweng1979 wrote: > From: wengjianfeng > > The variable ret is defined at the beginning and initialized > to 0 until the function returns ret, and the variable ret is > not reassigned.Therefore, we do not need to define the variable > ret, just return 0 directly at the end of the function. > > Signed-off-by: wengjianfeng Patch applied to wireless-drivers-next.git, thanks. 4a7ea94377c9 rtw88: remove unnecessary variable -- https://patchwork.kernel.org/project/linux-wireless/patch/20210223075438.13676-1-samirweng1...@163.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH net-next 0/3] iwlwifi: series with smaller improvements
Heiner Kallweit writes: > Series includes smaller improvements. > > Heiner Kallweit (3): > iwlwifi: use DECLARE_BITMAP macro > iwlwifi: switch "index larger than supported by driver" warning to > debug level > iwlwifi: use dma_set_mask_and_coherent iwlwifi patches go to iwlwifi-next, not net-next. But no need to resend just because of this. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH net] wireless/nl80211: fix wdev_id may be used uninitialized
Jarod Wilson writes: > Build currently fails with -Werror=maybe-uninitialized set: > > net/wireless/nl80211.c: In function '__cfg80211_wdev_from_attrs': > net/wireless/nl80211.c:124:44: error: 'wdev_id' may be used > uninitialized in this function [-Werror=maybe-uninitialized] Really, build fails? Is -Werror enabled by default now? I hope not. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH RESEND][next] rtl8xxxu: Fix fall-through warnings for Clang
Kees Cook writes: > On Fri, Mar 05, 2021 at 03:40:33PM +0200, Kalle Valo wrote: >> "Gustavo A. R. Silva" writes: >> >> > In preparation to enable -Wimplicit-fallthrough for Clang, fix >> > multiple warnings by replacing /* fall through */ comments with >> > the new pseudo-keyword macro fallthrough; instead of letting the >> > code fall through to the next case. >> > >> > Notice that Clang doesn't recognize /* fall through */ comments as >> > implicit fall-through markings. >> > >> > Link: https://github.com/KSPP/linux/issues/115 >> > Signed-off-by: Gustavo A. R. Silva >> >> It's not cool that you ignore the comments you got in [1], then after a >> while mark the patch as "RESEND" and not even include a changelog why it >> was resent. >> >> [1] >> https://patchwork.kernel.org/project/linux-wireless/patch/d522f387b2d0dde774785c7169c1f25aa529989d.1605896060.git.gustavo...@kernel.org/ > > Hm, this conversation looks like a miscommunication, mainly? I see > Gustavo, as requested by many others[1], replacing the fallthrough > comments with the "fallthrough" statement. (This is more than just a > "Clang doesn't parse comments" issue.) v1 was clearly rejected by Jes, so sending a new version without any changelog or comments is not the way to go. The changelog shoud at least have had "v1 was rejected but I'm resending this again because " or something like that to make it clear what's happening. > This could be a tree-wide patch and not bother you, but Greg KH has > generally advised us to send these changes broken out. Anyway, this > change still needs to land, so what would be the preferred path? I think > Gustavo could just carry it for Linus to merge without bothering you if > that'd be preferred? I agree with Greg. Please don't do cleanups like this via another tree as that just creates more work due to conflicts between the trees, which is a lot more annoying to deal with than applying few patches. But when submitting patches please follow the rules, don't cut corners. Jes, I don't like 'fallthrough' either and prefer the original comment, but the ship has sailed on this one. Maybe we should just take it? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v3] ath10k: skip the wait for completion to recovery in shutdown path
Youghandhar Chintala wrote: > Currently in the shutdown callback we wait for recovery to complete > before freeing up the resources. This results in additional two seconds > delay during the shutdown and thereby increase the shutdown time. > > As an attempt to take less time during shutdown, remove the wait for > recovery completion in the shutdown callback and added an API to freeing > the reosurces in which they were common for shutdown and removing > the module. > > Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1 > > Signed-off-by: Youghandhar Chintala > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 018e3fa8e7ff ath10k: skip the wait for completion to recovery in shutdown path -- https://patchwork.kernel.org/project/linux-wireless/patch/20210223142908.23374-1-yough...@codeaurora.org/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [patch 10/14] ath9k: Use tasklet_disable_in_atomic()
Thomas Gleixner writes: > From: Sebastian Andrzej Siewior > > All callers of ath9k_beacon_ensure_primary_slot() are preemptible / > acquire a mutex except for this callchain: > > spin_lock_bh(&sc->sc_pcu_lock); > ath_complete_reset() > -> ath9k_calculate_summary_state() > -> ath9k_beacon_ensure_primary_slot() > > It's unclear how that can be distangled, so use tasklet_disable_in_atomic() > for now. This allows tasklet_disable() to become sleepable once the > remaining atomic users are cleaned up. > > Signed-off-by: Sebastian Andrzej Siewior > Signed-off-by: Thomas Gleixner > Cc: ath9k-de...@qca.qualcomm.com > Cc: Kalle Valo > Cc: "David S. Miller" > Cc: Jakub Kicinski > Cc: linux-wirel...@vger.kernel.org > Cc: netdev@vger.kernel.org > --- > drivers/net/wireless/ath/ath9k/beacon.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) I assume this goes via some other tree: Acked-by: Kalle Valo -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH RESEND][next] rtl8xxxu: Fix fall-through warnings for Clang
"Gustavo A. R. Silva" writes: > In preparation to enable -Wimplicit-fallthrough for Clang, fix > multiple warnings by replacing /* fall through */ comments with > the new pseudo-keyword macro fallthrough; instead of letting the > code fall through to the next case. > > Notice that Clang doesn't recognize /* fall through */ comments as > implicit fall-through markings. > > Link: https://github.com/KSPP/linux/issues/115 > Signed-off-by: Gustavo A. R. Silva It's not cool that you ignore the comments you got in [1], then after a while mark the patch as "RESEND" and not even include a changelog why it was resent. [1] https://patchwork.kernel.org/project/linux-wireless/patch/d522f387b2d0dde774785c7169c1f25aa529989d.1605896060.git.gustavo...@kernel.org/ -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
pull-request: wireless-drivers-2021-03-03
Hi, here's a pull request to net tree, more info below. Please let me know if there are any problems. Kalle The following changes since commit c490492f15f656340b35cb9e36b9bfdea3539e19: mt76: mt7915: fix unused 'mode' variable (2021-02-26 17:35:15 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-2021-03-03 for you to fetch changes up to 295d4cd82b0181dd36b145fd535c13d623d7a335: iwlwifi: don't call netif_napi_add() with rxq->lock held (was Re: Lockdep warning in iwl_pcie_rx_handle()) (2021-03-03 17:59:16 +0200) wireless-drivers fixes for v5.12 Second set of fixes for v5.12. Only three iwlwifi fixes this time, the crash with MVM being the most important one and reported by multiple people. iwlwifi * fix kernel crash regression when using LTO with MVM devices * fix printk format warnings * fix potential deadlock found by lockdep Jiri Kosina (1): iwlwifi: don't call netif_napi_add() with rxq->lock held (was Re: Lockdep warning in iwl_pcie_rx_handle()) Pierre-Louis Bossart (1): iwlwifi: fix ARCH=i386 compilation warnings Wei Yongjun (1): iwlwifi: mvm: add terminate entry for dmi_system_id tables drivers/net/wireless/intel/iwlwifi/fw/pnvm.c | 4 ++-- drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 1 + drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 3 ++- 3 files changed, 5 insertions(+), 3 deletions(-)
Re: [PATCH] iwlwifi: ensure that DMI scan table is properly terminated
Jens Axboe writes: > On 3/2/21 8:49 PM, Jens Axboe wrote: >> On 3/2/21 11:34 AM, Coelho, Luciano wrote: >> >>> Thanks for the report and patch! And I'm sorry that we broke your >>> laptop's boot... >>> >>> We already have a patch to fix this: >>> >>> https://patchwork.kernel.org/project/linux-wireless/patch/20210223140039.1708534-1-weiyongj...@huawei.com/ >>> >>> I thought I had already acked it for Kalle to take it directly to >>> wireless-drivers, but apparently I hadn't. >>> >>> I acked now and assigned it to him. >> >> All good thanks, as long as it gets fixed and goes upstream I don't care >> where it's from :-) > > I looked at the link, and feel free to steal my commit trace/message it > you want. Thanks, did that. The patch is now applied: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git/commit/?id=a22549f12767fce49c74c53a853595f82b727935 I'll send a pull request to the net tree later today. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] iwlwifi: fix ARCH=i386 compilation warnings
Pierre-Louis Bossart wrote:
> An unsigned long variable should rely on '%lu' format strings, not '%zd'
>
> Fixes: a1a6a4cf49ece ("iwlwifi: pnvm: implement reading PNVM from UEFI")
> Signed-off-by: Pierre-Louis Bossart
> Acked-by: Luca Coelho
Patch applied to wireless-drivers.git, thanks.
436b265671d6 iwlwifi: fix ARCH=i386 compilation warnings
--
https://patchwork.kernel.org/project/linux-wireless/patch/20210302011640.1276636-1-pierre-louis.boss...@linux.intel.com/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: iwlwifi: mvm: add terminate entry for dmi_system_id tables
Wei Yongjun wrote:
> Make sure dmi_system_id tables are NULL terminated. This crashed when LTO was
> enabled:
>
> BUG: KASAN: global-out-of-bounds in dmi_check_system+0x5a/0x70
> Read of size 1 at addr c16af750 by task NetworkManager/1913
>
> CPU: 4 PID: 1913 Comm: NetworkManager Not tainted 5.12.0-rc1+ #10057
> Hardware name: LENOVO 20THCTO1WW/20THCTO1WW, BIOS N2VET27W (1.12 ) 12/21/2020
> Call Trace:
> dump_stack+0x90/0xbe
> print_address_description.constprop.0+0x1d/0x140
> ? dmi_check_system+0x5a/0x70
> ? dmi_check_system+0x5a/0x70
> kasan_report.cold+0x7b/0xd4
> ? dmi_check_system+0x5a/0x70
> __asan_load1+0x4d/0x50
> dmi_check_system+0x5a/0x70
> iwl_mvm_up+0x1360/0x1690 [iwlmvm]
> ? iwl_mvm_send_recovery_cmd+0x270/0x270 [iwlmvm]
> ? setup_object.isra.0+0x27/0xd0
> ? kasan_poison+0x20/0x50
> ? ___slab_alloc.constprop.0+0x483/0x5b0
> ? mempool_kmalloc+0x17/0x20
> ? ftrace_graph_ret_addr+0x2a/0xb0
> ? kasan_poison+0x3c/0x50
> ? cfg80211_iftype_allowed+0x2e/0x90 [cfg80211]
> ? __kasan_check_write+0x14/0x20
> ? mutex_lock+0x86/0xe0
> ? __mutex_lock_slowpath+0x20/0x20
> __iwl_mvm_mac_start+0x49/0x290 [iwlmvm]
> iwl_mvm_mac_start+0x37/0x50 [iwlmvm]
> drv_start+0x73/0x1b0 [mac80211]
> ieee80211_do_open+0x53e/0xf10 [mac80211]
> ? ieee80211_check_concurrent_iface+0x266/0x2e0 [mac80211]
> ieee80211_open+0xb9/0x100 [mac80211]
> __dev_open+0x1b8/0x280
>
> Fixes: a2ac0f48a07c ("iwlwifi: mvm: implement approved list for the PPAG
> feature")
> Reported-by: Hulk Robot
> Signed-off-by: Wei Yongjun
> Reviewed-by: Nathan Chancellor
> Tested-by: Victor Michel
> Acked-by: Luca Coelho
> [kv...@codeaurora.org: improve commit log]
Patch applied to wireless-drivers.git, thanks.
a22549f12767 iwlwifi: mvm: add terminate entry for dmi_system_id tables
--
https://patchwork.kernel.org/project/linux-wireless/patch/20210223140039.1708534-1-weiyongj...@huawei.com/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] iwlwifi: mvm: add terminate entry for dmi_system_id tables
Jakub Kicinski writes: > On Tue, 2 Mar 2021 18:31:11 + Coelho, Luciano wrote: >> On Sat, 2021-02-27 at 08:39 +0200, Kalle Valo wrote: >> > Nathan Chancellor writes: >> > > We received a report about a crash in iwlwifi when compiled with LTO and >> > > this fix resolves it. >> > >> > That information should be added to the commit log. >> > >> > Luca, should I take this to wireless-drivers? >> >> I just saw Jens' patch now and I don't remember if I acked this one? >> >> In any, I assigned it to you in patchwork, so please take it directly >> to w-d. >> >> Acked-by: Luca Coelho > > Thanks, I'm getting pinged, too. It sounded like Kalle would like to > see the commit log improved I wrote my comment hastily, I was trying to say that I can add the crash information to the commit log. > if Wei doesn't respond could you please step in to make sure this > fix is part of Dave's next PR to Linus? Will do. Related to this, what's your pull request schedule to Linus nowadays? Do you submit it every Thursday? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] iwlwifi: fix ARCH=i386 compilation warnings
"Coelho, Luciano" writes:
> On Tue, 2021-03-02 at 07:58 +0200, Kalle Valo wrote:
>> Pierre-Louis Bossart writes:
>>
>> > An unsigned long variable should rely on '%lu' format strings, not '%zd'
>> >
>> > Fixes: a1a6a4cf49ece ("iwlwifi: pnvm: implement reading PNVM from UEFI")
>> > Signed-off-by: Pierre-Louis Bossart
>> > ---
>> > warnings found with v5.12-rc1 and next-20210301
>>
>> Luca, can I take this to wireless-drivers?
>
> Yes, please.
>
> Acked-by: Luca Coelho
Thansk. I don't see this in patchwork yet (I guess vger is slow again)
so I cannot assign it to me at the moment, will do it later.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] iwlwifi: fix ARCH=i386 compilation warnings
Pierre-Louis Bossart writes:
> An unsigned long variable should rely on '%lu' format strings, not '%zd'
>
> Fixes: a1a6a4cf49ece ("iwlwifi: pnvm: implement reading PNVM from UEFI")
> Signed-off-by: Pierre-Louis Bossart
> ---
> warnings found with v5.12-rc1 and next-20210301
Luca, can I take this to wireless-drivers?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v3 0/3] Add lockdep_assert_not_held()
Peter Zijlstra writes: > On Mon, Mar 01, 2021 at 10:45:32AM +0200, Kalle Valo wrote: >> Peter Zijlstra writes: >> >> > On Fri, Feb 26, 2021 at 05:06:57PM -0700, Shuah Khan wrote: >> >> Shuah Khan (3): >> >> lockdep: add lockdep_assert_not_held() >> >> lockdep: add lockdep lock state defines >> >> ath10k: detect conf_mutex held ath10k_drain_tx() calls >> > >> > Thanks! >> >> Via which tree should these go? > > I've just queued the lot for locking/core, which will show up in tip > when the robots don't hate on it. > > Does that work for you? That's perfect, thanks! Just making sure that the patches don't get lost. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v3 0/3] Add lockdep_assert_not_held()
Peter Zijlstra writes: > On Fri, Feb 26, 2021 at 05:06:57PM -0700, Shuah Khan wrote: >> Shuah Khan (3): >> lockdep: add lockdep_assert_not_held() >> lockdep: add lockdep lock state defines >> ath10k: detect conf_mutex held ath10k_drain_tx() calls > > Thanks! Via which tree should these go? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] iwlwifi: mvm: add terminate entry for dmi_system_id tables
Nathan Chancellor writes:
> On Tue, Feb 23, 2021 at 02:00:39PM +, Wei Yongjun wrote:
>> Make sure dmi_system_id tables are NULL terminated.
>>
>> Fixes: a2ac0f48a07c ("iwlwifi: mvm: implement approved list for the PPAG
>> feature")
>> Reported-by: Hulk Robot
>> Signed-off-by: Wei Yongjun
>
> We received a report about a crash in iwlwifi when compiled with LTO and
> this fix resolves it.
That information should be added to the commit log.
Luca, should I take this to wireless-drivers?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
pull-request: wireless-drivers-2021-02-26
Hi, here's a pull request to net tree, more info below. Please let me know if there are any problems. Kalle The following changes since commit 773dc50d71690202afd7b5017c060c6ca8c75dd9: Merge branch 'Xilinx-axienet-updates' (2021-02-12 17:38:53 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-2021-02-26 for you to fetch changes up to c490492f15f656340b35cb9e36b9bfdea3539e19: mt76: mt7915: fix unused 'mode' variable (2021-02-26 17:35:15 +0200) wireless-drivers fixes for v5.12 First set of fixes for v5.12. One iwlwifi kernel crash fix and smaller fixes to multiple drivers. ath9k * fix Spatial Multiplexing Power Save (SMPS) handling to improve thoughtput mt76 * error handling fixes * memory leax fixes iwlwifi * don't crash during debug collection on DVM devices MAINTAINERS * email address update ath11k * fix GCC warning about DMA address debug messages * fix regression which broke QCA6390 AP mode Arnd Bergmann (2): mt76: mt7921: remove incorrect error handling mt76: mt7915: fix unused 'mode' variable Felix Fietkau (3): ath9k: fix transmitting to stations in dynamic SMPS mode mt76: fix tx skb error handling in mt76_dma_tx_queue_skb mt76: mt7915: only modify tx buffer list after allocating tx token id Geert Uytterhoeven (1): ath11k: qmi: use %pad to format dma_addr_t Johannes Berg (1): iwlwifi: avoid crash on unsupported debug collection Kalle Valo (2): ath11k: fix AP mode for QCA6390 iwlwifi: pcie: fix iwl_so_trans_cfg link error when CONFIG_IWLMVM is disabled Lorenzo Bianconi (1): mt76: dma: do not report truncated frames to mac80211 Sharvari Harisangam (1): MAINTAINERS: update for mwifiex driver maintainers MAINTAINERS| 3 ++- drivers/net/wireless/ath/ath11k/mac.c | 4 ++-- drivers/net/wireless/ath/ath11k/qmi.c | 4 ++-- drivers/net/wireless/ath/ath9k/ath9k.h | 3 ++- drivers/net/wireless/ath/ath9k/xmit.c | 6 + drivers/net/wireless/intel/iwlwifi/iwl-op-mode.h | 2 ++ drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 3 ++- drivers/net/wireless/mediatek/mt76/dma.c | 26 +++--- drivers/net/wireless/mediatek/mt76/mt7915/mac.c| 10 - .../net/wireless/mediatek/mt76/mt7915/testmode.c | 4 ++-- drivers/net/wireless/mediatek/mt76/mt7921/mcu.c| 4 +--- 11 files changed, 39 insertions(+), 30 deletions(-)
Re: [PATCH 3/3] PCI: Convert rtw88 power cycle quirk to shutdown quirk
Heiner Kallweit writes: > On 26.02.2021 13:18, Kai-Heng Feng wrote: >> On Fri, Feb 26, 2021 at 8:10 PM Heiner Kallweit wrote: >>> >>> On 26.02.2021 08:12, Kalle Valo wrote: >>>> Kai-Heng Feng writes: >>>> >>>>> Now we have a generic D3 shutdown quirk, so convert the original >>>>> approach to a PCI quirk. >>>>> >>>>> Signed-off-by: Kai-Heng Feng >>>>> --- >>>>> drivers/net/wireless/realtek/rtw88/pci.c | 2 -- >>>>> drivers/pci/quirks.c | 6 ++ >>>>> 2 files changed, 6 insertions(+), 2 deletions(-) >>>> >>>> It would have been nice to CC linux-wireless also on patches 1-2. I only >>>> saw patch 3 and had to search the rest of patches from lkml. >>>> >>>> I assume this goes via the PCI tree so: >>>> >>>> Acked-by: Kalle Valo >>>> >>> >>> To me it looks odd to (mis-)use the quirk mechanism to set a device >>> to D3cold on shutdown. As I see it the quirk mechanism is used to work >>> around certain device misbehavior. And setting a device to a D3 >>> state on shutdown is a normal activity, and the shutdown() callback >>> seems to be a good place for it. >>> I miss an explanation what the actual benefit of the change is. >> >> To make putting device to D3 more generic, as there are more than one >> device need the quirk. >> >> Here's the discussion: >> https://lore.kernel.org/linux-usb/00de6927-3fa6-a9a3-2d65-2b4d4e8f0...@linux.intel.com/ >> > > Thanks for the link. For the AMD USB use case I don't have a strong opinion, > what's considered the better option may be a question of personal taste. > For rtw88 however I'd still consider it over-engineering to replace a simple > call to pci_set_power_state() with a PCI quirk. > I may be biased here because I find it sometimes bothering if I want to > look up how a device is handled and in addition to checking the respective > driver I also have to grep through quirks.c whether there's any special > handling. Good point about rtw88. And if there's a new PCI id for rtw88 we need to also update the quirk in the PCI subsystem, which will be most likely forgotten. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 1/2] mt76: mt7915: fix unused 'mode' variable
Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> clang points out a possible corner case in the mt7915_tm_set_tx_cont()
> function if called with invalid arguments:
>
> drivers/net/wireless/mediatek/mt76/mt7915/testmode.c:593:2: warning: variable
> 'mode' is used uninitialized whenever switch default is taken
> [-Wsometimes-uninitialized]
> default:
> ^~~
> drivers/net/wireless/mediatek/mt76/mt7915/testmode.c:597:13: note:
> uninitialized use occurs here
> rateval = mode << 6 | rate_idx;
>^~~~
> drivers/net/wireless/mediatek/mt76/mt7915/testmode.c:506:37: note: initialize
> the variable 'mode' to silence this warning
> u8 rate_idx = td->tx_rate_idx, mode;
>^
>
> Change it to return an error instead of continuing with invalid data
> here.
>
> Fixes: 3f0caa3cbf94 ("mt76: mt7915: add support for continuous tx in
> testmode")
> Signed-off-by: Arnd Bergmann
Please remove the break and send v2.
Patch set to Changes Requested.
--
https://patchwork.kernel.org/project/linux-wireless/patch/20210225145953.404859-1-a...@kernel.org/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 2/2] mt76: mt7921: remove incorrect error handling
Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Clang points out a mistake in the error handling in
> mt7921_mcu_tx_rate_report(), which tries to dereference a pointer that
> cannot be initialized because of the error that is being handled:
>
> drivers/net/wireless/mediatek/mt76/mt7921/mcu.c:409:3: warning: variable
> 'stats' is uninitialized when used here [-Wuninitialized]
> stats->tx_rate = rate;
> ^
> drivers/net/wireless/mediatek/mt76/mt7921/mcu.c:401:32: note: initialize the
> variable 'stats' to silence this warning
> struct mt7921_sta_stats *stats;
> ^
> Just remove the obviously incorrect line.
>
> Fixes: 1c099ab44727 ("mt76: mt7921: add MCU support")
> Signed-off-by: Arnd Bergmann
> Reviewed-by: Nick Desaulniers
Patch applied to wireless-drivers.git, thanks.
fb5fabb192b2 mt76: mt7921: remove incorrect error handling
--
https://patchwork.kernel.org/project/linux-wireless/patch/20210225145953.404859-2-a...@kernel.org/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 3/3] PCI: Convert rtw88 power cycle quirk to shutdown quirk
Kai-Heng Feng writes: > Now we have a generic D3 shutdown quirk, so convert the original > approach to a PCI quirk. > > Signed-off-by: Kai-Heng Feng > --- > drivers/net/wireless/realtek/rtw88/pci.c | 2 -- > drivers/pci/quirks.c | 6 ++ > 2 files changed, 6 insertions(+), 2 deletions(-) It would have been nice to CC linux-wireless also on patches 1-2. I only saw patch 3 and had to search the rest of patches from lkml. I assume this goes via the PCI tree so: Acked-by: Kalle Valo -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] iwlwifi: fix link error without CONFIG_IWLMVM
Arnd Bergmann writes:
> From: Arnd Bergmann
>
> A runtime check that was introduced recently failed to
> check for the matching Kconfig symbol:
>
> ld.lld: error: undefined symbol: iwl_so_trans_cfg
referenced by drv.c
net/wireless/intel/iwlwifi/pcie/drv.o:(iwl_pci_probe)
>
> Fixes: 930be4e76f26 ("iwlwifi: add support for SnJ with Jf devices")
> Signed-off-by: Arnd Bergmann
A sent a similar patch this morning:
https://patchwork.kernel.org/project/linux-wireless/patch/1614236661-20274-1-git-send-email-kv...@codeaurora.org/
But I forgot to include an Fixes tag, I'll add that to my patch during commit.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 1/2] mt76: mt7915: fix unused 'mode' variable
Arnd Bergmann writes:
> From: Arnd Bergmann
>
> clang points out a possible corner case in the mt7915_tm_set_tx_cont()
> function if called with invalid arguments:
>
> drivers/net/wireless/mediatek/mt76/mt7915/testmode.c:593:2: warning: variable
> 'mode' is used uninitialized whenever switch default is taken
> [-Wsometimes-uninitialized]
> default:
> ^~~
> drivers/net/wireless/mediatek/mt76/mt7915/testmode.c:597:13: note:
> uninitialized use occurs here
> rateval = mode << 6 | rate_idx;
>^~~~
> drivers/net/wireless/mediatek/mt76/mt7915/testmode.c:506:37: note: initialize
> the variable 'mode' to silence this warning
> u8 rate_idx = td->tx_rate_idx, mode;
>^
>
> Change it to return an error instead of continuing with invalid data
> here.
>
> Fixes: 3f0caa3cbf94 ("mt76: mt7915: add support for continuous tx in
> testmode")
> Signed-off-by: Arnd Bergmann
Felix, can I take these two to wireless-drivers? An ack would be good.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] qtnfmac: remove meaningless goto statement and labels
kernel test robot writes: > Hi samirweng1979, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on wireless-drivers-next/master] > [also build test ERROR on wireless-drivers/master sparc-next/master v5.11 > next-20210225] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch] > > url: > https://github.com/0day-ci/linux/commits/samirweng1979/qtnfmac-remove-meaningless-goto-statement-and-labels/20210225-145714 > base: > https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git > master > config: x86_64-randconfig-a001-20210225 (attached as .config) > compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project > a921aaf789912d981cbb2036bdc91ad7289e1523) > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # install x86_64 cross compiling tool for clang build > # apt-get install binutils-x86-64-linux-gnu > # > https://github.com/0day-ci/linux/commit/d18bea1fd25dee219ae56343ff9caf9cb6eb1519 > git remote add linux-review https://github.com/0day-ci/linux > git fetch --no-tags linux-review > samirweng1979/qtnfmac-remove-meaningless-goto-statement-and-labels/20210225-145714 > git checkout d18bea1fd25dee219ae56343ff9caf9cb6eb1519 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross > ARCH=x86_64 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>): > >>> drivers/net/wireless/quantenna/qtnfmac/commands.c:1901:8: error: use of >>> undeclared label 'out' >goto out; Do you compile test your patches? This error implies that not. Compilation test is a hard requirement for patches. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] wilc1000: write value to WILC_INTR2_ENABLE register
writes:
> On 24/02/21 10:13 pm, Kalle Valo wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you
>> know the content is safe
>>
>> Marcus Folkesson writes:
>>
>>> Write the value instead of reading it twice.
>>>
>>> Fixes: 5e63a598441a ("staging: wilc1000: added 'wilc_' prefix for function
>>> in wilc_sdio.c file")
>>>
>>> Signed-off-by: Marcus Folkesson
>>> ---
>>> drivers/net/wireless/microchip/wilc1000/sdio.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/microchip/wilc1000/sdio.c
>>> b/drivers/net/wireless/microchip/wilc1000/sdio.c
>>> index 351ff909ab1c..e14b9fc2c67a 100644
>>> --- a/drivers/net/wireless/microchip/wilc1000/sdio.c
>>> +++ b/drivers/net/wireless/microchip/wilc1000/sdio.c
>>> @@ -947,7 +947,7 @@ static int wilc_sdio_sync_ext(struct wilc *wilc, int
>>> nint)
>>> for (i = 0; (i < 3) && (nint > 0); i++, nint--)
>>> reg |= BIT(i);
>>>
>>> - ret = wilc_sdio_read_reg(wilc, WILC_INTR2_ENABLE,
>>> ®);
>>> + ret = wilc_sdio_write_reg(wilc, WILC_INTR2_ENABLE,
>>> reg);
>>
>> To me it looks like the bug existed before commit 5e63a598441a:
>
>
> Yes, you are correct. The bug existed from commit c5c77ba18ea6:
>
> https://git.kernel.org/linus/c5c77ba18ea6
So the fixes tag should be:
Fixes: c5c77ba18ea6 ("staging: wilc1000: Add SDIO/SPI 802.11 driver")
I can change that during commit, ok?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] wilc1000: write value to WILC_INTR2_ENABLE register
Marcus Folkesson writes:
> Write the value instead of reading it twice.
>
> Fixes: 5e63a598441a ("staging: wilc1000: added 'wilc_' prefix for function in
> wilc_sdio.c file")
>
> Signed-off-by: Marcus Folkesson
> ---
> drivers/net/wireless/microchip/wilc1000/sdio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/microchip/wilc1000/sdio.c
> b/drivers/net/wireless/microchip/wilc1000/sdio.c
> index 351ff909ab1c..e14b9fc2c67a 100644
> --- a/drivers/net/wireless/microchip/wilc1000/sdio.c
> +++ b/drivers/net/wireless/microchip/wilc1000/sdio.c
> @@ -947,7 +947,7 @@ static int wilc_sdio_sync_ext(struct wilc *wilc, int nint)
> for (i = 0; (i < 3) && (nint > 0); i++, nint--)
> reg |= BIT(i);
>
> - ret = wilc_sdio_read_reg(wilc, WILC_INTR2_ENABLE, ®);
> + ret = wilc_sdio_write_reg(wilc, WILC_INTR2_ENABLE, reg);
To me it looks like the bug existed before commit 5e63a598441a:
- ret = sdio_read_reg(wilc, WILC_INTR2_ENABLE, ®);
+ ret = wilc_sdio_read_reg(wilc, WILC_INTR2_ENABLE, ®);
https://git.kernel.org/linus/5e63a598441a
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] ath11k: qmi: use %pad to format dma_addr_t
Geert Uytterhoeven wrote:
> If CONFIG_ARCH_DMA_ADDR_T_64BIT=n:
>
> drivers/net/wireless/ath/ath11k/qmi.c: In function
> ‘ath11k_qmi_respond_fw_mem_request’:
> drivers/net/wireless/ath/ath11k/qmi.c:1690:8: warning: format ‘%llx’
> expects argument of type ‘long long unsigned int’, but argument 5 has type
> ‘dma_addr_t’ {aka ‘unsigned int’} [-Wformat=]
> 1690 |"qmi req mem_seg[%d] 0x%llx %u %u\n", i,
> |^~~~
> 1691 | ab->qmi.target_mem[i].paddr,
> | ~~~
> | |
> | dma_addr_t {aka unsigned int}
> drivers/net/wireless/ath/ath11k/debug.h:64:30: note: in definition of
> macro ‘ath11k_dbg’
>64 | __ath11k_dbg(ar, dbg_mask, fmt, ##__VA_ARGS__); \
> | ^~~
> drivers/net/wireless/ath/ath11k/qmi.c:1690:34: note: format string is
> defined here
> 1690 |"qmi req mem_seg[%d] 0x%llx %u %u\n", i,
> | ~~~^
> | |
> | long long unsigned int
> | %x
>
> Fixes: d5395a5486596308 ("ath11k: qmi: add debug message for allocated memory
> segment addresses and sizes")
> Signed-off-by: Geert Uytterhoeven
Patch applied to wireless-drivers.git, thanks.
ebb9d34e073d ath11k: qmi: use %pad to format dma_addr_t
--
https://patchwork.kernel.org/project/linux-wireless/patch/20210221182754.2071863-1-ge...@linux-m68k.org/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v2] rtw88: 8822ce: fix wifi disconnect after S3/S4 on HONOR laptop
Pkshih writes:
> On Tue, 2021-02-23 at 09:08 +0200, Kalle Valo wrote:
>> Pkshih writes:
>>
>> >> > --- a/drivers/net/wireless/realtek/rtw88/rtw8822ce.c
>> >> > +++ b/drivers/net/wireless/realtek/rtw88/rtw8822ce.c
>> >> > @@ -25,7 +25,6 @@ static struct pci_driver rtw_8822ce_driver = {
>> >> > .id_table = rtw_8822ce_id_table,
>> >> > .probe = rtw_pci_probe,
>> >> > .remove = rtw_pci_remove,
>> >> > - .driver.pm = &rtw_pm_ops,
>> >>
>> >> Why just 8822ce? Why not remove rtw_pm_ops entirely if it just creates
>> >> problems?
>> >
>> > I think we can't remove rtw_pm_ops, because wowlan will not work.
>>
>> Ah. A comment code in the code stating that would be nice.
>>
>
> I'll do it.
Thank you.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v2] rtw88: 8822ce: fix wifi disconnect after S3/S4 on HONOR laptop
Pkshih writes:
>> > --- a/drivers/net/wireless/realtek/rtw88/rtw8822ce.c
>> > +++ b/drivers/net/wireless/realtek/rtw88/rtw8822ce.c
>> > @@ -25,7 +25,6 @@ static struct pci_driver rtw_8822ce_driver = {
>> > .id_table = rtw_8822ce_id_table,
>> > .probe = rtw_pci_probe,
>> > .remove = rtw_pci_remove,
>> > - .driver.pm = &rtw_pm_ops,
>>
>> Why just 8822ce? Why not remove rtw_pm_ops entirely if it just creates
>> problems?
>
> I think we can't remove rtw_pm_ops, because wowlan will not work.
Ah. A comment code in the code stating that would be nice.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v2] rtw88: 8822ce: fix wifi disconnect after S3/S4 on HONOR laptop
Hao Chen writes:
> The laptop's wifi disconnect after the laptop HONOR MagicBook 14
> sleep to S3/S4 and wake up.
>
> The dmesg of kernel report:
> "[ 99.990168] pcieport :00:01.2: can't change power state from D3hot
> to D0 (config space inaccessible)
> [ 99.990176] ACPI: EC: interrupt unblocked
> [ 99.993334] rtw_pci :01:00.0: can't change power state from D3hot
> to D0 (config space inaccessible)
> ..
> [ 102.133500] rtw_pci :01:00.0: mac power on failed
> [ 102.133503] rtw_pci :01:00.0: failed to power on mac
> [ 102.133505] [ cut here ]
> [ 102.133506] Hardware became unavailable upon resume. This could be a
> software issue prior to suspend or a hardware issue.
> [ 102.133569] WARNING: CPU: 4 PID: 5612 at net/mac80211/util.c:2232
> ieee80211_reconfig+0x9b/0x1490 [mac80211]
> [ 102.133570] Modules linked in: ccm rfcomm uvcvideo videobuf2_vmalloc
> videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc cmac bnep
> btusb btrtl btbcm btintel edac_mce_amd bluetooth kvm_amd ecdh_generic
> ecc kvm nls_iso8859_1 rtwpci rtw88 crct10dif_pclmul crc32_pclmul mac80211
> ghash_clmulni_intel aesni_intel snd_hda_codec_realtek crypto_simd huawei_wmi
> snd_hda_codec_generic cryptd cfg80211 wmi_bmof serio_raw sparse_keymap
> ledtrig_audio sp5100_tco glue_helper joydev snd_hda_codec_hdmi snd_hda_intel
> snd_intel_dspcfg wdat_wdt snd_hda_codec snd_hda_core pcspkr snd_hwdep snd_pcm
> efi_pstore snd_timer libarc4 k10temp snd soundcore snd_pci_acp3x ccp mac_hid
> binfmt_misc ip_tables x_tables autofs4 amdgpu amd_iommu_v2 gpu_sched
> i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops
> usbmouse cec nvme hid_generic i2c_piix4 usbhid nvme_core drm wmi video
> [ 102.133617] CPU: 4 PID: 5612 Comm: kworker/u32:16 Not tainted
> 5.7.7-amd64-desktop-8822 #3
> [ 102.133618] Hardware name: HUAWEI NBLL-WXX9/NBLL-WXX9-PCB, BIOS 1.06
> 09/29/2020
> [ 102.133623] Workqueue: events_unbound async_run_entry_fn
> [ 102.133651] RIP: 0010:ieee80211_reconfig+0x9b/0x1490 [mac80211]
> [ 102.133654] Code: 31 db e8 e8 fb 27 c2 41 c6 85 34 05 00 00 00 4c 89 ef e8
> 38
> 56 fc ff 89 45 b8 85 c0 74 4c 48 c7 c7 d0 0c 09 c1 e8 01 e0 25 c2 <0f> 0b 4c
> 89 ef e8 2b d1 ff ff e9 02 03 00 00 80 7d 9f 00 0f 85 1d
> [ 102.133655] RSP: 0018:be52c059fd08 EFLAGS: 00010286
> [ 102.133657] RAX: RBX: RCX:
> 0007
> [ 102.133658] RDX: 0007 RSI: 0096 RDI:
> 9d573f519cc0
> [ 102.133659] RBP: be52c059fd80 R08: ffd96245 R09:
> 0002cb80
> [ 102.133660] R10: 00016989e54c R11: 0002a360 R12:
> 9d5731f50300
> [ 102.133661] R13: 9d5731f50800 R14: 9d5731f504c8 R15:
> 8463fbef
> [ 102.133664] FS: () GS:9d573f50()
> knlGS:
> [ 102.133665] CS: 0010 DS: ES: CR0: 80050033
> [ 102.133666] CR2: CR3: 00033320a000 CR4:
> 00340ee0
> [ 102.133667] Call Trace:
> [ 102.133673] ? enqueue_entity+0xe3/0x680
> [ 102.133705] ieee80211_resume+0x55/0x70 [mac80211]
> [ 102.133729] wiphy_resume+0x84/0x130 [cfg80211]
> [ 102.133752] ? addresses_show+0xa0/0xa0 [cfg80211]
> [ 102.133757] dpm_run_callback+0x5b/0x150
> [ 102.133760] device_resume+0xad/0x1f0
> [ 102.133762] async_resume+0x1d/0x30
> [ 102.133764] async_run_entry_fn+0x3e/0x170
> [ 102.133768] process_one_work+0x1ab/0x380
> [ 102.133771] worker_thread+0x37/0x3b0
> [ 102.133774] kthread+0x120/0x140
> [ 102.133776] ? create_worker+0x1b0/0x1b0
> [ 102.133778] ? kthread_park+0x90/0x90
> [ 102.133782] ret_from_fork+0x22/0x40
> [ 102.133785] ---[ end trace 46229bfd3a4273be ]---
> [ 102.134137] [ cut here ]
> [ 102.134141] wlp1s0: Failed check-sdata-in-driver check, flags: 0x0
> [ 102.134195] WARNING: CPU: 0 PID: 5612 at net/mac80211/driver-ops.h:19
> drv_remove_interface+0xfe/0x110 [mac80211]"
>
> When try to pointer the driver.pm to NULL, the problem is fixed.
> It makes the sleep and wake procedure expected when pm's ops not NULL.
>
> By `git blame` command, I know that the assignment of .driver.pm =
> RTW_PM_OPS was in commit 44bc17f7f5b3 ("rtw88: support wowlan feature for
> 8822c"), and another
> commit 7dc7c41607d1 ("rtw88: avoid unused function warnings")
> pointed out rtw_pci_resume() and rtw_pci_suspend() are not used at
> all.
>
> So I think it's safe to remove them.
>
> Fixes: 7dc7c41607d1 ("rtw88: avoid unused function warnings")
> Fixes: 44bc17f7f5b3 ("rtw88: support wowlan feature for 8822c")
>
> Signed-off-by: Hao Chen
> ---
> drivers/net/wireless/realtek/rtw88/rtw8822ce.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/rtw8822ce.c
> b/drivers/net/wireless/realtek/rtw88/rtw8822ce.c
> index 3845b1333dc3..4c063192f801 100644
> --- a/drivers/net/wireless/realtek/rtw88/rtw8822ce.c
> +++ b/drivers/
Re: [PATCH] Revert "ath9k: fix ath_tx_process_buffer() potential null ptr dereference"
Shuah Khan wrote:
> This reverts commit a56c14bb21b296fb6d395164ab62ef2e419e5069.
>
> ath_tx_process_buffer() doesn't dereference or check sta and passes it
> to ath_tx_complete_aggr() and ath_tx_complete_buf().
>
> ath_tx_complete_aggr() checks the pointer before use. No problem here.
>
> ath_tx_complete_buf() doesn't check or dereference sta and passes it on
> to ath_tx_complete(). ath_tx_complete() doesn't check or dereference sta,
> but assigns it to tx_info->status.status_driver_data[0]
>
> ath_tx_complete_buf() is called from ath_tx_complete_aggr() passing
> null ieee80211_sta pointer.
>
> There is a potential for dereference later on, if and when the
> tx_info->status.status_driver_data[0]is referenced. In addition, the
> rcu read lock might be released before referencing the contents.
>
> ath_tx_complete_buf() should be fixed to check sta perhaps? Worth
> looking into.
>
> Reverting this patch because it doesn't solve the problem and introduces
> memory leak by skipping buffer completion if the pointer (sta) is NULL.
>
> Fixes: a56c14bb21b2 ("ath9k: fix ath_tx_process_buffer() potential null ptr
> dereference")
> Signed-off-by: Shuah Khan
> Signed-off-by: Kalle Valo
Patch applied to ath-next branch of ath.git, thanks.
14ebaeeff8d0 Revert "ath9k: fix ath_tx_process_buffer() potential null ptr
dereference"
--
https://patchwork.kernel.org/project/linux-wireless/patch/20210217211801.22540-1-sk...@linuxfoundation.org/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] rtw88: 8822ce: fix wifi disconnect after S3/S4 on HONOR laptop
陈浩 writes:
> By git blame command, I know that the assignment of .driver.pm =
> RTW_PM_OPS
>
> was in commit 44bc17f7f5b3b("rtw88: support wowlan feature for
> 8822c"),
>
> and another commit 7dc7c41607d19("avoid unused function warnings")
>
> pointed out rtw_pci_resume() and rtw_pci_suspend() are not used at
> all.
>
> So I think it's safe to remove them.
>
> Currently, I find that the rtl8822ce wifi chip and the pci bridge of
> it are not linked by pci
>
> after wake up by `lspci` command.
>
> when I set `pcie_aspm.policy=performance ` in the GRUB. The machine
> sleep and
>
> wake up normal.So I think when this ops is assignmented,the sleep and
> wake up procedure
>
> may cause pci device not linked.
Please don't use HTML, our lists automatically drop all HTML email.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] rtw88: 8822ce: fix wifi disconnect after S3/S4 on HONOR laptop
Hao Chen writes:
> When the laptop HONOR MagicBook 14 sleep to S3/S4, the laptop can't
> resume.
> The dmesg of kernel report:
> "[ 99.990168] pcieport :00:01.2: can't change power state
> from D3hot to D0 (config space inaccessible)
> [ 99.993334] rtw_pci :01:00.0: can't change power state
> from D3hot to D0 (config space inaccessible)
> [ 104.435004] rtw_pci :01:00.0: mac power on failed
> [ 104.435010] rtw_pci :01:00.0: failed to power on mac"
> When try to pointer the driver.pm to NULL, the problem is fixed.
> This driver hasn't implemented pm ops yet.It makes the sleep and
> wake procedure expected when pm's ops not NULL.
But why rtw_pci_suspend() and rtw_pci_resume() are empty? Should we just
remove them if they cause issues for the users? And if they are really
needed there should be a comment in the functions explaining the
situation.
> Fixed: commit e3037485c68e ("rtw88: new Realtek 802.11ac driver")
This should be:
Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: linux-next: build warnings after merge of the net-next tree
Stephen Rothwell writes:
> Hi all,
>
> On Fri, 19 Feb 2021 07:52:56 +1100 Stephen Rothwell
> wrote:
>>
>> After merging the net-next tree, today's linux-next build (htmldocs)
>> produced these warnings:
>>
>> Documentation/networking/filter.rst:1053: WARNING: Inline emphasis
>> start-string without end-string.
>> Documentation/networking/filter.rst:1053: WARNING: Inline emphasis
>> start-string without end-string.
>> Documentation/networking/filter.rst:1053: WARNING: Inline emphasis
>> start-string without end-string.
>> Documentation/networking/filter.rst:1053: WARNING: Inline emphasis
>> start-string without end-string.
>>
>> Introduced by commit
>>
>> 91c960b00566 ("bpf: Rename BPF_XADD and prepare to encode other atomics in
>> .imm")
>>
>> Sorry that I missed these earlier.
>
> These have been fixed in the net-next tree, actually. I was fooled
> because an earlier part of the net-next tree has been included in the
> wireless-drivers (not -next) tree today so these warnings popped up
> earlier, but are gone one the rest of the net-next tree is merged.
>
> Sorry for the noise.
Argh, sorry about that Stephen. I was preparing wireless-drivers for
followup fixes sent during the merge window, but didn't realise that it
will mess up your tree building. I need to avoid this in the future and
wireless-drivers should only follow the net tree.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] Revert "ath9k: fix ath_tx_process_buffer() potential null ptr dereference"
Shuah Khan wrote:
> This reverts commit a56c14bb21b296fb6d395164ab62ef2e419e5069.
>
> ath_tx_process_buffer() doesn't dereference or check sta and passes it
> to ath_tx_complete_aggr() and ath_tx_complete_buf().
>
> ath_tx_complete_aggr() checks the pointer before use. No problem here.
>
> ath_tx_complete_buf() doesn't check or dereference sta and passes it on
> to ath_tx_complete(). ath_tx_complete() doesn't check or dereference sta,
> but assigns it to tx_info->status.status_driver_data[0]
>
> ath_tx_complete_buf() is called from ath_tx_complete_aggr() passing
> null ieee80211_sta pointer.
>
> There is a potential for dereference later on, if and when the
> tx_info->status.status_driver_data[0]is referenced. In addition, the
> rcu read lock might be released before referencing the contents.
>
> ath_tx_complete_buf() should be fixed to check sta perhaps? Worth
> looking into.
>
> Reverting this patch because it doesn't solve the problem and introduces
> memory leak by skipping buffer completion if the pointer (sta) is NULL.
>
> Fixes: a56c14bb21b2 ("ath9k: fix ath_tx_process_buffer() potential null ptr
> dereference")
> Signed-off-by: Shuah Khan
> Signed-off-by: Kalle Valo
Thanks. I added the commit id and Fixes tag to the commit log, see the new
version above.
--
https://patchwork.kernel.org/project/linux-wireless/patch/20210217211801.22540-1-sk...@linuxfoundation.org/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] [v13] wireless: Initial driver submission for pureLiFi STA devices
Srinivasan Raju writes:
> This introduces the pureLiFi LiFi driver for LiFi-X, LiFi-XC
> and LiFi-XL USB devices.
>
> This driver implementation has been based on the zd1211rw driver.
>
> Driver is based on 802.11 softMAC Architecture and uses
> native 802.11 for configuration and management.
>
> The driver is compiled and tested in ARM, x86 architectures and
> compiled in powerpc architecture.
>
> Signed-off-by: Srinivasan Raju
[...]
> + if ((le16_to_cpu(udev->descriptor.idVendor) ==
> + PURELIFI_X_VENDOR_ID_0) &&
> + (le16_to_cpu(udev->descriptor.idProduct) ==
> + PURELIFI_X_PRODUCT_ID_0)) {
> + fw_name = "plfxlc/LiFi-X.bin";
> + dev_dbg(&intf->dev, "bin file for X selected\n");
> +
> + } else if ((le16_to_cpu(udev->descriptor.idVendor)) ==
> + PURELIFI_XC_VENDOR_ID_0 &&
> +(le16_to_cpu(udev->descriptor.idProduct) ==
> + PURELIFI_XC_PRODUCT_ID_0)) {
> + fw_name = "plfxlc/LiFi-XC.bin";
> + dev_dbg(&intf->dev, "bin file for XC selected\n");
> +
> + } else {
> + r = -EINVAL;
> + goto error;
> + }
> +
> + r = request_firmware((const struct firmware **)&fw, fw_name,
> + &intf->dev);
> + if (r) {
> + dev_err(&intf->dev, "request_firmware failed (%d)\n", r);
> + goto error;
> + }
[...]
> + /* Code for single pack file download */
> +
> + fw_pack = "plfxlc/LiFi-XL.bin";
> +
> + r = request_firmware((const struct firmware **)&fw_packed, fw_pack,
> + &intf->dev);
> + if (r) {
> + dev_err(&intf->dev, "request_firmware failed (%d)\n", r);
> + goto error;
> + }
Having the firmware files under plfxlc/ directory looks good to me. But
I'm not really a fan of upper case filenames, is there a reason for
that? I would prefer have all lowercase filenames.
Also the cast (const struct firmware **) looks very wrong, but I didn't
investigate why you do it. I'm sure there is a proper way to implement
whatever you need here, without the cast.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] [v13] wireless: Initial driver submission for pureLiFi STA devices
Kalle Valo writes: > Srinivasan Raju writes: > >> This introduces the pureLiFi LiFi driver for LiFi-X, LiFi-XC >> and LiFi-XL USB devices. >> >> This driver implementation has been based on the zd1211rw driver. >> >> Driver is based on 802.11 softMAC Architecture and uses >> native 802.11 for configuration and management. >> >> The driver is compiled and tested in ARM, x86 architectures and >> compiled in powerpc architecture. >> >> Signed-off-by: Srinivasan Raju > > I pushed this now to the pending branch of wireless-drivers-next for > build testing, let's see what kind of results we get. Ah, kbuild bot had already reported few issues: https://patchwork.kernel.org/project/linux-wireless/patch/20210212115030.124490-1-srini.r...@purelifi.com/ Please fix those and I recommend waiting few days in case the bot finds more issues. After that you can submitt v14 fixing the comments you got in this review round. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] [v13] wireless: Initial driver submission for pureLiFi STA devices
Srinivasan Raju writes: > This introduces the pureLiFi LiFi driver for LiFi-X, LiFi-XC > and LiFi-XL USB devices. > > This driver implementation has been based on the zd1211rw driver. > > Driver is based on 802.11 softMAC Architecture and uses > native 802.11 for configuration and management. > > The driver is compiled and tested in ARM, x86 architectures and > compiled in powerpc architecture. > > Signed-off-by: Srinivasan Raju [...] > + send_vendor_command(udev, PLF_VNDR_FPGA_STATE_CMD, NULL, 0); > + > + msleep(200); There are multiple msleeps like this, please add a descriptive define for value 200. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] [v13] wireless: Initial driver submission for pureLiFi STA devices
Johannes Berg writes: >> +++ b/drivers/net/wireless/purelifi/Makefile >> @@ -0,0 +1,2 @@ >> +# SPDX-License-Identifier: GPL-2.0-only >> +obj-$(CONFIG_WLAN_VENDOR_PURELIFI) := plfxlc/ > > Although this one doesn't do anything, so all you did was save a level > of Kconfig inclusion I guess ... no real objection to that. I think this should use obj-$(CONFIG_PLFXLC). -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] [v13] wireless: Initial driver submission for pureLiFi STA devices
Srinivasan Raju writes: > This introduces the pureLiFi LiFi driver for LiFi-X, LiFi-XC > and LiFi-XL USB devices. > > This driver implementation has been based on the zd1211rw driver. > > Driver is based on 802.11 softMAC Architecture and uses > native 802.11 for configuration and management. > > The driver is compiled and tested in ARM, x86 architectures and > compiled in powerpc architecture. > > Signed-off-by: Srinivasan Raju I pushed this now to the pending branch of wireless-drivers-next for build testing, let's see what kind of results we get. I didn't manage to do a thorough review yet, but few quick comments: > --- a/drivers/net/wireless/Kconfig > +++ b/drivers/net/wireless/Kconfig > @@ -35,6 +35,7 @@ source "drivers/net/wireless/st/Kconfig" > source "drivers/net/wireless/ti/Kconfig" > source "drivers/net/wireless/zydas/Kconfig" > source "drivers/net/wireless/quantenna/Kconfig" > +source "drivers/net/wireless/purelifi/Kconfig" This is supposed to be in alphabetical order. > --- a/drivers/net/wireless/Makefile > +++ b/drivers/net/wireless/Makefile > @@ -20,6 +20,7 @@ obj-$(CONFIG_WLAN_VENDOR_ST) += st/ > obj-$(CONFIG_WLAN_VENDOR_TI) += ti/ > obj-$(CONFIG_WLAN_VENDOR_ZYDAS) += zydas/ > obj-$(CONFIG_WLAN_VENDOR_QUANTENNA) += quantenna/ > +obj-$(CONFIG_WLAN_VENDOR_PURELIFI) += purelifi/ And this one as well. Clearly I missed these with quantenna, but no need to redo the same mistake with purelife. Also patches welcome to fix quantenna sorting. > --- /dev/null > +++ b/drivers/net/wireless/purelifi/plfxlc/Kconfig > @@ -0,0 +1,13 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +config PLFXLC > + > + tristate "pureLiFi X, XL, XC device support" > + depends on CFG80211 && MAC80211 && USB > + help > +This driver makes the adapter appear as a normal WLAN interface. > + > +The pureLiFi device requires external STA firmware to be loaded. > + The documentation here is not telling much. I think it goes without saying that a firmware is needed, so no need to mention it. And also "normal WLAN interface" is a standard upstream requirement so drop that as well. Instead describe here in detail what hardware this driver supports, for example exact product names, bus types, wifi/ieee generation etc. > +To compile this driver as a module, choose M here: the module will > +be called purelifi. Didn't you rename it to plfxlc? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 2/2] ath9k: fix ath_tx_process_buffer() potential null ptr dereference
Shuah Khan writes: > On 2/16/21 12:53 AM, Felix Fietkau wrote: >> >> On 2021-02-16 08:03, Kalle Valo wrote: >>> Shuah Khan wrote: >>> >>>> ath_tx_process_buffer() references ieee80211_find_sta_by_ifaddr() >>>> return pointer (sta) outside null check. Fix it by moving the code >>>> block under the null check. >>>> >>>> This problem was found while reviewing code to debug RCU warn from >>>> ath10k_wmi_tlv_parse_peer_stats_info() and a subsequent manual audit >>>> of other callers of ieee80211_find_sta_by_ifaddr() that don't hold >>>> RCU read lock. >>>> >>>> Signed-off-by: Shuah Khan >>>> Signed-off-by: Kalle Valo >>> >>> Patch applied to ath-next branch of ath.git, thanks. >>> >>> a56c14bb21b2 ath9k: fix ath_tx_process_buffer() potential null ptr >>> dereference >> I just took another look at this patch, and it is completely bogus. >> Not only does the stated reason not make any sense (sta is simply passed >> to other functions, not dereferenced without checks), but this also >> introduces a horrible memory leak by skipping buffer completion if sta >> is NULL. >> Please drop it, the code is fine as-is. > > A comment describing what you said here might be a good addition to this > comment block though. Shuah, can you send a followup patch which reverts your change and adds the comment? I try to avoid rebasing my trees. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH][next] ath11k: debugfs: Fix spelling mistake "Opportunies" -> "Opportunities"
Colin King wrote: > There is a spelling mistake in some debug text, fix this. > > Signed-off-by: Colin Ian King > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 9c349dbd0752 ath11k: debugfs: Fix spelling mistake "Opportunies" -> "Opportunities" -- https://patchwork.kernel.org/project/linux-wireless/patch/20210212113627.212787-1-colin.k...@canonical.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 2/2] ath9k: fix ath_tx_process_buffer() potential null ptr dereference
Shuah Khan wrote: > ath_tx_process_buffer() references ieee80211_find_sta_by_ifaddr() > return pointer (sta) outside null check. Fix it by moving the code > block under the null check. > > This problem was found while reviewing code to debug RCU warn from > ath10k_wmi_tlv_parse_peer_stats_info() and a subsequent manual audit > of other callers of ieee80211_find_sta_by_ifaddr() that don't hold > RCU read lock. > > Signed-off-by: Shuah Khan > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. a56c14bb21b2 ath9k: fix ath_tx_process_buffer() potential null ptr dereference -- https://patchwork.kernel.org/project/linux-wireless/patch/43ed9abb9e8d7112f3cc168c2f8c489e253635ba.1613090339.git.sk...@linuxfoundation.org/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 2/2] ath10k: detect conf_mutex held ath10k_drain_tx() calls
Shuah Khan writes: > ath10k_drain_tx() must not be called with conf_mutex held as workers can > use that also. Add call to lockdep_assert_not_held() on conf_mutex to > detect if conf_mutex is held by the caller. > > The idea for this patch stemmed from coming across the comment block > above the ath10k_drain_tx() while reviewing the conf_mutex holds during > to debug the conf_mutex lock assert in ath10k_debug_fw_stats_request(). > > Adding detection to assert on conf_mutex hold will help detect incorrect > usages that could lead to locking problems when async worker routines try > to call this routine. > > Link: https://lore.kernel.org/linux-wireless/871rdmu9z9@codeaurora.org/ > Signed-off-by: Shuah Khan This can go via the same tree as patch 1: Acked-by: Kalle Valo But I can also take this to my ath tree, once patch 1 has reached it. Just let me know what is preferred. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
pull-request: wireless-drivers-next-2021-02-12
A15 tablet Ihab Zhaika (1): iwlwifi: add new cards for So and Qu family Ilan Peer (2): iwlwifi: pcie: Disable softirqs during Rx queue init iwlwifi: mvm: Support SCAN_CFG_CMD version 5 Jiapeng Chong (4): iwlegacy: 4965-mac: Simplify the calculation of variables ssb: Use true and false for bool variable rtlwifi: rtl8192se: Simplify bool comparison rtlwifi: rtl8821ae: phy: Simplify bool comparison Johannes Berg (19): iwlwifi: mvm: add notification size checks iwlwifi: mvm: check more notification sizes iwlwifi: mvm: remove debugfs injection limitations iwlwifi: mvm: scan: fix scheduled scan restart handling iwlwifi: mvm: handle CCA-EXT delay firmware notification iwlwifi: pcie: properly implement NAPI iwlwifi: mvm: simplify TX power setting iwlwifi: mvm: debugfs: check length precisely in inject_packet iwlwifi: always allow maximum A-MSDU on newer devices iwlwifi: mvm: advertise BIGTK client support if available iwlwifi: fw api: make hdr a zero-size array again iwlwifi: mvm: slightly clean up rs_fw_set_supp_rates() iwlwifi: mvm: make iwl_mvm_tt_temp_changed() static iwlwifi: pcie: don't disable interrupts for reg_lock iwlwifi: mvm: remove useless iwl_mvm_resume_d3() function iwlwifi: api: clean up some documentation/bits iwlwifi: remove flags argument for nic_access iwlwifi: remove max_vht_ampdu_exponent config parameter iwlwifi: remove max_ht_ampdu_exponent config parameter Kalle Valo (8): ath10k: remove unused struct ath10k::dev_type Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git Merge tag 'iwlwifi-next-for-kalle-2021-02-05' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Merge tag 'mt76-for-kvalo-2021-01-29' of https://github.com/nbd168/wireless ath11k: pci: remove experimental warning ath11k: qmi: add debug message for allocated memory segment addresses and sizes Merge tag 'iwlwifi-next-for-kalle-2021-02-10' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git Karthikeyan Periyasamy (2): ath11k: remove duplicate function declaration ath11k: Update tx descriptor search index properly Krishnanand Prabhu (1): iwlwifi: mvm: add explicit check for non-data frames in get Tx rate Linus Lüssing (2): ath10k: increase rx buffer size to 2048 ath9k: fix data bus crash when setting nf_override via debugfs Loic Poulain (1): wcn36xx: del BA session on TX stop Lorenzo Bianconi (19): mt76: mt7915: run mt7915_configure_filter holding mt76 mutex mt76: mt7915: fix endianness warning in mt7915_mcu_set_radar_th mt76: mt7915: simplify mt7915_mcu_send_message routine mt76: move mac_work in mt76_core module mt76: move chainmask in mt76_phy mt76: mt7615: set mcu country code in mt7615_mcu_set_channel_domain() mt76: usb: process URBs with status EPROTO properly mt76: introduce mt76_vif data structure mt76: mt76_connac: create mcu library mt76: mt76_connac: move hw_scan and sched_scan routine in mt76_connac_mcu module mt76: mt76_connac: move WoW and suspend code in mt76_connac_mcu module mt76: mt76_connac: move pm data struct in mt76_connac.h mt76: mt76_connac: move pm utility routines in mt76_connac_lib module mt76: mt7921: rely on mt76_connac_mcu common library mt76: mt7921: rely on mt76_connac_mcu module for sched_scan and hw_scan mt76: mt7921: rely on mt76_connac_mcu module for suspend and WoW support mt76: mt7921: introduce regdomain notifier support mt76: mt7921: enable MSI interrupts mt76: mt7663: introduce coredump support Luca Coelho (24): iwlwifi: bump FW API to 60 for AX devices iwlwifi: move SnJ and So rules to the new tables iwlwifi: add support for SnJ with Jf devices iwlwifi: mvm: move early time-point before nvm_init in non-unified iwlwifi: pcie: add support for SnJ with Hr1 iwlwifi: mvm: set enabled in the PPAG command properly iwlwifi: mvm: implement approved list for the PPAG feature iwlwifi: mvm: add HP to the PPAG approved list iwlwifi: mvm: add Samsung to the PPAG approved list iwlwifi: mvm: add Microsoft to the PPAG approved list iwlwifi: mvm: add Asus to the PPAG approved list iwlwifi: bump FW API to 61 for AX devices iwlwifi: pcie: add a few missing entries for So with Hr iwlwifi: acpi: fix PPAG table sizes iwlwifi: mvm: fix the type we use in the PPAG table validity checks iwlwifi: mvm: store PPAG enabled/disabled flag properly iwlwifi: mvm: send stored PPAG command instead of local iwlwifi: mvm: assign SAR table revision to the command later
Re: [PATCH v2] ath10k: hold RCU lock when calling ieee80211_find_sta_by_ifaddr()
Shuah Khan wrote: > ieee80211_find_sta_by_ifaddr() must be called under the RCU lock and > the resulting pointer is only valid under RCU lock as well. > > Fix ath10k_wmi_tlv_op_pull_peer_stats_info() to hold RCU lock before it > calls ieee80211_find_sta_by_ifaddr() and release it when the resulting > pointer is no longer needed. > > This problem was found while reviewing code to debug RCU warn from > ath10k_wmi_tlv_parse_peer_stats_info(). > > Link: > https://lore.kernel.org/linux-wireless/7230c9e5-2632-b77e-c4f9-10eca557a...@linuxfoundation.org/ > Signed-off-by: Shuah Khan > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 09078368d516 ath10k: hold RCU lock when calling ieee80211_find_sta_by_ifaddr() -- https://patchwork.kernel.org/project/linux-wireless/patch/20210210212107.40373-1-sk...@linuxfoundation.org/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 5/5] ath10k: reduce invalid ht params rate message noise
Shuah Khan writes:
> On 2/10/21 1:28 AM, Kalle Valo wrote:
>> Wen Gong writes:
>>
>>> On 2021-02-10 08:42, Shuah Khan wrote:
>>>> ath10k_mac_get_rate_flags_ht() floods dmesg with the following
>>>> messages,
>>>> when it fails to find a match for mcs=7 and rate=1440.
>>>>
>>>> supported_ht_mcs_rate_nss2:
>>>> {7, {1300, 2700, 1444, 3000} }
>>>>
>>>> ath10k_pci :02:00.0: invalid ht params rate 1440 100kbps nss 2
>>>> mcs 7
>>>>
>>>> dev_warn_ratelimited() isn't helping the noise. Use dev_warn_once()
>>>> instead.
>>>>
>>>> Signed-off-by: Shuah Khan
>>>> ---
>>>> drivers/net/wireless/ath/ath10k/mac.c | 5 +++--
>>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
>>>> b/drivers/net/wireless/ath/ath10k/mac.c
>>>> index 3545ce7dce0a..276321f0cfdd 100644
>>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>>> @@ -8970,8 +8970,9 @@ static void ath10k_mac_get_rate_flags_ht(struct
>>>> ath10k *ar, u32 rate, u8 nss, u8
>>>>*bw |= RATE_INFO_BW_40;
>>>>*flags |= RATE_INFO_FLAGS_SHORT_GI;
>>>>} else {
>>>> - ath10k_warn(ar, "invalid ht params rate %d 100kbps nss %d mcs
>>>> %d",
>>>> - rate, nss, mcs);
>>>> + dev_warn_once(ar->dev,
>>>> +"invalid ht params rate %d 100kbps nss %d mcs %d",
>>>> +rate, nss, mcs);
>>>>}
>>>> }
>>>
>>> The {7, {1300, 2700, 1444, 3000} } is a correct value.
>>> The 1440 is report from firmware, its a wrong value, it has fixed in
>>> firmware.
>>
>> In what version?
>>
>
> Here is the info:
>
> ath10k_pci :02:00.0: qca6174 hw3.2 target 0x0503 chip_id
> 0x00340aff sub 17aa:0827
>
> ath10k_pci :02:00.0: firmware ver WLAN.RM.4.4.1-00140-QCARMSWPZ-1
> api 6 features wowlan,ignore-otp,mfp crc32 29eb8ca1
>
> ath10k_pci :02:00.0: board_file api 2 bmi_id N/A crc32 4ac0889b
>
> ath10k_pci :02:00.0: htt-ver 3.60 wmi-op 4 htt-op 3 cal otp
> max-sta 32 raw 0 hwcrypto 1
>
>>> If change it to dev_warn_once, then it will have no chance to find the
>>> other wrong values which report by firmware, and it indicate
>>> a wrong value to mac80211/cfg80211 and lead "iw wlan0 station dump"
>>> get a wrong bitrate.
>>
>
> Agreed.
>
>> I agree, we should keep this warning. If the firmware still keeps
>> sending invalid rates we should add a specific check to ignore the known
>> invalid values, but not all of them.
>>
>
> Would it be helpful to adjust the default rate limits and set the to
> a higher value instead. It might be difficult to account all possible
> invalid values?
>
> Something like, ath10k_warn_ratelimited() to adjust the
>
> DEFAULT_RATELIMIT_INTERVAL and DEFAULT_RATELIMIT_BURST using
> DEFINE_RATELIMIT_STATE
>
> Let me know if you like this idea. I can send a patch in to do this.
> I will hang on to this firmware version for a little but longer, so
> we have a test case. :)
I would rather first try to fix the root cause, which is the firmware
sending invalid rates. Wen, you mentioned there's a fix in firmware. Do
you know which firmware version (and branch) has the fix?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 4/5] ath10k: detect conf_mutex held ath10k_drain_tx() calls
Shuah Khan writes:
> On 2/10/21 1:25 AM, Kalle Valo wrote:
>> Shuah Khan writes:
>>
>>> ath10k_drain_tx() must not be called with conf_mutex held as workers can
>>> use that also. Add check to detect conf_mutex held calls.
>>>
>>> Signed-off-by: Shuah Khan
>>
>> The commit log does not answer to "Why?". How did you find this? What
>> actual problem are you trying to solve?
>>
>
> I came across the comment block above the ath10k_drain_tx() as I was
> reviewing at conf_mutex holds while I was debugging the conf_mutex
> lock assert in ath10k_debug_fw_stats_request().
>
> My reasoning is that having this will help detect incorrect usages
> of ath10k_drain_tx() while holding conf_mutex which could lead to
> locking problems when async worker routines try to call this routine.
Ok, makes sense. I prefer having this background info in the commit log,
for example "found by code review" or something like that. Or just copy
what you wrote above :)
>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>> @@ -4566,6 +4566,7 @@ static void
>>> ath10k_mac_op_wake_tx_queue(struct ieee80211_hw *hw,
>>> /* Must not be called with conf_mutex held as workers can use that also.
>>> */
>>> void ath10k_drain_tx(struct ath10k *ar)
>>> {
>>> + WARN_ON(lockdep_is_held(&ar->conf_mutex));
>>
>> Empty line after WARN_ON().
>>
>
> Will do.
>
>> Shouldn't this check debug_locks similarly lockdep_assert_held() does?
>>
>> #define lockdep_assert_held(l) do {\
>> WARN_ON(debug_locks && !lockdep_is_held(l));\
>> } while (0)
>>
>> And I suspect you need #ifdef CONFIG_LOCKDEP which should fix the kbuild
>> bot error.
>>
>
> Yes.
>
>> But honestly I would prefer to have lockdep_assert_not_held() in
>> include/linux/lockdep.h, much cleaner that way. Also
>> i915_gem_object_lookup_rcu() could then use the same macro.
>>
>
> Right. This is the right way to go. That was first instinct and
> decided to have the discussion evolve in that direction. Now that
> it has, I will combine this change with
> include/linux/lockdep.h and add lockdep_assert_not_held()
>
> I think we might have other places in the kernel that could use
> lockdep_assert_not_held() in addition to i915_gem_object_lookup_rcu()
Great, thank you. The only problem is that lockdep.h changes have to go
via some other tree, I just don't know which :) I think it would be
easiest if also the ath10k patch goes via that other tree, I can ack the
ath10k changes.
Another option is that I'll apply the ath10k patch after the lockdep.h
change has trickled down to my tree, but that usually happens only after
the merge window and means weeks of waiting. Either is fine for me.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
