linux-kernel - Re: [PATCH 2/5] staging: cxt1e1: remove dead code in musycc.c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 9 May 2014 17:15:34 +0300
From:	Dan Carpenter <dan.carpenter@...cle.com>
To:	DaeSeok Youn <daeseok.youn@...il.com>
Cc:	gregkh@...uxfoundation.org, himangi774@...il.com,
	sachin.kamat@...aro.org, fempsci@...il.com, nandu.hgowda@...il.com,
	devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/5] staging: cxt1e1: remove dead code in musycc.c

On Fri, May 09, 2014 at 11:09:35PM +0900, DaeSeok Youn wrote:
> 2014-05-09 19:51 GMT+09:00, Dan Carpenter <dan.carpenter@...cle.com>:
> > On Fri, May 09, 2014 at 07:06:06PM +0900, Daeseok Youn wrote:
> >> Removes "#if 0" blocks.
> >>
> >> Signed-off-by: Daeseok Youn <daeseok.youn@...il.com>
> >> ---
> >> Dan,
> >>  I decided to leave musycc_dump_rxbuffer_ring(ch, 0) which is commented
> >>  out and make a block as "RLD_DEBUG". Because i think this block need to
> >> debug
> >>  with define "RLD_DEBUG". If I am wrong, let me know.
> >>
> >
> > This change should maybe have been in a separate patch.  It's a border
> > line thing.  But definitely, it should have been mentioned in the
> > changelog.
> >
> > Btw, you can use `git citool` to add or remove lines from a
> > commit.  Highlight and right click on the lines you want to add or
> > remove.
> Thanks for the tip. I used "git add -p" after "git rebase" and "git
> reset HEAD" for
> spliting a patch.
> But I have a question, Do I have to resend rest of patches after
> spliting this patch?
> In this case, 2/5 is splited to two, it doesn't need to rebase but
> numbering of patches are changed.

Probably it's simplest to just fixup the changelog and resend as-is.
If you split a patch then normally it's easiest to just resend
everything.

If you have to resend just one patch and it doesn't affect the later
patches then you can just resend that one so long as you get the
In-Reply-To email header correct.  If you don't know what an In-Reply-To
header is, then resend everything.

regards,
dan carpenter

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