Kconfig unmet dependency with RADIO_WL1273

Kconfig unmet dependency with RADIO_WL1273

[Luciano Coelho]

Hi Matti,

Johannes has just reported a problem in the Kconfig of radio-wl1273.  It
seems to select MFD_CORE, but if the platform doesn't support MFD, then
MFD_SUPPORT won't be selected and this kind of warning will come out:

warning: (OLPC_XO1_PM && OLPC_XO1_SCI && I2C_ISCH && GPIO_SCH && GPIO_RDC321X && RADIO_WL1273) 
                selects MFD_CORE which has unmet direct dependencies (MFD_SUPPORT)

I guess it must depend on MFD_SUPPORT, right? If that's the correct
solution, the following patch should fix the problem:

diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 52798a1..e87f544 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -425,7 +425,7 @@ config RADIO_TIMBERDALE
 
 config RADIO_WL1273
        tristate "Texas Instruments WL1273 I2C FM Radio"
-       depends on I2C && VIDEO_V4L2
+       depends on I2C && VIDEO_V4L2 && MFD_SUPPORT
        select MFD_CORE
        select MFD_WL1273_CORE
        select FW_LOADER

The same problem is happening with other drivers too, so maybe there is
a better solution to fix all problems at once. ;)

Reported-by: Johannes Berg <johannes@sipsolutions.net>


-- 
Cheers,
Luca.

Re: Kconfig unmet dependency with RADIO_WL1273

[Randy Dunlap]

On Mon, 29 Aug 2011 20:02:38 +0300 Luciano Coelho wrote:

> Hi Matti,
> 
> Johannes has just reported a problem in the Kconfig of radio-wl1273.  It
> seems to select MFD_CORE, but if the platform doesn't support MFD, then
> MFD_SUPPORT won't be selected and this kind of warning will come out:
> 
> warning: (OLPC_XO1_PM && OLPC_XO1_SCI && I2C_ISCH && GPIO_SCH && GPIO_RDC321X && RADIO_WL1273) 
>                 selects MFD_CORE which has unmet direct dependencies (MFD_SUPPORT)
> 
> I guess it must depend on MFD_SUPPORT, right? If that's the correct
> solution, the following patch should fix the problem:
> 
> diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
> index 52798a1..e87f544 100644
> --- a/drivers/media/radio/Kconfig
> +++ b/drivers/media/radio/Kconfig
> @@ -425,7 +425,7 @@ config RADIO_TIMBERDALE
>  
>  config RADIO_WL1273
>         tristate "Texas Instruments WL1273 I2C FM Radio"
> -       depends on I2C && VIDEO_V4L2
> +       depends on I2C && VIDEO_V4L2 && MFD_SUPPORT
>         select MFD_CORE
>         select MFD_WL1273_CORE
>         select FW_LOADER
> 
> The same problem is happening with other drivers too, so maybe there is
> a better solution to fix all problems at once. ;)
> 
> Reported-by: Johannes Berg <johannes@sipsolutions.net>

Yes, it can depend on MFD_SUPPORT or it can select both
MFD_SUPPORT and MFD_CORE or we could do what Jean Delvare
suggested last December and combine the MFD_SUPPORT and MFD_CORE
symbols, like I2c does.  I did a patch for that but never
posted it.  It's below, but probably needs a good bit of
updating since this patch was made in January.

---
From: Randy Dunlap <rdunlap@xenotime.net>

Combine MFD_SUPPORT (which only enabled the remainder of the MFD
menu) and MFD_CORE.  This allows other drivers to select MFD_CORE
without needing to also select MFD_SUPPORT, which fixes some
kconfig unmet dependency warnings.  Modeled after I2C kconfig.

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
 drivers/mfd/Kconfig |   42 ++++--------------------------------------
 1 file changed, 4 insertions(+), 38 deletions(-)

--- lnx-2637-rc5.orig/drivers/mfd/Kconfig
+++ lnx-2637-rc5/drivers/mfd/Kconfig
@@ -2,10 +2,9 @@
 # Multifunction miscellaneous devices
 #
 
-menuconfig MFD_SUPPORT
-	bool "Multifunction device drivers"
+menuconfig MFD_CORE
+	tristate "Multifunction device drivers"
 	depends on HAS_IOMEM
-	default y
 	help
 	  Multifunction devices embed several functions (e.g. GPIOs,
 	  touchscreens, keyboards, current regulators, power management chips,
@@ -18,16 +17,11 @@ menuconfig MFD_SUPPORT
 
 	  This option alone does not add any kernel code.
 
-if MFD_SUPPORT
-
-config MFD_CORE
-	tristate
-	default n
+if MFD_CORE
 
 config MFD_88PM860X
 	bool "Support Marvell 88PM8606/88PM8607"
 	depends on I2C=y && GENERIC_HARDIRQS
-	select MFD_CORE
 	help
 	  This supports for Marvell 88PM8606/88PM8607 Power Management IC.
 	  This includes the I2C driver and the core APIs _only_, you have to
@@ -55,7 +49,6 @@ config MFD_SM501_GPIO
 config MFD_ASIC3
 	bool "Support for Compaq ASIC3"
 	depends on GENERIC_HARDIRQS && GPIOLIB && ARM
-	select MFD_CORE
 	 ---help---
 	  This driver supports the ASIC3 multifunction chip found on many
 	  PDAs (mainly iPAQ and HTC based ones)
@@ -63,7 +56,6 @@ config MFD_ASIC3
 config MFD_SH_MOBILE_SDHI
 	bool "Support for SuperH Mobile SDHI"
 	depends on SUPERH || ARCH_SHMOBILE
-	select MFD_CORE
 	select TMIO_MMC_DMA
 	 ---help---
 	  This driver supports the SDHI hardware block found in many
@@ -71,7 +63,6 @@ config MFD_SH_MOBILE_SDHI
 
 config MFD_DAVINCI_VOICECODEC
 	tristate
-	select MFD_CORE
 
 config MFD_DM355EVM_MSP
 	bool "DaVinci DM355 EVM microcontroller"
@@ -91,7 +82,6 @@ config HTC_EGPIO
 
 config HTC_PASIC3
 	tristate "HTC PASIC3 LED/DS1WM chip support"
-	select MFD_CORE
 	help
 	  This core driver provides register access for the LED/DS1WM
 	  chips labeled "AIC2" and "AIC3", found on HTC Blueangel and
@@ -133,7 +123,6 @@ config TPS65010
 
 config TPS6507X
 	tristate "TPS6507x Power Management / Touch Screen chips"
-	select MFD_CORE
 	depends on I2C
 	help
 	  If you say yes here you get support for the TPS6507x series of
@@ -183,7 +172,6 @@ config TWL4030_POWER
 config TWL4030_CODEC
 	bool
 	depends on TWL4030_CORE
-	select MFD_CORE
 	default n
 
 config TWL6030_PWM
@@ -198,7 +186,6 @@ config TWL6030_PWM
 config MFD_STMPE
 	bool "Support STMicroelectronics STMPE"
 	depends on I2C=y && GENERIC_HARDIRQS
-	select MFD_CORE
 	help
 	  Support for the STMPE family of I/O Expanders from
 	  STMicroelectronics.
@@ -221,7 +208,6 @@ config MFD_STMPE
 config MFD_TC35892
 	bool "Support Toshiba TC35892"
 	depends on I2C=y && GENERIC_HARDIRQS
-	select MFD_CORE
 	help
 	  Support for the Toshiba TC35892 I/O Expander.
 
@@ -241,7 +227,6 @@ config TMIO_MMC_DMA
 config MFD_T7L66XB
 	bool "Support Toshiba T7L66XB"
 	depends on ARM && HAVE_CLK
-	select MFD_CORE
 	select MFD_TMIO
 	help
 	  Support for Toshiba Mobile IO Controller T7L66XB
@@ -249,7 +234,6 @@ config MFD_T7L66XB
 config MFD_TC6387XB
 	bool "Support Toshiba TC6387XB"
 	depends on ARM && HAVE_CLK
-	select MFD_CORE
 	select MFD_TMIO
 	help
 	  Support for Toshiba Mobile IO Controller TC6387XB
@@ -257,7 +241,6 @@ config MFD_TC6387XB
 config MFD_TC6393XB
 	bool "Support Toshiba TC6393XB"
 	depends on GPIOLIB && ARM
-	select MFD_CORE
 	select MFD_TMIO
 	help
 	  Support for Toshiba Mobile IO Controller TC6393XB
@@ -286,7 +269,6 @@ config PMIC_ADP5520
 config MFD_MAX8925
 	bool "Maxim Semiconductor MAX8925 PMIC Support"
 	depends on I2C=y && GENERIC_HARDIRQS
-	select MFD_CORE
 	help
 	  Say yes here to support for Maxim Semiconductor MAX8925. This is
 	  a Power Management IC. This driver provies common support for
@@ -296,7 +278,6 @@ config MFD_MAX8925
 config MFD_MAX8998
 	bool "Maxim Semiconductor MAX8998/National LP3974 PMIC Support"
 	depends on I2C=y && GENERIC_HARDIRQS
-	select MFD_CORE
 	help
 	  Say yes here to support for Maxim Semiconductor MAX8998 and
 	  National Semiconductor LP3974. This is a Power Management IC.
@@ -306,7 +287,6 @@ config MFD_MAX8998
 
 config MFD_WM8400
 	tristate "Support Wolfson Microelectronics WM8400"
-	select MFD_CORE
 	depends on I2C
 	help
 	  Support for the Wolfson Microelecronics WM8400 PMIC and audio
@@ -320,7 +300,6 @@ config MFD_WM831X
 
 config MFD_WM831X_I2C
 	bool "Support Wolfson Microelectronics WM831x/2x PMICs with I2C"
-	select MFD_CORE
 	select MFD_WM831X
 	depends on I2C=y && GENERIC_HARDIRQS
 	help
@@ -331,7 +310,6 @@ config MFD_WM831X_I2C
 
 config MFD_WM831X_SPI
 	bool "Support Wolfson Microelectronics WM831x/2x PMICs with SPI"
-	select MFD_CORE
 	select MFD_WM831X
 	depends on SPI_MASTER && GENERIC_HARDIRQS
 	help
@@ -405,7 +383,6 @@ config MFD_WM8350_I2C
 
 config MFD_WM8994
 	bool "Support Wolfson Microelectronics WM8994"
-	select MFD_CORE
 	depends on I2C=y && GENERIC_HARDIRQS
 	help
 	  The WM8994 is a highly integrated hi-fi CODEC designed for
@@ -430,7 +407,6 @@ config MFD_MC13783
 config MFD_MC13XXX
 	tristate "Support Freescale MC13783 and MC13892"
 	depends on SPI_MASTER
-	select MFD_CORE
 	select MFD_MC13783
 	help
 	  Support for the Freescale (Atlas) PMIC and audio CODECs
@@ -466,7 +442,6 @@ config ABX500_CORE
 config AB3100_CORE
 	bool "ST-Ericsson AB3100 Mixed Signal Circuit core functions"
 	depends on I2C=y && ABX500_CORE
-	select MFD_CORE
 	default y if ARCH_U300
 	help
 	  Select this to enable the AB3100 Mixed Signal IC core
@@ -497,7 +472,6 @@ config EZX_PCAP
 config AB8500_CORE
 	bool "ST-Ericsson AB8500 Mixed Signal Power Management chip"
 	depends on GENERIC_HARDIRQS && ABX500_CORE && SPI_MASTER && ARCH_U8500
-	select MFD_CORE
 	help
 	  Select this option to enable access to AB8500 power management
 	  chip. This connects to U8500 either on the SSP/SPI bus
@@ -525,7 +499,6 @@ config AB8500_DEBUG
 
 config AB3550_CORE
         bool "ST-Ericsson AB3550 Mixed Signal Circuit core functions"
-	select MFD_CORE
 	depends on I2C=y && GENERIC_HARDIRQS && ABX500_CORE
 	help
 	  Select this to enable the AB3550 Mixed Signal IC core
@@ -539,7 +512,6 @@ config AB3550_CORE
 
 config MFD_TIMBERDALE
 	tristate "Support for the Timberdale FPGA"
-	select MFD_CORE
 	depends on PCI && GPIOLIB
 	---help---
 	This is the core driver for the timberdale FPGA. This device is a
@@ -551,14 +523,12 @@ config MFD_TIMBERDALE
 config LPC_SCH
 	tristate "Intel SCH LPC"
 	depends on PCI
-	select MFD_CORE
 	help
 	  LPC bridge function of the Intel SCH provides support for
 	  System Management Bus and General Purpose I/O.
 
 config MFD_RDC321X
 	tristate "Support for RDC-R321x southbridge"
-	select MFD_CORE
 	depends on PCI
 	help
 	  Say yes here if you want to have support for the RDC R-321x SoC
@@ -567,7 +537,6 @@ config MFD_RDC321X
 
 config MFD_JANZ_CMODIO
 	tristate "Support for Janz CMOD-IO PCI MODULbus Carrier Board"
-	select MFD_CORE
 	depends on PCI
 	help
 	  This is the core driver for the Janz CMOD-IO PCI MODULbus
@@ -577,7 +546,6 @@ config MFD_JANZ_CMODIO
 
 config MFD_JZ4740_ADC
 	tristate "Support for the JZ4740 SoC ADC core"
-	select MFD_CORE
 	depends on MACH_JZ4740
 	help
 	  Say yes here if you want support for the ADC unit in the JZ4740 SoC.
@@ -586,7 +554,6 @@ config MFD_JZ4740_ADC
 config MFD_TPS6586X
 	bool "TPS6586x Power Management chips"
 	depends on I2C=y && GPIOLIB && GENERIC_HARDIRQS
-	select MFD_CORE
 	help
 	  If you say yes here you get support for the TPS6586X series of
 	  Power Management chips.
@@ -600,13 +567,12 @@ config MFD_TPS6586X
 config MFD_VX855
 	tristate "Support for VIA VX855/VX875 integrated south bridge"
 	depends on PCI
-	select MFD_CORE
 	help
 	  Say yes here to enable support for various functions of the
 	  VIA VX855/VX875 south bridge. You will need to enable the vx855_spi
 	  and/or vx855_gpio drivers for this to do anything useful.
 
-endif # MFD_SUPPORT
+endif # MFD_CORE
 
 menu "Multimedia Capabilities Port drivers"
 	depends on ARCH_SA1100

[PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE

[Luciano Coelho]

From: Randy Dunlap <rdunlap@xenotime.net>

Combine MFD_SUPPORT (which only enabled the remainder of the MFD
menu) and MFD_CORE.  This allows other drivers to select MFD_CORE
without needing to also select MFD_SUPPORT, which fixes some
kconfig unmet dependency warnings.  Modeled after I2C kconfig.

[Forward-ported to 3.1-rc4.  This fixes a warning when some drivers,
such as RADIO_WL1273, are selected, but MFD_SUPPORT is not. -- Luca]

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Luciano Coelho <coelho@ti.com>
---

I guess this should fix the problem.  I've simple forward-ported
Randy's patch to the latest mainline kernel.  I don't know via which
tree this should go in, though.

NOTE: I have *not* tested this very thoroughly.  But at least
omap2plus stuff seems to work okay with this change.  MFD_SUPPORT is
also selected by a couple of "tile" platforms defconfigs, but I guess
the Kconfig system should take care of it.

 arch/arm/mach-omap2/Kconfig |    2 +-
 drivers/gpio/Kconfig        |    3 +-
 drivers/mfd/Kconfig         |   54 +++---------------------------------------
 3 files changed, 6 insertions(+), 53 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 57b66d5..1046923 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -14,7 +14,7 @@ config ARCH_OMAP2PLUS_TYPICAL
 	select SERIAL_OMAP_CONSOLE
 	select I2C
 	select I2C_OMAP
-	select MFD_SUPPORT
+	select MFD_CORE
 	select MENELAUS if ARCH_OMAP2
 	select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4
 	select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index d539efd..fbc5fd4 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -180,7 +180,7 @@ config GPIO_SCH
 
 config GPIO_VX855
 	tristate "VIA VX855/VX875 GPIO"
-	depends on MFD_SUPPORT && PCI
+	depends on PCI
 	select MFD_CORE
 	select MFD_VX855
 	help
@@ -417,7 +417,6 @@ config GPIO_TIMBERDALE
 config GPIO_RDC321X
 	tristate "RDC R-321x GPIO support"
 	depends on PCI
-	select MFD_SUPPORT
 	select MFD_CORE
 	select MFD_RDC321X
 	help
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 21574bd..1836cdf 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2,10 +2,9 @@
 # Multifunction miscellaneous devices
 #
 
-menuconfig MFD_SUPPORT
-	bool "Multifunction device drivers"
+menuconfig MFD_CORE
+	tristate "Multifunction device drivers"
 	depends on HAS_IOMEM
-	default y
 	help
 	  Multifunction devices embed several functions (e.g. GPIOs,
 	  touchscreens, keyboards, current regulators, power management chips,
@@ -18,16 +17,11 @@ menuconfig MFD_SUPPORT
 
 	  This option alone does not add any kernel code.
 
-if MFD_SUPPORT
-
-config MFD_CORE
-	tristate
-	default n
+if MFD_CORE
 
 config MFD_88PM860X
 	bool "Support Marvell 88PM8606/88PM8607"
 	depends on I2C=y && GENERIC_HARDIRQS
-	select MFD_CORE
 	help
 	  This supports for Marvell 88PM8606/88PM8607 Power Management IC.
 	  This includes the I2C driver and the core APIs _only_, you have to
@@ -55,14 +49,12 @@ config MFD_SM501_GPIO
 config MFD_ASIC3
 	bool "Support for Compaq ASIC3"
 	depends on GENERIC_HARDIRQS && GPIOLIB && ARM
-	select MFD_CORE
 	 ---help---
 	  This driver supports the ASIC3 multifunction chip found on many
 	  PDAs (mainly iPAQ and HTC based ones)
 
 config MFD_DAVINCI_VOICECODEC
 	tristate
-	select MFD_CORE
 
 config MFD_DM355EVM_MSP
 	bool "DaVinci DM355 EVM microcontroller"
@@ -75,7 +67,6 @@ config MFD_DM355EVM_MSP
 config MFD_TI_SSP
 	tristate "TI Sequencer Serial Port support"
 	depends on ARCH_DAVINCI_TNETV107X
-	select MFD_CORE
 	---help---
 	  Say Y here if you want support for the Sequencer Serial Port
 	  in a Texas Instruments TNETV107X SoC.
@@ -93,7 +84,6 @@ config HTC_EGPIO
 
 config HTC_PASIC3
 	tristate "HTC PASIC3 LED/DS1WM chip support"
-	select MFD_CORE
 	help
 	  This core driver provides register access for the LED/DS1WM
 	  chips labeled "AIC2" and "AIC3", found on HTC Blueangel and
@@ -124,7 +114,6 @@ config TPS6105X
 	tristate "TPS61050/61052 Boost Converters"
 	depends on I2C
 	select REGULATOR
-	select MFD_CORE
 	select REGULATOR_FIXED_VOLTAGE
 	help
 	  This option enables a driver for the TP61050/TPS61052
@@ -147,7 +136,6 @@ config TPS65010
 
 config TPS6507X
 	tristate "TPS6507x Power Management / Touch Screen chips"
-	select MFD_CORE
 	depends on I2C
 	help
 	  If you say yes here you get support for the TPS6507x series of
@@ -160,7 +148,6 @@ config TPS6507X
 config MFD_TPS6586X
 	bool "TPS6586x Power Management chips"
 	depends on I2C=y && GPIOLIB && GENERIC_HARDIRQS
-	select MFD_CORE
 	help
 	  If you say yes here you get support for the TPS6586X series of
 	  Power Management chips.
@@ -174,7 +161,6 @@ config MFD_TPS6586X
 config MFD_TPS65910
 	bool "TPS65910 Power Management chip"
 	depends on I2C=y && GPIOLIB
-	select MFD_CORE
 	select GPIO_TPS65910
 	help
 	  if you say yes here you get support for the TPS65910 series of
@@ -186,7 +172,6 @@ config MFD_TPS65912
 
 config MFD_TPS65912_I2C
 	bool "TPS95612 Power Management chip with I2C"
-	select MFD_CORE
 	select MFD_TPS65912
 	depends on I2C=y && GPIOLIB
 	help
@@ -195,7 +180,6 @@ config MFD_TPS65912_I2C
 
 config MFD_TPS65912_SPI
 	bool "TPS65912 Power Management chip with SPI"
-	select MFD_CORE
 	select MFD_TPS65912
 	depends on SPI_MASTER && GPIOLIB
 	help
@@ -252,7 +236,6 @@ config TWL4030_POWER
 config MFD_TWL4030_AUDIO
 	bool
 	depends on TWL4030_CORE
-	select MFD_CORE
 	default n
 
 config TWL6030_PWM
@@ -267,13 +250,11 @@ config TWL6030_PWM
 config TWL6040_CORE
 	bool
 	depends on TWL4030_CORE && GENERIC_HARDIRQS
-	select MFD_CORE
 	default n
 
 config MFD_STMPE
 	bool "Support STMicroelectronics STMPE"
 	depends on I2C=y && GENERIC_HARDIRQS
-	select MFD_CORE
 	help
 	  Support for the STMPE family of I/O Expanders from
 	  STMicroelectronics.
@@ -296,7 +277,6 @@ config MFD_STMPE
 config MFD_TC3589X
 	bool "Support Toshiba TC35892 and variants"
 	depends on I2C=y && GENERIC_HARDIRQS
-	select MFD_CORE
 	help
 	  Support for the Toshiba TC35892 and variants I/O Expander.
 
@@ -311,7 +291,6 @@ config MFD_TMIO
 config MFD_T7L66XB
 	bool "Support Toshiba T7L66XB"
 	depends on ARM && HAVE_CLK
-	select MFD_CORE
 	select MFD_TMIO
 	help
 	  Support for Toshiba Mobile IO Controller T7L66XB
@@ -319,7 +298,6 @@ config MFD_T7L66XB
 config MFD_TC6387XB
 	bool "Support Toshiba TC6387XB"
 	depends on ARM && HAVE_CLK
-	select MFD_CORE
 	select MFD_TMIO
 	help
 	  Support for Toshiba Mobile IO Controller TC6387XB
@@ -327,7 +305,6 @@ config MFD_TC6387XB
 config MFD_TC6393XB
 	bool "Support Toshiba TC6393XB"
 	depends on GPIOLIB && ARM
-	select MFD_CORE
 	select MFD_TMIO
 	help
 	  Support for Toshiba Mobile IO Controller TC6393XB
@@ -356,7 +333,6 @@ config PMIC_ADP5520
 config MFD_MAX8925
 	bool "Maxim Semiconductor MAX8925 PMIC Support"
 	depends on I2C=y && GENERIC_HARDIRQS
-	select MFD_CORE
 	help
 	  Say yes here to support for Maxim Semiconductor MAX8925. This is
 	  a Power Management IC. This driver provies common support for
@@ -366,7 +342,6 @@ config MFD_MAX8925
 config MFD_MAX8997
 	bool "Maxim Semiconductor MAX8997/8966 PMIC Support"
 	depends on I2C=y && GENERIC_HARDIRQS
-	select MFD_CORE
 	help
 	  Say yes here to support for Maxim Semiconductor MAX8998/8966.
 	  This is a Power Management IC with RTC, Flash, Fuel Gauge, Haptic,
@@ -378,7 +353,6 @@ config MFD_MAX8997
 config MFD_MAX8998
 	bool "Maxim Semiconductor MAX8998/National LP3974 PMIC Support"
 	depends on I2C=y && GENERIC_HARDIRQS
-	select MFD_CORE
 	help
 	  Say yes here to support for Maxim Semiconductor MAX8998 and
 	  National Semiconductor LP3974. This is a Power Management IC.
@@ -388,7 +362,6 @@ config MFD_MAX8998
 
 config MFD_WM8400
 	tristate "Support Wolfson Microelectronics WM8400"
-	select MFD_CORE
 	depends on I2C
 	help
 	  Support for the Wolfson Microelecronics WM8400 PMIC and audio
@@ -402,7 +375,6 @@ config MFD_WM831X
 
 config MFD_WM831X_I2C
 	bool "Support Wolfson Microelectronics WM831x/2x PMICs with I2C"
-	select MFD_CORE
 	select MFD_WM831X
 	depends on I2C=y && GENERIC_HARDIRQS
 	help
@@ -413,7 +385,6 @@ config MFD_WM831X_I2C
 
 config MFD_WM831X_SPI
 	bool "Support Wolfson Microelectronics WM831x/2x PMICs with SPI"
-	select MFD_CORE
 	select MFD_WM831X
 	depends on SPI_MASTER && GENERIC_HARDIRQS
 	help
@@ -487,7 +458,6 @@ config MFD_WM8350_I2C
 
 config MFD_WM8994
 	bool "Support Wolfson Microelectronics WM8994"
-	select MFD_CORE
 	depends on I2C=y && GENERIC_HARDIRQS
 	help
 	  The WM8994 is a highly integrated hi-fi CODEC designed for
@@ -526,7 +496,6 @@ config MFD_MC13783
 config MFD_MC13XXX
 	tristate "Support Freescale MC13783 and MC13892"
 	depends on SPI_MASTER
-	select MFD_CORE
 	select MFD_MC13783
 	help
 	  Support for the Freescale (Atlas) PMIC and audio CODECs
@@ -548,7 +517,6 @@ config ABX500_CORE
 config AB3100_CORE
 	bool "ST-Ericsson AB3100 Mixed Signal Circuit core functions"
 	depends on I2C=y && ABX500_CORE
-	select MFD_CORE
 	default y if ARCH_U300
 	help
 	  Select this to enable the AB3100 Mixed Signal IC core
@@ -579,7 +547,6 @@ config EZX_PCAP
 config AB8500_CORE
 	bool "ST-Ericsson AB8500 Mixed Signal Power Management chip"
 	depends on GENERIC_HARDIRQS && ABX500_CORE
-	select MFD_CORE
 	help
 	  Select this option to enable access to AB8500 power management
 	  chip. This connects to U8500 either on the SSP/SPI bus (deprecated
@@ -614,7 +581,6 @@ config AB8500_GPADC
 
 config AB3550_CORE
         bool "ST-Ericsson AB3550 Mixed Signal Circuit core functions"
-	select MFD_CORE
 	depends on I2C=y && GENERIC_HARDIRQS && ABX500_CORE
 	help
 	  Select this to enable the AB3550 Mixed Signal IC core
@@ -629,7 +595,6 @@ config AB3550_CORE
 config MFD_DB8500_PRCMU
 	bool "ST-Ericsson DB8500 Power Reset Control Management Unit"
 	depends on UX500_SOC_DB8500
-	select MFD_CORE
 	help
 	  Select this option to enable support for the DB8500 Power Reset
 	  and Control Management Unit. This is basically an autonomous
@@ -639,7 +604,6 @@ config MFD_DB8500_PRCMU
 config MFD_DB5500_PRCMU
 	bool "ST-Ericsson DB5500 Power Reset Control Management Unit"
 	depends on UX500_SOC_DB5500
-	select MFD_CORE
 	help
 	  Select this option to enable support for the DB5500 Power Reset
 	  and Control Management Unit. This is basically an autonomous
@@ -648,7 +612,6 @@ config MFD_DB5500_PRCMU
 
 config MFD_CS5535
 	tristate "Support for CS5535 and CS5536 southbridge core functions"
-	select MFD_CORE
 	depends on PCI && X86
 	---help---
 	  This is the core driver for CS5535/CS5536 MFD functions.  This is
@@ -656,7 +619,6 @@ config MFD_CS5535
 
 config MFD_TIMBERDALE
 	tristate "Support for the Timberdale FPGA"
-	select MFD_CORE
 	depends on PCI && GPIOLIB
 	---help---
 	This is the core driver for the timberdale FPGA. This device is a
@@ -668,14 +630,12 @@ config MFD_TIMBERDALE
 config LPC_SCH
 	tristate "Intel SCH LPC"
 	depends on PCI
-	select MFD_CORE
 	help
 	  LPC bridge function of the Intel SCH provides support for
 	  System Management Bus and General Purpose I/O.
 
 config MFD_RDC321X
 	tristate "Support for RDC-R321x southbridge"
-	select MFD_CORE
 	depends on PCI
 	help
 	  Say yes here if you want to have support for the RDC R-321x SoC
@@ -684,7 +644,6 @@ config MFD_RDC321X
 
 config MFD_JANZ_CMODIO
 	tristate "Support for Janz CMOD-IO PCI MODULbus Carrier Board"
-	select MFD_CORE
 	depends on PCI
 	help
 	  This is the core driver for the Janz CMOD-IO PCI MODULbus
@@ -694,7 +653,6 @@ config MFD_JANZ_CMODIO
 
 config MFD_JZ4740_ADC
 	bool "Support for the JZ4740 SoC ADC core"
-	select MFD_CORE
 	select GENERIC_IRQ_CHIP
 	depends on MACH_JZ4740
 	help
@@ -704,7 +662,6 @@ config MFD_JZ4740_ADC
 config MFD_VX855
 	tristate "Support for VIA VX855/VX875 integrated south bridge"
 	depends on PCI
-	select MFD_CORE
 	help
 	  Say yes here to enable support for various functions of the
 	  VIA VX855/VX875 south bridge. You will need to enable the vx855_spi
@@ -713,7 +670,6 @@ config MFD_VX855
 config MFD_WL1273_CORE
 	tristate "Support for TI WL1273 FM radio."
 	depends on I2C
-	select MFD_CORE
 	default n
 	help
 	  This is the core driver for the TI WL1273 FM radio. This MFD
@@ -735,7 +691,6 @@ config MFD_PM8XXX
 config MFD_PM8921_CORE
 	tristate "Qualcomm PM8921 PMIC chip"
 	depends on MSM_SSBI
-	select MFD_CORE
 	select MFD_PM8XXX
 	help
 	  If you say yes to this option, support will be included for the
@@ -762,7 +717,6 @@ config TPS65911_COMPARATOR
 
 config MFD_AAT2870_CORE
 	bool "Support for the AnalogicTech AAT2870"
-	select MFD_CORE
 	depends on I2C=y && GPIOLIB
 	help
 	  If you say yes here you get support for the AAT2870.
@@ -770,7 +724,7 @@ config MFD_AAT2870_CORE
 	  additional drivers must be enabled in order to use the
 	  functionality of the device.
 
-endif # MFD_SUPPORT
+endif # MFD_CORE
 
 menu "Multimedia Capabilities Port drivers"
 	depends on ARCH_SA1100
-- 
1.7.1

Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE

[Grant Likely]

On Mon, Aug 29, 2011 at 12:41 PM, Luciano Coelho <coelho@ti.com> wrote:
> From: Randy Dunlap <rdunlap@xenotime.net>
>
> Combine MFD_SUPPORT (which only enabled the remainder of the MFD
> menu) and MFD_CORE.  This allows other drivers to select MFD_CORE
> without needing to also select MFD_SUPPORT, which fixes some
> kconfig unmet dependency warnings.  Modeled after I2C kconfig.
>
> [Forward-ported to 3.1-rc4.  This fixes a warning when some drivers,
> such as RADIO_WL1273, are selected, but MFD_SUPPORT is not. -- Luca]
>
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> Reported-by: Johannes Berg <johannes@sipsolutions.net>
> Cc: Jean Delvare <khali@linux-fr.org>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Signed-off-by: Luciano Coelho <coelho@ti.com>

okay by me.

g.

> ---
>
> I guess this should fix the problem.  I've simple forward-ported
> Randy's patch to the latest mainline kernel.  I don't know via which
> tree this should go in, though.
>
> NOTE: I have *not* tested this very thoroughly.  But at least
> omap2plus stuff seems to work okay with this change.  MFD_SUPPORT is
> also selected by a couple of "tile" platforms defconfigs, but I guess
> the Kconfig system should take care of it.
>
>  arch/arm/mach-omap2/Kconfig |    2 +-
>  drivers/gpio/Kconfig        |    3 +-
>  drivers/mfd/Kconfig         |   54 +++---------------------------------------
>  3 files changed, 6 insertions(+), 53 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 57b66d5..1046923 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -14,7 +14,7 @@ config ARCH_OMAP2PLUS_TYPICAL
>        select SERIAL_OMAP_CONSOLE
>        select I2C
>        select I2C_OMAP
> -       select MFD_SUPPORT
> +       select MFD_CORE
>        select MENELAUS if ARCH_OMAP2
>        select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4
>        select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index d539efd..fbc5fd4 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -180,7 +180,7 @@ config GPIO_SCH
>
>  config GPIO_VX855
>        tristate "VIA VX855/VX875 GPIO"
> -       depends on MFD_SUPPORT && PCI
> +       depends on PCI
>        select MFD_CORE
>        select MFD_VX855
>        help
> @@ -417,7 +417,6 @@ config GPIO_TIMBERDALE
>  config GPIO_RDC321X
>        tristate "RDC R-321x GPIO support"
>        depends on PCI
> -       select MFD_SUPPORT
>        select MFD_CORE
>        select MFD_RDC321X
>        help
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 21574bd..1836cdf 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -2,10 +2,9 @@
>  # Multifunction miscellaneous devices
>  #
>
> -menuconfig MFD_SUPPORT
> -       bool "Multifunction device drivers"
> +menuconfig MFD_CORE
> +       tristate "Multifunction device drivers"
>        depends on HAS_IOMEM
> -       default y
>        help
>          Multifunction devices embed several functions (e.g. GPIOs,
>          touchscreens, keyboards, current regulators, power management chips,
> @@ -18,16 +17,11 @@ menuconfig MFD_SUPPORT
>
>          This option alone does not add any kernel code.
>
> -if MFD_SUPPORT
> -
> -config MFD_CORE
> -       tristate
> -       default n
> +if MFD_CORE
>
>  config MFD_88PM860X
>        bool "Support Marvell 88PM8606/88PM8607"
>        depends on I2C=y && GENERIC_HARDIRQS
> -       select MFD_CORE
>        help
>          This supports for Marvell 88PM8606/88PM8607 Power Management IC.
>          This includes the I2C driver and the core APIs _only_, you have to
> @@ -55,14 +49,12 @@ config MFD_SM501_GPIO
>  config MFD_ASIC3
>        bool "Support for Compaq ASIC3"
>        depends on GENERIC_HARDIRQS && GPIOLIB && ARM
> -       select MFD_CORE
>         ---help---
>          This driver supports the ASIC3 multifunction chip found on many
>          PDAs (mainly iPAQ and HTC based ones)
>
>  config MFD_DAVINCI_VOICECODEC
>        tristate
> -       select MFD_CORE
>
>  config MFD_DM355EVM_MSP
>        bool "DaVinci DM355 EVM microcontroller"
> @@ -75,7 +67,6 @@ config MFD_DM355EVM_MSP
>  config MFD_TI_SSP
>        tristate "TI Sequencer Serial Port support"
>        depends on ARCH_DAVINCI_TNETV107X
> -       select MFD_CORE
>        ---help---
>          Say Y here if you want support for the Sequencer Serial Port
>          in a Texas Instruments TNETV107X SoC.
> @@ -93,7 +84,6 @@ config HTC_EGPIO
>
>  config HTC_PASIC3
>        tristate "HTC PASIC3 LED/DS1WM chip support"
> -       select MFD_CORE
>        help
>          This core driver provides register access for the LED/DS1WM
>          chips labeled "AIC2" and "AIC3", found on HTC Blueangel and
> @@ -124,7 +114,6 @@ config TPS6105X
>        tristate "TPS61050/61052 Boost Converters"
>        depends on I2C
>        select REGULATOR
> -       select MFD_CORE
>        select REGULATOR_FIXED_VOLTAGE
>        help
>          This option enables a driver for the TP61050/TPS61052
> @@ -147,7 +136,6 @@ config TPS65010
>
>  config TPS6507X
>        tristate "TPS6507x Power Management / Touch Screen chips"
> -       select MFD_CORE
>        depends on I2C
>        help
>          If you say yes here you get support for the TPS6507x series of
> @@ -160,7 +148,6 @@ config TPS6507X
>  config MFD_TPS6586X
>        bool "TPS6586x Power Management chips"
>        depends on I2C=y && GPIOLIB && GENERIC_HARDIRQS
> -       select MFD_CORE
>        help
>          If you say yes here you get support for the TPS6586X series of
>          Power Management chips.
> @@ -174,7 +161,6 @@ config MFD_TPS6586X
>  config MFD_TPS65910
>        bool "TPS65910 Power Management chip"
>        depends on I2C=y && GPIOLIB
> -       select MFD_CORE
>        select GPIO_TPS65910
>        help
>          if you say yes here you get support for the TPS65910 series of
> @@ -186,7 +172,6 @@ config MFD_TPS65912
>
>  config MFD_TPS65912_I2C
>        bool "TPS95612 Power Management chip with I2C"
> -       select MFD_CORE
>        select MFD_TPS65912
>        depends on I2C=y && GPIOLIB
>        help
> @@ -195,7 +180,6 @@ config MFD_TPS65912_I2C
>
>  config MFD_TPS65912_SPI
>        bool "TPS65912 Power Management chip with SPI"
> -       select MFD_CORE
>        select MFD_TPS65912
>        depends on SPI_MASTER && GPIOLIB
>        help
> @@ -252,7 +236,6 @@ config TWL4030_POWER
>  config MFD_TWL4030_AUDIO
>        bool
>        depends on TWL4030_CORE
> -       select MFD_CORE
>        default n
>
>  config TWL6030_PWM
> @@ -267,13 +250,11 @@ config TWL6030_PWM
>  config TWL6040_CORE
>        bool
>        depends on TWL4030_CORE && GENERIC_HARDIRQS
> -       select MFD_CORE
>        default n
>
>  config MFD_STMPE
>        bool "Support STMicroelectronics STMPE"
>        depends on I2C=y && GENERIC_HARDIRQS
> -       select MFD_CORE
>        help
>          Support for the STMPE family of I/O Expanders from
>          STMicroelectronics.
> @@ -296,7 +277,6 @@ config MFD_STMPE
>  config MFD_TC3589X
>        bool "Support Toshiba TC35892 and variants"
>        depends on I2C=y && GENERIC_HARDIRQS
> -       select MFD_CORE
>        help
>          Support for the Toshiba TC35892 and variants I/O Expander.
>
> @@ -311,7 +291,6 @@ config MFD_TMIO
>  config MFD_T7L66XB
>        bool "Support Toshiba T7L66XB"
>        depends on ARM && HAVE_CLK
> -       select MFD_CORE
>        select MFD_TMIO
>        help
>          Support for Toshiba Mobile IO Controller T7L66XB
> @@ -319,7 +298,6 @@ config MFD_T7L66XB
>  config MFD_TC6387XB
>        bool "Support Toshiba TC6387XB"
>        depends on ARM && HAVE_CLK
> -       select MFD_CORE
>        select MFD_TMIO
>        help
>          Support for Toshiba Mobile IO Controller TC6387XB
> @@ -327,7 +305,6 @@ config MFD_TC6387XB
>  config MFD_TC6393XB
>        bool "Support Toshiba TC6393XB"
>        depends on GPIOLIB && ARM
> -       select MFD_CORE
>        select MFD_TMIO
>        help
>          Support for Toshiba Mobile IO Controller TC6393XB
> @@ -356,7 +333,6 @@ config PMIC_ADP5520
>  config MFD_MAX8925
>        bool "Maxim Semiconductor MAX8925 PMIC Support"
>        depends on I2C=y && GENERIC_HARDIRQS
> -       select MFD_CORE
>        help
>          Say yes here to support for Maxim Semiconductor MAX8925. This is
>          a Power Management IC. This driver provies common support for
> @@ -366,7 +342,6 @@ config MFD_MAX8925
>  config MFD_MAX8997
>        bool "Maxim Semiconductor MAX8997/8966 PMIC Support"
>        depends on I2C=y && GENERIC_HARDIRQS
> -       select MFD_CORE
>        help
>          Say yes here to support for Maxim Semiconductor MAX8998/8966.
>          This is a Power Management IC with RTC, Flash, Fuel Gauge, Haptic,
> @@ -378,7 +353,6 @@ config MFD_MAX8997
>  config MFD_MAX8998
>        bool "Maxim Semiconductor MAX8998/National LP3974 PMIC Support"
>        depends on I2C=y && GENERIC_HARDIRQS
> -       select MFD_CORE
>        help
>          Say yes here to support for Maxim Semiconductor MAX8998 and
>          National Semiconductor LP3974. This is a Power Management IC.
> @@ -388,7 +362,6 @@ config MFD_MAX8998
>
>  config MFD_WM8400
>        tristate "Support Wolfson Microelectronics WM8400"
> -       select MFD_CORE
>        depends on I2C
>        help
>          Support for the Wolfson Microelecronics WM8400 PMIC and audio
> @@ -402,7 +375,6 @@ config MFD_WM831X
>
>  config MFD_WM831X_I2C
>        bool "Support Wolfson Microelectronics WM831x/2x PMICs with I2C"
> -       select MFD_CORE
>        select MFD_WM831X
>        depends on I2C=y && GENERIC_HARDIRQS
>        help
> @@ -413,7 +385,6 @@ config MFD_WM831X_I2C
>
>  config MFD_WM831X_SPI
>        bool "Support Wolfson Microelectronics WM831x/2x PMICs with SPI"
> -       select MFD_CORE
>        select MFD_WM831X
>        depends on SPI_MASTER && GENERIC_HARDIRQS
>        help
> @@ -487,7 +458,6 @@ config MFD_WM8350_I2C
>
>  config MFD_WM8994
>        bool "Support Wolfson Microelectronics WM8994"
> -       select MFD_CORE
>        depends on I2C=y && GENERIC_HARDIRQS
>        help
>          The WM8994 is a highly integrated hi-fi CODEC designed for
> @@ -526,7 +496,6 @@ config MFD_MC13783
>  config MFD_MC13XXX
>        tristate "Support Freescale MC13783 and MC13892"
>        depends on SPI_MASTER
> -       select MFD_CORE
>        select MFD_MC13783
>        help
>          Support for the Freescale (Atlas) PMIC and audio CODECs
> @@ -548,7 +517,6 @@ config ABX500_CORE
>  config AB3100_CORE
>        bool "ST-Ericsson AB3100 Mixed Signal Circuit core functions"
>        depends on I2C=y && ABX500_CORE
> -       select MFD_CORE
>        default y if ARCH_U300
>        help
>          Select this to enable the AB3100 Mixed Signal IC core
> @@ -579,7 +547,6 @@ config EZX_PCAP
>  config AB8500_CORE
>        bool "ST-Ericsson AB8500 Mixed Signal Power Management chip"
>        depends on GENERIC_HARDIRQS && ABX500_CORE
> -       select MFD_CORE
>        help
>          Select this option to enable access to AB8500 power management
>          chip. This connects to U8500 either on the SSP/SPI bus (deprecated
> @@ -614,7 +581,6 @@ config AB8500_GPADC
>
>  config AB3550_CORE
>         bool "ST-Ericsson AB3550 Mixed Signal Circuit core functions"
> -       select MFD_CORE
>        depends on I2C=y && GENERIC_HARDIRQS && ABX500_CORE
>        help
>          Select this to enable the AB3550 Mixed Signal IC core
> @@ -629,7 +595,6 @@ config AB3550_CORE
>  config MFD_DB8500_PRCMU
>        bool "ST-Ericsson DB8500 Power Reset Control Management Unit"
>        depends on UX500_SOC_DB8500
> -       select MFD_CORE
>        help
>          Select this option to enable support for the DB8500 Power Reset
>          and Control Management Unit. This is basically an autonomous
> @@ -639,7 +604,6 @@ config MFD_DB8500_PRCMU
>  config MFD_DB5500_PRCMU
>        bool "ST-Ericsson DB5500 Power Reset Control Management Unit"
>        depends on UX500_SOC_DB5500
> -       select MFD_CORE
>        help
>          Select this option to enable support for the DB5500 Power Reset
>          and Control Management Unit. This is basically an autonomous
> @@ -648,7 +612,6 @@ config MFD_DB5500_PRCMU
>
>  config MFD_CS5535
>        tristate "Support for CS5535 and CS5536 southbridge core functions"
> -       select MFD_CORE
>        depends on PCI && X86
>        ---help---
>          This is the core driver for CS5535/CS5536 MFD functions.  This is
> @@ -656,7 +619,6 @@ config MFD_CS5535
>
>  config MFD_TIMBERDALE
>        tristate "Support for the Timberdale FPGA"
> -       select MFD_CORE
>        depends on PCI && GPIOLIB
>        ---help---
>        This is the core driver for the timberdale FPGA. This device is a
> @@ -668,14 +630,12 @@ config MFD_TIMBERDALE
>  config LPC_SCH
>        tristate "Intel SCH LPC"
>        depends on PCI
> -       select MFD_CORE
>        help
>          LPC bridge function of the Intel SCH provides support for
>          System Management Bus and General Purpose I/O.
>
>  config MFD_RDC321X
>        tristate "Support for RDC-R321x southbridge"
> -       select MFD_CORE
>        depends on PCI
>        help
>          Say yes here if you want to have support for the RDC R-321x SoC
> @@ -684,7 +644,6 @@ config MFD_RDC321X
>
>  config MFD_JANZ_CMODIO
>        tristate "Support for Janz CMOD-IO PCI MODULbus Carrier Board"
> -       select MFD_CORE
>        depends on PCI
>        help
>          This is the core driver for the Janz CMOD-IO PCI MODULbus
> @@ -694,7 +653,6 @@ config MFD_JANZ_CMODIO
>
>  config MFD_JZ4740_ADC
>        bool "Support for the JZ4740 SoC ADC core"
> -       select MFD_CORE
>        select GENERIC_IRQ_CHIP
>        depends on MACH_JZ4740
>        help
> @@ -704,7 +662,6 @@ config MFD_JZ4740_ADC
>  config MFD_VX855
>        tristate "Support for VIA VX855/VX875 integrated south bridge"
>        depends on PCI
> -       select MFD_CORE
>        help
>          Say yes here to enable support for various functions of the
>          VIA VX855/VX875 south bridge. You will need to enable the vx855_spi
> @@ -713,7 +670,6 @@ config MFD_VX855
>  config MFD_WL1273_CORE
>        tristate "Support for TI WL1273 FM radio."
>        depends on I2C
> -       select MFD_CORE
>        default n
>        help
>          This is the core driver for the TI WL1273 FM radio. This MFD
> @@ -735,7 +691,6 @@ config MFD_PM8XXX
>  config MFD_PM8921_CORE
>        tristate "Qualcomm PM8921 PMIC chip"
>        depends on MSM_SSBI
> -       select MFD_CORE
>        select MFD_PM8XXX
>        help
>          If you say yes to this option, support will be included for the
> @@ -762,7 +717,6 @@ config TPS65911_COMPARATOR
>
>  config MFD_AAT2870_CORE
>        bool "Support for the AnalogicTech AAT2870"
> -       select MFD_CORE
>        depends on I2C=y && GPIOLIB
>        help
>          If you say yes here you get support for the AAT2870.
> @@ -770,7 +724,7 @@ config MFD_AAT2870_CORE
>          additional drivers must be enabled in order to use the
>          functionality of the device.
>
> -endif # MFD_SUPPORT
> +endif # MFD_CORE
>
>  menu "Multimedia Capabilities Port drivers"
>        depends on ARCH_SA1100
> --
> 1.7.1
>
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE

[Jean Delvare]

Hi Luciano,

On Mon, 29 Aug 2011 21:41:47 +0300, Luciano Coelho wrote:
> From: Randy Dunlap <rdunlap@xenotime.net>
> 
> Combine MFD_SUPPORT (which only enabled the remainder of the MFD
> menu) and MFD_CORE.  This allows other drivers to select MFD_CORE
> without needing to also select MFD_SUPPORT, which fixes some
> kconfig unmet dependency warnings.  Modeled after I2C kconfig.
> 
> [Forward-ported to 3.1-rc4.  This fixes a warning when some drivers,
> such as RADIO_WL1273, are selected, but MFD_SUPPORT is not. -- Luca]

I like the idea in general, this makes things much simpler.

There is at least one issue with your current implementation though.
"make oldconfig" has this to complain about:

drivers/mfd/Kconfig:5:error: recursive dependency detected!
drivers/mfd/Kconfig:5:	symbol MFD_CORE is selected by OLPC_XO1_PM
arch/x86/Kconfig:2028:	symbol OLPC_XO1_PM depends on MFD_CS5535
drivers/mfd/Kconfig:613:	symbol MFD_CS5535 depends on MFD_CORE

Not sure if it is really caused by your patch or only revealed by it,
but it should be fixed anyway. The following should fix it, please
consider folding in your patch:

--- linux-3.1-rc4.orig/arch/x86/Kconfig	2011-08-16 11:49:42.000000000 +0200
+++ linux-3.1-rc4/arch/x86/Kconfig	2011-08-31 16:54:09.000000000 +0200
@@ -2028,7 +2028,6 @@ config OLPC
 config OLPC_XO1_PM
 	bool "OLPC XO-1 Power Management"
 	depends on OLPC && MFD_CS5535 && PM_SLEEP
-	select MFD_CORE
 	---help---
 	  Add support for poweroff and suspend of the OLPC XO-1 laptop.
 
@@ -2044,7 +2043,6 @@ config OLPC_XO1_SCI
 	depends on OLPC && OLPC_XO1_PM
 	select POWER_SUPPLY
 	select GPIO_CS5535
-	select MFD_CORE
 	---help---
 	  Add support for SCI-based features of the OLPC XO-1 laptop:
 	   - EC-driven system wakeups

> 
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> Reported-by: Johannes Berg <johannes@sipsolutions.net>
> Cc: Jean Delvare <khali@linux-fr.org>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Signed-off-by: Luciano Coelho <coelho@ti.com>
> ---
> 
> I guess this should fix the problem.  I've simple forward-ported
> Randy's patch to the latest mainline kernel.  I don't know via which
> tree this should go in, though.

Samuel Ortiz is the maintainer of the mfd subsystem, so his tree would
be an obvious choice.

> NOTE: I have *not* tested this very thoroughly.  But at least
> omap2plus stuff seems to work okay with this change.  MFD_SUPPORT is
> also selected by a couple of "tile" platforms defconfigs, but I guess
> the Kconfig system should take care of it.

I can't test it either, but it looks sane to me. If you merge the
proposed changes above, you can add:

Acked-by: Jean Delvare <khali@linux-fr.org>

-- 
Jean Delvare

Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE

[Arnd Bergmann]

On Monday 29 August 2011, Luciano Coelho wrote:
> From: Randy Dunlap <rdunlap@xenotime.net>
> 
> Combine MFD_SUPPORT (which only enabled the remainder of the MFD
> menu) and MFD_CORE.  This allows other drivers to select MFD_CORE
> without needing to also select MFD_SUPPORT, which fixes some
> kconfig unmet dependency warnings.  Modeled after I2C kconfig.
> 
> [Forward-ported to 3.1-rc4.  This fixes a warning when some drivers,
> such as RADIO_WL1273, are selected, but MFD_SUPPORT is not. -- Luca]
> 
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> Reported-by: Johannes Berg <johannes@sipsolutions.net>
> Cc: Jean Delvare <khali@linux-fr.org>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Signed-off-by: Luciano Coelho <coelho@ti.com>
> ---
> 
> I guess this should fix the problem.  I've simple forward-ported
> Randy's patch to the latest mainline kernel.  I don't know via which
> tree this should go in, though.
> 
> NOTE: I have not tested this very thoroughly.  But at least
> omap2plus stuff seems to work okay with this change.  MFD_SUPPORT is
> also selected by a couple of "tile" platforms defconfigs, but I guess
> the Kconfig system should take care of it.

Doing this is a good idea, but incidentally I have just spent some time
with the same problem and ended up with a solution that I like better,
which is removing CONFIG_MFD_SUPPORT altogether.

The point is that there is no use enabling MFD_CORE if you don't also
enable any of the specific drivers. MFD_SUPPORT was added as a 'menuconfig'
before we had Kconfig warn about broken dependencies, so everything was
fine. Since Kconfig now issues the warnings, I think it would be better
to just turn the MFD menu into a plain 'menu' and remove all the
'depends on MFD_SUPPORT' and 'select MFD_SUPPORT' lines from the other
Kconfig files.

	Arnd

Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE

[Luciano Coelho]

On Wed, 2011-08-31 at 18:49 +0200, Arnd Bergmann wrote: 
> On Monday 29 August 2011, Luciano Coelho wrote:
> > From: Randy Dunlap <rdunlap@xenotime.net>
> > 
> > Combine MFD_SUPPORT (which only enabled the remainder of the MFD
> > menu) and MFD_CORE.  This allows other drivers to select MFD_CORE
> > without needing to also select MFD_SUPPORT, which fixes some
> > kconfig unmet dependency warnings.  Modeled after I2C kconfig.
> > 
> > [Forward-ported to 3.1-rc4.  This fixes a warning when some drivers,
> > such as RADIO_WL1273, are selected, but MFD_SUPPORT is not. -- Luca]
> > 
> > Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> > Reported-by: Johannes Berg <johannes@sipsolutions.net>
> > Cc: Jean Delvare <khali@linux-fr.org>
> > Cc: Tony Lindgren <tony@atomide.com>
> > Cc: Grant Likely <grant.likely@secretlab.ca>
> > Signed-off-by: Luciano Coelho <coelho@ti.com>
> > ---
> > 
> > I guess this should fix the problem.  I've simple forward-ported
> > Randy's patch to the latest mainline kernel.  I don't know via which
> > tree this should go in, though.
> > 
> > NOTE: I have not tested this very thoroughly.  But at least
> > omap2plus stuff seems to work okay with this change.  MFD_SUPPORT is
> > also selected by a couple of "tile" platforms defconfigs, but I guess
> > the Kconfig system should take care of it.
> 
> Doing this is a good idea, but incidentally I have just spent some time
> with the same problem and ended up with a solution that I like better,
> which is removing CONFIG_MFD_SUPPORT altogether.
> 
> The point is that there is no use enabling MFD_CORE if you don't also
> enable any of the specific drivers. MFD_SUPPORT was added as a 'menuconfig'
> before we had Kconfig warn about broken dependencies, so everything was
> fine. Since Kconfig now issues the warnings, I think it would be better
> to just turn the MFD menu into a plain 'menu' and remove all the
> 'depends on MFD_SUPPORT' and 'select MFD_SUPPORT' lines from the other
> Kconfig files.

Yes, this makes sense.  I think your solution is indeed cleaner.  If you
want to send it it's fine with me.  I don't really have any preference,
I just wanted to clean a problem that was reported to me. ;)

If you send your changes, my patch can be ignored, otherwise, I can send
a v2 with the changes Jean proposed.


-- 
Cheers,
Luca.

Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE

[Jean Delvare]

Hi Arnd,

On Wed, 31 Aug 2011 18:49:37 +0200, Arnd Bergmann wrote:
> On Monday 29 August 2011, Luciano Coelho wrote:
> > From: Randy Dunlap <rdunlap@xenotime.net>
> > 
> > Combine MFD_SUPPORT (which only enabled the remainder of the MFD
> > menu) and MFD_CORE.  This allows other drivers to select MFD_CORE
> > without needing to also select MFD_SUPPORT, which fixes some
> > kconfig unmet dependency warnings.  Modeled after I2C kconfig.
> > 
> > [Forward-ported to 3.1-rc4.  This fixes a warning when some drivers,
> > such as RADIO_WL1273, are selected, but MFD_SUPPORT is not. -- Luca]
> > 
> > Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> > Reported-by: Johannes Berg <johannes@sipsolutions.net>
> > Cc: Jean Delvare <khali@linux-fr.org>
> > Cc: Tony Lindgren <tony@atomide.com>
> > Cc: Grant Likely <grant.likely@secretlab.ca>
> > Signed-off-by: Luciano Coelho <coelho@ti.com>
> > ---
> > 
> > I guess this should fix the problem.  I've simple forward-ported
> > Randy's patch to the latest mainline kernel.  I don't know via which
> > tree this should go in, though.
> > 
> > NOTE: I have not tested this very thoroughly.  But at least
> > omap2plus stuff seems to work okay with this change.  MFD_SUPPORT is
> > also selected by a couple of "tile" platforms defconfigs, but I guess
> > the Kconfig system should take care of it.
> 
> Doing this is a good idea, but incidentally I have just spent some time
> with the same problem and ended up with a solution that I like better,
> which is removing CONFIG_MFD_SUPPORT altogether.
> 
> The point is that there is no use enabling MFD_CORE if you don't also
> enable any of the specific drivers.

Same holds for pretty much every subsystem, right?

> MFD_SUPPORT was added as a 'menuconfig'
> before we had Kconfig warn about broken dependencies, so everything was
> fine. Since Kconfig now issues the warnings, I think it would be better
> to just turn the MFD menu into a plain 'menu' and remove all the
> 'depends on MFD_SUPPORT' and 'select MFD_SUPPORT' lines from the other
> Kconfig files.

This would make it impossible to turn off all MFD drivers at once. I
think this is considered a feature, at least I find it very convenient
to be able to "kill" a subsystem completely. And in the past few years
many subsystems were turned from menu to menuconfig for this reason.
But maybe MFD is a special case here.

Anyway, if you want your patch to be applied, you'll have to send it
for review first, as at this point all we have is Luciano's proposal.

-- 
Jean Delvare

[PATCH 1/2] misc: remove CONFIG_MISC_DEVICES

[Arnd Bergmann]

Since misc devices have nothing in common besides fitting in no
other category, there is no need to group them in one Kconfig
symbol. Simply removing the symbol gets rid of all sorts of
Kconfig warnings about missing dependencies when another driver
selects a misc driver without also selecting MISC_DEVICES.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-davinci/Kconfig |    6 ------
 arch/unicore32/Kconfig        |    1 -
 drivers/misc/Kconfig          |   26 ++++++++------------------
 drivers/mmc/host/Kconfig      |    1 -
 4 files changed, 8 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index c0deaca..3755cec 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -61,7 +61,6 @@ config MACH_DAVINCI_EVM
 	bool "TI DM644x EVM"
 	default ARCH_DAVINCI_DM644x
 	depends on ARCH_DAVINCI_DM644x
-	select MISC_DEVICES
 	select EEPROM_AT24
 	select I2C
 	help
@@ -71,7 +70,6 @@ config MACH_DAVINCI_EVM
 config MACH_SFFSDR
 	bool "Lyrtech SFFSDR"
 	depends on ARCH_DAVINCI_DM644x
-	select MISC_DEVICES
 	select EEPROM_AT24
 	select I2C
 	help
@@ -105,7 +103,6 @@ config MACH_DAVINCI_DM6467_EVM
 	default ARCH_DAVINCI_DM646x
 	depends on ARCH_DAVINCI_DM646x
 	select MACH_DAVINCI_DM6467TEVM
-	select MISC_DEVICES
 	select EEPROM_AT24
 	select I2C
 	help
@@ -119,7 +116,6 @@ config MACH_DAVINCI_DM365_EVM
 	bool "TI DM365 EVM"
 	default ARCH_DAVINCI_DM365
 	depends on ARCH_DAVINCI_DM365
-	select MISC_DEVICES
 	select EEPROM_AT24
 	select I2C
 	help
@@ -131,7 +127,6 @@ config MACH_DAVINCI_DA830_EVM
 	default ARCH_DAVINCI_DA830
 	depends on ARCH_DAVINCI_DA830
 	select GPIO_PCF857X
-	select MISC_DEVICES
 	select EEPROM_AT24
 	select I2C
 	help
@@ -208,7 +203,6 @@ config MACH_TNETV107X
 config MACH_MITYOMAPL138
 	bool "Critical Link MityDSP-L138/MityARM-1808 SoM"
 	depends on ARCH_DAVINCI_DA850
-	select MISC_DEVICES
 	select EEPROM_AT24
 	select I2C
 	help
diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig
index e57dcce..5fb023a 100644
--- a/arch/unicore32/Kconfig
+++ b/arch/unicore32/Kconfig
@@ -244,7 +244,6 @@ config I2C_BATTERY_BQ27200
 config I2C_EEPROM_AT24
 	tristate "I2C EEPROMs AT24 support"
 	select PUV3_I2C
-	select MISC_DEVICES
 	select EEPROM_AT24
 
 config LCD_BACKLIGHT
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 2d6423c..c11e5ba 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -2,23 +2,7 @@
 # Misc strange devices
 #
 
-# This one has to live outside of the MISC_DEVICES conditional,
-# because it may be selected by drivers/platform/x86/hp_accel.
-config SENSORS_LIS3LV02D
-	tristate
-	depends on INPUT
-	select INPUT_POLLDEV
-	default n
-
-menuconfig MISC_DEVICES
-	bool "Misc devices"
-	---help---
-	  Say Y here to get to see options for device drivers from various
-	  different categories. This option alone does not add any kernel code.
-
-	  If you say N, all options in this submenu will be skipped and disabled.
-
-if MISC_DEVICES
+menu "Misc devices"
 
 config AD525X_DPOT
 	tristate "Analog Devices Digital Potentiometers"
@@ -344,6 +328,12 @@ config ISL29020
 	  This driver can also be built as a module.  If so, the module
 	  will be called isl29020.
 
+config SENSORS_LIS3LV02D
+	tristate
+	depends on INPUT
+	select INPUT_POLLDEV
+	default n
+
 config SENSORS_TSL2550
 	tristate "Taos TSL2550 ambient light sensor"
 	depends on I2C && SYSFS
@@ -507,4 +497,4 @@ source "drivers/misc/ti-st/Kconfig"
 source "drivers/misc/lis3lv02d/Kconfig"
 source "drivers/misc/carma/Kconfig"
 
-endif # MISC_DEVICES
+endmenu
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 8c87096..4fb03d4 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -477,7 +477,6 @@ config MMC_SDHI
 config MMC_CB710
 	tristate "ENE CB710 MMC/SD Interface support"
 	depends on PCI
-	select MISC_DEVICES
 	select CB710_CORE
 	help
 	  This option enables support for MMC/SD part of ENE CB710/720 Flash
-- 
1.7.1

Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES

[Jean Delvare]

Hi Arnd,

On Fri, 2 Sep 2011 16:43:14 +0200, Arnd Bergmann wrote:
> Since misc devices have nothing in common besides fitting in no
> other category, there is no need to group them in one Kconfig
> symbol. Simply removing the symbol gets rid of all sorts of
> Kconfig warnings about missing dependencies when another driver
> selects a misc driver without also selecting MISC_DEVICES.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  arch/arm/mach-davinci/Kconfig |    6 ------
>  arch/unicore32/Kconfig        |    1 -
>  drivers/misc/Kconfig          |   26 ++++++++------------------
>  drivers/mmc/host/Kconfig      |    1 -
>  4 files changed, 8 insertions(+), 26 deletions(-)
> (...)
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -2,23 +2,7 @@
>  # Misc strange devices
>  #
>  
> -# This one has to live outside of the MISC_DEVICES conditional,
> -# because it may be selected by drivers/platform/x86/hp_accel.
> -config SENSORS_LIS3LV02D
> -	tristate
> -	depends on INPUT
> -	select INPUT_POLLDEV
> -	default n
> -
> -menuconfig MISC_DEVICES
> -	bool "Misc devices"
> -	---help---
> -	  Say Y here to get to see options for device drivers from various
> -	  different categories. This option alone does not add any kernel code.
> -
> -	  If you say N, all options in this submenu will be skipped and disabled.
> -
> -if MISC_DEVICES
> +menu "Misc devices"

As said before, I'm not sure. Yes, it makes it easier to select misc
device drivers from Kconfig files. But it also makes it impossible to
deselect all misc device drivers at once.

I think that what we really need is the implementation in the Kconfig
system of smart selects, i.e. whenever an entry is selected, everything
it depends on gets selected as well. I don't know how feasible this is,
but if it can be done then I'd prefer this to your proposal.

Meanwhile, I am not in favor of applying your patch. The benefit is
relatively small IMHO (misc device drivers are rarely selected) and
there is one significant drawback.

That being said, I'm not the one to decide, so if you can convince
someone with more power (aka Andrew Morton)...

>  
>  config AD525X_DPOT
>  	tristate "Analog Devices Digital Potentiometers"
> @@ -344,6 +328,12 @@ config ISL29020
>  	  This driver can also be built as a module.  If so, the module
>  	  will be called isl29020.
>  
> +config SENSORS_LIS3LV02D
> +	tristate
> +	depends on INPUT
> +	select INPUT_POLLDEV
> +	default n
> +

If you patch gets applied, then this one would better be moved to
drivers/misc/lis3lv02d/Kconfig.

-- 
Jean Delvare

Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES

[Arnd Bergmann]

On Monday 05 September 2011, Jean Delvare wrote:
> As said before, I'm not sure. Yes, it makes it easier to select misc
> device drivers from Kconfig files. But it also makes it impossible to
> deselect all misc device drivers at once.
> 
> I think that what we really need is the implementation in the Kconfig
> system of smart selects, i.e. whenever an entry is selected, everything
> it depends on gets selected as well. I don't know how feasible this is,
> but if it can be done then I'd prefer this to your proposal.
> 
> Meanwhile, I am not in favor of applying your patch. The benefit is
> relatively small IMHO (misc device drivers are rarely selected) and
> there is one significant drawback.

Before I made this patch, I started a different one that added about
a dozen 'select MISC_DEVICES' statements sprinkled all over the kernel
in order to silence the Kconfig warnings.

The problem is that whenever you select that option, the misc directory
suddenly becomes visible when it was disabled before, and things like
'oldconfig' will start asking about all other misc drivers as well.

I think it would simply be more consistent to have it enabled all
the time. Well, even better would be to move the bulk of the misc
drivers to a proper location sorted by their subsystems. A lot of them
should never have been merged in their current state IMHO.

> That being said, I'm not the one to decide, so if you can convince
> someone with more power (aka Andrew Morton)...

I think I should finally do what has been  talked about a few times and
formally become the maintainer of drivers/char and drivers/misc ;-)

The problem is that I'm not actually a good maintainer, but maybe it's
better to just have someone instead of falling back to Andrew or
some random subsystem maintainer to send any patches for drivers/misc.

> >  config AD525X_DPOT
> >       tristate "Analog Devices Digital Potentiometers"
> > @@ -344,6 +328,12 @@ config ISL29020
> >         This driver can also be built as a module.  If so, the module
> >         will be called isl29020.
> >  
> > +config SENSORS_LIS3LV02D
> > +     tristate
> > +     depends on INPUT
> > +     select INPUT_POLLDEV
> > +     default n
> > +
> 
> If you patch gets applied, then this one would better be moved to
> drivers/misc/lis3lv02d/Kconfig.

Ah, that's true.

	Arnd

Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES

[Jean Delvare]

On Mon, 5 Sep 2011 16:19:35 +0200, Arnd Bergmann wrote:
> On Monday 05 September 2011, Jean Delvare wrote:
> > As said before, I'm not sure. Yes, it makes it easier to select misc
> > device drivers from Kconfig files. But it also makes it impossible to
> > deselect all misc device drivers at once.
> > 
> > I think that what we really need is the implementation in the Kconfig
> > system of smart selects, i.e. whenever an entry is selected, everything
> > it depends on gets selected as well. I don't know how feasible this is,
> > but if it can be done then I'd prefer this to your proposal.
> > 
> > Meanwhile, I am not in favor of applying your patch. The benefit is
> > relatively small IMHO (misc device drivers are rarely selected) and
> > there is one significant drawback.
> 
> Before I made this patch, I started a different one that added about
> a dozen 'select MISC_DEVICES' statements sprinkled all over the kernel
> in order to silence the Kconfig warnings.

Ah, OK. This certainly shifts the scales towards your side.

> The problem is that whenever you select that option, the misc directory
> suddenly becomes visible when it was disabled before, and things like
> 'oldconfig' will start asking about all other misc drivers as well.

Another good point. Maybe I'm convinced now.

> I think it would simply be more consistent to have it enabled all
> the time. Well, even better would be to move the bulk of the misc
> drivers to a proper location sorted by their subsystems. A lot of them
> should never have been merged in their current state IMHO.

As one of the offenders, I won't dare to comment on this ;)

> > That being said, I'm not the one to decide, so if you can convince
> > someone with more power (aka Andrew Morton)...
> 
> I think I should finally do what has been  talked about a few times and
> formally become the maintainer of drivers/char and drivers/misc ;-)
> 
> The problem is that I'm not actually a good maintainer, but maybe it's
> better to just have someone instead of falling back to Andrew or
> some random subsystem maintainer to send any patches for drivers/misc.

Certainly. And having a maintainer for these (non-)subsystems would
certainly help keep their size low, while the current trend is in the
other direction.

-- 
Jean Delvare

Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES

[Randy Dunlap]

On 09/05/2011 07:19 AM, Arnd Bergmann wrote:
> I think it would simply be more consistent to have it enabled all
> the time. Well, even better would be to move the bulk of the misc
> drivers to a proper location sorted by their subsystems. A lot of them
> should never have been merged in their current state IMHO.


If it's clear where they belong, then sure, they should be somewhere
other than drivers/misc/, but I don't see that it's clear for several
of them.


> I think I should finally do what has been  talked about a few times and
> formally become the maintainer of drivers/char and drivers/misc ;-)
> 
> The problem is that I'm not actually a good maintainer, but maybe it's
> better to just have someone instead of falling back to Andrew or
> some random subsystem maintainer to send any patches for drivers/misc.

We have fallbacks to Andrew and/or GregKH currently, but GregKH is not
consistent or timely with applying drivers/misc/ patches.  It deserves better.
[added him to Cc: list]

So yes, I think that drivers/misc/ (and probably drivers/char/) deserves
a maintainer, but you are not making a good case for you being that person.


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES

[Greg KH]

On Sun, Sep 18, 2011 at 08:11:45AM -0700, Randy Dunlap wrote:
> On 09/05/2011 07:19 AM, Arnd Bergmann wrote:
> > I think it would simply be more consistent to have it enabled all
> > the time. Well, even better would be to move the bulk of the misc
> > drivers to a proper location sorted by their subsystems. A lot of them
> > should never have been merged in their current state IMHO.
> 
> 
> If it's clear where they belong, then sure, they should be somewhere
> other than drivers/misc/, but I don't see that it's clear for several
> of them.
> 
> 
> > I think I should finally do what has been  talked about a few times and
> > formally become the maintainer of drivers/char and drivers/misc ;-)
> > 
> > The problem is that I'm not actually a good maintainer, but maybe it's
> > better to just have someone instead of falling back to Andrew or
> > some random subsystem maintainer to send any patches for drivers/misc.
> 
> We have fallbacks to Andrew and/or GregKH currently, but GregKH is not
> consistent or timely with applying drivers/misc/ patches.  It deserves better.
> [added him to Cc: list]

I do try to handle patches sent to me for misc/ in time for the
different merge windows as that directory contains drivers that have
moved out of the staging/ directory.

But yes, I'm not the overall drivers/misc/ maintainer, do we really need
one?  If so, I can easily start maintaining a development tree for it to
keep it separate for the different driver authors to send me stuff and
start tracking it more "for real" if Arnd doesn't want to do it.

thanks,

greg k-h

Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES

[Randy Dunlap]

On 09/18/2011 08:28 AM, Greg KH wrote:
> On Sun, Sep 18, 2011 at 08:11:45AM -0700, Randy Dunlap wrote:
>> On 09/05/2011 07:19 AM, Arnd Bergmann wrote:
>>> I think it would simply be more consistent to have it enabled all
>>> the time. Well, even better would be to move the bulk of the misc
>>> drivers to a proper location sorted by their subsystems. A lot of them
>>> should never have been merged in their current state IMHO.
>>
>>
>> If it's clear where they belong, then sure, they should be somewhere
>> other than drivers/misc/, but I don't see that it's clear for several
>> of them.
>>
>>
>>> I think I should finally do what has been  talked about a few times and
>>> formally become the maintainer of drivers/char and drivers/misc ;-)
>>>
>>> The problem is that I'm not actually a good maintainer, but maybe it's
>>> better to just have someone instead of falling back to Andrew or
>>> some random subsystem maintainer to send any patches for drivers/misc.
>>
>> We have fallbacks to Andrew and/or GregKH currently, but GregKH is not
>> consistent or timely with applying drivers/misc/ patches.  It deserves better.
>> [added him to Cc: list]
> 
> I do try to handle patches sent to me for misc/ in time for the
> different merge windows as that directory contains drivers that have
> moved out of the staging/ directory.
> 
> But yes, I'm not the overall drivers/misc/ maintainer, do we really need
> one?  If so, I can easily start maintaining a development tree for it to
> keep it separate for the different driver authors to send me stuff and
> start tracking it more "for real" if Arnd doesn't want to do it.

We need for the patches to be applied in a timely manner.
Sometimes when there is no real maintainer, that does not happen.

-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES

[Arnd Bergmann]

On Sunday 18 September 2011 11:45:16 Randy Dunlap wrote:
> >> We have fallbacks to Andrew and/or GregKH currently, but GregKH is not
> >> consistent or timely with applying drivers/misc/ patches.  It deserves better.
> >> [added him to Cc: list]
> > 
> > I do try to handle patches sent to me for misc/ in time for the
> > different merge windows as that directory contains drivers that have
> > moved out of the staging/ directory.
> > 
> > But yes, I'm not the overall drivers/misc/ maintainer, do we really need
> > one?  If so, I can easily start maintaining a development tree for it to
> > keep it separate for the different driver authors to send me stuff and
> > start tracking it more "for real" if Arnd doesn't want to do it.
> 
> We need for the patches to be applied in a timely manner.
> Sometimes when there is no real maintainer, that does not happen.

I think the other equally import aspect of maintainership that
drivers/misc (and drivers/char) needs is someone who says no to
stuff that doesn't belong there and helps submitters to find a
proper place where appropriate and to come up with a proper user
interface abstraction.

I'm definitely willing to do that part.

Greg, how about we both formally take ownership of driver/{misc,char}
and you track the patches while I do the bulk of the reviews? You
are definitely better than me with the patch tracking workflow.

	Arnd

Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES

[Greg KH]

On Mon, Sep 19, 2011 at 10:47:50AM +0200, Arnd Bergmann wrote:
> On Sunday 18 September 2011 11:45:16 Randy Dunlap wrote:
> > >> We have fallbacks to Andrew and/or GregKH currently, but GregKH is not
> > >> consistent or timely with applying drivers/misc/ patches.  It deserves better.
> > >> [added him to Cc: list]
> > > 
> > > I do try to handle patches sent to me for misc/ in time for the
> > > different merge windows as that directory contains drivers that have
> > > moved out of the staging/ directory.
> > > 
> > > But yes, I'm not the overall drivers/misc/ maintainer, do we really need
> > > one?  If so, I can easily start maintaining a development tree for it to
> > > keep it separate for the different driver authors to send me stuff and
> > > start tracking it more "for real" if Arnd doesn't want to do it.
> > 
> > We need for the patches to be applied in a timely manner.
> > Sometimes when there is no real maintainer, that does not happen.
> 
> I think the other equally import aspect of maintainership that
> drivers/misc (and drivers/char) needs is someone who says no to
> stuff that doesn't belong there and helps submitters to find a
> proper place where appropriate and to come up with a proper user
> interface abstraction.
> 
> I'm definitely willing to do that part.
> 
> Greg, how about we both formally take ownership of driver/{misc,char}
> and you track the patches while I do the bulk of the reviews? You
> are definitely better than me with the patch tracking workflow.

That sounds good to me, I'll be glad to collect the patches and push
them to Linus for both of those trees (might as well keep them in the
same git tree, no need to separate them, right?) and I'll rely on you
for review and acking them.  Much like I do today for the tty and serial
trees.

I'll go set up the trees locally today and when kernel.org opens back
up, make them public and add them to linux-next.

thanks,

greg k-h

Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES

[Arnd Bergmann]

On Monday 19 September 2011, Greg KH wrote:
> That sounds good to me, I'll be glad to collect the patches and push
> them to Linus for both of those trees (might as well keep them in the
> same git tree, no need to separate them, right?) and I'll rely on you
> for review and acking them.  Much like I do today for the tty and serial
> trees.
> 
> I'll go set up the trees locally today and when kernel.org opens back
> up, make them public and add them to linux-next.

Ok, great!

Thanks,

	Arnd

[PATCH 2/2] mfd: remove CONFIG_MFD_SUPPORT

[Arnd Bergmann]

We currently have two symbols to control compilation the MFD subsystem,
MFD_SUPPORT and MFD_CORE. The MFD_SUPPORT is actually not required
at all, it only hides the submenu when not set, with the effect that
Kconfig warns about missing dependencies when another driver selects
an MFD driver while MFD_SUPPORT is disabled. Turning the MFD submenu
back from menuconfig into a plain menu simplifies the Kconfig syntax
for those kinds of users and avoids the surprise when the menu
suddenly appears because another driver was enabled that selects this
symbol.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-omap2/Kconfig |    1 -
 drivers/gpio/Kconfig        |    3 +--
 drivers/i2c/busses/Kconfig  |    1 -
 drivers/media/radio/Kconfig |    1 -
 drivers/mfd/Kconfig         |   22 ++++------------------
 5 files changed, 5 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 57b66d5..1aee224 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -14,7 +14,6 @@ config ARCH_OMAP2PLUS_TYPICAL
 	select SERIAL_OMAP_CONSOLE
 	select I2C
 	select I2C_OMAP
-	select MFD_SUPPORT
 	select MENELAUS if ARCH_OMAP2
 	select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4
 	select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index d539efd..fbc5fd4 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -180,7 +180,7 @@ config GPIO_SCH
 
 config GPIO_VX855
 	tristate "VIA VX855/VX875 GPIO"
-	depends on MFD_SUPPORT && PCI
+	depends on PCI
 	select MFD_CORE
 	select MFD_VX855
 	help
@@ -417,7 +417,6 @@ config GPIO_TIMBERDALE
 config GPIO_RDC321X
 	tristate "RDC R-321x GPIO support"
 	depends on PCI
-	select MFD_SUPPORT
 	select MFD_CORE
 	select MFD_RDC321X
 	help
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 646068e..d625a48 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -110,7 +110,6 @@ config I2C_I801
 config I2C_ISCH
 	tristate "Intel SCH SMBus 1.0"
 	depends on PCI
-	select MFD_CORE
 	select LPC_SCH
 	help
 	  Say Y here if you want to use SMBus controller on the Intel SCH
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 52798a1..ccd5f0d 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -426,7 +426,6 @@ config RADIO_TIMBERDALE
 config RADIO_WL1273
 	tristate "Texas Instruments WL1273 I2C FM Radio"
 	depends on I2C && VIDEO_V4L2
-	select MFD_CORE
 	select MFD_WL1273_CORE
 	select FW_LOADER
 	---help---
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 21574bd..a7f1137 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2,23 +2,8 @@
 # Multifunction miscellaneous devices
 #
 
-menuconfig MFD_SUPPORT
-	bool "Multifunction device drivers"
-	depends on HAS_IOMEM
-	default y
-	help
-	  Multifunction devices embed several functions (e.g. GPIOs,
-	  touchscreens, keyboards, current regulators, power management chips,
-	  etc...) in one single integrated circuit. They usually talk to the
-	  main CPU through one or more IRQ lines and low speed data busses (SPI,
-	  I2C, etc..). They appear as one single device to the main system
-	  through the data bus and the MFD framework allows for sub devices
-	  (a.k.a. functions) to appear as discrete platform devices.
-	  MFDs are typically found on embedded platforms.
-
-	  This option alone does not add any kernel code.
-
-if MFD_SUPPORT
+if HAS_IOMEM
+menu "Multifunction device drivers"
 
 config MFD_CORE
 	tristate
@@ -770,7 +755,8 @@ config MFD_AAT2870_CORE
 	  additional drivers must be enabled in order to use the
 	  functionality of the device.
 
-endif # MFD_SUPPORT
+endmenu
+endif
 
 menu "Multimedia Capabilities Port drivers"
 	depends on ARCH_SA1100
-- 
1.7.1

Re: [PATCH 2/2] mfd: remove CONFIG_MFD_SUPPORT

[Jean Delvare]

On Fri, 2 Sep 2011 16:43:36 +0200, Arnd Bergmann wrote:
> We currently have two symbols to control compilation the MFD subsystem,
> MFD_SUPPORT and MFD_CORE. The MFD_SUPPORT is actually not required
> at all, it only hides the submenu when not set, with the effect that
> Kconfig warns about missing dependencies when another driver selects
> an MFD driver while MFD_SUPPORT is disabled. Turning the MFD submenu
> back from menuconfig into a plain menu simplifies the Kconfig syntax
> for those kinds of users and avoids the surprise when the menu
> suddenly appears because another driver was enabled that selects this
> symbol.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  arch/arm/mach-omap2/Kconfig |    1 -
>  drivers/gpio/Kconfig        |    3 +--
>  drivers/i2c/busses/Kconfig  |    1 -
>  drivers/media/radio/Kconfig |    1 -
>  drivers/mfd/Kconfig         |   22 ++++------------------
>  5 files changed, 5 insertions(+), 23 deletions(-)
> (...)
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -2,23 +2,8 @@
>  # Multifunction miscellaneous devices
>  #
>  
> -menuconfig MFD_SUPPORT
> -	bool "Multifunction device drivers"
> -	depends on HAS_IOMEM
> -	default y
> -	help
> -	  Multifunction devices embed several functions (e.g. GPIOs,
> -	  touchscreens, keyboards, current regulators, power management chips,
> -	  etc...) in one single integrated circuit. They usually talk to the
> -	  main CPU through one or more IRQ lines and low speed data busses (SPI,
> -	  I2C, etc..). They appear as one single device to the main system
> -	  through the data bus and the MFD framework allows for sub devices
> -	  (a.k.a. functions) to appear as discrete platform devices.
> -	  MFDs are typically found on embedded platforms.
> -
> -	  This option alone does not add any kernel code.
> -
> -if MFD_SUPPORT
> +if HAS_IOMEM
> +menu "Multifunction device drivers"
>  
>  config MFD_CORE
>  	tristate

I think I prefer Luciano's proposal, for the same reasons given for the
misc device drivers patch. But here again I'm not the one making the
decision, so it's up to Samuel to decide which patch he wants to apply.


-- 
Jean Delvare

Re: [PATCH 2/2] mfd: remove CONFIG_MFD_SUPPORT

[Samuel Ortiz]

Hi Arnd,

On Fri, Sep 02, 2011 at 04:43:36PM +0200, Arnd Bergmann wrote:
> We currently have two symbols to control compilation the MFD subsystem,
> MFD_SUPPORT and MFD_CORE. The MFD_SUPPORT is actually not required
> at all, it only hides the submenu when not set, with the effect that
> Kconfig warns about missing dependencies when another driver selects
> an MFD driver while MFD_SUPPORT is disabled. Turning the MFD submenu
> back from menuconfig into a plain menu simplifies the Kconfig syntax
> for those kinds of users and avoids the surprise when the menu
> suddenly appears because another driver was enabled that selects this
> symbol.
So I applied this one, thanks a lot.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE

[Arnd Bergmann]

On Friday 02 September 2011, Jean Delvare wrote:
> > Doing this is a good idea, but incidentally I have just spent some time
> > with the same problem and ended up with a solution that I like better,
> > which is removing CONFIG_MFD_SUPPORT altogether.
> > 
> > The point is that there is no use enabling MFD_CORE if you don't also
> > enable any of the specific drivers.
> 
> Same holds for pretty much every subsystem, right?

I think not: MFD is a bit different from other subsystems in that it does
not have a user space interface by itself. It's also different from bus
drivers in that it is not specific to some particular class of hardware,
since it only abstracts devices that do multiple things independent of
how they do them.

It is similar to MISC_DEVICES (drivers/misc) in some regards, and I
would also like to turn that one back from menuconfig into menu for
the same reasons.

> > MFD_SUPPORT was added as a 'menuconfig'
> > before we had Kconfig warn about broken dependencies, so everything was
> > fine. Since Kconfig now issues the warnings, I think it would be better
> > to just turn the MFD menu into a plain 'menu' and remove all the
> > 'depends on MFD_SUPPORT' and 'select MFD_SUPPORT' lines from the other
> > Kconfig files.
> 
> This would make it impossible to turn off all MFD drivers at once. I
> think this is considered a feature, at least I find it very convenient
> to be able to "kill" a subsystem completely. And in the past few years
> many subsystems were turned from menu to menuconfig for this reason.
> But maybe MFD is a special case here.

I agree that it's convenient for a lot of subsystems to be able to
turn them off entirely, but in case of MFD and MISC, I cannot see a clear
use case for that.

> Anyway, if you want your patch to be applied, you'll have to send it
> for review first, as at this point all we have is Luciano's proposal.

Ok. I had actually meant to send this mail out before the patches, but
apparently it got stuck in my mail client.

	Arnd

Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE

[Grant Likely]

On Mon, Aug 29, 2011 at 09:41:47PM +0300, Luciano Coelho wrote:
> ---
> @@ -417,7 +417,6 @@ config GPIO_TIMBERDALE
>  config GPIO_RDC321X
>  	tristate "RDC R-321x GPIO support"
>  	depends on PCI
> -	select MFD_SUPPORT
>  	select MFD_CORE
>  	select MFD_RDC321X
>  	help
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 21574bd..1836cdf 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -2,10 +2,9 @@
>  # Multifunction miscellaneous devices
>  #
>  
> -menuconfig MFD_SUPPORT
> -	bool "Multifunction device drivers"
> +menuconfig MFD_CORE
> +	tristate "Multifunction device drivers"
>  	depends on HAS_IOMEM
> -	default y

Looks like there is a bug here.  Kconfig symbols with dependencies
(HAS_IOMEM) must not ever be selected by other symbols because Kconfig
doesn't implement a way to resolve them.  This patch means that every
"select MFD_CORE" just assumes that HAS_IOMEM is also selected.

g.

Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE

[Arnd Bergmann]

On Thursday 15 September 2011, Grant Likely wrote:
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index 21574bd..1836cdf 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -2,10 +2,9 @@
> >  # Multifunction miscellaneous devices
> >  #
> >  
> > -menuconfig MFD_SUPPORT
> > -     bool "Multifunction device drivers"
> > +menuconfig MFD_CORE
> > +     tristate "Multifunction device drivers"
> >       depends on HAS_IOMEM
> > -     default y
> 
> Looks like there is a bug here.  Kconfig symbols with dependencies
> (HAS_IOMEM) must not ever be selected by other symbols because Kconfig
> doesn't implement a way to resolve them.  This patch means that every
> "select MFD_CORE" just assumes that HAS_IOMEM is also selected.

That is probably a fair assumption though. Almost all architectures
set HAS_IOMEM unconditionally, and the other ones (probably just s390)
would not select MFD_CORE.

Note that Samuel already took the other patch in the end, so it doesn't
matter. The patch I posted encloses the entire directory in "if HAS_IOMEM".

	Arnd