Skip to contentSkip to conversation

Kconfig unmet dependency with RADIO_WL1273

PATCH In review Luciano Coelho 7 participants 24 messages Aug 29, 2011 – Sep 19, 2011

Subsystems (11)
Arm (32-bit) Media (V4L/DVB) x86 Arm sub-architectures +7 more subsystems
lore
Share & tools
lore

Luciano Coelho

author
#0 lore raw

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:

drivers/media/radio/Kconfig +1 -1
index 52798a1..e87f544 100644
@@ -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 <[email protected]>
Signature · 2 lines
Cheers,
Luca.
#1 lore raw
Quoted 26 lines · 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:

drivers/media/radio/Kconfig +1 -1
index 52798a1..e87f544 100644
@@ -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
Quoted 4 lines

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 <[email protected]>

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 <[email protected]>

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 <[email protected]>
---
 drivers/mfd/Kconfig |   42 ++++--------------------------------------
 1 file changed, 4 insertions(+), 38 deletions(-)
drivers/mfd/Kconfig +4 -38
@@ -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
author
#2 lore raw

PATCH 1/1 mfd: Combine MFD_SUPPORT and MFD_CORE

From: Randy Dunlap <[email protected]>

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 <[email protected]>
Reported-by Johannes Berg <[email protected]>
Cc Jean Delvare <[email protected]>
Cc Tony Lindgren <[email protected]>
Cc Grant Likely <[email protected]>
Signed-off-by Luciano Coelho <[email protected]>

---

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(-)
arch/arm/mach-omap2/Kconfig +1 -1
index 57b66d5..1046923 100644
@@ -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
drivers/gpio/Kconfig +1 -2
index d539efd..fbc5fd4 100644
@@ -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
drivers/mfd/Kconfig +4 -50

316 lines not on this page · raw message

Signature · 1 line
1.7.1
#3 lore raw

Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE

Quoted 10 lines · Luciano Coelho

From: Randy Dunlap <[email protected]>

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]

Quoted 6 lines
Signed-off-by Randy Dunlap <[email protected]>
Reported-by Johannes Berg <[email protected]>
Cc Jean Delvare <[email protected]>
Cc Tony Lindgren <[email protected]>
Cc Grant Likely <[email protected]>
Signed-off-by Luciano Coelho <[email protected]>

okay by me.

g.

Quoted 414 lines

---

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(-)
arch/arm/mach-omap2/Kconfig +0 -0
index 57b66d5..1046923 100644
@@ -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

drivers/gpio/Kconfig +0 -0
index d539efd..fbc5fd4 100644
@@ -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

drivers/gpio/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +2 -2
index 21574bd..1836cdf 100644
@@ -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,

drivers/mfd/Kconfig +0 -0
@@ -18,16 +17,11 @@ menuconfig MFD_SUPPORT

         This option alone does not add any kernel code.

drivers/mfd/Kconfig +1 -5
-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

drivers/mfd/Kconfig +0 -0
@@ -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"

drivers/mfd/Kconfig +0 -0
@@ -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.

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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.

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -252,7 +236,6 @@ config TWL4030_POWER

 config MFD_TWL4030_AUDIO
       bool
       depends on TWL4030_CORE
-       select MFD_CORE
       default n

 config TWL6030_PWM

drivers/mfd/Kconfig +0 -0
@@ -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.

drivers/mfd/Kconfig +0 -0
@@ -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.

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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,

drivers/mfd/Kconfig +0 -0
@@ -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.

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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

drivers/mfd/Kconfig +0 -0
@@ -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.

drivers/mfd/Kconfig +0 -0
@@ -770,7 +724,7 @@ config MFD_AAT2870_CORE

         additional drivers must be enabled in order to use the functionality of the device.

drivers/mfd/Kconfig +1 -1
-endif # MFD_SUPPORT
+endif # MFD_CORE

 menu "Multimedia Capabilities Port drivers"
       depends on ARCH_SA1100
--
1.7.1

Signature · 2 lines
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
Acked-by on v1 1/1
#4 lore raw

Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE

In reply to Luciano Coelho

Hi Luciano,

Quoted 9 lines · Luciano Coelho

From: Randy Dunlap <[email protected]>

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:

arch/x86/Kconfig +0 -2
@@ -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
Quoted 7 lines
Signed-off-by Randy Dunlap <[email protected]>
Reported-by Johannes Berg <[email protected]>
Cc Jean Delvare <[email protected]>
Cc Tony Lindgren <[email protected]>
Cc Grant Likely <[email protected]>
Signed-off-by Luciano Coelho <[email protected]>
Quoted 5 lines

---

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.

Quoted 4 lines

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 <[email protected]>
Signature · 1 line
Jean Delvare
maintainer
#5 lore raw

Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE

In reply to Luciano Coelho
Quoted 18 lines · Luciano Coelho

From: Randy Dunlap <[email protected]>

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 <[email protected]>
Reported-by Johannes Berg <[email protected]>
Cc Jean Delvare <[email protected]>
Cc Tony Lindgren <[email protected]>
Cc Grant Likely <[email protected]>
Signed-off-by Luciano Coelho <[email protected]>

---

Quoted 8 lines

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

author
#6 lore raw

Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE

Quoted 32 lines · Arnd Bergmann
Quoted 18 lines · Luciano Coelho

From: Randy Dunlap <[email protected]>

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 <[email protected]>
Reported-by Johannes Berg <[email protected]>
Cc Jean Delvare <[email protected]>
Cc Tony Lindgren <[email protected]>
Cc Grant Likely <[email protected]>
Signed-off-by Luciano Coelho <[email protected]>

---

Quoted 8 lines

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.

Quoted 7 lines

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.

Signature · 2 lines
Cheers,
Luca.
#7 lore raw

Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE

In reply to Arnd Bergmann

Hi Arnd,

Quoted 28 lines · Arnd Bergmann
Quoted 18 lines · Luciano Coelho

From: Randy Dunlap <[email protected]>

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 <[email protected]>
Reported-by Johannes Berg <[email protected]>
Cc Jean Delvare <[email protected]>
Cc Tony Lindgren <[email protected]>
Cc Grant Likely <[email protected]>
Signed-off-by Luciano Coelho <[email protected]>

---

Quoted 8 lines

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.

Quoted 6 lines

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?

Quoted 6 lines

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.

Signature · 1 line
Jean Delvare
maintainer
#8 lore raw

PATCH 1/2 misc: remove CONFIG_MISC_DEVICES

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 <[email protected]>
---
 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(-)
arch/arm/mach-davinci/Kconfig +0 -6
index c0deaca..3755cec 100644
@@ -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
arch/unicore32/Kconfig +0 -1
index e57dcce..5fb023a 100644
@@ -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
drivers/misc/Kconfig +8 -18
index 2d6423c..c11e5ba 100644
@@ -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
drivers/mmc/host/Kconfig +0 -1
index 8c87096..4fb03d4 100644
@@ -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
Signature · 1 line
1.7.1
#9 lore raw

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

Hi Arnd,

Quoted 28 lines · 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 <[email protected]>
---
 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(-)

(...)

drivers/misc/Kconfig +0 -8
@@ -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
-

drivers/misc/Kconfig line 5

Quoted 10 lines
drivers/misc/Kconfig +1 -9
-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)...

drivers/misc/Kconfig config ISL29020 · line 336

Quoted 13 lines
drivers/misc/Kconfig +6 -0
 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.

Signature · 1 line
Jean Delvare
maintainer
#10 lore raw

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

Quoted 4 lines · Jean Delvare

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.

Quoted 8 lines

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.

Quoted 2 lines

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.

Quoted 6 lines
Quoted 6 lines

config AD525X_DPOT
tristate "Analog Devices Digital Potentiometers"

drivers/misc/Kconfig +0 -0
@@ -344,6 +328,12 @@ config ISL29020
        This driver can also be built as a module.  If so, the module
        will be called isl29020.
Quoted 9 lines

drivers/misc/Kconfig config ISL29020 · line 336

Quoted 6 lines
drivers/misc/Kconfig +6 -0
+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

#11 lore raw

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

Quoted 10 lines · Arnd Bergmann
Quoted 9 lines · Jean Delvare

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.

Quoted 7 lines
Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 4 lines

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 ;)

Quoted 9 lines
Quoted 2 lines

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.

Signature · 1 line
Jean Delvare
#12 lore raw

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

In reply to Arnd Bergmann
Quoted 4 lines · Arnd Bergmann

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.

Quoted 6 lines

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.

Signature · 2 lines
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
#13 lore raw

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

Quoted 15 lines · Randy Dunlap
Quoted 4 lines · Arnd Bergmann

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.

Quoted 3 lines

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 ;-)

Quoted 7 lines
Quoted 3 lines

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

#14 lore raw

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

Quoted 24 lines · Greg KH
Quoted 15 lines · Randy Dunlap
Quoted 4 lines · Arnd Bergmann

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.

Quoted 3 lines

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 ;-)

Quoted 7 lines
Quoted 3 lines

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]

Quoted 8 lines

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.

Signature · 2 lines
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
maintainer
#15 lore raw

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

Quoted 8 lines · On Sunday 18 September 2011 11:45:16 Randy Dunlap wrote:
Quoted 8 lines
Quoted 3 lines

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.

Quoted 7 lines
Quoted 4 lines

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

#16 lore raw

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

Quoted 23 lines · Arnd Bergmann
Quoted 8 lines · On Sunday 18 September 2011 11:45:16 Randy Dunlap wrote:
Quoted 8 lines
Quoted 3 lines

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.

Quoted 7 lines
Quoted 4 lines

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.

Quoted 5 lines

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

maintainer
#17 lore raw

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

Quoted 8 lines · Greg KH

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

maintainer
#18 lore raw

PATCH 2/2 mfd: remove CONFIG_MFD_SUPPORT

In reply to Jean Delvare

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 <[email protected]>
---
 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(-)
arch/arm/mach-omap2/Kconfig +0 -1
index 57b66d5..1aee224 100644
@@ -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
drivers/gpio/Kconfig +1 -2
index d539efd..fbc5fd4 100644
@@ -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
drivers/i2c/busses/Kconfig +0 -1
index 646068e..d625a48 100644
@@ -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
drivers/media/radio/Kconfig +0 -1
index 52798a1..ccd5f0d 100644
@@ -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---
drivers/mfd/Kconfig +4 -18
index 21574bd..a7f1137 100644
@@ -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
Signature · 1 line
1.7.1
#19 lore raw

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

Quoted 37 lines · 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 <[email protected]>
---
 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(-)

(...)

drivers/mfd/Kconfig +0 -12
@@ -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.

drivers/mfd/Kconfig line 9

Quoted 10 lines
drivers/mfd/Kconfig +2 -5
-	  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.

Signature · 1 line
Jean Delvare
#20 lore raw

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

In reply to Arnd Bergmann

Hi Arnd,

Quoted 9 lines · 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.

So I applied this one, thanks a lot.

Cheers,
Samuel.

Signature · 2 lines
Intel Open Source Technology Centre
http://oss.intel.com/
maintainer
#21 lore raw

Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE

In reply to Jean Delvare
Quoted 8 lines · Jean Delvare
Quoted 6 lines

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.

Quoted 7 lines
Quoted 6 lines

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.

Quoted 5 lines

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.

Quoted 2 lines

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

#22 lore raw

Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE

In reply to Luciano Coelho
Quoted 14 lines · Luciano Coelho

---

drivers/gpio/Kconfig +0 -1
@@ -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
drivers/mfd/Kconfig +0 -0
index 21574bd..1836cdf 100644

drivers/mfd/Kconfig line 8

Quoted 9 lines
drivers/mfd/Kconfig +2 -3
@@ -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.

maintainer
#23 lore raw

Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE

Quoted 8 lines · Grant Likely
Quoted 8 lines
drivers/mfd/Kconfig +0 -0
index 21574bd..1836cdf 100644
@@ -2,10 +2,9 @@
 # Multifunction miscellaneous devices
 #
Quoted 11 lines

drivers/mfd/Kconfig line 8

Quoted 6 lines
drivers/mfd/Kconfig +2 -3
-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