All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kukjin Kim <kgene.kim@samsung.com>
To: 'Sachin Kamat' <sachin.kamat@linaro.org>,
	linux-samsung-soc@vger.kernel.org
Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	mark.rutland@arm.com
Subject: RE: [PATCH Resend 1/3] ARM: EXYNOS: Consolidate Kconfig entries
Date: Thu, 20 Mar 2014 14:54:45 +0900	[thread overview]
Message-ID: <02f701cf4400$e561e2c0$b025a840$@samsung.com> (raw)
In-Reply-To: <1395224705-2935-1-git-send-email-sachin.kamat@linaro.org>

Sachin Kamat wrote:
> 
> Instead of repeating the Kconfig entries for every SoC, move them under
> ARCH_EXYNOS4 and 5 and move the entries common to both 4 and 5 under
> ARCH_EXYNOS. Also, since the individual SoCs do not have any specific
> machine/platform code, keep them as boolean symbols instead of user
> selectable and select them from Exynos4 and 5 config symbols. Individual
> SoC symbols can be removed eventually once the driver Kconfig dependencies
> on these symbols are removed.
> 
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> Acked-by: Tomasz Figa <t.figa@samsung.com>
> ---
> This is a resend of the series rebased on top of latest linux-next and
> Tomasz Figa's PM consolidation series 1 and 2.
> ---
>  arch/arm/Kconfig             |   10 +++++
>  arch/arm/mach-exynos/Kconfig |   89
+++++++++++---------------------------
> ----
>  2 files changed, 33 insertions(+), 66 deletions(-)
> 
Hmm...I'm still thinking whether we don't need to select some specific
Exynos SoCs. Because actually we're implement/develop some features based on
mainline kernel and sometimes the features are not valid on all of Exynos4
or Exynos5. Even though they are not in mainline, for mass product it's true
that Samsung needs to do it. It's another thing we have a plan for them or
not.

So in my opinion, basically consolidation something is usually good but it's
not always good so we need to provide a way to use one of both.

Thanks,
Kukjin

WARNING: multiple messages have this Message-ID (diff)
From: kgene.kim@samsung.com (Kukjin Kim)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH Resend 1/3] ARM: EXYNOS: Consolidate Kconfig entries
Date: Thu, 20 Mar 2014 14:54:45 +0900	[thread overview]
Message-ID: <02f701cf4400$e561e2c0$b025a840$@samsung.com> (raw)
In-Reply-To: <1395224705-2935-1-git-send-email-sachin.kamat@linaro.org>

Sachin Kamat wrote:
> 
> Instead of repeating the Kconfig entries for every SoC, move them under
> ARCH_EXYNOS4 and 5 and move the entries common to both 4 and 5 under
> ARCH_EXYNOS. Also, since the individual SoCs do not have any specific
> machine/platform code, keep them as boolean symbols instead of user
> selectable and select them from Exynos4 and 5 config symbols. Individual
> SoC symbols can be removed eventually once the driver Kconfig dependencies
> on these symbols are removed.
> 
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> Acked-by: Tomasz Figa <t.figa@samsung.com>
> ---
> This is a resend of the series rebased on top of latest linux-next and
> Tomasz Figa's PM consolidation series 1 and 2.
> ---
>  arch/arm/Kconfig             |   10 +++++
>  arch/arm/mach-exynos/Kconfig |   89
+++++++++++---------------------------
> ----
>  2 files changed, 33 insertions(+), 66 deletions(-)
> 
Hmm...I'm still thinking whether we don't need to select some specific
Exynos SoCs. Because actually we're implement/develop some features based on
mainline kernel and sometimes the features are not valid on all of Exynos4
or Exynos5. Even though they are not in mainline, for mass product it's true
that Samsung needs to do it. It's another thing we have a plan for them or
not.

So in my opinion, basically consolidation something is usually good but it's
not always good so we need to provide a way to use one of both.

Thanks,
Kukjin

  parent reply	other threads:[~2014-03-20  5:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-19 10:25 [PATCH Resend 1/3] ARM: EXYNOS: Consolidate Kconfig entries Sachin Kamat
2014-03-19 10:25 ` Sachin Kamat
2014-03-19 10:25 ` [PATCH Resend 2/3] ARM: EXYNOS: Consolidate CPU init code Sachin Kamat
2014-03-19 10:25   ` Sachin Kamat
2014-03-20 19:33   ` Kukjin Kim
2014-03-20 19:33     ` Kukjin Kim
2014-03-19 10:25 ` [PATCH Resend 3/3] ARM: EXYNOS: Map SYSRAM address through DT Sachin Kamat
2014-03-19 10:25   ` Sachin Kamat
2014-04-16 11:06   ` Chanwoo Choi
2014-04-16 11:06     ` Chanwoo Choi
2014-04-16 11:52     ` Sachin Kamat
2014-04-16 11:52       ` Sachin Kamat
2014-03-20  5:54 ` Kukjin Kim [this message]
2014-03-20  5:54   ` [PATCH Resend 1/3] ARM: EXYNOS: Consolidate Kconfig entries Kukjin Kim
2014-03-20  6:05   ` Kukjin Kim
2014-03-20  6:05     ` Kukjin Kim

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='02f701cf4400$e561e2c0$b025a840$@samsung.com' \
    --to=kgene.kim@samsung.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=sachin.kamat@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.