From: Simon Horman <horms@verge.net.au>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [GIT PULL 00/28] Renesas ARM based SoC updates for v3.14
Date: Wed, 04 Dec 2013 06:26:07 +0000 [thread overview]
Message-ID: <20131204062605.GA6283@verge.net.au> (raw)
In-Reply-To: <20131204011745.GD20332@quad.lixom.net>
On Tue, Dec 03, 2013 at 05:17:45PM -0800, Olof Johansson wrote:
> Hi Simon,
>
> On Mon, Dec 02, 2013 at 11:18:47AM +0900, Simon Horman wrote:
> > Hi Kevin, Hi Olof, Hi Arnd,
> >
> > please consider these Renesas ARM based SoC updates for v3.14.
> >
> > This pull-request is based on "[GIT PULL 00/16] Renesas ARM based SoC
> > defconfig updates for v3.14" (tag: renesas-defconfig-for-v3.14) which I
> > send a pull-request for on Thursday. The reason for this is to include
> > defconfig updates for the emma2 based kzm9d which are required in order to
> > avoid a build regression when using the defconfig for that board.
>
> If you can get a build regression due to an outdated defconfig, then you're
> likely missing some dependencies in your Kconfig? You could hit the same state
> of configurations through randconfig. So I think fixing the dependencies is
> better than relying on the defconfig branch in this case.
>
> Would you mind doing it that way instead? It'd reduce our dependencies and in
> general it's a more appropriate approach.
The problem that I was trying to address was that
"ARM: shmobile: Remove legacy KZM9D board code" removes
legacy board code and thus the following line from
arch/arm/mach-shmobile/Makefile.boot
loadaddr-$(CONFIG_MACH_KZM9D) += 0x40008000
My understanding is that a result of this change is that
CONFIG_AUTO_ZRELADDR is now needed in order for the kernel
to compile.
Is it appropriate to set CONFIG_AUTO_ZRELADDR in Kconfig?
Or is there another approach that I could take?
> > This pull-request also includes defconfig changes related to renaming
> > ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY. These are also to avoid build
> > regressions when using defconfigs.
>
> So what happens if someone has an old defconfig in their build environment
> (i.e. hosted outside of the kernel tree), will they see breakage?
Yes, I believe so.
> If so, you should probably add a new option ARCH_SHMOBILE_MULTI or similar.
We have added ARCH_SHMOBILE_MULTI.
The changelog entry describes the motivation for the change as well as I
could. My view on this is that its global change that avoids an even more
widespread global change.
From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY
SH-Mobile platforms are transitioning from non-multiplatform to
multiplatform kernel. A new ARCH_SHMOBILE_MULTI configuration symbol has
been created to group all multiplatform-enabled SH-Mobile SoCs. The
existing ARCH_SHMOBILE configuration symbol groups SoCs that haven't
been converted yet.
This arrangement works fine for the arch/ code, but lots of drivers
needed on both ARCH_SHMOBILE and ARCH_SHMOBILE_MULTI depend on
ARCH_SHMOBILE only. In order to avoid changing them, rename
ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY, and create a new boolean
ARCH_SHMOBILE configuration symbol that is selected by both
ARCH_SHMOBILE_LEGACY and ARCH_SHMOBILE_MULTI.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> We had similar issues with the first attempt to go multiplatform on Exynos,
> some existing defconfigs wouldn't build a usable kernel any more due to new
> options, so Arnd had to do it the other way (that code is still unmerged
> though).
prev parent reply other threads:[~2013-12-04 6:26 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-02 2:18 [GIT PULL 00/28] Renesas ARM based SoC updates for v3.14 Simon Horman
2013-12-02 2:19 ` [PATCH 01/28] ARM: shmobile: r8a7778: add I2C clock for DT Simon Horman
2013-12-02 2:19 ` [PATCH 02/28] ARM: shmobile: r8a7779: " Simon Horman
2013-12-02 2:19 ` [PATCH 03/28] ARM: shmobile: Select IRQC in case of the r8a7791 SoC Simon Horman
2013-12-02 2:19 ` [PATCH 04/28] ARM: shmobile: r8a7791 PFC platform device support Simon Horman
2013-12-02 2:19 ` [PATCH 05/28] ARM: shmobile: Select GPIO in case of the r8a7791 SoC Simon Horman
2013-12-02 2:19 ` [PATCH 06/28] ARM: shmobile: r8a7791 GPIO platform device support Simon Horman
2013-12-02 2:19 ` [PATCH 07/28] ARM: shmobile: r8a73a4: don't use named irq for DMAEngine Simon Horman
2013-12-02 2:19 ` [PATCH 08/28] ARM: shmobile: Select GPIO in case of the r7s72100 SoC Simon Horman
2013-12-02 2:19 ` [PATCH 09/28] ARM: shmobile: r8a7778: add MMCIF clock support for DT Simon Horman
2013-12-02 2:19 ` [PATCH 10/28] ARM: shmobile: r8a7778: add SDHI " Simon Horman
2013-12-02 2:19 ` [PATCH 11/28] ARM: shmobile: r8a7779: " Simon Horman
2013-12-02 2:19 ` [PATCH 12/28] ARM: shmobile: r8a7790: Add USBHS clock support Simon Horman
2013-12-02 2:19 ` [PATCH 13/28] ARM: shmobile: r8a7790: add QSPI support Simon Horman
2013-12-02 2:19 ` [PATCH 14/28] ARM: shmobile: Enable MTU2 on r7s72100 Simon Horman
2013-12-02 2:19 ` [PATCH 15/28] ARM: shmobile: Add shared EMEV2 code for ->init_machine() Simon Horman
2013-12-02 2:19 ` [PATCH 16/28] ARM: shmobile: Use ->init_late() in shared EMEV2 case Simon Horman
2013-12-02 2:19 ` [PATCH 17/28] ARM: shmobile: Remove legacy KZM9D board code Simon Horman
2013-12-02 2:19 ` [PATCH 18/28] ARM: shmobile: Remove legacy platform devices from EMEV2 SoC code Simon Horman
2013-12-02 2:19 ` [PATCH 19/28] ARM: shmobile: r8a7778: add HSPI clock support for DT Simon Horman
2013-12-02 2:19 ` [PATCH 20/28] ARM: shmobile: Select USE_OF on EMEV2 Simon Horman
2013-12-02 2:19 ` [PATCH 21/28] ARM: shmobile: r8a7791: Add DU and LVDS clocks Simon Horman
2013-12-02 2:19 ` [PATCH 22/28] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY Simon Horman
2013-12-02 2:19 ` [PATCH 23/28] ARM: shmobile: Add r8a7790 clocks for thermal devices Simon Horman
2013-12-02 2:19 ` [PATCH 24/28] ARM: shmobile: Add r8a7791 thermal platform device Simon Horman
2013-12-02 2:19 ` [PATCH 25/28] ARM: shmobile: Add r8a7791 clocks for thermal devices Simon Horman
2013-12-02 2:19 ` [PATCH 26/28] ARM: shmobile: r8a7790: care EXTAL divider settings Simon Horman
2013-12-02 2:19 ` [PATCH 27/28] ARM: shmobile: r8a7790: fixup I2C clock source Simon Horman
2013-12-02 2:19 ` [PATCH 28/28] ARM: shmobile: r8a7790: tidyup clock table order Simon Horman
2013-12-04 1:17 ` [GIT PULL 00/28] Renesas ARM based SoC updates for v3.14 Olof Johansson
2013-12-04 6:26 ` Simon Horman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131204062605.GA6283@verge.net.au \
--to=horms@verge.net.au \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).