linux-kernel - Re: [GIT PULL 4/5] ARM: More device tree support updates

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]

Message-Id: <201203282058.20226.arnd@arndb.de>
Date:	Wed, 28 Mar 2012 20:58:19 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Olof Johansson <olof@...om.net>, arm@...nel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL 4/5] ARM: More device tree support updates

On Wednesday 28 March 2012, Linus Torvalds wrote:
> On Wed, Mar 28, 2012 at 12:14 AM, Olof Johansson <olof@...om.net> wrote:
> >
> > Merge conflicts and proposed solutions:
> >
> > arch/arm/mach-ux500/Kconfig: Two new config options. Keep both.
> 
> Guys, I'm seeing merge problems that go way beyond this.
> 
> Look at that MACH_U8500 config option. It got renamed to MACH_MOP500,
> but it continues to live in the tree.
> 
> This rename conflict happened earlier and I didn't notice (grep for
> it: it's used by a staging driver), so it's already in my pushed out
> tree. But it seems to be getting worse, and your proposed merge
> solution doesn't cover it.

Your solution looks good. I had the MACH_UX500_DT option above U5500
instead of below it in our for-next branch, but either way makes sense.

> I'll try to fix things up, but you need to verify my merge. And you
> guys should have noticed and noted it, rather than leave it to my
> random bumbling about.

Yes, noted for next time. We had a lot of merge conflicts because of
being relatively late in the merge window (this one was purely
self made though), and it's not always easy to decide which ones
to eliminate in advance, leave in or describe the resolution we found.

Since we usually see the same conflicts and resolve them in the
for-next branch, I guess it's easy enough to just always provide
the branch with the resolutions as a help for cases like this one.

	Arnd
--
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/