All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Antti Palosaari <crope@iki.fi>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
	Amber Thrall <amber.rose.thrall@gmail.com>,
	jarod@wilsonet.com, linux-media@vger.kernel.org,
	devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Fixed all coding style issues for drivers/staging/media/lirc/
Date: Thu, 02 Oct 2014 18:41:27 -0700	[thread overview]
Message-ID: <1412300487.3247.91.camel@joe-AO725> (raw)
In-Reply-To: <542DE6B5.1060906@iki.fi>

On Fri, 2014-10-03 at 02:58 +0300, Antti Palosaari wrote:
> On 10/02/2014 07:45 PM, Joe Perches wrote:
> > On Thu, 2014-10-02 at 10:29 -0300, Mauro Carvalho Chehab wrote:
> >> Em Wed, 01 Oct 2014 21:40:02 -0700 Amber Thrall <amber.rose.thrall@gmail.com> escreveu:
> >>> Fixed various coding style issues, including strings over 80 characters long and many
> >>> deprecated printk's have been replaced with proper methods.
> > []
> >>> diff --git a/drivers/staging/media/lirc/lirc_imon.c b/drivers/staging/media/lirc/lirc_imon.c
> > []
> >>> @@ -623,8 +623,8 @@ static void imon_incoming_packet(struct imon_context *context,
> >>>   	if (debug) {
> >>>   		dev_info(dev, "raw packet: ");
> >>>   		for (i = 0; i < len; ++i)
> >>> -			printk("%02x ", buf[i]);
> >>> -		printk("\n");
> >>> +			dev_info(dev, "%02x ", buf[i]);
> >>> +		dev_info(dev, "\n");
> >>>   	}
> >>
> >> This is wrong, as the second printk should be printk_cont.
> >>
> >> The best here would be to change all above to use %*ph.
> >> So, just:
> >>
> >> 	dev_debug(dev, "raw packet: %*ph\n", len, buf);
> >
> > Not quite.
> >
> > %*ph is length limited and only useful for lengths < 30 or so.
> > Even then, it's pretty ugly.
> >
> > print_hex_dump_debug() is generally better.
> 
> That is place where you print 8 debug bytes, which are received remote 
> controller code. IMHO %*ph format is just what you like in that case.

Hi Antti.

I stand by my statement as I only looked at the
patch snippet itself, not any function real code.

In the actual code, there's a test above it:

	if (len != 8) {
		dev_warn(dev, "imon %s: invalid incoming packet size (len = %d, intf%d)\n",
			__func__, len, intf);
		return;
	}

So in my opinion, this would be better/smaller as:

	dev_dbg(dev, "raw packet: %8ph\n", urb->transfer_buffer);

> Why print_hex_dump_debug() is better? IIRC it could not be even 
> controlled like those dynamic debug printings.

Nope, it is. (from printk.h)

#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, rowsize,		\
			     groupsize, buf, len, ascii)		\
	print_hex_dump(KERN_DEBUG, prefix_str, prefix_type, rowsize,	\
		       groupsize, buf, len, ascii)
#endif /* defined(CONFIG_DYNAMIC_DEBUG) */

It prints multiple lines when the length is > 16.
It prints the ascii along with the hex if desired.

cheers, Joe


  reply	other threads:[~2014-10-03  1:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-02  4:40 [PATCH] Fixed all coding style issues for drivers/staging/media/lirc/ Amber Thrall
2014-10-02  4:49 ` Ilia Mirkin
2014-10-02  6:20 ` Jeremiah Mahler
2014-10-02 12:45 ` Greg KH
2014-10-02 13:29 ` Mauro Carvalho Chehab
2014-10-02 16:45   ` Joe Perches
2014-10-02 23:58     ` Antti Palosaari
2014-10-03  1:41       ` Joe Perches [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-10-02  2:35 Amber Thrall
2014-10-02  2:46 ` Greg KH
2014-10-02  8:13 ` Dan Carpenter

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=1412300487.3247.91.camel@joe-AO725 \
    --to=joe@perches.com \
    --cc=amber.rose.thrall@gmail.com \
    --cc=crope@iki.fi \
    --cc=devel@driverdev.osuosl.org \
    --cc=jarod@wilsonet.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@osg.samsung.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.