On 09/15/2016 07:06 AM, Valo, Kalle wrote:
Ben Greear <gree...@candelatech.com> writes:
On 09/14/2016 07:18 AM, Valo, Kalle wrote:
gree...@candelatech.com writes:
From: Ben Greear <gree...@candelatech.com>
This allows user-space tools to decode debug-log
messages by parsing dmesg or /var/log/messages.
Signed-off-by: Ben Greear <gree...@candelatech.com>
Don't tracing points already provide the same information?
Tracing tools are difficult to set up and may not be available on
random embedded devices. And if we are dealing with bug reports from
the field, most users will not be able to set it up regardless.
There are similar ways to print out hex, but the logic below creates
specific and parseable logs in the 'dmesg' output and similar.
I have written a tool that can decode these messages into useful human-readable
text so that I can debug firmware issues both locally and from field reports.
Stock firmware generates similar logs and QCA could write their own decode logic
for their firmware versions.
Reinventing the wheel by using printk as the delivery mechanism doesn't
sound like a good idea. IIRC Emmanuel talked about some kind of firmware
debugging framework, he might have some ideas.
Waiting for magical frameworks to fix problems is even worse.
It has been years since ath10k has been in the kernel. There is basically
still no way to debug what the firmware is doing.
My patch gives you something that can work right now, with the standard 'dmesg'
framework found in virtually all kernels new and old, and it has been proven
to be useful in the field. The messages are also nicely interleaved with the
rest of the mac80211 stack messages and any other driver messages, so you have
context.
If someone wants to add support for a framework later, then by all means, post
the patches when it is ready.
Thanks,
Ben
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
