From: Jiri Slaby <jirislaby@gmail.com>
To: postfail@hushmail.com
Cc: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH 1 of 5 ] /drivers/char ioremap balancing/ returncode check
Date: Wed, 15 Aug 2007 19:36:12 +0000 [thread overview]
Message-ID: <46C355AC.3040604@gmail.com> (raw)
In-Reply-To: <20070815043503.535662281F@mailserver9.hushmail.com>
Scott Thompson napsal(a):
> On Mon, 13 Aug 2007 16:17:29 -0400 Jiri Slaby <jirislaby@gmail.com>
> wrote:
>>> diff --git a/drivers/char/sx.c b/drivers/char/sx.c
>>> index 85a2328..30829ed 100644
>>> --- a/drivers/char/sx.c
>>> +++ b/drivers/char/sx.c
>>> @@ -2627,6 +2627,12 @@ static void __devinit fix_sx_pci(struct
>>> pci_dev *pdev, struct sx_board *board)
>>> pci_read_config_dword(pdev, PCI_BASE_ADDRESS_0, &hwbase);
>>> hwbase &= PCI_BASE_ADDRESS_MEM_MASK;
>>> rebase = ioremap(hwbase, 0x80);
>>> + if (!rebase) {
>>> + printk(KERN_DEBUG
>>> + "sx:ioremap fail, unable to perform cntrl reg fix\n");
>>> + return;
>>> + }
>>> +
>> 1) this should be pci_iomap(pdev, 0, 0x80)
> The ioremap call was there before my patch and I'm just trying to
> audit ioremap calls to make sure that they are cleaned up and have
> their return codes checked. If you want me to take care of that
> "while I'm in the neighborhood", let me know, but trying to avoid
> too much scope creep on my audit to increase chances it actually
> gets included...
Yup, while you are at it, make yet another patch, which will convert this to
pci_iomap/unmap.
>
>> 2) KERN_DEBUG is inappropriate and wrap the string in the middle
>> and not in the
>> beginning
>
> Agree on the wordwrap, several artifacts were created on this
> patchset and this whole thing will be resubmitted through a
> different mail client.
Aha. Anyways, if it's more that 80 columns in width, split it into more lines.
> As for KERN_DEBUG, KERN_DEBUG is used in the function following
> this call as notification that this workaround was required. When
> I audit code as I am here I generally try to blend the patch in
> with the style and conventions of the code around it. If
> KERN_DEBUG is inappropriate on the subsequent call, both values
> should be changed.
Only a string, where you warn an user, that something went wrong and this and
over that won't work... KERN_DEBUG messages are usually NOT logged. I suggest
KERN_ERR for mapping failure and KERN_INFO for the message about the workaround
is being used.
--
Jiri Slaby (jirislaby@gmail.com)
Faculty of Informatics, Masaryk University
WARNING: multiple messages have this Message-ID (diff)
From: Jiri Slaby <jirislaby@gmail.com>
To: postfail@hushmail.com
Cc: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH 1 of 5 ] /drivers/char ioremap balancing/ returncode check
Date: Wed, 15 Aug 2007 21:36:12 +0200 [thread overview]
Message-ID: <46C355AC.3040604@gmail.com> (raw)
In-Reply-To: <20070815043503.535662281F@mailserver9.hushmail.com>
Scott Thompson napsal(a):
> On Mon, 13 Aug 2007 16:17:29 -0400 Jiri Slaby <jirislaby@gmail.com>
> wrote:
>>> diff --git a/drivers/char/sx.c b/drivers/char/sx.c
>>> index 85a2328..30829ed 100644
>>> --- a/drivers/char/sx.c
>>> +++ b/drivers/char/sx.c
>>> @@ -2627,6 +2627,12 @@ static void __devinit fix_sx_pci(struct
>>> pci_dev *pdev, struct sx_board *board)
>>> pci_read_config_dword(pdev, PCI_BASE_ADDRESS_0, &hwbase);
>>> hwbase &= PCI_BASE_ADDRESS_MEM_MASK;
>>> rebase = ioremap(hwbase, 0x80);
>>> + if (!rebase) {
>>> + printk(KERN_DEBUG
>>> + "sx:ioremap fail, unable to perform cntrl reg fix\n");
>>> + return;
>>> + }
>>> +
>> 1) this should be pci_iomap(pdev, 0, 0x80)
> The ioremap call was there before my patch and I'm just trying to
> audit ioremap calls to make sure that they are cleaned up and have
> their return codes checked. If you want me to take care of that
> "while I'm in the neighborhood", let me know, but trying to avoid
> too much scope creep on my audit to increase chances it actually
> gets included...
Yup, while you are at it, make yet another patch, which will convert this to
pci_iomap/unmap.
>
>> 2) KERN_DEBUG is inappropriate and wrap the string in the middle
>> and not in the
>> beginning
>
> Agree on the wordwrap, several artifacts were created on this
> patchset and this whole thing will be resubmitted through a
> different mail client.
Aha. Anyways, if it's more that 80 columns in width, split it into more lines.
> As for KERN_DEBUG, KERN_DEBUG is used in the function following
> this call as notification that this workaround was required. When
> I audit code as I am here I generally try to blend the patch in
> with the style and conventions of the code around it. If
> KERN_DEBUG is inappropriate on the subsequent call, both values
> should be changed.
Only a string, where you warn an user, that something went wrong and this and
over that won't work... KERN_DEBUG messages are usually NOT logged. I suggest
KERN_ERR for mapping failure and KERN_INFO for the message about the workaround
is being used.
--
Jiri Slaby (jirislaby@gmail.com)
Faculty of Informatics, Masaryk University
next prev parent reply other threads:[~2007-08-15 19:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-13 4:00 [PATCH 1 of 5 ] /drivers/char ioremap balancing/ returncode check Scott Thompson
2007-08-13 4:00 ` Scott Thompson
2007-08-13 20:17 ` Jiri Slaby
2007-08-13 20:17 ` Jiri Slaby
2007-08-15 4:35 ` Scott Thompson
2007-08-15 4:35 ` Scott Thompson
2007-08-15 19:36 ` Jiri Slaby [this message]
2007-08-15 19:36 ` Jiri Slaby
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=46C355AC.3040604@gmail.com \
--to=jirislaby@gmail.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=postfail@hushmail.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.