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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
