From: Arnd Bergmann <arnd@arndb.de>
To: Kumar Gala <kumar.gala@freescale.com>
Cc: linuxppc-dev@ozlabs.org, pantelis.antoniou@gmail.com,
linuxppc64-dev@ozlabs.org, linuxppc-embedded@ozlabs.org
Subject: Re: [PATCH] powerpc: merge include/asm/cputable.h
Date: Fri, 16 Sep 2005 00:56:31 +0200 [thread overview]
Message-ID: <200509160056.32617.arnd@arndb.de> (raw)
In-Reply-To: <CEA72228-613A-4106-8ACB-97B81D018B03@freescale.com>
On Dunnersdag 15 September 2005 19:44, Kumar Gala wrote:
> I get the idea now, how about we make CPU_FTR_ALWAYS &
> CPU_FTR_POSSIBLE just #defines and leave it to various sub-archs to
> define CPU_FTR_POSSIBLE if they want to.
>
So you mean like:
#ifdef CONFIG_PPC_PSERIES
#define CPU_FTR_PSERIES_POSSIBLE (CPU_FTR_FOO | CPU_FTR_BAR)
#define CPU_FTR_PSERIES_ALWAYS (CPU_FTR_FOO)
#else
#define CPU_FTR_PSERIES_POSSIBLE (0)
#define CPU_FTR_PSERIES_ALWAYS (-1)
#endif
#ifdef CONFIG_PPC_PMAC
#define CPU_FTR_PMAC_POSSIBLE (CPU_FTR_BAR | CPU_FTR_BAZ)
#define CPU_FTR_PMAL_ALWAYS (CPU_FTR_BAZ)
#else
#define CPU_FTR_PMAC_POSSIBLE (0)
#define CPU_FTR_PMAC_ALWAYS (-1)
#endif
...
#define CPU_FTR_POSSIBLE CPU_FTR_PSERIES_POSSIBLE | CPU_FTR_PMAC_POSSIBLE \
| CPU_FTR_...
#define CPU_FTR_ALWAYS CPU_FTR_POSSIBLE & CPU_FTR_PSERIES_ALWAYS \
& CPU_FTR_PMAC_ALWAYS & CPU_FTR_ ...
That would of course avoid having to define the features per CPU type,
but at the same time make the system more error prone, because every
time you add a feature to some of the CPUs, you'd have to know exactly
which platform defines to change as well, and they might get out of sync.
I also don't think that using the #defines here makes it any more
readable than the enums, because you cannot have compile-time conditionals
inside of #define.
> I see the classes of for FTR_POSSIBLE: CLASSIC_PPC, 8xx, 4xx, FSL-
> BOOKE, PPC64 (maybe more subclasses here).
>
> The hugh enum while useful, is just really ugly and I can't believe
> it's worth it for the ~60 cases we are using cpu_has_feature() in.
One point to consider is that we traditionally use #ifdef in the
source for many places that could simply use cpu_has_feature(). E.g.
most instances of #ifdef CONFIG_ALTIVEC could be replaced by
cpu_has_feature(CPU_FTR_ALTIVEC) without additional run-time overhead.
Arnd <><
next prev parent reply other threads:[~2005-09-15 22:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-08 21:02 cpu features testing 32 vs 64 bit Becky Bruce
2005-09-08 21:08 ` Pantelis Antoniou
2005-09-08 21:20 ` Kumar Gala
2005-09-08 21:48 ` Dan Malek
2005-09-08 22:02 ` Kumar Gala
2005-09-08 22:20 ` Dan Malek
2005-09-08 22:36 ` Arnd Bergmann
2005-09-09 0:08 ` David Gibson
2005-09-09 4:23 ` [PATCH] powerpc: merge include/asm/cputable.h Arnd Bergmann
2005-09-14 19:11 ` Kumar Gala
2005-09-14 23:58 ` Arnd Bergmann
2005-09-15 17:44 ` Kumar Gala
2005-09-15 22:56 ` Arnd Bergmann [this message]
2005-09-16 2:22 ` Kumar Gala
2005-09-16 3:11 ` Arnd Bergmann
2005-09-16 21:40 ` Kumar Gala
2005-09-17 0:36 ` Arnd Bergmann
2005-09-09 22:19 ` cpu features testing 32 vs 64 bit 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=200509160056.32617.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=kumar.gala@freescale.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=linuxppc-embedded@ozlabs.org \
--cc=linuxppc64-dev@ozlabs.org \
--cc=pantelis.antoniou@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).