| Age | Commit message (Collapse) | Author |
|---|
|
Management Real Time Clock Query (MRTCQ) register is used to query
hardware clock identity.
Signed-off-by: Jianbo Liu <jianbol@nvidia.com>
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20250109204231.1809851-3-tariqt@nvidia.com
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
Add FEC admin and override related fields in PPLM, and the bit in PCAM
to indicate those fields are supported.
Signed-off-by: Jianbo Liu <jianbol@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20250109204231.1809851-2-tariqt@nvidia.com
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull probes fix from Masami Hiramatsu:
"Fix to free trace_kprobe objects at a failure path in
__trace_kprobe_create() function. This fixes a memory leak"
* tag 'probes-fixes-v6.13-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
tracing/kprobes: Fix to free objects when failed to copy a symbol
|
|
Register a struct led_classdev with the kernel's LED subsystem and
create a throughput-based trigger for it. Then mac80211 makes the LED
blink.
Tested with Tenda U12 (RTL8812AU), Tenda U9 (RTL8811CU), TP-Link Archer
T2U Nano (RTL8811AU), TP-Link Archer T3U Plus (RTL8812BU), Edimax
EW-7611UCB (RTL8821AU), LM842 (RTL8822CU).
Also tested with devices which don't have LEDs: the laptop's internal
RTL8822CE and a no-name RTL8723DU.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/6c43451f-ab2f-4e76-ac6e-ff5a18dd981d@gmail.com
|
|
This is the equivalent of commit 28818b4d871b ("wifi: rtw88: usb: Fix
disconnection after beacon loss") for SDIO chips.
Tested on Pinephone (RTL8723CS), random disconnections became rare,
instead of a frequent nuisance.
Cc: stable@vger.kernel.org
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> # Tested on Pinebook
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250106135434.35936-1-fiona.klute@gmx.de
|
|
Fix 3 typos in 8703b driver. 2 typos in calibration routines are not
fatal and do not seem to have any impact, just fix them to match vendor
driver.
However the last one in rtw8703b_set_channel_bb() clears too many bits
in REG_OFDM0_TX_PSD_NOISE, causing TX and RX issues (neither rate goes
above MCS0-MCS1). Vendor driver clears only 2 most significant bits.
With the last typo fixed, the driver is able to reach MCS7 on Pinebook
Cc: stable@vger.kernel.org
Fixes: 9bb762b3a957 ("wifi: rtw88: Add definitions for 8703b chip")
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Tested-by: Fiona Klute <fiona.klute@gmx.de>
Tested-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250103075107.1337533-1-anarsoul@gmail.com
|
|
It's not used for anything.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/b80f7904-c6b4-4d12-a5f9-69ab9b965732@gmail.com
|
|
Add some extra configuration for USB devices. Currently only RTL8822BU
version (cut) D needs this. The new code makes use of the existing
usb3_param_8822b array from rtw8822b.c.
A user reported that TP-Link Archer T3U in USB 3 mode was randomly
disconnecting from USB:
[ 26.036502] usb 2-2: new SuperSpeed USB device number 3 using xhci_hcd
...
[ 27.576491] usb 2-2: USB disconnect, device number 3
[ 28.621528] usb 2-2: new SuperSpeed USB device number 4 using xhci_hcd
...
[ 45.984521] usb 2-2: USB disconnect, device number 4
...
[ 46.845585] usb 2-2: new SuperSpeed USB device number 5 using xhci_hcd
...
[ 94.400380] usb 2-2: USB disconnect, device number 5
...
[ 95.590421] usb 2-2: new SuperSpeed USB device number 6 using xhci_hcd
This patch fixes that.
Link: https://github.com/lwfinger/rtw88/issues/262
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/9d312b14-0146-4be8-9c50-ef432234db50@gmail.com
|
|
RTL8922AE-VS is a variant of RTL8922AE, which is supported by firmware
version after 0.35.54.0 and only can support up to MCS11. Add a variant
struct to describe these requirements accordingly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250108020955.14668-3-pkshih@realtek.com
|
|
Firmware after version 0.35.51.0 defines and exports more hardware
capabilities, which driver will consider reported QAM field as
EHT MCS capability to register hardware.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250108020955.14668-2-pkshih@realtek.com
|
|
The rtwdev->scanning flag isn't protected by mutex originally, so
cancel_hw_scan can pass the condition, but suddenly hw_scan completion
unset the flag and calls ieee80211_scan_completed() that will free
local->hw_scan_req. Then, cancel_hw_scan raises null-ptr-deref and
use-after-free. Fix it by moving the check condition to where
protected by mutex.
KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f]
CPU: 2 PID: 6922 Comm: kworker/2:2 Tainted: G OE
Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB6WW (2.76 ) 09/10/2019
Workqueue: events cfg80211_conn_work [cfg80211]
RIP: 0010:rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core]
Code: 00 45 89 6c 24 1c 0f 85 23 01 00 00 48 8b 85 20 ff ff ff 48 8d
RSP: 0018:ffff88811fd9f068 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: ffff88811fd9f258 RCX: 0000000000000001
RDX: 0000000000000011 RSI: 0000000000000001 RDI: 0000000000000089
RBP: ffff88811fd9f170 R08: 0000000000000000 R09: 0000000000000000
R10: ffff88811fd9f108 R11: 0000000000000000 R12: ffff88810e47f960
R13: 0000000000000000 R14: 000000000000ffff R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8881d6f00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007531dfca55b0 CR3: 00000001be296004 CR4: 00000000001706e0
Call Trace:
<TASK>
? show_regs+0x61/0x73
? __die_body+0x20/0x73
? die_addr+0x4f/0x7b
? exc_general_protection+0x191/0x1db
? asm_exc_general_protection+0x27/0x30
? rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core]
? rtw89_fw_h2c_scan_offload_be+0x458/0x13c3 [rtw89_core]
? __pfx_rtw89_fw_h2c_scan_offload_be+0x10/0x10 [rtw89_core]
? do_raw_spin_lock+0x75/0xdb
? __pfx_do_raw_spin_lock+0x10/0x10
rtw89_hw_scan_offload+0xb5e/0xbf7 [rtw89_core]
? _raw_spin_unlock+0xe/0x24
? __mutex_lock.constprop.0+0x40c/0x471
? __pfx_rtw89_hw_scan_offload+0x10/0x10 [rtw89_core]
? __mutex_lock_slowpath+0x13/0x1f
? mutex_lock+0xa2/0xdc
? __pfx_mutex_lock+0x10/0x10
rtw89_hw_scan_abort+0x58/0xb7 [rtw89_core]
rtw89_ops_cancel_hw_scan+0x120/0x13b [rtw89_core]
ieee80211_scan_cancel+0x468/0x4d0 [mac80211]
ieee80211_prep_connection+0x858/0x899 [mac80211]
ieee80211_mgd_auth+0xbea/0xdde [mac80211]
? __pfx_ieee80211_mgd_auth+0x10/0x10 [mac80211]
? cfg80211_find_elem+0x15/0x29 [cfg80211]
? is_bss+0x1b7/0x1d7 [cfg80211]
ieee80211_auth+0x18/0x27 [mac80211]
cfg80211_mlme_auth+0x3bb/0x3e7 [cfg80211]
cfg80211_conn_do_work+0x410/0xb81 [cfg80211]
? __pfx_cfg80211_conn_do_work+0x10/0x10 [cfg80211]
? __kasan_check_read+0x11/0x1f
? psi_group_change+0x8bc/0x944
? __kasan_check_write+0x14/0x22
? mutex_lock+0x8e/0xdc
? __pfx_mutex_lock+0x10/0x10
? __pfx___radix_tree_lookup+0x10/0x10
cfg80211_conn_work+0x245/0x34d [cfg80211]
? __pfx_cfg80211_conn_work+0x10/0x10 [cfg80211]
? update_cfs_rq_load_avg+0x3bc/0x3d7
? sched_clock_noinstr+0x9/0x1a
? sched_clock+0x10/0x24
? sched_clock_cpu+0x7e/0x42e
? newidle_balance+0x796/0x937
? __pfx_sched_clock_cpu+0x10/0x10
? __pfx_newidle_balance+0x10/0x10
? __kasan_check_read+0x11/0x1f
? psi_group_change+0x8bc/0x944
? _raw_spin_unlock+0xe/0x24
? raw_spin_rq_unlock+0x47/0x54
? raw_spin_rq_unlock_irq+0x9/0x1f
? finish_task_switch.isra.0+0x347/0x586
? __schedule+0x27bf/0x2892
? mutex_unlock+0x80/0xd0
? do_raw_spin_lock+0x75/0xdb
? __pfx___schedule+0x10/0x10
process_scheduled_works+0x58c/0x821
worker_thread+0x4c7/0x586
? __kasan_check_read+0x11/0x1f
kthread+0x285/0x294
? __pfx_worker_thread+0x10/0x10
? __pfx_kthread+0x10/0x10
ret_from_fork+0x29/0x6f
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
</TASK>
Fixes: 895907779752 ("rtw89: 8852a: add ieee80211_ops::hw_scan")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250107114254.6769-1-pkshih@realtek.com
|
|
For each MCC role, time limits, including max_tob_us, max_toa_us, and
mac_dur_us, are calculated if there are NoA attributes. The relation
between these time limits is "max_dur_us = max_tob_us + max_toa_us".
Then, the unit is converted from us to TU. However, originally, each
time limit was divided by 1024 independently. It missed to consider
the cases that max_tob_us or max_toa_us is not divisible by 1024. It
causes the result breaks "max_dur (TU) = max_tob (TU) + max_toa (TU)".
Finally, when MCC calculates pattern parameters based on these kinds
of time limits, it might not perform well.
Fixes: b09df09b55fb ("wifi: rtw89: mcc: initialize start flow")
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250103074412.124066-1-pkshih@realtek.com
|
|
For early chips, the RX BD info contains FS/LS bits for first/last segments
of a receiving packet. For 8922AE, the FS bit should be ignored, or it
may throw warning:
rtw89_8922ae 0000:1a:00.0: skb should not be ready before first segment start
To have compatible logic, FS determined by what pending skb is existing
(!new) or not.
Since we expect every single receiving packet in single one segment,
enlarge 4 bytes for RX BD info, and add a debug message to note if
RX buffer is possibly smaller than expected size.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250103025126.15378-1-pkshih@realtek.com
|
|
If WoWLAN failed in resume flow, the rtw89_ops_add_interface() triggered
without removing the interface first. Then the mgnt_entry list init again,
causing the list_empty() check in rtw89_chanctx_ops_assign_vif()
useless, and list_add_tail() again. Therefore, we have added a check to
prevent double adding of the list.
rtw89_8852ce 0000:01:00.0: failed to check wow status disabled
rtw89_8852ce 0000:01:00.0: wow: failed to check disable fw ready
rtw89_8852ce 0000:01:00.0: wow: failed to swap to normal fw
rtw89_8852ce 0000:01:00.0: failed to disable wow
rtw89_8852ce 0000:01:00.0: failed to resume for wow -110
rtw89_8852ce 0000:01:00.0: MAC has already powered on
i2c_hid_acpi i2c-ILTK0001:00: PM: acpi_subsys_resume+0x0/0x60 returned 0 after 284705 usecs
list_add corruption. prev->next should be next (ffff9d9719d82228), but was ffff9d9719f96030. (prev=ffff9d9719f96030).
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:34!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 2 PID: 6918 Comm: kworker/u8:19 Tainted: G U O
Hardware name: Google Anraggar/Anraggar, BIOS Google_Anraggar.15217.514.0 03/25/2024
Workqueue: events_unbound async_run_entry_fn
RIP: 0010:__list_add_valid_or_report+0x9f/0xb0
Code: e8 56 89 ff ff 0f 0b 48 c7 c7 3e fc e0 96 48 89 c6 e8 45 89 ff ...
RSP: 0018:ffffa51b42bbbaf0 EFLAGS: 00010246
RAX: 0000000000000075 RBX: ffff9d9719d82ab0 RCX: 13acb86e047a4400
RDX: 3fffffffffffffff RSI: 0000000000000000 RDI: 00000000ffffdfff
RBP: ffffa51b42bbbb28 R08: ffffffff9768e250 R09: 0000000000001fff
R10: ffffffff9765e250 R11: 0000000000005ffd R12: ffff9d9719f95c40
R13: ffff9d9719f95be8 R14: ffff9d97081bfd78 R15: ffff9d9719d82060
FS: 0000000000000000(0000) GS:ffff9d9a6fb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007e7d029a4060 CR3: 0000000345e38000 CR4: 0000000000750ee0
PKRU: 55555554
Call Trace:
<TASK>
? __die_body+0x68/0xb0
? die+0xaa/0xd0
? do_trap+0x9f/0x170
? __list_add_valid_or_report+0x9f/0xb0
? __list_add_valid_or_report+0x9f/0xb0
? handle_invalid_op+0x69/0x90
? __list_add_valid_or_report+0x9f/0xb0
? exc_invalid_op+0x3c/0x50
? asm_exc_invalid_op+0x16/0x20
? __list_add_valid_or_report+0x9f/0xb0
rtw89_chanctx_ops_assign_vif+0x1f9/0x210 [rtw89_core cbb375c44bf28564ce479002bff66617a25d9ac1]
? __mutex_unlock_slowpath+0xa0/0xf0
rtw89_ops_assign_vif_chanctx+0x4b/0x90 [rtw89_core cbb375c44bf28564ce479002bff66617a25d9ac1]
drv_assign_vif_chanctx+0xa7/0x1f0 [mac80211 6efaad16237edaaea0868b132d4f93ecf918a8b6]
ieee80211_reconfig+0x9cb/0x17b0 [mac80211 6efaad16237edaaea0868b132d4f93ecf918a8b6]
? __pfx_wiphy_resume+0x10/0x10 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed]
? dev_printk_emit+0x51/0x70
? _dev_info+0x6e/0x90
wiphy_resume+0x89/0x180 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed]
? __pfx_wiphy_resume+0x10/0x10 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed]
dpm_run_callback+0x37/0x1e0
device_resume+0x26d/0x4b0
? __pfx_dpm_watchdog_handler+0x10/0x10
async_resume+0x1d/0x30
async_run_entry_fn+0x29/0xd0
worker_thread+0x397/0x970
kthread+0xed/0x110
? __pfx_worker_thread+0x10/0x10
? __pfx_kthread+0x10/0x10
ret_from_fork+0x38/0x50
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
</TASK>
Fixes: 68ec751b2881 ("wifi: rtw89: chan: manage active interfaces")
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250103024500.14990-1-pkshih@realtek.com
|
|
Header conversion should only be used with MLO connections. Otherwise
P2P connection fails due to wrong probe responses sent. Fix it
accordingly.
Fixes: b8499664fca9 ("wifi: rtw89: Add header conversion for MLO connections")
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241231004811.8646-4-pkshih@realtek.com
|
|
During rtw89_entity_recalc_mgnt_roles(), there is a normalizing process
which will re-order the list if an entry with target pattern is found.
And once one is found, should have aborted the list_for_each_entry. But,
`break` just aborted the inner for-loop. The outer list_for_each_entry
still continues. Normally, only the first entry will match the target
pattern, and the re-ordering will change nothing, so there won't be
soft lockup. However, in some special cases, soft lockup would happen.
Fix it by `goto fill` to break from the list_for_each_entry.
The following is a sample of kernel log for this problem.
watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [wpa_supplicant:2055]
[...]
RIP: 0010:rtw89_entity_recalc ([...] chan.c:392 chan.c:479) rtw89_core
[...]
Fixes: 68ec751b2881 ("wifi: rtw89: chan: manage active interfaces")
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241231004811.8646-3-pkshih@realtek.com
|
|
When starting/proceeding MCC, it will abort an ongoing hw scan process.
In the proceeding cases, it unexpectedly tries to abort a non-exist hw
scan process. Then, a trace shown at the bottom will happen. This problem
is caused by a previous commit which changed some call sequence inside
rtw89_hw_scan_complete() to fix some coex problems. These changes lead
to our scanning flag was not cleared when proceeding MCC. To keep the
fixes on coex, and resolve the problem here, re-consider the related
call sequence.
The known sequence requirements are listed below.
* the old sequence:
A. notify coex
B. clear scanning flag
C. proceed chanctx
C-1. set channel
C-2. proceed MCC
(the problem: A needs to be after C-1)
* the current sequence:
C. proceed chanctx
C-1. set channel
C-2. proceed MCC
A. notify coex
B. clear scanning flag
(the problem: C-2 needs to be after B)
So, now let hw scan caller pass a callback to proceed chanctx if needed.
Then, the new sequence will be like the below.
C-1. set channel
A. notify coex
B. clear scanning flag
C-2. proceed MCC
The following is the kernel log for the problem in current sequence.
rtw89_8852be 0000:04:00.0: rtw89_hw_scan_offload failed ret -110
------------[ cut here ]------------
[...]
CPU: 2 PID: 3991 Comm: kworker/u16:0 Tainted: G OE 6.6.17 #3
Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018
Workqueue: events_unbound wiphy_work_cancel [cfg80211]
RIP: 0010:ieee80211_sched_scan_stopped+0xaea/0xd80 [mac80211]
Code: 9c 24 d0 11 00 00 49 39 dd 0f 85 46 ff ff ff 4c 89 e7 e8 09 2d
RSP: 0018:ffffb27783643d48 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff8a2280964bc0 RSI: 0000000000000000 RDI: ffff8a23df580900
RBP: ffffb27783643d88 R08: 0000000000000001 R09: 0000000000000400
R10: 0000000000000000 R11: 0000000000008268 R12: ffff8a23df580900
R13: ffff8a23df581b00 R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8a258e680000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f26a0654000 CR3: 000000002ea2e002 CR4: 00000000001706e0
Call Trace:
<TASK>
? show_regs+0x68/0x70
? ieee80211_sched_scan_stopped+0xaea/0xd80 [mac80211]
? __warn+0x8f/0x150
? ieee80211_sched_scan_stopped+0xaea/0xd80 [mac80211]
? report_bug+0x1f5/0x200
? handle_bug+0x46/0x80
? exc_invalid_op+0x19/0x70
? asm_exc_invalid_op+0x1b/0x20
? ieee80211_sched_scan_stopped+0xaea/0xd80 [mac80211]
ieee80211_scan_work+0x14a/0x650 [mac80211]
? __queue_work+0x10f/0x410
wiphy_work_cancel+0x2fb/0x310 [cfg80211]
process_scheduled_works+0x9d/0x390
? __pfx_worker_thread+0x10/0x10
worker_thread+0x15b/0x2d0
? __pfx_worker_thread+0x10/0x10
kthread+0x108/0x140
? __pfx_kthread+0x10/0x10
ret_from_fork+0x3c/0x60
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
</TASK>
---[ end trace 0000000000000000 ]---
Fixes: f16c40acd319 ("wifi: rtw89: Fix TX fail with A2DP after scanning")
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241231004811.8646-2-pkshih@realtek.com
|
|
Limit ETS QoS channel to AIROHA_NUM_QOS_CHANNELS in
airoha_tc_setup_qdisc_ets() in order to align the configured channel to
the value set in airoha_dev_select_queue().
Fixes: 20bf7d07c956 ("net: airoha: Add sched ETS offload support")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
Link: https://patch.msgid.link/20250107-airoha-ets-fix-chan-v1-1-97f66ed3a068@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Here "buf" is a void pointer so sizeof(*buf) is one. Doing a divide
by one makes the code less readable. Delete it.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Link: https://patch.msgid.link/ee1a790b-f874-4512-b3ae-9c45f99dc640@stanley.mountain
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The DP83822 supports up to three configurable Light Emitting Diode (LED)
pins: LED_0, LED_1 (GPIO1), COL (GPIO2) and RX_D3 (GPIO3). Several
functions can be multiplexed onto the LEDs for different modes of
operation. LED_0 and COL (GPIO2) use the MLED function. MLED can be routed
to only one of these two pins at a time. Add minimal LED controller driver
supporting the most common uses with the 'netdev' trigger.
Signed-off-by: Dimitri Fedrau <dima.fedrau@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20250107-dp83822-leds-v2-1-5b260aad874f@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
Pull hwmon fix from Guenter Roeck:
"One patch to fix error handling in drivetemp driver"
* tag 'hwmon-for-v6.13-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
hwmon: (drivetemp) Fix driver producing garbage data when SCSI errors occur
|
|
Pull block fix from Jens Axboe:
"A single fix for a use-after-free in the BFQ IO scheduler"
* tag 'block-6.13-20250111' of git://git.kernel.dk/linux:
block, bfq: fix waker_bfqq UAF after bfq_split_bfqq()
|
|
Pull io_uring fixes from Jens Axboe:
- Fix for multishot timeout updates only using the updated value for
the first invocation, not subsequent ones
- Silence a false positive lockdep warning
- Fix the eventfd signaling and putting RCU logic
- Fix fault injected SQPOLL setup not clearing the task pointer in the
error path
- Fix local task_work looking at the SQPOLL thread rather than just
signaling the safe variant. Again one of those theoretical issues,
which should be closed up none the less.
* tag 'io_uring-6.13-20250111' of git://git.kernel.dk/linux:
io_uring: don't touch sqd->thread off tw add
io_uring/sqpoll: zero sqd->thread on tctx errors
io_uring/eventfd: ensure io_eventfd_signal() defers another RCU period
io_uring: silence false positive warnings
io_uring/timeout: fix multishot updates
|
|
Pull smb client fix from Steve French:
- fix unneeded session setup retry due to stale password e.g. for DFS
automounts
* tag '6.13-rc6-SMB3-client-fix' of git://git.samba.org/sfrench/cifs-2.6:
smb: client: sync the root session and superblock context passwords before automounting
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull SoC fixes from Arnd Bergmann:
"Over the Christmas break a couple of devicetree fixes came in for
Rockchips, Qualcomm and NXP/i.MX. These add some missing board
specific properties, address build time warnings,
The USB/TOG supoprt on X1 Elite regressed, so two earlier DT changes
get reverted for now.
Aside from the devicetree fixes, there is One build fix for the stm32
firewall driver, and a defconfig change to enable SPDIF support for
i.MX"
* tag 'soc-fixes-6.13-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
firewall: remove misplaced semicolon from stm32_firewall_get_firewall
arm64: dts: rockchip: add hevc power domain clock to rk3328
arm64: dts: rockchip: Fix the SD card detection on NanoPi R6C/R6S
arm64: dts: qcom: sa8775p: fix the secure device bootup issue
Revert "arm64: dts: qcom: x1e80100: enable OTG on USB-C controllers"
Revert "arm64: dts: qcom: x1e80100-crd: enable otg on usb ports"
arm64: dts: qcom: x1e80100: Fix up BAR space size for PCIe6a
Revert "arm64: dts: qcom: x1e78100-t14s: enable otg on usb-c ports"
ARM: dts: imxrt1050: Fix clocks for mmc
ARM: imx_v6_v7_defconfig: enable SND_SOC_SPDIF
arm64: dts: imx95: correct the address length of netcmix_blk_ctrl
arm64: dts: imx8-ss-audio: add fallback compatible string fsl,imx6ull-esai for esai
arm64: dts: rockchip: rename rfkill label for Radxa ROCK 5B
arm64: dts: rockchip: add reset-names for combphy on rk3568
arm64: dts: qcom: sa8775p: Fix the size of 'addr_space' regions
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next
Marc Kleine-Budde says:
====================
pull-request: can-next 2025-01-10
Pierre-Henry Moussay adds PIC64GX compatibility to the DT bindings for
Microchip's mpfs-can IP core.
The next 3 patches are by Sean Nyekjaer and target the tcan4x5x
driver. First the DT bindings is converted to DT schema, then nWKRQ
voltage selection is added to the driver.
Dario Binacchi's patch for the sun4i_can makes the driver more
consistent by adding a likely() to the driver.
Another patch by Sean Nyekjaer for the tcan4x5x driver gets rid of a
false error message.
Charan Pedumuru converts the atmel-can DT bindings to DT schema.
The next 2 patches are by Oliver Hartkopp. The first one maps Oliver's
former mail addresses to a dedicated CAN mail address. The second one
assigns net/sched/em_canid.c additionally to the CAN maintainers.
Ariel Otilibili's patch removes dead code from the CAN dev helper.
The next 3 patches are by Sean Nyekjaer and add HW standby support to
the tcan4x5x driver.
A patch by Dario Binacchi fixes the DT bindings for the st,stm32-bxcan
driver.
The last 4 patches are by Jimmy Assarsson and target the kvaser_usb
and the kvaser_pciefd driver: error statistics are improved and
CAN_CTRLMODE_BERR_REPORTING is added.
* tag 'linux-can-next-for-6.14-20250110' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next:
can: kvaser_pciefd: Add support for CAN_CTRLMODE_BERR_REPORTING
can: kvaser_pciefd: Update stats and state even if alloc_can_err_skb() fails
can: kvaser_usb: Add support for CAN_CTRLMODE_BERR_REPORTING
can: kvaser_usb: Update stats and state even if alloc_can_err_skb() fails
dt-bindings: can: st,stm32-bxcan: fix st,gcan property type
can: m_can: call deinit/init callback when going into suspend/resume
can: tcan4x5x: add deinit callback to set standby mode
can: m_can: add deinit callback
can: dev: can_get_state_str(): Remove dead code
MAINTAINERS: assign em_canid.c additionally to CAN maintainers
mailmap: add an entry for Oliver Hartkopp
dt-bindings: net: can: atmel: Convert to json schema
can: tcan4x5x: get rid of false clock errors
can: sun4i_can: continue to use likely() to check skb
can: tcan4x5x: add option for selecting nWKRQ voltage
dt-bindings: can: tcan4x5x: Document the ti,nwkrq-voltage-vio option
dt-bindings: can: convert tcan4x5x.txt to DT schema
dt-bindings: can: mpfs: add PIC64GX CAN compatibility
====================
Link: https://patch.msgid.link/20250110112712.3214173-1-mkl@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
There are no module callers of dev_get_by_napi_id(),
and commit d1cacd747768 ("netdev: prevent accessing NAPI instances
from another namespace") proves that getting NAPI by id
needs to be done with care. So hide dev_get_by_napi_id().
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Reviewed-by: Joe Damato <jdamato@fastly.com>
Link: https://patch.msgid.link/20250110004924.3212260-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Dump continuation depends on the NAPI list being sorted.
Broken netlink dump continuation may be rare and hard to debug
so add a warning if we notice the potential problem while walking
the list.
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
Reviewed-by: Joe Damato <jdamato@fastly.com>
Link: https://patch.msgid.link/20250110004505.3210140-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
In all 3 cases (cpsw, cpsw-new, am65-cpsw) ALE is being configured in
VLAN-aware mode, while the comment states the opposite. Seems to be a typo
copy-pasted from one driver to another. Fix the commend which has been
puzzling some people (including me) for at least a decade.
Link: https://lore.kernel.org/linux-arm-kernel/4699400.vD3TdgH1nR@localhost/
Link: https://lore.kernel.org/netdev/0106ce78-c83f-4552-a234-1bf7a33f1ed1@kernel.org/
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250109214219.123767-1-alexander.sverdlin@siemens.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
syzbot reported a problem when calling setsockopt(SO_SNDBUF) after a
rekey. SO_SNDBUF calls sk_write_space, ie tls_write_space, which then
calls the original socket's sk_write_space, saved in
ctx->sk_write_space. Rekeys should skip re-assigning
ctx->sk_write_space, so we don't end up with tls_write_space calling
itself.
Fixes: 47069594e67e ("tls: implement rekey for TLS1.3")
Reported-by: syzbot+6ac73b3abf1b598863fa@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/676d231b.050a0220.2f3838.0461.GAE@google.com/
Tested-by: syzbot+6ac73b3abf1b598863fa@syzkaller.appspotmail.com
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Link: https://patch.msgid.link/ffdbe4de691d1c1eead556bbf42e33ae215304a7.1736436785.git.sd@queasysnail.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Commit in a fixes tag attempted to fix the issue in the following
sequence of calls:
do_output
-> ovs_vport_send
-> dev_queue_xmit
-> __dev_queue_xmit
-> netdev_core_pick_tx
-> skb_tx_hash
When device is unregistering, the 'dev->real_num_tx_queues' goes to
zero and the 'while (unlikely(hash >= qcount))' loop inside the
'skb_tx_hash' becomes infinite, locking up the core forever.
But unfortunately, checking just the carrier status is not enough to
fix the issue, because some devices may still be in unregistering
state while reporting carrier status OK.
One example of such device is a net/dummy. It sets carrier ON
on start, but it doesn't implement .ndo_stop to set the carrier off.
And it makes sense, because dummy doesn't really have a carrier.
Therefore, while this device is unregistering, it's still easy to hit
the infinite loop in the skb_tx_hash() from the OVS datapath. There
might be other drivers that do the same, but dummy by itself is
important for the OVS ecosystem, because it is frequently used as a
packet sink for tcpdump while debugging OVS deployments. And when the
issue is hit, the only way to recover is to reboot.
Fix that by also checking if the device is running. The running
state is handled by the net core during unregistering, so it covers
unregistering case better, and we don't really need to send packets
to devices that are not running anyway.
While only checking the running state might be enough, the carrier
check is preserved. The running and the carrier states seem disjoined
throughout the code and different drivers. And other core functions
like __dev_direct_xmit() check both before attempting to transmit
a packet. So, it seems safer to check both flags in OVS as well.
Fixes: 066b86787fa3 ("net: openvswitch: fix race on port output")
Reported-by: Friedrich Weber <f.weber@proxmox.com>
Closes: https://mail.openvswitch.org/pipermail/ovs-discuss/2025-January/053423.html
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Tested-by: Friedrich Weber <f.weber@proxmox.com>
Reviewed-by: Aaron Conole <aconole@redhat.com>
Link: https://patch.msgid.link/20250109122225.4034688-1-i.maximets@ovn.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When tx_max_frame_size was added to struct ravb_hw_info, no value was
set in ravb_rzv2m_hw_info so the default value of zero was used.
The maximum MTU is set by subtracting from tx_max_frame_size to allow
space for headers and frame checksums. As ndev->max_mtu is unsigned,
this subtraction wraps around leading to a ridiculously large positive
value that is obviously incorrect.
Before tx_max_frame_size was introduced, the maximum MTU was based on
rx_max_frame_size. So, we can restore the correct maximum MTU by copying
the rx_max_frame_size value into tx_max_frame_size for RZ/V2M.
Fixes: 1d63864299ca ("net: ravb: Fix maximum TX frame size for GbEth devices")
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Link: https://patch.msgid.link/20250109113706.1409149-1-paul.barker.ct@bp.renesas.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
hwprov should be protected by rcu_read_lock to prevent possible UAF
Fixes: 4c61d809cf60 ("net: ethtool: Fix suspicious rcu_dereference usage")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Acked-by: Kory Maincent <kory.maincent@bootlin.com>
diff with v1: move and use err varialbe, instead of define a new variable
net/ethtool/common.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Link: https://patch.msgid.link/20250109111057.4746-1-lirongqing@baidu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
In mana_driver_exit(), mana_debugfs_root gets cleanup before any of it's
children (which happens later in the pci_unregister_driver()).
Due to this, when mana driver is configured as a module and rmmod is
invoked, following stack gets printed along with failure in rmmod command.
[ 2399.317651] BUG: kernel NULL pointer dereference, address: 0000000000000098
[ 2399.318657] #PF: supervisor write access in kernel mode
[ 2399.319057] #PF: error_code(0x0002) - not-present page
[ 2399.319528] PGD 10eb68067 P4D 0
[ 2399.319914] Oops: Oops: 0002 [#1] SMP NOPTI
[ 2399.320308] CPU: 72 UID: 0 PID: 5815 Comm: rmmod Not tainted 6.13.0-rc5+ #89
[ 2399.320986] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024
[ 2399.321892] RIP: 0010:down_write+0x1a/0x50
[ 2399.322303] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 54 49 89 fc e8 9d cd ff ff 31 c0 ba 01 00 00 00 <f0> 49 0f b1 14 24 75 17 65 48 8b 05 f6 84 dd 5f 49 89 44 24 08 4c
[ 2399.323669] RSP: 0018:ff53859d6c663a70 EFLAGS: 00010246
[ 2399.324061] RAX: 0000000000000000 RBX: ff1d4eb505060180 RCX: ffffff8100000000
[ 2399.324620] RDX: 0000000000000001 RSI: 0000000000000064 RDI: 0000000000000098
[ 2399.325167] RBP: ff53859d6c663a78 R08: 00000000000009c4 R09: ff1d4eb4fac90000
[ 2399.325681] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000098
[ 2399.326185] R13: ff1d4e42e1a4a0c8 R14: ff1d4eb538ce0000 R15: 0000000000000098
[ 2399.326755] FS: 00007fe729570000(0000) GS:ff1d4eb2b7200000(0000) knlGS:0000000000000000
[ 2399.327269] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2399.327690] CR2: 0000000000000098 CR3: 00000001c0584005 CR4: 0000000000373ef0
[ 2399.328166] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2399.328623] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
[ 2399.329055] Call Trace:
[ 2399.329243] <TASK>
[ 2399.329379] ? show_regs+0x69/0x80
[ 2399.329602] ? __die+0x25/0x70
[ 2399.329856] ? page_fault_oops+0x271/0x550
[ 2399.330088] ? psi_group_change+0x217/0x470
[ 2399.330341] ? do_user_addr_fault+0x455/0x7b0
[ 2399.330667] ? finish_task_switch.isra.0+0x91/0x2f0
[ 2399.331004] ? exc_page_fault+0x73/0x160
[ 2399.331275] ? asm_exc_page_fault+0x27/0x30
[ 2399.343324] ? down_write+0x1a/0x50
[ 2399.343631] simple_recursive_removal+0x4d/0x2c0
[ 2399.343977] ? __pfx_remove_one+0x10/0x10
[ 2399.344251] debugfs_remove+0x45/0x70
[ 2399.344511] mana_destroy_rxq+0x44/0x400 [mana]
[ 2399.344845] mana_destroy_vport+0x54/0x1c0 [mana]
[ 2399.345229] mana_detach+0x2f1/0x4e0 [mana]
[ 2399.345466] ? ida_free+0x150/0x160
[ 2399.345718] ? __cond_resched+0x1a/0x50
[ 2399.345987] mana_remove+0xf4/0x1a0 [mana]
[ 2399.346243] mana_gd_remove+0x25/0x80 [mana]
[ 2399.346605] pci_device_remove+0x41/0xb0
[ 2399.346878] device_remove+0x46/0x70
[ 2399.347150] device_release_driver_internal+0x1e3/0x250
[ 2399.347831] ? klist_remove+0x81/0xe0
[ 2399.348377] driver_detach+0x4b/0xa0
[ 2399.348906] bus_remove_driver+0x83/0x100
[ 2399.349435] driver_unregister+0x31/0x60
[ 2399.349919] pci_unregister_driver+0x40/0x90
[ 2399.350492] mana_driver_exit+0x1c/0xb50 [mana]
[ 2399.351102] __do_sys_delete_module.constprop.0+0x184/0x320
[ 2399.351664] ? __fput+0x1a9/0x2d0
[ 2399.352200] __x64_sys_delete_module+0x12/0x20
[ 2399.352760] x64_sys_call+0x1e66/0x2140
[ 2399.353316] do_syscall_64+0x79/0x150
[ 2399.353813] ? syscall_exit_to_user_mode+0x49/0x230
[ 2399.354346] ? do_syscall_64+0x85/0x150
[ 2399.354816] ? irqentry_exit+0x1d/0x30
[ 2399.355287] ? exc_page_fault+0x7f/0x160
[ 2399.355756] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 2399.356302] RIP: 0033:0x7fe728d26aeb
[ 2399.356776] Code: 73 01 c3 48 8b 0d 45 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 15 33 0f 00 f7 d8 64 89 01 48
[ 2399.358372] RSP: 002b:00007ffff954d6f8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
[ 2399.359066] RAX: ffffffffffffffda RBX: 00005609156cc760 RCX: 00007fe728d26aeb
[ 2399.359779] RDX: 000000000000000a RSI: 0000000000000800 RDI: 00005609156cc7c8
[ 2399.360535] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 2399.361261] R10: 00007fe728dbeac0 R11: 0000000000000206 R12: 00007ffff954d950
[ 2399.361952] R13: 00005609156cc2a0 R14: 00007ffff954ee5f R15: 00005609156cc760
[ 2399.362688] </TASK>
Fixes: 6607c17c6c5e ("net: mana: Enable debugfs files for MANA device")
Cc: stable@vger.kernel.org
Signed-off-by: Shradha Gupta <shradhagupta@linux.microsoft.com>
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
Link: https://patch.msgid.link/1736398991-764-1-git-send-email-shradhagupta@linux.microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Etienne Champetier says:
====================
ipvlan: Support bonding events
====================
Link: https://patch.msgid.link/20250109032819.326528-1-champetier.etienne@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
This rework bond_macvlan.sh into bond_macvlan_ipvlan.sh
We only test bridge mode for macvlan and l2 mode
]# ./bond_macvlan_ipvlan.sh
TEST: active-backup/macvlan_bridge: IPv4: client->server [ OK ]
...
TEST: active-backup/ipvlan_l2: IPv4: client->server [ OK ]
...
TEST: balance-tlb/macvlan_bridge: IPv4: client->server [ OK ]
...
TEST: balance-tlb/ipvlan_l2: IPv4: client->server [ OK ]
...
TEST: balance-alb/macvlan_bridge: IPv4: client->server [ OK ]
...
TEST: balance-alb/ipvlan_l2: IPv4: client->server [ OK ]
...
Signed-off-by: Etienne Champetier <champetier.etienne@gmail.com>
Link: https://patch.msgid.link/20250109032819.326528-3-champetier.etienne@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
This allows ipvlan to function properly on top of
bonds using active-backup mode.
This was implemented for macvlan in 2014 in commit
4c9912556867 ("macvlan: Support bonding events").
Signed-off-by: Etienne Champetier <champetier.etienne@gmail.com>
Link: https://patch.msgid.link/20250109032819.326528-2-champetier.etienne@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Commit 86e25f40aa1e ("net: napi: Add napi_config") moved napi->napi_id
assignment to a later point in time (napi_hash_add_with_id). This breaks
__xdp_rxq_info_reg which copies napi_id at an earlier time and now
stores 0 napi_id. It also makes sk_mark_napi_id_once_xdp and
__sk_mark_napi_id_once useless because they now work against 0 napi_id.
Since sk_busy_loop requires valid napi_id to busy-poll on, there is no way
to busy-poll AF_XDP sockets anymore.
Bring back the ability to busy-poll on XSK by resolving socket's napi_id
at bind time. This relies on relatively recent netif_queue_set_napi,
but (assume) at this point most popular drivers should have been converted.
This also removes per-tx/rx cycles which used to check and/or set
the napi_id value.
Confirmed by running a busy-polling AF_XDP socket
(github.com/fomichev/xskrtt) on mlx5 and looking at BusyPollRxPackets
from /proc/net/netstat.
Fixes: 86e25f40aa1e ("net: napi: Add napi_config")
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Acked-by: Magnus Karlsson <magnus.karlsson@intel.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20250109003436.2829560-1-sdf@fomichev.me
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Recalculate features when XDP is detached.
Before:
# ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp
# ip li set dev eth0 xdp off
# ethtool -k eth0 | grep gro
rx-gro-hw: off [requested on]
After:
# ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp
# ip li set dev eth0 xdp off
# ethtool -k eth0 | grep gro
rx-gro-hw: on
The fact that HW-GRO doesn't get re-enabled automatically is just
a minor annoyance. The real issue is that the features will randomly
come back during another reconfiguration which just happens to invoke
netdev_update_features(). The driver doesn't handle reconfiguring
two things at a time very robustly.
Starting with commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in
__bnxt_reserve_rings()") we only reconfigure the RSS hash table
if the "effective" number of Rx rings has changed. If HW-GRO is
enabled "effective" number of rings is 2x what user sees.
So if we are in the bad state, with HW-GRO re-enablement "pending"
after XDP off, and we lower the rings by / 2 - the HW-GRO rings
doing 2x and the ethtool -L doing / 2 may cancel each other out,
and the:
if (old_rx_rings != bp->hw_resc.resv_rx_rings &&
condition in __bnxt_reserve_rings() will be false.
The RSS map won't get updated, and we'll crash with:
BUG: kernel NULL pointer dereference, address: 0000000000000168
RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0
bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180
__bnxt_setup_vnic_p5+0x58/0x110
bnxt_init_nic+0xb72/0xf50
__bnxt_open_nic+0x40d/0xab0
bnxt_open_nic+0x2b/0x60
ethtool_set_channels+0x18c/0x1d0
As we try to access a freed ring.
The issue is present since XDP support was added, really, but
prior to commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in
__bnxt_reserve_rings()") it wasn't causing major issues.
Fixes: 1054aee82321 ("bnxt_en: Use NETIF_F_GRO_HW.")
Fixes: 98ba1d931f61 ("bnxt_en: Fix RSS logic in __bnxt_reserve_rings()")
Reviewed-by: Michael Chan <michael.chan@broadcom.com>
Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
Link: https://patch.msgid.link/20250109043057.2888953-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
As pointed out in the original comment, lookup in sockmap can return a TCP
ESTABLISHED socket. Such TCP socket may have had SO_ATTACH_REUSEPORT_EBPF
set before it was ESTABLISHED. In other words, a non-NULL sk_reuseport_cb
does not imply a non-refcounted socket.
Drop sk's reference in both error paths.
unreferenced object 0xffff888101911800 (size 2048):
comm "test_progs", pid 44109, jiffies 4297131437
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
80 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 9336483b):
__kmalloc_noprof+0x3bf/0x560
__reuseport_alloc+0x1d/0x40
reuseport_alloc+0xca/0x150
reuseport_attach_prog+0x87/0x140
sk_reuseport_attach_bpf+0xc8/0x100
sk_setsockopt+0x1181/0x1990
do_sock_setsockopt+0x12b/0x160
__sys_setsockopt+0x7b/0xc0
__x64_sys_setsockopt+0x1b/0x30
do_syscall_64+0x93/0x180
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Fixes: 64d85290d79c ("bpf: Allow bpf_map_lookup_elem for SOCKMAP and SOCKHASH")
Signed-off-by: Michal Luczaj <mhal@rbox.co>
Reviewed-by: Martin KaFai Lau <martin.lau@kernel.org>
Link: https://patch.msgid.link/20250110-reuseport-memleak-v1-1-fa1ddab0adfe@rbox.co
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Russell King says:
====================
net: stmmac: clean up and fix EEE implementation
This is a rework of stmmac's EEE support in light of the addition of EEE
management to phylib. It's slightly more than 15 patches, but I think it
makes sense to be so.
Patch 1 adds configuration of the receive clock phy_eee_rx_clock_stop()
(which was part of another series, but is necessary for this patch set.)
Patch 2 converts stmmac to use phylib's tracking of tx_lpi_timer.
Patch 3 corrects the data type used for things involving the LPI
timer. The user API uses u32, so stmmac should do too, rather than
blindly converting it to "int". eee_timer is left for patch 4.
Patch 4 (new) uses an unsigned int for eee_timer.
Patch 5 makes stmmac EEE state depend on phylib's enable_tx_lpi flag,
thus using phylib's resolution of EEE state.
Patch 6 removes redundant code from the ethtool EEE operations.
Patch 7 removes some redundant code in stmmac_disable_eee_mode()
and renames it to stmmac_disable_sw_eee_mode() to better reflect its
purpose.
Patch 8 removes the driver private tx_lpi_enabled, which is managed by
phylib since patch 4.
Patch 9 removes the dependence of EEE error statistics on the EEE
enable state, instead depending on whether EEE is supported by the
hardware.
Patch 10 removes phy_init_eee(), instead using phy_eee_rx_clock_stop()
to configure whether the PHY may stop the receive clock.
Patch 11 removes priv->eee_tw_timer, which is only ever set to one
value at probe time, effectively it is a constant. Hence this is
unnecessary complexity.
Patch 12 moves priv->eee_enabled into stmmac_eee_init(), and placing
it under the protection of priv->lock, except when EEE is not
supported (where it becomes constant-false.)
Patch 13 moves priv->eee_active also into stmmac_eee_init(), so
the indication whether EEE should be enabled or not is passed in
to this function.
Since both priv->eee_enabled and priv->eee_active are assigned
true/false values, they should be typed "bool". Make it sew in
patch 14. No Singer machine required.
Patch 15 moves the initialisation of priv->eee_ctrl_timer to the
probe function - it makes no sense to re-initialise the timer each
time we want to start using it.
Patch 16 removes the unnecessary EEE handling in the driver tear-down
method. The core net code will have brought the interface down
already, meaning EEE has already been disabled.
Patch 17 reorganises the code to split the hardware LPI timer
control paths from the software LPI timer paths.
Patch 18 works on this further by eliminating
stmmac_lpi_entry_timer_config() and making direct calls to the new
functions. This reveals a potential bug where priv->eee_sw_timer_en
is set true when EEE is disabled. This is not addressed in this
series, but will be in a future separate patch - so that if fixing
that causes a regression, it can be handled separately.
====================
Link: https://patch.msgid.link/Z36sHIlnExQBuFJE@shell.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Remove stmmac_lpi_entry_timer_config(), setting priv->eee_sw_timer_en
at the original call sites, and calling the appropriate
stmmac_xxx_hw_lpi_timer() function. No functional change.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1tVZEq-0002LQ-PC@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Provide stmmac_disable_hw_lpi_timer() and stmmac_enable_hw_lpi_timer()
to control the hardware transmit LPI timer.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1tVZEl-0002LK-LA@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
phylink_stop() will cause phylink to call the mac_link_down() operation
before phylink_stop() returns. As mac_link_down() will call
stmmac_eee_init(false), this will set both priv->eee_active and
priv->eee_enabled to be false, deleting the eee_ctrl_timer if
priv->eee_enabled was previously set.
As stmmac_release() calls phylink_stop() before checking whether
priv->eee_enabled is true, this is a condition that can never be
satisfied, and thus the code within this if() block will never be
executed. Remove it.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1tVZEg-0002LE-HH@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Move the initialisation of the EEE software timer to the probe function
as it is unnecessary to do this each time we enable software LPI.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1tVZEb-0002L8-DJ@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
priv->eee_enabled and priv->eee_active are both assigned using boolean
values. Type them as bool rather than int.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1tVZEW-0002L2-9w@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Since all call sites of stmmac_eee_init() assign priv->eee_active
immediately before, pass this state into stmmac_eee_init() and
assign priv->eee_active within this function.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1tVZER-0002Kv-5O@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
All call sites for stmmac_eee_init() assign the return code to
priv->eee_enabled. Rather than having this coded at each call site,
move the assignment inside stmmac_eee_init().
Since stmmac_init_eee() takes priv->lock before checking the state of
priv->eee_enabled, move the assignment within the locked region. Also,
stmmac_suspend() checks the state of this member under the lock. While
two concurrent calls to stmmac_init_eee() aren't possible, there is
a possibility that stmmac_suspend() may run concurrently with a change
of priv->eee_enabled unless we modify it under the lock.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1tVZEM-0002Kq-2Z@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
priv->eee_tw_timer is only assigned during initialisation to a
constant value (STMMAC_DEFAULT_TWT_LS) and then never changed.
Remove priv->eee_tw_timer, and instead use STMMAC_DEFAULT_TWT_LS
for both uses in stmmac_eee_init().
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1tVZEG-0002Kk-VH@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Convert stmmac to use phy_eee_rx_clock_stop() to set the PHY receive
clock stop in LPI setting, rather than calling the legacy
phy_init_eee() function.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1tVZEB-0002Ke-RZ@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
