From: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
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: Sat, 12 Feb 2022 08:39:28 +1300 [thread overview]
Message-ID: <Yga7cDO00Hmk9+BL@mail.google.com> (raw)
In-Reply-To: <YgYa8Pt77v6AAyjb@kroah.com>
On Fri, Feb 11, 2022 at 09:14:40AM +0100, Greg KH wrote:
>
> This is a lot of additional complexity for almost no real benefit.
>
you're right. I will no longer pursue this approach.
> > - /* 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?
>
to be honest, I think that 1 register per line isn't the easiest way to
read them. Given that print_hex_dump_debug existed and had this
horizontal-style priting format, I thought that it would be a better
way of visualizing the fifo data.
the only problems with print_hex_dump_debug was the absense of device
name and string format... so I saw a couple of drivers implementing
alternative hex_dump-like functions and thought that pi433 would benefit
from similar approach.
> > - /* print content written from fifo for debugging purposes */
> > - for (i = 0; i < size; i++)
> > - dev_dbg(&spi->dev, "0x%x\n", buffer[i]);
if we are keeping this format, I may need to add the register idx to
dev_dbg:
dev_dbg(&spi->dev, "%d - 0x%x\n", i, buffer[i]);
> Again, the original is fine here, why make this so complex?
[thinking out loud/brainstorm]
I do agree that, for just a single driver, having a method like that
seemed unnecessary but do you think it would be a good idea having
something like dev_dbg_hex_dump or similar?
print_hex_dump_debug has the following limitation:
1) lacks string format
2) doesn't honor dynamic debug flags (other then 'p')
3) doesn't print device driver name and device name
> > + rf69_dbg_hex(spi, local_buffer + 1, size, "%s - ", __func__);
>
> Also, you are using local_buffer here, not buffer, why?
>
That was a mistake, good catch.
> 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
thanks for taking the time to review the patch, I won't pursue this
approach anymore.
thanks,
Paulo Almeida
next prev parent reply other threads:[~2022-02-11 19:39 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
2022-02-11 19:39 ` Paulo Miguel Almeida [this message]
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=Yga7cDO00Hmk9+BL@mail.google.com \
--to=paulo.miguel.almeida.rodenas@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--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.