lkml.org 
[lkml]   [2013]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v7] arm: use built-in byte swap function
Hi Russell,

On Thu, 6 Jun 2013 23:12:34 +0100 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>
> So, we have a problem here - the kind which appears when people stuff
> things into the -next tree which aren't destined for the next merge
> window. This is the relevant context from your patch, which is
> against linux-next:
>
> - lib1funcs.o lib1funcs.S ashldi3.o ashldi3.S \
> - font.o font.c head.o misc.o $(OBJS)
> + lib1funcs.o lib1funcs.S ashldi3.o ashldi3.S bswapsdi2.o \
> + bswapsdi2.S font.o font.c head.o misc.o $(OBJS)
>
> # Make sure files are removed during clean
> extra-y += piggy.gzip piggy.lzo piggy.lzma piggy.xzkern piggy.lz4 \
> ^^^^^^^^^
> - lib1funcs.S ashldi3.S $(libfdt) $(libfdt_hdrs)
> + lib1funcs.S ashldi3.S bswapsdi2.S $(libfdt) $(libfdt_hdrs)
>
> the underlined bit - piggy.lz4 for those who read mail with proportional
> fonts.
>
> That is not in any kernel I have, and if it _is_ something that is
> destined for the next merge window, it should be in my tree as it's
> a core ARM feature, not in some random other tree.

That is commit d8a6bf1b25bd ("arm: add support for LZ4-compressed
kernel") from next-20130606 from the akpm tree. (adding author cc) That
patch was cc'd to you, and is part of a series that adds LZ4 compression
to the kernel, so would not work on its own. The first patch in the
series is "decompressor: add LZ4 decompressor module".


> Short of hand-editing and manually applying the patch, a solution would
> be to rebase it on a mainline kernel version, like -rc4, and resubmit
> that version instead. That will ultimately then give sfr a conflict
> which should be trivial to resolve - and hopefully we'll find out who's
> carrying the LZ4 patch and putting it into linux-next.

People should *never, ever* submit patches based on linux-next (unless,
of course they are to me to help fix merge conflicts in linux-next, etc).
Patches submitted to a particular maintainer should be based on (an
ancestor of) that maintainer's current tree.

Sure, test new code before and after merging linux-next, but don;t base
new code on it.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2013-06-07 02:21    [W:0.077 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site