[RFC PATCH] arm: msm: moved Kconfig machine entry into mach-msm

[RFC PATCH] arm: msm: moved Kconfig machine entry into mach-msm

[Daniel Walker]

Has anyone suggested this? It seems like it might reduce conflicts
in the Kconfig file.

Signed-off-by: Daniel Walker <dwalker@codeaurora.org>
---
 arch/arm/Kconfig               |   12 +-----------
 arch/arm/mach-msm/Kconfig.base |   13 +++++++++++++
 2 files changed, 14 insertions(+), 11 deletions(-)
 create mode 100644 arch/arm/mach-msm/Kconfig.base

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 88c97bc..e256564 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -590,17 +590,7 @@ config ARCH_PXA
 	help
 	  Support for Intel/Marvell's PXA2xx/PXA3xx processor line.
 
-config ARCH_MSM
-	bool "Qualcomm MSM"
-	select HAVE_CLK
-	select GENERIC_CLOCKEVENTS
-	select ARCH_REQUIRE_GPIOLIB
-	help
-	  Support for Qualcomm MSM/QSD based systems.  This runs on the
-	  apps processor of the MSM/QSD and depends on a shared memory
-	  interface to the modem processor which runs the baseband
-	  stack and controls some vital subsystems
-	  (clock and power control, etc).
+source "arch/arm/mach-msm/Kconfig.base"
 
 config ARCH_SHMOBILE
 	bool "Renesas SH-Mobile"
diff --git a/arch/arm/mach-msm/Kconfig.base b/arch/arm/mach-msm/Kconfig.base
new file mode 100644
index 0000000..184ac66
--- /dev/null
+++ b/arch/arm/mach-msm/Kconfig.base
@@ -0,0 +1,13 @@
+
+config ARCH_MSM
+	bool "Qualcomm MSM"
+	select HAVE_CLK
+	select GENERIC_CLOCKEVENTS
+	select ARCH_REQUIRE_GPIOLIB
+	help
+	  Support for Qualcomm MSM/QSD based systems.  This runs on the
+	  apps processor of the MSM/QSD and depends on a shared memory
+	  interface to the modem processor which runs the baseband
+	  stack and controls some vital subsystems
+	  (clock and power control, etc).
+
-- 
1.7.0.4

[RFC PATCH] arm: msm: moved Kconfig machine entry into mach-msm

[Russell King - ARM Linux]

On Thu, Oct 21, 2010 at 11:37:35AM -0700, Daniel Walker wrote:
> Has anyone suggested this? It seems like it might reduce conflicts
> in the Kconfig file.

How?  The choice normally has one entry for each mach- directory.
You're still going to have 'source' for each mach- directory, so
the chances of conflicts are no different.

Plus it increases the file count, makes things more indirect, and
therefore harder to follow.

[RFC PATCH] arm: msm: moved Kconfig machine entry into mach-msm

[Daniel Walker]

On Fri, 2010-10-22 at 08:49 +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 21, 2010 at 11:37:35AM -0700, Daniel Walker wrote:
> > Has anyone suggested this? It seems like it might reduce conflicts
> > in the Kconfig file.
> 
> How?  The choice normally has one entry for each mach- directory.
> You're still going to have 'source' for each mach- directory, so
> the chances of conflicts are no different.

The source lines would be mostly static.. We wouldn't have to modify
Kconfig to add new "select" statements to are entries. People end up
having to send you patches which do something then modify the Kconfig
(or in some cases they don't send them to you which is worse) in order
to reduce conflicts. With this change they wouldn't need to do that.

> Plus it increases the file count, makes things more indirect, and
> therefore harder to follow.

True. It's a trade off , but we already have this for the other menu
options further down the Kconfig.

Daniel
-- 
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.

[RFC PATCH] arm: msm: moved Kconfig machine entry into mach-msm

[Russell King - ARM Linux]

On Fri, Oct 22, 2010 at 08:20:00AM -0700, Daniel Walker wrote:
> On Fri, 2010-10-22 at 08:49 +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 21, 2010 at 11:37:35AM -0700, Daniel Walker wrote:
> > > Has anyone suggested this? It seems like it might reduce conflicts
> > > in the Kconfig file.
> > 
> > How?  The choice normally has one entry for each mach- directory.
> > You're still going to have 'source' for each mach- directory, so
> > the chances of conflicts are no different.
> 
> The source lines would be mostly static..

In practice, the entries here are mostly static already - the only
time that something gets added there is when a new class of machines
gets added.

> We wouldn't have to modify
> Kconfig to add new "select" statements to are entries. People end up
> having to send you patches which do something then modify the Kconfig
> (or in some cases they don't send them to you which is worse) in order
> to reduce conflicts. With this change they wouldn't need to do that.

As I say, the only time that these entries get touched is when a new
class of machines gets added - and given that people can't read (proven
by the number of times people get their entries out of order), they
should come through my tree.

> > Plus it increases the file count, makes things more indirect, and
> > therefore harder to follow.
> 
> True. It's a trade off , but we already have this for the other menu
> options further down the Kconfig.

Actually, it'll increase the chances of a conflict when a change is made
to it - because more machine classes will be visible to any particular
patch.  If we have two similarly named machine classes added at the same
time.

I think you're trying to make a mountain out of a mole hill.  This
hasn't been a problem to date.