summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-11-06vdpa: solidrun: Fix UB bug with devresPhilipp Stanner
In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf(). Cc: stable@vger.kernel.org # v6.3 Fixes: 51a8f9d7f587 ("virtio: vdpa: new SolidNET DPU driver.") Reported-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Closes: https://lore.kernel.org/all/74e9109a-ac59-49e2-9b1d-d825c9c9f891@wanadoo.fr/ Suggested-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Philipp Stanner <pstanner@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Message-Id: <20241028074357.9104-3-pstanner@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-11-06vsock/virtio: Initialization of the dangling pointer occurring in vsk->transHyunwoo Kim
During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL. Cc: stable <stable@kernel.org> Fixes: 06a8fc78367d ("VSOCK: Introduce virtio_vsock_common.ko") Signed-off-by: Hyunwoo Kim <v4bel@theori.io> Signed-off-by: Wongi Lee <qwerty@theori.io> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Message-Id: <2024102245-strive-crib-c8d3@gregkh> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-11-06wifi: rtlwifi: Remove some exhalbtc deadcodeDr. David Alan Gilbert
exhalbtc_rf_status_notify(), exhalbtc_coex_dm_switch() and exhalbtc_antenna_detection() are unused since they were added in 2017's commit 7937f02d1953 ("rtlwifi: btcoex: hook external functions for newer chips") Remove them. This leaves ex_btc8723b1ant_coex_dm_reset() unused. Remove it. exhalbtc_dbg_control(), exhalbtc_stack_update_profile_info(), exhalbtc_set_hci_version(), and exhalbtc_set_bt_patch_version() are unused since their addition in 2014 by commit aa45a673b291 ("rtlwifi: btcoexist: Add new mini driver") Remove them. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241104144331.29262-1-linux@treblig.org
2024-11-06wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failuresGuilherme G. Piccoli
Syzkaller reported a hung task with uevent_show() on stack trace. That specific issue was addressed by another commit [0], but even with that fix applied (for example, running v6.12-rc5) we face another type of hung task that comes from the same reproducer [1]. By investigating that, we could narrow it to the following path: (a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and dummy_hcd infrastructure. (b) During the probe of rtl8192cu, the driver ends-up performing an efuse read procedure (which is related to EEPROM load IIUC), and here lies the issue: the function read_efuse() calls read_efuse_byte() many times, as loop iterations depending on the efuse size (in our example, 512 in total). This procedure for reading efuse bytes relies in a loop that performs an I/O read up to *10k* times in case of failures. We measured the time of the loop inside read_efuse_byte() alone, and in this reproducer (which involves the dummy_hcd emulation layer), it takes 15 seconds each. As a consequence, we have the driver stuck in its probe routine for big time, exposing a stack trace like below if we attempt to reboot the system, for example: task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000 Workqueue: usb_hub_wq hub_event Call Trace: __schedule+0xe22/0xeb6 schedule_timeout+0xe7/0x132 __wait_for_common+0xb5/0x12e usb_start_wait_urb+0xc5/0x1ef ? usb_alloc_urb+0x95/0xa4 usb_control_msg+0xff/0x184 _usbctrl_vendorreq_sync+0xa0/0x161 _usb_read_sync+0xb3/0xc5 read_efuse_byte+0x13c/0x146 read_efuse+0x351/0x5f0 efuse_read_all_map+0x42/0x52 rtl_efuse_shadow_map_update+0x60/0xef rtl_get_hwinfo+0x5d/0x1c2 rtl92cu_read_eeprom_info+0x10a/0x8d5 ? rtl92c_read_chip_version+0x14f/0x17e rtl_usb_probe+0x323/0x851 usb_probe_interface+0x278/0x34b really_probe+0x202/0x4a4 __driver_probe_device+0x166/0x1b2 driver_probe_device+0x2f/0xd8 [...] We propose hereby to drastically reduce the attempts of doing the I/O reads in case of failures, restricted to USB devices (given that they're inherently slower than PCIe ones). By retrying up to 10 times (instead of 10000), we got reponsiveness in the reproducer, while seems reasonable to believe that there's no sane USB device implementation in the field requiring this amount of retries at every I/O read in order to properly work. Based on that assumption, it'd be good to have it backported to stable but maybe not since driver implementation (the 10k number comes from day 0), perhaps up to 6.x series makes sense. [0] Commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race") [1] A note about that: this syzkaller report presents multiple reproducers that differs by the type of emulated USB device. For this specific case, check the entry from 2024/08/08 06:23 in the list of crashes; the C repro is available at https://syzkaller.appspot.com/text?tag=ReproC&x=1521fc83980000. Cc: stable@vger.kernel.org # v6.1+ Reported-by: syzbot+edd9fe0d3a65b14588d5@syzkaller.appspotmail.com Tested-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241101193412.1390391-1-gpiccoli@igalia.com
2024-11-06wifi: rtw88: Enable the new RTL8821AU/RTL8812AU driversBitterblue Smith
These are older Wifi 5 chips. RTL8821AU is 1x1, with or without Bluetooth. RTL8812AU is 2x2, without Bluetooth. Beamforming is not implemented. It looks like these chips need a different implementation than what is in bf.c. Speed tests with RTL8821AU: 137 Mbps download, 144 Mbps upload. Speed tests with RTL8812AU: 344 Mbps download, 387 Mbps upload. Station mode and AP mode were tested. Bluetooth coexistence works. I used my Bluetooth headphones for several days, listening to music and watching videos. There is only a problem with the wifi speeds with one router: With ISP's HG6544C router: Official driver: 3/5 Mbps. rtw88: a bit more, but not steady at all. Not enough to watch a 1080p Youtube video. With my D-Link Eagle R32 router running Openwrt, on the same channel: Official driver: 6/10 Mbps. rtw88: download starts around 30, climbs to 50 / upload is 10 Mbps. I can watch a 1080p Youtube video. The music doesn't cut out during any speed tests. I also tested transferring files to and from my phone. I don't have other types of Bluetooth devices to test. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/0b8e8093-8103-4999-86bf-0055ec52ea64@gmail.com
2024-11-06wifi: rtw88: Add rtw8821au.c and rtw8812au.cBitterblue Smith
These are the entry points for the new modules rtw88_8821au (RTL8821AU/RTL8811AU) and rtw88_8812au (RTL8812AU). Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/91c495f8-a607-429b-8bc0-5a45d3c1393e@gmail.com
2024-11-06wifi: rtw88: Add rtw8812a.{c,h}Bitterblue Smith
These contain code specific to RTL8812AU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/a0057683-79eb-4ab2-8f74-11a3bc58adfb@gmail.com
2024-11-06wifi: rtw88: Add rtw8821a.{c,h}Bitterblue Smith
These contain code specific to RTL8821AU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/37218648-ada7-4fad-b7bd-d2aee28cefb9@gmail.com
2024-11-06wifi: rtw88: Add rtw88xxa.{c,h}Bitterblue Smith
These contain code shared by both RTL8821AU and RTL8812AU chips. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/b8590382-a954-412d-a96b-63e360b97acc@gmail.com
2024-11-06wifi: rtw88: Add rtw8821a_table.{c,h}Bitterblue Smith
These contain various arrays for initialising RTL8821AU. Also TX power limits. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/087c7260-fcc3-4e22-886b-ac477cad9198@gmail.com
2024-11-06wifi: rtw88: Add rtw8812a_table.{c,h}Bitterblue Smith
These contain various arrays for initialising RTL8812AU. Also TX power limits. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/086f476c-e832-4867-963c-a64a63252fd6@gmail.com
2024-11-06wifi: rtw89: coex: set higher priority to BT when WL scan and BT A2DP existChing-Te Ku
If WiFi operation channel & scan channel both at 2.4GHz, original will keep going at WL > BT priority table for a long time. It makes A2DP can not sent audio data to SUT device in time then performed a lag audio. Assign a BT > WL priority table when A2DP exist, to avoid the issue. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241031023032.7102-1-pkshih@realtek.com
2024-11-06wifi: rtw89: 8852b: change RF mode to normal mode when set channelChih-Kang Chang
Set the RF mode from 0xA(low power mode) to 0x3(Normal mode) to avoid abnormal TX waveform in OFDM rate. Originally the RF mode will be changed to normal mode by the firmware after entering LPS once. Therefore, this change does not affect power saving. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030091603.6073-1-pkshih@realtek.com
2024-11-06wifi: rtw89: coex: check NULL return of kmalloc in btc_fw_set_monreg()Pei Xiao
kmalloc may fail, return value might be NULL and will cause NULL pointer dereference. Add check NULL return of kmalloc in btc_fw_set_monreg(). Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Fixes: b952cb0a6e2d ("wifi: rtw89: coex: Add register monitor report v7 format") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/516a91f3997534f708af43c7592cbafdd53dd599.1730253508.git.xiaopei01@kylinos.cn
2024-11-06wifi: rtw89: 8922a: fill the missing OP1dB configurationKuan-Chung Chen
OP1dB stands for Output 1dB Compression Point. At this point, the power amplifier starts to enter the saturation region, resulting in distortion. The configuration of OP1dB can optimize the RX gain saturation region, improving RX throughput from 573 to 675 Mbps. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022903.13243-1-pkshih@realtek.com
2024-11-06KVM: PPC: Book3S HV: Mask off LPCR_MER for a vCPU before running it to avoid ↵Gautam Menghani
spurious interrupts Running a L2 vCPU (see [1] for terminology) with LPCR_MER bit set and no pending interrupts results in that L2 vCPU getting an infinite flood of spurious interrupts. The 'if check' in kvmhv_run_single_vcpu() sets the LPCR_MER bit if there are pending interrupts. The spurious flood problem can be observed in 2 cases: 1. Crashing the guest while interrupt heavy workload is running a. Start a L2 guest and run an interrupt heavy workload (eg: ipistorm) b. While the workload is running, crash the guest (make sure kdump is configured) c. Any one of the vCPUs of the guest will start getting an infinite flood of spurious interrupts. 2. Running LTP stress tests in multiple guests at the same time a. Start 4 L2 guests. b. Start running LTP stress tests on all 4 guests at same time. c. In some time, any one/more of the vCPUs of any of the guests will start getting an infinite flood of spurious interrupts. The root cause of both the above issues is the same: 1. A NMI is sent to a running vCPU that has LPCR_MER bit set. 2. In the NMI path, all registers are refreshed, i.e, H_GUEST_GET_STATE is called for all the registers. 3. When H_GUEST_GET_STATE is called for LPCR, the vcpu->arch.vcore->lpcr of that vCPU at L1 level gets updated with LPCR_MER set to 1, and this new value is always used whenever that vCPU runs, regardless of whether there was a pending interrupt. 4. Since LPCR_MER is set, the vCPU in L2 always jumps to the external interrupt handler, and this cycle never ends. Fix the spurious flood by masking off the LPCR_MER bit before running a L2 vCPU to ensure that it is not set if there are no pending interrupts. [1] Terminology: 1. L0 : PAPR hypervisor running in HV mode 2. L1 : Linux guest (logical partition) running on top of L0 3. L2 : KVM guest running on top of L1 Fixes: ec0f6639fa88 ("KVM: PPC: Book3S HV nestedv2: Ensure LPCR_MER bit is passed to the L0") Cc: stable@vger.kernel.org # v6.8+ Signed-off-by: Gautam Menghani <gautam@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
2024-11-06wifi: rtw89: mac: no configure CMAC/DMAC tables for firmware secure bootPing-Ke Shih
The initial CMAC/DMAC tables used by WiFi 6 chips are not needed to be called for firmware secure boot. Otherwise, it causes firmware abnormal and throw warnings. rtw89_8852be 0000:03:00.0: FW status = 0x1400 rtw89_8852be 0000:03:00.0: FW BADADDR = 0xb872f800 rtw89_8852be 0000:03:00.0: FW EPC/RA = 0xb89333b7 rtw89_8852be 0000:03:00.0: FW MISC = 0x0 rtw89_8852be 0000:03:00.0: R_AX_HALT_C2H = 0x10002010 rtw89_8852be 0000:03:00.0: R_AX_SER_DBG_INFO = 0x0 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c95 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c99 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9b rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9f rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9b rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c99 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9d rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c99 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9f rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c99 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-9-pkshih@realtek.com
2024-11-06wifi: rtw89: fw: use common function to parse security section for WiFi 6 chipsPing-Ke Shih
The MSSC (multiple security section count) can be regular number (shown in below figure) or 0xFF (supported already). For WiFi 7 or newer WiFi 6 chips, the MSSC will be 0xFF. But early WiFi 6 chip such as RTL8852B could be either one of the cases. Extend __parse_security_section() to support both with/without secure boot mode accordingly. +---------------------------+ -\ | firmware header | | | | | | +-----------------------+ | | | | section type/size * N | | | | +-----------------------+ | | +---------------------------+ -/ : : +---------------------------+ -\ | secure section type (ID:9)| | | | | +----|-> [ security key data ] | | | +---------------------------+ -/ | |MSS Pool for above section | | | [ security key data 1 ] | +----|- [ security key data 2 ] | by mss_idx | [ security key data 3 ] | | ... M | * M = MSSC (MSSC != 0xFF) +---------------------------+ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-8-pkshih@realtek.com
2024-11-06wifi: rtw89: fw: move v1 MSSC out of __parse_security_section() to share with v0Ping-Ke Shih
The security section can be a common parser for v0 and v1 format of firmware header, so move retrieval code of v1 MSSC from the function, and then sharing becomes possible. Not logic change at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-7-pkshih@realtek.com
2024-11-06wifi: rtw89: fw: set recorded IDMEM share mode in firmware header to registerPing-Ke Shih
For WiFi 6 chips, firmware secure boot will run on a IDMEM mode specified in firmware header. Retrieve the mode from firmware, and set to registers accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-6-pkshih@realtek.com
2024-11-06wifi: rtw89: fw: shrink download size of security section for RTL8852BPing-Ke Shih
For RTL8852B, when current firmware is secure boot, the security section needs a special treatment that shrink its size to 960. As figure below, not only shrink the amount of download size of security section (2), but also need to modify the section size in firmware header (1) that is also downloaded to chip. +---------------------------+ | firmware header | | | | +-----------------------+ | | | section type, size N -|-|-------+ | | ... (1) | | | | +-----------------------+ | | +---------------------------+ | 2048 shrink to 960 : : | +---------------------------+ -\ | | security section type 9 | | | | (2) | | <--+ | | | +---------------------------+ -/ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-5-pkshih@realtek.com
2024-11-06wifi: rtw89: efuse: read firmware secure info v0 from efuse for WiFi 6 chipsPing-Ke Shih
WiFi 6 chips could program secure information in v0 or v1 format. Use existing v1 parser or newly added v0 parser to recognize firmware key that is going to be used. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-4-pkshih@realtek.com
2024-11-06wifi: rtw89: efuse: move recognize firmware MSS info v1 to commonPing-Ke Shih
The WiFi 6 chip use the same firmware MSS information v1 read from efuse, so move this logic to common. No change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-3-pkshih@realtek.com
2024-11-06wifi: rtw89: efuse: move reading efuse of fw secure info to commonPing-Ke Shih
The secure key used by certain hardware module is programmed in efuse, so driver should read the information from efuse before downloading firmware. Originally only RTL8922AE can support firmware secure boot, and read efuse during chip power on. To extend to support all chips, move the caller to common power on flow and add separate functions to read efuse for WiFi 6 chips. No logic change at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-2-pkshih@realtek.com
2024-11-05Merge branch '100GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2024-11-04 (ice, idpf, i40e, e1000e) For ice: Marcin adjusts ordering of calls in ice_eswitch_detach() to resolve a use after free issue. Mateusz corrects variable type for Flow Director queue to fix issues related to drop actions. For idpf: Pavan resolves issues related to reset on idpf; avoiding use of freed vport and correctly unrolling the mailbox task. For i40e: Aleksandr fixes a race condition involving addition and deletion of VF MAC filters. For e1000e: Vitaly reverts workaround for Meteor Lake causing regressions in power management flows. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: e1000e: Remove Meteor Lake SMBUS workarounds i40e: fix race condition by adding filter's intermediate sync state idpf: fix idpf_vc_core_init error path idpf: avoid vport access in idpf_get_link_ksettings ice: change q_index variable type to s16 to store -1 value ice: Fix use after free during unload with ports in bridge ==================== Link: https://patch.msgid.link/20241104223639.2801097-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05selftests: netfilter: nft_queue.sh: fix warnings with socat 1.8.0.0Florian Westphal
Updated to a more recent socat release and saw this: socat E xioopen_ipdgram_listen(): unknown address family 0 socat W address is opened in read-write mode but only supports read-only First error is avoided via pf=ipv4 option, second one via -u (unidirectional) mode. Signed-off-by: Florian Westphal <fw@strlen.de> Link: https://patch.msgid.link/20241104142821.2608-1-fw@strlen.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05selftests: netfilter: run conntrack_dump_flush in netnsFlorian Westphal
This test will fail if the initial namespace has conntrack active due to unexpected number of flows returned on dump: conntrack_dump_flush.c:451:test_flush_by_zone:Expected ret (7) == 2 (2) test_flush_by_zone: Test failed FAIL conntrack_dump_flush.test_flush_by_zone not ok 2 conntrack_dump_flush.test_flush_by_zone Add a wrapper that unshares this program to avoid this problem. Signed-off-by: Florian Westphal <fw@strlen.de> Link: https://patch.msgid.link/20241104142529.2352-1-fw@strlen.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05mptcp: remove unneeded lock when listing schedsMatthieu Baerts (NGI0)
mptcp_get_available_schedulers() needs to iterate over the schedulers' list only to read the names: it doesn't modify anything there. In this case, it is enough to hold the RCU read lock, no need to combine this with the associated spin lock as it was done since its introduction in commit 73c900aa3660 ("mptcp: add net.mptcp.available_schedulers"). Suggested-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Geliang Tang <geliang@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20241104-net-next-mptcp-sched-unneeded-lock-v2-1-2ccc1e0c750c@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05Merge branch 'mptcp-pm-fix-wrong-perm-and-sock-kfree'Jakub Kicinski
Matthieu Baerts says: ==================== mptcp: pm: fix wrong perm and sock kfree Two small fixes related to the MPTCP path-manager: - Patch 1: remove an accidental restriction to admin users to list MPTCP endpoints. A regression from v6.7. - Patch 2: correctly use sock_kfree_s() instead of kfree() in the userspace PM. A fix for another fix introduced in v6.4 and backportable up to v5.19. ==================== Link: https://patch.msgid.link/20241104-net-mptcp-misc-6-12-v1-0-c13f2ff1656f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05mptcp: use sock_kfree_s instead of kfreeGeliang Tang
The local address entries on userspace_pm_local_addr_list are allocated by sock_kmalloc(). It's then required to use sock_kfree_s() instead of kfree() to free these entries in order to adjust the allocated size on the sk side. Fixes: 24430f8bf516 ("mptcp: add address into userspace pm list") Cc: stable@vger.kernel.org Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20241104-net-mptcp-misc-6-12-v1-2-c13f2ff1656f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05mptcp: no admin perm to list endpointsMatthieu Baerts (NGI0)
During the switch to YNL, the command to list all endpoints has been accidentally restricted to users with admin permissions. It looks like there are no reasons to have this restriction which makes it harder for a user to quickly check if the endpoint list has been correctly populated by an automated tool. Best to go back to the previous behaviour then. mptcp_pm_gen.c has been modified using ynl-gen-c.py: $ ./tools/net/ynl/ynl-gen-c.py --mode kernel \ --spec Documentation/netlink/specs/mptcp_pm.yaml --source \ -o net/mptcp/mptcp_pm_gen.c The header file doesn't need to be regenerated. Fixes: 1d0507f46843 ("net: mptcp: convert netlink from small_ops to ops") Cc: stable@vger.kernel.org Reviewed-by: Davide Caratti <dcaratti@redhat.com> Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20241104-net-mptcp-misc-6-12-v1-1-c13f2ff1656f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05Merge branch 'add-the-dwmac-driver-support-for-t-head-th1520-soc'Jakub Kicinski
Drew Fustini says: ==================== Add the dwmac driver support for T-HEAD TH1520 SoC This series adds support for dwmac gigabit ethernet in the T-Head TH1520 RISC-V SoC used on boards like BeagleV Ahead and the LicheePi 4A. The gigabit ethernet on these boards does need pinctrl support to mux the necessary pads. The pinctrl-th1520 driver, pinctrl binding, and related dts patches are in linux-next. However, they are not yet in net-next/main. Therefore, I am dropping the dts patch for v5 as it will not build on net-next/main due to the lack of the padctrl0_apsys pin controller node in next-next/main version th1520.dtsi. It does exist in linux-next [1] and the two patches in this series allow the ethernet ports to work correctly on the LPi4A and Ahead when applied to linux-next. The dwmac-thead driver in this series does not need the pinctrl-th1520 driver to build. Nor does the thead,th1520-gmac.yaml binding need the pinctrl binding to pass the schema check. [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/riscv/boot/dts/thead/th1520.dtsi ==================== Link: https://patch.msgid.link/20241103-th1520-gmac-v7-0-ef094a30169c@tenstorrent.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05net: stmmac: Add glue layer for T-HEAD TH1520 SoCJisheng Zhang
Add dwmac glue driver to support the DesignWare-based GMAC controllers on the T-HEAD TH1520 SoC. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com> Signed-off-by: Drew Fustini <dfustini@tenstorrent.com> Link: https://patch.msgid.link/20241103-th1520-gmac-v7-2-ef094a30169c@tenstorrent.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05dt-bindings: net: Add T-HEAD dwmac supportJisheng Zhang
Add documentation to describe the DesginWare-based GMAC controllers in the T-HEAD TH1520 SoC. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com> Signed-off-by: Drew Fustini <dfustini@tenstorrent.com> Link: https://patch.msgid.link/20241103-th1520-gmac-v7-1-ef094a30169c@tenstorrent.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05r8169: remove leftover locks after reverted changeHeiner Kallweit
After e31a9fedc7d8 ("Revert "r8169: disable ASPM during NAPI poll"") these locks aren't needed any longer. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/680f2606-ac7d-4ced-8694-e5033855da9b@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05net: phy: ti: add PHY_RST_AFTER_CLK_EN flagDiogo Silva
DP83848 datasheet (section 4.7.2) indicates that the reset pin should be toggled after the clocks are running. Add the PHY_RST_AFTER_CLK_EN to make sure that this indication is respected. In my experience not having this flag enabled would lead to, on some boots, the wrong MII mode being selected if the PHY was initialized on the bootloader and was receiving data during Linux boot. Signed-off-by: Diogo Silva <diogompaissilva@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Fixes: 34e45ad9378c ("net: phy: dp83848: Add TI DP83848 Ethernet PHY") Link: https://patch.msgid.link/20241102151504.811306-1-paissilva@ld-100007.ds1.internal Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05Merge branch 'add-support-for-synopsis-designware-version-3-72a'Jakub Kicinski
Lothar Rubusch says: ==================== Add support for Synopsis DesignWare version 3.72a Add compatibility and dt-binding for Synopsis DesignWare version 3.72a. The dwmac is used on some older Altera/Intel SoCs such as Arria10. Updating compatibles in the driver and bindings for the DT improves the binding check coverage for such SoCs. ==================== Link: https://patch.msgid.link/20241102114122.4631-1-l.rubusch@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05dt-bindings: net: snps,dwmac: add support for Arria10Lothar Rubusch
The hard processor system (HPS) on the Intel/Altera Arria10 provides three Ethernet Media Access Controller (EMAC) peripherals. Each EMAC can be used to transmit and receive data at 10/100/1000 Mbps over ethernet connections in compliance with the IEEE 802.3 specification. The EMACs on the Arria10 are instances of the Synopsis DesignWare Universal 10/100/1000 Ethernet MAC, version 3.72a. Support the Synopsis DesignWare version 3.72a, which is used in Intel's Arria10 SoC, since it was missing. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20241102114122.4631-3-l.rubusch@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05net: stmmac: add support for dwmac 3.72aLothar Rubusch
The dwmac 3.72a is an ip version that can be found on Intel/Altera Arria10 SoCs. Going by the hardware features "snps,multicast-filter-bins" and "snps,perfect-filter-entries" shall be supported. Thus add a compatibility flag, and extend coverage of the driver for the 3.72a. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20241102114122.4631-2-l.rubusch@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05net: hisilicon: hns: use ethtool string helpersRosen Penev
The latter is the preferred way to copy ethtool strings. Avoids manually incrementing the pointer. Cleans up the code quite well. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Jijie Shao <shaojijie@huawei.com> Link: https://patch.msgid.link/20241101220023.290926-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05openvswitch: Pass on secpath details for internal port rx.Aaron Conole
Clearing the secpath for internal ports will cause packet drops when ipsec offload or early SW ipsec decrypt are used. Systems that rely on these will not be able to actually pass traffic via openvswitch. There is still an open issue for a flow miss packet - this is because we drop the extensions during upcall and there is no facility to restore such data (and it is non-trivial to add such functionality to the upcall interface). That means that when a flow miss occurs, there will still be packet drops. With this patch, when a flow is found then traffic which has an associated xfrm extension will properly flow. Signed-off-by: Aaron Conole <aconole@redhat.com> Acked-by: Eelco Chaudron <echaudro@redhat.com> Link: https://patch.msgid.link/20241101204732.183840-1-aconole@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05r8169: improve initialization of RSS registers on RTL8125/RTL8126Heiner Kallweit
Replace the register addresses with the names used in r8125/r8126 vendor driver, and consider that RSS_CTRL_8125 is a 32 bit register. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/3bf2f340-b369-4174-97bf-fd38d4217492@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05Merge branch 'a-pile-of-sfc-deadcode'Jakub Kicinski
Dr. David Alan Gilbert says: ==================== A pile of sfc deadcode This is a collection of deadcode removal in the sfc drivers; the split is vaguely where I found them in the tree, with some left over. This has been build tested and booted on an x86 VM, but I fon't have the hardware to test; however it's all full function removal. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> ==================== Link: https://patch.msgid.link/20241102151625.39535-1-linux@treblig.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05sfc: Remove more unused functionsDr. David Alan Gilbert
efx_ticks_to_usecs(), efx_reconfigure_port(), efx_ptp_get_mode(), and efx_tx_get_copy_buffer_limited() are unused. They seem to be partially due to the later splits to Siena, but some seem unused for longer. Remove them. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Acked-by: Martin Habets <habetsm.xilinx@gmail.com> Link: https://patch.msgid.link/20241102151625.39535-5-linux@treblig.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05sfc: Remove unused mcdi functionsDr. David Alan Gilbert
efx_mcdi_flush_rxqs(), efx_mcdi_rpc_async_quiet(), efx_mcdi_rpc_finish_quiet(), and efx_mcdi_wol_filter_get_magic() are unused. I think these are fall out from the split into Siena that happened in commit 4d49e5cd4b09 ("sfc/siena: Rename functions in mcdi headers to avoid conflicts with sfc") and commit d48523cb88e0 ("sfc: Copy shared files needed for Siena (part 2)") Remove them. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Acked-by: Martin Habets <habetsm.xilinx@gmail.com> Link: https://patch.msgid.link/20241102151625.39535-4-linux@treblig.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05sfc: Remove unused efx_mae_mport_vfDr. David Alan Gilbert
efx_mae_mport_vf() has been unused since commit 5227adff37af ("sfc: add mport lookup based on driver's mport data") Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Acked-by: Martin Habets <habetsm.xilinx@gmail.com> Link: https://patch.msgid.link/20241102151625.39535-3-linux@treblig.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05sfc: Remove falcon deadcodeDr. David Alan Gilbert
ef4_farch_dimension_resources(), ef4_nic_fix_nodesc_drop_stat(), ef4_ticks_to_usecs() and ef4_tx_get_copy_buffer_limited() were copied over from efx_ equivalents in 2016 but never used by commit 5a6681e22c14 ("sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver") EF4_MAX_FLUSH_TIME is also unused. Remove them. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Acked-by: Martin Habets <habetsm.xilinx@gmail.com> Link: https://patch.msgid.link/20241102151625.39535-2-linux@treblig.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05netlink: typographical error in nlmsg_type constants definitionMaurice Lambert
This commit fix a typographical error in netlink nlmsg_type constants definition in the include/uapi/linux/rtnetlink.h at line 177. The definition is RTM_NEWNVLAN RTM_NEWVLAN instead of RTM_NEWVLAN RTM_NEWVLAN. Signed-off-by: Maurice Lambert <mauricelambert434@gmail.com> Fixes: 8dcea187088b ("net: bridge: vlan: add rtm definitions and dump support") Link: https://patch.msgid.link/20241103223950.230300-1-mauricelambert434@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05bnxt_en: replace PTP spinlock with seqlockVadim Fedorenko
We can see high contention on ptp_lock while doing RX timestamping on high packet rates over several queues. Spinlock is not effecient to protect timecounter for RX timestamps when reads are the most usual operations and writes are only occasional. It's better to use seqlock in such cases. Reviewed-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Vadim Fedorenko <vadfed@meta.com> Link: https://patch.msgid.link/20241103215108.557531-2-vadfed@meta.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05bnxt_en: cache only 24 bits of hw counterVadim Fedorenko
This hardware can provide only 48 bits of cycle counter. We can leave only 24 bits in the cache to extend RX timestamps from 32 bits to 48 bits. Lower 8 bits of the cached value will be used to check for roll-over while extending to full 48 bits. This change makes cache writes atomic even on 32 bit platforms and we can simply use READ_ONCE()/WRITE_ONCE() pair and remove spinlock. The configuration structure will be also reduced by 4 bytes. Reviewed-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Vadim Fedorenko <vadfed@meta.com> Link: https://patch.msgid.link/20241103215108.557531-1-vadfed@meta.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-14 02:37:09 +0000