RE: [PATCH] Staging: comedi: ssv_snp: fix checkpatch.pl warnings
From: H Hartley Sweeten
Date: Thu Aug 09 2012 - 12:27:48 EST
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@xxxxxxxxx>
> ---
> 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
èº{.nÇ+‰·Ÿ®‰†+%ŠËlzwm…ébëæìr¸›zX§»®w¥Š{ayºÊÚë,j¢f£¢·hš‹àz¹®w¥¢¸¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾«‘êçzZ+ƒùšŽŠÝj"ú!¶iO•æ¬z·švØ^¶m§ÿðÃnÆàþY&—