Re: [PATCH v3 2/2] drivers: cleanup Kconfig stuff
On Tue, Nov 02, 2010 at 02:14:13AM +0200, Felipe Contreras wrote: config REGULATOR_TWL4030 bool TI TWL4030/TWL5030/TWL6030/TPS695x0 PMIC depends on TWL4030_CORE + default y help This driver supports the voltage regulators provided by this family of companion chips. This default is not suitable for non-OMAP platforms, it should be conditional on OMAP or something if we're going to do this (though generally we handle this with defconfigs rather than in Kconfig). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] drivers: cleanup Kconfig stuff
On Tue, Nov 2, 2010 at 3:11 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Tue, Nov 02, 2010 at 02:14:13AM +0200, Felipe Contreras wrote: config REGULATOR_TWL4030 bool TI TWL4030/TWL5030/TWL6030/TPS695x0 PMIC depends on TWL4030_CORE + default y help This driver supports the voltage regulators provided by this family of companion chips. This default is not suitable for non-OMAP platforms, it should be conditional on OMAP or something if we're going to do this (though generally we handle this with defconfigs rather than in Kconfig). This would only be enabled when TWL4030_CORE is enabled, so non-OMAP platforms would not get affected. I guess you have seen the complaint from Linus regarding ARM relying too much on defconfigs. This helps in order to simplify defconfigs, and eventually getting rid of them completely. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] drivers: cleanup Kconfig stuff
On Tue, Nov 02, 2010 at 04:02:18PM +0200, Felipe Contreras wrote: On Tue, Nov 2, 2010 at 3:11 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Tue, Nov 02, 2010 at 02:14:13AM +0200, Felipe Contreras wrote: config REGULATOR_TWL4030 bool TI TWL4030/TWL5030/TWL6030/TPS695x0 PMIC depends on TWL4030_CORE + default y help This driver supports the voltage regulators provided by this family of companion chips. This default is not suitable for non-OMAP platforms, it should be conditional on OMAP or something if we're going to do this (though generally we handle this with defconfigs rather than in Kconfig). This would only be enabled when TWL4030_CORE is enabled, so non-OMAP platforms would not get affected. Well, all platforms that have TWL4030_CORE will get REGULATOR_TWL4030 by default, too. (TWL4030_CORE doesn't depend on something omapish.) For me this looks OK. It would be still better if it removed CONFIG_REGULATOR_TWL4030=y from arch/arm/configs/omap2plus_defconfig. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] drivers: cleanup Kconfig stuff
On Tue, Nov 02, 2010 at 02:14:13AM +0200, Felipe Contreras wrote: Add missing dependencies, and remove redundant ones, and select sensible defaults. This is more user-friendly, and logical. - TWL4030_CORE people should be able to compile without ARM - REGULATOR_TWL4030 if TWL4030_CORE and REGULATOR, it's pretty clear we want this - USB_GADGET_SELECTED is already inside USB_GADGET - USB_GADGET_OMAP only works on ARCH_OMAP1, and USB_OTG_UTILS is already selected by NOP_USB_XCEIV - USB_GADGET_R8A66597 is meant for ARCH_SHMOBILE - USB_MUSB_HDRC needs either NOP_USB_XCEIV, or TWL4030_USB - USB_MUSB_AM35X, NOP_USB_XCEIV is already selected because MACH_OMAP3EVM Finally, move: config USB_MUSB_HDRC select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) select TWL4030_USB if MACH_OMAP_3430SDP To: config TWL4030_USB default y if ARCH_OMAP3 config NOP_USB_XCEIV default y if ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN Signed-off-by: Felipe Contreras felipe.contre...@gmail.com All changes look fine to me, but I think you will need to split up this patch for the different subsystem maintainers. Best regards Uwe --- drivers/mfd/Kconfig|2 +- drivers/regulator/Kconfig |1 + drivers/usb/gadget/Kconfig |5 ++--- drivers/usb/musb/Kconfig |7 ++- drivers/usb/otg/Kconfig|2 ++ 5 files changed, 8 insertions(+), 9 deletions(-) diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 3a1493b..88e47a0 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -169,7 +169,7 @@ config TWL4030_CORE config TWL4030_POWER bool Support power resources on TWL4030 family chips - depends on TWL4030_CORE ARM + depends on TWL4030_CORE help Say yes here if you want to use the power resources on the TWL4030 family chips. Most of these resources are regulators, diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig index dd30e88..1397f7a 100644 --- a/drivers/regulator/Kconfig +++ b/drivers/regulator/Kconfig @@ -119,6 +119,7 @@ config REGULATOR_MAX8998 config REGULATOR_TWL4030 bool TI TWL4030/TWL5030/TWL6030/TPS695x0 PMIC depends on TWL4030_CORE + default y help This driver supports the voltage regulators provided by this family of companion chips. diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index 75733cd..0ad0c32 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -111,7 +111,6 @@ configUSB_GADGET_SELECTED # choice prompt USB Peripheral Controller - depends on USB_GADGET help A USB device uses a controller to talk to its host. Systems should have only one such upstream link. @@ -190,9 +189,8 @@ config USB_LH7A40X config USB_GADGET_OMAP boolean OMAP USB Device Controller - depends on ARCH_OMAP + depends on ARCH_OMAP1 select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 || MACH_OMAP_H4_OTG - select USB_OTG_UTILS if ARCH_OMAP help Many Texas Instruments OMAP processors have flexible full speed USB device controllers, with support for up to 30 @@ -244,6 +242,7 @@ config USB_PXA25X_SMALL config USB_GADGET_R8A66597 boolean Renesas R8A66597 USB Peripheral Controller + depends on ARCH_SHMOBILE select USB_GADGET_DUALSPEED help R8A66597 is a discrete USB host and peripheral controller chip that diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index f0e0495..5951b9f 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -11,8 +11,7 @@ config USB_MUSB_HDRC tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' depends on (USB || USB_GADGET) depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) - select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) - select TWL4030_USB if MACH_OMAP_3430SDP + depends on (NOP_USB_XCEIV || TWL4030_USB) select USB_OTG_UTILS help Say Y here if your system has a dual role high speed USB @@ -63,7 +62,6 @@ comment Blackfin high speed USB Support config USB_MUSB_AM35X bool depends on USB_MUSB_HDRC !ARCH_OMAP2430 !ARCH_OMAP4 - select NOP_USB_XCEIV default MACH_OMAP3517EVM help Select this option if your platform is based on AM35x. As @@ -73,8 +71,7 @@ config USB_MUSB_AM35X config USB_TUSB6010 boolean TUSB 6010 support - depends on USB_MUSB_HDRC !USB_MUSB_SOC - select NOP_USB_XCEIV + depends on USB_MUSB_HDRC !USB_MUSB_SOC NOP_USB_XCEIV default y help The TUSB 6010 chip, from Texas Instruments, connects a discrete diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig index 5ce0752..728b476 100644 --- a/drivers/usb/otg/Kconfig +++
Re: [PATCH v3 2/2] drivers: cleanup Kconfig stuff
2010/11/2 Uwe Kleine-König u.kleine-koe...@pengutronix.de: On Tue, Nov 02, 2010 at 04:02:18PM +0200, Felipe Contreras wrote: On Tue, Nov 2, 2010 at 3:11 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Tue, Nov 02, 2010 at 02:14:13AM +0200, Felipe Contreras wrote: config REGULATOR_TWL4030 bool TI TWL4030/TWL5030/TWL6030/TPS695x0 PMIC depends on TWL4030_CORE + default y help This driver supports the voltage regulators provided by this family of companion chips. This default is not suitable for non-OMAP platforms, it should be conditional on OMAP or something if we're going to do this (though generally we handle this with defconfigs rather than in Kconfig). This would only be enabled when TWL4030_CORE is enabled, so non-OMAP platforms would not get affected. Well, all platforms that have TWL4030_CORE will get REGULATOR_TWL4030 by default, too. (TWL4030_CORE doesn't depend on something omapish.) Yes, I think TWL4030_CORE should depend on OMAP3, but I think some people might not like that. That's why I wanted to make that a separate patch. For me this looks OK. It would be still better if it removed CONFIG_REGULATOR_TWL4030=y from arch/arm/configs/omap2plus_defconfig. Yes, but I want to run 'make savedefconfig'; there's many changes lingering like that. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] drivers: cleanup Kconfig stuff
2010/11/2 Uwe Kleine-König u.kleine-koe...@pengutronix.de: On Tue, Nov 02, 2010 at 02:14:13AM +0200, Felipe Contreras wrote: Add missing dependencies, and remove redundant ones, and select sensible defaults. This is more user-friendly, and logical. - TWL4030_CORE people should be able to compile without ARM - REGULATOR_TWL4030 if TWL4030_CORE and REGULATOR, it's pretty clear we want this - USB_GADGET_SELECTED is already inside USB_GADGET - USB_GADGET_OMAP only works on ARCH_OMAP1, and USB_OTG_UTILS is already selected by NOP_USB_XCEIV - USB_GADGET_R8A66597 is meant for ARCH_SHMOBILE - USB_MUSB_HDRC needs either NOP_USB_XCEIV, or TWL4030_USB - USB_MUSB_AM35X, NOP_USB_XCEIV is already selected because MACH_OMAP3EVM Finally, move: config USB_MUSB_HDRC select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) select TWL4030_USB if MACH_OMAP_3430SDP To: config TWL4030_USB default y if ARCH_OMAP3 config NOP_USB_XCEIV default y if ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN Signed-off-by: Felipe Contreras felipe.contre...@gmail.com All changes look fine to me, but I think you will need to split up this patch for the different subsystem maintainers. Ok, will do. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] drivers: cleanup Kconfig stuff
On Tue, Nov 02, 2010 at 04:02:18PM +0200, Felipe Contreras wrote: On Tue, Nov 2, 2010 at 3:11 PM, Mark Brown This default is not suitable for non-OMAP platforms, it should be conditional on OMAP or something if we're going to do this (though generally we handle this with defconfigs rather than in Kconfig). This would only be enabled when TWL4030_CORE is enabled, so non-OMAP platforms would not get affected. TWL4030 can be enabled on other platforms - it's not tied to OMAP (mostly to enable build coverage). I guess you have seen the complaint from Linus regarding ARM relying too much on defconfigs. This helps in order to simplify defconfigs, and eventually getting rid of them completely. This solution doesn't seem like it scales so well either, it just shifts it into the Kconfig files (where everything is all in central files shared by everyone which has its own problems). Certainly the goal of replacing defconfig files with Kconfig seems unattainable. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] drivers: cleanup Kconfig stuff
On Tue, Nov 02, 2010 at 04:18:18PM +0200, Felipe Contreras wrote: 2010/11/2 Uwe Kleine-König u.kleine-koe...@pengutronix.de: Well, all platforms that have TWL4030_CORE will get REGULATOR_TWL4030 by default, too. (TWL4030_CORE doesn't depend on something omapish.) Yes, I think TWL4030_CORE should depend on OMAP3, but I think some people might not like that. That's why I wanted to make that a separate patch. It did originally but that dependency was removed to allow build coverage for non-OMAP users. For me this looks OK. It would be still better if it removed CONFIG_REGULATOR_TWL4030=y from arch/arm/configs/omap2plus_defconfig. Yes, but I want to run 'make savedefconfig'; there's many changes lingering like that. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] drivers: cleanup Kconfig stuff
On Tue, Nov 2, 2010 at 4:35 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Tue, Nov 02, 2010 at 04:02:18PM +0200, Felipe Contreras wrote: On Tue, Nov 2, 2010 at 3:11 PM, Mark Brown This default is not suitable for non-OMAP platforms, it should be conditional on OMAP or something if we're going to do this (though generally we handle this with defconfigs rather than in Kconfig). This would only be enabled when TWL4030_CORE is enabled, so non-OMAP platforms would not get affected. TWL4030 can be enabled on other platforms - it's not tied to OMAP (mostly to enable build coverage). Yes, but if you are manually enabling TWL4030_CORE and REGULATOR, REGULATOR_TWL4030 makes sense. If somebody doesn't want it for some reason, it can be manually disabled. I guess you have seen the complaint from Linus regarding ARM relying too much on defconfigs. This helps in order to simplify defconfigs, and eventually getting rid of them completely. This solution doesn't seem like it scales so well either, it just shifts it into the Kconfig files (where everything is all in central files shared by everyone which has its own problems). Certainly the goal of replacing defconfig files with Kconfig seems unattainable. The difference is that Kconfig files are needed, and part of linux itself. The defconfig files should be optional, there are many, and not necessarily in the linux tree (e.g. meego kernel configs). However, even if you forget about Kconfig vs defconfig, it should be possible to create a .config file from nothing, and when you do that, having REGULATOR_TWL4030 enabled when you enable REGULATOR support just makes sense (if you have enabled TWL4030_CORE). -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] drivers: cleanup Kconfig stuff
On Tue, Nov 2, 2010 at 4:39 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Tue, Nov 02, 2010 at 04:18:18PM +0200, Felipe Contreras wrote: 2010/11/2 Uwe Kleine-König u.kleine-koe...@pengutronix.de: Well, all platforms that have TWL4030_CORE will get REGULATOR_TWL4030 by default, too. (TWL4030_CORE doesn't depend on something omapish.) Yes, I think TWL4030_CORE should depend on OMAP3, but I think some people might not like that. That's why I wanted to make that a separate patch. It did originally but that dependency was removed to allow build coverage for non-OMAP users. I'm not sure removing that dependency is worth it. There's probably a lot of code in the kernel that can be built without meeting the specified dependencies. Maybe there should be a way to differentiate soft from hard dependencies for this particular use-case. But I guess for now the lack of dependency should be ok. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] drivers: cleanup Kconfig stuff
On Tue, Nov 02, 2010 at 09:43:30PM +0200, Felipe Contreras wrote: On Tue, Nov 2, 2010 at 4:35 PM, Mark Brown This solution doesn't seem like it scales so well either, it just shifts it into the Kconfig files (where everything is all in central files shared by everyone which has its own problems). Certainly the goal of replacing defconfig files with Kconfig seems unattainable. The difference is that Kconfig files are needed, and part of linux itself. The defconfig files should be optional, there are many, and not necessarily in the linux tree (e.g. meego kernel configs). Right, but it's not like you're ever going to get a useful machine configuration just using Kconfig except in the most trivial systems. However, even if you forget about Kconfig vs defconfig, it should be possible to create a .config file from nothing, and when you do that, having REGULATOR_TWL4030 enabled when you enable REGULATOR support just makes sense (if you have enabled TWL4030_CORE). Right, but everyone uses the same Kconfig files while the defconfigs only affect the individual platform which uses them. This is annoying for me since it increases the amount of stuff that gets built into my kernel (I routinely build everything I possibly can in my subsystems for coverage but don't actually want to have all that stuff show up in the kernel image I'm running on my system). The stuff ends up built in due to the issue with MFDs not being buildable as modules since they have interrupt controllers, if that were fixed it wouldn't be an issue. If you're going to make this sort of change we need to have a policy change over all MFD subdevices (and possibly some other things) and decide that we'll eat the costs. Doing it randomly for individual chips and drivers within those chips doesn't seem like a good approach. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] drivers: cleanup Kconfig stuff
On Tue, Nov 02, 2010 at 09:46:47PM +0200, Felipe Contreras wrote: On Tue, Nov 2, 2010 at 4:39 PM, Mark Brown It did originally but that dependency was removed to allow build coverage for non-OMAP users. I'm not sure removing that dependency is worth it. There's probably a lot of code in the kernel that can be built without meeting the specified dependencies. Maybe there should be a way to differentiate soft from hard dependencies for this particular use-case. But I guess for now the lack of dependency should be ok. It's really useful for subsystem maintainers - it means you can do changes over the subsystem without having to have a build lots and lots of different configs per chip to make sure everything still at least compiles. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
