On Wednesday, July 09, 2014 at 11:21:08 PM, Joe Perches wrote:
On Wed, 2014-07-09 at 22:39 +0200, Marek Vasut wrote:
The above function looks like almost verbatim copy of print_hex_dump().
The only difference I can spot is that it's calling seq_printf() instead
of printk(). Can you not
On Thu, 2014-07-10 at 09:58 +0200, Marek Vasut wrote:
On Wednesday, July 09, 2014 at 11:21:08 PM, Joe Perches wrote:
On Wed, 2014-07-09 at 22:39 +0200, Marek Vasut wrote:
The above function looks like almost verbatim copy of print_hex_dump().
The only difference I can spot is that it's
On Thu, 2014-07-10 at 12:50 +0300, Andy Shevchenko wrote:
I have considered to modify hex_dump_to_buffer() to return how many
bytes it actually proceed to the buffer. In that case we can directly
print to m-buf like other seq_foo calls do.
But I still have doubts about it. Any opinion?
The new seq_hex_dump() is a complete analogue of print_hex_dump().
We have few users of this functionality already. It allows to reduce their
codebase.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
fs/seq_file.c| 35 +++
On Wednesday, July 09, 2014 at 05:24:26 PM, Andy Shevchenko wrote:
The new seq_hex_dump() is a complete analogue of print_hex_dump().
We have few users of this functionality already. It allows to reduce their
codebase.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
On Wed, 2014-07-09 at 22:39 +0200, Marek Vasut wrote:
The above function looks like almost verbatim copy of print_hex_dump(). The
only
difference I can spot is that it's calling seq_printf() instead of printk().
Can
you not instead generalize print_hex_dump() and based on it's invocation,
