summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-11-09neighbour: Convert seq_file functions to use hlistGilad Naaman
Convert seq_file-related neighbour functionality to use neighbour::hash and the related for_each macro. Signed-off-by: Gilad Naaman <gnaaman@drivenets.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20241107160444.2913124-4-gnaaman@drivenets.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09neighbour: Define neigh_for_each_in_bucketGilad Naaman
Introduce neigh_for_each_in_bucket in neighbour.h, to help iterate over the neighbour table more succinctly. Signed-off-by: Gilad Naaman <gnaaman@drivenets.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20241107160444.2913124-3-gnaaman@drivenets.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09neighbour: Add hlist_node to struct neighbourGilad Naaman
Add a doubly-linked node to neighbours, so that they can be deleted without iterating the entire bucket they're in. Signed-off-by: Gilad Naaman <gnaaman@drivenets.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20241107160444.2913124-2-gnaaman@drivenets.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09Merge branch 'r8169-improve-wol-suspend-related-code'Jakub Kicinski
Heiner Kallweit says: ==================== r8169: improve wol/suspend-related code This series improves wol/suspend-related code parts. ==================== Link: https://patch.msgid.link/be734d10-37f7-4830-b7c2-367c0a656c08@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09r8169: align WAKE_PHY handling with r8125/r8126 vendor driversHeiner Kallweit
Vendor drivers r8125/r8126 apply this additional magic setting when enabling WAKE_PHY, so do the same here. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/51130715-45be-4db5-abb7-05d87e1f5df9@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09r8169: improve rtl_set_d3_pll_downHeiner Kallweit
Make use of new helper r8169_mod_reg8_cond() and move from a switch() to an if() clause. Benefit is that we don't have to touch this piece of code each time support for a new chip version is added. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/e1ccdb85-a4ed-4800-89c2-89770ff06452@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09r8169: improve __rtl8169_set_wolHeiner Kallweit
Add helper r8169_mod_reg8_cond() what allows to significantly simplify __rtl8169_set_wol(). Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/697b197a-8eac-40c6-8847-27093cacec36@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09Merge tag 'nfsd-6.12-4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux Pull nfsd fix from Chuck Lever: - Fix a v6.12-rc regression when exporting ext4 filesystems with NFSD * tag 'nfsd-6.12-4' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux: NFSD: Fix READDIR on NFSv3 mounts of ext4 exports
2024-11-09Merge tag 'v6.12-rc6-smb3-client-fix' of git://git.samba.org/sfrench/cifs-2.6Linus Torvalds
Pull smb client fix from Steve French: "Fix net namespace refcount use after free issue" * tag 'v6.12-rc6-smb3-client-fix' of git://git.samba.org/sfrench/cifs-2.6: smb: client: Fix use-after-free of network namespace.
2024-11-09Merge tag 'block-6.12-20241108' of git://git.kernel.dk/linuxLinus Torvalds
Pull block fix from Jens Axboe: "Single fix for an issue triggered with PROVE_RCU=y, with nvme using the wrong iterators for an SRCU protected list" * tag 'block-6.12-20241108' of git://git.kernel.dk/linux: nvme/host: Fix RCU list traversal to use SRCU primitive
2024-11-09sched_ext: Handle cases where pick_task_scx() is called without preceding ↵Tejun Heo
balance_scx() sched_ext dispatches tasks from the BPF scheduler from balance_scx() and thus every pick_task_scx() call must be preceded by balance_scx(). While this usually holds, due to a bug, there are cases where the fair class's balance() returns true indicating that it has tasks to run on the CPU and thus terminating balance() calls but fails to actually find the next task to run when pick_task() is called. In such cases, pick_task_scx() can be called without preceding balance_scx(). Detect this condition using SCX_RQ_BAL_PENDING flags. If detected, keep running the previous task if possible and avoid stalling from entering idle without balancing. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/Ztj_h5c2LYsdXYbA@slm.duckdns.org
2024-11-09sched_ext: scx_bpf_dispatch_from_dsq_set_*() are allowed from unlocked contextTejun Heo
4c30f5ce4f7a ("sched_ext: Implement scx_bpf_dispatch[_vtime]_from_dsq()") added four kfuncs for dispatching while iterating. They are allowed from the dispatch and unlocked contexts but two of the kfuncs were only added in the dispatch section. Add missing declarations in the unlocked section. Signed-off-by: Tejun Heo <tj@kernel.org> Fixes: 4c30f5ce4f7a ("sched_ext: Implement scx_bpf_dispatch[_vtime]_from_dsq()")
2024-11-09landlock: Optimize scope enforcementMickaël Salaün
Do not walk through the domain hierarchy when the required scope is not supported by this domain. This is the same approach as for filesystem and network restrictions. Cc: Mikhail Ivanov <ivanov.mikhail1@huawei-partners.com> Cc: Tahera Fahimi <fahimitahera@gmail.com> Reviewed-by: Günther Noack <gnoack@google.com> Link: https://lore.kernel.org/r/20241109110856.222842-4-mic@digikod.net Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-11-09landlock: Refactor network access mask managementMickaël Salaün
Replace get_raw_handled_net_accesses() and get_current_net_domain() with a call to landlock_get_applicable_domain(). Cc: Konstantin Meskhidze <konstantin.meskhidze@huawei.com> Cc: Mikhail Ivanov <ivanov.mikhail1@huawei-partners.com> Reviewed-by: Günther Noack <gnoack@google.com> Link: https://lore.kernel.org/r/20241109110856.222842-3-mic@digikod.net Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-11-09landlock: Refactor filesystem access mask managementMickaël Salaün
Replace get_raw_handled_fs_accesses() with a generic landlock_union_access_masks(), and replace get_fs_domain() with a generic landlock_get_applicable_domain(). These helpers will also be useful for other types of access. Cc: Mikhail Ivanov <ivanov.mikhail1@huawei-partners.com> Reviewed-by: Günther Noack <gnoack@google.com> Link: https://lore.kernel.org/r/20241109110856.222842-2-mic@digikod.net [mic: Slightly improve doc as suggested by Günther] Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-11-09ARM: dts: rockchip: adapt regulator nodenames to preferred formJohan Jonker
The preferred nodename for fixed-regulators has changed to pattern: '^regulator(-[0-9]+v[0-9]+|-[0-9a-z-]+)?$' Fix all Rockchip DT regulator nodenames. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/cfc3cfe1-086b-48f1-9b89-f17c9391d3cc@gmail.com [Also include the backlight-regulator and panel-regulator from rk3288-veyron-edp, and adapt the Pinky device accordingly] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-09tc: fix typo probabilty in tc.yaml docAbhinav Saxena
Fix spelling of "probability" in tc.yaml documentation. This corrects the max-P field description in struct tc_sfq_qopt_v1. Signed-off-by: Abhinav Saxena <xandfury@gmail.com> Link: https://patch.msgid.link/20241108195642.139315-1-xandfury@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09sctp: fix possible UAF in sctp_v6_available()Eric Dumazet
A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints that sctp_v6_available() is calling dev_get_by_index_rcu() and ipv6_chk_addr() without holding rcu. [1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp stack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (security/security.c:4581 (discriminator 1)) __sys_bind (net/socket.c:1848 net/socket.c:1869) ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13)) __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1)) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f59b934a1e7 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48 All code ======== 0: 44 00 00 add %r8b,(%rax) 3: 48 8b 15 39 8c 0c 00 mov 0xc8c39(%rip),%rdx # 0xc8c43 a: f7 d8 neg %eax c: 64 89 02 mov %eax,%fs:(%rdx) f: b8 ff ff ff ff mov $0xffffffff,%eax 14: eb bd jmp 0xffffffffffffffd3 16: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1) 1d: 00 00 00 20: 0f 1f 00 nopl (%rax) 23: b8 31 00 00 00 mov $0x31,%eax 28: 0f 05 syscall 2a:* 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax <-- trapping instruction 30: 73 01 jae 0x33 32: c3 ret 33: 48 8b 0d 09 8c 0c 00 mov 0xc8c09(%rip),%rcx # 0xc8c43 3a: f7 d8 neg %eax 3c: 64 89 01 mov %eax,%fs:(%rcx) 3f: 48 rex.W Code starting with the faulting instruction =========================================== 0: 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax 6: 73 01 jae 0x9 8: c3 ret 9: 48 8b 0d 09 8c 0c 00 mov 0xc8c09(%rip),%rcx # 0xc8c19 10: f7 d8 neg %eax 12: 64 89 01 mov %eax,%fs:(%rcx) 15: 48 rex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 0000000000000202 R12: 00007ffe2d0ada61 R13: 0000000000000000 R14: 0000562926516dd8 R15: 00007f59b9479000 </TASK> Fixes: 6fe1e52490a9 ("sctp: check ipv6 addr with sk_bound_dev if set") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Acked-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/20241107192021.2579789-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09mISDN: Fix typosAndrew Kreimer
Fix typos: - syncronized -> synchronized - interfacs -> interface - otherwhise -> otherwise - ony -> only - busses -> buses - maxinum -> maximum Via codespell. Reported-by: Simon Horman <horms@kernel.org> Signed-off-by: Andrew Kreimer <algonell@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241106112513.9559-1-algonell@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointerHyunwoo Kim
When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL. Signed-off-by: Hyunwoo Kim <v4bel@theori.io> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Link: https://patch.msgid.link/Zys4hCj61V+mQfX2@v4bel-B760M-AORUS-ELITE-AX Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09net: sfc: use ethtool string helpersRosen Penev
The latter is the preferred way to copy ethtool strings. Avoids manually incrementing the pointer. Cleans up the code quite well. Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Link: https://patch.msgid.link/20241105231855.235894-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09mptcp: remove the redundant assignment of 'new_ctx->tcp_sock' in ↵MoYuanhao
subflow_ulp_clone() The variable has already been assigned in the subflow_create_ctx(), So we don't need to reassign this variable in the subflow_ulp_clone(). Signed-off-by: MoYuanhao <moyuanhao3676@163.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20241106071035.2591-1-moyuanhao3676@163.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09net: mctp: Expose transport binding identifier via IFLA attributeKhang Nguyen
MCTP control protocol implementations are transport binding dependent. Endpoint discovery is mandatory based on transport binding. Message timing requirements are specified in each respective transport binding specification. However, we currently have no means to get this information from MCTP links. Add a IFLA_MCTP_PHYS_BINDING netlink link attribute, which represents the transport type using the DMTF DSP0239-defined type numbers, returned as part of RTM_GETLINK data. We get an IFLA_MCTP_PHYS_BINDING attribute for each MCTP link, for example: - 0x00 (unspec) for loopback interface; - 0x01 (SMBus/I2C) for mctpi2c%d interfaces; and - 0x05 (serial) for mctpserial%d interfaces. Signed-off-by: Khang Nguyen <khangng@os.amperecomputing.com> Reviewed-by: Matt Johnston <matt@codeconstruct.com.au> Link: https://patch.msgid.link/20241105071915.821871-1-khangng@os.amperecomputing.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09scftorture: Use a lock-less list to free memory.Sebastian Andrzej Siewior
scf_handler() is used as a SMP function call. This function is always invoked in IRQ-context even with forced-threading enabled. This function frees memory which not allowed on PREEMPT_RT because the locking underneath is using sleeping locks. Add a per-CPU scf_free_pool where each SMP functions adds its memory to be freed. This memory is then freed by scftorture_invoker() on each iteration. On the majority of invocations the number of items is less than five. If the thread sleeps/ gets delayed the number exceed 350 but did not reach 400 in testing. These were the spikes during testing. The bulk free of 64 pointers at once should improve the give-back if the list grows. The list size is ~1.3 items per invocations. Having one global scf_free_pool with one cleaning thread let the list grow to over 10.000 items with 32 CPUs (again, spikes not the average) especially if the CPU went to sleep. The per-CPU part looks like a good compromise. Reported-by: "Paul E. McKenney" <paulmck@kernel.org> Closes: https://lore.kernel.org/lkml/41619255-cdc2-4573-a360-7794fc3614f7@paulmck-laptop/ Tested-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Tested-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2024-11-09scftorture: Move memory allocation outside of preempt_disable region.Sebastian Andrzej Siewior
Memory allocations can not happen within regions with explicit disabled preemption PREEMPT_RT. The problem is that the locking structures underneath are sleeping locks. Move the memory allocation outside of the preempt-disabled section. Keep the GFP_ATOMIC for the allocation to behave like a "ememergncy allocation". Tested-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Tested-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2024-11-09scftorture: Wait until scf_cleanup_handler() completes.Sebastian Andrzej Siewior
The smp_call_function() needs to be invoked with the wait flag set to wait until scf_cleanup_handler() is done. This ensures that all SMP function calls, that have been queued earlier, complete at this point. Tested-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Tested-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2024-11-09scftorture: Avoid additional div operation.Sebastian Andrzej Siewior
Replace "scfp->cpu % nr_cpu_ids" with "cpu". This has been computed earlier. Tested-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Tested-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2024-11-09sched_ext: add a missing rcu_read_lock/unlock pair at scx_select_cpu_dfl()Changwoo Min
When getting an LLC CPU mask in the default CPU selection policy, scx_select_cpu_dfl(), a pointer to the sched_domain is dereferenced using rcu_read_lock() without holding rcu_read_lock(). Such an unprotected dereference often causes the following warning and can cause an invalid memory access in the worst case. Therefore, protect dereference of a sched_domain pointer using a pair of rcu_read_lock() and unlock(). [ 20.996135] ============================= [ 20.996345] WARNING: suspicious RCU usage [ 20.996563] 6.11.0-virtme #17 Tainted: G W [ 20.996576] ----------------------------- [ 20.996576] kernel/sched/ext.c:3323 suspicious rcu_dereference_check() usage! [ 20.996576] [ 20.996576] other info that might help us debug this: [ 20.996576] [ 20.996576] [ 20.996576] rcu_scheduler_active = 2, debug_locks = 1 [ 20.996576] 4 locks held by kworker/8:1/140: [ 20.996576] #0: ffff8b18c00dd348 ((wq_completion)pm){+.+.}-{0:0}, at: process_one_work+0x4a0/0x590 [ 20.996576] #1: ffffb3da01f67e58 ((work_completion)(&dev->power.work)){+.+.}-{0:0}, at: process_one_work+0x1ba/0x590 [ 20.996576] #2: ffffffffa316f9f0 (&rcu_state.gp_wq){..-.}-{2:2}, at: swake_up_one+0x15/0x60 [ 20.996576] #3: ffff8b1880398a60 (&p->pi_lock){-.-.}-{2:2}, at: try_to_wake_up+0x59/0x7d0 [ 20.996576] [ 20.996576] stack backtrace: [ 20.996576] CPU: 8 UID: 0 PID: 140 Comm: kworker/8:1 Tainted: G W 6.11.0-virtme #17 [ 20.996576] Tainted: [W]=WARN [ 20.996576] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [ 20.996576] Workqueue: pm pm_runtime_work [ 20.996576] Sched_ext: simple (disabling+all), task: runnable_at=-6ms [ 20.996576] Call Trace: [ 20.996576] <IRQ> [ 20.996576] dump_stack_lvl+0x6f/0xb0 [ 20.996576] lockdep_rcu_suspicious.cold+0x4e/0x96 [ 20.996576] scx_select_cpu_dfl+0x234/0x260 [ 20.996576] select_task_rq_scx+0xfb/0x190 [ 20.996576] select_task_rq+0x47/0x110 [ 20.996576] try_to_wake_up+0x110/0x7d0 [ 20.996576] swake_up_one+0x39/0x60 [ 20.996576] rcu_core+0xb08/0xe50 [ 20.996576] ? srso_alias_return_thunk+0x5/0xfbef5 [ 20.996576] ? mark_held_locks+0x40/0x70 [ 20.996576] handle_softirqs+0xd3/0x410 [ 20.996576] irq_exit_rcu+0x78/0xa0 [ 20.996576] sysvec_apic_timer_interrupt+0x73/0x80 [ 20.996576] </IRQ> [ 20.996576] <TASK> [ 20.996576] asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 20.996576] RIP: 0010:_raw_spin_unlock_irqrestore+0x36/0x70 [ 20.996576] Code: f5 53 48 8b 74 24 10 48 89 fb 48 83 c7 18 e8 11 b4 36 ff 48 89 df e8 99 0d 37 ff f7 c5 00 02 00 00 75 17 9c 58 f6 c4 02 75 2b <65> ff 0d 5b 55 3c 5e 74 16 5b 5d e9 95 8e 28 00 e8 a5 ee 44 ff 9c [ 20.996576] RSP: 0018:ffffb3da01f67d20 EFLAGS: 00000246 [ 20.996576] RAX: 0000000000000002 RBX: ffffffffa4640220 RCX: 0000000000000040 [ 20.996576] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffa1c7b27b [ 20.996576] RBP: 0000000000000246 R08: 0000000000000001 R09: 0000000000000000 [ 20.996576] R10: 0000000000000001 R11: 000000000000021c R12: 0000000000000246 [ 20.996576] R13: ffff8b1881363958 R14: 0000000000000000 R15: ffff8b1881363800 [ 20.996576] ? _raw_spin_unlock_irqrestore+0x4b/0x70 [ 20.996576] serial_port_runtime_resume+0xd4/0x1a0 [ 20.996576] ? __pfx_serial_port_runtime_resume+0x10/0x10 [ 20.996576] __rpm_callback+0x44/0x170 [ 20.996576] ? __pfx_serial_port_runtime_resume+0x10/0x10 [ 20.996576] rpm_callback+0x55/0x60 [ 20.996576] ? __pfx_serial_port_runtime_resume+0x10/0x10 [ 20.996576] rpm_resume+0x582/0x7b0 [ 20.996576] pm_runtime_work+0x7c/0xb0 [ 20.996576] process_one_work+0x1fb/0x590 [ 20.996576] worker_thread+0x18e/0x350 [ 20.996576] ? __pfx_worker_thread+0x10/0x10 [ 20.996576] kthread+0xe2/0x110 [ 20.996576] ? __pfx_kthread+0x10/0x10 [ 20.996576] ret_from_fork+0x34/0x50 [ 20.996576] ? __pfx_kthread+0x10/0x10 [ 20.996576] ret_from_fork_asm+0x1a/0x30 [ 20.996576] </TASK> [ 21.056592] sched_ext: BPF scheduler "simple" disabled (unregistered from user space) Signed-off-by: Changwoo Min <changwoo@igalia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2024-11-09gpio: Get rid of GPIOF_ACTIVE_LOWAndy Shevchenko
No more users. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20241104093609.156059-7-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-09USB: gadget: pxa27x_udc: Avoid using GPIOF_ACTIVE_LOWAndy Shevchenko
Avoid using GPIOF_ACTIVE_LOW as it's deprecated and subject to remove. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20241104093609.156059-6-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-09pcmcia: soc_common: Avoid using GPIOF_ACTIVE_LOWAndy Shevchenko
Avoid using GPIOF_ACTIVE_LOW as it's deprecated and subject to remove. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Dominik Brodowski <linux@dominikbrodowski.net> Link: https://lore.kernel.org/r/20241104093609.156059-5-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-09leds: gpio: Avoid using GPIOF_ACTIVE_LOWAndy Shevchenko
Avoid using GPIOF_ACTIVE_LOW as it's deprecated and subject to remove. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Lee Jones <lee@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20241104093609.156059-4-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-09Input: gpio_keys_polled - avoid using GPIOF_ACTIVE_LOWAndy Shevchenko
Avoid using GPIOF_ACTIVE_LOW as it's deprecated and subject to remove. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20241104093609.156059-3-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-09Input: gpio_keys - avoid using GPIOF_ACTIVE_LOWAndy Shevchenko
Avoid using GPIOF_ACTIVE_LOW as it's deprecated and subject to remove. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20241104093609.156059-2-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-09media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in ↵Benoit Sevens
uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming. Fixes: c0efd232929c ("V4L/DVB (8145a): USB Video Class driver") Signed-off-by: Benoit Sevens <bsevens@google.com> Cc: stable@vger.kernel.org Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2024-11-09arm64: dts: rockchip: Enable HDMI0 on FriendlyElec CM3588 NASJonas Karlman
Add the necessary DT changes to enable HDMI0 on FriendlyElec CM3588 NAS. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20241108171423.835496-1-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-09arm64: dts: rockchip: add Banana Pi P2 Pro boardDmitry Yashin
Banana Pi P2 Pro is the SBC made by Shenzhen SINOVOIP based on Rockchip RK3308. Banana Pi P2 Pro features: - Rockchip RK3308B-S - DDR3 512 MB - eMMC 8 GB - 100M lan + onboard PoE - 40 pin and 12 pin headers - AP6256 BT + WIFI - TF card slot - 2x USB 2.0 (Type-C OTG and Type-A) - Headphone jack Add support for Banana Pi P2 Pro. Signed-off-by: Dmitry Yashin <dmt.yashin@gmail.com> Link: https://lore.kernel.org/r/20241030202144.629956-3-dmt.yashin@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-09dt-bindings: arm: rockchip: add Banana Pi P2 Pro boardDmitry Yashin
BBanana Pi P2 Pro is the SBC made by Shenzhen SINOVOIP based on Rockchip RK3308. Banana Pi P2 Pro features: - Rockchip RK3308B-S - DDR3 512 MB - eMMC 8 GB - 100M lan + onboard PoE - 40 pin and 12 pin headers - AP6256 BT + WIFI - TF card slot - 2x USB 2.0 (Type-C OTG and Type-A) - Headphone jack Add devicetree binding for Banana Pi P2 Pro. Signed-off-by: Dmitry Yashin <dmt.yashin@gmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20241030202144.629956-2-dmt.yashin@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-09arm64: dts: rockchip: Add new SoC dtsi for the RK3566T variantDragan Simic
Add new SoC dtsi file for the RK3566T variant of the Rockchip RK3566 SoC. The difference between the RK3566T variant and the "full-fat" RK3566 variant is in fewer supported CPU and GPU OPPs on the RK3566T, and in the absence of a functional NPU, which we currently don't have to worry about. Examples of the boards based on the RK3566T include the Pine64 Quartz64 Zero SBC, [1] which is yet to be supported, the Radxa ROCK 3C, and the Radxa ZERO 3E/3W SBCs, which are both already supported. Though, Radxa doesn't mention the use of RK3566T officially, but its official SBC specifications do state that the maximum frequency for the Cortex-A55 cores on those SBCs is lower than the "full-fat" RK3566's 1.8 GHz, which makes spotting the presence of the RK3566T SoC variant rather easy. [2][3][4] An additional, helpful cue is that Radxa handles the CPU and GPU OPPs for the RK3566T variant separately in its downstream kernel source. [5] The CPU and GPU OPPs supported on the RK3566T SoC variant are taken from the vendor kernel source, [6] which uses the values of the "opp-supported-hw" OPP properties to determine which ones are supported on a particular SoC variant. The actual values of the "opp-supported-hw" properties make it rather easy to see what OPPs are supported on the RK3566T SoC variant, but that, rather unfortunately, clashes with the maximum frequencies advertised officially for the Cortex-A55 CPU cores on the above-mentioned SBCs. [1][2][3][4] The vendor kernel source indicates that the maximum frequency for the CPU cores is 1.4 GHz, while the SBC specifications state that to be 1.6 GHz. Until that discrepancy is resolved somehow, let's take the safe approach and use the lower maximum frequency for the CPU cores. Update the dts files of the currently supported RK3566T-based boards to use the new SoC dtsi for the RK3566T variant. This actually takes the CPU cores and the GPUs found on these boards out of their earlier overclocks, but it also means that the officially advertised specifications [1][2][3][4] of the highest supported frequencies for the Cortex-A55 CPU cores on these boards may actually be wrong, as already explained above. The correctness of the introduced changes was validated by decompiling and comparing all affected board dtb files before and after these changes. [1] https://wiki.pine64.org/wiki/Quartz64 [2] https://dl.radxa.com/rock3/docs/hw/3c/radxa_rock3c_product_brief.pdf [3] https://dl.radxa.com/zero3/docs/hw/3e/radxa_zero_3e_product_brief.pdf [4] https://dl.radxa.com/zero3/docs/hw/3w/radxa_zero_3w_product_brief.pdf [5] https://github.com/radxa/kernel/commit/2dfd51da472e7ebb5ef0d3db78f902454af826b8 [6] https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi Cc: TL Lim <tllim@pine64.org> Cc: Marek Kraus <gamiee@pine64.org> Cc: Tom Cubie <tom@radxa.com> Cc: FUKAUMI Naoki <naoki@radxa.com> Helped-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> Helped-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/a85b9bdc176c542fea261fe7ef37697aebb42e8b.1730516702.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-09arm64: dts: rockchip: Prepare RK356x SoC dtsi files for per-variant OPPsDragan Simic
Rename the Rockchip RK356x SoC dtsi files and, consequently, adjust their contents appropriately, to prepare them for the ability to specify different CPU and GPU OPPs for each of the supported RK356x SoC variants. The first new RK356x SoC variant to be introduced is the RK3566T, which the Pine64 Quartz64 Zero SBC is officially based on. [1] Some other SBCs are also based on the RK3566T variant, including Radxa ROCK 3C and ZERO 3E/3W, but the slight trouble is that Radxa doesn't state that officially. Though, it's rather easy to spot the RK3566T on such boards, because their official specifications state that the maximum frequency for the Cortex-A55 cores is lower than the "full-fat" RK3566's 1.8 GHz. [2][3][4] These changes follow the approach used for the Rockchip RK3588 SoC variants, which was introduced and described further in commit def88eb4d836 ("arm64: dts: rockchip: Prepare RK3588 SoC dtsi files for per-variant OPPs"). Please see that commit for a more detailed explanation. No functional changes are introduced, which was validated by decompiling and comparing all affected board dtb files before and after these changes. In more detail, the affected dtb files have some of their blocks shuffled around a bit and some of their phandles have different values, as a result of the changes to the order in which the building blocks from the parent dtsi files are included, but they effectively remain the same as the originals. As a side note, due to the nature of introduced changes, this commit is a bit more readable when viewed using the --break-rewrites option for git-log(1). [1] https://wiki.pine64.org/wiki/Quartz64 [2] https://dl.radxa.com/rock3/docs/hw/3c/radxa_rock3c_product_brief.pdf [3] https://dl.radxa.com/zero3/docs/hw/3e/radxa_zero_3e_product_brief.pdf [4] https://dl.radxa.com/zero3/docs/hw/3w/radxa_zero_3w_product_brief.pdf Related-to: def88eb4d836 ("arm64: dts: rockchip: Prepare RK3588 SoC dtsi files for per-variant OPPs") Signed-off-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/77e7450b8280bbdf4e2dc47366c9da85d4d8d1de.1730516702.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-09arm64: dts: rockchip: Update CPU OPP voltages in RK356x SoC dtsiDragan Simic
Update the lower/upper voltage limits and the exact voltages for the Rockchip RK356x CPU OPPs, using the most conservative values (i.e. the highest per-OPP voltages) found in the vendor kernel source. [1] Using the most conservative per-OPP voltages ensures reliable CPU operation regardless of the actual CPU binning, with the downside of possibly using a bit more power for the CPU cores than absolutely needed. Additionally, fill in the missing "clock-latency-ns" CPU OPP properties, using the values found in the vendor kernel source. [1] [1] https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi Related-to: eb665b1c06bc ("arm64: dts: rockchip: Update GPU OPP voltages in RK356x SoC dtsi") Signed-off-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/f816cd24b62742dd05a1b7c6fe162bb581c9b3bf.1730516702.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-09arm64: dts: rockchip: Add OPP voltage ranges to RK3399 OP1 SoC dtsiDragan Simic
Add support for voltage ranges to the CPU, GPU and DMC OPPs defined in the SoC dtsi for Rockchip OP1, as a variant of the Rockchip RK3399. This may be useful if there are any OP1-based boards whose associated voltage regulators are unable to deliver the exact voltages; otherwise, it causes no functional changes to the resulting OPP voltages at runtime. These changes cannot cause stability issues or any kind of damage, because it's perfectly safe to use the highest voltage from an OPP group for each OPP in the same group. The only possible negative effect of using higher voltages is wasted energy in form of some additionally generated heat. Reported-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/dbee35c002bda99e44f8533623d94f202a60da95.1730881777.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-09arm64: dts: rockchip: Enable HDMI0 on Indiedroid NovaChris Morgan
Enable the HDMI0 port for the Indiedroid Nova. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://lore.kernel.org/r/20241031150505.967909-4-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-09arm64: dts: rockchip: Enable GPU on Indiedroid NovaChris Morgan
Enable the GPU for the Indiedroid Nova. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://lore.kernel.org/r/20241031150505.967909-3-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-09arm64: dts: rockchip: correct analog audio name on Indiedroid NovaChris Morgan
Correct the audio name for the Indiedroid Nova from rockchip,es8388-codec to rockchip,es8388. This name change corrects a kernel log error of "ASoC: driver name too long 'rockchip,es8388-codec' -> 'rockchip_es8388'". Fixes: 3900160e164b ("arm64: dts: rockchip: Add Indiedroid Nova board") Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://lore.kernel.org/r/20241031150505.967909-2-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-09arm64: dts: rockchip: sort rk3588s-rock5a properly in MakefileFUKAUMI Naoki
sort target dtb files properly in Makefile for rockchip. Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Link: https://lore.kernel.org/r/20241028072344.1514-1-naoki@radxa.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-08sched_ext: Clarify sched_ext_ops table for userland schedulerChangwoo Min
Update the comments in sched_ext_ops to clarify this table is for a BPF scheduler and a userland scheduler should also rely on the sched_ext_ops table through the BPF scheduler. Signed-off-by: Changwoo Min <changwoo@igalia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2024-11-08Merge tag 'thermal-6.12-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull thermal control fixes from Rafael Wysocki: "These fix one issue in the qcom lmh thermal driver, a DT handling issue in the thermal core and two issues in the userspace thermal library: - Allow tripless thermal zones defined in a DT to be registered in accordance with the thermal DT bindings (Icenowy Zheng) - Annotate LMH IRQs with lockdep classes to prevent lockdep from reporting a possible recursive locking issue that cannot really occur (Dmitry Baryshkov) - Improve the thermal library "make clean" to remove a leftover symbolic link created during compilation and fix the sampling handler invocation in that library to pass the correct pointer to it (Emil Dahl Juhl, zhang jiao)" * tag 'thermal-6.12-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: thermal/of: support thermal zones w/o trips subnode tools/lib/thermal: Remove the thermal.h soft link when doing make clean tools/lib/thermal: Fix sampling handler context ptr thermal/drivers/qcom/lmh: Remove false lockdep backtrace
2024-11-08Merge tag 'pm-6.12-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fix from Rafael Wysocki: "Fix the asymmetric CPU capacity support code in the intel_pstate driver, added during this develompent cycle, to address a corner case in which the capacity of a CPU going online is not updated (Rafael Wysocki)" * tag 'pm-6.12-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpufreq: intel_pstate: Update asym capacity for CPUs that were offline initially cpufreq: intel_pstate: Clear hybrid_max_perf_cpu before driver registration
2024-11-08Merge tag 'acpi-6.12-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fix from Rafael Wysocki: "Fix the ACPI processor driver initialization ordering after recent changes to avoid calling init_freq_invariance_cppc() too early on AMD platforms (Mario Limonciello)" * tag 'acpi-6.12-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: processor: Move arch_init_invariance_cppc() call later
generated by cgit (git 2.34.1) at 2025-10-02 05:54:19 +0000