summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2026-04-02wifi: rtw89: 8922d: configure TX/RX path assisting in BT coexistencePing-Ke Shih
The BT coexistence mechanism needs to control TX/RX path to co-work with BT well, and these helpers are provided by BB to configure path. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260330065847.48946-6-pkshih@realtek.com
2026-04-02wifi: rtw89: 8922d: add set TX power callbackPing-Ke Shih
Set TX power depends on operating channel. The Tx power factors are data rate, channel, bandwidth and etc. Also, consider SAR as a factor of TX power limit. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260330065847.48946-5-pkshih@realtek.com
2026-04-01net: macb: fix use of at91_default_usrio without CONFIG_OFConor Dooley
If CONFIG_OF is not enabled, at91_default_usrio is used undeclared in gem_default_config. Move at91_default_usrio back above the CONFIG_OF section where macb_default_usrio used to be, so that it is unconditionally defined and defined prior to any of the users. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202603280028.wQjUrIvv-lkp@intel.com/ Reported-by: Jiawen Wu <jiawenwu@trustnetic.com> Closes: https://lore.kernel.org/all/06a701dcc014$86def5b0$949ce110$@trustnetic.com/ Fixes: a17871778ee28 ("net: macb: rename macb_default_usrio to at91_default_usrio as not all platforms have mii mode control in usrio") Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20260331-enroll-sensation-50901318a419@spud Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-02wifi: rtw89: 8922d: add RF calibration opsPing-Ke Shih
The chips ops related to RF calibration include init, init_late, channel, band_change, scan, and track. The init_late is similar to init, but HCI is ready, so receiving C2H event is possible. The ops channel is the main function that do all RF calibration on operating channel. The ops band_change and scan are to reset RF calibration because channel is switching at these moment, we need to reset RF state. The ops track is to monitor temperature to check if re-calibrate RF again. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260330065847.48946-4-pkshih@realtek.com
2026-04-01bnxt_en: Restore default stat ctxs for ULP when resource is availablePavan Chebbi
During resource reservation, if the L2 driver does not have enough MSIX vectors to provide to the RoCE driver, it sets the stat ctxs for ULP also to 0 so that we don't have to reserve it unnecessarily. However, subsequently the user may reduce L2 rings thereby freeing up some resources that the L2 driver can now earmark for RoCE. In this case, the driver should restore the default ULP stat ctxs to make sure that all RoCE resources are ready for use. The RoCE driver may fail to initialize in this scenario without this fix. Fixes: d630624ebd70 ("bnxt_en: Utilize ulp client resources if RoCE is not registered") Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20260331065138.948205-4-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-01bnxt_en: Don't assume XDP is never enabled in bnxt_init_dflt_ring_mode()Michael Chan
The original code made the assumption that when we set up the initial default ring mode, we must be just loading the driver and XDP cannot be enabled yet. This is not true when the FW goes through a resource or capability change. Resource reservations will be cancelled and reinitialized with XDP already enabled. devlink reload with XDP enabled will also have the same issue. This scenario will cause the ring arithmetic to be all wrong in the bnxt_init_dflt_ring_mode() path causing failure: bnxt_en 0000:a1:00.0 ens2f0np0: bnxt_setup_int_mode err: ffffffea bnxt_en 0000:a1:00.0 ens2f0np0: bnxt_request_irq err: ffffffea bnxt_en 0000:a1:00.0 ens2f0np0: nic open fail (rc: ffffffea) Fix it by properly accounting for XDP in the bnxt_init_dflt_ring_mode() path by using the refactored helper functions in the previous patch. Reviewed-by: Andy Gospodarek <andrew.gospodarek@broadcom.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Fixes: ec5d31e3c15d ("bnxt_en: Handle firmware reset status during IF_UP.") Fixes: 228ea8c187d8 ("bnxt_en: implement devlink dev reload driver_reinit") Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20260331065138.948205-3-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-01bnxt_en: Refactor some basic ring setup and adjustment logicMichael Chan
Refactor out the basic code that trims the default rings, sets up and adjusts XDP TX rings and CP rings. There is no change in behavior. This is to prepare for the next bug fix patch. Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Andy Gospodarek <andrew.gospodarek@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20260331065138.948205-2-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-02wifi: rtw89: 8922d: add set channel with pre-/post- helpersPing-Ke Shih
The main set channel function calls MAC/BB/RF ones, and pre-/post- helpers are called before/after the main function to backup/restore and stop/restart circuits, including TX scheduler, PPDU status, DACK and TSSI. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260330065847.48946-3-pkshih@realtek.com
2026-04-02wifi: rtw89: 8922d: BB hardware pre-/post-init, TX/RX path and power settingsPing-Ke Shih
More settings related to BB pre-/post-initial settings, the TX/RX path settings, and digital power compensation. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260330065847.48946-2-pkshih@realtek.com
2026-04-01net/mlx5: Fix switchdev mode rollback in case of failureSaeed Mahameed
If for some internal reason switchdev mode fails, we rollback to legacy mode, before this patch, rollback will unregister the uplink netdev and leave it unregistered causing the below kernel bug. To fix this, we need to avoid netdev unregister by setting the proper rollback flag 'MLX5_PRIV_FLAGS_SWITCH_LEGACY' to indicate legacy mode. devlink (431) used greatest stack depth: 11048 bytes left mlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), \ necvfs(0), active vports(0) mlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload mlx5_core 0000:00:03.0: Loading uplink representor for vport 65535 mlx5_core 0000:00:03.0: mlx5_cmd_out_err:816:(pid 456): \ QUERY_HCA_CAP(0x100) op_mod(0x0) failed, \ status bad parameter(0x3), syndrome (0x3a3846), err(-22) mlx5_core 0000:00:03.0 enp0s3np0 (unregistered): Unloading uplink \ representor for vport 65535 ------------[ cut here ]------------ kernel BUG at net/core/dev.c:12070! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 456 Comm: devlink Not tainted 6.16.0-rc3+ \ #9 PREEMPT(voluntary) RIP: 0010:unregister_netdevice_many_notify+0x123/0xae0 ... Call Trace: [ 90.923094] unregister_netdevice_queue+0xad/0xf0 [ 90.923323] unregister_netdev+0x1c/0x40 [ 90.923522] mlx5e_vport_rep_unload+0x61/0xc6 [ 90.923736] esw_offloads_enable+0x8e6/0x920 [ 90.923947] mlx5_eswitch_enable_locked+0x349/0x430 [ 90.924182] ? is_mp_supported+0x57/0xb0 [ 90.924376] mlx5_devlink_eswitch_mode_set+0x167/0x350 [ 90.924628] devlink_nl_eswitch_set_doit+0x6f/0xf0 [ 90.924862] genl_family_rcv_msg_doit+0xe8/0x140 [ 90.925088] genl_rcv_msg+0x18b/0x290 [ 90.925269] ? __pfx_devlink_nl_pre_doit+0x10/0x10 [ 90.925506] ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10 [ 90.925766] ? __pfx_devlink_nl_post_doit+0x10/0x10 [ 90.926001] ? __pfx_genl_rcv_msg+0x10/0x10 [ 90.926206] netlink_rcv_skb+0x52/0x100 [ 90.926393] genl_rcv+0x28/0x40 [ 90.926557] netlink_unicast+0x27d/0x3d0 [ 90.926749] netlink_sendmsg+0x1f7/0x430 [ 90.926942] __sys_sendto+0x213/0x220 [ 90.927127] ? __sys_recvmsg+0x6a/0xd0 [ 90.927312] __x64_sys_sendto+0x24/0x30 [ 90.927504] do_syscall_64+0x50/0x1c0 [ 90.927687] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 90.927929] RIP: 0033:0x7f7d0363e047 Fixes: 2a4f56fbcc47 ("net/mlx5e: Keep netdev when leave switchdev for devlink set legacy only") Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Reviewed-by: Jianbo Liu <jianbol@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260330194015.53585-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-01net/mlx5: Avoid "No data available" when FW version queries failSaeed Mahameed
Avoid printing the misleading "kernel answers: No data available" devlink output when querying firmware or pending firmware version fails (e.g. MLX5 fw state errors / flash failures). FW can fail on loading the pending flash image and get its version due to various reasons, examples: mlxfw: Firmware flash failed: key not applicable, err (7) mlx5_fw_image_pending: can't read pending fw version while fw state is 1 and the resulting: $ devlink dev info kernel answers: No data available Instead, just report 0 or 0xfff.. versions in case of failure to indicate a problem, and let other information be shown. after the fix: $ devlink dev info pci/0000:00:06.0: driver mlx5_core serial_number xxx... board.serial_number MT2225300179 versions: fixed: fw.psid MT_0000000436 running: fw.version 22.41.0188 fw 22.41.0188 stored: fw.version 255.255.65535 fw 255.255.65535 Fixes: 9c86b07e3069 ("net/mlx5: Added fw version query command") Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260330194015.53585-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-01net/mlx5: lag: Check for LAG device before creating debugfsShay Drory
__mlx5_lag_dev_add_mdev() may return 0 (success) even when an error occurs that is handled gracefully. Consequently, the initialization flow proceeds to call mlx5_ldev_add_debugfs() even when there is no valid LAG context. mlx5_ldev_add_debugfs() blindly created the debugfs directory and attributes. This exposed interfaces (like the members file) that rely on a valid ldev pointer, leading to potential NULL pointer dereferences if accessed when ldev is NULL. Add a check to verify that mlx5_lag_dev(dev) returns a valid pointer before attempting to create the debugfs entries. Fixes: 7f46a0b7327a ("net/mlx5: Lag, add debugfs to query hardware lag state") Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260330194015.53585-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-01Octeontx2-af: add WQ_PERCPU to alloc_workqueue usersMarco Crivellari
This continues the effort to refactor workqueue APIs, which began with the introduction of new workqueues and a new alloc_workqueue flag in: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") The refactoring is going to alter the default behavior of alloc_workqueue() to be unbound by default. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND must now use WQ_PERCPU. For more details see the Link tag below. In order to keep alloc_workqueue() behavior identical, explicitly request WQ_PERCPU. Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/ Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://patch.msgid.link/20260330095405.116990-1-marco.crivellari@suse.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-01net: macb: properly unregister fixed rate clocksFedor Pchelkin
The additional resources allocated with clk_register_fixed_rate() need to be released with clk_unregister_fixed_rate(), otherwise they are lost. Fixes: 83a77e9ec415 ("net: macb: Added PCI wrapper for Platform Driver.") Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru> Link: https://patch.msgid.link/20260330184542.626619-2-pchelkin@ispras.ru Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-01net: macb: fix clk handling on PCI glue driver removalFedor Pchelkin
platform_device_unregister() may still want to use the registered clks during runtime resume callback. Note that there is a commit d82d5303c4c5 ("net: macb: fix use after free on rmmod") that addressed the similar problem of clk vs platform device unregistration but just moved the bug to another place. Save the pointers to clks into local variables for reuse after platform device is unregistered. BUG: KASAN: use-after-free in clk_prepare+0x5a/0x60 Read of size 8 at addr ffff888104f85e00 by task modprobe/597 CPU: 2 PID: 597 Comm: modprobe Not tainted 6.1.164+ #114 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x8d/0xba print_report+0x17f/0x496 kasan_report+0xd9/0x180 clk_prepare+0x5a/0x60 macb_runtime_resume+0x13d/0x410 [macb] pm_generic_runtime_resume+0x97/0xd0 __rpm_callback+0xc8/0x4d0 rpm_callback+0xf6/0x230 rpm_resume+0xeeb/0x1a70 __pm_runtime_resume+0xb4/0x170 bus_remove_device+0x2e3/0x4b0 device_del+0x5b3/0xdc0 platform_device_del+0x4e/0x280 platform_device_unregister+0x11/0x50 pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 </TASK> Allocated by task 519: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x8e/0x90 __clk_register+0x458/0x2890 clk_hw_register+0x1a/0x60 __clk_hw_register_fixed_rate+0x255/0x410 clk_register_fixed_rate+0x3c/0xa0 macb_probe+0x1d8/0x42e [macb_pci] local_pci_probe+0xd7/0x190 pci_device_probe+0x252/0x600 really_probe+0x255/0x7f0 __driver_probe_device+0x1ee/0x330 driver_probe_device+0x4c/0x1f0 __driver_attach+0x1df/0x4e0 bus_for_each_dev+0x15d/0x1f0 bus_add_driver+0x486/0x5e0 driver_register+0x23a/0x3d0 do_one_initcall+0xfd/0x4d0 do_init_module+0x18b/0x5a0 load_module+0x5663/0x7950 __do_sys_finit_module+0x101/0x180 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 597: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x50 __kasan_slab_free+0x106/0x180 __kmem_cache_free+0xbc/0x320 clk_unregister+0x6de/0x8d0 macb_remove+0x73/0xc0 [macb_pci] pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Fixes: d82d5303c4c5 ("net: macb: fix use after free on rmmod") Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru> Link: https://patch.msgid.link/20260330184542.626619-1-pchelkin@ispras.ru Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-02wifi: rtw89: fix typo "frome" -> "from" in rx_freq_frome_ieChristos Longros
The chip_info field rx_freq_frome_ie (RX frequency from Information Element) has a typo. The function that uses it is already spelled correctly: rtw89_core_update_rx_freq_from_ie. Rename the field to match. Signed-off-by: Christos Longros <chris.longros@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260329074550.114787-1-chris.longros@gmail.com
2026-04-01net: microchip: dead code cleanup in kconfig for FDMAJulian Braha
The Kconfig in the parent directory already has the first 'if NET_VENDOR_MICROCHIP' gating the inclusion of this Kconfig, meaning that the second 'if NET_VENDOR_MICROCHIP' condition is effectively dead code. I propose removing the second 'if NET_VENDOR_MICROCHIP' in drivers/net/ethernet/microchip/fdma/Kconfig This dead code was found by kconfirm, a static analysis tool for Kconfig. Signed-off-by: Julian Braha <julianbraha@gmail.com> Link: https://patch.msgid.link/20260329185348.526893-1-julianbraha@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-01virtio_net: clamp rss_max_key_size to NETDEV_RSS_KEY_LENSrujana Challa
rss_max_key_size in the virtio spec is the maximum key size supported by the device, not a mandatory size the driver must use. Also the value 40 is a spec minimum, not a spec maximum. The current code rejects RSS and can fail probe when the device reports a larger rss_max_key_size than the driver buffer limit. Instead, clamp the effective key length to min(device rss_max_key_size, NETDEV_RSS_KEY_LEN) and keep RSS enabled. This keeps probe working on devices that advertise larger maximum key sizes while respecting the netdev RSS key buffer size limit. Fixes: 3f7d9c1964fc ("virtio_net: Add hash_key_length check") Cc: stable@vger.kernel.org Signed-off-by: Srujana Challa <schalla@marvell.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Link: https://patch.msgid.link/20260326142344.1171317-1-schalla@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-02wifi: rtw89: Fill fw_version member of struct wiphyBitterblue Smith
Let userspace tools like lshw show the firmware version by filling the fw_version member of struct wiphy. Before: configuration: broadcast=yes driver=rtw89_8852au driverversion=6.19.6-arch1-1 firmware=N/A link=no multicast=yes wireless=IEEE 802.11 After: configuration: broadcast=yes driver=rtw89_8852au driverversion=6.19.6-arch1-1 firmware=0.13.36.2 link=no multicast=yes wireless=IEEE 802.11 Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/a46ed12c-387c-4063-849c-c6457bf97810@gmail.com
2026-04-02wifi: rtw88: Fill fw_version member of struct wiphyBitterblue Smith
Let userspace tools like lshw show the firmware version by filling the fw_version member of struct wiphy. Before: configuration: broadcast=yes driver=rtw88_8814au driverversion=6.19.6-arch1-1 firmware=N/A link=no multicast=yes wireless=IEEE 802.11 After: configuration: broadcast=yes driver=rtw88_8814au driverversion=6.19.6-arch1-1 firmware=33.6.0 link=no multicast=yes wireless=IEEE 802.11 Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/3701cce1-42c4-4382-9120-cd21012c1b21@gmail.com
2026-04-01Merge tag 'linux-can-next-for-7.1-20260401' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2026-04-01 The first patch is by Ethan Nelson-Moore and removes a useless copy of PCI_DEVICE_DATA from the ctucanfd driver. Geert Uytterhoeven's patch for the rcar_can converts the driver to use the FIELD_MODIFY macro. Viken Dadhaniya contributes 2 patches for the mcp251xfd driver that add transceiver standby control. The last 2 aptches are by Johan Hovold and refactor the usb endpoint lookup of the kvaser_usb and ucan driver. * tag 'linux-can-next-for-7.1-20260401' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: can: ucan: refactor endpoint lookup can: rcar_can: Convert to FIELD_MODIFY() can: mcp251xfd: add support for XSTBYEN transceiver standby control can: kvaser_usb: leaf: refactor endpoint lookup net: can: ctucanfd: remove useless copy of PCI_DEVICE_DATA macro dt-bindings: can: mcp251xfd: add microchip,xstbyen property ==================== Link: https://patch.msgid.link/20260401073338.5592-1-mkl@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-01net/mlx5: Move command entry freeing outside of spinlockLi RongQing
Move the kfree() call outside the critical section to reduce lock holding time. This aligns with the general principle of minimizing work under locks. Signed-off-by: Li RongQing <lirongqing@baidu.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260331122604.1933-1-lirongqing@baidu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-01ppp: dead code cleanup in KconfigJulian Braha
There is already an 'if PPP' condition wrapping several config options e.g. PPP_MPPE and PPPOE, making the 'depends on PPP' statement for each of these a duplicate dependency (dead code). I propose leaving the outer 'if PPP...endif' and removing the individual 'depends on PPP' statement from each option. This dead code was found by kconfirm, a static analysis tool for Kconfig. Signed-off-by: Julian Braha <julianbraha@gmail.com> Reviewed-by: Qingfang Deng <dqfext@gmail.com> Link: https://patch.msgid.link/20260330213258.13982-1-julianbraha@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-01can: ucan: refactor endpoint lookupJohan Hovold
Use the common USB helpers for looking up bulk and interrupt endpoints (and determining endpoint numbers and max packet sizes) instead of open coding. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260330101817.1664787-3-johan@kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2026-04-01can: kvaser_usb: leaf: refactor endpoint lookupJohan Hovold
Use the common USB helper for looking up bulk and interrupt endpoints instead of open coding. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260330101817.1664787-2-johan@kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2026-04-01can: mcp251xfd: add support for XSTBYEN transceiver standby controlViken Dadhaniya
The MCP251xFD has a dedicated transceiver standby control function on the INT0/GPIO0/XSTBY pin, controlled by the XSTBYEN bit in IOCON. When enabled, the hardware automatically manages the transceiver standby state: the pin is driven low when the controller is active and high when it enters Sleep mode. Enable this feature when the 'microchip,xstbyen' device tree property is present. Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> Link: https://patch.msgid.link/20260321135031.3107408-3-viken.dadhaniya@oss.qualcomm.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2026-04-01can: rcar_can: Convert to FIELD_MODIFY()Geert Uytterhoeven
Use the FIELD_MODIFY() helper instead of open-coding the same operation. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/ee2e6aaacd5e061c972716ecaf8a929be7ef5f2e.1772705647.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2026-04-01net: can: ctucanfd: remove useless copy of PCI_DEVICE_DATA macroEthan Nelson-Moore
The ctucanfd driver has its own copy of the PCI_DEVICE_DATA macro. I assume this was done to support older kernel versions where it didn't exist, but that is irrelevant once the driver is in the mainline kernel. Remove it. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Link: https://patch.msgid.link/20260130114134.47421-1-enelsonmoore@gmail.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2026-03-31net: vxlan: check ipv6_mod_enabled() on neigh_reduce()Fernando Fernandez Mancera
IPv6 must be enabled or otherwise neigh_reduce() might cause a kernel panic. This was prevented by a check on in6_dev. Use ipv6_mod_enabled() instead as it is cleaner and also consistent with the code at route_shortcircuit(). Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260330121033.4479-1-fmancera@suse.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-31net: stmmac: skip VLAN restore when VLAN hash ops are missingMichal Piekos
stmmac_vlan_restore() unconditionally calls stmmac_vlan_update() when NETIF_F_VLAN_FEATURES is set. On platforms where priv->hw->vlan (or ->update_vlan_hash) is not provided, stmmac_update_vlan_hash() returns -EINVAL via stmmac_do_void_callback(), resulting in a spurious "Failed to restore VLANs" error even when no VLAN filtering is in use. Remove not needed comment. Remove not used return value from stmmac_vlan_restore(). Tested on Orange Pi Zero 3. Fixes: bd7ad51253a7 ("net: stmmac: Fix VLAN HW state restore") Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl> Link: https://patch.msgid.link/20260328-vlan-restore-error-v4-1-f88624c530dc@mmpsystems.pl Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-31net: mana: hardening: Validate adapter_mtu from MANA_QUERY_DEV_CONFIGErni Sri Satya Vennela
As a part of MANA hardening for CVM, validate the adapter_mtu value returned from the MANA_QUERY_DEV_CONFIG HWC command. The adapter_mtu value is used to compute ndev->max_mtu via: gc->adapter_mtu - ETH_HLEN. If hardware returns a bogus adapter_mtu smaller than ETH_HLEN (e.g. 0), the unsigned subtraction wraps to a huge value, silently allowing oversized MTU settings. Add a validation check to reject adapter_mtu values below ETH_MIN_MTU + ETH_HLEN, returning -EPROTO to fail the device configuration early with a clear error message. Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com> Link: https://patch.msgid.link/20260326173101.2010514-1-ernis@linux.microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-31net: ftgmac100: fix ring allocation unwind on open failureYufan Chen
ftgmac100_alloc_rings() allocates rx_skbs, tx_skbs, rxdes, txdes, and rx_scratch in stages. On intermediate failures it returned -ENOMEM directly, leaking resources allocated earlier in the function. Rework the failure path to use staged local unwind labels and free allocated resources in reverse order before returning -ENOMEM. This matches common netdev allocation cleanup style. Fixes: d72e01a0430f ("ftgmac100: Use a scratch buffer for failed RX allocations") Cc: stable@vger.kernel.org Signed-off-by: Yufan Chen <yufan.chen@linux.dev> Link: https://patch.msgid.link/20260328163257.60836-1-yufan.chen@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-31declance: Include the offending address with DMA errorsMaciej W. Rozycki
The address latched in the I/O ASIC LANCE DMA Pointer Register uses the TURBOchannel bus address encoding and therefore bits 33:29 of location referred occupy bits 4:0, bits 28:2 are left-shifted by 3, and bits 1:0 are hardwired to zero. In reality no TURBOchannel system exceeds 1GiB of RAM though, so the address reported will always fit in 8 hex digits. Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://patch.msgid.link/alpine.DEB.2.21.2603291839220.60268@angie.orcam.me.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-31declance: Rate-limit DMA errorsMaciej W. Rozycki
Prevent the system from becoming unusable due to a flood of DMA error messages. Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://patch.msgid.link/alpine.DEB.2.21.2603291838370.60268@angie.orcam.me.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-31net: airoha: Fix typo in airoha_set_gdm2_loopback routine nameLorenzo Bianconi
Rename airhoha_set_gdm2_loopback() in airoha_set_gdm2_loopback() Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260330-airoha_set_gdm2_loopback-fix-typo-v1-1-a1320ff6b6cc@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-31net: ipeth: refactor endpoint lookupJohan Hovold
Use the common USB helper for looking up bulk and interrupt endpoints instead of open coding. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260330102611.1671546-3-johan@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-31net: hso: refactor endpoint lookupJohan Hovold
Use the common USB helpers for looking up bulk and interrupt endpoints instead of a custom implementation. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260330102611.1671546-2-johan@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-31sfc: add transmit timestamping supportIzabela Bakollari
Add ethtool op to advertise TX timestamping. Insert a skb_tx_timestamp call in __efx_enqueue_skb. Signed-off-by: Izabela Bakollari <ibakolla@redhat.com> Reviewed-by: Edward Cree <ecree.xilinx@gmail.com> Link: https://patch.msgid.link/20260330063236.247057-1-ibakolla@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-31net: phy: bcm84881: add BCM84891/BCM84892 supportDaniel Wagner
The BCM84891 and BCM84892 are 10GBASE-T PHYs in the same family as the BCM84881, sharing the register map and most callbacks. They add USXGMII as a host interface mode. bcm8489x_config_init() is separate from bcm84881_config_init(): it allows only USXGMII (the only host mode available on the tested hardware) and clears MDIO_CTRL1_LPOWER, which is set at boot on the tested platform. Does not recur on ifdown/ifup, cable events, or link-partner advertisement changes, so config_init is sufficient. For USXGMII, read_status() skips the 0x4011 host-mode register: it returns the same value regardless of negotiated copper speed (USXGMII symbol replication). Speed comes from phy_resolve_aneg_linkmode() via standard C45 AN resolution. Tested on TRENDnet TEG-S750 (RTL9303 + 1x BCM84891 + 4x BCM84892) running OpenWrt, where the MDIO controller driver is currently OpenWrt-specific. Link verified at 100M, 1G, 2.5G, 10G. Signed-off-by: Daniel Wagner <wagner.daniel.t@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/20260330225310.2801264-1-wagner.daniel.t@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-31net: dsa: mxl862xx: cancel pending work on probe errorDaniel Golle
Call mxl862xx_host_shutdown() in case dsa_register_switch() returns an error, so any still pending crc_err_work get canceled. Fixes: a319d0c8c8ce ("net: dsa: mxl862xx: add CRC for MDIO communication") Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/3fd163f5bb88de426ca9847549f94b4296170ef0.1774911025.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-31fbnic: Set Relaxed Ordering PCIe TLP attributes for DMA enginesAlexander Duyck
Add ATTR CSR bit field definitions for the DMA engine TLP header configuration registers: AW_CFG: RDE_ATTR[17:15], RQM_ATTR[14:12], TQM_ATTR[11:9] AR_CFG: TDE_ATTR[17:15], RQM_ATTR[14:12], TQM_ATTR[11:9] These fields control the PCIe TLP attribute bits for outbound transactions from the TQM, RQM, RDE (write path), and TDE (read path) DMA engines. An enum is added with standard PCIe TLP attribute values: NS (No Snoop), RO (Relaxed Ordering), and IDO (ID-based Ordering). Read the PCIe Relaxed Ordering capability at probe time and store it in fbnic_dev. Configure Relaxed Ordering on the PCIe TLP attributes in fbnic_mbx_init_desc_ring when the capability is enabled. For the write path (AW_CFG), set RO on RDE and TQM attributes. For the read path (AR_CFG), set RO on all three attributes (TDE, RQM, TQM). This allows the PCIe fabric to reorder these transactions for improved throughput. Signed-off-by: Alexander Duyck <alexanderduyck@fb.com> Signed-off-by: Dimitri Daskalakis <daskald@meta.com> Link: https://patch.msgid.link/20260327204445.3074446-1-dimitri.daskalakis1@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-31net: xilinx: axienet: Fix BQL accounting for multi-BD TX packetsSuraj Gupta
When a TX packet spans multiple buffer descriptors (scatter-gather), axienet_free_tx_chain sums the per-BD actual length from descriptor status into a caller-provided accumulator. That sum is reset on each NAPI poll. If the BDs for a single packet complete across different polls, the earlier bytes are lost and never credited to BQL. This causes BQL to think bytes are permanently in-flight, eventually stalling the TX queue. The SKB pointer is stored only on the last BD of a packet. When that BD completes, use skb->len for the byte count instead of summing per-BD status lengths. This matches netdev_sent_queue(), which debits skb->len, and naturally survives across polls because no partial packet contributes to the accumulator. Fixes: c900e49d58eb ("net: xilinx: axienet: Implement BQL") Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com> Reviewed-by: Sean Anderson <sean.anderson@linux.dev> Link: https://patch.msgid.link/20260327073238.134948-3-suraj.gupta2@amd.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-31net: xilinx: axienet: Correct BD length masks to match AXIDMA IP specSuraj Gupta
The XAXIDMA_BD_CTRL_LENGTH_MASK and XAXIDMA_BD_STS_ACTUAL_LEN_MASK macros were defined as 0x007FFFFF (23 bits), but the AXI DMA IP product guide (PG021) specifies the buffer length field as bits 25:0 (26 bits). Update both masks to match the IP documentation. In practice this had no functional impact, since Ethernet frames are far smaller than 2^23 bytes and the extra bits were always zero, but the masks should still reflect the hardware specification. Fixes: 8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver") Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com> Reviewed-by: Sean Anderson <sean.anderson@linux.dev> Link: https://patch.msgid.link/20260327073238.134948-2-suraj.gupta2@amd.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-31net: bonding: fix use-after-free in bond_xmit_broadcast()Xiang Mei
bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is "last" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the "last" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) </TASK> Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Fixes: 4e5bd03ae346 ("net: bonding: fix bond_xmit_broadcast return value error bug") Reported-by: Weiming Shi <bestswngs@gmail.com> Signed-off-by: Xiang Mei <xmei5@asu.edu> Link: https://patch.msgid.link/20260326075553.3960562-1-xmei5@asu.edu Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-31r8152: add helper functions for PHY OCP registersChih Kai Hsu
Add the following bitwise operation functions for PHY OCP registers to simplify the code. - ocp_reg_w0w1() - ocp_reg_clr_bits() - ocp_reg_set_bits() - sram_write_w0w1() - sram_clr_bits() - sram_set_bits() - r8152_mdio_clr_bit() - r8152_mdio_set_bit() - r8152_mdio_test_and_clr_bit() In addition, remove variable set but not used from r8153_init(), r8153b_init() and r8153c_init(). Signed-off-by: Chih Kai Hsu <hsu.chih.kai@realtek.com> Reviewed-by: Hayes Wang <hayeswang@realtek.com> Link: https://patch.msgid.link/20260326073925.32976-456-nic_swsd@realtek.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-31r8152: add helper functions for PLA/USB OCP registersChih Kai Hsu
Add the following bitwise operation functions for PLA/USB OCP registers to simplify the code. - ocp_dword_w0w1() - ocp_word_w0w1() - ocp_byte_w0w1() - ocp_dword_clr_bits() - ocp_dword_set_bits() - ocp_word_clr_bits() - ocp_word_set_bits() - ocp_word_test_and_clr_bits() - ocp_byte_clr_bits() - ocp_byte_set_bits() Signed-off-by: Chih Kai Hsu <hsu.chih.kai@realtek.com> Reviewed-by: Hayes Wang <hayeswang@realtek.com> Link: https://patch.msgid.link/20260326073925.32976-455-nic_swsd@realtek.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-31r8152: fix incorrect register write to USB_UPHY_XTALChih Kai Hsu
The old code used ocp_write_byte() to clear the OOBS_POLLING bit (BIT(8)) in the USB_UPHY_XTAL register, but this doesn't correctly clear a bit in the upper byte of the 16-bit register. Fix this by using ocp_write_word() instead. Fixes: 195aae321c82 ("r8152: support new chips") Signed-off-by: Chih Kai Hsu <hsu.chih.kai@realtek.com> Reviewed-by: Hayes Wang <hayeswang@realtek.com> Link: https://patch.msgid.link/20260326073925.32976-454-nic_swsd@realtek.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-30FDDI: defxx: Rate-limit memory allocation errorsMaciej W. Rozycki
Prevent the system from becoming unstable or unusable due to a flood of memory allocation error messages under memory pressure, e.g.: [...] fddi0: Could not allocate receive buffer. Dropping packet. fddi0: Could not allocate receive buffer. Dropping packet. fddi0: Could not allocate receive buffer. Dropping packet. fddi0: Could not allocate receive buffer. Dropping packet. rcu: INFO: rcu_sched self-detected stall on CPU rcu: 0-...!: (332 ticks this GP) idle=255c/1/0x40000000 softirq=16420123/16420123 fqs=0 rcu: (t=2103 jiffies g=35680089 q=4 ncpus=1) rcu: rcu_sched kthread timer wakeup didn't happen for 2102 jiffies! g35680089 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 rcu: Possible timer handling issue on cpu=0 timer-softirq=12779658 rcu: rcu_sched kthread starved for 2103 jiffies! g35680089 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0 rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior. rcu: RCU grace-period kthread stack dump: task:rcu_sched state:I stack:0 pid:14 tgid:14 ppid:2 flags:0x00004000 Call Trace: __schedule+0x258/0x580 schedule+0x19/0xa0 schedule_timeout+0x4a/0xb0 ? hrtimers_cpu_dying+0x1b0/0x1b0 rcu_gp_fqs_loop+0xb1/0x450 rcu_gp_kthread+0x9d/0x130 kthread+0xb2/0xe0 ? rcu_gp_init+0x4a0/0x4a0 ? kthread_park+0x90/0x90 ret_from_fork+0x2d/0x50 ? kthread_park+0x90/0x90 ret_from_fork_asm+0x12/0x20 entry_INT80_32+0x10d/0x10d CPU: 0 UID: 500 PID: 21895 Comm: 31370.exe Not tainted 6.13.0-dirty #2 (here running the libstdc++-v3 testsuite). Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/alpine.DEB.2.21.2603291236590.60268@angie.orcam.me.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-30FDDI: defza: Rate-limit memory allocation errorsMaciej W. Rozycki
Prevent the system from becoming unstable or unusable due to a flood of memory allocation error messages under memory pressure. Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/alpine.DEB.2.21.2603291252380.60268@angie.orcam.me.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-30bnxt_en: set backing store type from query typePengpeng Hou
bnxt_hwrm_func_backing_store_qcaps_v2() stores resp->type from the firmware response in ctxm->type and later uses that value to index fixed backing-store metadata arrays such as ctx_arr[] and bnxt_bstore_to_trace[]. ctxm->type is fixed by the current backing-store query type and matches the array index of ctx->ctx_arr. Set ctxm->type from the current loop variable instead of depending on resp->type. Also update the loop to advance type from next_valid_type in the for statement, which keeps the control flow simpler for non-valid and unchanged entries. Fixes: 6a4d0774f02d ("bnxt_en: Add support for new backing store query firmware API") Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Tested-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20260328234357.43669-1-pengpeng@iscas.ac.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.0.4) at 2026-04-20 23:48:13 +0000