[PATCH] powerpc: merge include/asm/cputable.h
arnd at arndb.de
Fri Sep 16 08:56:31 EST 2005
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:
#define CPU_FTR_PSERIES_POSSIBLE (CPU_FTR_FOO | CPU_FTR_BAR)
#define CPU_FTR_PSERIES_ALWAYS (CPU_FTR_FOO)
#define CPU_FTR_PSERIES_POSSIBLE (0)
#define CPU_FTR_PSERIES_ALWAYS (-1)
#define CPU_FTR_PMAC_POSSIBLE (CPU_FTR_BAR | CPU_FTR_BAZ)
#define CPU_FTR_PMAL_ALWAYS (CPU_FTR_BAZ)
#define CPU_FTR_PMAC_POSSIBLE (0)
#define CPU_FTR_PMAC_ALWAYS (-1)
#define CPU_FTR_POSSIBLE CPU_FTR_PSERIES_POSSIBLE | CPU_FTR_PMAC_POSSIBLE \
#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.
More information about the Linuxppc64-dev