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: 6+ 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox