[PATCH v2] ARM: Do not run dummy_flush_tlb_a15_erratum() on non-Cortex-A15

[Russell King - ARM Linux]

On Thu, Aug 01, 2013 at 03:09:51PM -0500, Rob Herring wrote:
> On Thu, Aug 1, 2013 at 5:58 AM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > On Wed, Jul 31, 2013 at 11:03:46PM -0500, Rob Herring wrote:
> >> I just submitted my patch for 798181 ECO fix handling to the patch
> >> system today. Then I noticed this patch in your fixes branch. This is
> >> going to cause some churn as my patch needs to move the core version
> >> check back to a .c file.
> >>
> >> I don't know if you are okay with rebasing your fixes branch or not.
> >> If my patch is applied first, then this issue can be handled by just
> >> replacing dummy_flush_tlb_a15_erratum call in context.c a call to
> >> erratum_a15_798181.
> >
> > Well, firstly, are you sure your patch is correct?
> 
> Yes.
> 
> > You're removing the call to dummy_flush_tlb_a15_erratum() before the
> > smp_call_function() - smp_call_function() does _not_ call the function
> > for the local CPU.  So, what this means is we don't end up doing any
> > of the workaround for the local CPU.
> 
> No,  dummy_flush_tlb_a15_erratum() is now called from within
> erratum_a15_798181 if errata_fix_needed is non-zero. The return value
> only means do the IPI or not.
> 
> > Secondly, doesn't the check in your case reduce down to:
> >
> >         unsigned int midr = read_cpuid_id();
> >
> >         /* Cortex-A15 r0p0..r3p2 affected */
> >         if ((midr & 0xff0ffff0) != 0x410fc0f0 || midr > 0x413fc0f2 ||
> >             /* ECO not fully fixed */
> >             !(read_cpuid(CPUID_REVIDR) & 0x010))
> >                 return 0;
> >         return 1;
> >
> > because, assuming midr is not satisfied:
> >
> > revidr  errata_fix_needed       function return
> > 000     2                       1
> > 010     1                       0
> > 200     2                       1
> > 210     0                       0
> >
> > I think that the above version is still cheap enough to be inline.
> 
> Only because it is incomplete. :)

Your timing is very bad.  I just sent the entire fixes branch (and some
other stuff - which was scheduled for a long time to be sent tonight)
off to Linus having waited all day.  It was either that or sit on the
fixes branch even longer.