[PATCH 0/3] s/FOOTBRIDGE/ARCH_FOOTBRIDGE/

[PATCH 0/3] s/FOOTBRIDGE/ARCH_FOOTBRIDGE/

[Uwe Kleine-König]

Hello Russell,

I'm not sure that FOOTBRIDGE and ARCH_FOOTBRIDGE are semantically
identical; if not, feel free to nack this series.

Best regards
Uwe

Uwe Kleine-K?nig (3):
  serial: DC21285: depend on ARCH_FOOTBRIDGE instead of FOOTBRIDGE
  watchdog: get rid of FOOTBRIDGE in dependencies
  ARM: drop Kconfig symbol FOOTBRIDGE

 arch/arm/Kconfig                 |  1 -
 arch/arm/Kconfig.debug           | 14 +++++++-------
 arch/arm/mach-footbridge/Kconfig |  4 ----
 drivers/tty/serial/Kconfig       |  2 +-
 drivers/watchdog/Kconfig         |  4 ++--
 5 files changed, 10 insertions(+), 15 deletions(-)

-- 
2.0.0

[PATCH 1/3] serial: DC21285: depend on ARCH_FOOTBRIDGE instead of FOOTBRIDGE

[Uwe Kleine-König]

The Kconfig symbol FOOTBRIDGE is only defined if ARCH_FOOTBRIDGE is
enabled and the latter unconditionally selects the former. So they are
either both selected or none and so they are equivalent. To allow
removing FOOTBRIDGE switch the dependency of SERIAL_21285 to
ARCH_FOOTBRIDGE.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-serial at vger.kernel.org
---
 drivers/tty/serial/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index fb57159bad3a..570ca2ff55d1 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -380,7 +380,7 @@ config SERIAL_ZS_CONSOLE
 
 config SERIAL_21285
 	tristate "DC21285 serial port support"
-	depends on FOOTBRIDGE
+	depends on ARCH_FOOTBRIDGE
 	select SERIAL_CORE
 	help
 	  If you have a machine based on a 21285 (Footbridge) StrongARM(R)/
-- 
2.0.0

[PATCH 2/3] watchdog: get rid of FOOTBRIDGE in dependencies

[Uwe Kleine-König]

The Kconfig symbol FOOTBRIDGE is only defined if ARCH_FOOTBRIDGE is
enabled and the latter unconditionally selects the former. So they are
either both selected or none and so they are equivalent. To allow
removing FOOTBRIDGE switch the dependency of 21285_WATCHDOG to
ARCH_FOOTBRIDGE. As ARCH_NETWINDER depends on ARCH_FOOTBRIDGE dropping
FOOTBRIDGE from 977_WATCHDOG's "depends on FOOTBRIDGE && ARCH_NETWINDER"
doesn't change anything.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
Cc: Wim Van Sebroeck <wim@iguana.be>
Cc: linux-watchdog at vger.kernel.org
---
 drivers/watchdog/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 76dd54122f76..0dc12d6de265 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -149,7 +149,7 @@ config AT91SAM9X_WATCHDOG
 
 config 21285_WATCHDOG
 	tristate "DC21285 watchdog"
-	depends on FOOTBRIDGE
+	depends on ARCH_FOOTBRIDGE
 	help
 	  The Intel Footbridge chip contains a built-in watchdog circuit. Say Y
 	  here if you wish to use this. Alternatively say M to compile the
@@ -163,7 +163,7 @@ config 21285_WATCHDOG
 
 config 977_WATCHDOG
 	tristate "NetWinder WB83C977 watchdog"
-	depends on FOOTBRIDGE && ARCH_NETWINDER
+	depends on ARCH_NETWINDER
 	help
 	  Say Y here to include support for the WB977 watchdog included in
 	  NetWinder machines. Alternatively say M to compile the driver as
-- 
2.0.0

[PATCH 3/3] ARM: drop Kconfig symbol FOOTBRIDGE

[Uwe Kleine-König]

The Kconfig symbols FOOTBRIDGE and ARCH_FOOTBRIDGE are equivalent so the
former can be substituted by the latter. The two previous patches do the
same for the other occurences of FOOTBRIDGE and so this symbol can be
removed now.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 arch/arm/Kconfig                 |  1 -
 arch/arm/Kconfig.debug           | 14 +++++++-------
 arch/arm/mach-footbridge/Kconfig |  4 ----
 3 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 245058b3b0ef..efb20226f95e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -442,7 +442,6 @@ config ARCH_EP93XX
 config ARCH_FOOTBRIDGE
 	bool "FootBridge"
 	select CPU_SA110
-	select FOOTBRIDGE
 	select GENERIC_CLOCKEVENTS
 	select HAVE_IDE
 	select NEED_MACH_IO_H if !MMU
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 8f90595069a1..6b69a5dc9a79 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -195,14 +195,14 @@ choice
 
 	config DEBUG_DC21285_PORT
 		bool "Kernel low-level debugging messages via footbridge serial port"
-		depends on FOOTBRIDGE
+		depends on ARCH_FOOTBRIDGE
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to the serial port in the DC21285 (Footbridge).
 
 	config DEBUG_FOOTBRIDGE_COM1
 		bool "Kernel low-level debugging messages via footbridge 8250 at PCI COM1"
-		depends on FOOTBRIDGE
+		depends on ARCH_FOOTBRIDGE
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to the 8250 at PCI COM1.
@@ -1031,7 +1031,7 @@ config DEBUG_UART_PL01X
 # Compatibility options for 8250
 config DEBUG_UART_8250
 	def_bool ARCH_DOVE || ARCH_EBSA110 || \
-		(FOOTBRIDGE && !DEBUG_DC21285_PORT) || \
+		(ARCH_FOOTBRIDGE && !DEBUG_DC21285_PORT) || \
 		ARCH_GEMINI || ARCH_IOP13XX || ARCH_IOP32X || \
 		ARCH_IOP33X || ARCH_IXP4XX || ARCH_KIRKWOOD || \
 		ARCH_LPC32XX || ARCH_MV78XX0 || ARCH_ORION5X || ARCH_RPC
@@ -1071,7 +1071,7 @@ config DEBUG_UART_PHYS
 				DEBUG_S3C2410_UART1)
 	default 0x50008000 if DEBUG_S3C24XX_UART && (DEBUG_S3C_UART2 || \
 				DEBUG_S3C2410_UART2)
-	default 0x7c0003f8 if FOOTBRIDGE
+	default 0x7c0003f8 if ARCH_FOOTBRIDGE
 	default 0x80070000 if DEBUG_IMX23_UART
 	default 0x80074000 if DEBUG_IMX28_UART
 	default 0x80230000 if DEBUG_PICOXCELL_UART
@@ -1159,7 +1159,7 @@ config DEBUG_UART_VIRT
 	default 0xfed64000 if DEBUG_RK29_UART1 || DEBUG_RK3X_UART2
 	default 0xfed68000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3
 	default 0xfedc0000 if ARCH_EP93XX
-	default 0xfee003f8 if FOOTBRIDGE
+	default 0xfee003f8 if ARCH_FOOTBRIDGE
 	default 0xfee20000 if DEBUG_NSPIRE_CLASSIC_UART || DEBUG_NSPIRE_CX_UART
 	default 0xfee82340 if ARCH_IOP13XX
 	default 0xfef00000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
@@ -1175,7 +1175,7 @@ config DEBUG_UART_VIRT
 config DEBUG_UART_8250_SHIFT
 	int "Register offset shift for the 8250 debug UART"
 	depends on DEBUG_LL_UART_8250 || DEBUG_UART_8250
-	default 0 if FOOTBRIDGE || ARCH_IOP32X
+	default 0 if ARCH_FOOTBRIDGE || ARCH_IOP32X
 	default 2
 
 config DEBUG_UART_8250_WORD
@@ -1191,7 +1191,7 @@ config DEBUG_UART_8250_WORD
 config DEBUG_UART_8250_FLOW_CONTROL
 	bool "Enable flow control for 8250 UART"
 	depends on DEBUG_LL_UART_8250 || DEBUG_UART_8250
-	default y if ARCH_EBSA110 || FOOTBRIDGE || ARCH_GEMINI || ARCH_RPC
+	default y if ARCH_EBSA110 || ARCH_FOOTBRIDGE || ARCH_GEMINI || ARCH_RPC
 
 config DEBUG_UNCOMPRESS
 	bool
diff --git a/arch/arm/mach-footbridge/Kconfig b/arch/arm/mach-footbridge/Kconfig
index 07152d00fc50..98d1dae727b6 100644
--- a/arch/arm/mach-footbridge/Kconfig
+++ b/arch/arm/mach-footbridge/Kconfig
@@ -79,10 +79,6 @@ config ARCH_NETWINDER
 
 endmenu
 
-# Footbridge support
-config FOOTBRIDGE
-	bool
-
 # Footbridge in host mode
 config FOOTBRIDGE_HOST
 	bool
-- 
2.0.0

[PATCH 0/3] s/FOOTBRIDGE/ARCH_FOOTBRIDGE/

[Russell King - ARM Linux]

On Tue, Jul 01, 2014 at 10:37:03PM +0200, Uwe Kleine-K?nig wrote:
> Hello Russell,
> 
> I'm not sure that FOOTBRIDGE and ARCH_FOOTBRIDGE are semantically
> identical; if not, feel free to nack this series.

CONFIG_FOOTBRIDGE means that we have a DC21285 in the system.  We
used to have ARCH_FOOTBRIDGE and ARCH_CO285 which both selected
CONFIG_FOOTBRIDGE.

ARCH_FOOTBRIDGE was for either host or addin mode using a PAGE_OFFSET
of 0xc0000000.  ARCH_CO285 had a PAGE_OFFSET of 0x80000000 as they
wanted to be able to map almost all of PCI memory space.

So think of CONFIG_FOOTBRIDGE as meaning that we have the physical
device, and CONFIG_ARCH_FOOTBRIDGE meaning that we want to support
boards with the device on.

So, it may make sense to rename CONFIG_FOOTBRIDGE to CONFIG_DC21285
if that makes the configuration symbol intention clearer.

This is why I prefer even hidden symbols to have a help text - having
the help text explains why they exist...

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH 0/3] s/FOOTBRIDGE/ARCH_FOOTBRIDGE/

[Uwe Kleine-König]

Hello Russell,

On Tue, Jul 01, 2014 at 11:14:28PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jul 01, 2014 at 10:37:03PM +0200, Uwe Kleine-K?nig wrote:
> > I'm not sure that FOOTBRIDGE and ARCH_FOOTBRIDGE are semantically
> > identical; if not, feel free to nack this series.
> 
> CONFIG_FOOTBRIDGE means that we have a DC21285 in the system.  We
> used to have ARCH_FOOTBRIDGE and ARCH_CO285 which both selected
> CONFIG_FOOTBRIDGE.
> 
> ARCH_FOOTBRIDGE was for either host or addin mode using a PAGE_OFFSET
> of 0xc0000000.  ARCH_CO285 had a PAGE_OFFSET of 0x80000000 as they
> wanted to be able to map almost all of PCI memory space.
> 
> So think of CONFIG_FOOTBRIDGE as meaning that we have the physical
> device, and CONFIG_ARCH_FOOTBRIDGE meaning that we want to support
> boards with the device on.
I expected something like that. Is it possible to "have" the device on a
cpu != StrongARM? If so I wonder why ARCH_FOOTBRIDGE is a "ARM system
type". And if not, wouldn't it be possible and better to have all
platforms which select CPU_SA110 (ARCH_EBSA110, ARCH_FOOTBRIDGE; what
about RPC?) in a single mach dir and make FOOTBRIDGE an option there?

It's hard to find information on the net about these chips, even
http://developer.intel.com/design/strong/sa110.htm only talks about x86
stuff only, so please excuse my unknowingness.
 
> So, it may make sense to rename CONFIG_FOOTBRIDGE to CONFIG_DC21285
> if that makes the configuration symbol intention clearer.
Maybe even better CONFIG_HAS_DC21285?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 0/3] s/FOOTBRIDGE/ARCH_FOOTBRIDGE/

[Russell King - ARM Linux]

On Wed, Jul 02, 2014 at 09:13:12AM +0200, Uwe Kleine-K?nig wrote:
> I expected something like that. Is it possible to "have" the device on a
> cpu != StrongARM? If so I wonder why ARCH_FOOTBRIDGE is a "ARM system
> type". And if not, wouldn't it be possible and better to have all
> platforms which select CPU_SA110 (ARCH_EBSA110, ARCH_FOOTBRIDGE; what
> about RPC?) in a single mach dir and make FOOTBRIDGE an option there?
> 
> It's hard to find information on the net about these chips, even
> http://developer.intel.com/design/strong/sa110.htm only talks about x86
> stuff only, so please excuse my unknowingness.

The Footbridge is a companion device to the StrongARM - the two are
designed to work together.  It probably is possible that the Footbridge
could have been connected to another CPU with appropriate interfacing,
but that never happened.

The thing to realise is that the Footbridge is a little more than just
a pure PCI bridge.  It's also the SDRAM controller, UART port and
provides support for a non-PCI expansion bus.

Probably the best model which represents it is in actual fact the x86
PC in years gone by.  The separate processor (StrongARM) with the PCI
northbridge (Footbridge) which couples the processor to the rest of
the system.  Some Footbridge systems really do approximate the x86
PC with a southbridge attached (eg, Netwinder did this, with a real
southbridge providing keyboard, mouse, bridge to the ISA bus, IDE etc).

You could also think of it as an early SoC which hasn't quite integrated
the CPU, as the Footbridge defines quite a lot about how the physical
system memory map looks.

The difference between the CO285 and the EBSA285 is that CO285 was
exclusively add-in mode (in other words, CO285 was Linux running on
a DC21285 based card you could plug into your PC and wanted to map
large spaces of PCI memory space) whereas the EBSA285 was the much
smaller end of the add-in mode, and also host mode (StrongARM being
responsible for PCI configuration etc.)

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.