All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Josh Holland <jrh@joshh.co.uk>,
	alan@linux.intel.com, andre.goddard@gmail.com,
	devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Staging: rar: fixed up rar_driver.{h,c}
Date: Fri, 5 Feb 2010 09:19:36 -0800	[thread overview]
Message-ID: <20100205171936.GG14145@suse.de> (raw)
In-Reply-To: <m3eil0o72j.fsf@intrepid.localdomain>

On Fri, Feb 05, 2010 at 01:32:52AM +0100, Krzysztof Halasa wrote:
> Josh Holland <jrh@joshh.co.uk> writes:
> 
> > This is a patch to the rar_driver.c and rar_driver.h files to remove
> > style issues found by the checkpatch.pl script.
> >
> > +++ b/drivers/staging/rar/rar_driver.c
> > @@ -68,7 +68,8 @@ static void __exit rar_exit_handler(void);
> >  /*
> >    function that is activated on the successfull probe of the RAR device
> >  */
> > -static int __devinit rar_probe(struct pci_dev *pdev, const struct pci_device_id *ent);
> > +static int __devinit rar_probe(struct pci_dev *pdev,
> > +	const struct pci_device_id *ent);
> 
> It's agreed such changes make it worse. The 80-column "ERROR" should be
> ignored, and it will be removed from checkpatch.
> 
> > -	printk(KERN_WARNING "rar- result from send ctl register is %x\n"
> > -	  ,result);
> > +	printk(KERN_WARNING "rar- result from send ctl register is %x\n",
> > +			result);
> 
> Also, here (and then) - I'd just make it a single line if you're changing
> it. I'd be far from "unwrapping" all code across the kernel, though
> (without otherwise changing the lines in question).

No, this is fine, no problem with this change.

> > +		if (memrar_get_rar_addr(pdev, (*i).low, &(rar_addr[n].low))
> > +			|| memrar_get_rar_addr(pdev, (*i).high,
> > +			   &(rar_addr[n].high))) {
> > +			result = -1;
> > +			break;
> > +		}
> 
> Isn't the following a bit more readable?
> 
> +		if (memrar_get_rar_addr(pdev, i->low, &rar_addr[n].low) ||
> +		    memrar_get_rar_addr(pdev, i->high, &rar_addr[n].high)) {
> +			result = -1;
> +			break;
> +		}

The latter is nicer, but it doesn't really matter :)

> It doesn't make sense to split the printk, at least every single output
> line printed shouldn't be broken into pieces (but perhaps one single
> line for the whole printk() is best).
> Also I like the post-increments (z++) more, but maybe it's just me.
> 
> > +		size_t z;
> > +		for (z = 0; z != MRST_NUM_RAR; ++z) {
> > +			printk(KERN_WARNING "rar - "
> > +			"BRAR[%Zd] physical address low\n"
> > +			"\tlow:  0x%08x\n"
> > +			"\thigh: 0x%08x\n",
> > +			z,
> > +			rar_addr[z].low,
> > +			rar_addr[z].high);
> 
> 
> > -#define DEBUG_PRINT_0(DEBUG_LEVEL , info) \
> > -do \
> > -{ \
> > -  if(DEBUG_LEVEL) \
> > -  { \
> > -    printk(KERN_WARNING info); \
> > -  } \
> > -}while(0)
> > +#define DEBUG_PRINT_0(DEBUG_LEVEL, info) \
> > +do { \
> > +	if (DEBUG_LEVEL) \
> > +		printk(KERN_WARNING info); \
> > +} while (0)
> 
> Also I think moving these backslashes to the right of the macro code is
> preferred, isn't it?


It doesn't matter all that much.

Overall this looks fine, I'll queue it up.

thanks,

greg k-h

  reply	other threads:[~2010-02-05 17:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-04 21:23 [PATCH] Staging: rar: fixed up rar_driver.{h,c} Josh Holland
2010-02-05  0:32 ` Krzysztof Halasa
2010-02-05 17:19   ` Greg KH [this message]
2010-02-05 21:32     ` Krzysztof Halasa
2010-02-05 21:58 ` [PATCH 2/2] Staging: rar: More style changes to rar_driver.c Josh Holland
2010-02-17 22:40   ` Greg KH
2010-02-20 11:36     ` Josh Holland
2010-02-24  2:05       ` Greg KH

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=20100205171936.GG14145@suse.de \
    --to=gregkh@suse.de \
    --cc=alan@linux.intel.com \
    --cc=andre.goddard@gmail.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=jrh@joshh.co.uk \
    --cc=khc@pm.waw.pl \
    --cc=linux-kernel@vger.kernel.org \
    /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.