| Message ID | 1426864935-29350-1-git-send-email-lstoakes@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Sorry I wasn't clear on this before. Please, stop putting RESEND in the
subject. That's only for if you think we are screwing up or ignoring
you. Just put v2, and put what changed under the --- cut off.
---
v2: changed the commit message
https://www.google.com/#q=how+to+send+a+v2+patch
Otherwise this set looks ok. Thanks!
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 23 March 2015 at 10:53, Dan Carpenter <dan.carpenter@oracle.com> wrote: > Sorry I wasn't clear on this before. Please, stop putting RESEND in the > subject. That's only for if you think we are screwing up or ignoring > you. Just put v2, and put what changed under the --- cut off. > --- > v2: changed the commit message > > https://www.google.com/#q=how+to+send+a+v2+patch > I have to say I'm quite massively confused on this :) and the linux newbies link at the top of the results for that google search doesn't seem to clear it up for me. May I be so cheeky as to ask you to help me understand so I can do this better in future?:- * Greg has asked me to send again because it wasn't clear which set was applicable. This is why I appended RESEND 2 (the original RESEND was the same deal but *also* containing fixups to apply to the latest staging-testing) since I wasn't changing anything, just resending to make clear which patch set is valid right now. In this case should I simply append a version number to each patch in the series and resend? * Which leads on to the next point of confusion - previously when I changed *one* patch in a series then resent *all* patches in that series with v2, I had complaints that 'this patch hasn't changed' on the unchanged patches, leading me to think that you should only resend patches that have actually changed (which fits the pattern of putting a change message under the '---' - though of course you could say v2: resend patchset or similar) - however this seems to be what causes the confusion that leads to needing a resend in the first instance (maybe a problem with options I'm passing to git send-email, perhaps I need to use in-reply-to to make the v2's replies to the v1's.) * If the former point is correct and I should only resend patches that have actually changed, but I'm asked for a resend - what is the correct course of action? And of course we end up with some patches at v>1, some at v1, so should all patches then be updated to v(MAX(v)+1)? > Otherwise this set looks ok. Thanks! > > Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> > Thanks for that, appreciated! Best,
Oh hm... This is an actual RESEND patch. RESEND is a flag to show a mess up in the system. I like to take a look at those to see what went wrong. The process failure was that you messed up the threading earlier. Take a look at the --in-reply-to flag. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 23 March 2015 at 11:51, Dan Carpenter <dan.carpenter@oracle.com> wrote: > Oh hm... This is an actual RESEND patch. > > RESEND is a flag to show a mess up in the system. I like to take a look > at those to see what went wrong. The process failure was that you > messed up the threading earlier. Take a look at the --in-reply-to flag. Will do, apologies for the mess up, it makes sense that the v2's should be replies to their respective v1s. Best,
On Mon, Mar 23, 2015 at 12:43:28PM +0000, Lorenzo Stoakes wrote: > On 23 March 2015 at 11:51, Dan Carpenter <dan.carpenter@oracle.com> wrote: > > Oh hm... This is an actual RESEND patch. > > > > RESEND is a flag to show a mess up in the system. I like to take a look > > at those to see what went wrong. The process failure was that you > > messed up the threading earlier. Take a look at the --in-reply-to flag. > > Will do, apologies for the mess up, it makes sense that the v2's > should be replies to their respective v1s. and you need to send v3 now :( your series is not applying. Please refresh it against staging-testing regards sudip > > Best, > > -- > Lorenzo Stoakes > https:/ljs.io -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 23 March 2015 at 12:55, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote: > and you need to send v3 now :( > your series is not applying. Please refresh it against staging-testing Applies to staging-testing for me. Are you sure you're applying the correct 'RESEND 2' patches?
On Mon, Mar 23, 2015 at 01:02:52PM +0000, Lorenzo Stoakes wrote: > On 23 March 2015 at 12:55, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote: > > > and you need to send v3 now :( > > your series is not applying. Please refresh it against staging-testing > > Applies to staging-testing for me. Are you sure you're applying the > correct 'RESEND 2' patches? i think. if you do git log drivers/staging/sm750fb/ are you getting the first patch author as Ragavendra Nagraj <ragavendra.bn@gmail.com> ? regards sudip > > -- > Lorenzo Stoakes > https:/ljs.io -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 23 March 2015 at 13:14, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote: > On Mon, Mar 23, 2015 at 01:02:52PM +0000, Lorenzo Stoakes wrote: >> On 23 March 2015 at 12:55, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote: >> >> > and you need to send v3 now :( >> > your series is not applying. Please refresh it against staging-testing >> >> Applies to staging-testing for me. Are you sure you're applying the >> correct 'RESEND 2' patches? > i think. if you do git log drivers/staging/sm750fb/ > are you getting the first patch author as > Ragavendra Nagraj <ragavendra.bn@gmail.com> ? Yep:- commit de99befd18c10d8085182a1facbb4b8760b2b6fe Author: Ragavendra Nagraj <ragavendra.bn@gmail.com> Date: Wed Mar 18 02:37:42 2015 -0700 staging: sm750fb: Fixed no space and indent warns I've tried applying resend 2 patches to both linux-next and staging-testing in Greg's staging.git tree, they apply in both places.
On 23 March 2015 at 13:16, Lorenzo Stoakes <lstoakes@gmail.com> wrote: > I've tried applying resend 2 patches to both linux-next and > staging-testing in Greg's staging.git tree, they apply in both places. Sigh. Checking the emails I actually sent, I seem to *somehow* have sent old files in this resend :S I really don't know how this happened. My copies of the patches all apply perfectly correctly, but these are not the ones I sent. I'll bump versions using the correct --in-reply-to to fix this. Apologies again! Best,
On 23 March 2015 at 13:21, Lorenzo Stoakes <lstoakes@gmail.com> wrote: > Sigh. Checking the emails I actually sent, I seem to *somehow* have > sent old files in this resend :S I really don't know how this > happened. My copies of the patches all apply perfectly correctly, but > these are not the ones I sent. And just to add to my embarrassment, this is actually *not* the case, they DO all apply, gmail mangled the patches. So they seem fine after all! Sudip - could you try to carefully grab each of the 5 patches with [RESEND 2] in the subject to make sure you are applying them correctly? Best,
On Mon, Mar 23, 2015 at 01:25:37PM +0000, Lorenzo Stoakes wrote: > On 23 March 2015 at 13:21, Lorenzo Stoakes <lstoakes@gmail.com> wrote: > > Sigh. Checking the emails I actually sent, I seem to *somehow* have > > sent old files in this resend :S I really don't know how this > > happened. My copies of the patches all apply perfectly correctly, but > > these are not the ones I sent. > > And just to add to my embarrassment, this is actually *not* the case, > they DO all apply, gmail mangled the patches. So they seem fine after > all! > > Sudip - could you try to carefully grab each of the 5 patches with > [RESEND 2] in the subject to make sure you are applying them > correctly? my apologies. they are applying properly. i had them already applied for testing that hardware change, and again i tried to apply them. sorry for the confusion. :( regards sudip > > Best, > > -- > Lorenzo Stoakes > https:/ljs.io -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Mar 20, 2015 at 03:22:11PM +0000, Lorenzo Stoakes wrote: > This patch takes into account that cursor->vstart, crtc->vScreen and > share->pvMem are pointers to memory-mapped I/O and thus we should use memset_io > to make this explicit. In addition, some architectures require special treatment > of memory-mapped I/O so the previous code could actually break without this > change. sorry for the confusion. tested the whole series on hardware. Tested-by: Sudip Mukherjee <sudip@vectorindia.org> sudip -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c index aa0888c..3e36b6a 100644 --- a/drivers/staging/sm750fb/sm750.c +++ b/drivers/staging/sm750fb/sm750.c @@ -486,8 +486,8 @@ static int lynxfb_resume(struct pci_dev* pdev) par = info->par; crtc = &par->crtc; cursor = &crtc->cursor; - memset(cursor->vstart, 0x0, cursor->size); - memset(crtc->vScreen,0x0,crtc->vidmem_size); + memset_io(cursor->vstart, 0x0, cursor->size); + memset_io(crtc->vScreen, 0x0, crtc->vidmem_size); lynxfb_ops_set_par(info); fb_set_suspend(info, 0); } @@ -498,8 +498,8 @@ static int lynxfb_resume(struct pci_dev* pdev) par = info->par; crtc = &par->crtc; cursor = &crtc->cursor; - memset(cursor->vstart, 0x0, cursor->size); - memset(crtc->vScreen,0x0,crtc->vidmem_size); + memset_io(cursor->vstart, 0x0, cursor->size); + memset_io(crtc->vScreen, 0x0, crtc->vidmem_size); lynxfb_ops_set_par(info); fb_set_suspend(info, 0); } @@ -830,7 +830,7 @@ static int lynxfb_set_fbinfo(struct fb_info* info,int index) crtc->cursor.share = share; - memset(crtc->cursor.vstart, 0, crtc->cursor.size); + memset_io(crtc->cursor.vstart, 0, crtc->cursor.size); if(!g_hwcursor){ lynxfb_ops.fb_cursor = NULL; crtc->cursor.disable(&crtc->cursor); @@ -1151,7 +1151,7 @@ static int lynxfb_pci_probe(struct pci_dev * pdev, } #endif - memset(share->pvMem,0,share->vidmem_size); + memset_io(share->pvMem, 0, share->vidmem_size); pr_info("sm%3x mmio address = %p\n",share->devid,share->pvReg);
This patch takes into account that cursor->vstart, crtc->vScreen and share->pvMem are pointers to memory-mapped I/O and thus we should use memset_io to make this explicit. In addition, some architectures require special treatment of memory-mapped I/O so the previous code could actually break without this change. This fixes the following sparse warnings:- drivers/staging/sm750fb/sm750.c:489:17: warning: incorrect type in argument 1 (different address spaces) drivers/staging/sm750fb/sm750.c:490:17: warning: incorrect type in argument 1 (different address spaces) drivers/staging/sm750fb/sm750.c:501:17: warning: incorrect type in argument 1 (different address spaces) drivers/staging/sm750fb/sm750.c:502:17: warning: incorrect type in argument 1 (different address spaces) drivers/staging/sm750fb/sm750.c:833:5: warning: incorrect type in argument 1 (different address spaces) drivers/staging/sm750fb/sm750.c:1154:9: warning: incorrect type in argument 1 (different address spaces) Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com> --- drivers/staging/sm750fb/sm750.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) -- 2.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html