- 01 Dec, 2023 7 commits
-
-
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:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231124071703.132549-7-pkshih@realtek.com
-
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 33 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:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> 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:
-
Kuniyuki Iwashima authored
We will support arbitrary SYN Cookie with BPF, and then some reqsk fields are initialised in kfunc, and others are done in cookie_v[46]_check(). This patch factorises the common part as cookie_tcp_reqsk_init() and calls it in cookie_tcp_reqsk_alloc() to minimise the discrepancy between cookie_v[46]_check(). Signed-off-by:
-
Kuniyuki Iwashima authored
We initialise treq->af_specific in cookie_tcp_reqsk_alloc() so that we can look up a key later in tcp_create_openreq_child(). Initially, that change was added for MD5 by commit ba5a4fdd ("tcp: make sure treq->af_specific is initialized"), but it has not been used since commit d0f2b7a9 ("tcp: Disable header prediction for MD5 flow."). Now, treq->af_specific is used only by TCP-AO, so, we can move that initialisation into tcp_ao_syncookie(). In addition to that, l3index in cookie_v[46]_check() is only used for tcp_ao_syncookie(), so let's move it as well. While at it, we move down tcp_ao_syncookie() in cookie_v4_check() so that it will be called after security_inet_conn_request() to make functions order consistent with cookie_v6_check(). Signed-off-by:
-
Kuniyuki Iwashima authored
When we create a full socket from SYN Cookie, we initialise tcp_sk(sk)->tsoffset redundantly in tcp_get_cookie_sock() as the field is inherited from tcp_rsk(req)->ts_off. cookie_v[46]_check |- treq->ts_off = 0 `- tcp_get_cookie_sock |- tcp_v[46]_syn_recv_sock | `- tcp_create_openreq_child | `- newtp->tsoffset = treq->ts_off `- tcp_sk(child)->tsoffset = tsoff Let's initialise tcp_rsk(req)->ts_off with the correct offset and remove the second initialisation of tcp_sk(sk)->tsoffset. Signed-off-by: -
Kuniyuki Iwashima authored
tcp_hdr(skb) and SYN Cookie are passed to __cookie_v[46]_check(), but none of the callers passes cookie other than ntohl(th->ack_seq) - 1. Let's fetch it in __cookie_v[46]_check() instead of passing the cookie over and over. Signed-off-by:
-
Kuniyuki Iwashima authored
We will support arbitrary SYN Cookie with BPF, and then reqsk will be preallocated before cookie_v[46]_check(). Depending on how validation fails, we send RST or just drop skb. To make the error handling easier, let's clean up goto labels. Signed-off-by:
-
Kuniyuki Iwashima authored
sock_net(sk) is used repeatedly in cookie_v[46]_check(). Let's cache it in a variable. Signed-off-by:
-
Kuniyuki Iwashima authored
We will grow and cut the xmas tree in cookie_v[46]_check(). This patch cleans it up to make later patches tidy. Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in struct field hc_tx_err_sqpdid_enforecement. Fix it. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
Shradha Gupta <shradhagupta@linux.microsoft.com> Link: https://lore.kernel.org/r/20231128095304.515492-1-colin.i.king@gmail.comSigned-off-by:
-
Andy Shevchenko authored
BYTES_PER_KBIT is defined in units.h, use that definition. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20231128175027.394754-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Jakub Kicinski authored
Mat Martineau says: ==================== mptcp: More selftest coverage and code cleanup for net-next Patches 1-5 and 7-8 add selftest coverage (and an associated subflow counter in the kernel) to validate the recently-updated handling of subflows with ID 0. Patch 6 renames a label in the userspace path manager for clarity. Patches 9-11 and 13-15 factor out common selftest code by moving certain functions to mptcp_lib.sh Patch 12 makes sure the random data file generated for selftest payloads has the intended size. v3: https://lore.kernel.org/r/20231115-send-net-next-2023107-v3-0-1ef58145a882@kernel.org v2: https://lore.kernel.org/r/20231114-send-net-next-2023107-v2-0-b650a477362c@kernel.org v1: https://lore.kernel.org/r/20231027-send-net-next-2023107-v1-0-03eff9452957@kernel.org ==================== Link: https://lore.kernel.org/r/20231128-send-net-next-2023107-v4-0-8d6b94150f6b@kernel.orgSigned-off-by:
-
Geliang Tang authored
To avoid duplicated code in different MPTCP selftests, we can add and use helpers defined in mptcp_lib.sh. wait_local_port_listen() helper is defined in diag.sh, mptcp_connect.sh, mptcp_join.sh and simult_flows.sh, export it into mptcp_lib.sh and rename it with mptcp_lib_ prefix. Use this new helper in all these scripts. Note: We only have IPv4 connections in this helper, not looking at IPv6 (tcp6) but that's OK because we only have IPv4 connections here in diag.sh. Reviewed-by:
Matthieu Baerts <matttbe@kernel.org> Signed-off-by:
Geliang Tang <geliang.tang@suse.com> Signed-off-by:
Mat Martineau <martineau@kernel.org> Link: https://lore.kernel.org/r/20231128-send-net-next-2023107-v4-15-8d6b94150f6b@kernel.orgSigned-off-by:
-
