Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset

[Lorenzo Stoakes]

On 23 March 2015 at 10:53, Dan Carpenter <dan.carpenter@xxxxxxxxxx> 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@xxxxxxxxxx>
>

Thanks for that, appreciated!

Best,

-- 
Lorenzo Stoakes
https:/ljs.io
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/