When deinitializing the driver, one or more "FW not responding" error
appears on the console. This appears to be due to wilc_wlan_stop()
disabling host/WILC1000 communication, but then right afterwards, it
tries to release the bus with chip-sleep enabled. The problem is
enabling the chip-sleep cannot success once host/WILC1000
communication is disabled. Fix by only releasing the bus.
Signed-off-by: David Mosberger-Tang <davidm@egauge.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211208062747.3405221-1-davidm@egauge.net
The USE_SPI_DMA macro name suggests that it could be set to 1 to
control whether or not SPI DMA should be used. However, that's not
what it does. If set to 1, it'll set the SPI messages'
"is_dma_mapped" flag to true, even though the tx/rx buffers aren't
actually DMA mapped by the driver. In other words, setting this flag
to 1 will break the driver.
Best to clean up this confusion by removing the macro altogether.
There is no need to explicitly initialize "is_dma_mapped" because the
message is cleared to zero anyhow, so "is_dma_mapped" is set to false
by default.
Signed-off-by: David Mosberger-Tang <davidm@egauge.net>
Acked-by: Ajay Singh <ajay.kathat@microchip.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211207002453.3193737-1-davidm@egauge.net
In mode-2 QCN9074 firmware uses 15MB of host memory and firmware
request 1MB size segements in QMI, whereas in mode-0 firmware
uses 45MB of host memory and each segment is of 2MB size.
In mode-2 firmware operates with reduced number of vdevs and peers.
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01838-QCAHKSWPL_SILICONZ-1
Signed-off-by: Seevalamuthu Mariappan <seevalam@codeaurora.org>
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211209104351.9811-3-kvalo@kernel.org
In ath11k_mac_op_hw_scan(), the return value of kzalloc() is directly
used in memcpy(), which may lead to a NULL pointer dereference on
failure of kzalloc().
Fix this bug by adding a check of arg.extraie.ptr.
This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.
Builds with CONFIG_ATH11K=m show no new warnings, and our static
analyzer no longer warns about this code.
Fixes: d5c65159f2 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Zhou Qingyang <zhou1615@umn.edu>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211202155348.71315-1-zhou1615@umn.edu
Update complete_and_exit to call kthread_exit instead of do_exit.
Change the name to reflect this change in functionality. All of the
users of complete_and_exit are causing the current kthread to exit so
this change makes it clear what is happening.
Move the implementation of kthread_complete_and_exit from
kernel/exit.c to to kernel/kthread.c. As this function is kthread
specific it makes most sense to live with the kthread functions.
There are no functional change.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
The code that uses variable queued has been removed,
and "mt76_is_usb(dev) ? q->ndesc - q->queued : q->queued"
didn't do anything, so all they should be removed as well.
Eliminate the following clang warnings:
drivers/net/wireless/mediatek/mt76/debugfs.c:77:9: warning: variable
‘queued’ set but not used.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Fixes: 2d8be76c16 ("mt76: debugfs: improve queue node readability")
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
I updated to sparse v0.6.4 and it warns:
drivers/net/wireless/ath/ath10k/wmi.c: note: in included file (through drivers/net/wireless/ath/ath10k/core.h):
drivers/net/wireless/ath/ath10k/wmi.h:3481:34: warning: array of flexible structures
Fix it by changing the type to u8 array, in struct wmi_phyerr_hdr_arg it's
stored as a void pointer anyway.
Compile tested only.
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211209091545.6098-2-kvalo@kernel.org
I updated to sparse v0.6.4 and it warns:
drivers/net/wireless/ath/ath10k/hw.c: note: in included file (through drivers/net/wireless/ath/ath10k/core.h):
drivers/net/wireless/ath/ath10k/htt.h:1503:41: warning: array of flexible structures
drivers/net/wireless/ath/ath10k/htt_rx.c: note: in included file (through drivers/net/wireless/ath/ath10k/core.h):
drivers/net/wireless/ath/ath10k/htt.h:1503:41: warning: array of flexible structures
The structure is unused in ath10k so let's just remove it.
Compile tested only.
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211209091545.6098-1-kvalo@kernel.org
Pull char/misc driver fixes from Greg KH:
"Here are a bunch of small char/misc and other driver subsystem fixes.
Included in here are:
- iio driver fixes for reported problems
- phy driver fixes for a number of reported problems
- mhi resume bugfix for broken hardware
- nvmem driver fix
- rtsx driver fix for irq issues
- fastrpc packet parsing fix
All of these have been in linux-next for a while with no reported
issues"
* tag 'char-misc-5.16-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (33 commits)
bus: mhi: core: Add support for forced PM resume
iio: trigger: stm32-timer: fix MODULE_ALIAS
misc: rtsx: Avoid mangling IRQ during runtime PM
nvmem: eeprom: at25: fix FRAM byte_len
misc: fastrpc: fix improper packet size calculation
MAINTAINERS: add maintainer for Qualcomm FastRPC driver
bus: mhi: pci_generic: Fix device recovery failed issue
iio: adc: stm32: fix null pointer on defer_probe error
phy: HiSilicon: Fix copy and paste bug in error handling
dt-bindings: phy: zynqmp-psgtr: fix USB phy name
phy: ti: omap-usb2: Fix the kernel-doc style
phy: qualcomm: ipq806x-usb: Fix kernel-doc style
iio: at91-sama5d2: Fix incorrect sign extension
iio: adc: axp20x_adc: fix charging current reporting on AXP22x
iio: gyro: adxrs290: fix data signedness
phy: ti: tusb1210: Fix the kernel-doc warn
phy: qualcomm: usb-hsic: Fix the kernel-doc warn
phy: qualcomm: qmp: Add missing struct documentation
phy: mvebu-cp110-utmi: Fix kernel-doc warns
iio: ad7768-1: Call iio_trigger_notify_done() on error
...
When scan request on channel 1, it also receive beacon from other
channels, and the beacon also indicate to mac80211 and wpa_supplicant,
and then the bss info appears in radio measurement report of radio
measurement sent from wpa_supplicant, thus lead RRM case fail.
This is to drop the beacon and probe response which is not the same
channel of scanning.
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00049
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211208061752.16564-1-quic_wgong@quicinc.com
Currently there is no validation on the spectral/CFR report
over the db ring buffers from the hardware. Improper/incomplete
DMA by the target can result in invalid data received by host.
Due to this we may populate incorrect data to user space.
This buffer validation support fix this issues by filling some
magic value in the buffer during buffer replenish and check for
the magic value in the buffer received by the target. If host
detect magic value in the received buffer it will drop the buffer.
Tested-on: IPQ8074 WLAN.HK.2.4.0.1-01467-QCAHKSWPL_SILICONZ-1
Signed-off-by: Venkateswara Naralasetty <quic_vnaralas@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/1637312901-10279-2-git-send-email-quic_vnaralas@quicinc.com
In full monitor mode, monitor destination ring is read before monitor
status ring. mon_dst_ring has ppdu id, reap till the end of PPDU. Add
all the MPDUs to list. Start processing the status ring, if PPDU id in
status ring is lagging behind, reap the status ring, once the PPDU ID
matches, deliver the MSDU to upper layer. If status PPDU id leading,
reap the mon_dst_ring.
The advantage with full monitor mode is hardware has status buffers
available for all the MPDUs in mon_dst_ring, which makes it possible
to deliver more frames to be seen on sniffer.
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01734-QCAHKSWPL_SILICONZ-1
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/1638881695-22155-4-git-send-email-akolli@codeaurora.org
In builds with -Warray-bounds, casts from smaller objects to larger
objects will produce warnings. These can be overly conservative, but since
-Warray-bounds has been finding legitimate bugs, it is desirable to turn
it on globally. Instead of casting a u32 to a larger object, redefine
the u32 portion of the header to a separate struct that can be used for
both u32 operations and the distinct header fields. Silences this warning:
drivers/net/wireless/ath/ath6kl/htc_mbox.c: In function 'htc_wait_for_ctrl_msg':
drivers/net/wireless/ath/ath6kl/htc_mbox.c:2275:20: error: array subscript 'struct htc_frame_hdr[0]' is partly outside array bounds of 'u32[1]' {aka 'unsigned int[1]'} [-Werror=array-bounds]
2275 | if (htc_hdr->eid != ENDPOINT_0)
| ^~
drivers/net/wireless/ath/ath6kl/htc_mbox.c:2264:13: note: while referencing 'look_ahead'
2264 | u32 look_ahead;
| ^~~~~~~~~~
This change results in no executable instruction differences.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211207063538.2767954-1-keescook@chromium.org
Currently mac80211 will send 3 scan request for each scan of WCN6855,
they are 2.4 GHz/5 GHz/6 GHz band scan. Firmware of WCN6855 will
cache the RNR IE(Reduced Neighbor Report element) which exist in the
beacon of 2.4 GHz/5 GHz of the AP which is co-located with 6 GHz,
and then use the cache to scan in 6 GHz band scan if the 6 GHz scan
is in the same scan with the 2.4 GHz/5 GHz band, this will helpful to
search more AP of 6 GHz. Also it will decrease the time cost of scan
because firmware will use dual-band scan for the 2.4 GHz/5 GHz, it
means the 2.4 GHz and 5 GHz scans are doing simultaneously.
Set the flag IEEE80211_HW_SINGLE_SCAN_ON_ALL_BANDS for WCN6855 since
it supports 2.4 GHz/5 GHz/6 GHz and it is single pdev which means
all the 2.4 GHz/5 GHz/6 GHz exist in the same wiphy/ieee80211_hw.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Tested-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211129101309.2931-1-quic_wgong@quicinc.com
If cfg80211 is providing extraie's for a scanning process then ath11k will
copy that over to the firmware. The extraie.len is a 32 bit value in struct
element_info and describes the amount of bytes for the vendor information
elements.
The WMI_TLV packet is having a special WMI_TAG_ARRAY_BYTE section. This
section can have a (payload) length up to 65535 bytes because the
WMI_TLV_LEN can store up to 16 bits. The code was missing such a check and
could have created a scan request which cannot be parsed correctly by the
firmware.
But the bigger problem was the allocation of the buffer. It has to align
the TLV sections by 4 bytes. But the code was using an u8 to store the
newly calculated length of this section (with alignment). And the new
calculated length was then used to allocate the skbuff. But the actual code
to copy in the data is using the extraie.len and not the calculated
"aligned" length.
The length of extraie with IEEE80211_HW_SINGLE_SCAN_ON_ALL_BANDS enabled
was 264 bytes during tests with a QCA Milan card. But it only allocated 8
bytes (264 bytes % 256) for it. As consequence, the code to memcpy the
extraie into the skb was then just overwriting data after skb->end. Things
like shinfo were therefore corrupted. This could usually be seen by a crash
in skb_zcopy_clear which tried to call a ubuf_info callback (using a bogus
address).
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-02892.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Cc: stable@vger.kernel.org
Fixes: d5c65159f2 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211207142913.1734635-1-sven@narfation.org
Quoting Jia-Ju Bai <baijiaju1990@gmail.com>:
mwifiex_dequeue_tx_packet()
spin_lock_bh(&priv->wmm.ra_list_spinlock); --> Line 1432 (Lock A)
mwifiex_send_addba()
spin_lock_bh(&priv->sta_list_spinlock); --> Line 608 (Lock B)
mwifiex_process_sta_tx_pause()
spin_lock_bh(&priv->sta_list_spinlock); --> Line 398 (Lock B)
mwifiex_update_ralist_tx_pause()
spin_lock_bh(&priv->wmm.ra_list_spinlock); --> Line 941 (Lock A)
Similar report for mwifiex_process_uap_tx_pause().
While the locking expectations in this driver are a bit unclear, the
Fixed commit only intended to protect the sta_ptr, so we can drop the
lock as soon as we're done with it.
IIUC, this deadlock cannot actually happen, because command event
processing (which calls mwifiex_process_sta_tx_pause()) is
sequentialized with TX packet processing (e.g.,
mwifiex_dequeue_tx_packet()) via the main loop (mwifiex_main_process()).
But it's good not to leave this potential issue lurking.
Fixes: f0f7c2275f ("mwifiex: minor cleanups w/ sta_list_spinlock in cfg80211.c")
Cc: Douglas Anderson <dianders@chromium.org>
Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
Link: https://lore.kernel.org/linux-wireless/0e495b14-efbb-e0da-37bd-af6bd677ee2c@gmail.com/
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/YaV0pllJ5p/EuUat@google.com
This is found by Smatch static checker warning:
drivers/net/wireless/realtek/rtw89/mac80211.c:31 rtw89_ops_tx()
error: uninitialized symbol 'qsel'.
The warning is because 'qsel' isn't filled by rtw89_core_tx_write() due to
failed to write. The way to fix it is to avoid kicking off TX DMA, so add
'return' to the failure case.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211201093816.13806-1-pkshih@realtek.com
Originally, cch_by_bw recorded center channels of each available
bandwidths under current bandwidth. And the plan was to iterate
cch_by_bw as parameters to query other configurations. However,
we have not used it for the time being. Keeping it will disturb
the follow-up things, such as bandwidth 160 MHz, so we remove it
for now. If it's really needed at some point, we will redesign it.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211201080901.12125-1-pkshih@realtek.com
With wrong rtwsta->mac_id, it can't send out ack properly when we receive
assoc response occasionally. Then, it failed to connect an AP.
The cause is that we store 'sta' and use it somewhere. To correct this,
remove the variable and use mac_id in drv_priv of 'sta' or 'vif' passed
by mac80211.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211201080607.11211-1-pkshih@realtek.com
It is useful to fix the bit rate of TX packets. For example, if
someone is measuring the TX power, or debugging with the issues
of the TX throughput on the field.
To set the value of fixed rate, one should input corresponding
desc rate index (ex, 0x0b for DESC_RATE54M to fix at 54 Mbps).
Set a value larger than DESC_RATE_MAX will disable fix rate, so
the rate adaptive mechanism can resume to work.
Example,
To fix rate at MCS 1:
echo 0x0d > /sys/kernel/debug/ieee80211/phy0/rtw88/fix_rate
To not to fix rate:
echo 0xff > /sys/kernel/debug/ieee80211/phy0/rtw88/fix_rate
To know which rate was fixed at:
cat /sys/kernel/debug/ieee80211/phy0/rtw88/fix_rate
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211129020506.6273-1-pkshih@realtek.com
We used to fill in rx skbs' frequency field by mac80211's current
channel value. In some cases, mac80211 switches channel before all
rx packets have been processed. This results in incorrect bss info.
We fix this by filling in frequency field with channel index obtained
from hardware, then fix potential cck missing issue by skb's original
hw rate. After all fix is done, convert hw rate back to the supported
band rate index.
Signed-off-by: Po Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211111023706.14154-3-pkshih@realtek.com
After mt7921s got added, there are two possible build problems:
a) mt7921s does not get built at all if mt7921e is not also enabled
b) there is a link error when mt7921e is a loadable module, but mt7921s
configured as built-in:
ERROR: modpost: "mt7921_mac_sta_add" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mac_sta_assoc" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mac_sta_remove" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mac_write_txwi" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mcu_drv_pmctrl" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mcu_fill_message" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mcu_parse_response" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_ops" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_queue_rx_skb" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_update_channel" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
Fix both by making sure that Kbuild enters the subdirectory when
either one is enabled.
Fixes: 48fab5bbef ("mt76: mt7921: introduce mt7921s support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211204173848.873293-3-arnd@kernel.org
