[U-Boot] [RFC] Rearrange CONFIG_* macros

[U-Boot] [RFC] Rearrange CONFIG_* macros

[york sun]

Guys,

I want to discuss to rearrange the current CONFIG_* macros used by 
Freescale Layerscape SoCs. We have been encouraged to use CONFIG_SYS_* 
macros to define hardware setting, and other CONFIG_* macros for user 
setting. Clearly this has changed. Kconfig options are used for most 
user settings from now on. I am OK with it. But for existing 
CONFIG_SYS_* macros, we need a plan to either move them out of CONFIG_* 
name space, or move some to Kconfig, if that makes sense. Since most our 
CONFIG_SYS_* macros are cross platforms (including armv7 and armv8), if 
using Kconfig option, do we add another mach-fsl folder to host the 
Kconfig, or somewhere else? We also have macros cross ARM and PowerPC. 
So we either move them out of arch/, or duplicate them for both arch.

If we move them to another name space, for example SYS_FSL_*, do we want 
to move them out of config.h?

Any suggestion/comment?

York

[U-Boot] [RFC] Rearrange CONFIG_* macros

[Tom Rini]

On Tue, Sep 27, 2016 at 05:39:55PM +0000, york sun wrote:
> Guys,
> 
> I want to discuss to rearrange the current CONFIG_* macros used by 
> Freescale Layerscape SoCs. We have been encouraged to use CONFIG_SYS_* 
> macros to define hardware setting, and other CONFIG_* macros for user 
> setting. Clearly this has changed. Kconfig options are used for most 
> user settings from now on. I am OK with it. But for existing 
> CONFIG_SYS_* macros, we need a plan to either move them out of CONFIG_* 
> name space, or move some to Kconfig, if that makes sense. Since most our 
> CONFIG_SYS_* macros are cross platforms (including armv7 and armv8), if 
> using Kconfig option, do we add another mach-fsl folder to host the 
> Kconfig, or somewhere else? We also have macros cross ARM and PowerPC. 
> So we either move them out of arch/, or duplicate them for both arch.
> 
> If we move them to another name space, for example SYS_FSL_*, do we want 
> to move them out of config.h?
> 
> Any suggestion/comment?

Well, if something is cross-platform the code is somewhere
cross-platform too, yes?  For example, if anything DDR related makes
sense to stay as CONFIG_SYS_FSL_... it could go in to
drivers/ddr/fsl/Kconfig and be visible in both cases.  Otherwise
<asm/arch/fsl_ddr.h> and SYS_FSL_... (or whatever makes sense, looking
at the am33xx and mx6 cases, there's no SYS_ type prefix on the defines,
just the IP block names) for the defines.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160927/03e578f9/attachment.sig>

[U-Boot] [RFC] Rearrange CONFIG_* macros

[Simon Glass]

Hi York,

On 27 September 2016 at 11:39, york sun <york.sun@nxp.com> wrote:
> Guys,
>
> I want to discuss to rearrange the current CONFIG_* macros used by
> Freescale Layerscape SoCs. We have been encouraged to use CONFIG_SYS_*
> macros to define hardware setting, and other CONFIG_* macros for user
> setting. Clearly this has changed. Kconfig options are used for most
> user settings from now on. I am OK with it. But for existing
> CONFIG_SYS_* macros, we need a plan to either move them out of CONFIG_*
> name space, or move some to Kconfig, if that makes sense. Since most our
> CONFIG_SYS_* macros are cross platforms (including armv7 and armv8), if
> using Kconfig option, do we add another mach-fsl folder to host the
> Kconfig, or somewhere else? We also have macros cross ARM and PowerPC.
> So we either move them out of arch/, or duplicate them for both arch.
>
> If we move them to another name space, for example SYS_FSL_*, do we want
> to move them out of config.h?
>
> Any suggestion/comment?

I wonder if some of these (the ones that represent actual values
rather than enabling functions) can move to device tree, or tables?

Regards,
Simon

[U-Boot] [RFC] Rearrange CONFIG_* macros

[york sun]

On 09/27/2016 10:51 AM, Tom Rini wrote:
> On Tue, Sep 27, 2016 at 05:39:55PM +0000, york sun wrote:
>> Guys,
>>
>> I want to discuss to rearrange the current CONFIG_* macros used by
>> Freescale Layerscape SoCs. We have been encouraged to use CONFIG_SYS_*
>> macros to define hardware setting, and other CONFIG_* macros for user
>> setting. Clearly this has changed. Kconfig options are used for most
>> user settings from now on. I am OK with it. But for existing
>> CONFIG_SYS_* macros, we need a plan to either move them out of CONFIG_*
>> name space, or move some to Kconfig, if that makes sense. Since most our
>> CONFIG_SYS_* macros are cross platforms (including armv7 and armv8), if
>> using Kconfig option, do we add another mach-fsl folder to host the
>> Kconfig, or somewhere else? We also have macros cross ARM and PowerPC.
>> So we either move them out of arch/, or duplicate them for both arch.
>>
>> If we move them to another name space, for example SYS_FSL_*, do we want
>> to move them out of config.h?
>>
>> Any suggestion/comment?
>
> Well, if something is cross-platform the code is somewhere
> cross-platform too, yes?  For example, if anything DDR related makes
> sense to stay as CONFIG_SYS_FSL_... it could go in to
> drivers/ddr/fsl/Kconfig and be visible in both cases.  Otherwise
> <asm/arch/fsl_ddr.h> and SYS_FSL_... (or whatever makes sense, looking
> at the am33xx and mx6 cases, there's no SYS_ type prefix on the defines,
> just the IP block names) for the defines.
>

The benefit of keeping things together is easier to add a different SoC. 
For example, when we have LS2080A and need to add LS1046A, we pay 
attention to the difference. If the settings are scattered into IP 
drivers, it is not that obvious to track.

Looking at am33xx, it doesn't use many Kconfig options, but a lot in 
hardware*.h files. I need to see if we can do the same way.

York

[U-Boot] [RFC] Rearrange CONFIG_* macros

[york sun]

On 09/27/2016 10:55 AM, Simon Glass wrote:
> Hi York,
>
> On 27 September 2016 at 11:39, york sun <york.sun@nxp.com> wrote:
>> Guys,
>>
>> I want to discuss to rearrange the current CONFIG_* macros used by
>> Freescale Layerscape SoCs. We have been encouraged to use CONFIG_SYS_*
>> macros to define hardware setting, and other CONFIG_* macros for user
>> setting. Clearly this has changed. Kconfig options are used for most
>> user settings from now on. I am OK with it. But for existing
>> CONFIG_SYS_* macros, we need a plan to either move them out of CONFIG_*
>> name space, or move some to Kconfig, if that makes sense. Since most our
>> CONFIG_SYS_* macros are cross platforms (including armv7 and armv8), if
>> using Kconfig option, do we add another mach-fsl folder to host the
>> Kconfig, or somewhere else? We also have macros cross ARM and PowerPC.
>> So we either move them out of arch/, or duplicate them for both arch.
>>
>> If we move them to another name space, for example SYS_FSL_*, do we want
>> to move them out of config.h?
>>
>> Any suggestion/comment?
>
> I wonder if some of these (the ones that represent actual values
> rather than enabling functions) can move to device tree, or tables?

Interesting idea. Putting those values into device tree of table will 
change a lot of data structure, as some macros are used to define 
arrays, or to initialize variables.

York

[U-Boot] [RFC] Rearrange CONFIG_* macros

[Tom Rini]

On Tue, Sep 27, 2016 at 06:24:09PM +0000, york sun wrote:
> On 09/27/2016 10:51 AM, Tom Rini wrote:
> > On Tue, Sep 27, 2016 at 05:39:55PM +0000, york sun wrote:
> >> Guys,
> >>
> >> I want to discuss to rearrange the current CONFIG_* macros used by
> >> Freescale Layerscape SoCs. We have been encouraged to use CONFIG_SYS_*
> >> macros to define hardware setting, and other CONFIG_* macros for user
> >> setting. Clearly this has changed. Kconfig options are used for most
> >> user settings from now on. I am OK with it. But for existing
> >> CONFIG_SYS_* macros, we need a plan to either move them out of CONFIG_*
> >> name space, or move some to Kconfig, if that makes sense. Since most our
> >> CONFIG_SYS_* macros are cross platforms (including armv7 and armv8), if
> >> using Kconfig option, do we add another mach-fsl folder to host the
> >> Kconfig, or somewhere else? We also have macros cross ARM and PowerPC.
> >> So we either move them out of arch/, or duplicate them for both arch.
> >>
> >> If we move them to another name space, for example SYS_FSL_*, do we want
> >> to move them out of config.h?
> >>
> >> Any suggestion/comment?
> >
> > Well, if something is cross-platform the code is somewhere
> > cross-platform too, yes?  For example, if anything DDR related makes
> > sense to stay as CONFIG_SYS_FSL_... it could go in to
> > drivers/ddr/fsl/Kconfig and be visible in both cases.  Otherwise
> > <asm/arch/fsl_ddr.h> and SYS_FSL_... (or whatever makes sense, looking
> > at the am33xx and mx6 cases, there's no SYS_ type prefix on the defines,
> > just the IP block names) for the defines.
> >
> 
> The benefit of keeping things together is easier to add a different SoC. 
> For example, when we have LS2080A and need to add LS1046A, we pay 
> attention to the difference. If the settings are scattered into IP 
> drivers, it is not that obvious to track.
> 
> Looking at am33xx, it doesn't use many Kconfig options, but a lot in 
> hardware*.h files. I need to see if we can do the same way.

It's an imperfect implementation, but yes, between
arch/arm/cpu/armv7/omap-common/, am33xx/ and omap*/ we have a large
number of IP blocks that have been evolving over time in a similar way
to the FSL blocks I suspect.  I also suspect there should be a bit more
in Kconfig than is there.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160927/9d2a86a9/attachment.sig>

[U-Boot] [RFC] Rearrange CONFIG_* macros

[york sun]

On 09/27/2016 10:55 AM, Simon Glass wrote:
> Hi York,
>
> On 27 September 2016 at 11:39, york sun <york.sun@nxp.com> wrote:
>> Guys,
>>
>> I want to discuss to rearrange the current CONFIG_* macros used by
>> Freescale Layerscape SoCs. We have been encouraged to use CONFIG_SYS_*
>> macros to define hardware setting, and other CONFIG_* macros for user
>> setting. Clearly this has changed. Kconfig options are used for most
>> user settings from now on. I am OK with it. But for existing
>> CONFIG_SYS_* macros, we need a plan to either move them out of CONFIG_*
>> name space, or move some to Kconfig, if that makes sense. Since most our
>> CONFIG_SYS_* macros are cross platforms (including armv7 and armv8), if
>> using Kconfig option, do we add another mach-fsl folder to host the
>> Kconfig, or somewhere else? We also have macros cross ARM and PowerPC.
>> So we either move them out of arch/, or duplicate them for both arch.
>>
>> If we move them to another name space, for example SYS_FSL_*, do we want
>> to move them out of config.h?
>>
>> Any suggestion/comment?
>
> I wonder if some of these (the ones that represent actual values
> rather than enabling functions) can move to device tree, or tables?
>

While I try to move some options to Kconfig, I have an issue of 
duplicated names. For example, the MAX_CPUS is used in arch/x86/Kconfig. 
I know I can put another config with the same name, for example 
arch/arm/cpu/armv8/fsl-layerscape/Kconfig. The funny thing is when I 
search for this config option under menuconfig, it shows the location of 
x86, but showing defined in arch/arm/cpu/armv8/fsl-layerscape/Kconfig. 
Same thing happens when I try to move an option which is used by both 
PowerPC and ARM. This is not related to a common driver so I cannot put 
the option into a driver Kconfig (for example CONFIG_SYS_HAS_SERDES).

Is there a solution for this?

York

[U-Boot] [RFC] Rearrange CONFIG_* macros

[Simon Glass]

+Masahiro, who may know

On 28 September 2016 at 12:57, york sun <york.sun@nxp.com> wrote:
> On 09/27/2016 10:55 AM, Simon Glass wrote:
>> Hi York,
>>
>> On 27 September 2016 at 11:39, york sun <york.sun@nxp.com> wrote:
>>> Guys,
>>>
>>> I want to discuss to rearrange the current CONFIG_* macros used by
>>> Freescale Layerscape SoCs. We have been encouraged to use CONFIG_SYS_*
>>> macros to define hardware setting, and other CONFIG_* macros for user
>>> setting. Clearly this has changed. Kconfig options are used for most
>>> user settings from now on. I am OK with it. But for existing
>>> CONFIG_SYS_* macros, we need a plan to either move them out of CONFIG_*
>>> name space, or move some to Kconfig, if that makes sense. Since most our
>>> CONFIG_SYS_* macros are cross platforms (including armv7 and armv8), if
>>> using Kconfig option, do we add another mach-fsl folder to host the
>>> Kconfig, or somewhere else? We also have macros cross ARM and PowerPC.
>>> So we either move them out of arch/, or duplicate them for both arch.
>>>
>>> If we move them to another name space, for example SYS_FSL_*, do we want
>>> to move them out of config.h?
>>>
>>> Any suggestion/comment?
>>
>> I wonder if some of these (the ones that represent actual values
>> rather than enabling functions) can move to device tree, or tables?
>>
>
> While I try to move some options to Kconfig, I have an issue of
> duplicated names. For example, the MAX_CPUS is used in arch/x86/Kconfig.
> I know I can put another config with the same name, for example
> arch/arm/cpu/armv8/fsl-layerscape/Kconfig. The funny thing is when I
> search for this config option under menuconfig, it shows the location of
> x86, but showing defined in arch/arm/cpu/armv8/fsl-layerscape/Kconfig.
> Same thing happens when I try to move an option which is used by both
> PowerPC and ARM. This is not related to a common driver so I cannot put
> the option into a driver Kconfig (for example CONFIG_SYS_HAS_SERDES).
>
> Is there a solution for this?
>
> York
>

[U-Boot] [RFC] Rearrange CONFIG_* macros

[york sun]

On 09/28/2016 12:17 PM, Simon Glass wrote:
> +Masahiro, who may know

Masahiro,

Need some advise on this. How do we deal with duplicated config?

York

>
> On 28 September 2016 at 12:57, york sun <york.sun@nxp.com> wrote:
>> On 09/27/2016 10:55 AM, Simon Glass wrote:
>>> Hi York,
>>>
>>> On 27 September 2016 at 11:39, york sun <york.sun@nxp.com> wrote:
>>>> Guys,
>>>>
>>>> I want to discuss to rearrange the current CONFIG_* macros used by
>>>> Freescale Layerscape SoCs. We have been encouraged to use CONFIG_SYS_*
>>>> macros to define hardware setting, and other CONFIG_* macros for user
>>>> setting. Clearly this has changed. Kconfig options are used for most
>>>> user settings from now on. I am OK with it. But for existing
>>>> CONFIG_SYS_* macros, we need a plan to either move them out of CONFIG_*
>>>> name space, or move some to Kconfig, if that makes sense. Since most our
>>>> CONFIG_SYS_* macros are cross platforms (including armv7 and armv8), if
>>>> using Kconfig option, do we add another mach-fsl folder to host the
>>>> Kconfig, or somewhere else? We also have macros cross ARM and PowerPC.
>>>> So we either move them out of arch/, or duplicate them for both arch.
>>>>
>>>> If we move them to another name space, for example SYS_FSL_*, do we want
>>>> to move them out of config.h?
>>>>
>>>> Any suggestion/comment?
>>>
>>> I wonder if some of these (the ones that represent actual values
>>> rather than enabling functions) can move to device tree, or tables?
>>>
>>
>> While I try to move some options to Kconfig, I have an issue of
>> duplicated names. For example, the MAX_CPUS is used in arch/x86/Kconfig.
>> I know I can put another config with the same name, for example
>> arch/arm/cpu/armv8/fsl-layerscape/Kconfig. The funny thing is when I
>> search for this config option under menuconfig, it shows the location of
>> x86, but showing defined in arch/arm/cpu/armv8/fsl-layerscape/Kconfig.
>> Same thing happens when I try to move an option which is used by both
>> PowerPC and ARM. This is not related to a common driver so I cannot put
>> the option into a driver Kconfig (for example CONFIG_SYS_HAS_SERDES).
>>
>> Is there a solution for this?
>>
>> York
>>
>

[U-Boot] [RFC] Rearrange CONFIG_* macros

[Masahiro Yamada]

2016-09-30 0:47 GMT+09:00 york sun <york.sun@nxp.com>:
> On 09/28/2016 12:17 PM, Simon Glass wrote:
>> +Masahiro, who may know
>
> Masahiro,
>
> Need some advise on this. How do we deal with duplicated config?
>
> York
>
>>
>> On 28 September 2016 at 12:57, york sun <york.sun@nxp.com> wrote:
>>> On 09/27/2016 10:55 AM, Simon Glass wrote:
>>>> Hi York,
>>>>
>>>> On 27 September 2016 at 11:39, york sun <york.sun@nxp.com> wrote:
>>>>> Guys,
>>>>>
>>>>> I want to discuss to rearrange the current CONFIG_* macros used by
>>>>> Freescale Layerscape SoCs. We have been encouraged to use CONFIG_SYS_*
>>>>> macros to define hardware setting, and other CONFIG_* macros for user
>>>>> setting. Clearly this has changed. Kconfig options are used for most
>>>>> user settings from now on. I am OK with it. But for existing
>>>>> CONFIG_SYS_* macros, we need a plan to either move them out of CONFIG_*
>>>>> name space, or move some to Kconfig, if that makes sense. Since most our
>>>>> CONFIG_SYS_* macros are cross platforms (including armv7 and armv8), if
>>>>> using Kconfig option, do we add another mach-fsl folder to host the
>>>>> Kconfig, or somewhere else? We also have macros cross ARM and PowerPC.
>>>>> So we either move them out of arch/, or duplicate them for both arch.
>>>>>
>>>>> If we move them to another name space, for example SYS_FSL_*, do we want
>>>>> to move them out of config.h?
>>>>>
>>>>> Any suggestion/comment?
>>>>
>>>> I wonder if some of these (the ones that represent actual values
>>>> rather than enabling functions) can move to device tree, or tables?
>>>>
>>>
>>> While I try to move some options to Kconfig, I have an issue of
>>> duplicated names. For example, the MAX_CPUS is used in arch/x86/Kconfig.
>>> I know I can put another config with the same name, for example
>>> arch/arm/cpu/armv8/fsl-layerscape/Kconfig. The funny thing is when I
>>> search for this config option under menuconfig, it shows the location of
>>> x86, but showing defined in arch/arm/cpu/armv8/fsl-layerscape/Kconfig.
>>> Same thing happens when I try to move an option which is used by both
>>> PowerPC and ARM. This is not related to a common driver so I cannot put
>>> the option into a driver Kconfig (for example CONFIG_SYS_HAS_SERDES).
>>>
>>> Is there a solution for this?
>>>

Right.
The "Help" in menuconfig is just to display the path
to the first Kconfig entry found.
The result looks funny if we have multiple entries for the same option name.


I am not pretty sure about this particular case,
but there should be general solutions.


(1)  Rename the option to avoid name space conflict, e.g.

    MAX_CPUS   ->  FSL_MAX_CPUS      (for Freescale SoCs)
    MAX_CPUS   ->  X86_MAX_CPUS      (for x86)


(2) Unify the Kconfig entry

  As in Linux, we do not generally create multiple entries for the same option.

  If the option is sensible only for some platforms, the general practice is
    to use   "depends on HAVE_..." to hide the option on unrelated platforms.


  If X86 and FSL are the only platforms that have interest in this option,
  we can save HAVE_... and put them directly in "depends on".

    config MAX_CPUS
         int "Maximum number of CPUs permitted"
         depends on (SMP && X86) || VENDOR_FSL

  I am not quite sure about "VENDOR_FSL",
   so please choose your favorite one like
  SOC_FSL, PLAT_FSL, ARCH_FSL, or whatever.



(3)  Deprecate the option?

As Simon suggested Device Tree (or a kind of table?),
if it is not really a config option,
it may possible to specify it in a different way.

int fsl_get_max_cpus(void)
{
         return 2;
}



Now we have 8400 options in the whitelist,
it is a crazy idea to move them as they are.
I am wondering how many of them should really be CONFIG.



-- 
Best Regards
Masahiro Yamada

[U-Boot] [RFC] Rearrange CONFIG_* macros

[york sun]

On 09/29/2016 08:59 PM, Masahiro Yamada wrote:
> 2016-09-30 0:47 GMT+09:00 york sun <york.sun@nxp.com>:
>> On 09/28/2016 12:17 PM, Simon Glass wrote:
>>> +Masahiro, who may know
>>
>> Masahiro,
>>
>> Need some advise on this. How do we deal with duplicated config?
>>
>> York
>>
>>>
>>> On 28 September 2016 at 12:57, york sun <york.sun@nxp.com> wrote:
>>>> On 09/27/2016 10:55 AM, Simon Glass wrote:
>>>>> Hi York,
>>>>>
>>>>> On 27 September 2016 at 11:39, york sun <york.sun@nxp.com> wrote:
>>>>>> Guys,
>>>>>>
>>>>>> I want to discuss to rearrange the current CONFIG_* macros used by
>>>>>> Freescale Layerscape SoCs. We have been encouraged to use CONFIG_SYS_*
>>>>>> macros to define hardware setting, and other CONFIG_* macros for user
>>>>>> setting. Clearly this has changed. Kconfig options are used for most
>>>>>> user settings from now on. I am OK with it. But for existing
>>>>>> CONFIG_SYS_* macros, we need a plan to either move them out of CONFIG_*
>>>>>> name space, or move some to Kconfig, if that makes sense. Since most our
>>>>>> CONFIG_SYS_* macros are cross platforms (including armv7 and armv8), if
>>>>>> using Kconfig option, do we add another mach-fsl folder to host the
>>>>>> Kconfig, or somewhere else? We also have macros cross ARM and PowerPC.
>>>>>> So we either move them out of arch/, or duplicate them for both arch.
>>>>>>
>>>>>> If we move them to another name space, for example SYS_FSL_*, do we want
>>>>>> to move them out of config.h?
>>>>>>
>>>>>> Any suggestion/comment?
>>>>>
>>>>> I wonder if some of these (the ones that represent actual values
>>>>> rather than enabling functions) can move to device tree, or tables?
>>>>>
>>>>
>>>> While I try to move some options to Kconfig, I have an issue of
>>>> duplicated names. For example, the MAX_CPUS is used in arch/x86/Kconfig.
>>>> I know I can put another config with the same name, for example
>>>> arch/arm/cpu/armv8/fsl-layerscape/Kconfig. The funny thing is when I
>>>> search for this config option under menuconfig, it shows the location of
>>>> x86, but showing defined in arch/arm/cpu/armv8/fsl-layerscape/Kconfig.
>>>> Same thing happens when I try to move an option which is used by both
>>>> PowerPC and ARM. This is not related to a common driver so I cannot put
>>>> the option into a driver Kconfig (for example CONFIG_SYS_HAS_SERDES).
>>>>
>>>> Is there a solution for this?
>>>>
>
> Right.
> The "Help" in menuconfig is just to display the path
> to the first Kconfig entry found.
> The result looks funny if we have multiple entries for the same option name.
>
>
> I am not pretty sure about this particular case,
> but there should be general solutions.
>
>
> (1)  Rename the option to avoid name space conflict, e.g.
>
>     MAX_CPUS   ->  FSL_MAX_CPUS      (for Freescale SoCs)
>     MAX_CPUS   ->  X86_MAX_CPUS      (for x86)
>

It is a solution, but I don't like it for the reason described below[1].

>
> (2) Unify the Kconfig entry
>
>   As in Linux, we do not generally create multiple entries for the same option.
>
>   If the option is sensible only for some platforms, the general practice is
>     to use   "depends on HAVE_..." to hide the option on unrelated platforms.
>
>
>   If X86 and FSL are the only platforms that have interest in this option,
>   we can save HAVE_... and put them directly in "depends on".
>
>     config MAX_CPUS
>          int "Maximum number of CPUs permitted"
>          depends on (SMP && X86) || VENDOR_FSL
>
>   I am not quite sure about "VENDOR_FSL",
>    so please choose your favorite one like
>   SOC_FSL, PLAT_FSL, ARCH_FSL, or whatever.

This sounds like a bandage. I can go with this if there is no better 
solution.

Checking Linux Kconfig, I noticed the NR_CPUS are used in all archs. The 
difference is only one arch Kconfig is sourced by

source "arch/$SRCARCH/Kconfig"

I tried to do the same for U-Boot, but that will require we put ARCH at 
the command line of environmental variable. I think we moved away from 
this syntax. It also has some trouble to to use aarch64 because we put 
the actual code under arch/arm.

>
>
>
> (3)  Deprecate the option?
>
> As Simon suggested Device Tree (or a kind of table?),
> if it is not really a config option,
> it may possible to specify it in a different way.
>
> int fsl_get_max_cpus(void)
> {
>          return 2;
> }

It is not a direct replace. The MAX_CPUS is used to define array size 
and others. Using device tree will defeat these codes and requires a lot 
of rewriting.

>
>
>
> Now we have 8400 options in the whitelist,
> it is a crazy idea to move them as they are.
> I am wondering how many of them should really be CONFIG.

It is crazy. I am trying to move some to Kconfig and delete them from 
the white list. Some can be rewritten to avoid using CONFIG_* name 
space, or restructure code to eliminate the macros.

I admit I didn't pay attention to this change and it caught me by surprise.

[1] We have macros shared between PowerPC and ARM for Freescale QorIQ 
SoCs because they share similar designs at SoC level. Some options can 
be moved to driver Kconfig to avoid duplication. But there are many 
options are tied to hardware and they are not related to a common 
driver. Using the same macro simplifies the code and is easier to 
maintain. It is preferred to either PowerPC Kconfig, or ARM Kconfig to 
avoid duplication if we can.

York

[U-Boot] [RFC] Rearrange CONFIG_* macros

[Tom Rini]

On Fri, Sep 30, 2016 at 04:20:10AM +0000, york sun wrote:
> On 09/29/2016 08:59 PM, Masahiro Yamada wrote:
> > 2016-09-30 0:47 GMT+09:00 york sun <york.sun@nxp.com>:
> >> On 09/28/2016 12:17 PM, Simon Glass wrote:
> >>> +Masahiro, who may know
> >>
> >> Masahiro,
> >>
> >> Need some advise on this. How do we deal with duplicated config?
> >>
> >> York
> >>
> >>>
> >>> On 28 September 2016 at 12:57, york sun <york.sun@nxp.com> wrote:
> >>>> On 09/27/2016 10:55 AM, Simon Glass wrote:
> >>>>> Hi York,
> >>>>>
> >>>>> On 27 September 2016 at 11:39, york sun <york.sun@nxp.com> wrote:
> >>>>>> Guys,
> >>>>>>
> >>>>>> I want to discuss to rearrange the current CONFIG_* macros used by
> >>>>>> Freescale Layerscape SoCs. We have been encouraged to use CONFIG_SYS_*
> >>>>>> macros to define hardware setting, and other CONFIG_* macros for user
> >>>>>> setting. Clearly this has changed. Kconfig options are used for most
> >>>>>> user settings from now on. I am OK with it. But for existing
> >>>>>> CONFIG_SYS_* macros, we need a plan to either move them out of CONFIG_*
> >>>>>> name space, or move some to Kconfig, if that makes sense. Since most our
> >>>>>> CONFIG_SYS_* macros are cross platforms (including armv7 and armv8), if
> >>>>>> using Kconfig option, do we add another mach-fsl folder to host the
> >>>>>> Kconfig, or somewhere else? We also have macros cross ARM and PowerPC.
> >>>>>> So we either move them out of arch/, or duplicate them for both arch.
> >>>>>>
> >>>>>> If we move them to another name space, for example SYS_FSL_*, do we want
> >>>>>> to move them out of config.h?
> >>>>>>
> >>>>>> Any suggestion/comment?
> >>>>>
> >>>>> I wonder if some of these (the ones that represent actual values
> >>>>> rather than enabling functions) can move to device tree, or tables?
> >>>>>
> >>>>
> >>>> While I try to move some options to Kconfig, I have an issue of
> >>>> duplicated names. For example, the MAX_CPUS is used in arch/x86/Kconfig.
> >>>> I know I can put another config with the same name, for example
> >>>> arch/arm/cpu/armv8/fsl-layerscape/Kconfig. The funny thing is when I
> >>>> search for this config option under menuconfig, it shows the location of
> >>>> x86, but showing defined in arch/arm/cpu/armv8/fsl-layerscape/Kconfig.
> >>>> Same thing happens when I try to move an option which is used by both
> >>>> PowerPC and ARM. This is not related to a common driver so I cannot put
> >>>> the option into a driver Kconfig (for example CONFIG_SYS_HAS_SERDES).
> >>>>
> >>>> Is there a solution for this?
> >>>>
> >
> > Right.
> > The "Help" in menuconfig is just to display the path
> > to the first Kconfig entry found.
> > The result looks funny if we have multiple entries for the same option name.
> >
> >
> > I am not pretty sure about this particular case,
> > but there should be general solutions.
> >
> >
> > (1)  Rename the option to avoid name space conflict, e.g.
> >
> >     MAX_CPUS   ->  FSL_MAX_CPUS      (for Freescale SoCs)
> >     MAX_CPUS   ->  X86_MAX_CPUS      (for x86)
> >
> 
> It is a solution, but I don't like it for the reason described below[1].
> 
> >
> > (2) Unify the Kconfig entry
> >
> >   As in Linux, we do not generally create multiple entries for the same option.
> >
> >   If the option is sensible only for some platforms, the general practice is
> >     to use   "depends on HAVE_..." to hide the option on unrelated platforms.
> >
> >
> >   If X86 and FSL are the only platforms that have interest in this option,
> >   we can save HAVE_... and put them directly in "depends on".
> >
> >     config MAX_CPUS
> >          int "Maximum number of CPUs permitted"
> >          depends on (SMP && X86) || VENDOR_FSL
> >
> >   I am not quite sure about "VENDOR_FSL",
> >    so please choose your favorite one like
> >   SOC_FSL, PLAT_FSL, ARCH_FSL, or whatever.
> 
> This sounds like a bandage. I can go with this if there is no better 
> solution.

If MAX_CPUS has the same meaning in both cases, this isn't imho a
bandage but one of the cleanups that was hoped for in moving to Kconfig.
We see that a problem is encountered in more than one area more easily
and instead of letting N solutions accumulate we get one.

> Checking Linux Kconfig, I noticed the NR_CPUS are used in all archs. The 
> difference is only one arch Kconfig is sourced by
> 
> source "arch/$SRCARCH/Kconfig"
> 
> I tried to do the same for U-Boot, but that will require we put ARCH at 
> the command line of environmental variable. I think we moved away from 
> this syntax. It also has some trouble to to use aarch64 because we put 
> the actual code under arch/arm.

Yeah, we don't want to move in this direction.

[snip]
> [1] We have macros shared between PowerPC and ARM for Freescale QorIQ 
> SoCs because they share similar designs at SoC level. Some options can 
> be moved to driver Kconfig to avoid duplication. But there are many 
> options are tied to hardware and they are not related to a common 
> driver. Using the same macro simplifies the code and is easier to 
> maintain. It is preferred to either PowerPC Kconfig, or ARM Kconfig to 
> avoid duplication if we can.

I think this is honestly going to be the hard part, deciding what
belongs in a Kconfig'd area and what belongs in a different namespace
but that in the end we'll have clearer code for PowerPC and ARM going
forward.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160930/eb5f2a42/attachment.sig>

[U-Boot] [RFC] Rearrange CONFIG_* macros

[Scott Wood]

On Fri, 2016-09-30 at 22:24 -0400, Tom Rini wrote:
> On Fri, Sep 30, 2016 at 04:20:10AM +0000, york sun wrote:
> > 
> > On 09/29/2016 08:59 PM, Masahiro Yamada wrote:
> > > 

> > > ? If X86 and FSL are the only platforms that have interest in this
> > > option,
> > > ? we can save HAVE_... and put them directly in "depends on".
> > > 
> > > ????config MAX_CPUS
> > > ?????????int "Maximum number of CPUs permitted"
> > > ?????????depends on (SMP && X86) || VENDOR_FSL
> > > 
> > > ? I am not quite sure about "VENDOR_FSL",
> > > ???so please choose your favorite one like
> > > ? SOC_FSL, PLAT_FSL, ARCH_FSL, or whatever.
> > This sounds like a bandage. I can go with this if there is no better?
> > solution.
> If MAX_CPUS has the same meaning in both cases, this isn't imho a
> bandage but one of the cleanups that was hoped for in moving to Kconfig.
> We see that a problem is encountered in more than one area more easily
> and instead of letting N solutions accumulate we get one.

It's the depends line that looks like a bandage -- can't it just be "depends
on SMP", and if there are any SMP platforms that can't be immediately
converted to use this (e.g. the non-CONFIG MAX_CPUS define in
arch/arm/cpu/armv7/mx6/mp.c should be pretty easily convertible), add a TODO
note in the help text indicating that?

-Scott