- 01 Dec, 2023 18 commits
-
-
Ilpo Järvinen authored
_rtl8821ae_clear_pci_pme_status() accesses the upper byte of the Power Management Control/Status register (PMCS) with literal 5 offset. Access the entire PMCS register using defines from pci_regs.h to improve code readability. While at it, remove the obvious comment and tweak debug prints slightly to not sound misleading. Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231124084725.12738-9-ilpo.jarvinen@linux.intel.com
-
Ilpo Järvinen authored
Add local variable pdev to shorten rtlpci->pdev. Signed-off-by:
-
Ilpo Järvinen authored
Instead of open coding the capability structure search, find the PM Capability using pci_find_capability(). While at it, rename the generic 'cap_pointer' to 'pm_cap' which makes the intent of the code more obvious. Signed-off-by:
-
Ilpo Järvinen authored
Check if PM Capability does not exists and return early which follows the usual error handling pattern. Signed-off-by:
-
Ilpo Järvinen authored
BIT(7) (PME_Status) is first checked and then set unnecessarily. Remove the unnecessary setting for the bit that is already on and adjust the comment related to it. Signed-off-by:
-
Ilpo Järvinen authored
The rtlwifi driver accesses PCIe capabilities through custom config offsets. Convert the accesses to use the normal PCIe capability accessors. Signed-off-by:
-
Ilpo Järvinen authored
The rtlwifi driver comes with custom code to write into PCIe Link Control register. RMW access for the Link Control register requires locking that is already provided by the standard PCIe capability accessors. Convert the custom RMW code writing into LNKCTL register to standard RMW capability accessors. The accesses are changed to cover the full LNKCTL register instead of touching just a single byte of the register. Fixes: 0c817338 ("rtl8192ce: Add new driver") Cc: stable@vger.kernel.org Signed-off-by:
-
Ilpo Järvinen authored
Ever since introduction in the commit 0c817338 ("rtl8192ce: Add new driver") the rtlwifi code has, according to comments, attempted to disable/enable ASPM of the upstream bridge by writing into its LNKCTL register. However, the code has never been correct because it performs the writes to the device instead of the upstream bridge. Worse yet, the offset where the PCIe capabilities reside is derived from the offset of the upstream bridge. As a result, the write will use an offset on the device that does not relate to the LNKCTL register making the ASPM disable/enable code outright dangerous. Because of those problems, there is no indication that the driver needs disable/enable ASPM on the upstream bridge. As the Capabilities offset is not correctly calculated for the write to target device's LNKCTL register, the code is not disabling/enabling device's ASPM either. Therefore, just remove the upstream bridge related ASPM disable/enable code entirely. The upstream bridge related ASPM code was the only user of the struct mp_adapter members num4bytes, pcibridge_pciehdr_offset, and pcibridge_linkctrlreg so those are removed as well. Note: This change does not remove the code related to changing the device's ASPM on purpose (which is independent of this flawed code related to upstream bridge's ASPM). Suggested-by:
Bjorn Helgaas <bhelgaas@kernel.org> Fixes: 0c817338 ("rtl8192ce: Add new driver") Fixes: 886e14b6 ("rtlwifi: Eliminate raw reads and writes from PCIe portion") Cc: stable@vger.kernel.org Signed-off-by:
-
Martin Blumenstingl authored
Lukas reports skb_over_panic errors on his Banana Pi BPI-CM4 which comes with an Amlogic A311D (G12B) SoC and a RTL8822CS SDIO wifi/Bluetooth combo card. The error he observed is identical to what has been fixed in commit e967229e ("wifi: rtw88: sdio: Check the HISR RX_REQUEST bit in rtw_sdio_rx_isr()") but that commit didn't fix Lukas' problem. Lukas found that disabling or limiting RX aggregation works around the problem for some time (but does not fully fix it). In the following discussion a few key topics have been discussed which have an impact on this problem: - The Amlogic A311D (G12B) SoC has a hardware bug in the SDIO controller which prevents DMA transfers. Instead all transfers need to go through the controller SRAM which limits transfers to 1536 bytes - rtw88 chips don't split incoming (RX) packets, so if a big packet is received this is forwarded to the host in it's original form - rtw88 chips can do RX aggregation, meaning more multiple incoming packets can be pulled by the host from the card with one MMC/SDIO transfer. This Depends on settings in the REG_RXDMA_AGG_PG_TH register (BIT_RXDMA_AGG_PG_TH limits the number of packets that will be aggregated, BIT_DMA_AGG_TO_V1 configures a timeout for aggregation and BIT_EN_PRE_CALC makes the chip honor the limits more effectively) Use multiple consecutive reads in rtw_sdio_read_port() and limit the number of bytes which are copied by the host from the card in one MMC/SDIO transfer. This allows receiving a buffer that's larger than the hosts max_req_size (number of bytes which can be transferred in one MMC/SDIO transfer). As a result of this the skb_over_panic error is gone as the rtw88 driver is now able to receive more than 1536 bytes from the card (either because the incoming packet is larger than that or because multiple packets have been aggregated). In case of an receive errors (-EILSEQ has been observed by Lukas) we need to drain the remaining data from the card's buffer, otherwise the card will return corrupt data for the next rtw_sdio_read_port() call. Fixes: 65371a3f ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets") Reported-by:
Lukas F. Hartmann <lukas@mntre.com> Closes: https://lore.kernel.org/linux-wireless/CAFBinCBaXtebixKbjkWKW_WXc5k=NdGNaGUjVE8NCPNxOhsb2g@mail.gmail.com/Suggested-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by:
Ulf Hansson <ulf.hansson@linaro.org> Acked-by:
-
Ping-Ke Shih authored
Add functions to configure HCI, DMAC (data MAC), DLE (data link engine), HFC (HCI flow control), PLE (payload engine) and etc for WiFi 7 chips. Signed-off-by:
-
Ping-Ke Shih authored
To share flow with WiFi 7 chips, abstract functions related hardware engines and their quota, so use pointer to access them. This doesn't change logic at all. Signed-off-by:
-
Ping-Ke Shih authored
WiFi 7 chips will use the same functionalities but different registers to control hardware components, so move these stuff into functions, and then we can implement these for WiFi 7 chips later. This patch doesn't change logic. Signed-off-by:
-
Zong-Zhe Yang authored
This function, currently called by WoWLAN flow, polls until specific HW queues are empty. The polling bit definitions are not totally the same between WiFi 6 and 7 chips. In addition, the check conditions are also a little different. So, we differentiate the implementations according to chip gen. Signed-off-by:
Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
-
Zong-Zhe Yang authored
In queue empty check, one group contains 32 queues. And, the two elements, wde_qempty_acq_num and wde_qempty_mgq_sel, are number of group and select of group. To avoid confusing them with queue number and queue selection, we refine their naming. (don't change logic at all) Signed-off-by:
-
Ping-Ke Shih authored
DLE stands for Double Link Engine that is used to maintain buffer page. To avoid linking to wrong pages, we check the used page size during initialization and stop driver probe if the used size is unexpected. Currently, we check the page size used by PLE (payload engine) and WDE (WiFi descriptor engine). For coming WiFi 7 chips, additional reserved size is added for BB as buffer to run LA mode, so add and check the reserved size as well. Signed-off-by:
-
Ping-Ke Shih authored
The reserved quota of DLE (data link engine) is used for processing next packet. Add this to get quota number, and then WiFi 7 chips can use them. Signed-off-by:
-
Ping-Ke Shih authored
Define 8922A buffer quota that are used by HCI control flow, payload engine, descriptor engine and etc for operation modes, such as SCC (single channel concurrence) and download firmware. Since WiFi 7 chips has more buffer classifications, add fields and struct according to design. Signed-off-by:
-
Justin Stitt authored
strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. Based on the deliberate `sizeof(dest) ... - 1` pattern we can see that both dump_info->dev_human_readable and dump_info->bus_human_readable are intended to be NUL-terminated. Moreover, since this seems to cross the file boundary let's NUL-pad to ensure no behavior change. strscpy_pad() covers both the NUL-termination and NUL-padding, let's use it. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by:
Justin Stitt <justinstitt@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
- 30 Nov, 2023 22 commits
-
-
Ping-Ke Shih authored
The wrapper of rtw89_debug() is unnecessary, so just remove it. Signed-off-by:
-
Ping-Ke Shih authored
A dynamic mechanism is usually an algorithm to adjust registers to adapt to different environment every two seconds. In field, it could get unexpected result, so we need to stop it and adjust registers manually, and then fine tune the algorithm. To stop mechanisms to assist debugging, add a debugfs entry shown as Disabled DM: 0x1 [0] DYNAMIC_EDCCA: X Signed-off-by:
-
Yi-Chen Chen authored
Add dynamic mechanism EDCCA (Energy Detection Clear Channel Assessment) in track work. Using a fixed-value threshold will make EDCCA particularly sensitive and cause failure to transmit under certain circumstances. Therefore, the threshold is dynamically adjusted to make EDCCA suitable for any situation. However, in some cases, we will adjust the EDCCA threshold to the highest level so that urgent transmissions can be performed successfully, such as scanning. Finally, in order to observe the EDCCA report in time, add the EDCCA perIC register macro and EDCCA HW report analysis. EDCCA logs can be displayed by using the EDCCA debug mask. Signed-off-by:
Yi-Chen Chen <jamie_chen@realtek.com> Signed-off-by:
-
Ping-Ke Shih authored
The coming dynamic mechanism of EDCCA adjustment will add a function to dump registers to reflect status. However, if we are not debugging the mechanism, we don't print anything, so avoid reading registers by checking debug mask to reduce IO. Signed-off-by:
-
Su Hui authored
Clang static checker warns: drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:184:49: The result of the left shift is undefined due to shifting by '32', which is greater or equal to the width of type 'u32'. [core.UndefinedBinaryOperatorResult] If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined.[1][2] For example, when using different gcc's compilation optimization options (-O0 or -O2), the result of '(u32)data << 32' is different. One is 0, the other is old value of data. Let _rtl8821ae_phy_calculate_bit_shift()'s return value less than 32 to fix this problem. Warn if bitmask is zero. [1] https://stackoverflow.com/questions/11270492/what-does-the-c-standard-say-about-bitshifting-more-bits-than-the-width-of-type [2] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf Fixes: 21e4b072 ("rtlwifi: rtl8821ae: Move driver from staging to regular tree") Signed-off-by:
Su Hui <suhui@nfschina.com> Acked-by:
-
Su Hui authored
Clang static checker warns: Value stored to 'v1' is never read [deadcode.DeadStores] Value stored to 'channel' is never read [deadcode.DeadStores] Remove them to save some place. Signed-off-by:
-
Ilpo Järvinen authored
Replace literal 0x7f with PCI_HEADER_TYPE_MASK. Signed-off-by:
-
Lukas Bulwahn authored
Commit 4b478bf6 ("wifi: libertas: drop 16-bit PCMCIA support") reworks the dependencies for config LIBERTAS, and adds alternative dependencies for USB, SDIO and SPI. The config option SDIO however does not exist in the kernel tree. It was probably intended to refer to the config option MMC, which represents "MMC/SD/SDIO card support" and is used as dependency by various other drivers that use SDIO. Fix the dependency to the config option MMC for declaring the requirement on provision of SDIO support. Fixes: 4b478bf6 ("wifi: libertas: drop 16-bit PCMCIA support") Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Ping-Ke Shih authored
Remove unnecessary wrapper of rtw_dbg(), and just call it directly. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by:
-
Yang Li authored
./drivers/net/wireless/ralink/rt2x00/rt2800lib.c:1331:47-52: WARNING: conversion to bool not needed here ./drivers/net/wireless/ralink/rt2x00/rt2800lib.c:1332:47-52: WARNING: conversion to bool not needed here Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7531Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Signed-off-by:
-
Eric Dumazet authored
syzbot was able to trigger a crash [1] in page_pool_unlist() page_pool_list() only inserts a page pool into a netdev page pool list if a netdev was set in params. Even if the kzalloc() call in page_pool_create happens to initialize pool->user.list, I chose to be more explicit in page_pool_list() adding one INIT_HLIST_NODE(). We could test in page_pool_unlist() if netdev was set, but since netdev can be changed to lo, it seems more robust to check if pool->user.list is hashed before calling hlist_del(). [1] Illegal XDP return value 4294946546 on prog (id 2) dev N/A, expect packet loss! general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 5064 Comm: syz-executor391 Not tainted 6.7.0-rc2-syzkaller-00533-ga3799729 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 RIP: 0010:__hlist_del include/linux/list.h:988 [inline] RIP: 0010:hlist_del include/linux/list.h:1002 [inline] RIP: 0010:page_pool_unlist+0xd1/0x170 net/core/page_pool_user.c:342 Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 90 00 00 00 4c 8b a3 f0 06 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 75 68 48 85 ed 49 89 2c 24 74 24 e8 1b ca 07 f9 48 8d RSP: 0018:ffffc900039ff768 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88814ae02000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88814ae026f0 RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff1d57fdc R10: ffffffff8eabfee3 R11: ffffffff8aa0008b R12: 0000000000000000 R13: ffff88814ae02000 R14: dffffc0000000000 R15: 0000000000000001 FS: 000055555717a380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000002555398 CR3: 0000000025044000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __page_pool_destroy net/core/page_pool.c:851 [inline] page_pool_release+0x507/0x6b0 net/core/page_pool.c:891 page_pool_destroy+0x1ac/0x4c0 net/core/page_pool.c:956 xdp_test_run_teardown net/bpf/test_run.c:216 [inline] bpf_test_run_xdp_live+0x1578/0x1af0 net/bpf/test_run.c:388 bpf_prog_test_run_xdp+0x827/0x1530 net/bpf/test_run.c:1254 bpf_prog_test_run kernel/bpf/syscall.c:4041 [inline] __sys_bpf+0x11bf/0x4920 kernel/bpf/syscall.c:5402 __do_sys_bpf kernel/bpf/syscall.c:5488 [inline] __se_sys_bpf kernel/bpf/syscall.c:5486 [inline] __x64_sys_bpf+0x78/0xc0 kernel/bpf/syscall.c:5486 Fixes: 083772c9 ("net: page_pool: record pools per netdev") Reported-and-tested-by: syzbot+f9f8efb58a4db2ca98d0@syzkaller.appspotmail.com Signed-off-by:
Eric Dumazet <edumazet@google.com> Tested-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20231130092259.3797753-1-edumazet@google.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Paolo Abeni authored
Uwe Kleine-König says: ==================== net: ethernet: Convert to platform remove callback returning void in (implicit) v1 of this series (https://lore.kernel.org/netdev/20231117091655.872426-1-u.kleine-koenig@pengutronix.de) I tried to address the resource leaks in the three cpsw drivers. However this is hard to get right without being able to test the changes. So here comes a series that just converts all drivers below drivers/net/ethernet to use .remove_new() and adds a comment about the potential leaks for someone else to fix the problem. See commit 5c5a7680 ("platform: Provide a remove callback that returns no value") for an extended explanation and the eventual goal. The TL;DR; is to prevent bugs like the three noticed here. Note this series results in no change of behaviour apart from improving the error message for the three cpsw drivers from remove callback returned a non-zero value. This will be ignored. to Failed to resume device (-ESOMETHING) ==================== Link: https://lore.kernel.org/r/20231128173823.867512-1-u.kleine-koenig@pengutronix.deSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Replace the error path returning a non-zero value by an error message and a comment that there is more to do. With that this patch results in no change of behaviour in this driver apart from improving the error message. Signed-off-by:
Roger Quadros <rogerq@kernel.org> Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Replace the error path returning a non-zero value by an error message and a comment that there is more to do. With that this patch results in no change of behaviour in this driver apart from improving the error message. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Replace the error path returning a non-zero value by an error message and a comment that there is more to do. With that this patch results in no change of behaviour in this driver apart from improving the error message. Signed-off-by:
-
Paolo Abeni authored
Jiri Pirko says: ==================== devlink: warn about existing entities during reload-reinit Recently there has been a couple of attempts from drivers to block devlink reload in certain situations. Turned out, the drivers do not properly tear down ports and related netdevs during reload. To address this, add couple of checks to be done during devlink reload reinit action. Also, extend documentation to be more explicit. ==================== Link: https://lore.kernel.org/r/20231128115255.773377-1-jiri@resnulli.usSigned-off-by:
-
Jiri Pirko authored
During reload-reinit, all entities except for params, resources, regions and health reporter should be removed and re-added. Add a warning to be triggered in case the driver behaves differently. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by:
-
Jiri Pirko authored
Be more explicit about devlink entities that may stay and that have to be removed during reload reinit action. Signed-off-by:
-
Jakub Kicinski authored
Kuniyuki Iwashima says: ==================== tcp: Clean up and refactor cookie_v[46]_check(). This is a preparation series for upcoming arbitrary SYN Cookie support with BPF. [0] There are slight differences between cookie_v[46]_check(). Such a discrepancy caused an issue in the past, and BPF SYN Cookie support will add more churn. The primary purpose of this series is to clean up and refactor cookie_v[46]_check() to minimise such discrepancies and make the BPF series easier to review. [0]: https://lore.kernel.org/netdev/20231121184245.69569-1-kuniyu@amazon.com/ v2: https://lore.kernel.org/netdev/20231125011638.72056-1-kuniyu@amazon.com/ v1: https://lore.kernel.org/netdev/20231123012521.62841-1-kuniyu@amazon.com/ ==================== Link: https://lore.kernel.org/r/20231129022924.96156-1-kuniyu@amazon.comSigned-off-by:
-
Kuniyuki Iwashima authored
We will support arbitrary SYN Cookie with BPF, and then kfunc at TC will preallocate reqsk and initialise some fields that should not be overwritten later by cookie_v[46]_check(). To simplify the flow in cookie_v[46]_check(), we move such fields' initialisation to cookie_tcp_reqsk_alloc() and factorise non-BPF SYN Cookie handling into cookie_tcp_check(), where we validate the cookie and allocate reqsk, as done by kfunc later. Note that we set ireq->ecn_ok in two steps, the latter of which will be shared by the BPF case. As cookie_ecn_ok() is one-liner, now it's inlined. Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by:
Simon Horman <horms@kernel.org> Reviewed-by:
-
