All of lore.kernel.org
 help / color / mirror / Atom feed
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] staging: sm750fb: Fix sparse warning
Date: Tue, 10 Mar 2015 08:59:15 +0000	[thread overview]
Message-ID: <20150310085915.GB16501@mwanda> (raw)
In-Reply-To: <CAA5enKa5x5R2Z9+Sc4UzKFu+N9rKoh_sW7hfVN8CmmqhF9LMiw@mail.gmail.com>

On Tue, Mar 10, 2015 at 08:47:47AM +0000, Lorenzo Stoakes wrote:
> On 10 March 2015 at 07:00, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> 
> > No need for the volatile.
> 
> Will remove.
> 
> > Really mmio750 should be a "void __iomem *"
> > it is declared as "unsigned char __iomem *" but it's not a char pointer
> > that's only to make the pointer math work.  It would work just as well
> > as a void and we could remove some ugly casting.
> 
> I'm thinking the change to "void __iomem *" from "unsigned char
> __iomem *" ought to be a separate patch in order to keep this cleanly
> focused on solving the sparse warning? Am more than happy to do this
> and make the appropriate changes to the macros in ddk750_help.h.
> 

The patch is:

[patch] cleanup the type of mmio750

silencing a Sparse warning is just a side benifit of using correct
data types.  The "one thing per patch" rule also means that you should
fix a whole problem instead of half a thing per patch.

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] staging: sm750fb: Fix sparse warning
Date: Tue, 10 Mar 2015 11:59:15 +0300	[thread overview]
Message-ID: <20150310085915.GB16501@mwanda> (raw)
In-Reply-To: <CAA5enKa5x5R2Z9+Sc4UzKFu+N9rKoh_sW7hfVN8CmmqhF9LMiw@mail.gmail.com>

On Tue, Mar 10, 2015 at 08:47:47AM +0000, Lorenzo Stoakes wrote:
> On 10 March 2015 at 07:00, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> 
> > No need for the volatile.
> 
> Will remove.
> 
> > Really mmio750 should be a "void __iomem *"
> > it is declared as "unsigned char __iomem *" but it's not a char pointer
> > that's only to make the pointer math work.  It would work just as well
> > as a void and we could remove some ugly casting.
> 
> I'm thinking the change to "void __iomem *" from "unsigned char
> __iomem *" ought to be a separate patch in order to keep this cleanly
> focused on solving the sparse warning? Am more than happy to do this
> and make the appropriate changes to the macros in ddk750_help.h.
> 

The patch is:

[patch] cleanup the type of mmio750

silencing a Sparse warning is just a side benifit of using correct
data types.  The "one thing per patch" rule also means that you should
fix a whole problem instead of half a thing per patch.

regards,
dan carpenter


  reply	other threads:[~2015-03-10  8:59 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-09 20:57 [PATCH] staging: sm750fb: Fix sparse warning Lorenzo Stoakes
2015-03-09 20:57 ` Lorenzo Stoakes
2015-03-10  7:00 ` Dan Carpenter
2015-03-10  7:00   ` Dan Carpenter
2015-03-10  8:47   ` Lorenzo Stoakes
2015-03-10  8:59     ` Dan Carpenter [this message]
2015-03-10  8:59       ` Dan Carpenter
2015-03-10  9:14       ` Lorenzo Stoakes
2015-03-10  7:42 ` Sudip Mukherjee
2015-03-10  7:54   ` Sudip Mukherjee
2015-03-10  8:44   ` Lorenzo Stoakes
2015-08-05 13:26 ` [PATCH] staging: sm750fb: fix sparse warning for lock Peng Fan
2015-08-05 13:26   ` Peng Fan
2015-08-05 19:01   ` Greg KH
2015-08-05 19:01     ` Greg KH
2015-08-05 22:34   ` Dan Carpenter
2015-08-05 22:34     ` Dan Carpenter

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=20150310085915.GB16501@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.