ARM: tegra: rebuild tegra_defconfig

From: Stephen Warren <swarren@nvidia.com>

This simply rebuilds tegra_defconfig on top of next-20130520. As such, it
should introduce no changes; simply moving entries around due to Kconfig
ordering changes. The apparent exceptions are:

AUTO_ZRELADDR: Selected by ARM multi-platform support.
MTD_CHAR: Removed in Kconfig.

This should make it easier to create future defconfig patches on top of
linux-next, since all the extraneous diffs have been removed. It also
makes it more likely that once 3.12 comes around, this defconfig will
already match what's required there.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 arch/arm/configs/tegra_defconfig |   14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

On 05/28/2013 11:26 AM, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
> 
> This simply rebuilds tegra_defconfig on top of next-20130520. As such, it
> should introduce no changes; simply moving entries around due to Kconfig
> ordering changes. The apparent exceptions are:
> 
> AUTO_ZRELADDR: Selected by ARM multi-platform support.
> MTD_CHAR: Removed in Kconfig.
> 
> This should make it easier to create future defconfig patches on top of
> linux-next, since all the extraneous diffs have been removed. It also
> makes it more likely that once 3.12 comes around, this defconfig will
> already match what's required there.

I've applied this (squashed it into) Tegra's for-3.11/defconfig branch.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Am Dienstag, 28. Mai 2013, 15:30:29 schrieb Stephen Warren:
> On 05/28/2013 11:26 AM, Stephen Warren wrote:
> > From: Stephen Warren <swarren@nvidia.com>
> > 
> > This simply rebuilds tegra_defconfig on top of next-20130520. As such, it
> > should introduce no changes; simply moving entries around due to Kconfig
> > ordering changes. The apparent exceptions are:
> > 
> > AUTO_ZRELADDR: Selected by ARM multi-platform support.
> > MTD_CHAR: Removed in Kconfig.
> > 
> > This should make it easier to create future defconfig patches on top of
> > linux-next, since all the extraneous diffs have been removed. It also
> > makes it more likely that once 3.12 comes around, this defconfig will
> > already match what's required there.
> 
> I've applied this (squashed it into) Tegra's for-3.11/defconfig branch.

wouldn't it make more sense to apply such a patch just before the merge window 
closes (or better after some release candidate)? This way we would have a 
better chance to have a zero diff between defconfig and tegra_defconfig, e.g. 
not like 3.10 is now.

Marc
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 05/29/2013 07:38 AM, Marc Dietrich wrote:
> Am Dienstag, 28. Mai 2013, 15:30:29 schrieb Stephen Warren:
>> On 05/28/2013 11:26 AM, Stephen Warren wrote:
>>> From: Stephen Warren <swarren@nvidia.com>
>>>
>>> This simply rebuilds tegra_defconfig on top of next-20130520. As such, it
>>> should introduce no changes; simply moving entries around due to Kconfig
>>> ordering changes. The apparent exceptions are:
>>>
>>> AUTO_ZRELADDR: Selected by ARM multi-platform support.
>>> MTD_CHAR: Removed in Kconfig.
>>>
>>> This should make it easier to create future defconfig patches on top of
>>> linux-next, since all the extraneous diffs have been removed. It also
>>> makes it more likely that once 3.12 comes around, this defconfig will
>>> already match what's required there.
>>
>> I've applied this (squashed it into) Tegra's for-3.11/defconfig branch.
> 
> wouldn't it make more sense to apply such a patch just before the merge window 
> closes (or better after some release candidate)?

Perhaps. It probably also depends a lot on when Kconfig changes get
applied in other areas as far as when it makes sense. I deferred it this
time around in order to pick up some tegra_defconfig changes that made
it into 3.10-rc3.

> This way we would have a 
> better chance to have a zero diff between defconfig and tegra_defconfig, e.g. 
> not like 3.10 is now.

I don't understand this; what is "defconfig" if not "tegra_defconfig"?
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wednesday 29 May 2013 09:29:48 Stephen Warren wrote:
> On 05/29/2013 07:38 AM, Marc Dietrich wrote:
> > Am Dienstag, 28. Mai 2013, 15:30:29 schrieb Stephen Warren:
> >> On 05/28/2013 11:26 AM, Stephen Warren wrote:
> >>> From: Stephen Warren <swarren@nvidia.com>
> >>> 
> >>> This simply rebuilds tegra_defconfig on top of next-20130520. As such,
> >>> it
> >>> should introduce no changes; simply moving entries around due to Kconfig
> >>> ordering changes. The apparent exceptions are:
> >>> 
> >>> AUTO_ZRELADDR: Selected by ARM multi-platform support.
> >>> MTD_CHAR: Removed in Kconfig.
> >>> 
> >>> This should make it easier to create future defconfig patches on top of
> >>> linux-next, since all the extraneous diffs have been removed. It also
> >>> makes it more likely that once 3.12 comes around, this defconfig will
> >>> already match what's required there.
> >> 
> >> I've applied this (squashed it into) Tegra's for-3.11/defconfig branch.
> > 
> > wouldn't it make more sense to apply such a patch just before the merge
> > window closes (or better after some release candidate)?
> 
> Perhaps. It probably also depends a lot on when Kconfig changes get
> applied in other areas as far as when it makes sense. I deferred it this
> time around in order to pick up some tegra_defconfig changes that made
> it into 3.10-rc3.

ok, nice.

> > This way we would have a
> > better chance to have a zero diff between defconfig and tegra_defconfig,
> > e.g. not like 3.10 is now.
> 
> I don't understand this; what is "defconfig" if not "tegra_defconfig"?

defconfig: make tegra_defconfig; make saveconfig

diff -u tegra_defconfig defconfig

Marc
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 05/29/2013 11:30 AM, Marc Dietrich wrote:
> On Wednesday 29 May 2013 09:29:48 Stephen Warren wrote:
>> On 05/29/2013 07:38 AM, Marc Dietrich wrote:
>>> Am Dienstag, 28. Mai 2013, 15:30:29 schrieb Stephen Warren:
>>>> On 05/28/2013 11:26 AM, Stephen Warren wrote:
>>>>> From: Stephen Warren <swarren@nvidia.com>
>>>>>
>>>>> This simply rebuilds tegra_defconfig on top of next-20130520. As such,
>>>>> it
>>>>> should introduce no changes; simply moving entries around due to Kconfig
>>>>> ordering changes. The apparent exceptions are:
...
>>> This way we would have a
>>> better chance to have a zero diff between defconfig and tegra_defconfig,
>>> e.g. not like 3.10 is now.
>>
>> I don't understand this; what is "defconfig" if not "tegra_defconfig"?
> 
> defconfig: make tegra_defconfig; make saveconfig
> 
> diff -u tegra_defconfig defconfig

Oh right. Yes, if you do that in the for-3.11/defconfig branch itself,
there will be diffs.

That will always be true; that branch won't have any of the new
drivers/features that will be added in linux-next and the next mainline
kernel, so at the very least you'd end up removing some options doing that.

I expect most people editing defconfig will be doing it based on some
linux-next version rather than right on top of for-3.11/defconfig, so
they can pick up, enable, and test new drivers or features. If you run
the commands above in next-20130529, there should be a zero diff (unless
someone made some Kconfig changes between
next-20130528 and next-20130529 anyway).
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html