From: leroy christophe <christophe.leroy@c-s.fr>
To: David Laight <David.Laight@ACULAB.COM>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
"scottwood@freescale.com" <scottwood@freescale.com>
Cc: "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 07/11] powerpc/8xx: macro for handling CPU15 errata
Date: Tue, 20 Jan 2015 12:32:39 +0100 [thread overview]
Message-ID: <54BE3CD7.4040208@c-s.fr> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CACEFD9@AcuExch.aculab.com>
Le 20/01/2015 12:09, David Laight a écrit :
> From Christophe Leroy
>> Having a macro will help keep clear code.
> It might remove an #if but it doesn't really help.
> All it means is that anyone reading the code has to hunt for
> the definition before proceeding.
>
> Some comment about what (and why) the extra code is needed
> might help.
The main reason is because of patch 09/11 where we have to duplicate
this code. I prefer to just duplicate one line rather than duplicate the
whole code (especially because in v1 of the PATCHset, it was duplicated
twice):
- DO_8xx_CPU15(r11, r10)
[...]
#ifdef CONFIG_MODULES
[...]
+ DO_8xx_CPU15(r10, r11)
[...]
+#else
+ mfspr r10, SPRN_SRR0 /* Get effective address of fault */
+ DO_8xx_CPU15(r11, r10)
Is this approach wrong ?
>
> ...
>> +
>> +#ifdef CONFIG_8xx_CPU15
>> +#define DO_8xx_CPU15(tmp, addr) \
>> + addi tmp, addr, PAGE_SIZE; \
>> + tlbie tmp; \
>> + addi tmp, addr, PAGE_SIZE; \
> You've even transcribed this incorrectly.
Oops
>
> Clearly not tested :-)
Indeed it's been tested, but tests can only show that the code is not
worth than before.
This code is there to fix a chip errata which (almost?) never happens.
In my production version, I have not activated this errata, and he have
never seen the problem on any of the more than 200 boards that have run
for at least 4 years.
Christophe
>
> David
>
>> + tlbie tmp
>> +#else
>> +#define DO_8xx_CPU15(tmp, addr)
>> +#endif
>> +
>> InstructionTLBMiss:
>> #ifdef CONFIG_8xx_CPU6
>> mtspr SPRN_DAR, r3
>> @@ -304,12 +315,7 @@ InstructionTLBMiss:
>> EXCEPTION_PROLOG_0
>> mtspr SPRN_SPRG_SCRATCH2, r10
>> mfspr r10, SPRN_SRR0 /* Get effective address of fault */
>> -#ifdef CONFIG_8xx_CPU15
>> - addi r11, r10, PAGE_SIZE
>> - tlbie r11
>> - addi r11, r10, -PAGE_SIZE
>> - tlbie r11
>> -#endif
>> + DO_8xx_CPU15(r11, r10)
>>
>> /* If we are faulting a kernel address, we have to use the
>> * kernel page tables.
>> --
>> 2.1.0
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
next prev parent reply other threads:[~2015-01-20 11:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-20 9:57 [PATCH v2 07/11] powerpc/8xx: macro for handling CPU15 errata Christophe Leroy
2015-01-20 9:57 ` Christophe Leroy
2015-01-20 11:09 ` David Laight
2015-01-20 11:09 ` David Laight
2015-01-20 11:32 ` leroy christophe [this message]
2015-01-20 11:43 ` David Laight
2015-01-20 11:43 ` David Laight
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=54BE3CD7.4040208@c-s.fr \
--to=christophe.leroy@c-s.fr \
--cc=David.Laight@ACULAB.COM \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=scottwood@freescale.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.