public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: linuxppc64-dev@ozlabs.org
Cc: olof@austin.ibm.com (Olof Johansson),
	linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org,
	akpm@osdl.org, trini@kernel.crashing.org, paulus@samba.org,
	anton@samba.org, hpa@zytor.com
Subject: Re: [PATCH] PPC/PPC64: Introduce CPU_HAS_FEATURE() macro
Date: Fri, 4 Feb 2005 13:36:55 +0100	[thread overview]
Message-ID: <200502041336.59892.arnd@arndb.de> (raw)
In-Reply-To: <20050204072254.GA17565@austin.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 2368 bytes --]

On Freedag 04 Februar 2005 08:22, Olof Johansson wrote:
> It's getting pretty old to have see and type cur_cpu_spec->cpu_features
> & CPU_FTR_<feature>, when a shorter and less TLA-ridden macro is more
> readable.
> 
> This also takes care of the differences between PPC and PPC64 cpu
> features for the common code; most places in PPC could be replaced with
> the macro as well.

I have a somewhat similar patch that does the same to the
systemcfg->platform checks. I'm not sure if we should use the same inline
function for both checks, but I do think that they should be used in a
similar way, e.g. CPU_HAS_FEATURE(x) and PLATFORM_HAS_FEATURE(x).

My implementation of the platform checks tries to be extra clever by turning
runtime checks into compile time checks if possible. This reduces code size
and in some cases execution speed. It can also be used to replace compile
time checks, i.e. it allows us to write

static inline unsigned int readl(const volatile void __iomem *addr)
{
	if (platform_is(PLATFORM_PPC_ISERIES))
		return iSeries_readl(addr);
	if (platform_possible(PLATFORM_PPC_PSERIES))
		return eeh_readl(addr);
	return in_le32();
}

which will always result in the shortest code for any combination of
CONFIG_PPC_ISERIES, CONFIG_PPC_PSERIES and the other platforms.

The required code for this is roughly

enum {
	PPC64_PLATFORM_POSSIBLE =
#ifdef CONFIG_PPC_ISERIES
		PLATFORM_ISERIES |
#endif
#ifdef CONFIG_PPC_PSERIES
		PLATFORM_PSERIES |
#endif
#ifdef CONFIG_PPC_PSERIES
		PLATFORM_PSERIES_LPAR |
#endif
#ifdef CONFIG_PPC_POWERMAC
		PLATFORM_POWERMAC |
#endif
#ifdef CONFIG_PPC_MAPLE
		PLATFORM_MAPLE |
#endif
		0,
	PPC64_PLATFORM_ONLY =
#ifdef CONFIG_PPC_ISERIES
		PLATFORM_ISERIES &
#endif
#ifdef CONFIG_PPC_PSERIES
		PLATFORM_PSERIES &
#endif
#ifdef CONFIG_PPC_POWERMAC
		PLATFORM_POWERMAC &
#endif
#ifdef CONFIG_PPC_MAPLE
		PLATFORM_MAPLE &
#endif
		-1ul,
};

static inline platform_is(unsigned long platform)
{
	return ((PPC64_PLATFORM_ONLY & platform) 
	 || (PPC64_PLATFORM_POSSIBLE & platform & systemcfg->platform));
}

static inline platform_possible(unsigned long platform)
{
	reutrn !!(PPC64_PLATFORM_POSSIBLE & platform);
}

The same stuff is obviously possible for cur_cpu_spec->cpu_features as well.
Do you think that it will help there?

	Arnd <><

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2005-02-04 12:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-04  7:22 [PATCH] PPC/PPC64: Introduce CPU_HAS_FEATURE() macro Olof Johansson
2005-02-04  8:17 ` Pekka Enberg
2005-02-04 17:20   ` Olof Johansson
2005-02-05  7:48     ` Pekka Enberg
2005-02-05  9:08     ` Benjamin Herrenschmidt
2005-02-04 12:36 ` Arnd Bergmann [this message]
2005-02-04 18:35   ` Olof Johansson
2005-02-04 18:57     ` Arnd Bergmann
2005-02-04 23:50     ` Benjamin Herrenschmidt
2005-02-04 23:49   ` Benjamin Herrenschmidt
2005-02-05  0:22     ` Arnd Bergmann
2005-02-05  1:34       ` Anton Blanchard
2005-02-05 11:04         ` Arnd Bergmann
2005-02-05  1:47       ` Benjamin Herrenschmidt
2005-02-04 14:45 ` Tom Rini
2005-02-05 18:46 ` [PATCH] PPC/PPC64: Abstract cpu_feature checks Olof Johansson
2005-02-06  3:26   ` Olof Johansson
2005-02-06 11:57     ` Arnd Bergmann

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=200502041336.59892.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=akpm@osdl.org \
    --cc=anton@samba.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=linuxppc64-dev@ozlabs.org \
    --cc=olof@austin.ibm.com \
    --cc=paulus@samba.org \
    --cc=trini@kernel.crashing.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox