linux-kernel - Re: linux-next: manual merge of the devicetree tree with the m68k tree

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] [day] [month] [year] [list]

Date:	Wed, 10 Feb 2010 13:17:49 -0700
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Finn Thain <fthain@...egraphics.com.au>,
	Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: linux-next: manual merge of the devicetree tree with the m68k 
	tree

On Tue, Feb 9, 2010 at 10:02 PM, Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> Hi Grant,
>
> Today's linux-next merge of the devicetree tree got a conflict in
> drivers/serial/pmac_zilog.c between commit
> f0ccf0f0269dfe53ec3f1c58fe130a47b908b907 ("pmac-zilog: cleanup") from
> the m68k tree and commit71a157e8edca55198e808f8561dd49017a54ee34  ("of: add
> 'of_' prefix to machine_is_compatible()") from the devicetree tree.
>
> The first removes a space ... I fixed it up (see below) and can carry the
> fix as necessary.  (Grant, you could get rid of this by removing the
> space between the tabs on the line "baud = 57600;".  Not a big issue,
> though.)

Removing the space didn't help.  git still complains about a conflict
on merge if I remove the space.  Probably because both branches show a
diff on the same area against the common base.

What should be done here?  Should I merge Geert's 68k tree into my
next-devicetree branch?  Or is there a better way to prepare for the
merge window?

> Also, there is a further patch in the m68k tree
> (89d58f83cfce675a2054975cc2598ba1979816c7 "pmac-zilog: add platform
> driver") that adds a define for machine_is_compatible.  I fixed that as
> below as well.  Hmmm, this file should really include linux/of_fdt.h for
> the definition of of_machine_is_compatible(), shouldn't it?  And then
> maybe we could have a non OF version of the prototype/define in
> of_fdt.h?  Just an idea.

That sounds reasonable.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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/