From: Greg KH <gregkh@linuxfoundation.org>
To: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>
Cc: realwakka@gmail.com, linux-staging@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: pi433: add rf69_dbg_hex function
Date: Fri, 11 Feb 2022 09:14:40 +0100 [thread overview]
Message-ID: <YgYa8Pt77v6AAyjb@kroah.com> (raw)
In-Reply-To: <YgYZRArwwF7Z1B4f@mail.google.com>
On Fri, Feb 11, 2022 at 09:07:32PM +1300, Paulo Miguel Almeida wrote:
> dev_<level> functions don't support printing hex dumps and the
> alternative available (print_hex_dump_debug) doesn't print the device
> information such as device's driver name and device name. That type of
> information which comes in handy for situations in which you can more
> than 1 device attached at the same type.
>
> this patch adds a utility function that can obtain the same result as
> print_hex_dump_debug while being able to honour all possible flags that
> one may be interested in when dynamic debug is used.
>
> Signed-off-by: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>
> ---
> Meta-comments:
>
> the initial discussion to use print_hex_dump_debug started in this patch
> but the original idea got merged into the brach.
>
> https://lore.kernel.org/lkml/a630d8381cee0f543e0d77614052e1d04ab162a5.camel@perches.com/#t
>
> ---
> drivers/staging/pi433/rf69.c | 39 ++++++++++++++++++++++++++++--------
> 1 file changed, 31 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
> index 901f8db3e3ce..82d4ba24c35f 100644
> --- a/drivers/staging/pi433/rf69.c
> +++ b/drivers/staging/pi433/rf69.c
> @@ -822,9 +822,37 @@ int rf69_set_dagc(struct spi_device *spi, enum dagc dagc)
>
> /*-------------------------------------------------------------------------*/
>
> +static void rf69_dbg_hex(struct spi_device *spi, u8 *buf, unsigned int size,
> + const char *fmt, ...)
> +{
> + va_list args;
> + char textbuf[512] = {};
> + char *text = textbuf;
> + int text_pos;
> +
> + int rowsize = 16;
> + int i, linelen, remaining = size;
> +
> + va_start(args, fmt);
> + text_pos = vscnprintf(text, sizeof(textbuf), fmt, args);
> + text += text_pos;
> + va_end(args);
> +
> + for (i = 0; i < size; i += rowsize) {
> + linelen = min(remaining, rowsize);
> + remaining -= rowsize;
> +
> + hex_dump_to_buffer(buf + i, linelen, rowsize, 1,
> + text, sizeof(textbuf) - text_pos, false);
> +
> + dev_dbg(&spi->dev, "%s\n", textbuf);
> +
> + memset(text, 0, sizeof(textbuf) - text_pos);
> + }
> +}
This is a lot of additional complexity for almost no real benefit.
> +
> int rf69_read_fifo(struct spi_device *spi, u8 *buffer, unsigned int size)
> {
> - int i;
> struct spi_transfer transfer;
> u8 local_buffer[FIFO_SIZE + 1];
> int retval;
> @@ -844,9 +872,7 @@ int rf69_read_fifo(struct spi_device *spi, u8 *buffer, unsigned int size)
>
> retval = spi_sync_transfer(spi, &transfer, 1);
>
> - /* print content read from fifo for debugging purposes */
> - for (i = 0; i < size; i++)
> - dev_dbg(&spi->dev, "%d - 0x%x\n", i, local_buffer[i + 1]);
What is wrong with this simple line?
> + rf69_dbg_hex(spi, local_buffer + 1, size, "%s - ", __func__);
>
> memcpy(buffer, &local_buffer[1], size);
>
> @@ -855,7 +881,6 @@ int rf69_read_fifo(struct spi_device *spi, u8 *buffer, unsigned int size)
>
> int rf69_write_fifo(struct spi_device *spi, u8 *buffer, unsigned int size)
> {
> - int i;
> u8 local_buffer[FIFO_SIZE + 1];
>
> if (size > FIFO_SIZE) {
> @@ -867,9 +892,7 @@ int rf69_write_fifo(struct spi_device *spi, u8 *buffer, unsigned int size)
> local_buffer[0] = REG_FIFO | WRITE_BIT;
> memcpy(&local_buffer[1], buffer, size);
>
> - /* print content written from fifo for debugging purposes */
> - for (i = 0; i < size; i++)
> - dev_dbg(&spi->dev, "0x%x\n", buffer[i]);
> + rf69_dbg_hex(spi, local_buffer + 1, size, "%s - ", __func__);
Again, the original is fine here, why make this so complex?
Also, you are using local_buffer here, not buffer, why?
I think the original is just fine, no need to polish something as tiny
as a hex dump for debugging only.
thanks,
greg k-h
next prev parent reply other threads:[~2022-02-11 8:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-11 8:07 [PATCH] staging: pi433: add rf69_dbg_hex function Paulo Miguel Almeida
2022-02-11 8:14 ` Greg KH [this message]
2022-02-11 19:39 ` Paulo Miguel Almeida
2022-02-12 2:59 ` Joe Perches
2022-02-11 10:12 ` kernel test robot
2022-02-11 14:25 ` Dan Carpenter
2022-02-11 19:22 ` Paulo Miguel Almeida
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YgYa8Pt77v6AAyjb@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=paulo.miguel.almeida.rodenas@gmail.com \
--cc=realwakka@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.