Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-12-12 Thread Luis R. Rodriguez
On Wed, Dec 12, 2012 at 1:12 AM, Vladimir Kondratiev
 wrote:
> +#define dynamic_hex_dump(prefix_str, prefix_type, rowsize, \

wil_dynamic_hex_dump()

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-12-12 Thread Vladimir Kondratiev
On Tuesday, December 11, 2012 02:55:55 PM Luis R. Rodriguez wrote:
> Vladimir, to be clear, you can continue with waiting for the patches
> to get into 3.9 but that will take a while but given that you want
> your driver in 3.8 you can fold those routines into your driver as
> you had before but with a rename by adding a prefix and sumbit that
> driver and specify it is for 3.8.
> 

I have internally patch that will compensate not merged yet functionality,
without any rename, see below. I can massage commit message and include it
with my driver as separate patch to be easier to undo later.

Comments?

>From c4e7254d0cba51c8b43d36a317a1b847fffb18d8 Mon Sep 17 00:00:00 2001
From: Vladimir Kondratiev 
Date: Wed, 21 Nov 2012 13:57:21 +0200
Subject: [PATCH] [DEBUG] Allow to compile with mainstream kernel

Unless patch for dynamic hexdump merged into mainstream kernel,
need to provide replacement for the dynamic hexdump functionality

Do not hurt compilation with kernel that have patch above merged.

REMOVE when dynamic hexdump merged into mainstream kernel!!

Change-Id: I6abb8f91ed529ffc84bd9cc21444a59ee15fe456
---
 dbg_hexdump.h |   32 
 wil6210.h |2 ++
 2 files changed, 34 insertions(+)
 create mode 100644 dbg_hexdump.h

diff --git a/dbg_hexdump.h b/dbg_hexdump.h
new file mode 100644
index 000..7144eed
--- /dev/null
+++ b/dbg_hexdump.h
@@ -0,0 +1,32 @@
+#ifndef DBG_HEXDUMP_H_
+#define DBG_HEXDUMP_H_
+
+#if !defined(print_hex_dump_debug)
+#if defined(CONFIG_DYNAMIC_DEBUG)
+#define dynamic_hex_dump(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)\
+do {   \
+   DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \
+   __builtin_constant_p(prefix_str) ? prefix_str : "hexdump");\
+   if (unlikely(descriptor.flags & _DPRINTK_FLAGS_PRINT))  \
+   print_hex_dump(KERN_DEBUG, prefix_str,  \
+  prefix_type, rowsize, groupsize, \
+  buf, len, ascii);\
+} while (0)
+
+#define print_hex_dump_debug(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)\
+   dynamic_hex_dump(prefix_str, prefix_type, rowsize,  \
+groupsize, buf, len, ascii)
+
+#define print_hex_dump_bytes(prefix_str, prefix_type, buf, len)\
+   dynamic_hex_dump(prefix_str, prefix_type, 16, 1, buf, len, true)
+#else /* defined(CONFIG_DYNAMIC_DEBUG) */
+#define print_hex_dump_debug(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)\
+   print_hex_dump(KERN_DEBUG, prefix_str, prefix_type, rowsize,\
+  groupsize, buf, len, ascii)
+#endif /* defined(CONFIG_DYNAMIC_DEBUG) */
+#endif /* !defined(print_hex_dump_debug) */
+
+#endif /* DBG_HEXDUMP_H_ */
diff --git a/wil6210.h b/wil6210.h
index b37c3d2..4797da0 100644
--- a/wil6210.h
+++ b/wil6210.h
@@ -21,6 +21,8 @@
 #include 
 #include 
 
+#include "dbg_hexdump.h"
+
 #define WIL_NAME "wil6210"
 
 /**
-- 
1.7.10.4


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-12-12 Thread Vladimir Kondratiev
On Tuesday, December 11, 2012 02:55:55 PM Luis R. Rodriguez wrote:
 Vladimir, to be clear, you can continue with waiting for the patches
 to get into 3.9 but that will take a while but given that you want
 your driver in 3.8 you can fold those routines into your driver as
 you had before but with a rename by adding a prefix and sumbit that
 driver and specify it is for 3.8.
 

I have internally patch that will compensate not merged yet functionality,
without any rename, see below. I can massage commit message and include it
with my driver as separate patch to be easier to undo later.

Comments?

From c4e7254d0cba51c8b43d36a317a1b847fffb18d8 Mon Sep 17 00:00:00 2001
From: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com
Date: Wed, 21 Nov 2012 13:57:21 +0200
Subject: [PATCH] [DEBUG] Allow to compile with mainstream kernel

Unless patch for dynamic hexdump merged into mainstream kernel,
need to provide replacement for the dynamic hexdump functionality

Do not hurt compilation with kernel that have patch above merged.

REMOVE when dynamic hexdump merged into mainstream kernel!!

Change-Id: I6abb8f91ed529ffc84bd9cc21444a59ee15fe456
---
 dbg_hexdump.h |   32 
 wil6210.h |2 ++
 2 files changed, 34 insertions(+)
 create mode 100644 dbg_hexdump.h

diff --git a/dbg_hexdump.h b/dbg_hexdump.h
new file mode 100644
index 000..7144eed
--- /dev/null
+++ b/dbg_hexdump.h
@@ -0,0 +1,32 @@
+#ifndef DBG_HEXDUMP_H_
+#define DBG_HEXDUMP_H_
+
+#if !defined(print_hex_dump_debug)
+#if defined(CONFIG_DYNAMIC_DEBUG)
+#define dynamic_hex_dump(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)\
+do {   \
+   DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \
+   __builtin_constant_p(prefix_str) ? prefix_str : hexdump);\
+   if (unlikely(descriptor.flags  _DPRINTK_FLAGS_PRINT))  \
+   print_hex_dump(KERN_DEBUG, prefix_str,  \
+  prefix_type, rowsize, groupsize, \
+  buf, len, ascii);\
+} while (0)
+
+#define print_hex_dump_debug(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)\
+   dynamic_hex_dump(prefix_str, prefix_type, rowsize,  \
+groupsize, buf, len, ascii)
+
+#define print_hex_dump_bytes(prefix_str, prefix_type, buf, len)\
+   dynamic_hex_dump(prefix_str, prefix_type, 16, 1, buf, len, true)
+#else /* defined(CONFIG_DYNAMIC_DEBUG) */
+#define print_hex_dump_debug(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)\
+   print_hex_dump(KERN_DEBUG, prefix_str, prefix_type, rowsize,\
+  groupsize, buf, len, ascii)
+#endif /* defined(CONFIG_DYNAMIC_DEBUG) */
+#endif /* !defined(print_hex_dump_debug) */
+
+#endif /* DBG_HEXDUMP_H_ */
diff --git a/wil6210.h b/wil6210.h
index b37c3d2..4797da0 100644
--- a/wil6210.h
+++ b/wil6210.h
@@ -21,6 +21,8 @@
 #include linux/wireless.h
 #include net/cfg80211.h
 
+#include dbg_hexdump.h
+
 #define WIL_NAME wil6210
 
 /**
-- 
1.7.10.4


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-12-12 Thread Luis R. Rodriguez
On Wed, Dec 12, 2012 at 1:12 AM, Vladimir Kondratiev
qca_vkond...@qca.qualcomm.com wrote:
 +#define dynamic_hex_dump(prefix_str, prefix_type, rowsize, \

wil_dynamic_hex_dump()

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-12-11 Thread Luis R. Rodriguez
On Tue, Dec 11, 2012 at 12:24:04PM -0800, Joe Perches wrote:
> On Tue, 2012-12-11 at 12:12 -0800, Greg KH wrote:
> > On Tue, Dec 11, 2012 at 03:08:31PM -0500, Jason Baron wrote:
> > > On Tue, Dec 11, 2012 at 11:36:46AM -0800, Luis R. Rodriguez wrote:
> > > > On Tue, Dec 04, 2012 at 11:28:26AM +0200, Vladimir Kondratiev wrote:
> > > > > Hi Jason,
> > > > > 
> > > > > Do you have any update on the status for patches below?
> > > > > Where is it now? When do you expect it to merge? 3.8?
> > > > > I am waiting for this to merge before I can go on
> > > > > with my driver.
> > > > 
> > > > *poke*
> > > > 
> > > >   Luis
> > > 
> > > Hi Luis,
> > > 
> > > Yes, I posted this patch, along with 2 others last week for Greg to
> > > pull. I believe these are too late for the 3.8 merge window. Perhaps,
> > > Greg can comment. Here's a link to the post:
> > > 
> > > http://marc.info/?l=linux-kernel=135474417810281=2
> > 
> > Yes it's too late, these will go into linux-next after 3.8-rc1 is out.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Vladimir, sorry about this.
> 
> I suggest you prefix/rename and include these functions directly into
> your driver and later after 3.9 is out you could again rename the
> local calls to the now generic kernel functions and delete the local
> ones.

Vladimir, to be clear, you can continue with waiting for the patches
to get into 3.9 but that will take a while but given that you want
your driver in 3.8 you can fold those routines into your driver as
you had before but with a rename by adding a prefix and sumbit that
driver and specify it is for 3.8.

> Your driver is for new hardware, so even now it should be able to
> go into 3.8.

Agreed.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-12-11 Thread Joe Perches
On Tue, 2012-12-11 at 12:12 -0800, Greg KH wrote:
> On Tue, Dec 11, 2012 at 03:08:31PM -0500, Jason Baron wrote:
> > On Tue, Dec 11, 2012 at 11:36:46AM -0800, Luis R. Rodriguez wrote:
> > > On Tue, Dec 04, 2012 at 11:28:26AM +0200, Vladimir Kondratiev wrote:
> > > > Hi Jason,
> > > > 
> > > > Do you have any update on the status for patches below?
> > > > Where is it now? When do you expect it to merge? 3.8?
> > > > I am waiting for this to merge before I can go on
> > > > with my driver.
> > > 
> > > *poke*
> > > 
> > >   Luis
> > 
> > Hi Luis,
> > 
> > Yes, I posted this patch, along with 2 others last week for Greg to
> > pull. I believe these are too late for the 3.8 merge window. Perhaps,
> > Greg can comment. Here's a link to the post:
> > 
> > http://marc.info/?l=linux-kernel=135474417810281=2
> 
> Yes it's too late, these will go into linux-next after 3.8-rc1 is out.
> 
> thanks,
> 
> greg k-h
> 

Vladimir, sorry about this.

I suggest you prefix/rename and include these functions directly into
your driver and later after 3.9 is out you could again rename the
local calls to the now generic kernel functions and delete the local
ones.

Your driver is for new hardware, so even now it should be able to
go into 3.8.

cheers, Joe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-12-11 Thread Greg KH
On Tue, Dec 11, 2012 at 03:08:31PM -0500, Jason Baron wrote:
> On Tue, Dec 11, 2012 at 11:36:46AM -0800, Luis R. Rodriguez wrote:
> > On Tue, Dec 04, 2012 at 11:28:26AM +0200, Vladimir Kondratiev wrote:
> > > Hi Jason,
> > > 
> > > Do you have any update on the status for patches below?
> > > Where is it now? When do you expect it to merge? 3.8?
> > > I am waiting for this to merge before I can go on
> > > with my driver.
> > 
> > *poke*
> > 
> >   Luis
> 
> Hi Luis,
> 
> Yes, I posted this patch, along with 2 others last week for Greg to
> pull. I believe these are too late for the 3.8 merge window. Perhaps,
> Greg can comment. Here's a link to the post:
> 
> http://marc.info/?l=linux-kernel=135474417810281=2

Yes it's too late, these will go into linux-next after 3.8-rc1 is out.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-12-11 Thread Jason Baron
On Tue, Dec 11, 2012 at 11:36:46AM -0800, Luis R. Rodriguez wrote:
> On Tue, Dec 04, 2012 at 11:28:26AM +0200, Vladimir Kondratiev wrote:
> > Hi Jason,
> > 
> > Do you have any update on the status for patches below?
> > Where is it now? When do you expect it to merge? 3.8?
> > I am waiting for this to merge before I can go on
> > with my driver.
> 
> *poke*
> 
>   Luis

Hi Luis,

Yes, I posted this patch, along with 2 others last week for Greg to
pull. I believe these are too late for the 3.8 merge window. Perhaps,
Greg can comment. Here's a link to the post:

http://marc.info/?l=linux-kernel=135474417810281=2

Thanks,

-Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-12-11 Thread Luis R. Rodriguez
On Tue, Dec 04, 2012 at 11:28:26AM +0200, Vladimir Kondratiev wrote:
> Hi Jason,
> 
> Do you have any update on the status for patches below?
> Where is it now? When do you expect it to merge? 3.8?
> I am waiting for this to merge before I can go on
> with my driver.

*poke*

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-12-11 Thread Luis R. Rodriguez
On Tue, Dec 04, 2012 at 11:28:26AM +0200, Vladimir Kondratiev wrote:
 Hi Jason,
 
 Do you have any update on the status for patches below?
 Where is it now? When do you expect it to merge? 3.8?
 I am waiting for this to merge before I can go on
 with my driver.

*poke*

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-12-11 Thread Jason Baron
On Tue, Dec 11, 2012 at 11:36:46AM -0800, Luis R. Rodriguez wrote:
 On Tue, Dec 04, 2012 at 11:28:26AM +0200, Vladimir Kondratiev wrote:
  Hi Jason,
  
  Do you have any update on the status for patches below?
  Where is it now? When do you expect it to merge? 3.8?
  I am waiting for this to merge before I can go on
  with my driver.
 
 *poke*
 
   Luis

Hi Luis,

Yes, I posted this patch, along with 2 others last week for Greg to
pull. I believe these are too late for the 3.8 merge window. Perhaps,
Greg can comment. Here's a link to the post:

http://marc.info/?l=linux-kernelm=135474417810281w=2

Thanks,

-Jason
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-12-11 Thread Greg KH
On Tue, Dec 11, 2012 at 03:08:31PM -0500, Jason Baron wrote:
 On Tue, Dec 11, 2012 at 11:36:46AM -0800, Luis R. Rodriguez wrote:
  On Tue, Dec 04, 2012 at 11:28:26AM +0200, Vladimir Kondratiev wrote:
   Hi Jason,
   
   Do you have any update on the status for patches below?
   Where is it now? When do you expect it to merge? 3.8?
   I am waiting for this to merge before I can go on
   with my driver.
  
  *poke*
  
Luis
 
 Hi Luis,
 
 Yes, I posted this patch, along with 2 others last week for Greg to
 pull. I believe these are too late for the 3.8 merge window. Perhaps,
 Greg can comment. Here's a link to the post:
 
 http://marc.info/?l=linux-kernelm=135474417810281w=2

Yes it's too late, these will go into linux-next after 3.8-rc1 is out.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-12-11 Thread Joe Perches
On Tue, 2012-12-11 at 12:12 -0800, Greg KH wrote:
 On Tue, Dec 11, 2012 at 03:08:31PM -0500, Jason Baron wrote:
  On Tue, Dec 11, 2012 at 11:36:46AM -0800, Luis R. Rodriguez wrote:
   On Tue, Dec 04, 2012 at 11:28:26AM +0200, Vladimir Kondratiev wrote:
Hi Jason,

Do you have any update on the status for patches below?
Where is it now? When do you expect it to merge? 3.8?
I am waiting for this to merge before I can go on
with my driver.
   
   *poke*
   
 Luis
  
  Hi Luis,
  
  Yes, I posted this patch, along with 2 others last week for Greg to
  pull. I believe these are too late for the 3.8 merge window. Perhaps,
  Greg can comment. Here's a link to the post:
  
  http://marc.info/?l=linux-kernelm=135474417810281w=2
 
 Yes it's too late, these will go into linux-next after 3.8-rc1 is out.
 
 thanks,
 
 greg k-h
 

Vladimir, sorry about this.

I suggest you prefix/rename and include these functions directly into
your driver and later after 3.9 is out you could again rename the
local calls to the now generic kernel functions and delete the local
ones.

Your driver is for new hardware, so even now it should be able to
go into 3.8.

cheers, Joe

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-12-11 Thread Luis R. Rodriguez
On Tue, Dec 11, 2012 at 12:24:04PM -0800, Joe Perches wrote:
 On Tue, 2012-12-11 at 12:12 -0800, Greg KH wrote:
  On Tue, Dec 11, 2012 at 03:08:31PM -0500, Jason Baron wrote:
   On Tue, Dec 11, 2012 at 11:36:46AM -0800, Luis R. Rodriguez wrote:
On Tue, Dec 04, 2012 at 11:28:26AM +0200, Vladimir Kondratiev wrote:
 Hi Jason,
 
 Do you have any update on the status for patches below?
 Where is it now? When do you expect it to merge? 3.8?
 I am waiting for this to merge before I can go on
 with my driver.

*poke*

  Luis
   
   Hi Luis,
   
   Yes, I posted this patch, along with 2 others last week for Greg to
   pull. I believe these are too late for the 3.8 merge window. Perhaps,
   Greg can comment. Here's a link to the post:
   
   http://marc.info/?l=linux-kernelm=135474417810281w=2
  
  Yes it's too late, these will go into linux-next after 3.8-rc1 is out.
  
  thanks,
  
  greg k-h
  
 
 Vladimir, sorry about this.
 
 I suggest you prefix/rename and include these functions directly into
 your driver and later after 3.9 is out you could again rename the
 local calls to the now generic kernel functions and delete the local
 ones.

Vladimir, to be clear, you can continue with waiting for the patches
to get into 3.9 but that will take a while but given that you want
your driver in 3.8 you can fold those routines into your driver as
you had before but with a rename by adding a prefix and sumbit that
driver and specify it is for 3.8.

 Your driver is for new hardware, so even now it should be able to
 go into 3.8.

Agreed.

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-12-04 Thread Vladimir Kondratiev
Hi Jason,

Do you have any update on the status for patches below?
Where is it now? When do you expect it to merge? 3.8?
I am waiting for this to merge before I can go on
with my driver.

Thanks, Vladimir

On Tuesday, November 20, 2012 11:08:45 AM Jason Baron wrote:
> On Sun, Nov 18, 2012 at 10:35:40AM -0800, Joe Perches wrote:
> > On Sun, 2012-11-18 at 19:01 +0200, Vladimir Kondratiev wrote:
> > > In case this option wins, patch follows. There is no need for
> > > 2-nd one to fix existing drivers.
> > 
> > Thanks Vladimir.
> > 
> > 
> 
> Yes, thanks. I've pulled in this patch, and posted a dynamic debug tree
> at: git clone git://github.com/jibaron/ddebug.git
> 
> I will push the collected set of patches to Greg.
> 
> I also added a couple of patches there to convert dynamic debug to use
> 'jump labels', which shows good results.
> 
> Thanks,
> 
> -Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-12-04 Thread Vladimir Kondratiev
Hi Jason,

Do you have any update on the status for patches below?
Where is it now? When do you expect it to merge? 3.8?
I am waiting for this to merge before I can go on
with my driver.

Thanks, Vladimir

On Tuesday, November 20, 2012 11:08:45 AM Jason Baron wrote:
 On Sun, Nov 18, 2012 at 10:35:40AM -0800, Joe Perches wrote:
  On Sun, 2012-11-18 at 19:01 +0200, Vladimir Kondratiev wrote:
   In case this option wins, patch follows. There is no need for
   2-nd one to fix existing drivers.
  
  Thanks Vladimir.
  
  
 
 Yes, thanks. I've pulled in this patch, and posted a dynamic debug tree
 at: git clone git://github.com/jibaron/ddebug.git
 
 I will push the collected set of patches to Greg.
 
 I also added a couple of patches there to convert dynamic debug to use
 'jump labels', which shows good results.
 
 Thanks,
 
 -Jason
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-20 Thread Jason Baron
On Sun, Nov 18, 2012 at 10:35:40AM -0800, Joe Perches wrote:
> On Sun, 2012-11-18 at 19:01 +0200, Vladimir Kondratiev wrote:
> > In case this option wins, patch follows. There is no need for
> > 2-nd one to fix existing drivers.
> 
> Thanks Vladimir.
> 
> 

Yes, thanks. I've pulled in this patch, and posted a dynamic debug tree
at: git clone git://github.com/jibaron/ddebug.git

I will push the collected set of patches to Greg.

I also added a couple of patches there to convert dynamic debug to use
'jump labels', which shows good results.

Thanks,

-Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-20 Thread Jason Baron
On Sun, Nov 18, 2012 at 10:35:40AM -0800, Joe Perches wrote:
 On Sun, 2012-11-18 at 19:01 +0200, Vladimir Kondratiev wrote:
  In case this option wins, patch follows. There is no need for
  2-nd one to fix existing drivers.
 
 Thanks Vladimir.
 
 

Yes, thanks. I've pulled in this patch, and posted a dynamic debug tree
at: git clone git://github.com/jibaron/ddebug.git

I will push the collected set of patches to Greg.

I also added a couple of patches there to convert dynamic debug to use
'jump labels', which shows good results.

Thanks,

-Jason
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-18 Thread Joe Perches
On Sun, 2012-11-18 at 19:01 +0200, Vladimir Kondratiev wrote:
> In case this option wins, patch follows. There is no need for
> 2-nd one to fix existing drivers.

Thanks Vladimir.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-18 Thread Vladimir Kondratiev
On Sunday, November 18, 2012 05:43:07 PM Vladimir Kondratiev wrote:
> On Sunday, November 18, 2012 06:38:51 AM Joe Perches wrote:
> > Another option could be testing __builtin_constant_p(prefix)
> 
> You mean something like below? Yes, it will work as well.
> 
> Pro: don't need to change existing code
> (drop [PATCH 2/2] dynamic_debug: use constant format in
> print_hex_dump_bytes())
> 
> Cons: format in dynamic metadata will be useless
> 
> What looks better?
> 
> ---
> #define dynamic_hex_dump(prefix_str, prefix_type, rowsize,\
>groupsize, buf, len, ascii)\
> do {  \
>   DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \
>   __builtin_constant_p(prefix_str) ? prefix_str : "hexdump");\
>   if (unlikely(descriptor.flags & _DPRINTK_FLAGS_PRINT))  \
>   print_hex_dump(KERN_DEBUG, prefix_str,  \
>  prefix_type, rowsize, groupsize, \
>  buf, len, ascii);\
> } while (0)

In case this option wins, patch follows. There is no need for
2-nd one to fix existing drivers.


>From 42bea6be2b3899eac1ed3f48eb955a4d83960cf5 Mon Sep 17 00:00:00 2001
From: Vladimir Kondratiev 
Date: Sun, 18 Nov 2012 18:56:29 +0200
Subject: [PATCH] dynamic_debug: dynamic hex dump

Introduce print_hex_dump_debug() that can be dynamically controlled, similar to
pr_debug.

Also, make print_hex_dump_bytes() dynamically controlled

Implement only 'p' flag (_DPRINTK_FLAGS_PRINT) to keep it simple since hex dump 
prints
multiple lines and long prefix would impact readability.
To provide line/file etc. information, use pr_debug or similar
before/after print_hex_dump_debug()

Signed-off-by: Vladimir Kondratiev 
---
 Documentation/dynamic-debug-howto.txt |   15 +--
 include/linux/dynamic_debug.h |   11 +++
 include/linux/printk.h|   17 +
 lib/hexdump.c |4 +++-
 4 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/Documentation/dynamic-debug-howto.txt 
b/Documentation/dynamic-debug-howto.txt
index 6e16849..72322c6 100644
--- a/Documentation/dynamic-debug-howto.txt
+++ b/Documentation/dynamic-debug-howto.txt
@@ -6,8 +6,16 @@ This document describes how to use the dynamic debug (dyndbg) 
feature.
 
 Dynamic debug is designed to allow you to dynamically enable/disable
 kernel code to obtain additional kernel information.  Currently, if
-CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() calls can
-be dynamically enabled per-callsite.
+CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() and
+print_hex_dump_debug()/print_hex_dump_bytes() calls can be dynamically
+enabled per-callsite.
+
+If CONFIG_DYNAMIC_DEBUG is not set, print_hex_dump_debug() is just
+shortcut for print_hex_dump(KERN_DEBUG).
+
+For print_hex_dump_debug()/print_hex_dump_bytes(), format string is
+its 'prefix_str' argument, if it is constant string; or "hexdump"
+in case 'prefix_str' is build dynamically.
 
 Dynamic debug has even more useful features:
 
@@ -202,6 +210,9 @@ The flags are:
   tInclude thread ID in messages not generated from interrupt context
   _No flags are set. (Or'd with others on input)
 
+For print_hex_dump_debug() and print_hex_dump_bytes(), only 'p' flag
+have meaning, other flags ignored.
+
 For display, the flags are preceded by '='
 (mnemonic: what the flags are currently equal to).
 
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 6dd4787..2fe93b2 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -95,6 +95,17 @@ do { 
\
 ##__VA_ARGS__);\
 } while (0)
 
+#define dynamic_hex_dump(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)\
+do {   \
+   DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \
+   __builtin_constant_p(prefix_str) ? prefix_str : "hexdump");\
+   if (unlikely(descriptor.flags & _DPRINTK_FLAGS_PRINT))  \
+   print_hex_dump(KERN_DEBUG, prefix_str,  \
+  prefix_type, rowsize, groupsize, \
+  buf, len, ascii);\
+} while (0)
+
 #else
 
 #include 
diff --git a/include/linux/printk.h b/include/linux/printk.h
index 9afc01e..02c95cf 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -321,8 +321,13 @@ extern void hex_dump_to_buffer(const void *buf, size_t len,
 extern void print_hex_dump(const char *level, const char *prefix_str,
   int prefix_type, int rowsize, int groupsize,
   const void *buf, size_t len, bool ascii);
+#if defined(CONFIG_DYNAMIC_DEBUG)
+#define 

Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-18 Thread Vladimir Kondratiev
On Sunday, November 18, 2012 06:38:51 AM Joe Perches wrote:
> Another option could be testing __builtin_constant_p(prefix)

You mean something like below? Yes, it will work as well.

Pro: don't need to change existing code 
(drop [PATCH 2/2] dynamic_debug: use constant format in print_hex_dump_bytes())

Cons: format in dynamic metadata will be useless

What looks better?

---
#define dynamic_hex_dump(prefix_str, prefix_type, rowsize,  \
 groupsize, buf, len, ascii)\
do {\
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \
__builtin_constant_p(prefix_str) ? prefix_str : "hexdump");\
if (unlikely(descriptor.flags & _DPRINTK_FLAGS_PRINT))  \
print_hex_dump(KERN_DEBUG, prefix_str,  \
   prefix_type, rowsize, groupsize, \
   buf, len, ascii);\
} while (0)



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-18 Thread Joe Perches
On Sun, 2012-11-18 at 11:47 +0200, Vladimir Kondratiev wrote:
> I see 2 drivers that use dynamic prefix:
> 
> - mentioned above drivers/tty/ipwireless/hardware.c
> - drivers/isdn/hardware/mISDN/
> 
> I see several options:
> 
> 1) require prefix_str to be constant. Patch code mentioned. For example,
> code above may reads:
> 
> static void dump_data_bytes(const char *type, const unsigned char *data,
>   unsigned length)
> {
>   pr_debug(IPWIRELESS_PCCARD_NAME ": %s %s\n",
>   type, data_type(data, length));
>   print_hex_dump_bytes(IPWIRELESS_PCCARD_NAME, 0, (void *)data,
>   length < DUMP_MAX_BYTES ? length : DUMP_MAX_BYTES);
> }
> 
> 2) introduce fixed format string in DEFINE_DYNAMIC_DEBUG_METADATA, like
> 
> DEFINE_DYNAMIC_DEBUG_METADATA((descriptor, "hexdump");
> 
> 3) remove print_hex_dump_bytes from this patch
> 
> I think 1) is the best, opinions?

Another option could be testing __builtin_constant_p(prefix)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-18 Thread Vladimir Kondratiev
On Sunday, November 18, 2012 11:47:58 AM Vladimir Kondratiev wrote:
> On Wednesday, November 14, 2012 07:27:47 PM Vladimir Kondratiev wrote:
> > +#define dynamic_hex_dump(prefix_str, prefix_type, rowsize, \
> > +groupsize, buf, len, ascii)\
> > +do {   \
> > +   DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, prefix_str);  \
> > +   if (unlikely(descriptor.flags & _DPRINTK_FLAGS_PRINT))  \
> > +   print_hex_dump(KERN_DEBUG, prefix_str,  \
> > +  prefix_type, rowsize, groupsize, \
> > +  buf, len, ascii);\
> > +} while (0)
> 
> There is some problem with the code above. There are existing drivers
> that use print_hex_dump_bytes() with the prefix_str built dynamically,
> like this (see drivers/tty/ipwireless/hardware.c:362)
> 
> static void dump_data_bytes(const char *type, const unsigned char *data,
>   unsigned length)
> {
>   char prefix[56];
> 
>   sprintf(prefix, IPWIRELESS_PCCARD_NAME ": %s %s ",
>   type, data_type(data, length));
>   print_hex_dump_bytes(prefix, 0, (void *)data,
>   length < DUMP_MAX_BYTES ? length : DUMP_MAX_BYTES);
> }
> 
> In this case, prefix_str is not constant, and this solution will not
> work.
> 
> I see 2 drivers that use dynamic prefix:
> 
> - mentioned above drivers/tty/ipwireless/hardware.c
> - drivers/isdn/hardware/mISDN/
> 
> I see several options:
> 
> 1) require prefix_str to be constant. Patch code mentioned. For example,
> code above may reads:
> 
> static void dump_data_bytes(const char *type, const unsigned char *data,
>   unsigned length)
> {
>   pr_debug(IPWIRELESS_PCCARD_NAME ": %s %s\n",
>   type, data_type(data, length));
>   print_hex_dump_bytes(IPWIRELESS_PCCARD_NAME, 0, (void *)data,
>   length < DUMP_MAX_BYTES ? length : DUMP_MAX_BYTES);
> }
> 
> 2) introduce fixed format string in DEFINE_DYNAMIC_DEBUG_METADATA, like
> 
> DEFINE_DYNAMIC_DEBUG_METADATA((descriptor, "hexdump");
> 
> 3) remove print_hex_dump_bytes from this patch
> 
> I think 1) is the best, opinions?
> 
> Thanks, Vladimir

In case of option 1), patches follows. Note there is change in the initial 
patch as well (I forgot to exclude print_hex_dump_bytes() from compilation in 
hexdump.c. Please, comment.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-18 Thread Vladimir Kondratiev
On Sunday, November 18, 2012 11:47:58 AM Vladimir Kondratiev wrote:
 On Wednesday, November 14, 2012 07:27:47 PM Vladimir Kondratiev wrote:
  +#define dynamic_hex_dump(prefix_str, prefix_type, rowsize, \
  +groupsize, buf, len, ascii)\
  +do {   \
  +   DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, prefix_str);  \
  +   if (unlikely(descriptor.flags  _DPRINTK_FLAGS_PRINT))  \
  +   print_hex_dump(KERN_DEBUG, prefix_str,  \
  +  prefix_type, rowsize, groupsize, \
  +  buf, len, ascii);\
  +} while (0)
 
 There is some problem with the code above. There are existing drivers
 that use print_hex_dump_bytes() with the prefix_str built dynamically,
 like this (see drivers/tty/ipwireless/hardware.c:362)
 
 static void dump_data_bytes(const char *type, const unsigned char *data,
   unsigned length)
 {
   char prefix[56];
 
   sprintf(prefix, IPWIRELESS_PCCARD_NAME : %s %s ,
   type, data_type(data, length));
   print_hex_dump_bytes(prefix, 0, (void *)data,
   length  DUMP_MAX_BYTES ? length : DUMP_MAX_BYTES);
 }
 
 In this case, prefix_str is not constant, and this solution will not
 work.
 
 I see 2 drivers that use dynamic prefix:
 
 - mentioned above drivers/tty/ipwireless/hardware.c
 - drivers/isdn/hardware/mISDN/
 
 I see several options:
 
 1) require prefix_str to be constant. Patch code mentioned. For example,
 code above may reads:
 
 static void dump_data_bytes(const char *type, const unsigned char *data,
   unsigned length)
 {
   pr_debug(IPWIRELESS_PCCARD_NAME : %s %s\n,
   type, data_type(data, length));
   print_hex_dump_bytes(IPWIRELESS_PCCARD_NAME, 0, (void *)data,
   length  DUMP_MAX_BYTES ? length : DUMP_MAX_BYTES);
 }
 
 2) introduce fixed format string in DEFINE_DYNAMIC_DEBUG_METADATA, like
 
 DEFINE_DYNAMIC_DEBUG_METADATA((descriptor, hexdump);
 
 3) remove print_hex_dump_bytes from this patch
 
 I think 1) is the best, opinions?
 
 Thanks, Vladimir

In case of option 1), patches follows. Note there is change in the initial 
patch as well (I forgot to exclude print_hex_dump_bytes() from compilation in 
hexdump.c. Please, comment.


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-18 Thread Joe Perches
On Sun, 2012-11-18 at 11:47 +0200, Vladimir Kondratiev wrote:
 I see 2 drivers that use dynamic prefix:
 
 - mentioned above drivers/tty/ipwireless/hardware.c
 - drivers/isdn/hardware/mISDN/
 
 I see several options:
 
 1) require prefix_str to be constant. Patch code mentioned. For example,
 code above may reads:
 
 static void dump_data_bytes(const char *type, const unsigned char *data,
   unsigned length)
 {
   pr_debug(IPWIRELESS_PCCARD_NAME : %s %s\n,
   type, data_type(data, length));
   print_hex_dump_bytes(IPWIRELESS_PCCARD_NAME, 0, (void *)data,
   length  DUMP_MAX_BYTES ? length : DUMP_MAX_BYTES);
 }
 
 2) introduce fixed format string in DEFINE_DYNAMIC_DEBUG_METADATA, like
 
 DEFINE_DYNAMIC_DEBUG_METADATA((descriptor, hexdump);
 
 3) remove print_hex_dump_bytes from this patch
 
 I think 1) is the best, opinions?

Another option could be testing __builtin_constant_p(prefix)


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-18 Thread Vladimir Kondratiev
On Sunday, November 18, 2012 06:38:51 AM Joe Perches wrote:
 Another option could be testing __builtin_constant_p(prefix)

You mean something like below? Yes, it will work as well.

Pro: don't need to change existing code 
(drop [PATCH 2/2] dynamic_debug: use constant format in print_hex_dump_bytes())

Cons: format in dynamic metadata will be useless

What looks better?

---
#define dynamic_hex_dump(prefix_str, prefix_type, rowsize,  \
 groupsize, buf, len, ascii)\
do {\
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \
__builtin_constant_p(prefix_str) ? prefix_str : hexdump);\
if (unlikely(descriptor.flags  _DPRINTK_FLAGS_PRINT))  \
print_hex_dump(KERN_DEBUG, prefix_str,  \
   prefix_type, rowsize, groupsize, \
   buf, len, ascii);\
} while (0)



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-18 Thread Vladimir Kondratiev
On Sunday, November 18, 2012 05:43:07 PM Vladimir Kondratiev wrote:
 On Sunday, November 18, 2012 06:38:51 AM Joe Perches wrote:
  Another option could be testing __builtin_constant_p(prefix)
 
 You mean something like below? Yes, it will work as well.
 
 Pro: don't need to change existing code
 (drop [PATCH 2/2] dynamic_debug: use constant format in
 print_hex_dump_bytes())
 
 Cons: format in dynamic metadata will be useless
 
 What looks better?
 
 ---
 #define dynamic_hex_dump(prefix_str, prefix_type, rowsize,\
groupsize, buf, len, ascii)\
 do {  \
   DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \
   __builtin_constant_p(prefix_str) ? prefix_str : hexdump);\
   if (unlikely(descriptor.flags  _DPRINTK_FLAGS_PRINT))  \
   print_hex_dump(KERN_DEBUG, prefix_str,  \
  prefix_type, rowsize, groupsize, \
  buf, len, ascii);\
 } while (0)

In case this option wins, patch follows. There is no need for
2-nd one to fix existing drivers.


From 42bea6be2b3899eac1ed3f48eb955a4d83960cf5 Mon Sep 17 00:00:00 2001
From: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com
Date: Sun, 18 Nov 2012 18:56:29 +0200
Subject: [PATCH] dynamic_debug: dynamic hex dump

Introduce print_hex_dump_debug() that can be dynamically controlled, similar to
pr_debug.

Also, make print_hex_dump_bytes() dynamically controlled

Implement only 'p' flag (_DPRINTK_FLAGS_PRINT) to keep it simple since hex dump 
prints
multiple lines and long prefix would impact readability.
To provide line/file etc. information, use pr_debug or similar
before/after print_hex_dump_debug()

Signed-off-by: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com
---
 Documentation/dynamic-debug-howto.txt |   15 +--
 include/linux/dynamic_debug.h |   11 +++
 include/linux/printk.h|   17 +
 lib/hexdump.c |4 +++-
 4 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/Documentation/dynamic-debug-howto.txt 
b/Documentation/dynamic-debug-howto.txt
index 6e16849..72322c6 100644
--- a/Documentation/dynamic-debug-howto.txt
+++ b/Documentation/dynamic-debug-howto.txt
@@ -6,8 +6,16 @@ This document describes how to use the dynamic debug (dyndbg) 
feature.
 
 Dynamic debug is designed to allow you to dynamically enable/disable
 kernel code to obtain additional kernel information.  Currently, if
-CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() calls can
-be dynamically enabled per-callsite.
+CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() and
+print_hex_dump_debug()/print_hex_dump_bytes() calls can be dynamically
+enabled per-callsite.
+
+If CONFIG_DYNAMIC_DEBUG is not set, print_hex_dump_debug() is just
+shortcut for print_hex_dump(KERN_DEBUG).
+
+For print_hex_dump_debug()/print_hex_dump_bytes(), format string is
+its 'prefix_str' argument, if it is constant string; or hexdump
+in case 'prefix_str' is build dynamically.
 
 Dynamic debug has even more useful features:
 
@@ -202,6 +210,9 @@ The flags are:
   tInclude thread ID in messages not generated from interrupt context
   _No flags are set. (Or'd with others on input)
 
+For print_hex_dump_debug() and print_hex_dump_bytes(), only 'p' flag
+have meaning, other flags ignored.
+
 For display, the flags are preceded by '='
 (mnemonic: what the flags are currently equal to).
 
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 6dd4787..2fe93b2 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -95,6 +95,17 @@ do { 
\
 ##__VA_ARGS__);\
 } while (0)
 
+#define dynamic_hex_dump(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)\
+do {   \
+   DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \
+   __builtin_constant_p(prefix_str) ? prefix_str : hexdump);\
+   if (unlikely(descriptor.flags  _DPRINTK_FLAGS_PRINT))  \
+   print_hex_dump(KERN_DEBUG, prefix_str,  \
+  prefix_type, rowsize, groupsize, \
+  buf, len, ascii);\
+} while (0)
+
 #else
 
 #include linux/string.h
diff --git a/include/linux/printk.h b/include/linux/printk.h
index 9afc01e..02c95cf 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -321,8 +321,13 @@ extern void hex_dump_to_buffer(const void *buf, size_t len,
 extern void print_hex_dump(const char *level, const char *prefix_str,
   int prefix_type, int rowsize, int groupsize,
   const void *buf, size_t len, bool ascii);
+#if 

Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-18 Thread Joe Perches
On Sun, 2012-11-18 at 19:01 +0200, Vladimir Kondratiev wrote:
 In case this option wins, patch follows. There is no need for
 2-nd one to fix existing drivers.

Thanks Vladimir.


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-14 Thread Vladimir Kondratiev
On Wednesday, November 14, 2012 09:08:52 AM Joe Perches wrote:
> On Wed, 2012-11-14 at 18:18 +0200, Vladimir Kondratiev wrote:
> > And, here it goes (can I call it PATCH?):
> Don't see why not.
> 
> > From: Vladimir Kondratiev 
> 
> []
> 
> > Introduce debug_hex_dump() that can be dynamically controlled, similar to
> > pr_debug.
> > 
> > Also, make print_hex_dump_bytes() dynamically controlled
> 
> print_hex_dump_debug might be a better name than
> debug_hex_dump because it's more similar to the other
> print_hex_dump<_foo> names.

Well, let it be:

>From 5c9a79ea32e300f9a228d659f325e30d450b57c1 Mon Sep 17 00:00:00 2001
From: Vladimir Kondratiev 
Date: Wed, 14 Nov 2012 19:24:51 +0200
Subject: [PATCH] dynamic_debug: dynamic hex dump

Introduce print_hex_dump_debug() that can be dynamically controlled, similar to
pr_debug.

Also, make print_hex_dump_bytes() dynamically controlled

Implement only 'p' flag (_DPRINTK_FLAGS_PRINT) to keep it simple since hex dump 
prints
multiple lines and long prefix would impact readability.
To provide line/file etc. information, use pr_debug or similar
before/after print_hex_dump_debug()

Signed-off-by: Vladimir Kondratiev 
---
 Documentation/dynamic-debug-howto.txt |   11 +--
 include/linux/dynamic_debug.h |   10 ++
 include/linux/printk.h|   17 +
 3 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/Documentation/dynamic-debug-howto.txt 
b/Documentation/dynamic-debug-howto.txt
index 6e16849..b39a771 100644
--- a/Documentation/dynamic-debug-howto.txt
+++ b/Documentation/dynamic-debug-howto.txt
@@ -6,8 +6,12 @@ This document describes how to use the dynamic debug (dyndbg) 
feature.
 
 Dynamic debug is designed to allow you to dynamically enable/disable
 kernel code to obtain additional kernel information.  Currently, if
-CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() calls can
-be dynamically enabled per-callsite.
+CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() and
+print_hex_dump_debug()/print_hex_dump_bytes() calls can be dynamically
+enabled per-callsite.
+
+If CONFIG_DYNAMIC_DEBUG is not set, print_hex_dump_debug() is just
+shortcut for print_hex_dump(KERN_DEBUG).
 
 Dynamic debug has even more useful features:
 
@@ -202,6 +206,9 @@ The flags are:
   tInclude thread ID in messages not generated from interrupt context
   _No flags are set. (Or'd with others on input)
 
+For print_hex_dump_debug() and print_hex_dump_bytes(), only 'p' flag
+have meaning, other flags ignored.
+
 For display, the flags are preceded by '='
 (mnemonic: what the flags are currently equal to).
 
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 6dd4787..17565ab 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -95,6 +95,16 @@ do { 
\
 ##__VA_ARGS__);\
 } while (0)
 
+#define dynamic_hex_dump(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)\
+do {   \
+   DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, prefix_str);  \
+   if (unlikely(descriptor.flags & _DPRINTK_FLAGS_PRINT))  \
+   print_hex_dump(KERN_DEBUG, prefix_str,  \
+  prefix_type, rowsize, groupsize, \
+  buf, len, ascii);\
+} while (0)
+
 #else
 
 #include 
diff --git a/include/linux/printk.h b/include/linux/printk.h
index 9afc01e..02c95cf 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -321,8 +321,13 @@ extern void hex_dump_to_buffer(const void *buf, size_t len,
 extern void print_hex_dump(const char *level, const char *prefix_str,
   int prefix_type, int rowsize, int groupsize,
   const void *buf, size_t len, bool ascii);
+#if defined(CONFIG_DYNAMIC_DEBUG)
+#define print_hex_dump_bytes(prefix_str, prefix_type, buf, len)\
+   dynamic_hex_dump(prefix_str, prefix_type, 16, 1, buf, len, true)
+#else
 extern void print_hex_dump_bytes(const char *prefix_str, int prefix_type,
 const void *buf, size_t len);
+#endif /* defined(CONFIG_DYNAMIC_DEBUG) */
 #else
 static inline void print_hex_dump(const char *level, const char *prefix_str,
  int prefix_type, int rowsize, int groupsize,
@@ -336,4 +341,16 @@ static inline void print_hex_dump_bytes(const char 
*prefix_str, int prefix_type,
 
 #endif
 
+#if defined(CONFIG_DYNAMIC_DEBUG)
+#define print_hex_dump_debug(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)\
+   dynamic_hex_dump(prefix_str, prefix_type, rowsize,  \
+groupsize, buf, len, ascii)
+#else
+#define print_hex_dump_debug(prefix_str, prefix_type, 

Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-14 Thread Joe Perches
On Wed, 2012-11-14 at 18:18 +0200, Vladimir Kondratiev wrote:
> And, here it goes (can I call it PATCH?):

Don't see why not.

> From: Vladimir Kondratiev 
[]
> Introduce debug_hex_dump() that can be dynamically controlled, similar to
> pr_debug.
> 
> Also, make print_hex_dump_bytes() dynamically controlled

print_hex_dump_debug might be a better name than
debug_hex_dump because it's more similar to the other
print_hex_dump<_foo> names.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-14 Thread Vladimir Kondratiev
On Wednesday, November 14, 2012 05:41:08 AM Joe Perches wrote:
> On Wed, 2012-11-14 at 14:17 +0200, Vladimir Kondratiev wrote:
> > Introduce debug_hex_dump() that can be dynamically controlled, similar to
> > pr_debug.
> 
> (added Jason Baron, Jim Cromie, GregKH and lkml to cc's)
> 
> []
> 
> > diff --git a/include/linux/printk.h b/include/linux/printk.h
> 
> []
> 
> > @@ -220,6 +220,20 @@ extern void dump_stack(void) __cold;
> > 
> > no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
> >  
> >  #endifD
> > 
> > +#if defined(CONFIG_DYNAMIC_DEBUG)
> > +#define debug_hex_dump(prefix_str, prefix_type, rowsize,   \
> > +  groupsize, buf, len, ascii)  \
> > +  dynamic_hex_dump(prefix_str, prefix_type,\
> > +   rowsize, groupsize, buf,\
> > +   len, ascii)
> > +#else
> > +#define debug_hex_dump(prefix_str, prefix_type, rowsize,   \
> > +  groupsize, buf, len, ascii)  \
> > +  print_hex_dump(KERN_DEBUG, prefix_str,   \
> > + prefix_type, rowsize, \
> > + groupsize, buf, len, ascii)
> > +#endif
> 
> These should be in a different location after print_hex_dump
> is declared. Also for #defines, the indentation doesn't
> need to be so deep.

Ups, correct.

> 
> #if defined(CONFIG_DYNAMIC_DEBUG)
> #define debug_hex_dump(prefix_str, prefix_type, rowsize,  \
>  groupsize, buf, len, ascii)  \
>   dynamic_hex_dump(prefix_str, prefix_type,   \
>rowsize, groupsize, buf, len, ascii)
> #else
> #define debug_hex_dump(prefix_str, prefix_type, rowsize,  \
>  groupsize, buf, len, ascii)  \
>   print_hex_dump(KERN_DEBUG, prefix_str, prefix_type, \
>  rowsize, groupsize, buf, len, ascii)
> #endif
> 
> A better option might be to convert print_hex_dump_bytes()
> to dynamic_debug as that's already KERN_DEBUG.  That
> could be simpler overall and it makes existing calls
> become dynamic as well.

And, here it goes (can I call it PATCH?):

>From 755b74861b66435bfe4875b64a53c45bbe172495 Mon Sep 17 00:00:00 2001
From: Vladimir Kondratiev 
Date: Wed, 14 Nov 2012 18:14:15 +0200
Subject: [PATCH] dynamic_debug: dynamic hex dump

Introduce debug_hex_dump() that can be dynamically controlled, similar to
pr_debug.

Also, make print_hex_dump_bytes() dynamically controlled

Implement only 'p' flag (_DPRINTK_FLAGS_PRINT) to keep it simple since hex dump 
prints
multiple lines and long prefix would impact readability.
To provide line/file etc. information, use pr_debug or similar
before/after debug_hex_dump()

Signed-off-by: Vladimir Kondratiev 
---
 Documentation/dynamic-debug-howto.txt |   11 +--
 include/linux/dynamic_debug.h |   10 ++
 include/linux/printk.h|   17 +
 3 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/Documentation/dynamic-debug-howto.txt 
b/Documentation/dynamic-debug-howto.txt
index 6e16849..cec98f8 100644
--- a/Documentation/dynamic-debug-howto.txt
+++ b/Documentation/dynamic-debug-howto.txt
@@ -6,8 +6,12 @@ This document describes how to use the dynamic debug (dyndbg) 
feature.
 
 Dynamic debug is designed to allow you to dynamically enable/disable
 kernel code to obtain additional kernel information.  Currently, if
-CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() calls can
-be dynamically enabled per-callsite.
+CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() and
+debug_hex_dump()/print_hex_dump_bytes() calls can be dynamically
+enabled per-callsite.
+
+If CONFIG_DYNAMIC_DEBUG is not set, debug_hex_dump() is just shortcut
+for print_hex_dump(KERN_DEBUG).
 
 Dynamic debug has even more useful features:
 
@@ -202,6 +206,9 @@ The flags are:
   tInclude thread ID in messages not generated from interrupt context
   _No flags are set. (Or'd with others on input)
 
+For debug_hex_dump() and print_hex_dump_bytes(), only 'p' flag have meaning,
+other flags ignored.
+
 For display, the flags are preceded by '='
 (mnemonic: what the flags are currently equal to).
 
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 6dd4787..17565ab 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -95,6 +95,16 @@ do { 
\
 ##__VA_ARGS__);\
 } while (0)
 
+#define dynamic_hex_dump(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)\
+do {   \
+   DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, prefix_str);  \
+   if (unlikely(descriptor.flags & _DPRINTK_FLAGS_PRINT))  \
+   print_hex_dump(KERN_DEBUG, prefix_str,   

Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-14 Thread Joe Perches
On Wed, 2012-11-14 at 14:17 +0200, Vladimir Kondratiev wrote:
> Introduce debug_hex_dump() that can be dynamically controlled, similar to
> pr_debug.

(added Jason Baron, Jim Cromie, GregKH and lkml to cc's)

[]
> diff --git a/include/linux/printk.h b/include/linux/printk.h
[]
> @@ -220,6 +220,20 @@ extern void dump_stack(void) __cold;
>   no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
>  #endifD
>  
> +#if defined(CONFIG_DYNAMIC_DEBUG)
> +#define debug_hex_dump(prefix_str, prefix_type, rowsize, \
> +groupsize, buf, len, ascii)  \
> +dynamic_hex_dump(prefix_str, prefix_type,\
> + rowsize, groupsize, buf,\
> + len, ascii)
> +#else
> +#define debug_hex_dump(prefix_str, prefix_type, rowsize, \
> +groupsize, buf, len, ascii)  \
> +print_hex_dump(KERN_DEBUG, prefix_str,   \
> +   prefix_type, rowsize, \
> +   groupsize, buf, len, ascii)
> +#endif

These should be in a different location after print_hex_dump
is declared. Also for #defines, the indentation doesn't
need to be so deep.

#if defined(CONFIG_DYNAMIC_DEBUG)
#define debug_hex_dump(prefix_str, prefix_type, rowsize,\
   groupsize, buf, len, ascii)  \
dynamic_hex_dump(prefix_str, prefix_type,   \
 rowsize, groupsize, buf, len, ascii)
#else
#define debug_hex_dump(prefix_str, prefix_type, rowsize,\
   groupsize, buf, len, ascii)  \
print_hex_dump(KERN_DEBUG, prefix_str, prefix_type, \
   rowsize, groupsize, buf, len, ascii)
#endif

A better option might be to convert print_hex_dump_bytes()
to dynamic_debug as that's already KERN_DEBUG.  That
could be simpler overall and it makes existing calls
become dynamic as well.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-14 Thread Joe Perches
On Wed, 2012-11-14 at 14:17 +0200, Vladimir Kondratiev wrote:
 Introduce debug_hex_dump() that can be dynamically controlled, similar to
 pr_debug.

(added Jason Baron, Jim Cromie, GregKH and lkml to cc's)

[]
 diff --git a/include/linux/printk.h b/include/linux/printk.h
[]
 @@ -220,6 +220,20 @@ extern void dump_stack(void) __cold;
   no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
  #endifD
  
 +#if defined(CONFIG_DYNAMIC_DEBUG)
 +#define debug_hex_dump(prefix_str, prefix_type, rowsize, \
 +groupsize, buf, len, ascii)  \
 +dynamic_hex_dump(prefix_str, prefix_type,\
 + rowsize, groupsize, buf,\
 + len, ascii)
 +#else
 +#define debug_hex_dump(prefix_str, prefix_type, rowsize, \
 +groupsize, buf, len, ascii)  \
 +print_hex_dump(KERN_DEBUG, prefix_str,   \
 +   prefix_type, rowsize, \
 +   groupsize, buf, len, ascii)
 +#endif

These should be in a different location after print_hex_dump
is declared. Also for #defines, the indentation doesn't
need to be so deep.

#if defined(CONFIG_DYNAMIC_DEBUG)
#define debug_hex_dump(prefix_str, prefix_type, rowsize,\
   groupsize, buf, len, ascii)  \
dynamic_hex_dump(prefix_str, prefix_type,   \
 rowsize, groupsize, buf, len, ascii)
#else
#define debug_hex_dump(prefix_str, prefix_type, rowsize,\
   groupsize, buf, len, ascii)  \
print_hex_dump(KERN_DEBUG, prefix_str, prefix_type, \
   rowsize, groupsize, buf, len, ascii)
#endif

A better option might be to convert print_hex_dump_bytes()
to dynamic_debug as that's already KERN_DEBUG.  That
could be simpler overall and it makes existing calls
become dynamic as well.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-14 Thread Vladimir Kondratiev
On Wednesday, November 14, 2012 05:41:08 AM Joe Perches wrote:
 On Wed, 2012-11-14 at 14:17 +0200, Vladimir Kondratiev wrote:
  Introduce debug_hex_dump() that can be dynamically controlled, similar to
  pr_debug.
 
 (added Jason Baron, Jim Cromie, GregKH and lkml to cc's)
 
 []
 
  diff --git a/include/linux/printk.h b/include/linux/printk.h
 
 []
 
  @@ -220,6 +220,20 @@ extern void dump_stack(void) __cold;
  
  no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
   
   #endifD
  
  +#if defined(CONFIG_DYNAMIC_DEBUG)
  +#define debug_hex_dump(prefix_str, prefix_type, rowsize,   \
  +  groupsize, buf, len, ascii)  \
  +  dynamic_hex_dump(prefix_str, prefix_type,\
  +   rowsize, groupsize, buf,\
  +   len, ascii)
  +#else
  +#define debug_hex_dump(prefix_str, prefix_type, rowsize,   \
  +  groupsize, buf, len, ascii)  \
  +  print_hex_dump(KERN_DEBUG, prefix_str,   \
  + prefix_type, rowsize, \
  + groupsize, buf, len, ascii)
  +#endif
 
 These should be in a different location after print_hex_dump
 is declared. Also for #defines, the indentation doesn't
 need to be so deep.

Ups, correct.

 
 #if defined(CONFIG_DYNAMIC_DEBUG)
 #define debug_hex_dump(prefix_str, prefix_type, rowsize,  \
  groupsize, buf, len, ascii)  \
   dynamic_hex_dump(prefix_str, prefix_type,   \
rowsize, groupsize, buf, len, ascii)
 #else
 #define debug_hex_dump(prefix_str, prefix_type, rowsize,  \
  groupsize, buf, len, ascii)  \
   print_hex_dump(KERN_DEBUG, prefix_str, prefix_type, \
  rowsize, groupsize, buf, len, ascii)
 #endif
 
 A better option might be to convert print_hex_dump_bytes()
 to dynamic_debug as that's already KERN_DEBUG.  That
 could be simpler overall and it makes existing calls
 become dynamic as well.

And, here it goes (can I call it PATCH?):

From 755b74861b66435bfe4875b64a53c45bbe172495 Mon Sep 17 00:00:00 2001
From: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com
Date: Wed, 14 Nov 2012 18:14:15 +0200
Subject: [PATCH] dynamic_debug: dynamic hex dump

Introduce debug_hex_dump() that can be dynamically controlled, similar to
pr_debug.

Also, make print_hex_dump_bytes() dynamically controlled

Implement only 'p' flag (_DPRINTK_FLAGS_PRINT) to keep it simple since hex dump 
prints
multiple lines and long prefix would impact readability.
To provide line/file etc. information, use pr_debug or similar
before/after debug_hex_dump()

Signed-off-by: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com
---
 Documentation/dynamic-debug-howto.txt |   11 +--
 include/linux/dynamic_debug.h |   10 ++
 include/linux/printk.h|   17 +
 3 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/Documentation/dynamic-debug-howto.txt 
b/Documentation/dynamic-debug-howto.txt
index 6e16849..cec98f8 100644
--- a/Documentation/dynamic-debug-howto.txt
+++ b/Documentation/dynamic-debug-howto.txt
@@ -6,8 +6,12 @@ This document describes how to use the dynamic debug (dyndbg) 
feature.
 
 Dynamic debug is designed to allow you to dynamically enable/disable
 kernel code to obtain additional kernel information.  Currently, if
-CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() calls can
-be dynamically enabled per-callsite.
+CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() and
+debug_hex_dump()/print_hex_dump_bytes() calls can be dynamically
+enabled per-callsite.
+
+If CONFIG_DYNAMIC_DEBUG is not set, debug_hex_dump() is just shortcut
+for print_hex_dump(KERN_DEBUG).
 
 Dynamic debug has even more useful features:
 
@@ -202,6 +206,9 @@ The flags are:
   tInclude thread ID in messages not generated from interrupt context
   _No flags are set. (Or'd with others on input)
 
+For debug_hex_dump() and print_hex_dump_bytes(), only 'p' flag have meaning,
+other flags ignored.
+
 For display, the flags are preceded by '='
 (mnemonic: what the flags are currently equal to).
 
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 6dd4787..17565ab 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -95,6 +95,16 @@ do { 
\
 ##__VA_ARGS__);\
 } while (0)
 
+#define dynamic_hex_dump(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)\
+do {   \
+   DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, prefix_str);  \
+   if (unlikely(descriptor.flags  _DPRINTK_FLAGS_PRINT))  \
+   print_hex_dump(KERN_DEBUG, prefix_str,  \
+

Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-14 Thread Joe Perches
On Wed, 2012-11-14 at 18:18 +0200, Vladimir Kondratiev wrote:
 And, here it goes (can I call it PATCH?):

Don't see why not.

 From: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com
[]
 Introduce debug_hex_dump() that can be dynamically controlled, similar to
 pr_debug.
 
 Also, make print_hex_dump_bytes() dynamically controlled

print_hex_dump_debug might be a better name than
debug_hex_dump because it's more similar to the other
print_hex_dump_foo names.


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-14 Thread Vladimir Kondratiev
On Wednesday, November 14, 2012 09:08:52 AM Joe Perches wrote:
 On Wed, 2012-11-14 at 18:18 +0200, Vladimir Kondratiev wrote:
  And, here it goes (can I call it PATCH?):
 Don't see why not.
 
  From: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com
 
 []
 
  Introduce debug_hex_dump() that can be dynamically controlled, similar to
  pr_debug.
  
  Also, make print_hex_dump_bytes() dynamically controlled
 
 print_hex_dump_debug might be a better name than
 debug_hex_dump because it's more similar to the other
 print_hex_dump_foo names.

Well, let it be:

From 5c9a79ea32e300f9a228d659f325e30d450b57c1 Mon Sep 17 00:00:00 2001
From: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com
Date: Wed, 14 Nov 2012 19:24:51 +0200
Subject: [PATCH] dynamic_debug: dynamic hex dump

Introduce print_hex_dump_debug() that can be dynamically controlled, similar to
pr_debug.

Also, make print_hex_dump_bytes() dynamically controlled

Implement only 'p' flag (_DPRINTK_FLAGS_PRINT) to keep it simple since hex dump 
prints
multiple lines and long prefix would impact readability.
To provide line/file etc. information, use pr_debug or similar
before/after print_hex_dump_debug()

Signed-off-by: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com
---
 Documentation/dynamic-debug-howto.txt |   11 +--
 include/linux/dynamic_debug.h |   10 ++
 include/linux/printk.h|   17 +
 3 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/Documentation/dynamic-debug-howto.txt 
b/Documentation/dynamic-debug-howto.txt
index 6e16849..b39a771 100644
--- a/Documentation/dynamic-debug-howto.txt
+++ b/Documentation/dynamic-debug-howto.txt
@@ -6,8 +6,12 @@ This document describes how to use the dynamic debug (dyndbg) 
feature.
 
 Dynamic debug is designed to allow you to dynamically enable/disable
 kernel code to obtain additional kernel information.  Currently, if
-CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() calls can
-be dynamically enabled per-callsite.
+CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() and
+print_hex_dump_debug()/print_hex_dump_bytes() calls can be dynamically
+enabled per-callsite.
+
+If CONFIG_DYNAMIC_DEBUG is not set, print_hex_dump_debug() is just
+shortcut for print_hex_dump(KERN_DEBUG).
 
 Dynamic debug has even more useful features:
 
@@ -202,6 +206,9 @@ The flags are:
   tInclude thread ID in messages not generated from interrupt context
   _No flags are set. (Or'd with others on input)
 
+For print_hex_dump_debug() and print_hex_dump_bytes(), only 'p' flag
+have meaning, other flags ignored.
+
 For display, the flags are preceded by '='
 (mnemonic: what the flags are currently equal to).
 
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 6dd4787..17565ab 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -95,6 +95,16 @@ do { 
\
 ##__VA_ARGS__);\
 } while (0)
 
+#define dynamic_hex_dump(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)\
+do {   \
+   DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, prefix_str);  \
+   if (unlikely(descriptor.flags  _DPRINTK_FLAGS_PRINT))  \
+   print_hex_dump(KERN_DEBUG, prefix_str,  \
+  prefix_type, rowsize, groupsize, \
+  buf, len, ascii);\
+} while (0)
+
 #else
 
 #include linux/string.h
diff --git a/include/linux/printk.h b/include/linux/printk.h
index 9afc01e..02c95cf 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -321,8 +321,13 @@ extern void hex_dump_to_buffer(const void *buf, size_t len,
 extern void print_hex_dump(const char *level, const char *prefix_str,
   int prefix_type, int rowsize, int groupsize,
   const void *buf, size_t len, bool ascii);
+#if defined(CONFIG_DYNAMIC_DEBUG)
+#define print_hex_dump_bytes(prefix_str, prefix_type, buf, len)\
+   dynamic_hex_dump(prefix_str, prefix_type, 16, 1, buf, len, true)
+#else
 extern void print_hex_dump_bytes(const char *prefix_str, int prefix_type,
 const void *buf, size_t len);
+#endif /* defined(CONFIG_DYNAMIC_DEBUG) */
 #else
 static inline void print_hex_dump(const char *level, const char *prefix_str,
  int prefix_type, int rowsize, int groupsize,
@@ -336,4 +341,16 @@ static inline void print_hex_dump_bytes(const char 
*prefix_str, int prefix_type,
 
 #endif
 
+#if defined(CONFIG_DYNAMIC_DEBUG)
+#define print_hex_dump_debug(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)\
+   dynamic_hex_dump(prefix_str, prefix_type, rowsize,  \
+groupsize, buf, len,