Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp788371imm; Wed, 8 Aug 2018 05:54:38 -0700 (PDT) X-Google-Smtp-Source: AA+uWPxS7NS0YrefHrUp3I2/H/X1UnIyJaLa7igYwE+Mreku1MPLJPcbaWvEIng6U3G8eeNz+/BR X-Received: by 2002:a17:902:b58e:: with SMTP id a14-v6mr2544641pls.22.1533732878937; Wed, 08 Aug 2018 05:54:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533732878; cv=none; d=google.com; s=arc-20160816; b=LpkgUkjHTVUikTsvSCisglGmhlJHn2i5srFU9v/U6vUX9sp6uA1QnGCjfabglHxcMo o1SQIPL4PXqHRgpPHac6Ula8noptak1JMqUlhp6sELxAnt+I7axBu+NvOCYjs7IxjR4P 4CIMydUT5scFzIyg+0nwhi+dgW//Q97Jt1G3FUjXEjUvjT2A6VRcCqrEJ61oE9WiuSdi jhcDuXRQXpbTB95jEametYcDhKqayRAARZflQU9rQGzm9P/r5dYo0tcV8PNMu45uTurI AZp8yD9QvKsFiyX6YlMIpENORNeYAIg/s7q34Ym2XLVTpTqRNogaj6zerotPYeSlo0/G WVKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=V/LqpM4+i0EvDMgWc7ZTbIiOqG58kxD0S2vj3ggXnZM=; b=y942O4iIsrgW+hwLoNMPg9vqJEm/etKjIAWPHb2nm8FDw16VoYnY3FEQu0R9csYhXj 2mU/ZhoHyN1HfOSPrB2pgisczy0s1pHnFlJFYWioquu/055V5Le7+5z52EC9k+B22gjM jxnOOoZS3RRJM7jKJZivGfi/6hnElxqpu9FBtMxTyWT0UPjKF/RC1wRPotIERaHIaR10 HF2emMWU5/JOceW3v87kSCB6se/JsCz3LHqXdYJsClNjU24xrQirWgzWAAb7o6maWaOz YxitWq5jg9B5OxTORpW+Mn0tx9GYd4YHNn4nPpVR2quuYnXxH2KSzoo0lfPSdtPqtnRB IzGQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a67-v6si3586273pla.135.2018.08.08.05.54.24; Wed, 08 Aug 2018 05:54:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727245AbeHHPMi (ORCPT + 99 others); Wed, 8 Aug 2018 11:12:38 -0400 Received: from mail.kernel.org ([198.145.29.99]:36742 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726680AbeHHPMh (ORCPT ); Wed, 8 Aug 2018 11:12:37 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 42B44219EF; Wed, 8 Aug 2018 12:53:03 +0000 (UTC) Date: Wed, 8 Aug 2018 08:53:01 -0400 From: Steven Rostedt To: "Liu, Changcheng" Cc: broonie@opensource.wolfsonmicro.com, mingo@redhat.com, linux-kernel@vger.kernel.org, akpm@linux-foundation.org Subject: Re: [PATCH] ASoC: trace: track dapm type in snd_soc_dapm_widget Message-ID: <20180808085301.2b0617c6@gandalf.local.home> In-Reply-To: <20180808123921.GA145536@sofia> References: <20180808092927.GA144203@sofia> <20180808082412.20f7bd92@gandalf.local.home> <20180808123921.GA145536@sofia> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 8 Aug 2018 20:39:22 +0800 "Liu, Changcheng" wrote: > > > - TP_printk("widget=%s val=%d", __get_str(name), > > > - (int)__entry->val) > > > + TP_printk("widget=%s dapm_id=%d val=%d", __get_str(name), > > > + (int)__entry->id, (int)__entry->val) > > > > Not sure why it was there before, but the (int) typecast isn't needed > > in either case. __field(int, val) makes __entry->val of type int. Same > > for id. > > > > -- Steve > > @Steve: This patch aims at tracking the dapm up/down sequence. For the > (int) typecast format problem, what do you think of using another > seperate patch to resolve it? Yeah, I was just commenting on that as a general comment. It doesn't affect the actual patch, which I don't see anything wrong with it from a tracing point of view. I agree the typecast removal should be done in a separate clean-up patch. -- Steve