Re: [PATCH 2/8] Kconfig: unwanted menus for s390.

Arnd Bergmann
2007-04-21T23:11:13Z

On Friday 20 April 2007, Martin Schwidefsky wrote:
> diff -urpN linux-2.6/drivers/char/ipmi/Kconfig linux-2.6-patched/drivers/char/ipmi/Kconfig
> --- linux-2.6/drivers/char/ipmi/Kconfig 2007-02-04 19:44:54.000000000 +0100
> +++ linux-2.6-patched/drivers/char/ipmi/Kconfig 2007-04-19 15:49:55.000000000 +0200
> @@ -3,6 +3,8 @@
>  #
>
>  menu "IPMI"
> +       depends on !S390
> +
>  config IPMI_HANDLER
>         tristate 'IPMI top-level message handler'
>         help

I think I made this comment the last time we discussed this topic, but don't
remember the exact outcome.

I would prefer to not have 'depends on !S390' but rather 'depends on MMIO',
because that is what really drives stuff like IPMI: they expect the device
to be reachable through the use of ioremap or inX/outX instructions, which
don't exist on s390.

While it's unlikely that another architecture has the same restriction,
it expresses much clearer what you mean.

In drivers/Kconfig, you can then simply add a

config MMIO
def_bool !S390

There are a few exceptions though, that I think should not depend on MMIO:

> --- linux-2.6/drivers/dma/Kconfig 2007-04-19 15:24:33.000000000 +0200
> +++ linux-2.6-patched/drivers/dma/Kconfig 2007-04-19 15:49:55.000000000 +0200
> @@ -3,6 +3,7 @@
> #
>
> menu "DMA Engine support"
> + depends on !S390
>
> config DMA_ENGINE
> bool "Support for DMA engines"

I'd leave the menu enabled. If the DMA engine infrastructure becomes more widely
used, you may want to add an implementation for s390 using milicoded instructions
like xor-string or copy-page.

> diff -urpN linux-2.6/drivers/input/Kconfig linux-2.6-patched/drivers/input/Kconfig
> --- linux-2.6/drivers/input/Kconfig 2007-02-04 19:44:54.000000000 +0100
> +++ linux-2.6-patched/drivers/input/Kconfig 2007-04-19 15:49:55.000000000 +0200
> @@ -3,6 +3,7 @@
> #
>
> menu "Input device support"
> + depends on !S390
>
> config INPUT
> tristate "Generic input layer (needed for keyboard, mouse, ...)" if EMBEDDED

Probably leave this as !S390. One could imagine channel-attached input devices
or the idea of intepreting a terminal as an input device, but no driver currently
does and probably never will.

> diff -urpN linux-2.6/drivers/isdn/Kconfig linux-2.6-patched/drivers/isdn/Kconfig
> --- linux-2.6/drivers/isdn/Kconfig 2007-02-04 19:44:54.000000000 +0100
> +++ linux-2.6-patched/drivers/isdn/Kconfig 2007-04-19 15:49:55.000000000 +0200
> @@ -3,6 +3,7 @@
> #
>
> menu "ISDN subsystem"
> + depends on !S390
>
> config ISDN
> tristate "ISDN support"

Same here, actually there was an IBM 2216 ISDN adapter with channel attachment,
but I don't think anybody wants to add a driver for that one.

> diff -urpN linux-2.6/drivers/misc/Kconfig linux-2.6-patched/drivers/misc/Kconfig
> --- linux-2.6/drivers/misc/Kconfig 2007-04-19 15:24:35.000000000 +0200
> +++ linux-2.6-patched/drivers/misc/Kconfig 2007-04-19 15:49:55.000000000 +0200
> @@ -3,6 +3,7 @@
> #
>
> menu "Misc devices"
> + depends on !S390
>
> config IBM_ASM
> tristate "Device driver for IBM RSA service processor"

Maybe just leave the menu open, all drivers in it are already depending on PCI
or similar and someone might add a driver that does work on s390 here.

> diff -urpN linux-2.6/drivers/net/phy/Kconfig linux-2.6-patched/drivers/net/phy/Kconfig
> --- linux-2.6/drivers/net/phy/Kconfig 2007-02-04 19:44:54.000000000 +0100
> +++ linux-2.6-patched/drivers/net/phy/Kconfig 2007-04-19 15:49:55.000000000 +0200
> @@ -3,6 +3,7 @@
> #
>
> menu "PHY device support"
> + depends on !S390
>
> config PHYLIB
> tristate "PHY Device support and infrastructure"

Also depends on !S390, not MMIO. A future network adapter might give you access
to the phy device through other means than MMIO.

> diff -urpN linux-2.6/drivers/rtc/Kconfig linux-2.6-patched/drivers/rtc/Kconfig
> --- linux-2.6/drivers/rtc/Kconfig 2007-04-19 15:24:39.000000000 +0200
> +++ linux-2.6-patched/drivers/rtc/Kconfig 2007-04-19 15:49:55.000000000 +0200
> @@ -3,6 +3,7 @@
> #
>
> menu "Real Time Clock"
> + depends on !S390
>
> config RTC_LIB
> tristate

Applications might actually want to use the RTC interface to access the system time
or get accurate timers, but the rtc drivers are all very dependant on either MMIO
or I2C. Not sure what would be best here.