[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1359478014.3529.157.camel@shinybook.infradead.org>
Date: Tue, 29 Jan 2013 16:46:58 +0000
From: "Woodhouse, David" <david.woodhouse@...el.com>
To: Borislav Petkov <bp@...en8.de>
CC: Kim Phillips <kim.phillips@...escale.com>,
Russell King <linux@....linux.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
Daniel Santos <daniel.santos@...ox.com>,
David Rientjes <rientjes@...gle.com>,
Rusty Russell <rusty@...tcorp.com.au>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] arm: use built-in byte swap function
On Tue, 2013-01-29 at 09:35 +0100, Borislav Petkov wrote:
>
> >
> > #ifdef CONFIG_ARCH_USE_BUILTIN_BSWAP
> > -#if GCC_VERSION >= 40400
> > +#if (!defined(__arm__) && GCC_VERSION >= 40400) || \
> > + (defined(__arm__) && GCC_VERSION >= 40600)
>
> There should be no arch-specific stuff in a generic header. I guess
> you probably need to select ARCH_USE_BUILTIN_BSWAP in an arm-specific
> compiler.h header after checking compiler version...
If we're really going to have many different architectures depending on
different versions of GCC for this (if it wasn't sane to use it from
4.4/4.8 when it got introduced, and depends on some later arch-specific
optimisation), then perhaps we'll have the arch provide the
corresponding required GCC_VERSION for using each of 64/32/16 bit
builtins, instead of just a yes/no flag? Or just define
__HAVE_BUILTIN_BSWAPxx__ for itself, perhaps?
In fact we could start by having just the problematic architectures set
__HAVE_BUILTIN_BSWAPxx__ for themselves according to whatever criteria
they want, and then if there's scope for consolidating that in the
generic code then we can do so later.
--
Sent with MeeGo's ActiveSync support.
David Woodhouse Open Source Technology Centre
David.Woodhouse@...el.com Intel Corporation
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (4370 bytes)
Powered by blists - more mailing lists