- 22 Dec, 2022 7 commits
-
-
Zhengchao Shao authored
After the DMA buffer is mapped to a physical address, address is stored in pktids in brcmf_msgbuf_alloc_pktid(). Then, pktids is parsed in brcmf_msgbuf_get_pktid()/brcmf_msgbuf_release_array() to obtain physaddr and later unmap the DMA buffer. But when count is always equal to pktids->array_size, physaddr isn't stored in pktids and the DMA buffer will not be unmapped anyway. Fixes: 9a1bb602 ("brcmfmac: Adding msgbuf protocol.") Signed-off-by:
Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221207013114.1748936-1-shaozhengchao@huawei.com
-
Zhang Changzhong authored
The brcmf_netdev_start_xmit() returns NETDEV_TX_OK without freeing skb in case of pskb_expand_head() fails, add dev_kfree_skb() to fix it. Compile tested only. Fixes: 270a6c1f ("brcmfmac: rework headroom check in .start_xmit()") Signed-off-by:
Zhang Changzhong <zhangchangzhong@huawei.com> Reviewed-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
-
Jisoo Jang authored
This patch fixes a stack-out-of-bounds read in brcmfmac that occurs when 'buf' that is not null-terminated is passed as an argument of strsep() in brcmf_c_preinit_dcmds(). This buffer is filled with a firmware version string by memcpy() in brcmf_fil_iovar_data_get(). The patch ensures buf is null-terminated. Found by a modified version of syzkaller. [ 47.569679][ T1897] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43236b for chip BCM43236/3 [ 47.582839][ T1897] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 47.601565][ T1897] ================================================================== [ 47.602574][ T1897] BUG: KASAN: stack-out-of-bounds in strsep+0x1b2/0x1f0 [ 47.603447][ T1897] Read of size 1 at addr ffffc90001f6f000 by task kworker/0:2/1897 [ 47.604336][ T1897] [ 47.604621][ T1897] CPU: 0 PID: 1897 Comm: kworker/0:2 Tainted: G O 5.14.0+ #131 [ 47.605617][ T1897] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 47.606907][ T1897] Workqueue: usb_hub_wq hub_event [ 47.607453][ T1897] Call Trace: [ 47.607801][ T1897] dump_stack_lvl+0x8e/0xd1 [ 47.608295][ T1897] print_address_description.constprop.0.cold+0xf/0x334 [ 47.609009][ T1897] ? strsep+0x1b2/0x1f0 [ 47.609434][ T1897] ? strsep+0x1b2/0x1f0 [ 47.609863][ T1897] kasan_report.cold+0x83/0xdf [ 47.610366][ T1897] ? strsep+0x1b2/0x1f0 [ 47.610882][ T1897] strsep+0x1b2/0x1f0 [ 47.611300][ T1897] ? brcmf_fil_iovar_data_get+0x3a/0xf0 [ 47.611883][ T1897] brcmf_c_preinit_dcmds+0x995/0xc40 [ 47.612434][ T1897] ? brcmf_c_set_joinpref_default+0x100/0x100 [ 47.613078][ T1897] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 47.613662][ T1897] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 47.614208][ T1897] ? lock_acquire+0x19d/0x4e0 [ 47.614704][ T1897] ? find_held_lock+0x2d/0x110 [ 47.615236][ T1897] ? brcmf_usb_deq+0x1a7/0x260 [ 47.615741][ T1897] ? brcmf_usb_rx_fill_all+0x5a/0xf0 [ 47.616288][ T1897] brcmf_attach+0x246/0xd40 [ 47.616758][ T1897] ? wiphy_new_nm+0x1703/0x1dd0 [ 47.617280][ T1897] ? kmemdup+0x43/0x50 [ 47.617720][ T1897] brcmf_usb_probe+0x12de/0x1690 [ 47.618244][ T1897] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 [ 47.618901][ T1897] usb_probe_interface+0x2aa/0x760 [ 47.619429][ T1897] ? usb_probe_device+0x250/0x250 [ 47.619950][ T1897] really_probe+0x205/0xb70 [ 47.620435][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.621048][ T1897] __driver_probe_device+0x311/0x4b0 [ 47.621595][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.622209][ T1897] driver_probe_device+0x4e/0x150 [ 47.622739][ T1897] __device_attach_driver+0x1cc/0x2a0 [ 47.623287][ T1897] bus_for_each_drv+0x156/0x1d0 [ 47.623796][ T1897] ? bus_rescan_devices+0x30/0x30 [ 47.624309][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 47.624907][ T1897] ? trace_hardirqs_on+0x46/0x160 [ 47.625437][ T1897] __device_attach+0x23f/0x3a0 [ 47.625924][ T1897] ? device_bind_driver+0xd0/0xd0 [ 47.626433][ T1897] ? kobject_uevent_env+0x287/0x14b0 [ 47.627057][ T1897] bus_probe_device+0x1da/0x290 [ 47.627557][ T1897] device_add+0xb7b/0x1eb0 [ 47.628027][ T1897] ? wait_for_completion+0x290/0x290 [ 47.628593][ T1897] ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0 [ 47.629249][ T1897] usb_set_configuration+0xf59/0x16f0 [ 47.629829][ T1897] usb_generic_driver_probe+0x82/0xa0 [ 47.630385][ T1897] usb_probe_device+0xbb/0x250 [ 47.630927][ T1897] ? usb_suspend+0x590/0x590 [ 47.631397][ T1897] really_probe+0x205/0xb70 [ 47.631855][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.632469][ T1897] __driver_probe_device+0x311/0x4b0 [ 47.633002][ T1897] ? usb_generic_driver_match+0x75/0x90 [ 47.633573][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.634170][ T1897] driver_probe_device+0x4e/0x150 [ 47.634703][ T1897] __device_attach_driver+0x1cc/0x2a0 [ 47.635248][ T1897] bus_for_each_drv+0x156/0x1d0 [ 47.635748][ T1897] ? bus_rescan_devices+0x30/0x30 [ 47.636271][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 47.636881][ T1897] ? trace_hardirqs_on+0x46/0x160 [ 47.637396][ T1897] __device_attach+0x23f/0x3a0 [ 47.637904][ T1897] ? device_bind_driver+0xd0/0xd0 [ 47.638426][ T1897] ? kobject_uevent_env+0x287/0x14b0 [ 47.638985][ T1897] bus_probe_device+0x1da/0x290 [ 47.639512][ T1897] device_add+0xb7b/0x1eb0 [ 47.639977][ T1897] ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0 [ 47.640612][ T1897] ? kfree+0x14a/0x6b0 [ 47.641055][ T1897] ? __usb_get_extra_descriptor+0x116/0x160 [ 47.641679][ T1897] usb_new_device.cold+0x49c/0x1029 [ 47.642245][ T1897] ? hub_disconnect+0x450/0x450 [ 47.642756][ T1897] ? rwlock_bug.part.0+0x90/0x90 [ 47.643273][ T1897] ? _raw_spin_unlock_irq+0x24/0x30 [ 47.643822][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 47.644445][ T1897] hub_event+0x1c98/0x3950 [ 47.644939][ T1897] ? hub_port_debounce+0x2e0/0x2e0 [ 47.645467][ T1897] ? check_irq_usage+0x861/0xf20 [ 47.645975][ T1897] ? drain_workqueue+0x280/0x360 [ 47.646506][ T1897] ? lock_release+0x640/0x640 [ 47.646994][ T1897] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 47.647572][ T1897] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 47.648111][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 47.648735][ T1897] process_one_work+0x92b/0x1460 [ 47.649262][ T1897] ? pwq_dec_nr_in_flight+0x330/0x330 [ 47.649816][ T1897] ? rwlock_bug.part.0+0x90/0x90 [ 47.650336][ T1897] worker_thread+0x95/0xe00 [ 47.650830][ T1897] ? __kthread_parkme+0x115/0x1e0 [ 47.651361][ T1897] ? process_one_work+0x1460/0x1460 [ 47.651904][ T1897] kthread+0x3a1/0x480 [ 47.652329][ T1897] ? set_kthread_struct+0x120/0x120 [ 47.652878][ T1897] ret_from_fork+0x1f/0x30 [ 47.653370][ T1897] [ 47.653608][ T1897] [ 47.653848][ T1897] addr ffffc90001f6f000 is located in stack of task kworker/0:2/1897 at offset 512 in frame: [ 47.654891][ T1897] brcmf_c_preinit_dcmds+0x0/0xc40 [ 47.655442][ T1897] [ 47.655690][ T1897] this frame has 4 objects: [ 47.656151][ T1897] [48, 56) 'ptr' [ 47.656159][ T1897] [80, 148) 'revinfo' [ 47.656534][ T1897] [192, 210) 'eventmask' [ 47.656953][ T1897] [256, 512) 'buf' [ 47.657410][ T1897] [ 47.658035][ T1897] Memory state around the buggy address: [ 47.658743][ T1897] ffffc90001f6ef00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 47.659577][ T1897] ffffc90001f6ef80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 47.660394][ T1897] >ffffc90001f6f000: f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 [ 47.661199][ T1897] ^ [ 47.661625][ T1897] ffffc90001f6f080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 47.662455][ T1897] ffffc90001f6f100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 [ 47.663318][ T1897] ================================================================== [ 47.664147][ T1897] Disabling lock debugging due to kernel taint Reported-by:
Dokyung Song <dokyungs@yonsei.ac.kr> Reported-by:
Jisoo Jang <jisoo.jang@yonsei.ac.kr> Reported-by:
Minsuk Kang <linuxlovemin@yonsei.ac.kr> Signed-off-by:
-
Wang Yufen authored
Fault injection test reports this issue: kernel BUG at net/core/dev.c:10731! invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI Call Trace: <TASK> wilc_netdev_ifc_init+0x19f/0x220 [wilc1000 884bf126e9e98af6a708f266a8dffd53f99e4bf5] wilc_cfg80211_init+0x30c/0x380 [wilc1000 884bf126e9e98af6a708f266a8dffd53f99e4bf5] wilc_bus_probe+0xad/0x2b0 [wilc1000_spi 1520a7539b6589cc6cde2ae826a523a33f8bacff] spi_probe+0xe4/0x140 really_probe+0x17e/0x3f0 __driver_probe_device+0xe3/0x170 driver_probe_device+0x49/0x120 The root case here is alloc_ordered_workqueue() fails, but cfg80211_unregister_netdevice() or unregister_netdev() not be called in error handling path. To fix add unregister_netdev goto lable to add the unregister operation in error handling path. Fixes: 09ed8bfc ("wilc1000: Rename workqueue from "WILC_wq" to "NETDEV-wq"") Signed-off-by:
Wang Yufen <wangyufen@huawei.com> Signed-off-by:
-
Zhang Changzhong authored
The wilc_mac_xmit() returns NETDEV_TX_OK without freeing skb, add dev_kfree_skb() to fix it. Compile tested only. Fixes: c5c77ba1 ("staging: wilc1000: Add SDIO/SPI 802.11 driver") Signed-off-by:
-
Zhengchao Shao authored
In the error path of ipw_wdev_init(), exception value is returned, and the memory applied for in the function is not released. Also the memory is not released in ipw_pci_probe(). As a result, memory leakage occurs. So memory release needs to be added to the error path of ipw_wdev_init(). Fixes: a3caa99e ("libipw: initiate cfg80211 API conversion (v2)") Signed-off-by:
-
Yang Yingliang authored
It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead. The difference between them is free reason, dev_kfree_skb_irq() means the SKB is dropped in error and dev_consume_skb_irq() means the SKB is consumed in normal. In this case, dev_kfree_skb() is called to free and drop the SKB when it's reset, so replace it with dev_kfree_skb_irq(). Compile tested only. Fixes: 43f66a6c ("Add ipw2200 wireless driver.") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
- 21 Dec, 2022 17 commits
-
-
Jun ASAKA authored
Fixing transmission failure which results in "authentication with ... timed out". This can be fixed by disable the REG_TXPAUSE. Signed-off-by:
Jun ASAKA <JunASAKA@zzy040330.moe> Reviewed-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
-
Bitterblue Smith authored
Copied from the newer vendor driver, v5.2.2.4. Signed-off-by:
Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by:
-
Jes Sorensen authored
This chip is found in cheap USB devices from TP-Link, D-Link, etc. Features: 2.4 GHz, b/g/n mode, 1T1R, 150 Mbps. Chip versions older than "I cut" need software rate control. That will be in the next commit. Until then MCS7 is used for all data frames. The "I cut" chips are not supported. They require different firmware and initialisation tables. Support can be added if someone has the hardware to test it. Co-developed-by:
Andrea Merello <andrea.merello@gmail.com> Signed-off-by:
Taehee Yoo <ap420073@gmail.com> Signed-off-by:
Jes Sorensen <Jes.Sorensen@gmail.com> Co-developed-by:
-
Bitterblue Smith authored
Define the constants CCK_AGC_RPT_LNA_IDX_MASK and CCK_AGC_RPT_VGA_IDX_MASK instead of using the same literals in four places. And get the bits from cck_agc_rpt using u8_get_bits(). It's a cosmetic change only. Signed-off-by:
-
Bitterblue Smith authored
And pass const char* to it. Signed-off-by:
-
Bitterblue Smith authored
Every chip family except RTL8723AU has a copy of the efuse dumping code. Remove this and dump the efuse from a single place using a new function rtl8xxxu_dump_efuse(). Also, use print_hex_dump() to print the efuse instead of a loop and dev_info(). It shows the ASCII interpretation of the bytes, which is nice. Signed-off-by:
-
Chih-Kang Chang authored
Some hardware modules don't have good RF characteristic as regular. It could have RF PA characteristic that current code doesn't handle properly, and it runs into wrong DPK flow that doesn't complete DPK resulting in bad EVM. Signed-off-by:
Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by:
-
Po-Hao Huang authored
Reduce dwell time to improve scan duration in 6 GHz. This is required for scan requests that does not include RNR parsing and does full channel scan. Signed-off-by:
Po-Hao Huang <phhuang@realtek.com> Signed-off-by:
-
Eric Huang authored
BSS color mapping register is different per IC, therefore, move this register to chip_info and update the setting function. Without this patch, wrong BSS color causes behavior abnormal, especially DL-OFDMA. Signed-off-by:
Eric Huang <echuang@realtek.com> Signed-off-by:
-
Ching-Te Ku authored
In order to make different version of TDMA and coming update in the future can all work well, use BTC format version to replace chip_id, because format could change for specific chip_id. Signed-off-by:
Ching-Te Ku <ku920601@realtek.com> Signed-off-by:
-
Ching-Te Ku authored
Change the checking logic to switch case. Make the code more readable. There are more feature including to common code, in order to commit the following version of the features, switch case will make the logic more clearly. This patch did not change logic. Signed-off-by:
-
Ching-Te Ku authored
Wi-Fi firmware update AFH report feature to version 2. If there is BT BLE device connect to DUT, the mechanism will send H2C to request BT BLE channel map, it will help to debug. Signed-off-by:
-
Ching-Te Ku authored
The different version use different bit definition to enable firmware report. WiFi firmware will report information from Bluetooth firmware or some Wi-Fi firmware mechanism/status to driver by these bits. To solve the difference, add a function to map bitmap and versions. Signed-off-by:
-
Ching-Te Ku authored
Ask WiFi firmware to send Bluetooth version report when we want to show Bluetooth debug info. If there is no request for debug log, driver will not enable the report. This modification can save some C2H/H2C resources. Signed-off-by:
-
Ping-Ke Shih authored
Previous patch has added format version derived from firmware version. Use the format version, and remove constant version number from chip_info. Signed-off-by:
-
Ping-Ke Shih authored
Originally, each chip maintains its own format version followed firmware it uses. As new chip is added, firmware changes format of exchange messages to have rich information to handle more conditions. When old chip is going to upgrade firmware, it could use new format and driver needs to maintain compatibility with old firmware. So, add this version array to achieve this goal. Signed-off-by:
-
https://github.com/nbd168/wirelessKalle Valo authored
mt76 patches for 6.2 - fixes - per-PHY LED support
-
- 14 Dec, 2022 15 commits
-
-
Li Zetao authored
There is a global-out-of-bounds reported by KASAN: BUG: KASAN: global-out-of-bounds in _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae] Read of size 1 at addr ffffffffa0773c43 by task NetworkManager/411 CPU: 6 PID: 411 Comm: NetworkManager Tainted: G D 6.1.0-rc8+ #144 e15588508517267d37 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), Call Trace: <TASK> ... kasan_report+0xbb/0x1c0 _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae] rtl8821ae_phy_bb_config.cold+0x346/0x641 [rtl8821ae] rtl8821ae_hw_init+0x1f5e/0x79b0 [rtl8821ae] ... </TASK> The root cause of the problem is that the comparison order of "prate_section" in _rtl8812ae_phy_set_txpower_limit() is wrong. The _rtl8812ae_eq_n_byte() is used to compare the first n bytes of the two strings from tail to head, which causes the problem. In the _rtl8812ae_phy_set_txpower_limit(), it was originally intended to meet this requirement by carefully designing the comparison order. For example, "pregulation" and "pbandwidth" are compared in order of length from small to large, first is 3 and last is 4. However, the comparison order of "prate_section" dose not obey such order requirement, therefore when "prate_section" is "HT", when comparing from tail to head, it will lead to access out of bounds in _rtl8812ae_eq_n_byte(). As mentioned above, the _rtl8812ae_eq_n_byte() has the same function as strcmp(), so just strcmp() is enough. Fix it by removing _rtl8812ae_eq_n_byte() and use strcmp() barely. Although it can be fixed by adjusting the comparison order of "prate_section", this may cause the value of "rate_section" to not be from 0 to 5. In addition, commit "21e4b072" not only moved driver from staging to regular tree, but also added setting txpower limit function during the driver config phase, so the problem was introduced by this commit. Fixes: 21e4b072 ("rtlwifi: rtl8821ae: Move driver from staging to regular tree") Signed-off-by:
Li Zetao <lizetao1@huawei.com> Acked-by:
-
Ping-Ke Shih authored
RX DCK stands for RX DC calibration that affects CCA, so abnormal calibration values resulted from calibration failure can cause TX get stuck. To solve this, redo calibration if result is bad (over thresholds). When retry count is over, do recovery that sets high gain fields of RX DCK results from low gain fields. Signed-off-by:
-
Ping-Ke Shih authored
Some DPK settings are wrong, and causes bad TX performance occasionally. So, fix them by internal suggestions. Fixes: da4cea16 ("rtw89: 8852c: rfk: add DPK") Signed-off-by:
-
Ping-Ke Shih authored
After filling calibration parameters, set BIT(0) to enable the hardware circuit, but original set incorrect bit that affects a little TX performance. Fixes: 76599a8d ("rtw89: 8852c: rfk: add DACK") Signed-off-by:
-
Ping-Ke Shih authored
Normally, system image should ensure firmware integrity, but we provide an advance feature to ensure this by security section along with firmware. To enable this feature, custom ID is programmed into efuse, and driver will download proper security section to firmware. Since I don't have this kind hardware modules on hand yet, but new format is used by newer firmware. Therefore, I prepare this patch in advance to consider size of security section as a factor of checking rule of firmware size, but don't actually download security section to firmware. This patch is backward compatible, so it will be safe to have this change before adding an new format firmware to linux-firmware repository. Signed-off-by:
-
Ping-Ke Shih authored
ER (Extended Range) SU is to have a larger coverage. We set this as a RA capability, and then firmware can choose ER SU to transmit packets to reception at cell edge. For 8852C, it needs to fill this capability in TXWD, so update rtw89_build_txwd_info0_v1(). Signed-off-by:
-
Yang Yingliang authored
It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead. The difference between them is free reason, dev_kfree_skb_irq() means the SKB is dropped in error and dev_consume_skb_irq() means the SKB is consumed in normal. In this case, dev_kfree_skb() is called to free and drop the SKB when it's shutdown, so replace it with dev_kfree_skb_irq(). Compile tested only. Fixes: 26f1fad2 ("New driver: rtl8xxxu (mac80211)") Signed-off-by:
-
Bitterblue Smith authored
Just because priv->cck_agc_report_type is only one bit doesn't mean it works like a bool. The value assigned to it loses all bits except bit 0, so only assign 0 or 1 to it. This affects the RTL8192EU, but rtl8xxxu already can't connect to any networks with this chip, so it probably didn't bother anyone. Fixes: 2ad2a813 ("wifi: rtl8xxxu: Fix the CCK RSSI calculation") Signed-off-by:
-
Bitterblue Smith authored
Just because priv->pi_enabled is only one bit doesn't mean it works like a bool. The value assigned to it loses all bits except bit 0, so only assign 0 or 1 to it. This affects the RTL8188FU, but fixing the assignment didn't make a difference for my device. Fixes: c888183b ("wifi: rtl8xxxu: Support new chip RTL8188FU") Signed-off-by:
-
Zhengchao Shao authored
When kfifo_alloc() failed in lbs_init_adapter(), cmd buffer is not released. Add free memory to processing error path. Fixes: 7919b89c ("libertas: convert libertas driver to use an event/cmdresp queue") Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
-
Yang Yingliang authored
It is not allowed to call consume_skb() from hardware interrupt context or with interrupts being disabled. So replace dev_kfree_skb() with dev_consume_skb_irq() under spin_lock_irqsave(). Compile tested only. Fixes: 4bc85c13 ("Revert "iwlwifi: split the drivers for agn and legacy devices 3945/4965"") Signed-off-by:
Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by:
-
Yang Yingliang authored
It is not allowed to call kfree_skb() from hardware interrupt context or with interrupts being disabled. All the SKBs have been dequeued from the old queue, so it's safe to enqueue these SKBs to a free queue, then free them after spin_unlock_irqrestore() at once. Compile tested only. Fixes: 5c99f04f ("rtlwifi: rtl8723be: Update driver to match Realtek release of 06/28/14") Signed-off-by:
-
Yang Yingliang authored
It is not allowed to call kfree_skb() from hardware interrupt context or with interrupts being disabled. All the SKBs have been dequeued from the old queue, so it's safe to enqueue these SKBs to a free queue, then free them after spin_unlock_irqrestore() at once. Compile tested only. Fixes: 7fe3b3ab ("rtlwifi: rtl8188ee: rtl8821ae: Fix a queue locking problem") Signed-off-by:
-
Yang Yingliang authored
It is not allowed to call kfree_skb() from hardware interrupt context or with interrupts being disabled. All the SKBs have been dequeued from the old queue, so it's safe to enqueue these SKBs to a free queue, then free them after spin_unlock_irqrestore() at once. Compile tested only. Fixes: 5c99f04f ("rtlwifi: rtl8723be: Update driver to match Realtek release of 06/28/14") Signed-off-by:
-
Yuan Can authored
The coex_cb needs to be freed when rsi_create_kthread() failed in rsi_coex_attach(). Fixes: 2108df3c ("rsi: add coex support") Signed-off-by:
Yuan Can <yuancan@huawei.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
-
- 13 Dec, 2022 1 commit
-
-
Christophe JAILLET authored
vcap_alloc_rule() can't return NULL. So remove some dead-code Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/27992ffcee47fc865ce87274d6dfcffe7a1e69e0.1670873784.git.christophe.jaillet@wanadoo.frSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
