On Tue, 2020-04-14 at 17:33 +1000, Michael Ellerman wrote: > I'm not sure TBH. This is all ancient history as far as I can tell, none > of it's been touched for ~7 years. > > Your config has: > > CONFIG_EMBEDDED6xx=y > CONFIG_PPC_BOOK3S_32=y > CONFIG_PPC_BOOK3S_6xx=y > CONFIG_PPC_MPC52xx=y > CONFIG_PPC_86xx=y > > > Which I'm not sure really makes sense at all, ie. it's trying to build a > kernel for multiple platforms at once (EMBEDDED6xx, MPC52xx, 86xx), but > the Kconfig doesn't exclude that so I guess we have to live with it for > now.
I thought supporting multiple platforms in a kernel was something we tried to support when practical? > So I'm going to guess it should have also excluded embedded6xx, and this > seems to fix it: > > diff --git a/arch/powerpc/platforms/Kconfig.cputype > b/arch/powerpc/platforms/Kconfig.cputype > index 0c3c1902135c..134fc383daf7 100644 > --- a/arch/powerpc/platforms/Kconfig.cputype > +++ b/arch/powerpc/platforms/Kconfig.cputype > @@ -278,7 +278,7 @@ config PTE_64BIT > > config PHYS_64BIT > bool 'Large physical address support' if E500 || PPC_86xx > - depends on (44x || E500 || PPC_86xx) && !PPC_83xx && !PPC_82xx > + depends on (44x || E500 || PPC_86xx) && !PPC_83xx && !PPC_82xx && > !EMBEDDED6xx > select PHYS_ADDR_T_64BIT > ---help--- > This option enables kernel support for larger than 32-bit physical > > > So unless anyone can tell me otherwise I'm inclined to commit that ^ This could silently break someone's config who's depending on PHYS_64BIT (e.g. an 86xx kernel that happens to include an embedded6xx target as well, even if just by accident). It'd be better to have the MVME500 depend on !CONFIG_PHYS_ADDR_T_64BIT as Nathan suggested (if there's nobody around to test a fix to the actual bug), which shouldn't break anyone since it already didn't build. -Scott