From: Dan Carpenter <dan.carpenter@oracle.com>
To: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
teddy.wang@siliconmotion.com,
Greg KH <gregkh@linuxfoundation.org>,
devel@driverdev.osuosl.org, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/6] staging: sm750fb: Use memset_io instead of memset
Date: Wed, 11 Mar 2015 09:23:27 +0000 [thread overview]
Message-ID: <20150311092327.GE16501@mwanda> (raw)
In-Reply-To: <CAA5enKaWynLvLUN+GCdphOOMmqX+cAj3kA3owjKbng66CK=pqg@mail.gmail.com>
On Wed, Mar 11, 2015 at 09:11:52AM +0000, Lorenzo Stoakes wrote:
> On 11 March 2015 at 08:54, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > When I see a patch like this, then I worry, "What if the Sparse
> > annotations are wrong? The patch description doesn't say anything about
> > that." After review then I think the annotations are correct so that's
> > fine.
>
> How do you mean? I was careful to check what sparse was referring to,
> then investigate how memset should be used with pointers with a
> __iomem qualifier. I'd like to be able to improve my patch
> descriptions going forward as best I can :)
>
Yes. The patch is correct. I wasn't asking you to redo it. From later
patches it's actually clear that you know that this change is a bugfix
and a behavior change. But we get a lot of patches where people just
randomly change things to please Sparse and it maybe silences a warning
but it's not correct. I can think of a few recentish examples where
people used standard struct types which hold __iomem or __user pointers
but they used them in non-standard ways so the pointers were actually
normal kernel pointers.
I guess the rule here is that the patch should explain the effect of the
bugfix for the user. Often you won't know the effect, but it's a
helpful thing to think about.
> > Btw, do you have this hardware? Are you able to test these changes?
>
> Unfortunately not, I am trying to keep these changes as simple code
> fixes that ought not to affect actual hardware behaviour as I can
> (though of course you can never be entirely sure that's the case!)
That's fine. I was just wondering. It affects how paranoid I am when I
review the code.
regards,
dan carpenter
WARNING: multiple messages have this Message-ID (diff)
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
teddy.wang@siliconmotion.com,
Greg KH <gregkh@linuxfoundation.org>,
devel@driverdev.osuosl.org, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/6] staging: sm750fb: Use memset_io instead of memset
Date: Wed, 11 Mar 2015 12:23:27 +0300 [thread overview]
Message-ID: <20150311092327.GE16501@mwanda> (raw)
In-Reply-To: <CAA5enKaWynLvLUN+GCdphOOMmqX+cAj3kA3owjKbng66CK=pqg@mail.gmail.com>
On Wed, Mar 11, 2015 at 09:11:52AM +0000, Lorenzo Stoakes wrote:
> On 11 March 2015 at 08:54, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > When I see a patch like this, then I worry, "What if the Sparse
> > annotations are wrong? The patch description doesn't say anything about
> > that." After review then I think the annotations are correct so that's
> > fine.
>
> How do you mean? I was careful to check what sparse was referring to,
> then investigate how memset should be used with pointers with a
> __iomem qualifier. I'd like to be able to improve my patch
> descriptions going forward as best I can :)
>
Yes. The patch is correct. I wasn't asking you to redo it. From later
patches it's actually clear that you know that this change is a bugfix
and a behavior change. But we get a lot of patches where people just
randomly change things to please Sparse and it maybe silences a warning
but it's not correct. I can think of a few recentish examples where
people used standard struct types which hold __iomem or __user pointers
but they used them in non-standard ways so the pointers were actually
normal kernel pointers.
I guess the rule here is that the patch should explain the effect of the
bugfix for the user. Often you won't know the effect, but it's a
helpful thing to think about.
> > Btw, do you have this hardware? Are you able to test these changes?
>
> Unfortunately not, I am trying to keep these changes as simple code
> fixes that ought not to affect actual hardware behaviour as I can
> (though of course you can never be entirely sure that's the case!)
That's fine. I was just wondering. It affects how paranoid I am when I
review the code.
regards,
dan carpenter
next prev parent reply other threads:[~2015-03-11 9:23 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-11 1:28 [PATCH 1/6] staging: sm750fb: Use memset_io instead of memset Lorenzo Stoakes
2015-03-11 1:28 ` [PATCH 2/6] staging: sm750fb: Fix non-ANSI function declarations Lorenzo Stoakes
2015-03-11 1:28 ` Lorenzo Stoakes
2015-03-11 1:28 ` [PATCH 3/6] staging: sm750fb: Make internal functions static Lorenzo Stoakes
2015-03-11 9:30 ` Sudip Mukherjee
2015-03-11 9:42 ` Sudip Mukherjee
2015-03-11 9:38 ` Lorenzo Stoakes
2015-03-11 1:28 ` [PATCH 4/6] staging: sm750fb: Expose hw712_fillrect externally Lorenzo Stoakes
2015-03-11 8:56 ` Dan Carpenter
2015-03-11 8:56 ` Dan Carpenter
2015-03-11 9:37 ` Sudip Mukherjee
2015-03-11 9:49 ` Sudip Mukherjee
2015-03-11 9:39 ` Lorenzo Stoakes
2015-03-11 1:28 ` [PATCH 5/6] staging: sm750fb: Fix __iomem pointer types Lorenzo Stoakes
2015-03-11 1:28 ` [PATCH 6/6] staging: sm750fb: Spinlock and unlock in the same block Lorenzo Stoakes
2015-03-11 1:28 ` Lorenzo Stoakes
2015-03-11 9:09 ` Dan Carpenter
2015-03-11 9:09 ` Dan Carpenter
2015-03-11 8:54 ` [PATCH 1/6] staging: sm750fb: Use memset_io instead of memset Dan Carpenter
2015-03-11 8:54 ` Dan Carpenter
2015-03-11 9:11 ` Lorenzo Stoakes
2015-03-11 9:23 ` Dan Carpenter [this message]
2015-03-11 9:23 ` Dan Carpenter
2015-03-11 9:48 ` Sudip Mukherjee
2015-03-11 9:48 ` Sudip Mukherjee
2015-03-11 10:35 ` Sudip Mukherjee
2015-03-11 10:47 ` Sudip Mukherjee
2015-03-11 10:41 ` Lorenzo Stoakes
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=20150311092327.GE16501@mwanda \
--to=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lstoakes@gmail.com \
--cc=sudipm.mukherjee@gmail.com \
--cc=teddy.wang@siliconmotion.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.