Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp2471057pxu; Mon, 7 Dec 2020 07:27:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJwZXqvFRQNdQ08N6oxoqUE7bRRAo4x9rOGBbzdxBkDfd3/aMe1MBBpcXRhn69baQCsvOwsU X-Received: by 2002:a50:ed17:: with SMTP id j23mr20627437eds.218.1607354825945; Mon, 07 Dec 2020 07:27:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607354825; cv=none; d=google.com; s=arc-20160816; b=etXQfZ6bZ0mM/1DzS9Lh+OaOvkaMgfbpFpvsLLoXwGUEKgYgaR/jZ94S7JoK1oEd00 4+SQyIbvJcNybF/RULPzy83tJXVXbhl07dzJniYdfn8fjc6PW+D46y8B2fSaZxc+yDuh t7lEAfYhdACTGLl3xh0btQy4eIUyboaRdC0s2sFk+JhmjoOYKpRq0adKVW78ER7662Oa Cm/2A2b3dezbuWYMyw6BUCI6R/3qh12JcqUA8LHF/y1QujbMClEh4FwVwYPyLC/HHrnC o40gbNKdWPH6GQBfrJ5h8CinyWts4NfHqY71bYECspeA7Hqzc6wGZpBuXG5sRLY1fqix EIwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=BI+tq7CFdZAkBLJPY2WqVcLUVvQ7S3HDtrHajNlyCa0=; b=eCr5glp+qXJiIIfFtPo6Ho2tNxjycirz8pAG7XlG6rzLYohHaKZAN4Cv+xMaAAdBmV Yu7kxTnjQiNYPa4iQUV5EbvldWgK5U+fy4tGjO4V98fNFyHuUuZPO208TU9qj+WtZZJ2 P20YkopL7DfinXQ632KgtTb2k0s1uWPqfYZVq7Y9IRr0HC7cgtAS/YsohDOJJJZOb6y7 1x1GXPBuQPXeGnLbZWgnqMPeSyoG1FzNyfgs/Za3v6ZrX4iE2If/08VkdbFoOY5fc8iC X+MEUMqo/1m4EymnGHxFoFqiDX0bDfT2uFojQKHphThkZSCUT6H95AN85iUjkHhU570x JikA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j22si6542619ejm.64.2020.12.07.07.26.42; Mon, 07 Dec 2020 07:27:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726426AbgLGPWK (ORCPT + 99 others); Mon, 7 Dec 2020 10:22:10 -0500 Received: from mail.kernel.org ([198.145.29.99]:33170 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725832AbgLGPWJ (ORCPT ); Mon, 7 Dec 2020 10:22:09 -0500 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (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 486992371F; Mon, 7 Dec 2020 15:21:28 +0000 (UTC) Date: Mon, 7 Dec 2020 10:21:26 -0500 From: Steven Rostedt To: Bean Huo Cc: alim.akhtar@samsung.com, avri.altman@wdc.com, asutoshd@codeaurora.org, jejb@linux.ibm.com, martin.petersen@oracle.com, stanley.chu@mediatek.com, beanhuo@micron.com, bvanassche@acm.org, tomas.winkler@intel.com, cang@codeaurora.org, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 1/3] scsi: ufs: Distinguish between query REQ and query RSP in query trace Message-ID: <20201207102126.66d8e4f7@gandalf.local.home> In-Reply-To: <20201206164226.6595-2-huobean@gmail.com> References: <20201206164226.6595-1-huobean@gmail.com> <20201206164226.6595-2-huobean@gmail.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 6 Dec 2020 17:42:24 +0100 Bean Huo wrote: > From: Bean Huo > > Currently, in the query completion trace print, since we use > hba->lrb[tag].ucd_req_ptr and didn't differentiate UPIU between > request and response, thus header and transaction-specific field > in UPIU printed by query trace are identical. This is not very > practical. As below: > > query_send: HDR:16 00 00 0e 00 81 00 00 00 00 00 00, CDB:06 0e 03 00 00 00 00 00 00 00 00 00 00 00 00 00 > query_complete: HDR:16 00 00 0e 00 81 00 00 00 00 00 00, CDB:06 0e 03 00 00 00 00 00 00 00 00 00 00 00 00 00 > > For the failure analysis, we want to understand the real response > reported by the UFS device, however, the current query trace tells > us nothing. After this patch, the query trace on the query_send, and > the above a pair of query_send and query_complete will be: > > query_send: HDR:16 00 00 0e 00 81 00 00 00 00 00 00, CDB:06 0e 03 00 00 00 00 00 00 00 00 00 00 00 00 00 > ufshcd_upiu: HDR:36 00 00 0e 00 81 00 00 00 00 00 00, CDB:06 0e 03 00 00 00 00 00 00 00 00 01 00 00 00 00 > > Signed-off-by: Bean Huo > --- > drivers/scsi/ufs/ufshcd.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c > index ceb562accc39..e10de94adb3f 100644 > --- a/drivers/scsi/ufs/ufshcd.c > +++ b/drivers/scsi/ufs/ufshcd.c > @@ -321,9 +321,15 @@ static void ufshcd_add_cmd_upiu_trace(struct ufs_hba *hba, unsigned int tag, > static void ufshcd_add_query_upiu_trace(struct ufs_hba *hba, unsigned int tag, > const char *str) > { > - struct utp_upiu_req *rq = hba->lrb[tag].ucd_req_ptr; > + struct utp_upiu_req *rq_rsp; > + I would add: if (!trace_ufshcd_upiu_enabled()) return; Why do the work if the trace point is not enabled? -- Steve > + if (!strcmp("query_send", str)) > + rq_rsp = hba->lrb[tag].ucd_req_ptr; > + else > + rq_rsp = (struct utp_upiu_req *)hba->lrb[tag].ucd_rsp_ptr; > > - trace_ufshcd_upiu(dev_name(hba->dev), str, &rq->header, &rq->qr); > + trace_ufshcd_upiu(dev_name(hba->dev), str, &rq_rsp->header, > + &rq_rsp->qr); > } > > static void ufshcd_add_tm_upiu_trace(struct ufs_hba *hba, unsigned int tag,