summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-07-22Merge branch 'net-mlx5-misc-changes-2025-07-21'Jakub Kicinski
Tariq Toukan says: ==================== net/mlx5: misc changes 2025-07-21 This series by Lama contains misc enhancements to the SHAMPO parameters. ==================== Link: https://patch.msgid.link/1753081999-326247-1-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-22net/mlx5e: Remove duplicate mkey from SHAMPO headerLama Kayal
SHAMPO structure holds two variations of the mkey, which is unnecessary, a duplication that's repeated per rq. Remove duplicate mkey information and keep only one version, the one used in the fast path, rename field to reflect field type clearly. Signed-off-by: Lama Kayal <lkayal@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/1753081999-326247-4-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-22net/mlx5e: SHAMPO, Remove mlx5e_shampo_get_log_hd_entry_size()Lama Kayal
Refactor mlx5e_shampo_get_log_hd_entry_size() as macro, for more simplicity. Signed-off-by: Lama Kayal <lkayal@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/1753081999-326247-3-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-22net/mlx5e: SHAMPO, Cleanup reservation size formulaLama Kayal
The reservation size formula can be reduced to a simple evaluation of MLX5E_SHAMPO_WQ_RESRV_SIZE. This leaves mlx5e_shampo_get_log_rsrv_size() with one single use, which can be replaced with a macro for simplicity. Also, function mlx5e_shampo_get_log_rsrv_size() is used only throughout params.c, make it static. Signed-off-by: Lama Kayal <lkayal@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/1753081999-326247-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-22tcp: trace retransmit failures in tcp_retransmit_skbFan Yu
Background ========== When TCP retransmits a packet due to missing ACKs, the retransmission may fail for various reasons (e.g., packets stuck in driver queues, receiver zero windows, or routing issues). The original tcp_retransmit_skb tracepoint: 'commit e086101b150a ("tcp: add a tracepoint for tcp retransmission")' lacks visibility into these failure causes, making production diagnostics difficult. Solution ======== Adds the retval("err") to the tcp_retransmit_skb tracepoint. Enables users to know why some tcp retransmission failed and users can filter retransmission failures by retval. Compatibility description ========================= This patch extends the tcp_retransmit_skb tracepoint by adding a new "err" field at the end of its existing structure (within TP_STRUCT__entry). The compatibility implications are detailed as follows: 1) Structural compatibility for legacy user-space tools Legacy tools/BPF programs accessing existing fields (by offset or name) can still work without modification or recompilation.The new field is appended to the end, preserving original memory layout. 2) Note: semantic changes The original tracepoint primarily only focused on successfully retransmitted packets. With this patch, the tracepoint now can figure out packets that may terminate early due to specific reasons. For accurate statistics, users should filter using "err" to distinguish outcomes. Before patched: field:const void * skbaddr; offset:8; size:8; signed:0; field:const void * skaddr; offset:16; size:8; signed:0; field:int state; offset:24; size:4; signed:1; field:__u16 sport; offset:28; size:2; signed:0; field:__u16 dport; offset:30; size:2; signed:0; field:__u16 family; offset:32; size:2; signed:0; field:__u8 saddr[4]; offset:34; size:4; signed:0; field:__u8 daddr[4]; offset:38; size:4; signed:0; field:__u8 saddr_v6[16]; offset:42; size:16; signed:0; field:__u8 daddr_v6[16]; offset:58; size:16; signed:0; print fmt: "skbaddr=%p skaddr=%p family=%s sport=%hu dport=%hu saddr=%pI4 daddr=%pI4 saddrv6=%pI6c daddrv6=%pI6c state=%s" After patched: field:const void * skbaddr; offset:8; size:8; signed:0; field:const void * skaddr; offset:16; size:8; signed:0; field:int state; offset:24; size:4; signed:1; field:__u16 sport; offset:28; size:2; signed:0; field:__u16 dport; offset:30; size:2; signed:0; field:__u16 family; offset:32; size:2; signed:0; field:__u8 saddr[4]; offset:34; size:4; signed:0; field:__u8 daddr[4]; offset:38; size:4; signed:0; field:__u8 saddr_v6[16]; offset:42; size:16; signed:0; field:__u8 daddr_v6[16]; offset:58; size:16; signed:0; field:int err; offset:76; size:4; signed:1; print fmt: "skbaddr=%p skaddr=%p family=%s sport=%hu dport=%hu saddr=%pI4 daddr=%pI4 saddrv6=%pI6c daddrv6=%pI6c state=%s err=%d" Co-developed-by: xu xin <xu.xin16@zte.com.cn> Signed-off-by: xu xin <xu.xin16@zte.com.cn> Signed-off-by: Fan Yu <fan.yu9@zte.com.cn> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20250721111607626_BDnIJB0ywk6FghN63bor@zte.com.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-22perf ui scripts: Switch FILENAME_MAX to NAME_MAXIan Rogers
FILENAME_MAX is the same as PATH_MAX (4kb) in glibc rather than NAME_MAX's 255. Switch to using NAME_MAX and ensure the '\0' is accounted for in the path's buffer size. Signed-off-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250717150855.1032526-3-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-07-22perf pmu: Switch FILENAME_MAX to NAME_MAXIan Rogers
FILENAME_MAX is the same as PATH_MAX (4kb) in glibc rather than NAME_MAX's 255. Switch to using NAME_MAX and ensure the '\0' is accounted for in the path's buffer size. Fixes: 754baf426e09 ("perf pmu: Change aliases from list to hashmap") Signed-off-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250717150855.1032526-2-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-07-22tools subcmd: Tighten the filename size in check_if_command_finishedIan Rogers
FILENAME_MAX is often PATH_MAX (4kb), far more than needed for the /proc path. Make the buffer size sufficient for the maximum integer plus "/proc/" and "/status" with a '\0' terminator. Fixes: 5ce42b5de461 ("tools subcmd: Add non-waitpid check_if_command_finished()") Signed-off-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250717150855.1032526-1-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-07-22net: Kconfig: add endif/endmenu commentsRandy Dunlap
Add comments on endif & endmenu blocks. This can save time when searching & trying to understand kconfig menu dependencies. The other endif & endmenu statements are already commented like this. This makes it similar to drivers/net/Kconfig, which is already commented like this. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250721020420.3555128-1-rdunlap@infradead.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-22Merge branch 'selftests-drv-net-test-xdp-native-support'Jakub Kicinski
Mohsin Bashir says: ==================== selftests: drv-net: Test XDP native support This patch series add tests to validate XDP native support for PASS, DROP, ABORT, and TX actions, as well as headroom and tailroom adjustment. For adjustment tests, validate support for both the extension and shrinking cases across various packet sizes and offset values. The pass criteria for head/tail adjustment tests require that at-least one adjustment value works for at-least one packet size. This ensure that the variability in maximum supported head/tail adjustment offset across different drivers is being incorporated. The results reported in this series are based on netdevsim. However, the series is tested against multiple other drivers including fbnic. Note: The XDP support for fbnic will be added later. ==================== Link: https://patch.msgid.link/20250719083059.3209169-1-mohsin.bashr@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-22selftests: drv-net: Test head-adjustment supportMohsin Bashir
Add test to validate the headroom adjustment support for both extension and the shrinking cases. For the extension part, eat up space from the start of payload data whereas, for the shrinking part, populate the newly available space with a tag. In the user-space, validate that a test string is manipulated accordingly. The negative and positive offset values result in shrinking and growing of headroom (growing and shrinking of payload) respectively. TAP version 13 1..9 ok 1 xdp.test_xdp_native_pass_sb ok 2 xdp.test_xdp_native_pass_mb ok 3 xdp.test_xdp_native_drop_sb ok 4 xdp.test_xdp_native_drop_mb ok 5 xdp.test_xdp_native_tx_mb \# Failed run: pkt_sz 512, ... offset 1. Reason: Adjustment failed ok 6 xdp.test_xdp_native_adjst_tail_grow_data ok 7 xdp.test_xdp_native_adjst_tail_shrnk_data \# Failed run: pkt_sz 512, ... offset -128. Reason: Adjustment failed ok 8 xdp.test_xdp_native_adjst_head_grow_data \# Failed run: pkt_sz (512) > HDS threshold (0) and offset 64 > 48 ok 9 xdp.test_xdp_native_adjst_head_shrnk_data \# Totals: pass:9 fail:0 xfail:0 xpass:0 skip:0 error:0 Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com> Link: https://patch.msgid.link/20250719083059.3209169-6-mohsin.bashr@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-22selftests: drv-net: Test tail-adjustment supportMohsin Bashir
Add test to validate support for the two cases of tail adjustment: 1) tail extension, and 2) tail shrinking across different frame sizes and offset values. For each of the two cases, test both the single and multi-buffer cases by choosing appropriate packet size. The negative offset value result in growing of tailroom (shrinking of payload) while the positive offset result in shrinking of tailroom (growing of payload). Since the support for tail adjustment varies across drivers, classify the test as pass if at least one combination of packet size and offset from a pre-selected list results in a successful run. In case of an unsuccessful run, report the failure and highlight the packet size and offset values that caused the test to fail, as well as the values that resulted in the last successful run. Note: The growing part of this test for netdevsim may appear flaky when the offset value is larger than 1. This behavior occurs because tailroom is not explicitly reserved for netdevsim, with 1 being the typical tailroom value. However, in certain cases, such as payload being the last in the page with additional available space, the truesize is expanded. This also result increases the tailroom causing the test to pass intermittently. In contrast, when tailrrom is explicitly reserved, such as in the of fbnic, the test results are deterministic. ./drivers/net/xdp.py TAP version 13 1..7 ok 1 xdp.test_xdp_native_pass_sb ok 2 xdp.test_xdp_native_pass_mb ok 3 xdp.test_xdp_native_drop_sb ok 4 xdp.test_xdp_native_drop_mb ok 5 xdp.test_xdp_native_tx_mb \# Failed run: ... successful run: ... offset 1. Reason: Adjustment failed ok 6 xdp.test_xdp_native_adjst_tail_grow_data ok 7 xdp.test_xdp_native_adjst_tail_shrnk_data \# Totals: pass:7 fail:0 xfail:0 xpass:0 skip:0 error:0 Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com> Link: https://patch.msgid.link/20250719083059.3209169-5-mohsin.bashr@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-22selftests: drv-net: Test XDP_TX supportMohsin Bashir
Add test to verify the XDP_TX functionality by generating traffic from a remote node on a specific UDP port and redirecting it back to the sender. ./drivers/net/xdp.py TAP version 13 1..5 ok 1 xdp.test_xdp_native_pass_sb ok 2 xdp.test_xdp_native_pass_mb ok 3 xdp.test_xdp_native_drop_sb ok 4 xdp.test_xdp_native_drop_mb ok 5 xdp.test_xdp_native_tx_mb \# Totals: pass:5 fail:0 xfail:0 xpass:0 skip:0 error:0 Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com> Link: https://patch.msgid.link/20250719083059.3209169-4-mohsin.bashr@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-22selftests: drv-net: Test XDP_PASS/DROP supportMohsin Bashir
Test XDP_PASS/DROP in single buffer and multi buffer mode when XDP native support is available. ./drivers/net/xdp.py TAP version 13 1..4 ok 1 xdp.test_xdp_native_pass_sb ok 2 xdp.test_xdp_native_pass_mb ok 3 xdp.test_xdp_native_drop_sb ok 4 xdp.test_xdp_native_drop_mb \# Totals: pass:4 fail:0 xfail:0 xpass:0 skip:0 error:0 Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com> Link: https://patch.msgid.link/20250719083059.3209169-3-mohsin.bashr@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-22net: netdevsim: hook in XDP handlingJakub Kicinski
Add basic XDP support by hooking in do_xdp_generic(). This should be enough to validate most basic XDP tests. Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com> Link: https://patch.msgid.link/20250719083059.3209169-2-mohsin.bashr@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-22cdrom: Call cdrom_mrw_exit from cdrom_release functionPhillip Potter
Remove the cdrom_mrw_exit call from unregister_cdrom, as it invokes block commands that can fail due to a NULL pointer dereference from the call happening too late, during the unloading of the driver (e.g. unplugging of USB optical drives). Instead perform the call inside cdrom_release, thus also removing the need for the exit function pointer inside the cdrom_device_info struct. Reported-by: Sergey Senozhatsky <senozhatsky@chromium.org> Closes: https://lore.kernel.org/linux-block/uxgzea5ibqxygv3x7i4ojbpvcpv2wziorvb3ns5cdtyvobyn7h@y4g4l5ezv2ec Suggested-by: Jens Axboe <axboe@kernel.dk> Link: https://lore.kernel.org/linux-block/6686fe78-a050-4a1d-aa27-b7bf7ca6e912@kernel.dk Tested-by: Phillip Potter <phil@philpotter.co.uk> Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20250722231900.1164-2-phil@philpotter.co.uk Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-07-22perf: ftrace: add graph tracer options args/retval/retval-hex/retaddrChangbin Du
This change adds support for new funcgraph tracer options funcgraph-args, funcgraph-retval, funcgraph-retval-hex and funcgraph-retaddr. The new added options are: - args : Show function arguments. - retval : Show function return value. - retval-hex : Show function return value in hexadecimal format. - retaddr : Show function return address. # ./perf ftrace -G vfs_write --graph-opts retval,retaddr # tracer: function_graph # # CPU DURATION FUNCTION CALLS # | | | | | | | 5) | mutex_unlock() { /* <-rb_simple_write+0xda/0x150 */ 5) 0.188 us | local_clock(); /* <-lock_release+0x2ad/0x440 ret=0x3bf2a3cf90e */ 5) | rt_mutex_slowunlock() { /* <-rb_simple_write+0xda/0x150 */ 5) | _raw_spin_lock_irqsave() { /* <-rt_mutex_slowunlock+0x4f/0x200 */ 5) 0.123 us | preempt_count_add(); /* <-_raw_spin_lock_irqsave+0x23/0x90 ret=0x0 */ 5) 0.128 us | local_clock(); /* <-__lock_acquire.isra.0+0x17a/0x740 ret=0x3bf2a3cfc8b */ 5) 0.086 us | do_raw_spin_trylock(); /* <-_raw_spin_lock_irqsave+0x4a/0x90 ret=0x1 */ 5) 0.845 us | } /* _raw_spin_lock_irqsave ret=0x292 */ 5) | _raw_spin_unlock_irqrestore() { /* <-rt_mutex_slowunlock+0x191/0x200 */ 5) 0.097 us | local_clock(); /* <-lock_release+0x2ad/0x440 ret=0x3bf2a3cff1f */ 5) 0.086 us | do_raw_spin_unlock(); /* <-_raw_spin_unlock_irqrestore+0x23/0x60 ret=0x1 */ 5) 0.104 us | preempt_count_sub(); /* <-_raw_spin_unlock_irqrestore+0x35/0x60 ret=0x0 */ 5) 0.726 us | } /* _raw_spin_unlock_irqrestore ret=0x80000000 */ 5) 1.881 us | } /* rt_mutex_slowunlock ret=0x0 */ 5) 2.931 us | } /* mutex_unlock ret=0x0 */ Signed-off-by: Changbin Du <changbin.du@huawei.com> Reviewed-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250613114048.132336-1-changbin.du@huawei.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-07-22rv/ltl: Do not execute the Buchi automaton twice on start conditionNam Cao
On start condition of a Buchi automaton, the automaton is executed twice. This is fine for now, as all the current LTL operators do not care about this. But it would break the 'next' operator, which will be introduced in a follow-up patch. Prepare for the introduction of the 'next' operator, only execute the automaton once on start condition. Cc: John Ogness <john.ogness@linutronix.de> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Gabriele Monaco <gmonaco@redhat.com> Link: https://lore.kernel.org/9379f4e7b9c1c69a6dca3e20a22936c850a25ca7.1752239482.git.namcao@linutronix.de Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-07-22tracing: Fix comment in trace_module_remove_events()Steven Rostedt
Fix typo "allocade" -> "allocated". Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Link: https://lore.kernel.org/20250710095628.42ed6b06@batman.local.home Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-07-22tracing: Remove redundant config HAVE_FTRACE_MCOUNT_RECORDSteven Rostedt
Ftrace is tightly coupled with architecture specific code because it requires the use of trampolines written in assembly. This means that when a new feature or optimization is made, it must be done for all architectures. To simplify the approach, CONFIG_HAVE_FTRACE_* configs are added to denote which architecture has the new enhancement so that other architectures can still function until they too have been updated. The CONFIG_HAVE_FTRACE_MCOUNT was added to help simplify the DYNAMIC_FTRACE work, but now every architecture that implements DYNAMIC_FTRACE also has HAVE_FTRACE_MCOUNT set too, making it redundant with the HAVE_DYNAMIC_FTRACE. Remove the HAVE_FTRACE_MCOUNT config and use DYNAMIC_FTRACE directly where applicable. Link: https://lore.kernel.org/all/20250703154916.48e3ada7@gandalf.local.home/ Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/20250704104838.27a18690@gandalf.local.home Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-07-22tracing: Remove EVENT_FILE_FL_SOFT_MODE flagSteven Rostedt
When soft disabling of trace events was first created, it needed to have a way to know if a file had a user that was using it with soft disabled (for triggers that need to enable or disable events from a context that can not really enable or disable the event, it would set SOFT_DISABLED to state it is disabled). The flag SOFT_MODE was used to denote that an event had a user that would enable or disable it via the SOFT_DISABLED flag. Commit 1cf4c0732db3c ("tracing: Modify soft-mode only if there's no other referrer") fixed a bug where if two users were using the SOFT_DISABLED flag the accounting would get messed up as the SOFT_MODE flag could only handle one user. That commit added the sm_ref counter which kept track of how many users were using the event in "soft mode". This made the SOFT_MODE flag redundant as it should only be set if the sm_ref counter is non zero. Remove the SOFT_MODE flag and just use the sm_ref counter to know the event is in soft mode or not. This makes the code a bit simpler. Link: https://lore.kernel.org/all/20250702111908.03759998@batman.local.home/ Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Gabriele Paoloni <gpaoloni@redhat.com> Link: https://lore.kernel.org/20250702143657.18dd1882@batman.local.home Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-07-22tracing: Remove pointless memory barriersNam Cao
Memory barriers are useful to ensure memory accesses from one CPU appear in the original order as seen by other CPUs. Some smp_rmb() and smp_wmb() are used, but they are not ordering multiple memory accesses. Remove them. Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Gabriele Monaco <gmonaco@redhat.com> Link: https://lore.kernel.org/20250626151940.1756398-1-namcao@linutronix.de Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-07-22ftrace: Make DYNAMIC_FTRACE always enabled for architectures that support itSteven Rostedt
ftrace has two flavors: 1) static: Where every function always calls the ftrace trampoline 2) dynamic: Where each function has nops that can be changed on demand to jump to the ftrace trampoline when needed. The static flavor has very high performance overhead and was only created to make it easier for architectures to implement the dynamic flavor. An architecture developer can first implement the static ftrace to make sure the trampolines work before working on the more complicated dynamic aspect of ftrace. Once the architecture can support dynamic ftrace, there's no reason to continue to support the static flavor. In fact, the static flavor tends to bitrot and bugs start to appear in them. Remove the prompt to pick DYNAMIC_FTRACE and simply enable it if the architecture supports it. Link: https://lore.kernel.org/all/f7e12c6d-892e-4ca3-9ef0-fbb524d04a48@ghiti.fr/ Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Alexandre Ghiti <alex@ghiti.fr> Cc: ChenMiao <chenmiao.ku@gmail.com> Link: https://lore.kernel.org/20250703115222.2d7c8cd5@batman.local.home Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-07-22fgraph: Keep track of when fgraph_ops are registered or notSteven Rostedt
Add a warning if unregister_ftrace_graph() is called without ever registering it, or if register_ftrace_graph() is called twice. This can detect errors when they happen and not later when there's a side effect: Link: https://lore.kernel.org/all/20250617120830.24fbdd62@gandalf.local.home/ Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/20250701194451.22e34724@gandalf.local.home Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-07-23rust: Add warn_on macroFUJITA Tomonori
Add warn_on macro, uses the BUG/WARN feature (lib/bug.c) via assembly for x86_64/arm64/riscv. The current Rust code simply wraps BUG() macro but doesn't provide the proper debug information. The BUG/WARN feature can only be used from assembly. This uses the assembly code exported by the C side via ARCH_WARN_ASM macro. To avoid duplicating the assembly code, this approach follows the same strategy as the static branch code: it generates the assembly code for Rust using the C preprocessor at compile time. Similarly, ARCH_WARN_REACHABLE is also used at compile time to generate the assembly code; objtool's reachable annotation code. It's used for only architectures that use objtool. For now, Loongarch and arm just use a wrapper for WARN macro. UML doesn't use the assembly BUG/WARN feature; just wrapping generic BUG/WARN functions implemented in C works. Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250502094537.231725-5-fujita.tomonori@gmail.com [ Avoid evaluating the condition twice (a good idea in general, but it also matches the C side). Simplify with `as_char_ptr()` to avoid a cast. Cast to `ffi` integer types for `warn_slowpath_fmt`. Avoid cast for `null()`. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-07-22ring-buffer: Remove ring_buffer_read_prepare_sync()Steven Rostedt
When the ring buffer was first introduced, reading the non-consuming "trace" file required disabling the writing of the ring buffer. To make sure the writing was fully disabled before iterating the buffer with a non-consuming read, it would set the disable flag of the buffer and then call an RCU synchronization to make sure all the buffers were synchronized. The function ring_buffer_read_start() originally would initialize the iterator and call an RCU synchronization, but this was for each individual per CPU buffer where this would get called many times on a machine with many CPUs before the trace file could be read. The commit 72c9ddfd4c5bf ("ring-buffer: Make non-consuming read less expensive with lots of cpus.") separated ring_buffer_read_start into ring_buffer_read_prepare(), ring_buffer_read_sync() and then ring_buffer_read_start() to allow each of the per CPU buffers to be prepared, call the read_buffer_read_sync() once, and then the ring_buffer_read_start() for each of the CPUs which made things much faster. The commit 1039221cc278 ("ring-buffer: Do not disable recording when there is an iterator") removed the requirement of disabling the recording of the ring buffer in order to iterate it, but it did not remove the synchronization that was happening that was required to wait for all the buffers to have no more writers. It's now OK for the buffers to have writers and no synchronization is needed. Remove the synchronization and put back the interface for the ring buffer iterator back before commit 72c9ddfd4c5bf was applied. Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Link: https://lore.kernel.org/20250630180440.3eabb514@batman.local.home Reported-by: David Howells <dhowells@redhat.com> Fixes: 1039221cc278 ("ring-buffer: Do not disable recording when there is an iterator") Tested-by: David Howells <dhowells@redhat.com> Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-07-23tpm_crb_ffa: handle tpm busy return codePrachotan Bathi
Platforms supporting direct message request v2 [1] can support secure partitions that support multiple services. For CRB over FF-A interface, if the firmware TPM or TPM service [1] shares its Secure Partition (SP) with another service, message requests may fail with a -EBUSY error. To handle this, replace the single check and call with a retry loop that attempts the TPM message send operation until it succeeds or a configurable timeout is reached. Implement a _try_send_receive function to do a single send/receive and modify the existing send_receive to add this retry loop. The retry mechanism introduces a module parameter (`busy_timeout_ms`, default: 2000ms) to control how long to keep retrying on -EBUSY responses. Between retries, the code waits briefly (50-100 microseconds) to avoid busy-waiting and handling TPM BUSY conditions more gracefully. The parameter can be modified at run-time as such: echo 3000 | tee /sys/module/tpm_crb_ffa/parameters/busy_timeout_ms This changes the timeout from the default 2000ms to 3000ms. [1] TPM Service Command Response Buffer Interface Over FF-A https://developer.arm.com/documentation/den0138/latest/ Signed-off-by: Prachotan Bathi <prachotan.bathi@arm.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-07-23tpm_crb_ffa: Remove memset usagePrachotan Bathi
Simplify initialization of `ffa_send_direct_data2` and `ffa_send_direct_data` structures by using designated initializers instead of `memset()` followed by field assignments, reducing code size and improving readability. Signed-off-by: Prachotan Bathi <prachotan.bathi@arm.com> Suggested-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-07-23tpm_crb_ffa: Fix typos in function namePrachotan Bathi
Rename *recieve as __tpm_crb_ffa_send_receive [jarkko: polished commit message] Signed-off-by: Prachotan Bathi <prachotan.bathi@arm.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-07-23tpm: Check for completion after timeoutJarkko Sakkinen
The current implementation of timeout detection works in the following way: 1. Read completion status. If completed, return the data 2. Sleep for some time (usleep_range) 3. Check for timeout using current jiffies value. Return an error if timed out 4. Goto 1 usleep_range doesn't guarantee it's always going to wake up strictly in (min, max) range, so such a situation is possible: 1. Driver reads completion status. No completion yet 2. Process sleeps indefinitely. In the meantime, TPM responds 3. We check for timeout without checking for the completion again. Result is lost. Such a situation also happens for the guest VMs: if vCPU goes to sleep and doesn't get scheduled for some time, the guest TPM driver will timeout instantly after waking up without checking for the completion (which may already be in place). Perform the completion check once again after exiting the busy loop in order to give the device the last chance to send us some data. Since now we check for completion in two places, extract this check into a separate function. Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com> Reviewed-by: Jonathan McDowell <noodles@meta.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-07-23tpm: Use of_reserved_mem_region_to_resource() for "memory-region"Rob Herring
Use the newly added of_reserved_mem_region_to_resource() function to handle "memory-region" properties. Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-07-23tpm: Replace scnprintf() with sysfs_emit() and sysfs_emit_at() in sysfs show ↵Chelsy Ratnawat
functions Documentation/filesystems/sysfs.rst mentions that show() should only use sysfs_emit() or sysfs_emit_at() when formating the value to be returned to user space. So replace scnprintf() with sysfs_emit(). Signed-off-by: Chelsy Ratnawat <chelsyratnawat2001@gmail.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-07-23tpm_crb_ffa: Remove unused exportJarkko Sakkinen
Remove the export of tpm_crb_ffa_get_interface_version() as it has no callers outside tpm_crb_ffa. Fixes: eb93f0734ef1 ("tpm_crb: ffa_tpm: Implement driver compliant to CRB over FF-A") Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@opinsys.com> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-07-23tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's built-inYeoreum Yun
To generate the boot_aggregate log in the IMA subsystem using TPM PCR values, the TPM driver must be built as built-in and must be probed before the IMA subsystem is initialized. However, when the TPM device operates over the FF-A protocol using the CRB interface, probing fails and returns -EPROBE_DEFER if the tpm_crb_ffa device — an FF-A device that provides the communication interface to the tpm_crb driver — has not yet been probed. This issue occurs because both crb_acpi_driver_init() and tpm_crb_ffa_driver_init() are registered with device_initcall. As a result, crb_acpi_driver_init() may be invoked before tpm_crb_ffa_driver_init(), which is responsible for probing the tpm_crb_ffa device. When this happens, IMA fails to detect the TPM device and logs the following message: | ima: No TPM chip found, activating TPM-bypass! Consequently, it cannot generate the boot_aggregate log with the PCR values provided by the TPM. To resolve this issue, the tpm_crb_ffa_init() function explicitly attempts to probe the tpm_crb_ffa by register tpm_crb_ffa driver so that when tpm_crb_ffa device is created before tpm_crb_ffa_init(), probe the tpm_crb_ffa device in tpm_crb_ffa_init() to finish probe the TPM device completely. This ensures that the TPM device using CRB over FF-A can be successfully probed, even if crb_acpi_driver_init() is called first. [ jarkko: reformatted some of the paragraphs because they were going past the 75 character boundary. ] Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-07-23firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcallYeoreum Yun
The Linux IMA (Integrity Measurement Architecture) subsystem used for secure boot, file integrity, or remote attestation cannot be a loadable module for few reasons listed below: o Boot-Time Integrity: IMA’s main role is to measure and appraise files before they are used. This includes measuring critical system files during early boot (e.g., init, init scripts, login binaries). If IMA were a module, it would be loaded too late to cover those. o TPM Dependency: IMA integrates tightly with the TPM to record measurements into PCRs. The TPM must be initialized early (ideally before init_ima()), which aligns with IMA being built-in. o Security Model: IMA is part of a Trusted Computing Base (TCB). Making it a module would weaken the security model, as a potentially compromised system could delay or tamper with its initialization. IMA must be built-in to ensure it starts measuring from the earliest possible point in boot which inturn implies TPM must be initialised and ready to use before IMA. To enable integration of tpm_event_log with the IMA subsystem, the TPM drivers (tpm_crb and tpm_crb_ffa) also needs to be built-in. However with FF-A driver also being initialised at device initcall level, it can lead to an initialization order issue where: - crb_acpi_driver_init() may run before tpm_crb_ffa_driver()_init and ffa_init() - As a result, probing the TPM device via CRB over FFA is deferred - ima_init() (called as a late initcall) runs before deferred probe completes, IMA fails to find the TPM and logs the below error: | ima: No TPM chip found, activating TPM-bypass! Eventually it fails to generate boot_aggregate with PCR values. Because of the above stated dependency, the ffa driver needs to initialised before tpm_crb_ffa module to ensure IMA finds the TPM successfully when present. [ jarkko: reformatted some of the paragraphs because they were going past the 75 character boundary. ] Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-07-23tpm/tpm_svsm: support TPM_CHIP_FLAG_SYNCStefano Garzarella
This driver does not support interrupts, and receiving the response is synchronous with sending the command. Enable synchronous send() with TPM_CHIP_FLAG_SYNC, which implies that ->send() already fills the provided buffer with a response, and ->recv() is not implemented. Keep using the same pre-allocated buffer to avoid having to allocate it for each command. We need the buffer to have the header required by the SVSM protocol and the command contiguous in memory. Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-07-23tpm/tpm_ftpm_tee: support TPM_CHIP_FLAG_SYNCStefano Garzarella
This driver does not support interrupts, and receiving the response is synchronous with sending the command. Enable synchronous send() with TPM_CHIP_FLAG_SYNC, which implies that ->send() already fills the provided buffer with a response, and ->recv() is not implemented. Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-07-23tpm: support devices with synchronous send()Stefano Garzarella
Some devices do not support interrupts and provide a single synchronous operation to send the command and receive the response on the same buffer. Currently, these types of drivers must use an internal buffer where they temporarily store the response between .send() and .recv() calls. Introduce a new flag (TPM_CHIP_FLAG_SYNC) to support synchronous send(). If that flag is set by the driver, tpm_try_transmit() will use the send() callback to send the command and receive the response on the same buffer synchronously. In that case send() return the number of bytes of the response on success, or -errno on failure. Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Suggested-by: Jason Gunthorpe <jgg@ziepe.ca> Suggested-by: Jarkko Sakkinen <jarkko@kernel.org> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-07-23tpm: add bufsiz parameter in the .send callbackStefano Garzarella
Add a new `bufsiz` parameter to the `.send` callback in `tpm_class_ops`. This parameter will allow drivers to differentiate between the actual command length to send and the total buffer size. Currently `bufsiz` is not used, but it will be used to implement devices with synchronous send() to send the command and receive the response on the same buffer. Also rename the previous parameter `len` to `cmd_len` in the declaration to make it clear that it contains the length in bytes of the command stored in the buffer. The semantics don't change and it can be used as before by drivers. This is an optimization since the drivers could get it from the header, but let's avoid duplicating code. While we are here, resolve a checkpatch warning: WARNING: Unnecessary space before function pointer arguments #66: FILE: include/linux/tpm.h:90: + int (*send) (struct tpm_chip *chip, u8 *buf, size_t bufsiz, Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Suggested-by: Jarkko Sakkinen <jarkko@kernel.org> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-07-22PCI: Support Immediate Readiness on devices without PM capabilitiesSean Christopherson
Query support for Immediate Readiness irrespective of whether or not the device supports PM capabilities, as nothing in the PCIe spec suggests that Immediate Readiness is in any way dependent on PM functionality. Fixes: d6112f8def51 ("PCI: Add support for Immediate Readiness") Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: David Matlack <dmatlack@google.com> Cc: Vipin Sharma <vipinsh@google.com> Cc: Aaron Lewis <aaronlewis@google.com> Link: https://patch.msgid.link/20250722155926.352248-1-seanjc@google.com
2025-07-23rtc: s3c: Put 'const' just after 'static' keyword for dataKrzysztof Kozlowski
Convention is to define static data as 'static const ...', not 'static ... const' because of readability, even if the code is functionally equal. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250707092200.48862-2-krzysztof.kozlowski@linaro.org Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-07-23rtc: m41t80: remove HT feature for m41t65Alexander Shiyan
The M41T65 device does not support the "Halt Update Bit" (HT) feature as per its datasheet. This aligns the driver with the actual hardware capabilities. Signed-off-by: Alexander Shiyan <eagle.alexander923@gmail.com> Link: https://lore.kernel.org/r/20250704091144.45389-1-eagle.alexander923@gmail.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-07-22clk: thead: th1520-ap: Describe mux clocks with clk_muxYao Zi
Mux clocks are now described with a customized ccu_mux structure consisting of ccu_internal and ccu_common substructures, and registered later with devm_clk_hw_register_mux_parent_data_table(). As this helper always allocates a new clk_hw structure, it's extremely hard to use mux clocks as parents statically by clk_hw pointers, since CCF has no knowledge about the clk_hw structure embedded in ccu_mux. This scheme already causes issues for clock c910, which takes a mux clock, c910-i0, as a possible parent. With mainline U-Boot that reparents c910 to c910-i0 at boottime, c910 is considered as an orphan by CCF. This patch refactors handling of mux clocks, embeds a clk_mux structure in ccu_mux directly. Instead of calling devm_clk_hw_register_mux_*(), we could register mux clocks on our own without allocating any new clk_hw pointer, fixing c910 clock's issue. Fixes: ae81b69fd2b1 ("clk: thead: Add support for T-Head TH1520 AP_SUBSYS clocks") Signed-off-by: Yao Zi <ziyao@disroot.org> Signed-off-by: Drew Fustini <fustini@kernel.org>
2025-07-23arm64/bug: Add ARCH_WARN_ASM macro for BUG/WARN asm code sharing with RustFUJITA Tomonori
Add new ARCH_WARN_ASM macro for BUG/WARN assembly code sharing with Rust to avoid the duplication. No functional changes. Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Link: https://lore.kernel.org/r/20250502094537.231725-4-fujita.tomonori@gmail.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-07-23riscv/bug: Add ARCH_WARN_ASM macro for BUG/WARN asm code sharing with RustFUJITA Tomonori
Add new ARCH_WARN_ASM macro for BUG/WARN assembly code sharing with Rust to avoid the duplication. No functional changes. Acked-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Link: https://lore.kernel.org/r/20250502094537.231725-3-fujita.tomonori@gmail.com [ Remove ending newline in `ARCH_WARN_ASM` content to be closer to the original. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-07-22x86/bug: Add ARCH_WARN_ASM macro for BUG/WARN asm code sharing with RustFUJITA Tomonori
Add new ARCH_WARN_ASM macro for BUG/WARN assembly code sharing with Rust to avoid the duplication. No functional changes. Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Link: https://lore.kernel.org/r/20250502094537.231725-2-fujita.tomonori@gmail.com [ Fixed typo in macro parameter name. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-07-22selftests/kexec: fix test_kexec_jump buildMoon Hee Lee
The test_kexec_jump program builds correctly when invoked from the top-level selftests/Makefile, which explicitly sets the OUTPUT variable. However, building directly in tools/testing/selftests/kexec fails with: make: *** No rule to make target '/test_kexec_jump', needed by 'test_kexec_jump.sh'. Stop. This failure occurs because the Makefile rule relies on $(OUTPUT), which is undefined in direct builds. Fix this by listing test_kexec_jump in TEST_GEN_PROGS, the standard way to declare generated test binaries in the kselftest framework. This ensures the binary is built regardless of invocation context and properly removed by make clean. Link: https://lore.kernel.org/r/20250702171704.22559-2-moonhee.lee.ca@gmail.com Acked-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Moon Hee Lee <moonhee.lee.ca@gmail.com> Acked-by: Baoquan He <bhe@redhat.com> Acked-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2025-07-22Merge tag 'apple-soc-dt-6.17' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/sven/linux into soc/dt Apple SoC device tree changes for v6.17 - Added the bindings and nodes for Apple SoC GPU. The driver itself isn't ready for upstreaming yet due to rust dependencies but we're confident that the bindings are stable at this point. - Added a missing node for the touchbar framebuffer to Apple T2 device trees, which is the BMC for some x86 Macs - Fixed a W=1 warning by adding bit offsets to NVMEM node names. This required a change to the generic NVMEM cell binding which will be part of 6.17 through the NVMEM tree. Signed-off-by: Sven Peter <sven@kernel.org> * tag 'apple-soc-dt-6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/sven/linux: arm64: dts: apple: Add Apple SoC GPU dt-bindings: gpu: Add Apple SoC GPU arm64: dts: apple: t8012-j132: Include touchbar framebuffer node arm64: dts: apple: Add bit offset to PMIC NVMEM node names Link: https://lore.kernel.org/r/20250722163258.62424-2-sven@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-07-22Merge tag 'at91-dt-6.17' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into soc/dt Microchip AT91 device tree updates for v6.17 This update includes: - controllers enabled for SAMA7D65 SoC (crypto controllers, PWM, CAN) - controllers enabled for SAM9X7 SoC (LCD, LVDS) - cache configuration updates for SAMA5D2, SAMA5D3, SAMA5D4, SAMA7G5, SAMA7D65 - cleanups * tag 'at91-dt-6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux: (22 commits) ARM: dts: microchip: sama7g5: Add cache configuration for cpu node ARM: dts: microchip: sama7d65: Add cache configuration for cpu node ARM: dts: microchip: sama5d4: Update the cache configuration for CPU ARM: dts: microchip: sama5d3: Update the cache configuration for CPU ARM: dts: microchip: sama5d2: Update the cache configuration for CPU ARM: dts: microchip: sam9x7: Add LVDS controller ARM: dts: microchip: sama5d2_icp: rename spi-cs-setup-ns property to spi-cs-setup-delay-ns ARM: dts: microchip: sama5d27_wlsom1: rename spi-cs-setup-ns property to spi-cs-setup-delay-ns ARM: dts: microchip: sama5d27_som1: rename spi-cs-setup-ns property to spi-cs-setup-delay-ns ARM: dts: microchip: sam9x60ek: rename spi-cs-setup-ns property to spi-cs-setup-delay-ns ARM: dts: at91-sama5d27_wlsom1: Improve the Wifi compatible ARM: dts: microchip: gardena-smart-gateway: Fix power LED ARM: dts: microchip: sam9x7: Add clock name property ARM: dts: microchip: sama7d65: Add clock name property ARM: dts: microchip: sama7g5: Adjust clock xtal phandle ARM: dts: microchip: sam9x7: Add HLCD controller ARM: dts: microchip: sama7d65: Enable CAN bus ARM: dts: microchip: sama7d65: Clean up extra space ARM: dts: microchip: sama7d65: Add CAN bus support ARM: dts: microchip: sama7d65: Add PWM support ... Link: https://lore.kernel.org/r/20250721100904.568575-2-claudiu.beznea@tuxon.dev Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-07-22Merge tag 'thead-dt-for-v6.17' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux into soc/dt T-HEAD Devicetrees for v6.17 There are several additions for the T-Head TH1520 SoC: - Add PVT node for thermal sensor which works with the existing Moortec MR75203 driver. - Add "gpu-clkgen" reset property to the AON node which allows the power domain driver to detect the capability to power sequence the GPU. All of these patches have been tested in linux-next. Signed-off-by: Drew Fustini <fustini@kernel.org> * tag 'thead-dt-for-v6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux: riscv: dts: thead: Add PVT node riscv: dts: thead: th1520: Add GPU clkgen reset to AON node Link: https://lore.kernel.org/r/aHtnwthmTpfkIBMr@x1 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
generated by cgit (git 2.34.1) at 2025-09-22 06:42:12 +0000