linux-kernel - Re: [PATCH 13/22] ARM: ux500: Fork MSP platform registration for step-by-step DT enablement

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: <20120828074812.GA12957@gmail.com>
Date:	Tue, 28 Aug 2012 08:48:19 +0100
From:	Lee Jones <lee.jones@...aro.org>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	STEricsson_nomadik_linux@...t.st.com, linus.walleij@...ricsson.com,
	arnd@...db.de, broonie@...nsource.wolfsonmicro.com
Subject: Re: [PATCH 13/22] ARM: ux500: Fork MSP platform registration for
 step-by-step DT enablement

On Mon, Aug 27, 2012 at 04:07:58PM -0700, Linus Walleij wrote:
> On Mon, Aug 20, 2012 at 1:06 AM, Lee Jones <lee.jones@...aro.org> wrote:
> > On Tue, Aug 14, 2012 at 01:13:49PM +0200, Linus Walleij wrote:
> >> On Thu, Aug 9, 2012 at 5:47 PM, Lee Jones <lee.jones@...aro.org> wrote:
> >>
> >> > We've done this before and it worked well last time. Here we're
> >> > duplicating a complex registration function to ease the process
> >> > of enabling it for Device Tree. As there are quite a few steps
> >> > taken during the registration process, it makes sense to break
> >> > them up into more manageable chunks. This patch will aid us.
> >> >
> >> > Signed-off-by: Lee Jones <lee.jones@...aro.org>
> >>
> >> I understand you have used this approach before so:
> >> Acked-by: Linus Walleij <linus.walleij@...aro.org>
> >
> > Does this comment take back your previous one:
> >
> > NOTE: it seems this patch set contains some churn. First you
> > add in the forked device init, put in a big chunk of code and
> > then in the *same* patch set delete it again. It's not like
> > we're dying to see all the development history... can this
> > be squashed down a bit?
> >
> > ... hence leave the patch-set as it is?
> 
> No. I just meant leave it like that for the devices outside of this
> set.
> 
> If you're adding and then removing *all* of them in this set,
> why add them in the first place?

So that there's no breakage during bisection.

You should be able to roll the kernel back in between each of these
patches and there to be full compatibility at each point. At least
that was the intention. Is that wrong?

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/