Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig

[Emil Medve <Emilian.Medve@Freescale.com>]

Hello Scott,


On 11/13/2013 12:19 PM, Scott Wood wrote:
> On Tue, 2013-11-12 at 20:34 -0600, Emil Medve wrote:
>> Hello Scott,
>>
>>
>> On 11/12/2013 07:46 PM, Scott Wood wrote:
>>> On Tue, 2013-11-12 at 16:57 -0600, Emil Medve wrote:
>>>> Hello Scott,
>>>>
>>>>
>>>> On 11/12/2013 04:04 PM, Scott Wood wrote:
>>>>> On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote:
>>>>>> mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y.
>>>>>> Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig.
>>>>>>
>>>>>> Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
>>>>>> ---
>>>>>>  arch/powerpc/configs/85xx/p1023_defconfig  |  188 ----------------------------
>>>>>>  arch/powerpc/configs/mpc85xx_defconfig     |   18 +++
>>>>>>  arch/powerpc/configs/mpc85xx_smp_defconfig |   17 +++
>>>>>>  3 files changed, 35 insertions(+), 188 deletions(-)
>>>>>>  delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig
>>>>>
>>>>> Are we still going to want to have one defconfig if and when we finally
>>>>> get datapath support upstream?  That's a lot of code to add to the 85xx
>>>>> config just for this one chip.
>>>>
>>>> Yes. But for mpc85xx_/smp_defconfig the datapath support shouldn't be
>>>> enabled by default given that just one SoC in that family has the
>>>> datapath (and we don't plan to put it in another e500v2 based SoC). For
>>>> regression/automation purposes config fragments should be used
>>>
>>> Is there any way to specify a meta-config for p1023 (or e500v2-dpaa or
>>> whatever) that says to combine mpc85xx_smp_defconfig with a dpaa
>>> fragment?
>>
>> Not aware of it
> 
> Then it's not yet a substitute for having a defconfig.
> 
>>> Do we have any config fragments in the tree so far?
>>
>> Nope. However, just to make sure, the fragment was my secondary point
>> and not necessarily as a candidate for upstreaming. My main point was
>> that the datapath support should simply not be enabled by default in the
>> mpc85xx_[smp_]defconfig
> 
> I think we should get numbers on how big the datapath code is (in its
> eventual upstream form) before deciding that, but if we do end up
> deciding not to enable it in mpc85xx_smp_defconfig, then there should be
> a separate defconfig for p1023 (possibly with a more generic name as
> discussed earlier).  If and when there's support for defconfigs that
> direct fragments to be included, then we can change the p1023 defconfig
> to use that, but I don't want to just leave it up to the user to enable
> manually.
> 
> If there's any way we can get the datapath code down to a reasonable
> size for inclusion in mpc85xx_smp_defconfig, that would be ideal.

Somebody gratuitously added a P1023 defconfig more then two years ago
with the notion that P1023 is special due to its datapath and we're
still one year out before we'll have the (P1023) datapath driver
upstream.  As of now this defconfig is just bit-rotting in the tree
creating confusion. Let's just remove it for now and we'll deal with the
entire e500v2_dpaa business when the datapath support will be upstreamed


Cheers,