From: Dan Carpenter <dan.carpenter@oracle.com>
To: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: devel@driverdev.osuosl.org, linux-fbdev@vger.kernel.org,
Teddy Wang <teddy.wang@siliconmotion.com>,
Greg KH <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org,
Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Subject: Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
Date: Wed, 18 Mar 2015 10:52:56 +0000 [thread overview]
Message-ID: <20150318105256.GR16501@mwanda> (raw)
In-Reply-To: <CAA5enKZqRPx8a9Kk7cX1GJih9=N+Wj_zPbhg+hbLDJoKNEau-Q@mail.gmail.com>
On Wed, Mar 18, 2015 at 10:44:53AM +0000, Lorenzo Stoakes wrote:
> On 18 March 2015 at 10:18, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> >>
> >> This changelog still sucks. It doesn't describe the effect of this
> >> behavior change for the user. It doesn't even make it clear that you
> >> are aware that this is a behavior change.
> >
> > It doesn't say to me that you have asked yourself if the sparse
> > annotations are correct. Many times they are wrong.
>
> My understanding, which as a new contributor is of course limited and
> likely simply wrong in many aspects, is - these memset's are referring
> to I/O mapped memory, which as far as I can tell is actually the case
> here, so in order to make it explicit that this is the case and we
> know it is, we use memset_io. As far as I understand the pointers
> simply have a modifier applied which marks them as I/O mapped memory
> for the purposes of sparse checking whether they are used consistently
> as such and are not treated like they are a normal kernel pointer.
>
> In this case the cursor->vstart and crtc->vScreen pointers, looking
> through the source, explicitly refer to memory which is I/O mapped,
> and is annotated as __iomem accordingly throughout.
>
> I will update the message accordingly, obviously if I'm
> misunderstanding something let me know.
This is all fine.
>
> > We have had this discussion before but you still sent the same exact
> > bad changelog.
>
> Actually you said:-
>
> > 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.
>
> And:-
The patch is fine. The changelog is not.
>
> > 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.
>
> So it wasn't clear *to me* you wanted me to change that, given you
> asked me *not* to redo it explicitly (which I assumed applied to the
> message too) - apologies if I misinterpreted this!
I often say "don't resend" because something is minor and I don't want
to slow you down but since you were resending it anyway then please fix
it. Also changelogs are really easy to fix. In mutt, you can do it
without leaving your email client. So I have revised my earlier
statement, please fix it. :)
regards,
dan carpenter
next prev parent reply other threads:[~2015-03-18 10:52 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-18 8:57 [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset Lorenzo Stoakes
2015-03-18 8:57 ` [PATCH RESEND 2/5] staging: sm750fb: Make internal functions static Lorenzo Stoakes
2015-03-18 8:57 ` [PATCH RESEND 3/5] staging: sm750fb: Remove unused function Lorenzo Stoakes
2015-03-18 8:57 ` [PATCH RESEND 4/5] staging: sm750fb: Fix __iomem pointer types Lorenzo Stoakes
2015-03-18 8:57 ` [PATCH RESEND 5/5] staging: sm750fb: Remove spinlock helper function Lorenzo Stoakes
2015-03-18 10:17 ` [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset Dan Carpenter
2015-03-18 10:18 ` Dan Carpenter
2015-03-18 10:44 ` Lorenzo Stoakes
2015-03-18 10:52 ` Dan Carpenter [this message]
2015-03-18 10:55 ` Lorenzo Stoakes
2015-03-18 10:46 ` Lorenzo Stoakes
2015-03-18 10:59 ` Dan Carpenter
2015-03-18 11:14 ` Lorenzo Stoakes
2015-03-18 19:09 ` Lorenzo Stoakes
2015-03-18 10:50 ` Vitaly Kuznetsov
2015-03-18 11:12 ` Lorenzo Stoakes
2015-03-18 11:25 ` Dan Carpenter
2015-03-18 13:18 ` Sudip Mukherjee
2015-03-18 13:23 ` Dan Carpenter
2015-03-18 13:41 ` Sudip Mukherjee
2015-03-18 19:10 ` 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=20150318105256.GR16501@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).