- 09 Dec, 2022 9 commits
-
-
Ryder Lee authored
Check return value of mt7996_mcu_get_eeprom_free_block() first before accessing free_block_num. Fixes: 98686cd2 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Signed-off-by:
Ryder Lee <ryder.lee@mediatek.com> Signed-off-by:
Felix Fietkau <nbd@nbd.name>
-
Ryder Lee authored
Check return value of mt7915_mcu_get_eeprom_free_block() first before accessing free_block_num. Fixes: bbc1d415 ("mt76: mt7915: add default calibrated data support") Signed-off-by:
-
Ryder Lee authored
The current flow confuses coverity check that leads to false reporting, so split the offs[] into two pieces according to chipset revision to silence coverity tool. Signed-off-by:
-
Ryder Lee authored
This code is supposed to set a u32 value, but casting will not work on big endian systems. Reported-by:
coverity-bot <keescook+coverity-bot@chromium.org> Addresses-Coverity-ID: 1527816 ("Integer handling issues") Fixes: 98686cd2 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Signed-off-by:
-
Ryder Lee authored
Coverity message: using tainted "r->band_idx" variable as an index into an array "(*dev).mt76.phys". Reported-by:
-
Ryder Lee authored
Coverity message: using tainted "hdr->band" variable as an index into an array "(*dev).mt76.phys". Reported-by:
-
Ryder Lee authored
Coverity message: variable "buf" going out of scope leaks the storage. Reported-by:
-
Deren Wu authored
SDIO may need addtional 511 bytes to align bus operation. If the tailroom of this skb is not big enough, we would access invalid memory region. For low level operation, increase skb size to keep valid memory access in SDIO host. Error message: [69.951] BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0xe9/0x1a0 [69.951] Read of size 64 at addr ffff88811c9cf000 by task kworker/u16:7/451 [69.951] CPU: 4 PID: 451 Comm: kworker/u16:7 Tainted: G W OE 6.1.0-rc5 #1 [69.951] Workqueue: kvub300c vub300_cmndwork_thread [vub300] [69.951] Call Trace: [69.951] <TASK> [69.952] dump_stack_lvl+0x49/0x63 [69.952] print_report+0x171/0x4a8 [69.952] kasan_report+0xb4/0x130 [69.952] kasan_check_range+0x149/0x1e0 [69.952] memcpy+0x24/0x70 [69.952] sg_copy_buffer+0xe9/0x1a0 [69.952] sg_copy_to_buffer+0x12/0x20 [69.952] __command_write_data.isra.0+0x23c/0xbf0 [vub300] [69.952] vub300_cmndwork_thread+0x17f3/0x58b0 [vub300] [69.952] process_one_work+0x7ee/0x1320 [69.952] worker_thread+0x53c/0x1240 [69.952] kthread+0x2b8/0x370 [69.952] ret_from_fork+0x1f/0x30 [69.952] </TASK> [69.952] Allocated by task 854: [69.952] kasan_save_stack+0x26/0x50 [69.952] kasan_set_track+0x25/0x30 [69.952] kasan_save_alloc_info+0x1b/0x30 [69.952] __kasan_kmalloc+0x87/0xa0 [69.952] __kmalloc_node_track_caller+0x63/0x150 [69.952] kmalloc_reserve+0x31/0xd0 [69.952] __alloc_skb+0xfc/0x2b0 [69.952] __mt76_mcu_msg_alloc+0xbf/0x230 [mt76] [69.952] mt76_mcu_send_and_get_msg+0xab/0x110 [mt76] [69.952] __mt76_mcu_send_firmware.cold+0x94/0x15d [mt76] [69.952] mt76_connac_mcu_send_ram_firmware+0x415/0x54d [mt76_connac_lib] [69.952] mt76_connac2_load_ram.cold+0x118/0x4bc [mt76_connac_lib] [69.952] mt7921_run_firmware.cold+0x2e9/0x405 [mt7921_common] [69.952] mt7921s_mcu_init+0x45/0x80 [mt7921s] [69.953] mt7921_init_work+0xe1/0x2a0 [mt7921_common] [69.953] process_one_work+0x7ee/0x1320 [69.953] worker_thread+0x53c/0x1240 [69.953] kthread+0x2b8/0x370 [69.953] ret_from_fork+0x1f/0x30 [69.953] The buggy address belongs to the object at ffff88811c9ce800 which belongs to the cache kmalloc-2k of size 2048 [69.953] The buggy address is located 0 bytes to the right of 2048-byte region [ffff88811c9ce800, ffff88811c9cf000) [69.953] Memory state around the buggy address: [69.953] ffff88811c9cef00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [69.953] ffff88811c9cef80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [69.953] >ffff88811c9cf000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [69.953] ^ [69.953] ffff88811c9cf080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [69.953] ffff88811c9cf100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Fixes: 764dee47 ("mt76: sdio: move common code in mt76_sdio module") Suggested-by:Lorenzo Bianconi <lorenzo@kernel.org> Tested-by:
YN Chen <YN.Chen@mediatek.com> Signed-off-by:
Deren Wu <deren.wu@mediatek.com> Signed-off-by:
-
Wang Yufen authored
Add missing of_node_put() after of_reserved_mem_lookup() Fixes: 99ad32a4 ("mt76: mt7915: add support for MT7986") Signed-off-by:
Wang Yufen <wangyufen@huawei.com> Signed-off-by:
-
- 08 Dec, 2022 31 commits
-
-
Kalle Valo authored
Merge tag 'iwlwifi-next-for-kalle-2022-12-07' of http://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next An additional set of patches intended for v6.2. It contains: * Adjustments for the new HW * Adjustments for FW API update * A few small fixes and cleanups * Improvements for debug dumps mechanism
-
Jun ASAKA authored
Fixing "Path A RX IQK failed" and "Path B RX IQK failed" issues for rtl8192eu chips by replacing the arguments with the ones in the updated official driver as shown below. 1. https://github.com/Mange/rtl8192eu-linux-driver 2. vendor driver version: 5.6.4 Signed-off-by:
Jun ASAKA <JunASAKA@zzy040330.moe> Reviewed-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221207033926.11777-1-JunASAKA@zzy040330.moe
-
Peter Kosyh authored
Commit 40ca1882 ("rtlwifi: btcoex: 23b 1ant: fine tune for wifi not connected") introduced never executed branches. Compile test only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by:
Peter Kosyh <pkosyh@yandex.ru> Acked-by:
-
Peter Kosyh authored
Extra rtl_get_bbreg() call looks like redundant reading. The read has already been done in the "else" branch. Compile test only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by:
-
Sascha Hauer authored
Add support for the rtw8723du chipset based on https://github.com/ulli-kroll/rtw88-usb.gitSigned-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Sascha Hauer authored
Add support for the rtw8822cu chipset based on https://github.com/ulli-kroll/rtw88-usb.gitSigned-off-by:
-
Sascha Hauer authored
Add support for the rtw8822bu chipset based on https://github.com/ulli-kroll/rtw88-usb.gitSigned-off-by:
-
Sascha Hauer authored
Add support for the rtw8821cu chipset based on https://github.com/ulli-kroll/rtw88-usb.gitSigned-off-by:
-
Sascha Hauer authored
Add the common bits and pieces to add USB support to the RTW88 driver. This is based on https://github.com/ulli-kroll/rtw88-usb.git which itself is first written by Neo Jou. Signed-off-by:
neo_jou <neo_jou@realtek.com> Signed-off-by:
Hans Ulli Kroll <linux@ulli-kroll.de> Signed-off-by:
-
Sascha Hauer authored
The driver uses ieee80211_iterate_active_interfaces_atomic() and ieee80211_iterate_stations_atomic() in several places and does register accesses in the iterators. This doesn't cope with upcoming USB support as registers can only be accessed non-atomically. Split these into a two stage process: First use the atomic iterator functions to collect all active interfaces or stations on a list, then iterate over the list non-atomically and call the iterator on each entry. Signed-off-by:
-
Sascha Hauer authored
coex->mutex is used in rtw_coex_info_request() only. Most callers of this function hold rtwdev->mutex already, except for one callsite in the debugfs code. The debugfs code alone doesn't justify the extra lock, so acquire rtwdev->mutex there as well and drop the now unnecessary spinlock. Signed-off-by:
-
Sascha Hauer authored
The h2c.lock spinlock is used in rtw_fw_send_h2c_command() and rtw_fw_send_h2c_packet(). Most callers call this with rtwdev->mutex held, except from one callsite in the debugfs code. The debugfs code alone doesn't justify the extra lock, so acquire rtwdev->mutex in debugfs and drop the now unnecessary spinlock. Signed-off-by:
-
Sascha Hauer authored
The rtwdev->rf_lock spinlock protects the rf register accesses in rtw_read_rf() and rtw_write_rf(). Most callers of these functions hold rtwdev->mutex already with the exception of the callsites in the debugfs code. The debugfs code doesn't justify an extra lock, so acquire the mutex there as well before calling rf register accessors and drop the now unnecessary spinlock. Signed-off-by:
-
Sascha Hauer authored
rtw_fw_beacon_filter_config() is called once with rtwdev->mutex held and once without the mutex held. Call it consistently with rtwdev->mutex held. Signed-off-by:
-
Sascha Hauer authored
It's confusing to read two different firmware versions in the syslog for the same device: rtw_8822cu 2-1:1.2: Firmware version 9.9.4, H2C version 15 rtw_8822cu 2-1:1.2: Firmware version 9.9.11, H2C version 15 Print the firmware type in this message to make clear these are really two different firmwares for different purposes: rtw_8822cu 1-1.4:1.2: WOW Firmware version 9.9.4, H2C version 15 rtw_8822cu 1-1.4:1.2: Firmware version 9.9.11, H2C version 15 Signed-off-by:
-
Po-Hao Huang authored
To support multiple vifs, fw need more information of each role. Send this info to make things work as expected. Signed-off-by:
Po-Hao Huang <phhuang@realtek.com> Signed-off-by:
-
Po-Hao Huang authored
Remove according vifs from list if we couldn't set this interface up. Otherwise the rtwvif_list could contain unreferenced objects. Signed-off-by:
-
Po-Hao Huang authored
Disable hardware beacon related functions when ap stops. So hardware won't transmit beacons while interface is already removed. Signed-off-by:
-
Po-Hao Huang authored
If the interface is in AP/P2P GO mode, we adjust the TSF with random offset to avoid TBTT of different vifs to overlap and collide. For every new interface added, we adjust the value and resync for all interfaces. Signed-off-by:
-
Zong-Zhe Yang authored
Under some condition, we now have to do early request full firmware when rtw89_early_fw_feature_recognize(). In this case, we can avoid requesting full firmware twice during probing driver. So, we pass out full firmware from rtw89_early_fw_feature_recognize() if it's requested successfully. And then, if firmware is settled, we have no need to request full firmware again during normal initizating flow. Setting firmware flow is updated to be as the following. platform | early recognizing | normally initizating ----------------------------------------------------------------------- deny reading | request full FW | (no more FW requesting) partial file | | (obtain FW from early pahse) ----------------------------------------------------------------------- able to read | request partial FW | async request full FW partial file | (quite small chunk) | Signed-off-by:
Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
-
Zong-Zhe Yang authored
Kernel logs on platform enabling SECURITY_LOADPIN_ENFORCE ------ ``` LoadPin: firmware old-api-denied obj=<unknown> pid=810 cmdline="modprobe -q -- rtw89_8852ce" rtw89_8852ce 0000:01:00.0: loading /lib/firmware/rtw89/rtw8852c_fw.bin failed with error -1 rtw89_8852ce 0000:01:00.0: Direct firmware load for rtw89/rtw8852c_fw.bin failed with error -1 rtw89_8852ce 0000:01:00.0: failed to early request firmware: -1 ``` Trace ------ ``` request_partial_firmware_into_buf() > _request_firmware() >> fw_get_filesystem_firmware() >>> kernel_read_file_from_path_initns() >>>> kernel_read_file() >>>>> security_kernel_read_file() // It will iterate enabled LSMs' hooks for kernel_read_file. // With loadpin, it hooks loadpin_read_file. ``` If SECURITY_LOADPIN_ENFORCE is enabled, doing kernel_read_file() on partial files will be denied and return -EPERM (-1). Then, the outer API based on it, e.g. request_partial_firmware_into_buf(), will get the error. In the case, we cannot get the firmware stuffs right, even though there might be no error other than a permission issue on reading a partial file. So we have to request full firmware if SECURITY_LOADPIN_ENFORCE is enabled. It makes us still have a chance to do early firmware work on this kind of platforms. Signed-off-by:
-
Wang Yufen authored
Fix to return a negative error code instead of 0 when brcmf_chip_set_active() fails. In addition, change the return value for brcmf_pcie_exit_download_state() to keep consistent. Fixes: d380ebc9 ("brcmfmac: rename chip download functions") Signed-off-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
-
Bitterblue Smith authored
The ra_report struct is used for reporting the TX rate via sta_statistics. The code which fills it out is duplicated in two places, and the RTL8188EU will need it in a third place. Move this code into a new function rtl8xxxu_update_ra_report. Signed-off-by:
Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by:
-
Bitterblue Smith authored
The gen 2 chips RTL8192EU and RTL8188FU periodically send the driver reports about the TX rate, and the driver passes these reports to sta_statistics. The reports from RTL8192EU may or may not include the channel width. The reports from RTL8188FU do not include it. Only access the c2h->ra_report.bw field if the report (skb) is big enough. The other problem fixed here is that the code was actually never changing the channel width initially reported by rtl8xxxu_bss_info_changed because the value of RATE_INFO_BW_20 is 0. Fixes: 0985d3a4 ("rtl8xxxu: Feed current txrate information for mac80211") Signed-off-by:
-
Bitterblue Smith authored
This struct is used to access a sequence of bytes received from the wifi chip. It must not have any padding bytes between the members. This doesn't change anything on my system, possibly because currently none of the members need more than byte alignment. Fixes: b2b43b78 ("rtl8xxxu: Initial functionality to handle C2H events for 8723bu") Signed-off-by:
-
Arend van Spriel authored
Using a namespace variant to make clear it is only intended to be used by the vendor-specific modules. The symbol will only truly export the symbols when the driver and consequently the vendor-specific part are built as kernel modules. Reviewed-by:
Hante Meuleman <hante.meuleman@broadcom.com> Reviewed-by:
Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by:
Franky Lin <franky.lin@broadcom.com> Signed-off-by:
-
Arend van Spriel authored
Upon probe the driver determines the vendor supporting the device. Expose this information in the revinfo debugfs file. Reviewed-by:
-
Arend van Spriel authored
Broadcom BCA division develops its own firmware api and as such will likely diverge over time (or already has). Add support for handling this. Reviewed-by:
-
Arend van Spriel authored
Cypress uses the brcmfmac driver and releases firmware which will likely diverge over time (or already has). So adding support for handling that. Reviewed-by:
-
Arend van Spriel authored
The driver is being used by multiple vendors who develop the firmware api independently. So far the firmware api as used by the driver has not diverged (yet). This change adds framework for supporting multiple firmware apis. The vendor-specific support code has to provide a number of callback operations. Right now it is only attach and detach callbacks so no real functionality as the api is still common. This code only adds WCC variant anyway, which is selected for all devices right now. The vendor-specific part will be built in a separate module when the driver is configured to be built as a module through Kconfig, ie. when CONFIG_BRCMFMAC=m. Reviewed-by:
-
Arend van Spriel authored
In order to determine the vendor that released a firmware image for a specific device, the device table now sets the vendor identifier in driver info and it is stored in struct brcmf_bus::fwvid during probe. Reviewed-by:
-
