[U-Boot] [PATCH 1/2] common: mark commands as default to match "config_cmd_default.h"

[Simon Glass]

HI Masahiro,

On 13 January 2015 at 20:05, Masahiro Yamada <yamada.m at jp.panasonic.com> wrote:
> Hi Alexey,
>
>
> On Fri, 9 Jan 2015 20:09:22 +0000
> Alexey Brodkin <Alexey.Brodkin at synopsys.com> wrote:
>
>> Hi Masahiro-san,
>>
>> On Tue, 2015-01-06 at 00:34 +0900, Masahiro YAMADA wrote:
>> > Hi Alexey,
>> >
>> > 2015-01-03 22:20 GMT+09:00 Alexey Brodkin <Alexey.Brodkin at synopsys.com>:
>> > > Now when we may select commands via menuconfig let's adjust default
>> > > settings with "config_cmd_default.h".
>> > >
>> > > As the next step we may get rid of "config_cmd_default.h" inclusion in
>> > > "include/configs/*.h" and "config_cmd_default.h" itself.
>> >
>> > Thanks for working on this, but I think this patch changes the behavior.
>> >
>> > Some boards include <config_cmd_default.h> and then undefine
>> > unnecessary commands.
>>
>> > For example, include/configs/snapper9260.h
>> >
>> > #include <config_cmd_default.h>
>> > #undef CONFIG_CMD_BDI
>> > #undef CONFIG_CMD_FPGA
>> > #undef CONFIG_CMD_IMI
>> > #undef CONFIG_CMD_IMLS
>> > #undef CONFIG_CMD_LOADS
>> > #undef CONFIG_CMD_SOURCE
>> >
>> > If you set the default value to "y" in Kconfig,
>> > it cannot be undef'ed by C-headers.
>>
>> That's true.
>> But anyway at some point we'll need to switch selection of commands in
>> Kconfig, right?
>
> Yes.
>
>
>> Probably I'm missing details of our Kconfig migration plan if one
>> exists. Then I'd like to get a reference to the plan so I'm not
>> attempting to do things that are already scheduled and could be even in
>> a process of implementation.
>> Otherwise if there's no current plan for Kconfig migration we may start
>> discussion on how to deal with "commands" in particular.
>
>
> I proposed the following way, but no big conversion movement has happened yet.
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/199965/focus=200089
>
> If you have an idea, please propose it.
>
> Kconfig conversion is a too big task to be done by a single indivisual.
> Any suggestion, any form of contribution is very appreciated.
>
>
>
> I personally keep away from any global changes until
> non-generic boards are dumped.
>
> As Tom said in the following mail,
> http://lists.denx.de/pipermail/u-boot/2015-January/201032.html
> we are going to remove lots of boards.
>
> I do not want to make extra efforts on non-generic boards.
>
>
>
>
>> The point is commands are low-hanging fruits in terms of Kconfig
>> migration - there're no extra options and tweaks, once all commands are
>> added in Kconfig (essentially with dependencies etc) we may clean all
>> board headers. The only real problem here is amount of work - lots of
>> headers/defconfigs to patch. But still this is doable.
>
>
> I realized one problem when I was doing this task
> for my boards in commit 25e274e20208.
>
> The defconfigs of my boards are almost the same:
> (configs/ph1_ld4_defconfig, configs/ph1_pro4_defconfig, configs/ph1_sld8_defconfig)
>
> What is inconvenient as for defconfig is that
> it does not support "include" directive like C headers.
>
> People generally like to add CONFIG_CMD_* to a common header file
> such as include/configs/tegra-common.h
>
> On the other hand, on defconfig, we must touch each defconfig of the board family.
>
> I have not been able to decide right direction to solve this issue.
>
> I think we need to discuss about how to live with lots of defconfigs.

How about this:

1. Support an 'include' option in defconfig to include another file.
This could take the form of CONFIG_DEFCONFIG_INCLUDES (comma-separated
list of filenames). Don't allow nested includes - this CONFIG provides
a complete list of includes.
2. When you use menuconfig to edit the config, it ignores the include
and just writes out everything. Then it runs a simple script which
parses the include files, and adjusts the file so that things in the
includes are not repeated in the defconfig.

I think this scheme would be good enough, but can probably be
improved. At least it would be better than what we have.

Or we could instead define particular includes for different purposes:

- Arch
- SOC
- SOC Vendor
- Board vendor
- Board family

We could then require that standard filenames are used, and search for
the correct file based on the SOC/board/vendor setting, etc.

As an example, for trimslice, we could search for arm.h, tegra.h,
nvidia.h, compulab.h, some_family_name.h.

This is less flexible though.

>
>
>
>> > >  config CMD_BDI
>> > >         bool "bdinfo"
>> > > +       default y
>> > >         help
>> > >           Print board info
>> >
>> >
>> > This change enables CMD_BDI for all the boards.
>> >
>> > Please notice the following boards do not want to compile this command.
>> >
>> > ./include/configs/dbau1x00.h:#undef CONFIG_CMD_BDI
>>
>> > > @@ -193,6 +204,7 @@ config CMD_USB
>> > >
>> > >  config CMD_FPGA
>> > >         bool "fpga"
>> > > +       default y
>> > >         help
>> > >           FPGA support.
>> >
>> > Moreover, I doubt some of default commands in <config_cmd_default.h>
>> > (I have used only some of commands in <config_cmd_default.h>)
>> >
>> > For example, it seems weird to enable CONFIG_CMD_FPGA by default.
>> >
>> > I do not think most of boards have FPGA.
>>
>> That's a separate topic. I do agree that CMD_FPGA makes not much sense
>> for most of boards, as well as some others.
>>
>> And I think during migration process of commands to Kconfig it's a good
>> time to reconsider default commands.
>
> Agree.
> We should reconsider the default.
> In my opition, most of the ones in config_cmd_default.h are not default commands.
>
>
>
>> I will highly appreciate input on both topics from others so we'll do
>> some progress here and will make sure all parties are happy.
>>
>> -Alexey

Regards,
Simon