Re: Help adding trace events to xHCI

["Arend van Spriel" <arend@broadcom.com>]

On 07/11/2013 06:20 PM, Sarah Sharp wrote:
> On Mon, Jul 08, 2013 at 09:17:59PM +0300, Xenia Ragiadakou wrote:

>> But when there are other function calls before the callback call, I don't
>> no why but i cannot track anymore the position of the args following the
>> fmt argumenent in the stack with the pointer to fmt.
>
> I'm actually wondering if the call to ath6kl_printk is somehow necessary
> in order to be able to pass arguments on the stack.  Perhaps you should
> try defining a similar function for xHCI and see if that helps?

The ath6klk_printk() is not related to the trace function. It is a 
separate code path to get the message in the kernel log. I have seen 
these constructs before (and implemented it in brcmfmac) but it seems 
not very efficient when tracing as the printk can affect run-time behaviour.

> int ath6kl_printk(const char *level, const char *fmt, ...)
> {
> 	struct va_format vaf;
> 	va_list args;
> 	int rtn;
>
> 	va_start(args, fmt);
>
> 	vaf.fmt = fmt;
> 	vaf.va = &args;
>
> 	rtn = printk("%sath6kl: %pV", level, &vaf);
>
> 	va_end(args);
>
> 	return rtn;
> }
> EXPORT_SYMBOL(ath6kl_printk);
>
>> Anyway, something dirty like that will not enter the kernel but i will try
>> to do stack debugging on an example program to see why that happens.
>
> I would suggest just copy-pasting parts of the ath6kl trace code into
> the xHCI driver, and changing one of the xhci_dbg() calls to use that
> code, and see if it works.  If it doesn't work, send out an RFC patch
> (using the Cc list I've used), and we'll try to figure out what's going
> wrong.

The biggest challenge in adding tracepoints is identifying what you want 
to trace. While tracing debug messages can be convenient the real 
strength is in tracing code artifacts like for USB the thing that comes 
to my mind first is defining tracepoint for the urb and there are 
probably other internals that are informational.

Regards,
Arend