This gets rid of some warnings, makes defconfigs smarter by having more proper
dependencies, and general cleanups.
v3: comments by Roger Quadros, rebased to v2.6.37-rc1
Felipe Contreras (2):
usb: trivial Kconfig cleanups
drivers: cleanup Kconfig stuff
drivers/mfd/Kconfig | 2 +-
drivers/regulator/Kconfig | 1 +
drivers/usb/core/Kconfig | 3 ---
drivers/usb/gadget/Kconfig | 7 +++----
drivers/usb/musb/Kconfig | 24 ++++++------------------
drivers/usb/otg/Kconfig | 2 ++
6 files changed, 13 insertions(+), 26 deletions(-)
--
1.7.3.2.2.g0dc5c
Note: USB_GADGET_MUSB_HDRC is already defined in usb/gadget.
Signed-off-by: Felipe Contreras <[email protected]>
---
drivers/usb/core/Kconfig | 3 ---
drivers/usb/gadget/Kconfig | 2 +-
drivers/usb/musb/Kconfig | 17 ++++-------------
3 files changed, 5 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
index 9eed5b5..8f57a26 100644
--- a/drivers/usb/core/Kconfig
+++ b/drivers/usb/core/Kconfig
@@ -110,8 +110,6 @@ config USB_OTG
bool
depends on USB && EXPERIMENTAL
depends on USB_SUSPEND
- default n
-
config USB_OTG_WHITELIST
bool "Rely on OTG Targeted Peripherals List"
@@ -139,4 +137,3 @@ config USB_OTG_BLACKLIST_HUB
external hubs. OTG hosts are allowed to reduce hardware
and software costs by not supporting external hubs. So
are "Embedded Hosts" that don't offer OTG support.
-
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index b739ca8..75733cd 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -125,7 +125,6 @@ choice
config USB_GADGET_AT91
boolean "Atmel AT91 USB Device Port"
depends on ARCH_AT91 && !ARCH_AT91SAM9RL && !ARCH_AT91CAP9 && !ARCH_AT91SAM9G45
- select USB_GADGET_SELECTED
help
Many Atmel AT91 processors (such as the AT91RM2000) have a
full speed USB Device Port with support for five configurable
@@ -139,6 +138,7 @@ config USB_AT91
tristate
depends on USB_GADGET_AT91
default USB_GADGET
+ select USB_GADGET_SELECTED
config USB_GADGET_ATMEL_USBA
boolean "Atmel USBA"
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 341a37a..f0e0495 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -8,12 +8,12 @@ comment "Enable Host or Gadget support to see Inventra options"
# (M)HDRC = (Multipoint) Highspeed Dual-Role Controller
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
select USB_OTG_UTILS
- tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)'
help
Say Y here if your system has a dual role high speed USB
controller based on the Mentor Graphics silicon IP. Then
@@ -93,8 +93,8 @@ choice
# use USB_MUSB_HDRC_HCD not USB_MUSB_HOST to #ifdef host side support;
# OTG needs both roles, not just USB_MUSB_HOST.
config USB_MUSB_HOST
- depends on USB
bool "USB Host"
+ depends on USB
help
Say Y here if your system supports the USB host role.
If it has a USB "A" (rectangular), "Mini-A" (uncommon),
@@ -104,8 +104,8 @@ config USB_MUSB_HOST
# use USB_GADGET_MUSB_HDRC not USB_MUSB_PERIPHERAL to #ifdef peripheral
# side support ... OTG needs both roles
config USB_MUSB_PERIPHERAL
- depends on USB_GADGET
bool "USB Peripheral (gadget stack)"
+ depends on USB_GADGET
select USB_GADGET_MUSB_HDRC
help
Say Y here if your system supports the USB peripheral role.
@@ -114,8 +114,8 @@ config USB_MUSB_PERIPHERAL
(With a "Mini-AB" connector, you should enable USB OTG.)
config USB_MUSB_OTG
- depends on USB && USB_GADGET && PM && EXPERIMENTAL
bool "Both host and peripheral: USB OTG (On The Go) Device"
+ depends on USB && USB_GADGET && PM && EXPERIMENTAL
select USB_GADGET_MUSB_HDRC
select USB_OTG
help
@@ -139,14 +139,6 @@ config USB_MUSB_OTG
endchoice
-# enable peripheral support (including with OTG)
-config USB_GADGET_MUSB_HDRC
- bool
- depends on USB_MUSB_HDRC && (USB_MUSB_PERIPHERAL || USB_MUSB_OTG)
-# default y
-# select USB_GADGET_DUALSPEED
-# select USB_GADGET_SELECTED
-
# enables host support (including with OTG)
config USB_MUSB_HDRC_HCD
bool
@@ -154,7 +146,6 @@ config USB_MUSB_HDRC_HCD
select USB_OTG if USB_GADGET_MUSB_HDRC
default y
-
config MUSB_PIO_ONLY
bool 'Disable DMA (always use PIO)'
depends on USB_MUSB_HDRC
--
1.7.3.2.2.g0dc5c
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 <[email protected]>
---
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 @@ config USB_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
+++ b/drivers/usb/otg/Kconfig
@@ -53,6 +53,7 @@ config TWL4030_USB
tristate "TWL4030 USB Transceiver Driver"
depends on TWL4030_CORE && REGULATOR_TWL4030
select USB_OTG_UTILS
+ default y if ARCH_OMAP3
help
Enable this to support the USB OTG transceiver on TWL4030
family chips (including the TWL5030 and TPS659x0 devices).
@@ -62,6 +63,7 @@ config TWL4030_USB
config NOP_USB_XCEIV
tristate "NOP USB Transceiver Driver"
select USB_OTG_UTILS
+ default y if ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN
help
this driver is to be used by all the usb transceiver which are either
built-in with usb ip or which are autonomous and doesn't require any
--
1.7.3.2.2.g0dc5c
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).
On Tue, Nov 2, 2010 at 3:11 PM, Mark Brown
<[email protected]> 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
On Tue, Nov 02, 2010 at 04:02:18PM +0200, Felipe Contreras wrote:
> On Tue, Nov 2, 2010 at 3:11 PM, Mark Brown
> <[email protected]> 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/ |
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 <[email protected]>
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 @@ config USB_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
> +++ b/drivers/usb/otg/Kconfig
> @@ -53,6 +53,7 @@ config TWL4030_USB
> tristate "TWL4030 USB Transceiver Driver"
> depends on TWL4030_CORE && REGULATOR_TWL4030
> select USB_OTG_UTILS
> + default y if ARCH_OMAP3
> help
> Enable this to support the USB OTG transceiver on TWL4030
> family chips (including the TWL5030 and TPS659x0 devices).
> @@ -62,6 +63,7 @@ config TWL4030_USB
> config NOP_USB_XCEIV
> tristate "NOP USB Transceiver Driver"
> select USB_OTG_UTILS
> + default y if ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN
> help
> this driver is to be used by all the usb transceiver which are either
> built-in with usb ip or which are autonomous and doesn't require any
> --
> 1.7.3.2.2.g0dc5c
>
>
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
2010/11/2 Uwe Kleine-König <[email protected]>:
> On Tue, Nov 02, 2010 at 04:02:18PM +0200, Felipe Contreras wrote:
>> On Tue, Nov 2, 2010 at 3:11 PM, Mark Brown
>> <[email protected]> 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
2010/11/2 Uwe Kleine-König <[email protected]>:
> 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 <[email protected]>
> 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
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.
On Tue, Nov 02, 2010 at 04:18:18PM +0200, Felipe Contreras wrote:
> 2010/11/2 Uwe Kleine-K?nig <[email protected]>:
> > 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
On Tue, Nov 2, 2010 at 4:35 PM, Mark Brown
<[email protected]> 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
On Tue, Nov 2, 2010 at 4:39 PM, Mark Brown
<[email protected]> wrote:
> On Tue, Nov 02, 2010 at 04:18:18PM +0200, Felipe Contreras wrote:
>> 2010/11/2 Uwe Kleine-König <[email protected]>:
>
>> > 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
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.
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.