On Tue, 2009-06-02 at 11:49 +0100, Arnd Bergmann wrote:
> On Tuesday 02 June 2009, Benjamin Herrenschmidt wrote:
> > --- linux-work.orig/arch/powerpc/platforms/Kconfig.cputype  2009-06-02 
> > 16:29:27.000000000 +1000
> > +++ linux-work/arch/powerpc/platforms/Kconfig.cputype       2009-06-02 
> > 16:55:01.000000000 +1000
> > @@ -9,7 +9,6 @@ menu "Processor support"
> >  choice
> >     prompt "Processor Type"
> >     depends on PPC32
> > -   default 6xx
> >     help
> >       There are five families of 32 bit PowerPC chips supported.
> >       The most common ones are the desktop and server CPUs (601, 603,
> 
> It looks like you couldn't decide which route to take here. You leave the
> 'depends on PPC32' above, but

The choice depends on PPC32 since there is no choice .. yet for 64-bit.
I removed the default 6xx because I noticed a warning from Kbuild that
it doesn't like defaults for choices.

> >  config PPC_85xx
> >     bool "Freescale 85xx"
> > +   depends on PPC32

Ah right, I can remove these. Initially, the choice was available for
both 32 and 64 bit ;-) That's an artifact of the patch splitting since I
only introduce Book3E for 64-bit later.

> also add it (redundantly) in all other processor types except BOOK3S, and

Right. As I said, artifact of the split. I'll remove them for now.

> > -# Until we have a choice of exclusive CPU types on 64-bit, we always
> > -# use PPC_BOOK3S. On 32-bit, this is equivalent to 6xx which is
> > -# "classic" MMU
> > -
> >  config PPC_BOOK3S
> > -       def_bool y
> > -       depends on PPC64 || 6xx
> > +   default y
> > +           depends on PPC64
> > +   select PPC_FPU
> > +
> 
> then add the other BOOK3S option depending on PPC64. Even though
> it might look silly to have a choice statement with just one possible
> option in case of PPC64, why not integrate it right away, for consistency
> reasons. It seems strange to have the same Kconfig symbol both
> as a choice and a simple bool.

Well, I was hesitating. The initial patch added the choice with E and S
for both 32 and 64 as you can guess. But we aren't ready for that yet.

I suppose I can do a one-option choice in the meantime.

> > @@ -125,6 +131,7 @@ config BOOKE
> >  config FSL_BOOKE
> >     bool
> >     depends on E200 || E500
> > +   select PPC_BOOK3E_MMU
> >     default y
> >  
> >  config FSL_EMB_PERFMON
> > @@ -203,7 +210,7 @@ config SPE
> >  
> >  config PPC_STD_MMU
> >     bool
> > -   depends on 6xx || PPC64
> > +   depends on PPC_BOOK3S
> >     default y
> >  
> >  config PPC_STD_MMU_32
> 
> This also feels inconsistent, using a 'select' in one case and 'depends on' 
> in the
> other one. The two ways are obviously equivalent, but I find it a bit 
> confusing
> to mix them.

Right, I should probably use select in both.

Cheers,
Ben.


_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Reply via email to