From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 3/5] powerpc: Introduce CONFIG_PPC_BOOK3S
Date: Tue, 02 Jun 2009 21:37:18 +1000 [thread overview]
Message-ID: <1243942638.5308.48.camel@pasglop> (raw)
In-Reply-To: <200906021149.17816.arnd@arndb.de>
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.
next prev parent reply other threads:[~2009-06-02 11:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-02 7:50 [PATCH 0/5] powerpc: A bit more way paved toward 64-bit Book3E support Benjamin Herrenschmidt
2009-06-02 7:50 ` [PATCH 1/5] powerpc: Move VMX and VSX asm code to vector.S Benjamin Herrenschmidt
2009-06-02 7:50 ` [PATCH 2/5] powerpc: Split exception handling out of head_64.S Benjamin Herrenschmidt
2009-06-02 10:32 ` Benjamin Herrenschmidt
2009-06-02 7:50 ` [PATCH 3/5] powerpc: Introduce CONFIG_PPC_BOOK3S Benjamin Herrenschmidt
2009-06-02 10:49 ` Arnd Bergmann
2009-06-02 11:37 ` Benjamin Herrenschmidt [this message]
2009-06-03 1:54 ` Benjamin Herrenschmidt
2009-06-02 7:50 ` [PATCH 4/5] powerpc: Separate PACA fields for server CPUs Benjamin Herrenschmidt
2009-06-02 7:50 ` [PATCH 5/5] powerpc: Shield code specific to 64-bit server processors Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1243942638.5308.48.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=arnd@arndb.de \
--cc=linuxppc-dev@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.