Sarah Sharp <sarah.a.sh...@linux.intel.com> writes: > My initial list of specific trace points was something like: > > 1. xHCI host initialization and shutdown > > 2. xHCI memory allocation (dynamic ring resizing, structure alloc, etc) > > 3. A few individual xHCI host controller command tracepoints: > * status only for all completed commands > * Address Device command status and output > * Configure Endpoint and Evaluate Context output > * individual trace points for other xHCI commands > > 4. Tracepoints for all USB transfer types: > * Control TX output (only for non-successful transfers) > * Bulk TX > * Interrupt TX > * Isoc TX > > 5. URB cancellation > > And probably more. Basically, I want to be able to control what gets > printed, based on where I think the xHCI bug might be. Does that sound > reasonable?
Instead of individual trace points for command I would recommend to consider just pushing the whole command buffer to the trace point and parse the command in trace-cmd plugin in user space. Kernel code would be simpler that way. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
