From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6C02FC678D5 for ; Wed, 8 Mar 2023 13:43:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=BSZooRQU3KOAiV9jxRvihh+r4sWZOff4q0OVn+EcVkA=; b=qNnUAxWs0bh4Qt WDYw6EAj1l074tZpkGV0lFkmngDZhXIoXtqrDAqKax5ahj4WJKU5V2feio0exEBZOKCl9gTA1OmfV iREBo5ae/ZsD0FnBC0zosGZ12JXQPo0OgvSrP2H5ZKFD1VxGTxlyzyWnjcAtBEQxp+69SdeNyFD3H bGcc2IgLczi82GWFNHTjksM0m+oUrjw7DRSlYiAo+mKMsSa3JmtXetOIL7zBv9HbC/Ku2Tor6HxQ0 DNlOx2j6JOp+VLntvDwDIY+Mv0xMuBNB+3nRSuQVDyCsGY8ZohQpS3lS+HN37f43eZphaCV36hFoi FhJC1B60et97Jfh5KO+g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pZu3h-005FTR-2M; Wed, 08 Mar 2023 13:42:21 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pZu3c-005FSF-La for linux-arm-kernel@lists.infradead.org; Wed, 08 Mar 2023 13:42:18 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 36767FEC; Wed, 8 Mar 2023 05:42:54 -0800 (PST) Received: from bogus (unknown [10.57.16.230]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 64EB33F67D; Wed, 8 Mar 2023 05:42:09 -0800 (PST) Date: Wed, 8 Mar 2023 13:42:02 +0000 From: Sudeep Holla To: Rakesh Babu Saladi Cc: Mark Rutland , Sudeep Holla , "lpieralisi@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Sunil Kovvuri Goutham , George Cherian , Naveen Mamindlapalli Subject: Re: [EXT] Re: [PATCH] arm64: smccc: Add trace events to SMC calls. Message-ID: <20230308134202.smd7bfhtu27saaay@bogus> References: <20230304125850.32687-1-rsaladi2@marvell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230308_054216_773118_F13D50FD X-CRM114-Status: GOOD ( 20.88 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Mar 08, 2023 at 12:25:15PM +0000, Rakesh Babu Saladi wrote: > Hi Mark, > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_lkml_20210923112058.GA14893-40C02TD0UTHF1T.local_&d=DwIBAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=OrNjoyjPmqlDfiSr6RMDtAJU4gxiGfgzEtgbqDmoQPA&m=fj6aQCqc0xOYgRMw7BGCVRrOEabi2taRuKl63gCdHras-JfpWCGhjp6HqaLZYj9I&s=1_EJt65j5EoyHhcroJxJFMIkTqQY6jKtWypPIzmgYK8&e= > (Nit: You need to fix your email setup, it is spoiling the links and also flow for reading in general) > I don't think anything has changed, and this has all the same problems as > before, so I do not think we should do this. > > Rakesh >> Can you please be more specific why the changes are not getting accepted? > Have you gone through the link Mark pointed at ? For starters, you have new v1.2 specific calls that has x0-x17 as the input and output registers which neither this patch or the earlier one addressed if we agree to allow tracing SMCCC calls this way. > Which SMC calls do you want to trace, and why? > Rakesh >> These traces we would like to have for debugging purposes while calling any SMC call. > The main point was why would you want to enable universal tracing of all SMCCC calls. Remember that means you would trace the most common and fundamental for boot PSCI calls which cover CPU_SUSPEND and it gets called a *lot* for obvious reasons. So it is not a good idea to do so. So, what are you using this trace for ? Is that a specific driver using SMCCC ? Can't the trace be added in that driver as you could add specifics there ? Taking v1.2 SMCCC as example, though the spec and the API itself allows 18 registers to be input and output, it may not be used in most of the cases and adding them to the trace is just useless. Hence the suggestion of making it specific to your use-case. -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel