Re: [PATCH] riscv: Fix text patching when icache flushes use IPIs

2024-02-06 Thread Björn Töpel
Alexandre Ghiti writes: > For now, we use stop_machine() to patch the text and when we use IPIs for > remote icache flushes, the system hangs since the irqs are disabled on all > cpus. > > So instead, make sure every cpu executes the stop_machine() patching > function which emits a local icache

[PATCH] tools/rtla: Replace setting prio with nice for SCHED_OTHER

2024-02-06 Thread limingming3
Since the sched_priority for SCHED_OTHER is always 0, it makes no sence to set it. Setting nice for SCHED_OTHER seems more meaningful. Signed-off-by: limingming3 --- tools/tracing/rtla/src/utils.c | 6 +++--- tools/tracing/rtla/src/utils.h | 2 ++ 2 files changed, 5 insertions(+), 3

Re: [PATCH] tracing: use ring_buffer_record_is_set_on() in tracer_tracing_is_on()

2024-02-06 Thread Sven Schnelle
Hi Steven, Steven Rostedt writes: > On Tue, 06 Feb 2024 09:48:16 +0100 > Sven Schnelle wrote: > >> I added some logging, and the test is not triggering this issue. So i >> assume the default of 128 cmdline entries is just to small. Sorry for >> the noise. Lets see whether we're still

Re: (subset) [PATCH v7 0/4] remoteproc: qcom: Introduce DSP support for SM8650

2024-02-06 Thread Bjorn Andersson
On Tue, 23 Jan 2024 09:51:01 +0100, Neil Armstrong wrote: > Add the bindings and driver changes for DSP support on the > SM8650 platform in order to enable the aDSP, cDSP and MPSS > subsystems to boot. > > Compared to SM8550, where SM8650 uses the same dual firmware files, > (dtb file and main

Re: (subset) [PATCH v2 0/3] Add MDSS_BCR reset (+some more) for MSM8953

2024-02-06 Thread Bjorn Andersson
On Thu, 25 Jan 2024 22:35:11 +0100, Luca Weiss wrote: > Add the MDSS_BCR reset that is found in the GCC of MSM8953 so we can > make sure the MDSS gets properly reset before Linux starts using it. > > Also add some others that have been found in the LK sources. > > Applied, thanks! [3/3]

Re: [PATCH RFC 0/2] Add GPU support to MSM8953 SoC

2024-02-06 Thread Bjorn Andersson
On Thu, 25 Jan 2024 22:56:24 +0100, Luca Weiss wrote: > Add the GPU IOMMU and GPU nodes to the msm8953 dtsi so GPU can work. > > First of all, functionally this series looks fine, tested on > sdm632-fairphone-fp3. > > Secondly and the reason this is marked RFC for now is basically just dt >

Re: [PATCH] arm64: dts: qcom: sm6350: Add tsens thermal zones

2024-02-06 Thread Bjorn Andersson
On Wed, 24 Jan 2024 16:31:43 +0100, Luca Weiss wrote: > Add the definitions for the various thermal zones found on the SM6350 > SoC. Hooking up GPU and CPU cooling can limit the clock speeds there to > reduce the temperature again to good levels. > > Most thermal zones only have one critical

Re: [PATCH] vhost-vdpa: fail enabling virtqueue in certain conditions

2024-02-06 Thread Jason Wang
On Tue, Feb 6, 2024 at 10:52 PM Stefano Garzarella wrote: > > If VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK is not negotiated, we expect > the driver to enable virtqueue before setting DRIVER_OK. If the driver > tries anyway, better to fail right away as soon as we get the ioctl. > Let's also update

Re: [PATCH net-next v5] virtio_net: Support RX hash XDP hint

2024-02-06 Thread Liang Chen
On Tue, Feb 6, 2024 at 6:44 PM Paolo Abeni wrote: > > On Sat, 2024-02-03 at 10:56 +0800, Liang Chen wrote: > > On Sat, Feb 3, 2024 at 12:20 AM Jesper Dangaard Brouer > > wrote: > > > On 02/02/2024 13.11, Liang Chen wrote: > [...] > > > > @@ -1033,6 +1039,16 @@ static void put_xdp_frags(struct

Re: Question about the ipi_raise filter usage and output

2024-02-06 Thread richard clark
On Wed, Feb 7, 2024 at 10:28 AM richard clark wrote: > > On Tue, Feb 6, 2024 at 5:39 PM Valentin Schneider wrote: > > > > You should have access to the generic fields which include the CPU from > > which the event happens. Any of "CPU", "cpu" or "common_cpu" would match > > this. > > > > So if

Re: Question about the ipi_raise filter usage and output

2024-02-06 Thread richard clark
On Tue, Feb 6, 2024 at 5:39 PM Valentin Schneider wrote: > > You should have access to the generic fields which include the CPU from > which the event happens. Any of "CPU", "cpu" or "common_cpu" would match > this. > > So if you're on a recent enough kernel (v6.6 or above AFAICT), you should >

Re: [PATCH v2 3/3] x86/kprobes: Boost more instructions from grp2/3/4/5

2024-02-06 Thread Google
On Sun, 4 Feb 2024 22:39:32 -0600 Jinghao Jia wrote: > On 2/4/24 06:09, Masami Hiramatsu (Google) wrote: > > On Sat, 3 Feb 2024 21:13:00 -0600 > > Jinghao Jia wrote: > > > >> With the instruction decoder, we are now able to decode and recognize > >> instructions with opcode extensions. There

Re: [PATCH 0/3] Fairphone 5 PMIC-GLINK support (USB-C, charger, fuel gauge)

2024-02-06 Thread Luca Weiss
t; > > Worst case we end up with sc7280 which has yet another slightly > > > > > > different UCSI / PMIC GLINK implementation, but the compatible > > > > > > string > > > > > > is already taken. > > > > > > I still

[PATCH] riscv: Fix text patching when icache flushes use IPIs

2024-02-06 Thread Alexandre Ghiti
For now, we use stop_machine() to patch the text and when we use IPIs for remote icache flushes, the system hangs since the irqs are disabled on all cpus. So instead, make sure every cpu executes the stop_machine() patching function which emits a local icache flush and then avoids the use of

Re: [PATCH 2/4] hwspinlock: omap: Use devm_pm_runtime_enable() helper

2024-02-06 Thread Andrew Davis
On 2/6/24 1:06 PM, Bjorn Andersson wrote: On Tue, Jan 23, 2024 at 10:04:03AM -0600, Andrew Davis wrote: This disables runtime PM on module exit, allowing us to simplify the probe exit path and remove callbacks. Do that here. As with the later patch, unless I'm misreading the code, you already

Re: [PATCH 2/4] hwspinlock: omap: Use devm_pm_runtime_enable() helper

2024-02-06 Thread Bjorn Andersson
On Tue, Jan 23, 2024 at 10:04:03AM -0600, Andrew Davis wrote: > This disables runtime PM on module exit, allowing us to simplify > the probe exit path and remove callbacks. Do that here. As with the later patch, unless I'm misreading the code, you already do disable runtime PM in

Re: [PATCH 3/4] hwspinlock: omap: Use devm_hwspin_lock_register() helper

2024-02-06 Thread Bjorn Andersson
On Tue, Jan 23, 2024 at 10:04:04AM -0600, Andrew Davis wrote: > This unregister the HW spinlock on module exit, allowing us to > remove the remove callback. Do this here. > I interpret this as stating that the driver currently doesn't unregister the spinlocks, but as far as I can see it does,

Re: [PATCH] remoteproc: zynqmp: fix lockstep mode memory region

2024-02-06 Thread Tanmay Shah
On 2/6/24 11:39 AM, Mathieu Poirier wrote: > On Wed, Jan 31, 2024 at 04:48:12PM -0800, Tanmay Shah wrote: > > In lockstep mode, r5 core0 uses TCM of R5 core1. Following is lockstep > > mode memory region as per hardware reference manual. > > > > | *TCM* | *R5 View* | *Linux

Re: [PATCH] remoteproc: zynqmp: fix lockstep mode memory region

2024-02-06 Thread Mathieu Poirier
On Wed, Jan 31, 2024 at 04:48:12PM -0800, Tanmay Shah wrote: > In lockstep mode, r5 core0 uses TCM of R5 core1. Following is lockstep > mode memory region as per hardware reference manual. > > | *TCM* | *R5 View* | *Linux view* | > | R5_0 ATCM (128 KB) | 0x_ |

Re: [PATCH] vhost-vdpa: fail enabling virtqueue in certain conditions

2024-02-06 Thread Eugenio Perez Martin
On Tue, Feb 6, 2024 at 3:52 PM Stefano Garzarella wrote: > > If VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK is not negotiated, we expect > the driver to enable virtqueue before setting DRIVER_OK. If the driver > tries anyway, better to fail right away as soon as we get the ioctl. > Let's also update

Re: Re: [PATCH] vhost-vdpa: fail enabling virtqueue in certain conditions

2024-02-06 Thread Stefano Garzarella
On Tue, Feb 06, 2024 at 10:56:50AM -0500, Michael S. Tsirkin wrote: better @subj: try late vq enable only if negotiated I rewrote it 3/4 times, and before sending it I was not happy with the result. Thank you, much better! I'll change it in v2. Stefano

Re: [PATCH] vhost-vdpa: fail enabling virtqueue in certain conditions

2024-02-06 Thread Michael S. Tsirkin
better @subj: try late vq enable only if negotiated On Tue, Feb 06, 2024 at 03:51:54PM +0100, Stefano Garzarella wrote: > If VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK is not negotiated, we expect > the driver to enable virtqueue before setting DRIVER_OK. If the driver > tries anyway, better to fail

Re: [PATCH 1/6] tools/rtla: Fix Makefile compiler options for clang

2024-02-06 Thread Nathan Chancellor
On Tue, Feb 06, 2024 at 12:05:29PM +0100, Daniel Bristot de Oliveira wrote: > The following errors are showing up when compiling rtla with clang: > > $ make HOSTCC=clang CC=clang LLVM_IAS=1 > [...] > > clang -O -g -DVERSION=\"6.8.0-rc1\" -flto=auto -ffat-lto-objects > -fexceptions

[PATCH v7 35/36] selftests/ftrace: Add a test case for repeating register/unregister fprobe

2024-02-06 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) This test case repeats define and undefine the fprobe dynamic event to ensure that the fprobe does not cause any issue with such operations. Signed-off-by: Masami Hiramatsu (Google) --- .../test.d/dynevent/add_remove_fprobe_repeat.tc| 19

[PATCH v7 20/36] function_graph: Improve push operation for several interrupts

2024-02-06 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Improve push and data reserve operation on the shadow stack for several sequencial interrupts. To push a ret_stack or data entry on the shadow stack, we need to prepare an index (offset) entry before updating the stack pointer (curr_ret_stack) so that unwinder

[PATCH v7 21/36] function_graph: Add selftest for passing local variables

2024-02-06 Thread Masami Hiramatsu (Google)
From: Steven Rostedt (VMware) Add boot up selftest that passes variables from a function entry to a function exit, and make sure that they do get passed around. Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Masami Hiramatsu (Google) --- Changes in v2: - Add reserved size test. -

[PATCH v7 36/36] Documentation: probes: Update fprobe on function-graph tracer

2024-02-06 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Update fprobe documentation for the new fprobe on function-graph tracer. This includes some bahvior changes and pt_regs to ftrace_regs interface change. Signed-off-by: Masami Hiramatsu (Google) --- Changes in v2: - Update @fregs parameter explanation. ---

[PATCH v7 34/36] selftests: ftrace: Remove obsolate maxactive syntax check

2024-02-06 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Since the fprobe event does not support maxactive anymore, stop testing the maxactive syntax error checking. Signed-off-by: Masami Hiramatsu (Google) --- .../ftrace/test.d/dynevent/fprobe_syntax_errors.tc |4 +--- 1 file changed, 1 insertion(+), 3

[PATCH v7 33/36] tracing/fprobe: Remove nr_maxactive from fprobe

2024-02-06 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Remove depercated fprobe::nr_maxactive. This involves fprobe events to rejects the maxactive number. Signed-off-by: Masami Hiramatsu (Google) --- Changes in v2: - Newly added. --- include/linux/fprobe.h |2 -- kernel/trace/trace_fprobe.c | 44

[PATCH v7 32/36] fprobe: Rewrite fprobe on function-graph tracer

2024-02-06 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Rewrite fprobe implementation on function-graph tracer. Major API changes are: - 'nr_maxactive' field is deprecated. - This depends on CONFIG_DYNAMIC_FTRACE_WITH_ARGS or !CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS, and CONFIG_HAVE_FUNCTION_GRAPH_FREGS. So

[PATCH v7 13/36] function_graph: Have the instances use their own ftrace_ops for filtering

2024-02-06 Thread Masami Hiramatsu (Google)
From: Steven Rostedt (VMware) Allow for instances to have their own ftrace_ops part of the fgraph_ops that makes the funtion_graph tracer filter on the set_ftrace_filter file of the instance and not the top instance. Note that this also requires to update ftrace_graph_func() to call new

[PATCH v7 31/36] bpf: Enable kprobe_multi feature if CONFIG_FPROBE is enabled

2024-02-06 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Enable kprobe_multi feature if CONFIG_FPROBE is enabled. The pt_regs is converted from ftrace_regs by ftrace_partial_regs(), thus some registers may always returns 0. But it should be enough for function entry (access arguments) and exit (access return value).

[PATCH v7 30/36] tracing/fprobe: Enable fprobe events with CONFIG_DYNAMIC_FTRACE_WITH_ARGS

2024-02-06 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Allow fprobe events to be enabled with CONFIG_DYNAMIC_FTRACE_WITH_ARGS. With this change, fprobe events mostly use ftrace_regs instead of pt_regs. Note that if the arch doesn't enable HAVE_PT_REGS_COMPAT_FTRACE_REGS, fprobe events will not be able to be used from

[PATCH v7 29/36] tracing: Add ftrace_fill_perf_regs() for perf event

2024-02-06 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Add ftrace_fill_perf_regs() which should be compatible with the perf_fetch_caller_regs(). In other words, the pt_regs returned from the ftrace_fill_perf_regs() must satisfy 'user_mode(regs) == false' and can be used for stack tracing. Signed-off-by: Masami

[PATCH v7 28/36] tracing: Add ftrace_partial_regs() for converting ftrace_regs to pt_regs

2024-02-06 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Add ftrace_partial_regs() which converts the ftrace_regs to pt_regs. If the architecture defines its own ftrace_regs, this copies partial registers to pt_regs and returns it. If not, ftrace_regs is the same as pt_regs and ftrace_partial_regs() will return

[PATCH v7 27/36] fprobe: Use ftrace_regs in fprobe exit handler

2024-02-06 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Change the fprobe exit handler to use ftrace_regs structure instead of pt_regs. This also introduce HAVE_PT_REGS_TO_FTRACE_REGS_CAST which means the ftrace_regs's memory layout is equal to the pt_regs so that those are able to cast. Fprobe introduces a new

[PATCH v7 26/36] fprobe: Use ftrace_regs in fprobe entry handler

2024-02-06 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) This allows fprobes to be available with CONFIG_DYNAMIC_FTRACE_WITH_ARGS instead of CONFIG_DYNAMIC_FTRACE_WITH_REGS, then we can enable fprobe on arm64. Signed-off-by: Masami Hiramatsu (Google) Acked-by: Florent Revest --- Changes in v6: - Keep using

[PATCH v7 25/36] arm64: ftrace: Enable HAVE_FUNCTION_GRAPH_FREGS

2024-02-06 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Enable CONFIG_HAVE_FUNCTION_GRAPH_FREGS on arm64. Note that this depends on HAVE_DYNAMIC_FTRACE_WITH_ARGS which is enabled if the compiler supports "-fpatchable-function-entry=2". If not, it continue to use ftrace_ret_regs. Signed-off-by: Masami Hiramatsu

[PATCH v7 24/36] x86/ftrace: Enable HAVE_FUNCTION_GRAPH_FREGS

2024-02-06 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Support HAVE_FUNCTION_GRAPH_FREGS on x86-64, which saves ftrace_regs on the stack in ftrace_graph return trampoline so that the callbacks can access registers via ftrace_regs APIs. Note that this only recovers 'rax' and 'rdx' registers because other registers are

[PATCH v7 23/36] function_graph: Add a new exit handler with parent_ip and ftrace_regs

2024-02-06 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Add a new return handler to fgraph_ops as 'retregfunc' which takes parent_ip and ftrace_regs instead of ftrace_graph_ret. This handler is available only if the arch support CONFIG_HAVE_FUNCTION_GRAPH_FREGS. Note that the 'retfunc' and 'reregfunc' are mutual

[PATCH v7 22/36] function_graph: Add a new entry handler with parent_ip and ftrace_regs

2024-02-06 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Add a new entry handler to fgraph_ops as 'entryregfunc' which takes parent_ip and ftrace_regs. Note that the 'entryfunc' and 'entryregfunc' are mutual exclusive. You can set only one of them. Signed-off-by: Masami Hiramatsu (Google) --- Changes in v3: -

[PATCH v7 19/36] function_graph: Implement fgraph_reserve_data() and fgraph_retrieve_data()

2024-02-06 Thread Masami Hiramatsu (Google)
From: Steven Rostedt (VMware) Added functions that can be called by a fgraph_ops entryfunc and retfunc to store state between the entry of the function being traced to the exit of the same function. The fgraph_ops entryfunc() may call fgraph_reserve_data() to store up to 32 words onto the task's

[PATCH v7 18/36] function_graph: Move graph notrace bit to shadow stack global var

2024-02-06 Thread Masami Hiramatsu (Google)
From: Steven Rostedt (VMware) The use of the task->trace_recursion for the logic used for the function graph no-trace was a bit of an abuse of that variable. Now that there exists global vars that are per stack for registered graph traces, use that instead. Signed-off-by: Steven Rostedt

[PATCH v7 17/36] function_graph: Move graph depth stored data to shadow stack global var

2024-02-06 Thread Masami Hiramatsu (Google)
From: Steven Rostedt (VMware) The use of the task->trace_recursion for the logic used for the function graph depth was a bit of an abuse of that variable. Now that there exists global vars that are per stack for registered graph traces, use that instead. Signed-off-by: Steven Rostedt (VMware)

[PATCH v7 16/36] function_graph: Move set_graph_function tests to shadow stack global var

2024-02-06 Thread Masami Hiramatsu (Google)
From: Steven Rostedt (VMware) The use of the task->trace_recursion for the logic used for the set_graph_funnction was a bit of an abuse of that variable. Now that there exists global vars that are per stack for registered graph traces, use that instead. Signed-off-by: Steven Rostedt (VMware)

[PATCH v7 15/36] function_graph: Add "task variables" per task for fgraph_ops

2024-02-06 Thread Masami Hiramatsu (Google)
From: Steven Rostedt (VMware) Add a "task variables" array on the tasks shadow ret_stack that is the size of longs for each possible registered fgraph_ops. That's a total of 16, taking up 8 * 16 = 128 bytes (out of a page size 4k). This will allow for fgraph_ops to do specific features on a per

[PATCH v7 14/36] function_graph: Use a simple LRU for fgraph_array index number

2024-02-06 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Since the fgraph_array index is used for the bitmap on the shadow stack, it may leave some entries after a function_graph instance is removed. Thus if another instance reuses the fgraph_array index soon after releasing it, the fgraph may confuse to call the newer

[PATCH v7 12/36] ftrace: Allow ftrace startup flags exist without dynamic ftrace

2024-02-06 Thread Masami Hiramatsu (Google)
From: Steven Rostedt (VMware) Some of the flags for ftrace_startup() may be exposed even when CONFIG_DYNAMIC_FTRACE is not configured in. This is fine as the difference between dynamic ftrace and static ftrace is done within the internals of ftrace itself. No need to have use cases fail to

[PATCH v7 10/36] ftrace/function_graph: Pass fgraph_ops to function graph callbacks

2024-02-06 Thread Masami Hiramatsu (Google)
From: Steven Rostedt (VMware) Pass the fgraph_ops structure to the function graph callbacks. This will allow callbacks to add a descriptor to a fgraph_ops private field that wil be added in the future and use it for the callbacks. This will be useful when more than one callback can be registered

[PATCH v7 11/36] ftrace: Allow function_graph tracer to be enabled in instances

2024-02-06 Thread Masami Hiramatsu (Google)
From: Steven Rostedt (VMware) Now that function graph tracing can handle more than one user, allow it to be enabled in the ftrace instances. Note, the filtering of the functions is still joined by the top level set_ftrace_filter and friends, as well as the graph and nograph files.

[PATCH v7 09/36] function_graph: Remove logic around ftrace_graph_entry and return

2024-02-06 Thread Masami Hiramatsu (Google)
From: Steven Rostedt (VMware) The function pointers ftrace_graph_entry and ftrace_graph_return are no longer called via the function_graph tracer. Instead, an array structure is now used that will allow for multiple users of the function_graph infrastructure. The variables are still used by the

[PATCH v7 08/36] function_graph: Allow multiple users to attach to function graph

2024-02-06 Thread Masami Hiramatsu (Google)
From: Steven Rostedt (VMware) Allow for multiple users to attach to function graph tracer at the same time. Only 16 simultaneous users can attach to the tracer. This is because there's an array that stores the pointers to the attached fgraph_ops. When a function being traced is entered, each of

[PATCH v7 07/36] function_graph: Add an array structure that will allow multiple callbacks

2024-02-06 Thread Masami Hiramatsu (Google)
From: Steven Rostedt (VMware) Add an array structure that will eventually allow the function graph tracer to have up to 16 simultaneous callbacks attached. It's an array of 16 fgraph_ops pointers, that is assigned when one is registered. On entry of a function the entry of the first item in the

[PATCH v7 06/36] fgraph: Use BUILD_BUG_ON() to make sure we have structures divisible by long

2024-02-06 Thread Masami Hiramatsu (Google)
From: Steven Rostedt (VMware) Instead of using "ALIGN()", use BUILD_BUG_ON() as the structures should always be divisible by sizeof(long). Link: http://lkml.kernel.org/r/2019052444.gi2...@hirez.programming.kicks-ass.net Suggested-by: Peter Zijlstra Signed-off-by: Steven Rostedt (VMware)

[PATCH v7 05/36] function_graph: Convert ret_stack to a series of longs

2024-02-06 Thread Masami Hiramatsu (Google)
From: Steven Rostedt (VMware) In order to make it possible to have multiple callbacks registered with the function_graph tracer, the retstack needs to be converted from an array of ftrace_ret_stack structures to an array of longs. This will allow to store the list of callbacks on the stack for

[PATCH v7 04/36] x86: tracing: Add ftrace_regs definition in the header

2024-02-06 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Add ftrace_regs definition for x86_64 in the ftrace header to clarify what register will be accessible from ftrace_regs. Signed-off-by: Masami Hiramatsu (Google) --- Changes in v3: - Add rip to be saved. Changes in v2: - Newly added. ---

[PATCH v7 03/36] tracing: Rename ftrace_regs_return_value to ftrace_regs_get_return_value

2024-02-06 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) Rename ftrace_regs_return_value to ftrace_regs_get_return_value as same as other ftrace_regs_get/set_* APIs. Signed-off-by: Masami Hiramatsu (Google) Acked-by: Mark Rutland --- Changes in v6: - Moved to top of the series. Changes in v3: - Newly added. ---

[PATCH v7 02/36] tracing: Add a comment about ftrace_regs definition

2024-02-06 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) To clarify what will be expected on ftrace_regs, add a comment to the architecture independent definition of the ftrace_regs. Signed-off-by: Masami Hiramatsu (Google) Acked-by: Mark Rutland --- Changes in v3: - Add instruction pointer Changes in v2: -

[PATCH v7 01/36] ftrace: Fix DIRECT_CALLS to use SAVE_REGS by default

2024-02-06 Thread Masami Hiramatsu (Google)
From: Masami Hiramatsu (Google) The commit 60c8971899f3 ("ftrace: Make DIRECT_CALLS work WITH_ARGS and !WITH_REGS") changed DIRECT_CALLS to use SAVE_ARGS when there are multiple ftrace_ops at the same function, but since the x86 only support to jump to direct_call from ftrace_regs_caller, when

[PATCH v7 00/36] tracing: fprobe: function_graph: Multi-function graph and fprobe on fgraph

2024-02-06 Thread Masami Hiramatsu (Google)
Hi, Here is the 7th version of the series to re-implement the fprobe on function-graph tracer. The previous version is; https://lore.kernel.org/all/170505424954.459169.10630626365737237288.stgit@devnote2/ This version fixes max-limitation check[8/36] and interrupt while commiting pop operation

[PATCH] vhost-vdpa: fail enabling virtqueue in certain conditions

2024-02-06 Thread Stefano Garzarella
If VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK is not negotiated, we expect the driver to enable virtqueue before setting DRIVER_OK. If the driver tries anyway, better to fail right away as soon as we get the ioctl. Let's also update the documentation to make it clearer. We had a problem in QEMU for

Re: [PATCH v11] bus: mhi: host: Add tracing support

2024-02-06 Thread Naman Jain
On 2/6/2024 10:02 AM, Krishna chaitanya chundru wrote: This change adds ftrace support for following functions which helps in debugging the issues when there is Channel state & MHI state change and also when we receive data and control events: Please write commit msg in imperative mood.

Re: [PATCH net-next v3] net: dqs: add NIC stall detector based on BQL

2024-02-06 Thread Paolo Abeni
On Fri, 2024-02-02 at 08:53 -0800, Breno Leitao wrote: > From: Jakub Kicinski > > softnet_data->time_squeeze is sometimes used as a proxy for > host overload or indication of scheduling problems. In practice > this statistic is very noisy and has hard to grasp units - > e.g. is 10 squeezes a

[PATCH 6/6] tools/rv: Fix curr_reactor uninitialized variable

2024-02-06 Thread Daniel Bristot de Oliveira
clang is reporting: $ make HOSTCC=clang CC=clang LLVM_IAS=1 clang -O -g -DVERSION=\"6.8.0-rc3\" -flto=auto -fexceptions -fstack-protector-strong -fasynchronous-unwind-tables -fstack-clash-protection -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2

[PATCH 5/6] tools/rv: Fix Makefile compiler options for clang

2024-02-06 Thread Daniel Bristot de Oliveira
The following errors are showing up when compiling rv with clang: $ make HOSTCC=clang CC=clang LLVM_IAS=1 [...] clang -O -g -DVERSION=\"6.8.0-rc1\" -flto=auto -ffat-lto-objects -fexceptions -fstack-protector-strong -fasynchronous-unwind-tables -fstack-clash-protection -Wall

[PATCH 4/6] tools/rtla: Remove unused sched_getattr() function

2024-02-06 Thread Daniel Bristot de Oliveira
Clang is reporting: $ make HOSTCC=clang CC=clang LLVM_IAS=1 [...] clang -O -g -DVERSION=\"6.8.0-rc3\" -flto=auto -fexceptions -fstack-protector-strong -fasynchronous-unwind-tables -fstack-clash-protection -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS

[PATCH 3/6] tools/rtla: Fix clang warning about mount_point var size

2024-02-06 Thread Daniel Bristot de Oliveira
clang is reporting this warning: $ make HOSTCC=clang CC=clang LLVM_IAS=1 [...] clang -O -g -DVERSION=\"6.8.0-rc3\" -flto=auto -fexceptions -fstack-protector-strong -fasynchronous-unwind-tables -fstack-clash-protection -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2

[PATCH 2/6] tools/rtla: Fix uninitialized bucket/data->bucket_size warning

2024-02-06 Thread Daniel Bristot de Oliveira
When compiling rtla with clang, I am getting the following warnings: $ make HOSTCC=clang CC=clang LLVM_IAS=1 [..] clang -O -g -DVERSION=\"6.8.0-rc3\" -flto=auto -fexceptions -fstack-protector-strong -fasynchronous-unwind-tables -fstack-clash-protection -Wall

[PATCH 1/6] tools/rtla: Fix Makefile compiler options for clang

2024-02-06 Thread Daniel Bristot de Oliveira
The following errors are showing up when compiling rtla with clang: $ make HOSTCC=clang CC=clang LLVM_IAS=1 [...] clang -O -g -DVERSION=\"6.8.0-rc1\" -flto=auto -ffat-lto-objects -fexceptions -fstack-protector-strong -fasynchronous-unwind-tables -fstack-clash-protection

[PATCH 0/6] tools: Fix rtla and rv problems (found) with clang

2024-02-06 Thread Daniel Bristot de Oliveira
RHEL people reported some errors when compiling rtla and rv with clang. The command line used to compile the tools is: $ make HOSTCC=clang CC=clang LLVM_IAS=1 The first problem is two unsupported flags passed to the compiler: -ffat-lto-objects and -Wno-maybe-uninitialized. They will be removed

Re: [PATCH] tracing: use ring_buffer_record_is_set_on() in tracer_tracing_is_on()

2024-02-06 Thread Steven Rostedt
On Tue, 06 Feb 2024 09:48:16 +0100 Sven Schnelle wrote: > I added some logging, and the test is not triggering this issue. So i > assume the default of 128 cmdline entries is just to small. Sorry for > the noise. Lets see whether we're still triggering some failures with > the other fix applied

Re: [PATCH v14 4/6] tracing: Allow user-space mapping of the ring-buffer

2024-02-06 Thread kernel test robot
Hi Vincent, kernel test robot noticed the following build warnings: [auto build test WARNING on e2412e51fdea837b50ce31fea8e5dfc885237f3a] url: https://github.com/intel-lab-lkp/linux/commits/Vincent-Donnefort/ring-buffer-Zero-ring-buffer-sub-buffers/20240206-004413 base

Re: [PATCH net-next v5] virtio_net: Support RX hash XDP hint

2024-02-06 Thread Paolo Abeni
On Sat, 2024-02-03 at 10:56 +0800, Liang Chen wrote: > On Sat, Feb 3, 2024 at 12:20 AM Jesper Dangaard Brouer > wrote: > > On 02/02/2024 13.11, Liang Chen wrote: [...] > > > @@ -1033,6 +1039,16 @@ static void put_xdp_frags(struct xdp_buff *xdp) > > > } > > > } > > > > > > +static void

Re: Question about the ipi_raise filter usage and output

2024-02-06 Thread Valentin Schneider
On 06/02/24 16:42, richard clark wrote: > On Tue, Feb 6, 2024 at 12:05 AM Valentin Schneider > wrote: >> >> The CPUS{} thingie only works with an event field that is either declared as >> a >> cpumask (__cpumask) or a scalar. That's not the case for ipi_raise, the >> target_cpus event field is

Re: [PATCH v11] bus: mhi: host: Add tracing support

2024-02-06 Thread Manivannan Sadhasivam
__field(__le32, dword1) > + __field(int, state) > + __field(__le64, ptr) > + __field(void *, rp) > + ), > + > + TP_fast_assign( > + __assign_str(name, mhi_cntrl->mhi_dev->name); > + __entry->rp = rp; > + __entry->ptr = rp->ptr; > + __entry->dword0 = rp->dword[0]; > + __entry->dword1 = rp->dword[1]; > + __entry->state = MHI_TRE_GET_EV_STATE(rp); > + ), > + > + TP_printk("%s: TRE: 0x%p TRE buf: 0x%llx DWORD0: 0x%08x DWORD1: 0x%08x > State: %s\n", > + __get_str(name), __entry->rp, __entry->ptr, __entry->dword0, > + __entry->dword1, __print_symbolic(__entry->state, > MHI_STATE_LIST)) > +); > + > +DEFINE_EVENT(mhi_process_event_ring, mhi_data_event, > + > + TP_PROTO(struct mhi_controller *mhi_cntrl, struct mhi_ring_element *rp), > + > + TP_ARGS(mhi_cntrl, rp) > +); > + > +DEFINE_EVENT(mhi_process_event_ring, mhi_ctrl_event, > + > + TP_PROTO(struct mhi_controller *mhi_cntrl, struct mhi_ring_element *rp), > + > + TP_ARGS(mhi_cntrl, rp) > +); > + > +DECLARE_EVENT_CLASS(mhi_update_channel_state, > + > + TP_PROTO(struct mhi_controller *mhi_cntrl, struct mhi_chan *mhi_chan, > int state, > + const char *reason), > + > + TP_ARGS(mhi_cntrl, mhi_chan, state, reason), > + > + TP_STRUCT__entry( > + __string(name, mhi_cntrl->mhi_dev->name) > + __field(int, ch_num) > + __field(int, state) > + __field(const char *, reason) > + ), > + > + TP_fast_assign( > + __assign_str(name, mhi_cntrl->mhi_dev->name); > + __entry->ch_num = mhi_chan->chan; > + __entry->state = state; > + __entry->reason = reason; > + ), > + > + TP_printk("%s: chan%d: %s state to: %s\n", > + __get_str(name), __entry->ch_num, __entry->reason, > + __print_symbolic(__entry->state, MHI_CH_STATE_TYPE_LIST)) > +); > + > +DEFINE_EVENT(mhi_update_channel_state, mhi_channel_command_start, > + > + TP_PROTO(struct mhi_controller *mhi_cntrl, struct mhi_chan *mhi_chan, > int state, > + const char *reason), > + > + TP_ARGS(mhi_cntrl, mhi_chan, state, reason) > +); > + > +DEFINE_EVENT(mhi_update_channel_state, mhi_channel_command_end, > + > + TP_PROTO(struct mhi_controller *mhi_cntrl, struct mhi_chan *mhi_chan, > int state, > + const char *reason), > + > + TP_ARGS(mhi_cntrl, mhi_chan, state, reason) > +); > + > +TRACE_EVENT(mhi_pm_st_transition, > + > + TP_PROTO(struct mhi_controller *mhi_cntrl, int state), > + > + TP_ARGS(mhi_cntrl, state), > + > + TP_STRUCT__entry( > + __string(name, mhi_cntrl->mhi_dev->name) > + __field(int, state) > + ), > + > + TP_fast_assign( > + __assign_str(name, mhi_cntrl->mhi_dev->name); > + __entry->state = state; > + ), > + > + TP_printk("%s: Handling state transition: %s\n", __get_str(name), > + __print_symbolic(__entry->state, DEV_ST_TRANSITION_LIST)) > +); > + > +#endif > +#undef TRACE_INCLUDE_PATH > +#define TRACE_INCLUDE_PATH ../../drivers/bus/mhi/host > +#undef TRACE_INCLUDE_FILE > +#define TRACE_INCLUDE_FILE trace > + > +#include > > --- > base-commit: ae1d892d518af5c092f2b1f8e6921996c6a95cb3 > change-id: 20240206-ftrace_support-8ef0fbecf85e > > Best regards, > -- > Krishna chaitanya chundru > -- மணிவண்ணன் சதாசிவம்

Re: [PATCH v11] bus: mhi: host: Add tracing support

2024-02-06 Thread Manivannan Sadhasivam
ntrl, mhi_chan, mhi_tre), > > > > + > > > > + TP_STRUCT__entry( > > > > + __string(name, mhi_cntrl->mhi_dev->name) > > > > + __field(int, ch_num) > > > > + __field(void *, wp) > > > > + __field(__le64, tre_ptr) > > > > + __field(__le32, dword0) > > > > + __field(__le32, dword1) > > > > + ), > > > > + > > > > + TP_fast_assign( > > > > + __assign_str(name, mhi_cntrl->mhi_dev->name); > > > > + __entry->ch_num = mhi_chan->chan; > > > > + __entry->wp = mhi_tre; > > > > + __entry->tre_ptr = mhi_tre->ptr; > > > > + __entry->dword0 = mhi_tre->dword[0]; > > > > + __entry->dword1 = mhi_tre->dword[1]; > > > > + ), > > > > + > > > > + TP_printk("%s: Chan: %d TRE: 0x%p TRE buf: 0x%llx DWORD0: > > > > 0x%08x DWORD1: 0x%08x\n", > > > > + __get_str(name), __entry->ch_num, __entry->wp, > > > > __entry->tre_ptr, > > > > + __entry->dword0, __entry->dword1) > > > > +); > > > > + > > > > +TRACE_EVENT(mhi_intvec_states, > > > > + > > > > + TP_PROTO(struct mhi_controller *mhi_cntrl, int dev_ee, int > > > > dev_state), > > > > + > > > > + TP_ARGS(mhi_cntrl, dev_ee, dev_state), > > > > + > > > > + TP_STRUCT__entry( > > > > + __string(name, mhi_cntrl->mhi_dev->name) > > > > + __field(int, local_ee) > > > > + __field(int, state) > > > > + __field(int, dev_ee) > > > > + __field(int, dev_state) > > > > + ), > > > > + > > > > + TP_fast_assign( > > > > + __assign_str(name, mhi_cntrl->mhi_dev->name); > > > > + __entry->local_ee = mhi_cntrl->ee; > > > > + __entry->state = mhi_cntrl->dev_state; > > > > + __entry->dev_ee = dev_ee; > > > > + __entry->dev_state = dev_state; > > > > + ), > > > > + > > > > + TP_printk("%s: Local EE: %s State: %s Device EE: %s Dev State: > > > > %s\n", > > > > + __get_str(name), > > > > + __print_symbolic(__entry->local_ee, MHI_EE_LIST), > > > > + __print_symbolic(__entry->state, MHI_STATE_LIST), > > > > + __print_symbolic(__entry->dev_ee, MHI_EE_LIST), > > > > + __print_symbolic(__entry->dev_state, MHI_STATE_LIST)) > > > > +); > > > > + > > > > +TRACE_EVENT(mhi_tryset_pm_state, > > > > + > > > > + TP_PROTO(struct mhi_controller *mhi_cntrl, int pm_state), > > > > + > > > > + TP_ARGS(mhi_cntrl, pm_state), > > > > + > > > > + TP_STRUCT__entry( > > > > + __string(name, mhi_cntrl->mhi_dev->name) > > > > + __field(int, pm_state) > > > > + ), > > > > + > > > > + TP_fast_assign( > > > > + __assign_str(name, mhi_cntrl->mhi_dev->name); > > > > + if (pm_state) > > > > + pm_state = __fls(pm_state); > > > > + __entry->pm_state = pm_state; > > > > + ), > > > > + > > > > + TP_printk("%s: PM state: %s\n", __get_str(name), > > > > + __print_symbolic(__entry->pm_state, > > > > MHI_PM_STATE_LIST)) > > > > +); > > > > + > > > > +DECLARE_EVENT_CLASS(mhi_process_event_ring, > > > > + > > > > + TP_PROTO(struct mhi_controller *mhi_cntrl, struct > > > > mhi_ring_element *rp), > > > > + > > > > + TP_ARGS(mhi_cntrl, rp), > > > > + > > > > + TP_STRUCT__entry( > > > > + __string(name, mhi_cntrl->mhi_dev->name) > > > > + __field(__le32, dword0) > > > > + __field(__le32, dword1) > > > > + __field(int, state) > > > > + __field(__le64, ptr) > > > > + __field(void *, rp) > > > > + ), > > > > + > > > > + TP_fast_assign( > > > > + __assign_str(name, mhi_cntrl->mhi_dev->name); > > > > + __entry->rp = rp; > > > > + __entry->ptr = rp->ptr; > > > > + __entry->dword0 = rp->dword[0]; > > > > + __entry->dword1 = rp->dword[1]; > > > > + __entry->state = MHI_TRE_GET_EV_STATE(rp); > > > > + ), > > > > + > > > > + TP_printk("%s: TRE: 0x%p TRE buf: 0x%llx DWORD0: 0x%08x DWORD1: > > > > 0x%08x State: %s\n", > > > > + __get_str(name), __entry->rp, __entry->ptr, > > > > __entry->dword0, > > > > + __entry->dword1, __print_symbolic(__entry->state, > > > > MHI_STATE_LIST)) > > > > +); > > > > + > > > > +DEFINE_EVENT(mhi_process_event_ring, mhi_data_event, > > > > + > > > > + TP_PROTO(struct mhi_controller *mhi_cntrl, struct > > > > mhi_ring_element *rp), > > > > + > > > > + TP_ARGS(mhi_cntrl, rp) > > > > +); > > > > + > > > > +DEFINE_EVENT(mhi_process_event_ring, mhi_ctrl_event, > > > > + > > > > + TP_PROTO(struct mhi_controller *mhi_cntrl, struct > > > > mhi_ring_element *rp), > > > > + > > > > + TP_ARGS(mhi_cntrl, rp) > > > > +); > > > > + > > > > +DECLARE_EVENT_CLASS(mhi_update_channel_state, > > > > + > > > > + TP_PROTO(struct mhi_controller *mhi_cntrl, struct mhi_chan > > > > *mhi_chan, int state, > > > > +const char *reason), > > > > + > > > > + TP_ARGS(mhi_cntrl, mhi_chan, state, reason), > > > > + > > > > + TP_STRUCT__entry( > > > > + __string(name, mhi_cntrl->mhi_dev->name) > > > > + __field(int, ch_num) > > > > + __field(int, state) > > > > + __field(const char *, reason) > > > > + ), > > > > + > > > > + TP_fast_assign( > > > > + __assign_str(name, mhi_cntrl->mhi_dev->name); > > > > + __entry->ch_num = mhi_chan->chan; > > > > + __entry->state = state; > > > > + __entry->reason = reason; > > > > + ), > > > > + > > > > + TP_printk("%s: chan%d: %s state to: %s\n", > > > > + __get_str(name), __entry->ch_num, __entry->reason, > > > > + __print_symbolic(__entry->state, > > > > MHI_CH_STATE_TYPE_LIST)) > > > > +); > > > > + > > > > +DEFINE_EVENT(mhi_update_channel_state, mhi_channel_command_start, > > > > + > > > > + TP_PROTO(struct mhi_controller *mhi_cntrl, struct mhi_chan > > > > *mhi_chan, int state, > > > > +const char *reason), > > > > + > > > > + TP_ARGS(mhi_cntrl, mhi_chan, state, reason) > > > > +); > > > > + > > > > +DEFINE_EVENT(mhi_update_channel_state, mhi_channel_command_end, > > > > + > > > > + TP_PROTO(struct mhi_controller *mhi_cntrl, struct mhi_chan > > > > *mhi_chan, int state, > > > > +const char *reason), > > > > + > > > > + TP_ARGS(mhi_cntrl, mhi_chan, state, reason) > > > > +); > > > > + > > > > +TRACE_EVENT(mhi_pm_st_transition, > > > > + > > > > + TP_PROTO(struct mhi_controller *mhi_cntrl, int state), > > > > + > > > > + TP_ARGS(mhi_cntrl, state), > > > > + > > > > + TP_STRUCT__entry( > > > > + __string(name, mhi_cntrl->mhi_dev->name) > > > > + __field(int, state) > > > > + ), > > > > + > > > > + TP_fast_assign( > > > > + __assign_str(name, mhi_cntrl->mhi_dev->name); > > > > + __entry->state = state; > > > > + ), > > > > + > > > > + TP_printk("%s: Handling state transition: %s\n", > > > > __get_str(name), > > > > + __print_symbolic(__entry->state, > > > > DEV_ST_TRANSITION_LIST)) > > > > +); > > > > + > > > > +#endif > > > > +#undef TRACE_INCLUDE_PATH > > > > +#define TRACE_INCLUDE_PATH ../../drivers/bus/mhi/host > > > > +#undef TRACE_INCLUDE_FILE > > > > +#define TRACE_INCLUDE_FILE trace > > > > + > > > > +#include > > > > > > > > --- > > > > base-commit: ae1d892d518af5c092f2b1f8e6921996c6a95cb3 > > > > change-id: 20240206-ftrace_support-8ef0fbecf85e > > > > > > > > Best regards, > > > > -- > > > > Krishna chaitanya chundru > > > > > > > > > -- > மணிவண்ணன் சதாசிவம் > -- மணிவண்ணன் சதாசிவம்

Re: [PATCH v11] bus: mhi: host: Add tracing support

2024-02-06 Thread Manivannan Sadhasivam
_chan->chan; > > > + __entry->wp = mhi_tre; > > > + __entry->tre_ptr = mhi_tre->ptr; > > > + __entry->dword0 = mhi_tre->dword[0]; > > > + __entry->dword1 = mhi_tre->dword[1]; > > > + ), > > > + > > > + TP_printk("%s: Chan: %d TRE: 0x%p TRE buf: 0x%llx DWORD0: 0x%08x > > > DWORD1: 0x%08x\n", > > > + __get_str(name), __entry->ch_num, __entry->wp, > > > __entry->tre_ptr, > > > + __entry->dword0, __entry->dword1) > > > +); > > > + > > > +TRACE_EVENT(mhi_intvec_states, > > > + > > > + TP_PROTO(struct mhi_controller *mhi_cntrl, int dev_ee, int dev_state), > > > + > > > + TP_ARGS(mhi_cntrl, dev_ee, dev_state), > > > + > > > + TP_STRUCT__entry( > > > + __string(name, mhi_cntrl->mhi_dev->name) > > > + __field(int, local_ee) > > > + __field(int, state) > > > + __field(int, dev_ee) > > > + __field(int, dev_state) > > > + ), > > > + > > > + TP_fast_assign( > > > + __assign_str(name, mhi_cntrl->mhi_dev->name); > > > + __entry->local_ee = mhi_cntrl->ee; > > > + __entry->state = mhi_cntrl->dev_state; > > > + __entry->dev_ee = dev_ee; > > > + __entry->dev_state = dev_state; > > > + ), > > > + > > > + TP_printk("%s: Local EE: %s State: %s Device EE: %s Dev State: %s\n", > > > + __get_str(name), > > > + __print_symbolic(__entry->local_ee, MHI_EE_LIST), > > > + __print_symbolic(__entry->state, MHI_STATE_LIST), > > > + __print_symbolic(__entry->dev_ee, MHI_EE_LIST), > > > + __print_symbolic(__entry->dev_state, MHI_STATE_LIST)) > > > +); > > > + > > > +TRACE_EVENT(mhi_tryset_pm_state, > > > + > > > + TP_PROTO(struct mhi_controller *mhi_cntrl, int pm_state), > > > + > > > + TP_ARGS(mhi_cntrl, pm_state), > > > + > > > + TP_STRUCT__entry( > > > + __string(name, mhi_cntrl->mhi_dev->name) > > > + __field(int, pm_state) > > > + ), > > > + > > > + TP_fast_assign( > > > + __assign_str(name, mhi_cntrl->mhi_dev->name); > > > + if (pm_state) > > > + pm_state = __fls(pm_state); > > > + __entry->pm_state = pm_state; > > > + ), > > > + > > > + TP_printk("%s: PM state: %s\n", __get_str(name), > > > + __print_symbolic(__entry->pm_state, MHI_PM_STATE_LIST)) > > > +); > > > + > > > +DECLARE_EVENT_CLASS(mhi_process_event_ring, > > > + > > > + TP_PROTO(struct mhi_controller *mhi_cntrl, struct mhi_ring_element *rp), > > > + > > > + TP_ARGS(mhi_cntrl, rp), > > > + > > > + TP_STRUCT__entry( > > > + __string(name, mhi_cntrl->mhi_dev->name) > > > + __field(__le32, dword0) > > > + __field(__le32, dword1) > > > + __field(int, state) > > > + __field(__le64, ptr) > > > + __field(void *, rp) > > > + ), > > > + > > > + TP_fast_assign( > > > + __assign_str(name, mhi_cntrl->mhi_dev->name); > > > + __entry->rp = rp; > > > + __entry->ptr = rp->ptr; > > > + __entry->dword0 = rp->dword[0]; > > > + __entry->dword1 = rp->dword[1]; > > > + __entry->state = MHI_TRE_GET_EV_STATE(rp); > > > + ), > > > + > > > + TP_printk("%s: TRE: 0x%p TRE buf: 0x%llx DWORD0: 0x%08x DWORD1: 0x%08x > > > State: %s\n", > > > + __get_str(name), __entry->rp, __entry->ptr, __entry->dword0, > > > + __entry->dword1, __print_symbolic(__entry->state, > > > MHI_STATE_LIST)) > > > +); > > > + > > > +DEFINE_EVENT(mhi_process_event_ring, mhi_data_event, > > > + > > > + TP_PROTO(struct mhi_controller *mhi_cntrl, struct mhi_ring_element *rp), > > > + > > > + TP_ARGS(mhi_cntrl, rp) > > > +); > > > + > > > +DEFINE_EVENT(mhi_process_event_ring, mhi_ctrl_event, > > > + > > > + TP_PROTO(struct mhi_controller *mhi_cntrl, struct mhi_ring_element *rp), > > > + > > > + TP_ARGS(mhi_cntrl, rp) > > > +); > > > + > > > +DECLARE_EVENT_CLASS(mhi_update_channel_state, > > > + > > > + TP_PROTO(struct mhi_controller *mhi_cntrl, struct mhi_chan *mhi_chan, > > > int state, > > > + const char *reason), > > > + > > > + TP_ARGS(mhi_cntrl, mhi_chan, state, reason), > > > + > > > + TP_STRUCT__entry( > > > + __string(name, mhi_cntrl->mhi_dev->name) > > > + __field(int, ch_num) > > > + __field(int, state) > > > + __field(const char *, reason) > > > + ), > > > + > > > + TP_fast_assign( > > > + __assign_str(name, mhi_cntrl->mhi_dev->name); > > > + __entry->ch_num = mhi_chan->chan; > > > + __entry->state = state; > > > + __entry->reason = reason; > > > + ), > > > + > > > + TP_printk("%s: chan%d: %s state to: %s\n", > > > + __get_str(name), __entry->ch_num, __entry->reason, > > > + __print_symbolic(__entry->state, MHI_CH_STATE_TYPE_LIST)) > > > +); > > > + > > > +DEFINE_EVENT(mhi_update_channel_state, mhi_channel_command_start, > > > + > > > + TP_PROTO(struct mhi_controller *mhi_cntrl, struct mhi_chan *mhi_chan, > > > int state, > > > + const char *reason), > > > + > > > + TP_ARGS(mhi_cntrl, mhi_chan, state, reason) > > > +); > > > + > > > +DEFINE_EVENT(mhi_update_channel_state, mhi_channel_command_end, > > > + > > > + TP_PROTO(struct mhi_controller *mhi_cntrl, struct mhi_chan *mhi_chan, > > > int state, > > > + const char *reason), > > > + > > > + TP_ARGS(mhi_cntrl, mhi_chan, state, reason) > > > +); > > > + > > > +TRACE_EVENT(mhi_pm_st_transition, > > > + > > > + TP_PROTO(struct mhi_controller *mhi_cntrl, int state), > > > + > > > + TP_ARGS(mhi_cntrl, state), > > > + > > > + TP_STRUCT__entry( > > > + __string(name, mhi_cntrl->mhi_dev->name) > > > + __field(int, state) > > > + ), > > > + > > > + TP_fast_assign( > > > + __assign_str(name, mhi_cntrl->mhi_dev->name); > > > + __entry->state = state; > > > + ), > > > + > > > + TP_printk("%s: Handling state transition: %s\n", __get_str(name), > > > + __print_symbolic(__entry->state, DEV_ST_TRANSITION_LIST)) > > > +); > > > + > > > +#endif > > > +#undef TRACE_INCLUDE_PATH > > > +#define TRACE_INCLUDE_PATH ../../drivers/bus/mhi/host > > > +#undef TRACE_INCLUDE_FILE > > > +#define TRACE_INCLUDE_FILE trace > > > + > > > +#include > > > > > > --- > > > base-commit: ae1d892d518af5c092f2b1f8e6921996c6a95cb3 > > > change-id: 20240206-ftrace_support-8ef0fbecf85e > > > > > > Best regards, > > > -- > > > Krishna chaitanya chundru > > > > > -- மணிவண்ணன் சதாசிவம்

Re: [PATCH] tracing: use ring_buffer_record_is_set_on() in tracer_tracing_is_on()

2024-02-06 Thread Sven Schnelle
Sven Schnelle writes: > Looking at trace_save_cmdline(): > > tpid = tsk->pid & (PID_MAX_DEFAULT - 1); where PID_MAX_DEFAULT = 0x8000 > > so this is basically > > tpid = tsk->pid & 0x7fff; > > further on: > > // might clash with other pid if (otherpid & 0x7fff) == (tsk->pid & > 0x7fff) >

Re: Question about the ipi_raise filter usage and output

2024-02-06 Thread richard clark
On Tue, Feb 6, 2024 at 12:05 AM Valentin Schneider wrote: > > On 05/02/24 14:39, Mark Rutland wrote: > > [adding Valentin] > > > > Thanks! > > > On Mon, Feb 05, 2024 at 08:06:09AM -0500, Steven Rostedt wrote: > >> On Mon, 5 Feb 2024 10:28:57 + > >> Mark Rutland wrote: > >> > >> > > I try to