On Monday 16 June 2014 04:00:42 Tony Lindgren wrote:
> * Arnd Bergmann <a...@arndb.de> [140616 03:06]:
> > Commit 9851b662f659 ("ARM: use menuconfig for sub-arch menus") did more
> > than expected, which led to two OMAP specific bugs:
>
> It seems the commit above is not -rc cycle material at least not without
> proper testing. There's a good chance of breaking a lot of the existing
> .config files which can create a big mess as we've seen before.
Well, Kconfig is a big mess without it at the moment. The OMAP change
was definitely wrong there, but for all other platforms I don't see any
risk in applying it, because there is no semantic change, only cosmetic.
> > * Turning CONFIG_ARCH_OMAP into a user-selectable option makes it possible
> > to have a configuration with ARCH_OMAP enabled but none of the specific
> > OMAP SoCs enabled, which triggers a couple of link errors due to the
> > layout of the Makefile
>
> And so we have a regression to this old problem again :(
Yes, I didn't actually see this happen but from looking at the patch, I
concluded that it would likely be the case.
> > * The plat-omap menu still appears mixed into the normal menuconfig list,
> > which is confusing and inconsistent.
>
> That we should be able to remove completely soon but that's a
> separate patch..
Ok.
> > To make matters worse, the change did not enable CONFIG_ARCH_OMAP in the
> > defconfig files, which through some ripple effects disabled options that
> > were implicitly enabled from OMAP2, and that caused all machines to
> > fail booting with the unchanged config files.
> >
> > This reorders the OMAP Kconfig files some more, to be consistent with
> > the others, and also changes the defconfig files.
> >
> > Signed-off-by: Arnd Bergmann <a...@arndb.de>
> > ---
> > Tony, can you have a look at this please? I'd like to send out the
> > fixes for 3.16, but this is needed on top of Rob's Kconfig changes.
>
> Hmm why is this patch already in linux next before getting posted
> to the mailing lists?
I had applied Rob's patch to the fixes series but that broke all
multi_v7_defconfig runs on the boot test machines. I didn't want to
spend too much work on it over the weekend, but applied it so at least
today's linux-next wouldn't regress over last week's.
> > --- a/arch/arm/plat-omap/Kconfig
> > +++ b/arch/arm/plat-omap/Kconfig
> > @@ -1,6 +1,11 @@
> > -if ARCH_OMAP
> > +menuconfig ARCH_OMAP_ENABLE
> > + bool "TI OMAP platforms" if ARCH_MULTI_V6 || ARCH_MULTI_V7
> > + default ARCH_OMAP1
> >
> > -menu "TI OMAP Common Features"
> > +if ARCH_OMAP_ENABLE
> > +
> > +source "arch/arm/mach-omap1/Kconfig"
> > +source "arch/arm/mach-omap2/Kconfig"
>
> It seems to me this kind of change is going to break all the
> existing .config files unless they are manually updated. This
> includes all the distros and automated build systems. I'll look
> more at it, but my initial take is that we should be able to do
> this all with CONFIG_ARCH_OMAP + the selected OMAP SoC and should
> not introduce any new Kconfig options.
>
> For now I'd just leave out Rob's changed and this patch from fixes
> until they have been properly tested.
Let's see if others have similar opinions Rob's patch as a whole.
I'd still like to keep all the parts aside from the OMAP change
and just back out the change that caused the problems.
Does that seem reasonable to you?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
