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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200704220110.54587.arnd@arndb.de>
Date:	Sun, 22 Apr 2007 01:10:54 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Martin Schwidefsky <schwidefsky@...ibm.com>
Cc:	linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: [PATCH 2/8] Kconfig: unwanted menus for s390.

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.

	Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/