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 for Android: free password hash cracker in your pocket

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

Message-ID: <5a2dbcf9-8201-4e94-94ba-e8377d5c9d98@quicinc.com>
Date: Wed, 12 Jun 2024 14:42:27 +0530
From: Deepak Kumar Singh <quic_deesin@...cinc.com>
To: Chris Lew <quic_clew@...cinc.com>,
        Sudeepgoud Patil
	<quic_sudeepgo@...cinc.com>,
        <quic_bjorande@...cinc.com>, <andersson@...nel.org>,
        <mathieu.poirier@...aro.org>
CC: <linux-kernel@...r.kernel.org>, <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/12/2024 4:35 AM, Chris Lew wrote:
> 
> 
> 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.
> 
I think it is ok to have this define in smp2p.c, as that is the only 
place where it is being used.
>> +
>> +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.