From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751558AbdBOI5W (ORCPT ); Wed, 15 Feb 2017 03:57:22 -0500 Received: from mga06.intel.com ([134.134.136.31]:51344 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751063AbdBOI5O (ORCPT ); Wed, 15 Feb 2017 03:57:14 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,165,1484035200"; d="asc'?scan'208";a="934088337" From: Felipe Balbi To: Lu Baolu , Mathias Nyman Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/6] usb: xhci: add xhci_log_cmd trace events In-Reply-To: <58A4102C.3020502@linux.intel.com> References: <1487126112-6069-1-git-send-email-baolu.lu@linux.intel.com> <1487126112-6069-2-git-send-email-baolu.lu@linux.intel.com> <8760kbq40y.fsf@linux.intel.com> <58A4102C.3020502@linux.intel.com> Date: Wed, 15 Feb 2017 10:56:39 +0200 Message-ID: <87y3x7omrc.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Lu Baolu writes: >> Lu Baolu writes: >>> diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trac= e.h >>> index 1ac2cdf..c31eeaf 100644 >>> --- a/drivers/usb/host/xhci-trace.h >>> +++ b/drivers/usb/host/xhci-trace.h >>> @@ -285,6 +285,96 @@ DEFINE_EVENT(xhci_log_urb, xhci_urb_dequeue, >>> TP_ARGS(urb) >>> ); >>>=20=20 >>> +DECLARE_EVENT_CLASS(xhci_log_cmd, >>> + TP_PROTO(struct xhci_command *cmd), >>> + TP_ARGS(cmd), >>> + TP_STRUCT__entry( >>> + __field(struct xhci_command *, cmd) >>> + __field(struct xhci_container_ctx *, in_ctx) >>> + __field(union xhci_trb *, cmd_trb) >>> + __field(int, slot_id) >>> + __field(int, status) >>> + __field(int, type) >>> + ), >>> + TP_fast_assign( >>> + __entry->cmd =3D cmd; >>> + __entry->in_ctx =3D cmd->in_ctx; >>> + __entry->cmd_trb =3D cmd->command_trb; >>> + __entry->slot_id =3D cmd->slot_id; >>> + __entry->status =3D cmd->status; >>> + __entry->type =3D TRB_FIELD_TO_TYPE(le32_to_cpu(cmd->command_trb->ge= neric.field[3])) >>> + ), >>> + TP_printk("cmd @%p: %s: in_ctx=3D@%p, slot_id=3D%d, cmd_trb=3D@%p, st= atus=3D%d", >>> + __entry->cmd, xhci_trb_type_string(__entry->type), >>> + __entry->in_ctx, __entry->slot_id, __entry->cmd_trb, >>> + __entry->status >>> + ) >>> +); >> we already have a generic TRB tracer that decodes every single TRB. What >> is this bringing that the previous doesn't provide? > > This tracer traces the life cycle of a command. It gives, > > 1) Which function started an xhci command? > 2) What was name of that command? > 3) Did hardware respond to it, or timed out? > 4) If hardware responded, what was the execution result? > 5) If timed out, did 'abort command ring operation' abort it successfully? > 6) Was the command structure freed at last? We already have all that, AFAICT. Command is enqueued, then an event triggers for command completion, then we look at results. The only thing missing for completeness is slot/EP context tracers (which I've pointed you to) so we can see what changes each command cause to the different contexts. Frankly, I don't think printing out context pointers brings anything. What can you do with that address? :-p Same goes for cmd pointer, it brings nothing; gives no insight into the problem whatsoever. We certainly need to know which command was enqueued, the slot, etc. But addresses... not so sure. >> BTW, I also have >> ready Slot and EP context tracers, I didn't send before because I >> already had quite a large series pending for Mathias :-p > > Sorry for the duplication. no need to apologize, you didn't know :-) =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEElLzh7wn96CXwjh2IzL64meEamQYFAlikF8cACgkQzL64meEa mQaH2A/+JQ5oNlN9tnfkck+5iO59SKw/2WGfFrt+nkMEzBF5jiARvv221Niv4Ynu U5iYSZc4tcs73B4oC6vzce7E7ghel5y1ZvNwTOT2rr5d27dOd0xhbBl3YEE3JwdQ eJARga0KQyOMpEWtoqq95sGh7iaYI1kahmF9zBcrNNBXJRVH0Fpi0ANaBET69vQb 9UtwIKJmUTRxhclBOwNJ6UYg+hyA7rsfpexiQ/qDqH4VYHT9gVMPEQ/sxox7QCrb D2e5TxMk5YTlCe9q4F7BXZJJM9zoQRD6ppaPqWWZ9iUO1r1WI84vlBpNzND1GvnC crUTOOwSL49ertzaxhqFvuwFIGqsaEd2vqanQLgXJb8Uwbjddvhm1SRL+PBFozYJ OxisWUDKW0q4mL+54dSYY8fdJ0JS30teu1CLwDDZa7GwDxVIGxFEyP3ETqxuNVC5 E+uljkGViAam9FRqSNgx+ugRwUXBdiAM6U/IeaFccxIjZHH+GgX3Jx6lw6mMoJQA T1CpPUPdWBl8Su1yfvHNPIUVyBaqQPrB2zaNmSXg+Ye9TGoI29grqD4dz32G7/kr i6g/IppjpBD4hCgGwosXOwYc6nnS2n3ZOQlWqATjrogHgqFOvgl0mN2LZubR9nLG OAb3or19BAB9y44ajLAAsgcgHUA6j0CpU+R1cfeI3wZ6npi+UTc= =MMdn -----END PGP SIGNATURE----- --=-=-=--