Pull request: scottwood/linux.git next

[Scott Wood]

On Thu, 2013-08-15 at 07:01 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2013-08-14 at 12:02 -0500, Scott Wood wrote:
> > On Wed, 2013-08-14 at 14:18 +1000, Benjamin Herrenschmidt wrote:
> > > On Thu, 2013-08-08 at 17:45 -0500, Scott Wood wrote:
> > > >       powerpc/e500: Update compilation flags with core specific
> > > > options
> > > 
> > > This breaks the build for my FSL test configs. For some reason gcc 4.7.3
> > > doesn't know about -mcpu=e5500
> > 
> > Ugh.  I guess that's what I get for using toolchains provided internally
> > rather than building them myself
> 
> :-)
> 
> I recommend you use one of tony's on kernel.org, that way you have
> something that matches what other people use :-)

It looks like -mcpu=e500mc64 has been supported for a while.

> > > Additionally, on 64-bit, that means one can no longer make a kernel that
> > > does both A2 and e5500...
> > 
> > Other than the toolchain issue, I'm not sure how this is worse than it
> > was before, when such a kernel would have had -Wa,-me500 forced.
> 
> Probably similarly bad though it did work ... but if you are touching
> it, may as well do it right...

There are worms inside that can...

> > What -mcpu value should be used in such a combined kernel?
> 
> Good question. We lack a generic booke option. What about powerpc64 ?
> 
> A default like that is fine as long as tricky asm uses the macros for
> that and the *optional* -mcpu=<xxx> option is available (and you can put
> it in defconfig).
> 
> It might be worth asking gcc to add something like -march=<arch version>
> or something like that though.

If we use the generic CPU target then mftb won't get turned into mfspr
(I assume this is what you meant by "tricky asm").  Does mfspr work
everywhere, including from userspace?  Or do we need to patch?  What
about 403GCX which seems to need some special SPR (I could leave the
existing ifdef alone, but what about vdso)?

-Scott