* Re: linux-next: manual merge of the m68knommu tree with the m68k tree [not found] ` <4E018CE3.7070101@snapgear.com> @ 2011-06-22 8:29 ` Geert Uytterhoeven 2011-06-23 6:12 ` Greg Ungerer 0 siblings, 1 reply; 2+ messages in thread From: Geert Uytterhoeven @ 2011-06-22 8:29 UTC (permalink / raw) To: Greg Ungerer; +Cc: Stephen Rothwell, linux-next, linux-kernel, Linux/m68k Hi Greg, Stephen, On Wed, Jun 22, 2011 at 08:34, Greg Ungerer <gerg@snapgear.com> wrote: > On 22/06/11 11:12, Stephen Rothwell wrote: >> Today's linux-next merge of the m68knommu tree got a conflict in >> arch/m68k/include/asm/bitops_mm.h between commit 17c74432b88e >> ("m68k/bitops: Make bitmap data pointer of atomic ops volatile") from the >> m68k tree and commit 2cb0d89e66b1 ("m68k: merge mmu and non-mmu >> bitops.h") from the m68knommu tree. >> >> The latter effectively deletes in the file and in doing the merge, >> removes the funtions that were modified by the former commit. So I just >> removed the file. > > That would be right. The changes that Geert's patch makes are in > my merge patch. Sorry, I forgot that Greg was merging them, which also fixes the issue we had on m68k. [mental note to self: check for merge conflicts with m68knommu before updating for-next] > Geert: do you want me to hold of on merging the bitops.h files? No, it looks fine to me. Feel free to add my Acked-by. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: linux-next: manual merge of the m68knommu tree with the m68k tree 2011-06-22 8:29 ` linux-next: manual merge of the m68knommu tree with the m68k tree Geert Uytterhoeven @ 2011-06-23 6:12 ` Greg Ungerer 0 siblings, 0 replies; 2+ messages in thread From: Greg Ungerer @ 2011-06-23 6:12 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: Stephen Rothwell, linux-next, linux-kernel, Linux/m68k On 22/06/11 18:29, Geert Uytterhoeven wrote: > Hi Greg, Stephen, > > On Wed, Jun 22, 2011 at 08:34, Greg Ungerer<gerg@snapgear.com> wrote: >> On 22/06/11 11:12, Stephen Rothwell wrote: >>> Today's linux-next merge of the m68knommu tree got a conflict in >>> arch/m68k/include/asm/bitops_mm.h between commit 17c74432b88e >>> ("m68k/bitops: Make bitmap data pointer of atomic ops volatile") from the >>> m68k tree and commit 2cb0d89e66b1 ("m68k: merge mmu and non-mmu >>> bitops.h") from the m68knommu tree. >>> >>> The latter effectively deletes in the file and in doing the merge, >>> removes the funtions that were modified by the former commit. áSo I just >>> removed the file. >> >> That would be right. The changes that Geert's patch makes are in >> my merge patch. > > Sorry, I forgot that Greg was merging them, which also fixes the issue we > had on m68k. > > [mental note to self: check for merge conflicts with m68knommu before updating > for-next] > >> Geert: do you want me to hold of on merging the bitops.h files? > > No, it looks fine to me. Feel free to add my Acked-by. Thanks Geert. Will do. Regards Greg ------------------------------------------------------------------------ Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-06-23 6:12 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20110622111256.3857df1e.sfr@canb.auug.org.au>
[not found] ` <4E018CE3.7070101@snapgear.com>
2011-06-22 8:29 ` linux-next: manual merge of the m68knommu tree with the m68k tree Geert Uytterhoeven
2011-06-23 6:12 ` Greg Ungerer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox