All of lore.kernel.org
 help / color / mirror / Atom feed
From: dave.martin@linaro.org (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 2/5] ARM: SMP: Refactor Kconfig to be more maintainable
Date: Wed, 14 Dec 2011 11:36:55 +0000	[thread overview]
Message-ID: <20111214113655.GA2568@linaro.org> (raw)
In-Reply-To: <20111213201137.GA31437@huya.qualcomm.com>

On Tue, Dec 13, 2011 at 12:11:37PM -0800, David Brown wrote:
> On Tue, Dec 13, 2011 at 05:56:30PM +0000, Dave Martin wrote:
> > Making SMP depend on (huge list of MACH_ and ARCH_ configs) is
> > bothersome to maintain and likely to lead to merge conflicts.
> 
> > diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
> > index ebde97f..e6beaff 100644
> > --- a/arch/arm/mach-msm/Kconfig
> > +++ b/arch/arm/mach-msm/Kconfig
> > @@ -67,6 +67,7 @@ config MSM_SOC_REV_A
> >  	bool
> >  config  ARCH_MSM_SCORPIONMP
> >  	bool
> > +	select HAVE_SMP
> >  
> >  config  ARCH_MSM_ARM11
> >  	bool
> 
> The ARCH_MSM_SCORPIONMP config's only purpose was to enable SMP higher
> up.  We might as well eliminate ARCH_MSM_SCORPIONMP entirely, and just
> select HAVE_SMP in ARCH_MSM8X60 and ARCH_MSM8960.

First and foremost, I'm just refactoring with this series.  I've
included other trivial changes suggested by other people where the
effect is clear and straightforward.


Removing ARCH_MSM_SCORPIONMP is not quite trivial, though:

arch/arm/mach-msm/timer.c:
#ifdef CONFIG_ARCH_MSM_SCORPIONMP
	writel(DGT_CLK_CTL_DIV_4, MSM_TMR_BASE + DGT_CLK_CTL);
#endif

This suggests that ARCH_MSM_SCORPIONMP may mean more than just
"HAVE_SMP".

Also,

arch/arm/Kconfig:config HAVE_SMP
	select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP

...and

arch/arm/Kconfig:config LOCAL_TIMERS
	select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)


Now, we could list the affected MSM boards longhand in those
dependencies, but that's just reintroducing some of the exact kind of
kconfig clunkiness I'm trying to remove: those lists are obviously
liable to grow over time.

Configs like this also look like they may be incompatible with the
single kernel binary goal: if any of the boards supported by the kernel
have the ARM SCU and/or TWD unit, surely we should be able to enable the
support in the kernel?


If you can see a nice way to resolve those issues though, feel free to
propose a patch and I'll append it to the series.

> 
> Also, be sure to run ./scripts/get_maintainer.pl on your patch so that
> the proper people get addressed by the message.  Otherwise, people
> might miss patches.

Argh, my metadata for that series was mangled -- I put together a long
CC list based on but it never got used :(

Thanks for highlighting that... I'll repost.  This probably explains why
I didn't get much feedback.

Cheers
---Dave

  reply	other threads:[~2011-12-14 11:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-13 17:56 [PATCH v4 0/5] Refactor common Kconfigs for easier maintenance Dave Martin
2011-12-13 17:56 ` [PATCH v4 1/5] ARM: l2x0/pl310: Refactor Kconfig to be more maintainable Dave Martin
2011-12-13 17:56 ` [PATCH v4 2/5] ARM: SMP: " Dave Martin
2011-12-13 20:11   ` David Brown
2011-12-14 11:36     ` Dave Martin [this message]
2011-12-14 17:46       ` David Brown
2011-12-14 18:20         ` Dave Martin
2011-12-14 17:31   ` Linus Walleij
2011-12-18  4:22   ` Olof Johansson
2011-12-13 17:56 ` [PATCH v4 3/5] omap4: Unconditionally require l2x0 L2 cache controller support Dave Martin
2011-12-13 17:56 ` [PATCH v4 4/5] highbank: " Dave Martin
2011-12-13 17:56 ` [PATCH v4 5/5] imx6q: Remove unconditional dependency on l2x0 L2 cache support Dave Martin

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=20111214113655.GA2568@linaro.org \
    --to=dave.martin@linaro.org \
    --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 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.