[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ADE657CA350FB648AAC2C43247A983F00206AAE97175@AUSP01VMBX24.collaborationhost.net>
Date: Thu, 9 Aug 2012 11:27:41 -0500
From: H Hartley Sweeten <hartleys@...ionengravers.com>
To: Güngör Erseymen <gelurine@...il.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
CC: "abbotti@....co.uk" <abbotti@....co.uk>,
"fmhess@...rs.sourceforge.net" <fmhess@...rs.sourceforge.net>,
"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] Staging: comedi: ssv_snp: fix checkpatch.pl warnings
On Thursday, August 09, 2012 8:20 AM, Güngör Erseymen wrote:
> Fix two checkpatch.pl warnings about printk issues by using
> pr_info(...) instead of printk(KERN_INFO, ...).
>
> Signed-off-by: Güngör Erseymen <gelurine@...il.com>
> ---
> drivers/staging/comedi/drivers/ssv_dnp.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Hello Güngör,
You have a typo in the subject for this patch.
"ssv_snp" should be "ssv_dnp"
>
> diff --git a/drivers/staging/comedi/drivers/ssv_dnp.c b/drivers/staging/comedi/drivers/ssv_dnp.c
> index 84b9f2a..4cd0f1b 100644
> --- a/drivers/staging/comedi/drivers/ssv_dnp.c
> +++ b/drivers/staging/comedi/drivers/ssv_dnp.c
> @@ -177,7 +177,7 @@ static int dnp_attach(struct comedi_device *dev, struct comedi_devconfig *it)
> struct comedi_subdevice *s;
> int ret;
>
> - printk(KERN_INFO "comedi%d: dnp: ", dev->minor);
> + pr_info("comedi%d: dnp: ", dev->minor);
Where possible, fixes like this should use the dev_printk versions.
For instance, this one would be:
dev_info(dev->class_dev, "dnp:");
But, there is a cleaner fix for this file. See below.
> dev->board_name = board->name;
>
> @@ -195,7 +195,7 @@ static int dnp_attach(struct comedi_device *dev, struct comedi_devconfig *it)
> s->insn_bits = dnp_dio_insn_bits;
> s->insn_config = dnp_dio_insn_config;
>
> - printk("attached\n");
> + pr_info("attached\n");
There are only two printk's in this file, both in the "attach" routine.
The first one does not have a "\n" and the function could exit without
ever terminating the message.
A better fix would be to merge the two messages into one "attached" message
at the end of the function. You could also use the dev->board_name instead of
the open coded string. Something like:
dev_info(dev->class_dev, "%s: attached\n", dev->board_name);
Also, the message should be moved so that it's the last thing that happens
before the function returns.
Regards,
Hartley
>
> /* We use the I/O ports 0x22,0x23 and 0xa3-0xa9, which are always
> * allocated for the primary 8259, so we don't need to allocate them
--
1.7.11.4
Powered by blists - more mailing lists