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....@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 > 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 Cheers, _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
