* [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE [not found] <20110829102732.03f0f05d.rdunlap@xenotime.net> @ 2011-08-29 18:41 ` Luciano Coelho 2011-08-29 18:54 ` Grant Likely ` (3 more replies) 0 siblings, 4 replies; 22+ messages in thread From: Luciano Coelho @ 2011-08-29 18:41 UTC (permalink / raw) Cc: matti.j.aaltonen, johannes, linux-kernel, sameo, mchehab, linux-media, linux-omap, Randy Dunlap, Jean Delvare, Tony Lindgren, Grant Likely 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE 2011-08-29 18:41 ` [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE Luciano Coelho @ 2011-08-29 18:54 ` Grant Likely 2011-08-31 16:18 ` Jean Delvare ` (2 subsequent siblings) 3 siblings, 0 replies; 22+ messages in thread From: Grant Likely @ 2011-08-29 18:54 UTC (permalink / raw) To: Luciano Coelho Cc: Randy Dunlap, matti.j.aaltonen, johannes, linux-kernel, sameo, mchehab, linux-media, linux-omap, Jean Delvare, Tony Lindgren 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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE 2011-08-29 18:41 ` [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE Luciano Coelho 2011-08-29 18:54 ` Grant Likely @ 2011-08-31 16:18 ` Jean Delvare 2011-08-31 16:49 ` Arnd Bergmann 2011-09-15 17:16 ` Grant Likely 3 siblings, 0 replies; 22+ messages in thread From: Jean Delvare @ 2011-08-31 16:18 UTC (permalink / raw) To: Luciano Coelho Cc: Randy Dunlap, matti.j.aaltonen, johannes, linux-kernel, sameo, mchehab, linux-media, linux-omap, Tony Lindgren, Grant Likely 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE 2011-08-29 18:41 ` [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE Luciano Coelho 2011-08-29 18:54 ` Grant Likely 2011-08-31 16:18 ` Jean Delvare @ 2011-08-31 16:49 ` Arnd Bergmann 2011-09-02 11:54 ` Luciano Coelho 2011-09-02 12:37 ` Jean Delvare 2011-09-15 17:16 ` Grant Likely 3 siblings, 2 replies; 22+ messages in thread From: Arnd Bergmann @ 2011-08-31 16:49 UTC (permalink / raw) To: Luciano Coelho Cc: Randy Dunlap, matti.j.aaltonen, johannes, linux-kernel, sameo, mchehab, linux-media, linux-omap, Jean Delvare, Tony Lindgren, Grant Likely 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE 2011-08-31 16:49 ` Arnd Bergmann @ 2011-09-02 11:54 ` Luciano Coelho 2011-09-02 12:37 ` Jean Delvare 1 sibling, 0 replies; 22+ messages in thread From: Luciano Coelho @ 2011-09-02 11:54 UTC (permalink / raw) To: Arnd Bergmann Cc: Randy Dunlap, matti.j.aaltonen, johannes, linux-kernel, sameo, mchehab, linux-media, linux-omap, Jean Delvare, Tony Lindgren, Grant Likely 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE 2011-08-31 16:49 ` Arnd Bergmann 2011-09-02 11:54 ` Luciano Coelho @ 2011-09-02 12:37 ` Jean Delvare 2011-09-02 14:43 ` [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES Arnd Bergmann ` (2 more replies) 1 sibling, 3 replies; 22+ messages in thread From: Jean Delvare @ 2011-09-02 12:37 UTC (permalink / raw) To: Arnd Bergmann Cc: Luciano Coelho, Randy Dunlap, matti.j.aaltonen, johannes, linux-kernel, sameo, mchehab, linux-media, linux-omap, Tony Lindgren, Grant Likely 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES 2011-09-02 12:37 ` Jean Delvare @ 2011-09-02 14:43 ` Arnd Bergmann 2011-09-05 12:41 ` Jean Delvare 2011-09-02 14:43 ` [PATCH 2/2] mfd: remove CONFIG_MFD_SUPPORT Arnd Bergmann 2011-09-02 15:49 ` [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE Arnd Bergmann 2 siblings, 1 reply; 22+ messages in thread From: Arnd Bergmann @ 2011-09-02 14:43 UTC (permalink / raw) To: Jean Delvare Cc: Luciano Coelho, Randy Dunlap, matti.j.aaltonen, johannes, linux-kernel, sameo, mchehab, linux-media, linux-omap, Tony Lindgren, Grant Likely 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES 2011-09-02 14:43 ` [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES Arnd Bergmann @ 2011-09-05 12:41 ` Jean Delvare 2011-09-05 14:19 ` Arnd Bergmann 0 siblings, 1 reply; 22+ messages in thread From: Jean Delvare @ 2011-09-05 12:41 UTC (permalink / raw) To: Arnd Bergmann Cc: Luciano Coelho, Randy Dunlap, matti.j.aaltonen, johannes, linux-kernel, sameo, mchehab, linux-media, linux-omap, Tony Lindgren, Grant Likely 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES 2011-09-05 12:41 ` Jean Delvare @ 2011-09-05 14:19 ` Arnd Bergmann 2011-09-05 14:27 ` Jean Delvare 2011-09-18 15:11 ` Randy Dunlap 0 siblings, 2 replies; 22+ messages in thread From: Arnd Bergmann @ 2011-09-05 14:19 UTC (permalink / raw) To: Jean Delvare Cc: Luciano Coelho, Randy Dunlap, matti.j.aaltonen, johannes, linux-kernel, sameo, mchehab, linux-media, linux-omap, Tony Lindgren, Grant Likely 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES 2011-09-05 14:19 ` Arnd Bergmann @ 2011-09-05 14:27 ` Jean Delvare 2011-09-18 15:11 ` Randy Dunlap 1 sibling, 0 replies; 22+ messages in thread From: Jean Delvare @ 2011-09-05 14:27 UTC (permalink / raw) To: Arnd Bergmann Cc: Luciano Coelho, Randy Dunlap, matti.j.aaltonen, johannes, linux-kernel, sameo, mchehab, linux-media, linux-omap, Tony Lindgren, Grant Likely 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES 2011-09-05 14:19 ` Arnd Bergmann 2011-09-05 14:27 ` Jean Delvare @ 2011-09-18 15:11 ` Randy Dunlap 2011-09-18 15:28 ` Greg KH 1 sibling, 1 reply; 22+ messages in thread From: Randy Dunlap @ 2011-09-18 15:11 UTC (permalink / raw) To: Arnd Bergmann Cc: Jean Delvare, Luciano Coelho, matti.j.aaltonen, johannes, linux-kernel, sameo, mchehab, linux-media, linux-omap, Tony Lindgren, Grant Likely, Greg KH 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 *** ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES 2011-09-18 15:11 ` Randy Dunlap @ 2011-09-18 15:28 ` Greg KH 2011-09-18 18:45 ` Randy Dunlap 0 siblings, 1 reply; 22+ messages in thread From: Greg KH @ 2011-09-18 15:28 UTC (permalink / raw) To: Randy Dunlap Cc: Arnd Bergmann, Jean Delvare, Luciano Coelho, matti.j.aaltonen, johannes, linux-kernel, sameo, mchehab, linux-media, linux-omap, Tony Lindgren, Grant Likely 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES 2011-09-18 15:28 ` Greg KH @ 2011-09-18 18:45 ` Randy Dunlap 2011-09-19 8:47 ` Arnd Bergmann 0 siblings, 1 reply; 22+ messages in thread From: Randy Dunlap @ 2011-09-18 18:45 UTC (permalink / raw) To: Greg KH Cc: Arnd Bergmann, Jean Delvare, Luciano Coelho, matti.j.aaltonen, johannes, linux-kernel, sameo, mchehab, linux-media, linux-omap, Tony Lindgren, Grant Likely 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 *** ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES 2011-09-18 18:45 ` Randy Dunlap @ 2011-09-19 8:47 ` Arnd Bergmann 2011-09-19 13:07 ` Greg KH 0 siblings, 1 reply; 22+ messages in thread From: Arnd Bergmann @ 2011-09-19 8:47 UTC (permalink / raw) To: Randy Dunlap Cc: Greg KH, Jean Delvare, Luciano Coelho, matti.j.aaltonen, johannes, linux-kernel, sameo, mchehab, linux-media, linux-omap, Tony Lindgren, Grant Likely 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES 2011-09-19 8:47 ` Arnd Bergmann @ 2011-09-19 13:07 ` Greg KH 2011-09-19 15:14 ` Arnd Bergmann 0 siblings, 1 reply; 22+ messages in thread From: Greg KH @ 2011-09-19 13:07 UTC (permalink / raw) To: Arnd Bergmann Cc: Randy Dunlap, Jean Delvare, Luciano Coelho, matti.j.aaltonen, johannes, linux-kernel, sameo, mchehab, linux-media, linux-omap, Tony Lindgren, Grant Likely 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES 2011-09-19 13:07 ` Greg KH @ 2011-09-19 15:14 ` Arnd Bergmann 0 siblings, 0 replies; 22+ messages in thread From: Arnd Bergmann @ 2011-09-19 15:14 UTC (permalink / raw) To: Greg KH Cc: Randy Dunlap, Jean Delvare, Luciano Coelho, matti.j.aaltonen, johannes, linux-kernel, sameo, mchehab, linux-media, linux-omap, Tony Lindgren, Grant Likely 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 2/2] mfd: remove CONFIG_MFD_SUPPORT 2011-09-02 12:37 ` Jean Delvare 2011-09-02 14:43 ` [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES Arnd Bergmann @ 2011-09-02 14:43 ` Arnd Bergmann 2011-09-05 13:09 ` Jean Delvare 2011-09-15 15:46 ` Samuel Ortiz 2011-09-02 15:49 ` [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE Arnd Bergmann 2 siblings, 2 replies; 22+ messages in thread From: Arnd Bergmann @ 2011-09-02 14:43 UTC (permalink / raw) To: Jean Delvare Cc: Luciano Coelho, Randy Dunlap, matti.j.aaltonen, johannes, linux-kernel, sameo, mchehab, linux-media, linux-omap, Tony Lindgren, Grant Likely 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] mfd: remove CONFIG_MFD_SUPPORT 2011-09-02 14:43 ` [PATCH 2/2] mfd: remove CONFIG_MFD_SUPPORT Arnd Bergmann @ 2011-09-05 13:09 ` Jean Delvare 2011-09-15 15:46 ` Samuel Ortiz 1 sibling, 0 replies; 22+ messages in thread From: Jean Delvare @ 2011-09-05 13:09 UTC (permalink / raw) To: Arnd Bergmann Cc: Luciano Coelho, Randy Dunlap, matti.j.aaltonen, johannes, linux-kernel, sameo, mchehab, linux-media, linux-omap, Tony Lindgren, Grant Likely 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] mfd: remove CONFIG_MFD_SUPPORT 2011-09-02 14:43 ` [PATCH 2/2] mfd: remove CONFIG_MFD_SUPPORT Arnd Bergmann 2011-09-05 13:09 ` Jean Delvare @ 2011-09-15 15:46 ` Samuel Ortiz 1 sibling, 0 replies; 22+ messages in thread From: Samuel Ortiz @ 2011-09-15 15:46 UTC (permalink / raw) To: Arnd Bergmann Cc: Jean Delvare, Luciano Coelho, Randy Dunlap, matti.j.aaltonen, johannes, linux-kernel, mchehab, linux-media, linux-omap, Tony Lindgren, Grant Likely 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE 2011-09-02 12:37 ` Jean Delvare 2011-09-02 14:43 ` [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES Arnd Bergmann 2011-09-02 14:43 ` [PATCH 2/2] mfd: remove CONFIG_MFD_SUPPORT Arnd Bergmann @ 2011-09-02 15:49 ` Arnd Bergmann 2 siblings, 0 replies; 22+ messages in thread From: Arnd Bergmann @ 2011-09-02 15:49 UTC (permalink / raw) To: Jean Delvare Cc: Luciano Coelho, Randy Dunlap, matti.j.aaltonen, johannes, linux-kernel, sameo, mchehab, linux-media, linux-omap, Tony Lindgren, Grant Likely 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE 2011-08-29 18:41 ` [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE Luciano Coelho ` (2 preceding siblings ...) 2011-08-31 16:49 ` Arnd Bergmann @ 2011-09-15 17:16 ` Grant Likely 2011-09-19 15:06 ` Arnd Bergmann 3 siblings, 1 reply; 22+ messages in thread From: Grant Likely @ 2011-09-15 17:16 UTC (permalink / raw) To: Luciano Coelho Cc: Randy Dunlap, matti.j.aaltonen, johannes, linux-kernel, sameo, mchehab, linux-media, linux-omap, Jean Delvare, Tony Lindgren 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE 2011-09-15 17:16 ` Grant Likely @ 2011-09-19 15:06 ` Arnd Bergmann 0 siblings, 0 replies; 22+ messages in thread From: Arnd Bergmann @ 2011-09-19 15:06 UTC (permalink / raw) To: Grant Likely Cc: Luciano Coelho, Randy Dunlap, matti.j.aaltonen, johannes, linux-kernel, sameo, mchehab, linux-media, linux-omap, Jean Delvare, Tony Lindgren 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2011-09-19 15:14 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20110829102732.03f0f05d.rdunlap@xenotime.net>
2011-08-29 18:41 ` [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE Luciano Coelho
2011-08-29 18:54 ` Grant Likely
2011-08-31 16:18 ` Jean Delvare
2011-08-31 16:49 ` Arnd Bergmann
2011-09-02 11:54 ` Luciano Coelho
2011-09-02 12:37 ` Jean Delvare
2011-09-02 14:43 ` [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES Arnd Bergmann
2011-09-05 12:41 ` Jean Delvare
2011-09-05 14:19 ` Arnd Bergmann
2011-09-05 14:27 ` Jean Delvare
2011-09-18 15:11 ` Randy Dunlap
2011-09-18 15:28 ` Greg KH
2011-09-18 18:45 ` Randy Dunlap
2011-09-19 8:47 ` Arnd Bergmann
2011-09-19 13:07 ` Greg KH
2011-09-19 15:14 ` Arnd Bergmann
2011-09-02 14:43 ` [PATCH 2/2] mfd: remove CONFIG_MFD_SUPPORT Arnd Bergmann
2011-09-05 13:09 ` Jean Delvare
2011-09-15 15:46 ` Samuel Ortiz
2011-09-02 15:49 ` [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE Arnd Bergmann
2011-09-15 17:16 ` Grant Likely
2011-09-19 15:06 ` Arnd Bergmann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox