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
next prev parent reply other threads:[~2015-03-11 9:23 UTC|newest]
Thread overview: 18+ 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 ` [PATCH 3/6] staging: sm750fb: Make internal functions static Lorenzo Stoakes
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 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 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 9:11 ` Lorenzo Stoakes
2015-03-11 9:23 ` Dan Carpenter [this message]
2015-03-11 9:48 ` 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).