Pull request: scottwood/linux.git next

[Michael Ellerman]

On Tue, 2016-03-15 at 02:01 -0500, Scott Wood wrote:
> On Tue, 2016-03-15 at 11:19 +1100, Michael Ellerman wrote:
> > On Fri, 2016-03-11 at 21:15 -0600, Scott Wood wrote:
> >
> > > Highlights include 8xx optimizations, 32-bit checksum optimizations, 86xx
> > > consolidation, e5500/e6500 cpu hotplug, more fman and other dt bits, and
> > > minor fixes/cleanup.
> >
> > Hi Scott,
> >
> > This one's giving me a few troubles.
> >
> > > chenhui zhao (6):
> > >       powerpc/mm: any thread in one core can be the first to setup TLB1
> > >       powerpc/cache: add cache flush operation for various e500
> > >       powerpc/rcpm: add RCPM driver
> >
> > That commit doesn't build with SMP=n, as reported by Guenter:
> >
> >   arch/powerpc/sysdev/fsl_rcpm.c:32:2: error: implicit declaration of
> > function 'get_hard_smp_processor_id' [-Werror=implicit-function-declaration]
> >
> > That's not a biggy, I can probably fix it up here.
>
> By adding asm/smp.h?

Yeah I guess. I got derailed today and haven't got around to trying a fix.

> I missed this since we don't have a non-SMP defconfig that includes this.

Yep, same. I'll add a config to kisskb to catch it in future.

> > >       powerpc/mpc85xx: Add CPU hotplug support for E6500
> >
> > And this one breaks with old binutils (<= 2.22) because of:
> >
> >   arch/powerpc/kernel/head_64.S:210: Error: Unrecognized opcode: `mttmr'
> >
> > If you're happy to break the build on older bintuils for those configs then
> > that's OK with me.
>
> I'm not too bothered, but it's also an easy fix -- patch sent.

Thanks. Do you want to add it to your branch, or I can apply it after I merge
your branch?

> > > Christophe Leroy (31):
> > >       powerpc/8xx: Handle CPU6 ERRATA directly in mtspr() macro
> >
> > This breaks mpc866_ads_defconfig for me, with lots of:
> >
> >   arch/powerpc/mm/8xx_mmu.c:139:2: error: memory input 1 is not directly
> > addressable
> >
> > That's using gcc < 4.9. With >= 4.9 it builds OK. So again your call on
> > whether
> > we drop support for those compilers for that config.
>
> I'd rather not require something that new, especially for a chip so old.
>
> I've sent an untested patch that should fix it.

Thanks. I'll wait for Christophe to reply.

cheers