Re: [PATCH v3 2/2] drivers: cleanup Kconfig stuff

[Felipe Contreras <felipe.contreras@gmail.com>]

On Tue, Nov 2, 2010 at 4:35 PM, Mark Brown
<broonie@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