From: lee.jones@linaro.org (Lee Jones)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] ARM: ux500: Turn on the 'heartbeat' LED trigger
Date: Wed, 9 Jan 2013 13:00:04 +0000 [thread overview]
Message-ID: <20130109130004.GF31678@gmail.com> (raw)
In-Reply-To: <20130109123853.GJ3931@n2100.arm.linux.org.uk>
> > Excuse my ignorance, but I'm a little confused by this.
> >
> > What's the difference between 'select <OPTION>' in the Kconfig and
> > 'CONFIG_<OPTION>=y' in the defconfig; besides the fact that if we
> > do it in the Kconfig file, we can be more selective with regards to
> > which platform it gets enabled on?
>
> Take this in Kconfig:
>
> config FOO
> bool "FOO option"
> select BAR
>
> config BAR
> bool "BAR option"
>
> Now, irrespective of the default configuration file being used:
> - if you don't enable FOO, then you can enable _and_ _disable_ BAR according
> to your needs.
> - if you enable FOO, then BAR will be _forcefully_ enabled and you can't
> turn it off without first disabling FOO.
>
> The default configuration file will specify the _default_ values for these
> options, but if FOO ends up being enabled, BAR will be forcefully enabled
> irrespective of what's in the configuration file.
>
> With this instead:
>
> config FOO
> bool "FOO option"
>
> config BAR
> bool "BAR option"
>
> Then, the two options are independent. They can be enabled and disabled
> by the configuration completely independently. However, their default
> values come from the default configuration file. So, if the config file
> has:
>
> CONFIG_FOO=y
> CONFIG_BAR=y
>
> and you do a 'make oldconfig' then they will remain set. If you use one
> of the configuration editing tools, you'll be presented with them already
> enabled, and you can turn them off independently.
>
> So, putting this stuff in the default configuration file allows
> _non-mandatory_ options to be disabled should the user desire without the
> user having to edit the configuration files.
>
> If a user has to edit the configuration files in order to configure the
> kernel as they desire, then the configuration system has failed - or we
> have failed to properly think out how to represent the allowable
> configurations.
Understood. Thanks for the explanation.
Linus, is it okay to put these in the defconfig instead?
If so, I'll fixup.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee.jones@linaro.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>,
sameo@linux.intel.com, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linus.walleij@stericsson.com
Subject: Re: [PATCH 2/3] ARM: ux500: Turn on the 'heartbeat' LED trigger
Date: Wed, 9 Jan 2013 13:00:04 +0000 [thread overview]
Message-ID: <20130109130004.GF31678@gmail.com> (raw)
In-Reply-To: <20130109123853.GJ3931@n2100.arm.linux.org.uk>
> > Excuse my ignorance, but I'm a little confused by this.
> >
> > What's the difference between 'select <OPTION>' in the Kconfig and
> > 'CONFIG_<OPTION>=y' in the defconfig; besides the fact that if we
> > do it in the Kconfig file, we can be more selective with regards to
> > which platform it gets enabled on?
>
> Take this in Kconfig:
>
> config FOO
> bool "FOO option"
> select BAR
>
> config BAR
> bool "BAR option"
>
> Now, irrespective of the default configuration file being used:
> - if you don't enable FOO, then you can enable _and_ _disable_ BAR according
> to your needs.
> - if you enable FOO, then BAR will be _forcefully_ enabled and you can't
> turn it off without first disabling FOO.
>
> The default configuration file will specify the _default_ values for these
> options, but if FOO ends up being enabled, BAR will be forcefully enabled
> irrespective of what's in the configuration file.
>
> With this instead:
>
> config FOO
> bool "FOO option"
>
> config BAR
> bool "BAR option"
>
> Then, the two options are independent. They can be enabled and disabled
> by the configuration completely independently. However, their default
> values come from the default configuration file. So, if the config file
> has:
>
> CONFIG_FOO=y
> CONFIG_BAR=y
>
> and you do a 'make oldconfig' then they will remain set. If you use one
> of the configuration editing tools, you'll be presented with them already
> enabled, and you can turn them off independently.
>
> So, putting this stuff in the default configuration file allows
> _non-mandatory_ options to be disabled should the user desire without the
> user having to edit the configuration files.
>
> If a user has to edit the configuration files in order to configure the
> kernel as they desire, then the configuration system has failed - or we
> have failed to properly think out how to represent the allowable
> configurations.
Understood. Thanks for the explanation.
Linus, is it okay to put these in the defconfig instead?
If so, I'll fixup.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2013-01-09 13:00 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-09 10:06 [PATCH 1/3] mfd: Fix compile errors and warnings when !CONFIG_AB8500_BM Lee Jones
2013-01-09 10:06 ` Lee Jones
2013-01-09 10:06 ` [PATCH 2/3] ARM: ux500: Turn on the 'heartbeat' LED trigger Lee Jones
2013-01-09 10:06 ` Lee Jones
2013-01-09 10:18 ` Arnd Bergmann
2013-01-09 10:18 ` Arnd Bergmann
2013-01-09 10:35 ` Russell King - ARM Linux
2013-01-09 10:35 ` Russell King - ARM Linux
2013-01-09 11:08 ` Lee Jones
2013-01-09 11:08 ` Lee Jones
2013-01-09 11:12 ` Russell King - ARM Linux
2013-01-09 11:12 ` Russell King - ARM Linux
2013-01-09 11:56 ` Arnd Bergmann
2013-01-09 11:56 ` Arnd Bergmann
2013-01-09 11:59 ` Russell King - ARM Linux
2013-01-09 11:59 ` Russell King - ARM Linux
2013-01-09 12:02 ` Arnd Bergmann
2013-01-09 12:02 ` Arnd Bergmann
2013-01-09 12:23 ` Lee Jones
2013-01-09 12:23 ` Lee Jones
2013-01-09 12:38 ` Russell King - ARM Linux
2013-01-09 12:38 ` Russell King - ARM Linux
2013-01-09 13:00 ` Lee Jones [this message]
2013-01-09 13:00 ` Lee Jones
2013-01-17 10:22 ` Linus Walleij
2013-01-17 10:22 ` Linus Walleij
2013-01-09 10:06 ` [PATCH 3/3] ARM: ux500: Add Snowball pin configuration for user LED Lee Jones
2013-01-09 10:06 ` Lee Jones
2013-01-23 9:36 ` Linus Walleij
2013-01-23 9:36 ` Linus Walleij
2013-02-26 10:32 ` Lee Jones
2013-02-26 10:32 ` Lee Jones
2013-01-22 3:26 ` [PATCH 1/3] mfd: Fix compile errors and warnings when !CONFIG_AB8500_BM Samuel Ortiz
2013-01-22 3:26 ` Samuel Ortiz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130109130004.GF31678@gmail.com \
--to=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.