summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-07-14ARM: ptrace: Use USER_REGSET_NOTE_TYPE() to specify regset note namesDave Martin
Instead of having the core code guess the note name for each regset, use USER_REGSET_NOTE_TYPE() to pick the correct name from elf.h. Signed-off-by: Dave Martin <Dave.Martin@arm.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Kees Cook <kees@kernel.org> Cc: Akihiko Odaki <akihiko.odaki@daynix.com> Cc: linux-arm-kernel@lists.infradead.org Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Link: https://lore.kernel.org/r/20250701135616.29630-6-Dave.Martin@arm.com Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-14ARC: ptrace: Use USER_REGSET_NOTE_TYPE() to specify regset note namesDave Martin
Instead of having the core code guess the note name for each regset, use USER_REGSET_NOTE_TYPE() to pick the correct name from elf.h. Signed-off-by: Dave Martin <Dave.Martin@arm.com> Cc: Vineet Gupta <vgupta@kernel.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Kees Cook <kees@kernel.org> Cc: Akihiko Odaki <akihiko.odaki@daynix.com> Cc: linux-snps-arc@lists.infradead.org Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Link: https://lore.kernel.org/r/20250701135616.29630-5-Dave.Martin@arm.com Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-14binfmt_elf: Dump non-arch notes with strictly matching name and typeDave Martin
The note names for some arch-independent coredump notes are specified manually, albeit by referring to the NN_<foo> #define corresponding to the NT_<foo> #define that specifies the note type. Now that there are no exceptional cases, refactor fill_note() to pick the correct NN_ and NT_ macros implcitly for the requested note type. Signed-off-by: Dave Martin <Dave.Martin@arm.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Kees Cook <kees@kernel.org> Cc: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Link: https://lore.kernel.org/r/20250701135616.29630-4-Dave.Martin@arm.com Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-14regset: Add explicit core note name in struct user_regsetDave Martin
There is currently hard-coded logic spread around the tree for determining the note name for regset notes emitted in coredumps. Now that the names are declared explicitly in <uapi/elf.h>, this can be simplified. In preparation for getting rid of the special-case logic, add an explicit core_note_name field in struct user_regset for specifying the note name explicitly. To help avoid mistakes, a convenience macro USER_REGSET_NOTE_TYPE() is provided to set .core_note_type and .core_note_name based on the note type. When dumping core, use the new field to set the note name, if the regset specifies it. Signed-off-by: Dave Martin <Dave.Martin@arm.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Kees Cook <kees@kernel.org> Cc: Akihiko Odaki <akihiko.odaki@daynix.com> Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> # s390 Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Link: https://lore.kernel.org/r/20250701135616.29630-3-Dave.Martin@arm.com Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-14regset: Fix kerneldoc for struct regset_get() in user_regsetDave Martin
Commit 7717cb9bdd04 ("regset: new method and helpers for it") added a new interface ->regset_get() for struct user_regset, and commit 1e6986c9db21 ("regset: kill ->get()") got rid of the old interface. The kerneldoc comment block was never updated to take account of this change, though. Update it. No functional change. Signed-off-by: Dave Martin <Dave.Martin@arm.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Kees Cook <kees@kernel.org> Cc: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Link: https://lore.kernel.org/r/20250701135616.29630-2-Dave.Martin@arm.com Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-14lockdep: Speed up lockdep_unregister_key() with expedited RCU synchronizationBreno Leitao
lockdep_unregister_key() is called from critical code paths, including sections where rtnl_lock() is held. For example, when replacing a qdisc in a network device, network egress traffic is disabled while __qdisc_destroy() is called for every network queue. If lockdep is enabled, __qdisc_destroy() calls lockdep_unregister_key(), which gets blocked waiting for synchronize_rcu() to complete. For example, a simple tc command to replace a qdisc could take 13 seconds: # time /usr/sbin/tc qdisc replace dev eth0 root handle 0x1: mq real 0m13.195s user 0m0.001s sys 0m2.746s During this time, network egress is completely frozen while waiting for RCU synchronization. Use synchronize_rcu_expedited() instead to minimize the impact on critical operations like network connectivity changes. This improves 10x the function call to tc, when replacing the qdisc for a network card. # time /usr/sbin/tc qdisc replace dev eth0 root handle 0x1: mq real 0m1.789s user 0m0.000s sys 0m1.613s [boqun: Fixed the comment and add more information for the temporary workaround, and add TODO information for hazptr] Reported-by: Erik Lundgren <elundgren@meta.com> Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Paul E. McKenney <paulmck@kernel.org> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://lore.kernel.org/r/20250321-lockdep-v1-1-78b732d195fb@debian.org
2025-07-14locking/mutex: Remove redundant #ifdefsRan Xiaokai
hung_task_{set,clear}_blocker() is already guarded by CONFIG_DETECT_HUNG_TASK_BLOCKER in hung_task.h, So remove the redudant check of #ifdef. Signed-off-by: Ran Xiaokai <ran.xiaokai@zte.com.cn> Acked-by: Waiman Long <longman@redhat.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://lore.kernel.org/r/20250704015218.359754-1-ranxiaokai627@163.com
2025-07-14locking/lockdep: Change 'static const' variables to enum valuesArnd Bergmann
gcc warns about 'static const' variables even in headers when building with -Wunused-const-variables enabled: In file included from kernel/locking/lockdep_proc.c:25: kernel/locking/lockdep_internals.h:69:28: error: 'LOCKF_USED_IN_IRQ_READ' defined but not used [-Werror=unused-const-variable=] 69 | static const unsigned long LOCKF_USED_IN_IRQ_READ = | ^~~~~~~~~~~~~~~~~~~~~~ kernel/locking/lockdep_internals.h:63:28: error: 'LOCKF_ENABLED_IRQ_READ' defined but not used [-Werror=unused-const-variable=] 63 | static const unsigned long LOCKF_ENABLED_IRQ_READ = | ^~~~~~~~~~~~~~~~~~~~~~ kernel/locking/lockdep_internals.h:57:28: error: 'LOCKF_USED_IN_IRQ' defined but not used [-Werror=unused-const-variable=] 57 | static const unsigned long LOCKF_USED_IN_IRQ = | ^~~~~~~~~~~~~~~~~ kernel/locking/lockdep_internals.h:51:28: error: 'LOCKF_ENABLED_IRQ' defined but not used [-Werror=unused-const-variable=] 51 | static const unsigned long LOCKF_ENABLED_IRQ = | ^~~~~~~~~~~~~~~~~ This one is easy to avoid by changing the generated constant definition into an equivalent enum. Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://lore.kernel.org/r/20250409122314.2848028-6-arnd@kernel.org
2025-07-14locking/lockdep: Avoid struct return in lock_stats()Arnd Bergmann
Returning a large structure from the lock_stats() function causes clang to have multiple copies of it on the stack and copy between them, which can end up exceeding the frame size warning limit: kernel/locking/lockdep.c:300:25: error: stack frame size (1464) exceeds limit (1280) in 'lock_stats' [-Werror,-Wframe-larger-than] 300 | struct lock_class_stats lock_stats(struct lock_class *class) Change the calling conventions to directly operate on the caller's copy, which apparently is what gcc does already. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://lore.kernel.org/r/20250610092941.2642847-1-arnd@kernel.org
2025-07-14dt-bindings: interrupt-controller: Convert apm,xgene1-msi to DT schemaRob Herring (Arm)
Convert the Applied Micro X-Gene MSI controller binding to DT schema format. MSI controllers go in interrupt-controller directory so move the schema there. Link: https://lore.kernel.org/r/20250710180757.2970583-1-robh@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-07-15drivers: cpufreq: add Tegra114 supportSvyatoslav Ryhel
Tegra114 is fully compatible with existing Tegra124 cpufreq driver. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-07-15rust: cpumask: Replace `MaybeUninit` and `mem::zeroed` with `Opaque` APIsRitvik Gupta
Replace the following unsafe initializations: 1. `MaybeUninit::uninit().assume_init()` with `Opaque::uninit()` 2. `core::mem::zeroed()` with `Opaque::zeroed()` Suggested-by: Benno Lossin <lossin@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1178 Suggested-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/rust-for-linux/CAH5fLgj0OoCn56OkNUmiPQ=RAVa_VmS-yMZ4TNBSpGPNtZ5D0A@mail.gmail.com/ Reviewed-by: Benno Lossin <lossin@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Ritvik Gupta <ritvikfoss@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-07-14Merge tag 'for-6.16/dm-fixes-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm Pull device mapper fix from Mikulas Patocka: - dm-bufio: fix scheduling in atomic * tag 'for-6.16/dm-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm-bufio: fix sched in atomic context
2025-07-15gfs2: a minor finish_xmote cleanupAndreas Gruenbacher
As a minor clean-up to commit 1fc05c8d8426 ("gfs2: cancel timed-out glock requests"), when a demote request is in progress in finish_xmote(), there is no point in waking up the glock holder at the head of the queue because the reply from dlm cannot be on behalf of that glock holder. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Reviewed-by: Andrew Price <anprice@redhat.com>
2025-07-15gfs2: simplify finish_xmoteAndreas Gruenbacher
As a follow-up to commit a431d49243a0 ("gfs2: Fix request cancelation bug"), it turns out that any call to finish_xmote() is always followed by a call to run_queue(), either * directly when glock_work_func() calls finish_xmote() before calling run_queue(), or * indirectly when do_xmote() calls finish_xmote() before calling gfs2_glock_queue_work(), which queues a call to glock_work_func() in work queue context, so remove the code in finish_xmote() that duplicates the functionality of run_queue(). In addition, the code this commit removes is missing a check for the GLF_DEMOTE flag which indicates that no further promotes should be performed, so if that code didn't get removed, that check would have to be added. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Reviewed-by: Andrew Price <anprice@redhat.com>
2025-07-15gfs2: sanitize the gdlm_ast -> finish_xmote interfaceAndreas Gruenbacher
When gdlm_ast() is called with a non-zero status code, this means that the requested operation did not succeed and the current lock state didn't change. Turn that into a non-zero LM_OUT_* status code (with ret & ~LM_OUT_ST_MASK != 0) instead of pretending that dlm returned the current lock state. That way, we can easily change finish_xmote() to only update gl->gl_state when the state has actually changed. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Reviewed-by: Andrew Price <anprice@redhat.com>
2025-07-14net: phy: Don't register LEDs for genphySean Anderson
If a PHY has no driver, the genphy driver is probed/removed directly in phy_attach/detach. If the PHY's ofnode has an "leds" subnode, then the LEDs will be (un)registered when probing/removing the genphy driver. This could occur if the leds are for a non-generic driver that isn't loaded for whatever reason. Synchronously removing the PHY device in phy_detach leads to the following deadlock: rtnl_lock() ndo_close() ... phy_detach() phy_remove() phy_leds_unregister() led_classdev_unregister() led_trigger_set() netdev_trigger_deactivate() unregister_netdevice_notifier() rtnl_lock() There is a corresponding deadlock on the open/register side of things (and that one is reported by lockdep), but it requires a race while this one is deterministic. Generic PHYs do not support LEDs anyway, so don't bother registering them. Fixes: 01e5b728e9e4 ("net: phy: Add a binding for PHY LEDs") Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Link: https://patch.msgid.link/20250707195803.666097-1-sean.anderson@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-14selftests/tc-testing: Create test cases for adding qdiscs to invalid qdisc ↵Victor Nogueira
parents As described in a previous commit [1], Lion's patch [2] revealed an ancient bug in the qdisc API. Whenever a user tries to add a qdisc to an invalid parent (not a class, root, or ingress qdisc), the qdisc API will detect this after qdisc_create is called. Some qdiscs (like fq_codel, pie, and sfq) call functions (on their init callback) which assume the parent is valid, so qdisc_create itself may have caused a NULL pointer dereference in such cases. This commit creates 3 TDC tests that attempt to add fq_codel, pie and sfq qdiscs to invalid parents - Attempts to add an fq_codel qdisc to an hhf qdisc parent - Attempts to add a pie qdisc to a drr qdisc parent - Attempts to add an sfq qdisc to an inexistent hfsc classid (which would belong to a valid hfsc qdisc) [1] https://lore.kernel.org/all/20250707210801.372995-1-victor@mojatatu.com/ [2] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/ Signed-off-by: Victor Nogueira <victor@mojatatu.com> Link: https://patch.msgid.link/20250712145035.705156-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-14smc: Fix various oops due to inet_sock type confusion.Kuniyuki Iwashima
syzbot reported weird splats [0][1] in cipso_v4_sock_setattr() while freeing inet_sk(sk)->inet_opt. The address was freed multiple times even though it was read-only memory. cipso_v4_sock_setattr() did nothing wrong, and the root cause was type confusion. The cited commit made it possible to create smc_sock as an INET socket. The issue is that struct smc_sock does not have struct inet_sock as the first member but hijacks AF_INET and AF_INET6 sk_family, which confuses various places. In this case, inet_sock.inet_opt was actually smc_sock.clcsk_data_ready(), which is an address of a function in the text segment. $ pahole -C inet_sock vmlinux struct inet_sock { ... struct ip_options_rcu * inet_opt; /* 784 8 */ $ pahole -C smc_sock vmlinux struct smc_sock { ... void (*clcsk_data_ready)(struct sock *); /* 784 8 */ The same issue for another field was reported before. [2][3] At that time, an ugly hack was suggested [4], but it makes both INET and SMC code error-prone and hard to change. Also, yet another variant was fixed by a hacky commit 98d4435efcbf3 ("net/smc: prevent NULL pointer dereference in txopt_get"). Instead of papering over the root cause by such hacks, we should not allow non-INET socket to reuse the INET infra. Let's add inet_sock as the first member of smc_sock. [0]: kvfree_call_rcu(): Double-freed call. rcu_head 000000006921da73 WARNING: CPU: 0 PID: 6718 at mm/slab_common.c:1956 kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 Modules linked in: CPU: 0 UID: 0 PID: 6718 Comm: syz.0.17 Tainted: G W 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT Tainted: [W]=WARN Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 lr : kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 sp : ffff8000a03a7730 x29: ffff8000a03a7730 x28: 00000000fffffff5 x27: 1fffe000184823d3 x26: dfff800000000000 x25: ffff0000c2411e9e x24: ffff0000dd88da00 x23: ffff8000891ac9a0 x22: 00000000ffffffea x21: ffff8000891ac9a0 x20: ffff8000891ac9a0 x19: ffff80008afc2480 x18: 00000000ffffffff x17: 0000000000000000 x16: ffff80008ae642c8 x15: ffff700011ede14c x14: 1ffff00011ede14c x13: 0000000000000004 x12: ffffffffffffffff x11: ffff700011ede14c x10: 0000000000ff0100 x9 : 5fa3c1ffaf0ff000 x8 : 5fa3c1ffaf0ff000 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff8000a03a7078 x4 : ffff80008f766c20 x3 : ffff80008054d360 x2 : 0000000000000000 x1 : 0000000000000201 x0 : 0000000000000000 Call trace: kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 (P) cipso_v4_sock_setattr+0x2f0/0x3f4 net/ipv4/cipso_ipv4.c:1914 netlbl_sock_setattr+0x240/0x334 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa8/0x158 security/smack/smack_lsm.c:2581 smack_inode_setsecurity+0x378/0x430 security/smack/smack_lsm.c:2912 security_inode_setsecurity+0x118/0x3c0 security/security.c:2706 __vfs_setxattr_noperm+0x174/0x5c4 fs/xattr.c:251 __vfs_setxattr_locked+0x1ec/0x218 fs/xattr.c:295 vfs_setxattr+0x158/0x2ac fs/xattr.c:321 do_setxattr fs/xattr.c:636 [inline] file_setxattr+0x1b8/0x294 fs/xattr.c:646 path_setxattrat+0x2ac/0x320 fs/xattr.c:711 __do_sys_fsetxattr fs/xattr.c:761 [inline] __se_sys_fsetxattr fs/xattr.c:758 [inline] __arm64_sys_fsetxattr+0xc0/0xdc fs/xattr.c:758 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x180 arch/arm64/kernel/entry-common.c:879 el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 [1]: Unable to handle kernel write to read-only memory at virtual address ffff8000891ac9a8 KASAN: probably user-memory-access in range [0x0000000448d64d40-0x0000000448d64d47] Mem abort info: ESR = 0x000000009600004e EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x0e: level 2 permission fault Data abort info: ISV = 0, ISS = 0x0000004e, ISS2 = 0x00000000 CM = 0, WnR = 1, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000207144000 [ffff8000891ac9a8] pgd=0000000000000000, p4d=100000020f950003, pud=100000020f951003, pmd=0040000201000781 Internal error: Oops: 000000009600004e [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 6946 Comm: syz.0.69 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kvfree_call_rcu+0x31c/0x3f0 mm/slab_common.c:1971 lr : add_ptr_to_bulk_krc_lock mm/slab_common.c:1838 [inline] lr : kvfree_call_rcu+0xfc/0x3f0 mm/slab_common.c:1963 sp : ffff8000a28a7730 x29: ffff8000a28a7730 x28: 00000000fffffff5 x27: 1fffe00018b09bb3 x26: 0000000000000001 x25: ffff80008f66e000 x24: ffff00019beaf498 x23: ffff00019beaf4c0 x22: 0000000000000000 x21: ffff8000891ac9a0 x20: ffff8000891ac9a0 x19: 0000000000000000 x18: 00000000ffffffff x17: ffff800093363000 x16: ffff80008052c6e4 x15: ffff700014514ecc x14: 1ffff00014514ecc x13: 0000000000000004 x12: ffffffffffffffff x11: ffff700014514ecc x10: 0000000000000001 x9 : 0000000000000001 x8 : ffff00019beaf7b4 x7 : ffff800080a94154 x6 : 0000000000000000 x5 : ffff8000935efa60 x4 : 0000000000000008 x3 : ffff80008052c7fc x2 : 0000000000000001 x1 : ffff8000891ac9a0 x0 : 0000000000000001 Call trace: kvfree_call_rcu+0x31c/0x3f0 mm/slab_common.c:1967 (P) cipso_v4_sock_setattr+0x2f0/0x3f4 net/ipv4/cipso_ipv4.c:1914 netlbl_sock_setattr+0x240/0x334 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa8/0x158 security/smack/smack_lsm.c:2581 smack_inode_setsecurity+0x378/0x430 security/smack/smack_lsm.c:2912 security_inode_setsecurity+0x118/0x3c0 security/security.c:2706 __vfs_setxattr_noperm+0x174/0x5c4 fs/xattr.c:251 __vfs_setxattr_locked+0x1ec/0x218 fs/xattr.c:295 vfs_setxattr+0x158/0x2ac fs/xattr.c:321 do_setxattr fs/xattr.c:636 [inline] file_setxattr+0x1b8/0x294 fs/xattr.c:646 path_setxattrat+0x2ac/0x320 fs/xattr.c:711 __do_sys_fsetxattr fs/xattr.c:761 [inline] __se_sys_fsetxattr fs/xattr.c:758 [inline] __arm64_sys_fsetxattr+0xc0/0xdc fs/xattr.c:758 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x180 arch/arm64/kernel/entry-common.c:879 el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Code: aa1f03e2 52800023 97ee1e8d b4000195 (f90006b4) Fixes: d25a92ccae6b ("net/smc: Introduce IPPROTO_SMC") Reported-by: syzbot+40bf00346c3fe40f90f2@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/686d9b50.050a0220.1ffab7.0020.GAE@google.com/ Tested-by: syzbot+40bf00346c3fe40f90f2@syzkaller.appspotmail.com Reported-by: syzbot+f22031fad6cbe52c70e7@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/686da0f3.050a0220.1ffab7.0022.GAE@google.com/ Reported-by: syzbot+271fed3ed6f24600c364@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=271fed3ed6f24600c364 # [2] Link: https://lore.kernel.org/netdev/99f284be-bf1d-4bc4-a629-77b268522fff@huawei.com/ # [3] Link: https://lore.kernel.org/netdev/20250331081003.1503211-1-wangliang74@huawei.com/ # [4] Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: D. Wythe <alibuda@linux.alibaba.com> Reviewed-by: Wang Liang <wangliang74@huawei.com> Link: https://patch.msgid.link/20250711060808.2977529-1-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-14io_uring/net: cast min_not_zero() typeJens Axboe
kernel test robot reports that xtensa complains about different signedness for a min_not_zero() comparison. Cast the int part to size_t to avoid this issue. Fixes: e227c8cdb47b ("io_uring/net: use passed in 'len' in io_recv_buf_select()") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202507150504.zO5FsCPm-lkp@intel.com/ Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-07-14rust: use `#[used(compiler)]` to fix build and `modpost` with Rust >= 1.89.0Miguel Ojeda
Starting with Rust 1.89.0 (expected 2025-08-07), the Rust compiler fails to build the `rusttest` target due to undefined references such as: kernel...-cgu.0:(.text....+0x116): undefined reference to `rust_helper_kunit_get_current_test' Moreover, tooling like `modpost` gets confused: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/nova/nova.o ERROR: modpost: missing MODULE_LICENSE() in drivers/gpu/nova-core/nova_core.o The reason behind both issues is that the Rust compiler will now [1] treat `#[used]` as `#[used(linker)]` instead of `#[used(compiler)]` for our targets. This means that the retain section flag (`R`, `SHF_GNU_RETAIN`) will be used and that they will be marked as `unique` too, with different IDs. In turn, that means we end up with undefined references that did not get discarded in `rusttest` and that multiple `.modinfo` sections are generated, which confuse tooling like `modpost` because they only expect one. Thus start using `#[used(compiler)]` to keep the previous behavior and to be explicit about what we want. Sadly, it is an unstable feature (`used_with_arg`) [2] -- we will talk to upstream Rust about it. The good news is that it has been available for a long time (Rust >= 1.60) [3]. The changes should also be fine for previous Rust versions, since they behave the same way as before [4]. Alternatively, we could use `#[no_mangle]` or `#[export_name = ...]` since those still behave like `#[used(compiler)]`, but of course it is not really what we want to express, and it requires other changes to avoid symbol conflicts. Cc: David Wood <david@davidtw.co> Cc: Wesley Wiser <wwiser@gmail.com> Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/140872 [1] Link: https://github.com/rust-lang/rust/issues/93798 [2] Link: https://github.com/rust-lang/rust/pull/91504 [3] Link: https://godbolt.org/z/sxzWTMfzW [4] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Link: https://lore.kernel.org/r/20250712160103.1244945-3-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-07-14dt-bindings: gpu: mali-bifrost: Add Allwinner A523 compatibleMikhail Kalashnikov
Add a compatible for the Allwinner A523 SoC, with an integrated ARM Mali G57 MC1 (Valhall-JM) GPU. Signed-off-by: Mikhail Kalashnikov <iuncuim@gmail.com> Link: https://lore.kernel.org/r/20250711035730.17507-2-iuncuim@gmail.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-07-14docs: dt: writing-schema: Document preferred order of propertiesKrzysztof Kozlowski
Document established Devicetree bindings maintainers review practice: using DTS coding style property order in both 'properties' and 'required' secions. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250713-dt-bindings-docs-v2-4-672c898054ae@linaro.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-07-14docs: dt: writing-bindings: Document discouraged instance IDsKrzysztof Kozlowski
Document established Devicetree bindings maintainers review practice: instance indexes, either as properties or as custom new OF alias, are not accepted. Recommended way is to use, depending on the situation/hardware: different compatible, cell arguments or syscon phandle arguments. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250713-dt-bindings-docs-v2-3-672c898054ae@linaro.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-07-14docs: dt: writing-bindings: Document compatible and filename namingKrzysztof Kozlowski
Document established Devicetree bindings maintainers review practices: 1. Compatibles should not use bus suffixes to encode the type of interface, because the parent bus node defines that interface, e.g. "vendor,device" instead of "vendor,device-i2c" + "vendor,device-spi". 2. If the compatible represents the device as a whole, it should not contain the type of device in the name. 3. Filenames should match compatible. The best if match is 100%, but if binding has multiple compatibles, then one of the fallbacks should be used. Alternatively a genericish name is allowed if it follows "vendor,device" style. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250713-dt-bindings-docs-v2-2-672c898054ae@linaro.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-07-14docs: dt: submitting-patches: Avoid 'YAML' in the subject and add an exampleKrzysztof Kozlowski
Patches adding new device bindings should avoid 'YAML' keyword in the subject, because all bindings are supposed to be in DT schema format, which uses YAML. The DT schema is welcomed only in case of patches doing conversion. Effectively people get confused that subject should not contain anything else than device name after the prefix, so add two recommended examples. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250713-dt-bindings-docs-v2-1-672c898054ae@linaro.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-07-14objtool/rust: add one more `noreturn` Rust function for Rust 1.89.0Miguel Ojeda
Starting with Rust 1.89.0 (expected 2025-08-07), under `CONFIG_RUST_DEBUG_ASSERTIONS=y`, `objtool` may report: rust/kernel.o: warning: objtool: _R..._6kernel4pageNtB5_4Page8read_raw() falls through to next function _R..._6kernel4pageNtB5_4Page9write_raw() (and many others) due to calls to the `noreturn` symbol: core::panicking::panic_nounwind_fmt Thus add the mangled one to the list so that `objtool` knows it is actually `noreturn`. See commit 56d680dd23c3 ("objtool/rust: list `noreturn` Rust functions") for more details. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Cc: Josh Poimboeuf <jpoimboe@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20250712160103.1244945-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-07-14x86/mm: Remove duplicated __PAGE_KERNEL(_EXEC) definitionsNikolay Borisov
__PAGE_KERNEL(_EXEC) is defined twice, just remove the superfluous set. No functional changes. Signed-off-by: Nikolay Borisov <nik.borisov@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250714170258.390175-1-nik.borisov@suse.com
2025-07-14lib/crypto: tests: Add KUnit tests for SHA-1 and HMAC-SHA1Eric Biggers
Add a KUnit test suite for the SHA-1 library functions, including the corresponding HMAC support. The core test logic is in the previously-added hash-test-template.h. This commit just adds the actual KUnit suite, and it adds the generated test vectors to the tree so that gen-hash-testvecs.py won't have to be run at build time. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250712232329.818226-16-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-07-14lib/crypto: tests: Add KUnit tests for Poly1305Eric Biggers
Add a KUnit test suite for the Poly1305 functions. Most of its test cases are instantiated from hash-test-template.h, which is also used by the SHA-2 tests. A couple additional test cases are also included to test edge cases specific to Poly1305. Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250709200112.258500-5-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-07-14lib/crypto: tests: Add KUnit tests for SHA-384 and SHA-512Eric Biggers
Add KUnit test suites for the SHA-384 and SHA-512 library functions, including the corresponding HMAC support. The core test logic is in the previously-added hash-test-template.h. This commit just adds the actual KUnit suites, and it adds the generated test vectors to the tree so that gen-hash-testvecs.py won't have to be run at build time. Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250709200112.258500-4-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-07-14lib/crypto: tests: Add KUnit tests for SHA-224 and SHA-256Eric Biggers
Add KUnit test suites for the SHA-224 and SHA-256 library functions, including the corresponding HMAC support. The core test logic is in the previously-added hash-test-template.h. This commit just adds the actual KUnit suites, and it adds the generated test vectors to the tree so that gen-hash-testvecs.py won't have to be run at build time. Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250709200112.258500-3-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-07-14lib/crypto: tests: Add hash-test-template.h and gen-hash-testvecs.pyEric Biggers
Add hash-test-template.h which generates the following KUnit test cases for hash functions: test_hash_test_vectors test_hash_all_lens_up_to_4096 test_hash_incremental_updates test_hash_buffer_overruns test_hash_overlaps test_hash_alignment_consistency test_hash_ctx_zeroization test_hash_interrupt_context_1 test_hash_interrupt_context_2 test_hmac (when HMAC is supported) benchmark_hash (when CONFIG_CRYPTO_LIB_BENCHMARK=y) The initial use cases for this will be sha224_kunit, sha256_kunit, sha384_kunit, sha512_kunit, and poly1305_kunit. Add a Python script gen-hash-testvecs.py which generates the test vectors required by test_hash_test_vectors, test_hash_all_lens_up_to_4096, and test_hmac. Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250709200112.258500-2-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-07-14fsverity: Switch from crypto_shash to SHA-2 libraryEric Biggers
fsverity supports two hash algorithms: SHA-256 and SHA-512. Since both of these have a library API now, just use the library API instead of crypto_shash. Even with multiple algorithms, the library-based code still ends up being quite a bit simpler, due to how clumsy the old-school crypto API is. The library-based code is also more efficient, since it avoids overheads such as indirect calls. Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250630172224.46909-3-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-07-14fsverity: Explicitly include <linux/export.h>Eric Biggers
Fix build warnings with W=1 that started appearing after commit a934a57a42f6 ("scripts/misc-check: check missing #include <linux/export.h> when W=1"). Link: https://lore.kernel.org/r/20250614221723.131827-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-07-14apparmor: use SHA-256 library API instead of crypto_shash APIEric Biggers
This user of SHA-256 does not support any other algorithm, so the crypto_shash abstraction provides no value. Just use the SHA-256 library API instead, which is much simpler and easier to use. Acked-by: John Johansen <john.johansen@canonical.com> Link: https://lore.kernel.org/r/20250630174805.59010-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-07-14crypto: sha1 - Remove sha1_base.hEric Biggers
sha1_base.h is no longer used, so remove it. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250712232329.818226-15-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-07-14lib/crypto: x86/sha1: Migrate optimized code into libraryEric Biggers
Instead of exposing the x86-optimized SHA-1 code via x86-specific crypto_shash algorithms, instead just implement the sha1_blocks() library function. This is much simpler, it makes the SHA-1 library functions be x86-optimized, and it fixes the longstanding issue where the x86-optimized SHA-1 code was disabled by default. SHA-1 still remains available through crypto_shash, but individual architectures no longer need to handle it. To match sha1_blocks(), change the type of the nblocks parameter of the assembly functions from int to size_t. The assembly functions actually already treated it as size_t. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250712232329.818226-14-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-07-14iio: ABI: fix correctness of I and Q modifiersDavid Lechner
Update the IIO ABI documentation to reflect the actual usage of channels with I and Q modifiers. These are currently only used in a few drivers: frequency/admv1013 (kernel v5.17): - in_altvoltageY-altvoltageZ_i_calibphase - in_altvoltageY-altvoltageZ_q_calibphase - in_altvoltageY_i_calibbias - in_altvoltageY_q_calibbias frequency/admv1014 (kernel v5.18): - in_altvoltageY_i_phase - in_altvoltageY_q_phase - in_altvoltageY_i_offset - in_altvoltageY_q_offset - in_altvoltageY_i_calibscale_course - in_altvoltageY_i_calibscale_fine - in_altvoltageY_q_calibscale_course - in_altvoltageY_q_calibscale_fine frequency/adrf6780 (kernel v5.16): - out_altvoltageY_i_phase - out_altvoltageY_q_phase There are no _raw or _scale attributes in use, so those are all removed. There are no currentY attributes in use with these modifiers, so those are also removed. All of the voltageY are changed to altvoltageY since that is how they are actually used. None of these channels are used with scan buffers, so all of those attributes are removed as well. And the {in,out}_altvoltageY_{i,q}_phase attributes were missing so those are added. The differential channel names for admv1013 are fixed. Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/20250711-iio-abi-fix-i-and-q-modifiers-v1-1-35963c9c8c01@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: Add driver for Nicera D3-323-AA PIR sensorWaqar Hameed
Nicera D3-323-AA is a PIR sensor for human detection. It has support for raw data measurements and detection notification. The communication protocol is custom made and therefore needs to be GPIO bit banged. The device has two main settings that can be configured: a threshold value for detection and a band-pass filter. The configurable parameters for the band-pass filter are the high-pass and low-pass cutoff frequencies and its peak gain. Map these settings to the corresponding parameters in the `iio` framework. Raw data measurements can be obtained from the device. However, since we rely on bit banging, it will be rather cumbersome with buffer support. The main reason being that the data protocol has strict timing requirements (it's serial like UART), and it's mainly used during debugging since in real-world applications only the event notification is of importance. Therefore, only add support for events (for now). Signed-off-by: Waqar Hameed <waqar.hameed@axis.com> Link: https://patch.msgid.link/29f84da1431f4a3f17fdeef27297a4ab14455404.1751636734.git.waqar.hameed@axis.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14dt-bindings: iio: proximity: Add Nicera D3-323-AA PIR sensorWaqar Hameed
Nicera D3-323-AA is a PIR sensor for human detection. It has two GPIOs for detection and data communication. Signed-off-by: Waqar Hameed <waqar.hameed@axis.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/19a2744cebaee57fe5349986094168524baa9838.1751636734.git.waqar.hameed@axis.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14dt-bindings: vendor-prefixes: Add NiceraWaqar Hameed
Nicera (Nippon Ceramic Co.) is a manufacturer of a wide range of sensors. For example infrared, ultrasonic, gas sensors and much more. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Waqar Hameed <waqar.hameed@axis.com> Link: https://patch.msgid.link/b52e82aa312a52c03d2b6c58cf329884d1829d29.1751636734.git.waqar.hameed@axis.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: dac: vf610: Simplify with devm_clk_get_enabled()Krzysztof Kozlowski
Driver is getting clock and almost immediately enabling it, with no relevant code executed between, thus the probe path and cleanups can be simplified with devm_clk_get_enabled(). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20250713-iio-clk-get-enabled-v1-4-70abc1f9ce6c@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: adc: vf610: Simplify with dev_err_probeKrzysztof Kozlowski
Use dev_err_probe() to make error code handling simpler and handle deferred probe nicely (avoid spamming logs). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20250713-iio-clk-get-enabled-v1-3-70abc1f9ce6c@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: adc: vf610: Drop -ENOMEM error messageKrzysztof Kozlowski
Core already prints detailed error messages on ENOMEM errors and drivers should avoid repeating it. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20250713-iio-clk-get-enabled-v1-2-70abc1f9ce6c@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: imu: bno055: make bno055_sysfs_attr constDavid Lechner
Add const qualifier to struct bno055_sysfs_attr and its array fields. All of this is read-only data so it can be made const. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250709-iio-const-data-19-v2-2-fb3fc9191251@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: imu: bno055: fix OOB access of hw_xlate arrayDavid Lechner
Fix a potential out-of-bounds array access of the hw_xlate array in bno055.c. In bno055_get_regmask(), hw_xlate was iterated over the length of the vals array instead of the length of the hw_xlate array. In the case of bno055_gyr_scale, the vals array is larger than the hw_xlate array, so this could result in an out-of-bounds access. In practice, this shouldn't happen though because a match should always be found which breaks out of the for loop before it iterates beyond the end of the hw_xlate array. By adding a new hw_xlate_len field to the bno055_sysfs_attr, we can be sure we are iterating over the correct length. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202507100510.rGt1YOOx-lkp@intel.com/ Fixes: 4aefe1c2bd0c ("iio: imu: add Bosch Sensortec BNO055 core driver") Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250709-iio-const-data-19-v2-1-fb3fc9191251@baylibre.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14dt-bindings: iio: adc: Add support for MT7981Aleksander Jan Bajkowski
The temperature sensor in the MT7981 is same as in the MT7986. Add compatible string for mt7981. Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20250708220405.1072393-2-olek2@wp.pl Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: accel: kionix-kx022a: Apply approximate iwyu principles to includesJonathan Cameron
Motivated by the W=1 warning about export.h that was introduced this cycle this is an attempt to apply an approximation of the principles of including whatever is used in the file directly. Helped by the include-what-you-use tool. Reasoning: - Drop linux/moduleparam.h as completely unused. - linux/array_size.h for ARRAY_SIZE() - linux/bitmap.h for for_each_set_bit - linux/errno.h for error codes. - linux/export.h for EXPORT_SYMBOL*() - linux/math64.h for do_div - alternative would be asm/div64.h - linux/minmax.h for min() - linux/sysfs.h for sysfs_emit() - linux/time64.h for USEC_PER_MSEC - linux/iio/buffer.h for iio_push_to_buffers_with_timestamp() - asm/byteorder.h for le16_to_cpu() Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20250629183649.184479-1-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: adc: ad4170-4: Add support for weigh scale, thermocouple, and RTD sensMarcelo Schmitt
The AD4170-4 design provides features to aid interfacing with weigh scales, thermocouples, and RTD sensors, which are set up with additional circuitry for proper sensor operation. A key characteristic of those sensors is that the circuit they are in must be excited with a single, a pair, or two pairs of signals. The external circuit can be excited either by a voltage supply or by AD4170-4 excitation signals. The sensor can then be read through a different pair of lines that are connected to the AD4170-4 ADC. Extend the ad4170-4 driver to handle external circuit sensors. Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Link: https://patch.msgid.link/52686943040ecad34cc89833d4d5d37f1a51f412.1751895245.git.marcelo.schmitt@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-30 07:12:49 +0000