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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A334BC433F5 for ; Fri, 18 Mar 2022 14:09:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237068AbiCROKy (ORCPT ); Fri, 18 Mar 2022 10:10:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49738 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237024AbiCROKy (ORCPT ); Fri, 18 Mar 2022 10:10:54 -0400 Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E17B657A8; Fri, 18 Mar 2022 07:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1647612575; x=1679148575; h=message-id:date:mime-version:subject:to:references:from: in-reply-to:content-transfer-encoding; bh=bWqJsOTD8JiUP3/aKoY5m9fc2ncpVKEy1s6027tzTEM=; b=ggf5det3ZZ29/dalfqnNoiqKQkl0qQMfd9P8iqX4ySxM1o41eycJ2c8q T69r2ZxJEOoI5TippmIBIQfU40umkrCm2VKKZXe10dBPVFgOITExzYwhB 6a0RJ/37MmvOn8D1MN49jNrpDszjts8KhUwQguFlKDxozHwPG9bnlArfJ 0=; Received: from unknown (HELO ironmsg03-sd.qualcomm.com) ([10.53.140.143]) by alexa-out-sd-01.qualcomm.com with ESMTP; 18 Mar 2022 07:09:35 -0700 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.47.97.222]) by ironmsg03-sd.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Mar 2022 07:09:35 -0700 Received: from nalasex01a.na.qualcomm.com (10.47.209.196) by nasanex01c.na.qualcomm.com (10.47.97.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Fri, 18 Mar 2022 07:09:34 -0700 Received: from [10.110.88.130] (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Fri, 18 Mar 2022 07:09:33 -0700 Message-ID: Date: Fri, 18 Mar 2022 07:09:32 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH v2] i2c: add tracepoints for I2C slave events Content-Language: en-US To: Wolfram Sang , Steven Rostedt , "Ingo Molnar" , Jamie Iles , "Graeme Gregory" , , References: <20220308163333.3985974-1-quic_jaehyoo@quicinc.com> From: Jae Hyun Yoo In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01a.na.qualcomm.com (10.47.209.196) Precedence: bulk List-ID: X-Mailing-List: linux-i2c@vger.kernel.org Hi Wolfram, On 3/18/2022 3:53 AM, Wolfram Sang wrote: >> + if (trace_i2c_slave_enabled() && !ret) >> + trace_i2c_slave(client, event, val); > > Why '!ret'? I think we should always print 'ret' in the trace as well. > Backends are allowed to send errnos on WRITE_RECEIVED to NACK the > reception of a byte. This is useful information, too, or? Ah, you are right. As itself should trace all events including NACK cases, it'd be better to print out the 'ret' too. I'll add it to v3. Thanks, Jae