From: b.zolnierkie@samsung.com (Bartlomiej Zolnierkiewicz)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] ARM: multi_v7_defconfig: Enable shmobile platforms
Date: Mon, 01 Sep 2014 12:47:38 +0200 [thread overview]
Message-ID: <3021375.opancsXhz0@amdc1032> (raw)
In-Reply-To: <0a6f01cfc432$507900f0$f16b02d0$@samsung.com>
Hi,
On Saturday, August 30, 2014 06:10:59 PM Kukjin Kim wrote:
> Arnd Bergmann wrote:
> >
> Hi,
>
> > On Friday 29 August 2014 20:05:49 Bartlomiej Zolnierkiewicz wrote:
> > > I've been looking lately into making it possible to easily go
> > > from multi_v7_defconfig config to a single platform one (in my
> > > case Exynos one) and removing the need to keep the latter (i.e.
> > > exynos_defconfig) in the kernel tree in the long-term.
> > >
> Why? I don't have any idea why we should use only multi_v7_defconfig for each
> hardware platform. In my understanding, multi_v7_defconfig can be used for one
> kernel image can support all of the platforms but it doesn't mean it should be
In my long-term "plan" both configs should be available but one should
be generated from the other. Either way should be okay for me: multi ->
single platform or single platforms(s) -> multi.
[ Please note that if you take multi_v7_defconfig and disable support
for all archs besides Exynos (trivial operation even when done by
hand) you end up with platform specific kernel config. ]
Pros:
- less code in kernel
- concentrated testing efforts
- configs don't go out-of-sync with each other
- less maintainance burden
Cons:
- fewer config options may be covered than with two independent configs
> used for each platform. And I think, if we cannot maintain each platform's
> defconfig in mainline, it will be kept in each SoC vendor and it is not a good
It seems that currently in case of our internal kernel trees the custom
kernel configs are always used instead of either exynos_defconfig or
multi_v7_defconfig. I think that there is a big room for improvement
here.
> way. I mean both defconfigs has each value in mainline, exynos_defconfig should
> be updated though ;)
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
next prev parent reply other threads:[~2014-09-01 10:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-28 14:00 [PATCH 1/2] ARM: multi_v7_defconfig: Enable shmobile platforms Geert Uytterhoeven
2014-08-28 14:00 ` [PATCH 2/2] [RFC] ARM: Set CONFIG_LOCALVERSION in multi v5/v7 defconfigs Geert Uytterhoeven
2014-08-28 23:23 ` [PATCH 1/2] ARM: multi_v7_defconfig: Enable shmobile platforms Simon Horman
2014-08-29 18:05 ` Bartlomiej Zolnierkiewicz
2014-08-29 18:08 ` Bartlomiej Zolnierkiewicz
2014-08-29 20:11 ` Arnd Bergmann
2014-08-30 9:10 ` Kukjin Kim
2014-09-01 8:58 ` Arnd Bergmann
2014-09-01 10:47 ` Bartlomiej Zolnierkiewicz [this message]
2014-08-30 9:32 ` Geert Uytterhoeven
2014-09-01 8:24 ` Arnd Bergmann
2014-09-01 1:54 ` Simon Horman
2014-09-01 12:42 ` Bartlomiej Zolnierkiewicz
2014-09-01 13:19 ` Simon Horman
2014-09-10 0:48 ` Simon Horman
2014-11-25 15:08 ` Geert Uytterhoeven
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=3021375.opancsXhz0@amdc1032 \
--to=b.zolnierkie@samsung.com \
--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