linux-kernel - Re: [PATCH V2 2/2] soc: qcom: smp2p: Introduce tracepoint support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0318b0c2-5686-4565-b75b-fa1ecfe61740@quicinc.com>
Date: Tue, 11 Jun 2024 16:05:50 -0700
From: Chris Lew <quic_clew@...cinc.com>
To: Sudeepgoud Patil <quic_sudeepgo@...cinc.com>, <quic_bjorande@...cinc.com>,
        <andersson@...nel.org>, <mathieu.poirier@...aro.org>
CC: <linux-kernel@...r.kernel.org>, <quic_deesin@...cinc.com>,
        <linux-arm-msm@...r.kernel.org>, <linux-remoteproc@...r.kernel.org>,
        "Konrad
 Dybcio" <konrad.dybcio@...aro.org>
Subject: Re: [PATCH V2 2/2] soc: qcom: smp2p: Introduce tracepoint support



On 6/11/2024 5:33 AM, Sudeepgoud Patil wrote:
> This commit introduces tracepoint support for smp2p,
> enabling logging of communication between local and remote processors.
> The tracepoints include information about the remote processor ID,
> remote subsystem name, negotiation details, supported features,
> bit change notifications, and ssr activity.
> These tracepoints are valuable for debugging issues between subsystems.
> 
> Signed-off-by: Sudeepgoud Patil <quic_sudeepgo@...cinc.com>
> ---
...
> diff --git a/drivers/soc/qcom/trace-smp2p.h b/drivers/soc/qcom/trace-smp2p.h
> new file mode 100644
> index 000000000000..833782460b57
> --- /dev/null
> +++ b/drivers/soc/qcom/trace-smp2p.h
> @@ -0,0 +1,116 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM qcom_smp2p
> +
> +#if !defined(__QCOM_SMP2P_TRACE_H__) || defined(TRACE_HEADER_MULTI_READ)
> +#define __QCOM_SMP2P_TRACE_H__
> +
> +#include <linux/tracepoint.h>
> +
> +#define SMP2P_FEATURE_SSR_ACK 0x1

Now that I see it, redefining the the feature flag here seems a bit out 
of place. I'm not sure if it's worth kicking off a header file for this 
single define though.

> +
> +TRACE_EVENT(smp2p_ssr_ack,
> +	TP_PROTO(unsigned int remote_pid, char *irq_devname),
> +	TP_ARGS(remote_pid, irq_devname),
> +	TP_STRUCT__entry(
> +		__field(u32, remote_pid)
> +		__string(irq_devname, irq_devname)
> +	),
> +	TP_fast_assign(
> +		__entry->remote_pid = remote_pid;
> +		__assign_str(irq_devname, irq_devname);
> +	),
> +	TP_printk("%d: %s: SSR detected, doing SSR Handshake",
> +		__entry->remote_pid,
> +		__get_str(irq_devname)
> +	)
> +);
> +

I don't think we need to pass remote_pid into all of the traces if we 
have a unique name "irq_devname" to identify the remote now. We could 
remove remote_pid from all the trace event arguments.

We can probably drop the "doing SSR Handshake" part of this print. I 
think it can be assumed that we're doing the handshake once we've 
detected SSR.