* Re: [PATCH linux-next] selftests/powerpc: remove duplicate include
From: Christophe Leroy @ 2021-08-24 16:35 UTC (permalink / raw)
To: Shuah Khan, CGEL, Michael Ellerman
Cc: Shuah Khan, Zeal Robot, linux-kernel, Changcheng Deng,
Paul Mackerras, linux-kselftest, linuxppc-dev
In-Reply-To: <9096738b-7e57-418d-6253-16a107789dac@linuxfoundation.org>
Le 24/08/2021 à 16:41, Shuah Khan a écrit :
> On 8/23/21 9:05 PM, CGEL wrote:
>> From: Changcheng Deng <deng.changcheng@zte.com.cn>
>>
>> Clean up the following includecheck warning:
>>
>> ./tools/testing/selftests/powerpc/tm/tm-poison.c: inttypes.h is included
>> more than once.
>>
>> No functional change.
>>
>> Reported-by: Zeal Robot <zealci@zte.com.cn>
>> Signed-off-by: Changcheng Deng <deng.changcheng@zte.com.cn>
>> ---
>> tools/testing/selftests/powerpc/tm/tm-poison.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/tools/testing/selftests/powerpc/tm/tm-poison.c
>> b/tools/testing/selftests/powerpc/tm/tm-poison.c
>> index 29e5f26..27c083a 100644
>> --- a/tools/testing/selftests/powerpc/tm/tm-poison.c
>> +++ b/tools/testing/selftests/powerpc/tm/tm-poison.c
>> @@ -20,7 +20,6 @@
>> #include <sched.h>
>> #include <sys/types.h>
>> #include <signal.h>
>> -#include <inttypes.h>
>> #include "tm.h"
>>
>
> We can't accept this patch. The from and Signed-off-by don't match.
As far as I can see they match:
From: Changcheng Deng <deng.changcheng@zte.com.cn>
Signed-off-by: Changcheng Deng <deng.changcheng@zte.com.cn>
Christophe
^ permalink raw reply
* Re: [PATCH linux-next] selftests/powerpc: remove duplicate include
From: Shuah Khan @ 2021-08-24 16:42 UTC (permalink / raw)
To: Christophe Leroy, CGEL, Michael Ellerman
Cc: Shuah Khan, Zeal Robot, linux-kernel, Changcheng Deng,
Paul Mackerras, linux-kselftest, Shuah Khan, linuxppc-dev
In-Reply-To: <e59721c8-fe59-cafe-01a3-8c7d74f2583d@csgroup.eu>
On 8/24/21 10:35 AM, Christophe Leroy wrote:
>
>
> Le 24/08/2021 à 16:41, Shuah Khan a écrit :
>> On 8/23/21 9:05 PM, CGEL wrote:
>>> From: Changcheng Deng <deng.changcheng@zte.com.cn>
>>>
>>> Clean up the following includecheck warning:
>>>
>>> ./tools/testing/selftests/powerpc/tm/tm-poison.c: inttypes.h is included
>>> more than once.
>>>
>>> No functional change.
>>>
>>> Reported-by: Zeal Robot <zealci@zte.com.cn>
>>> Signed-off-by: Changcheng Deng <deng.changcheng@zte.com.cn>
>>> ---
>>> tools/testing/selftests/powerpc/tm/tm-poison.c | 1 -
>>> 1 file changed, 1 deletion(-)
>>>
>>> diff --git a/tools/testing/selftests/powerpc/tm/tm-poison.c b/tools/testing/selftests/powerpc/tm/tm-poison.c
>>> index 29e5f26..27c083a 100644
>>> --- a/tools/testing/selftests/powerpc/tm/tm-poison.c
>>> +++ b/tools/testing/selftests/powerpc/tm/tm-poison.c
>>> @@ -20,7 +20,6 @@
>>> #include <sched.h>
>>> #include <sys/types.h>
>>> #include <signal.h>
>>> -#include <inttypes.h>
>>> #include "tm.h"
>>>
>>
>> We can't accept this patch. The from and Signed-off-by don't match.
>
> As far as I can see they match:
>
> From: Changcheng Deng <deng.changcheng@zte.com.cn>
> Signed-off-by: Changcheng Deng <deng.changcheng@zte.com.cn>
>
Yeah. My bad.
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH v2 RESEND] powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC
From: Christophe Leroy @ 2021-08-24 17:11 UTC (permalink / raw)
To: Paul Moore
Cc: linux-kernel, Eric Paris, linux-audit, Paul Mackerras,
linuxppc-dev
In-Reply-To: <CAHC9VhR3E6=5HmRaWMWbp4WHsua02niwnzaRGM3tLqd4Y4LA6w@mail.gmail.com>
Le 24/08/2021 à 16:47, Paul Moore a écrit :
> On Tue, Aug 24, 2021 at 9:36 AM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>>
>> Commit e65e1fc2d24b ("[PATCH] syscall class hookup for all normal
>> targets") added generic support for AUDIT but that didn't include
>> support for bi-arch like powerpc.
>>
>> Commit 4b58841149dc ("audit: Add generic compat syscall support")
>> added generic support for bi-arch.
>>
>> Convert powerpc to that bi-arch generic audit support.
>>
>> Cc: Paul Moore <paul@paul-moore.com>
>> Cc: Eric Paris <eparis@redhat.com>
>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>> ---
>> Resending v2 with Audit people in Cc
>>
>> v2:
>> - Missing 'git add' for arch/powerpc/include/asm/unistd32.h
>> - Finalised commit description
>> ---
>> arch/powerpc/Kconfig | 5 +-
>> arch/powerpc/include/asm/unistd32.h | 7 +++
>> arch/powerpc/kernel/Makefile | 3 --
>> arch/powerpc/kernel/audit.c | 84 -----------------------------
>> arch/powerpc/kernel/compat_audit.c | 44 ---------------
>> 5 files changed, 8 insertions(+), 135 deletions(-)
>> create mode 100644 arch/powerpc/include/asm/unistd32.h
>> delete mode 100644 arch/powerpc/kernel/audit.c
>> delete mode 100644 arch/powerpc/kernel/compat_audit.c
>
> Can you explain, in detail please, the testing you have done to verify
> this patch?
>
I built ppc64_defconfig and checked that the generated code is functionnaly equivalent.
ppc32_classify_syscall() is exactly the same as audit_classify_compat_syscall() except that the
later takes the syscall as second argument (ie in r4) whereas the former takes it as first argument
(ie in r3).
audit_classify_arch() and powerpc audit_classify_syscall() are slightly different between the
powerpc version and the generic version because the powerpc version checks whether it is
AUDIT_ARCH_PPC or not (ie value 20), while the generic one checks whether it has bit
__AUDIT_ARCH_64BIT set or not (__AUDIT_ARCH_64BIT is the sign bit of a word), but taking into
account that the abi is either AUDIT_ARCH_PPC, AUDIT_ARCH_PPC64 or AUDIT_ARCH_PPC64LE, the result is
the same.
If you are asking I guess you saw something wrong ?
arch/powerpc/kernel/compat_audit.o: file format elf64-powerpc
Disassembly of section .text:
0000000000000000 <.ppc32_classify_syscall>:
0: 28 03 00 66 cmplwi r3,102
4: 7c 69 1b 78 mr r9,r3
8: 41 82 00 48 beq 50 <.ppc32_classify_syscall+0x50>
c: 41 81 00 24 bgt 30 <.ppc32_classify_syscall+0x30>
10: 28 03 00 05 cmplwi r3,5
14: 38 60 00 02 li r3,2
18: 4d 82 00 20 beqlr
1c: 28 09 00 0b cmplwi r9,11
20: 40 82 00 38 bne 58 <.ppc32_classify_syscall+0x58>
24: 38 60 00 05 li r3,5
28: 4e 80 00 20 blr
2c: 60 00 00 00 nop
30: 28 03 01 1e cmplwi r3,286
34: 38 60 00 01 li r3,1
38: 4c 82 00 20 bnelr
3c: 38 60 00 03 li r3,3
40: 4e 80 00 20 blr
44: 60 00 00 00 nop
48: 60 00 00 00 nop
4c: 60 00 00 00 nop
50: 38 60 00 04 li r3,4
54: 4e 80 00 20 blr
58: 38 60 00 01 li r3,1
5c: 4e 80 00 20 blr
lib/compat_audit.o: file format elf64-powerpc
Disassembly of section .text:
0000000000000000 <.audit_classify_compat_syscall>:
0: 28 04 00 66 cmplwi r4,102
4: 41 82 00 4c beq 50 <.audit_classify_compat_syscall+0x50>
8: 41 81 00 28 bgt 30 <.audit_classify_compat_syscall+0x30>
c: 28 04 00 05 cmplwi r4,5
10: 38 60 00 02 li r3,2
14: 4d 82 00 20 beqlr
18: 28 04 00 0b cmplwi r4,11
1c: 40 82 00 3c bne 58 <.audit_classify_compat_syscall+0x58>
20: 38 60 00 05 li r3,5
24: 4e 80 00 20 blr
28: 60 00 00 00 nop
2c: 60 00 00 00 nop
30: 28 04 01 1e cmplwi r4,286
34: 38 60 00 01 li r3,1
38: 4c 82 00 20 bnelr
3c: 38 60 00 03 li r3,3
40: 4e 80 00 20 blr
44: 60 00 00 00 nop
48: 60 00 00 00 nop
4c: 60 00 00 00 nop
50: 38 60 00 04 li r3,4
54: 4e 80 00 20 blr
58: 38 60 00 01 li r3,1
5c: 4e 80 00 20 blr
arch/powerpc/kernel/audit.o: file format elf64-powerpc
Disassembly of section .text:
0000000000000000 <.audit_classify_arch>:
0: 68 63 00 14 xori r3,r3,20
4: 7c 63 00 34 cntlzw r3,r3
8: 54 63 d9 7e rlwinm r3,r3,27,5,31
c: 4e 80 00 20 blr
0000000000000010 <.audit_classify_syscall>:
10: 2c 03 00 14 cmpwi r3,20
14: 41 82 00 5c beq 70 <.audit_classify_syscall+0x60>
18: 28 04 00 66 cmplwi r4,102
1c: 41 82 00 44 beq 60 <.audit_classify_syscall+0x50>
20: 41 81 00 20 bgt 40 <.audit_classify_syscall+0x30>
24: 28 04 00 05 cmplwi r4,5
28: 38 60 00 02 li r3,2
2c: 4d 82 00 20 beqlr
30: 28 04 00 0b cmplwi r4,11
34: 40 82 00 64 bne 98 <.audit_classify_syscall+0x88>
38: 38 60 00 05 li r3,5
3c: 4e 80 00 20 blr
40: 28 04 01 1e cmplwi r4,286
44: 38 60 00 00 li r3,0
48: 4c 82 00 20 bnelr
4c: 38 60 00 03 li r3,3
50: 4e 80 00 20 blr
54: 60 00 00 00 nop
58: 60 00 00 00 nop
5c: 60 00 00 00 nop
60: 38 60 00 04 li r3,4
64: 4e 80 00 20 blr
68: 60 00 00 00 nop
6c: 60 00 00 00 nop
70: 7c 08 02 a6 mflr r0
74: 7c 83 23 78 mr r3,r4
78: f8 01 00 10 std r0,16(r1)
7c: f8 21 ff 91 stdu r1,-112(r1)
80: 48 00 00 01 bl 80 <.audit_classify_syscall+0x70>
80: R_PPC64_REL24 .ppc32_classify_syscall
84: 60 00 00 00 nop
88: 38 21 00 70 addi r1,r1,112
8c: e8 01 00 10 ld r0,16(r1)
90: 7c 08 03 a6 mtlr r0
94: 4e 80 00 20 blr
98: 38 60 00 00 li r3,0
9c: 4e 80 00 20 blr
Disassembly of section .init.text:
0000000000000000 <.audit_classes_init>:
0: 7c 08 02 a6 mflr r0
4: fb e1 ff f8 std r31,-8(r1)
8: 3d 22 00 00 addis r9,r2,0
a: R_PPC64_TOC16_HA .toc
c: 38 60 00 07 li r3,7
10: e8 89 00 00 ld r4,0(r9)
12: R_PPC64_TOC16_LO_DS .toc
14: 3f e2 00 00 addis r31,r2,0
16: R_PPC64_TOC16_HA .data
18: 3b ff 00 00 addi r31,r31,0
1a: R_PPC64_TOC16_LO .data
1c: f8 01 00 10 std r0,16(r1)
20: f8 21 ff 81 stdu r1,-128(r1)
24: 48 00 00 01 bl 24 <.audit_classes_init+0x24>
24: R_PPC64_REL24 .audit_register_class
28: 60 00 00 00 nop
2c: 3d 22 00 00 addis r9,r2,0
2e: R_PPC64_TOC16_HA .toc+0x8
30: 38 60 00 05 li r3,5
34: e8 89 00 00 ld r4,0(r9)
36: R_PPC64_TOC16_LO_DS .toc+0x8
38: 48 00 00 01 bl 38 <.audit_classes_init+0x38>
38: R_PPC64_REL24 .audit_register_class
3c: 60 00 00 00 nop
40: 3d 22 00 00 addis r9,r2,0
42: R_PPC64_TOC16_HA .toc+0x10
44: 38 60 00 01 li r3,1
48: e8 89 00 00 ld r4,0(r9)
4a: R_PPC64_TOC16_LO_DS .toc+0x10
4c: 48 00 00 01 bl 4c <.audit_classes_init+0x4c>
4c: R_PPC64_REL24 .audit_register_class
50: 60 00 00 00 nop
54: 3d 22 00 00 addis r9,r2,0
56: R_PPC64_TOC16_HA .toc+0x18
58: 38 60 00 03 li r3,3
5c: e8 89 00 00 ld r4,0(r9)
5e: R_PPC64_TOC16_LO_DS .toc+0x18
60: 48 00 00 01 bl 60 <.audit_classes_init+0x60>
60: R_PPC64_REL24 .audit_register_class
64: 60 00 00 00 nop
68: 3d 22 00 00 addis r9,r2,0
6a: R_PPC64_TOC16_HA .toc+0x20
6c: 38 60 00 09 li r3,9
70: e8 89 00 00 ld r4,0(r9)
72: R_PPC64_TOC16_LO_DS .toc+0x20
74: 48 00 00 01 bl 74 <.audit_classes_init+0x74>
74: R_PPC64_REL24 .audit_register_class
78: 60 00 00 00 nop
7c: 7f e4 fb 78 mr r4,r31
80: 38 60 00 06 li r3,6
84: 48 00 00 01 bl 84 <.audit_classes_init+0x84>
84: R_PPC64_REL24 .audit_register_class
88: 60 00 00 00 nop
8c: 38 9f 00 5c addi r4,r31,92
90: 38 60 00 04 li r3,4
94: 48 00 00 01 bl 94 <.audit_classes_init+0x94>
94: R_PPC64_REL24 .audit_register_class
98: 60 00 00 00 nop
9c: 38 9f 00 84 addi r4,r31,132
a0: 38 60 00 00 li r3,0
a4: 48 00 00 01 bl a4 <.audit_classes_init+0xa4>
a4: R_PPC64_REL24 .audit_register_class
a8: 60 00 00 00 nop
ac: 38 9f 00 c4 addi r4,r31,196
b0: 38 60 00 02 li r3,2
b4: 48 00 00 01 bl b4 <.audit_classes_init+0xb4>
b4: R_PPC64_REL24 .audit_register_class
b8: 60 00 00 00 nop
bc: 38 9f 01 04 addi r4,r31,260
c0: 38 60 00 08 li r3,8
c4: 48 00 00 01 bl c4 <.audit_classes_init+0xc4>
c4: R_PPC64_REL24 .audit_register_class
c8: 60 00 00 00 nop
cc: 38 60 00 00 li r3,0
d0: 38 21 00 80 addi r1,r1,128
d4: e8 01 00 10 ld r0,16(r1)
d8: eb e1 ff f8 ld r31,-8(r1)
dc: 7c 08 03 a6 mtlr r0
e0: 4e 80 00 20 blr
lib/audit.o: file format elf64-powerpc
Disassembly of section .text:
0000000000000000 <.audit_classify_arch>:
0: 7c 63 18 f8 not r3,r3
4: 54 63 0f fe rlwinm r3,r3,1,31,31
8: 4e 80 00 20 blr
c: 60 00 00 00 nop
0000000000000010 <.audit_classify_syscall>:
10: 2c 03 00 00 cmpwi r3,0
14: 40 80 00 4c bge 60 <.audit_classify_syscall+0x50>
18: 28 04 00 66 cmplwi r4,102
1c: 41 82 00 74 beq 90 <.audit_classify_syscall+0x80>
20: 41 81 00 20 bgt 40 <.audit_classify_syscall+0x30>
24: 28 04 00 05 cmplwi r4,5
28: 38 60 00 02 li r3,2
2c: 4d 82 00 20 beqlr
30: 28 04 00 0b cmplwi r4,11
34: 41 82 00 20 beq 54 <.audit_classify_syscall+0x44>
38: 38 60 00 00 li r3,0
3c: 4e 80 00 20 blr
40: 28 04 01 1e cmplwi r4,286
44: 38 60 00 03 li r3,3
48: 4d 82 00 20 beqlr
4c: 28 04 01 6a cmplwi r4,362
50: 40 82 ff e8 bne 38 <.audit_classify_syscall+0x28>
54: 38 60 00 05 li r3,5
58: 4e 80 00 20 blr
5c: 60 00 00 00 nop
60: 7c 08 02 a6 mflr r0
64: f8 01 00 10 std r0,16(r1)
68: f8 21 ff 91 stdu r1,-112(r1)
6c: 48 00 00 01 bl 6c <.audit_classify_syscall+0x5c>
6c: R_PPC64_REL24 .audit_classify_compat_syscall
70: 60 00 00 00 nop
74: 38 21 00 70 addi r1,r1,112
78: e8 01 00 10 ld r0,16(r1)
7c: 7c 08 03 a6 mtlr r0
80: 4e 80 00 20 blr
84: 60 00 00 00 nop
88: 60 00 00 00 nop
8c: 60 00 00 00 nop
90: 38 60 00 04 li r3,4
94: 4e 80 00 20 blr
Disassembly of section .init.text:
0000000000000000 <.audit_classes_init>:
0: 7c 08 02 a6 mflr r0
4: fb e1 ff f8 std r31,-8(r1)
8: 3d 22 00 00 addis r9,r2,0
a: R_PPC64_TOC16_HA .toc
c: 38 60 00 07 li r3,7
10: e8 89 00 00 ld r4,0(r9)
12: R_PPC64_TOC16_LO_DS .toc
14: 3f e2 00 00 addis r31,r2,0
16: R_PPC64_TOC16_HA .data
18: 3b ff 00 00 addi r31,r31,0
1a: R_PPC64_TOC16_LO .data
1c: f8 01 00 10 std r0,16(r1)
20: f8 21 ff 81 stdu r1,-128(r1)
24: 48 00 00 01 bl 24 <.audit_classes_init+0x24>
24: R_PPC64_REL24 .audit_register_class
28: 60 00 00 00 nop
2c: 3d 22 00 00 addis r9,r2,0
2e: R_PPC64_TOC16_HA .toc+0x8
30: 38 60 00 05 li r3,5
34: e8 89 00 00 ld r4,0(r9)
36: R_PPC64_TOC16_LO_DS .toc+0x8
38: 48 00 00 01 bl 38 <.audit_classes_init+0x38>
38: R_PPC64_REL24 .audit_register_class
3c: 60 00 00 00 nop
40: 3d 22 00 00 addis r9,r2,0
42: R_PPC64_TOC16_HA .toc+0x10
44: 38 60 00 01 li r3,1
48: e8 89 00 00 ld r4,0(r9)
4a: R_PPC64_TOC16_LO_DS .toc+0x10
4c: 48 00 00 01 bl 4c <.audit_classes_init+0x4c>
4c: R_PPC64_REL24 .audit_register_class
50: 60 00 00 00 nop
54: 3d 22 00 00 addis r9,r2,0
56: R_PPC64_TOC16_HA .toc+0x18
58: 38 60 00 03 li r3,3
5c: e8 89 00 00 ld r4,0(r9)
5e: R_PPC64_TOC16_LO_DS .toc+0x18
60: 48 00 00 01 bl 60 <.audit_classes_init+0x60>
60: R_PPC64_REL24 .audit_register_class
64: 60 00 00 00 nop
68: 3d 22 00 00 addis r9,r2,0
6a: R_PPC64_TOC16_HA .toc+0x20
6c: 38 60 00 09 li r3,9
70: e8 89 00 00 ld r4,0(r9)
72: R_PPC64_TOC16_LO_DS .toc+0x20
74: 48 00 00 01 bl 74 <.audit_classes_init+0x74>
74: R_PPC64_REL24 .audit_register_class
78: 60 00 00 00 nop
7c: 7f e4 fb 78 mr r4,r31
80: 38 60 00 06 li r3,6
84: 48 00 00 01 bl 84 <.audit_classes_init+0x84>
84: R_PPC64_REL24 .audit_register_class
88: 60 00 00 00 nop
8c: 38 9f 00 5c addi r4,r31,92
90: 38 60 00 04 li r3,4
94: 48 00 00 01 bl 94 <.audit_classes_init+0x94>
94: R_PPC64_REL24 .audit_register_class
98: 60 00 00 00 nop
9c: 38 9f 00 84 addi r4,r31,132
a0: 38 60 00 00 li r3,0
a4: 48 00 00 01 bl a4 <.audit_classes_init+0xa4>
a4: R_PPC64_REL24 .audit_register_class
a8: 60 00 00 00 nop
ac: 38 9f 00 c4 addi r4,r31,196
b0: 38 60 00 02 li r3,2
b4: 48 00 00 01 bl b4 <.audit_classes_init+0xb4>
b4: R_PPC64_REL24 .audit_register_class
b8: 60 00 00 00 nop
bc: 38 9f 01 04 addi r4,r31,260
c0: 38 60 00 08 li r3,8
c4: 48 00 00 01 bl c4 <.audit_classes_init+0xc4>
c4: R_PPC64_REL24 .audit_register_class
c8: 60 00 00 00 nop
cc: 38 60 00 00 li r3,0
d0: 38 21 00 80 addi r1,r1,128
d4: e8 01 00 10 ld r0,16(r1)
d8: eb e1 ff f8 ld r31,-8(r1)
dc: 7c 08 03 a6 mtlr r0
e0: 4e 80 00 20 blr
^ permalink raw reply
* Re: [PATCH v3] powerpc/booke: Avoid link stack corruption in several places
From: Segher Boessenkool @ 2021-08-24 17:15 UTC (permalink / raw)
To: Christophe Leroy; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <e9fbc285eceb720e6c0e032ef47fe8b05f669b48.1629791751.git.christophe.leroy@csgroup.eu>
Hi!
On Tue, Aug 24, 2021 at 07:56:26AM +0000, Christophe Leroy wrote:
> Use bcl 20,31,+4 instead of bl in order to preserve link stack.
You use $+4 actually, which is clearer than .+4 or just +4 (and I am
surprised that the latter even works btw, I never knew :-) -- either
way it looks like a typo).
> - bl invstr /* Find our address */
> + bcl 20,31,$+4 /* Find our address */
> invstr: mflr r6 /* Make it accessible */
You can remove the label now. This isn't true in all cases, but here
you can (all times it is called "invstr").
> @@ -85,7 +85,7 @@ skpinv: addi r6,r6,1 /* Increment */
> addi r6,r6,10
> slw r6,r8,r6 /* convert to mask */
>
> - bl 1f /* Find our address */
> + bcl 20,31,$+4 /* Find our address */
> 1: mflr r7
Here, too.
> @@ -1045,7 +1045,7 @@ head_start_47x:
> sync
>
> /* Find the entry we are running from */
> - bl 1f
> + bcl 20,31,$+4
> 1: mflr r23
> tlbsx r23,0,r23
> tlbre r24,r23,0
And here.
> @@ -1132,7 +1132,7 @@ _GLOBAL(switch_to_as1)
> bne 1b
>
> /* Get the tlb entry used by the current running code */
> - bl 0f
> + bcl 20,31,$+4
> 0: mflr r4
> tlbsx 0,r4
> @@ -1166,7 +1166,7 @@ _GLOBAL(switch_to_as1)
> _GLOBAL(restore_to_as0)
> mflr r0
>
> - bl 0f
> + bcl 20,31,$+4
> 0: mflr r9
> addi r9,r9,1f - 0b
And these.
> --- a/arch/powerpc/mm/nohash/tlb_low.S
> +++ b/arch/powerpc/mm/nohash/tlb_low.S
> @@ -199,7 +199,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_476_DD2)
> * Touch enough instruction cache lines to ensure cache hits
> */
> 1: mflr r9
> - bl 2f
> + bcl 20,31,$+4
> 2: mflr r6
> li r7,32
> PPC_ICBT(0,R6,R7) /* touch next cache line */
> @@ -414,7 +414,7 @@ _GLOBAL(loadcam_multi)
> * Set up temporary TLB entry that is the same as what we're
> * running from, but in AS=1.
> */
> - bl 1f
> + bcl 20,31,$+4
> 1: mflr r6
> tlbsx 0,r8
> mfspr r6,SPRN_MAS1
And these too.
There does not see to be a warning for usused local labels, it would be
useful in this case :-)
Segher
^ permalink raw reply
* [GIT PULL] retire legacy WR sbc8548 and sbc8641 platforms
From: Paul Gortmaker @ 2021-08-24 17:42 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Scott Wood, Paul Mackerras, linuxppc-dev, linux-kernel
This is unchanged from the original wr_sbc-delete branch sent in January,
other than to add the Acks from Scott in July, and update the baseline.
Built with ppc64 defconfig and mpc85xx_cds_defconfig and mpc86xx_defconfig
just to make sure I didn't fat finger anything in the baseline update.
Original v1 text follows below, from:
https://lore.kernel.org/lkml/20210111082823.99562-1-paul.gortmaker@windriver.com
It would be nice to get this in and off our collective to-do list.
Thanks,
Paul.
---
In v2.6.27 (2008, 917f0af9e5a9) the sbc8260 support was implicitly
retired by not being carried forward through the ppc --> powerpc
device tree transition.
Then, in v3.6 (2012, b048b4e17cbb) we retired the support for the
sbc8560 boards.
Next, in v4.18 (2017, 3bc6cf5a86e5) we retired the support for the
2006 vintage sbc834x boards.
The sbc8548 and sbc8641d boards were maybe 1-2 years newer than the
sbc834x boards, but it is also 3+ years later, so it makes sense to
now retire them as well - which is what is done here.
These two remaining WR boards were based on the Freescale MPC8548-CDS
and the MPC8641D-HPCN reference board implementations. Having had the
chance to use these and many other Fsl ref boards, I know this: The
Freescale reference boards were typically produced in limited quantity
and primarily available to BSP developers and hardware designers, and
not likely to have found a 2nd life with hobbyists and/or collectors.
It was good to have that BSP code subjected to mainline review and
hence also widely available back in the day. But given the above, we
should probably also be giving serious consideration to retiring
additional similar age/type reference board platforms as well.
I've always felt it is important for us to be proactive in retiring
old code, since it has a genuine non-zero carrying cost, as described
in the 930d52c012b8 merge log. But for the here and now, we just
clean up the remaining BSP code that I had added for SBC platforms.
---
The following changes since commit e22ce8eb631bdc47a4a4ea7ecf4e4ba499db4f93:
Linux 5.14-rc7 (2021-08-22 14:24:56 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git wr_sbc-delete-v2
for you to fetch changes up to d44e2dc12ea2112e74cdd25090eeda2727ed09cc:
MAINTAINERS: update for Paul Gortmaker (2021-08-24 08:19:01 -0400)
----------------------------------------------------------------
Paul Gortmaker (3):
powerpc: retire sbc8548 board support
powerpc: retire sbc8641d board support
MAINTAINERS: update for Paul Gortmaker
MAINTAINERS | 1 -
arch/powerpc/boot/Makefile | 1 -
arch/powerpc/boot/dts/fsl/sbc8641d.dts | 176 -----------------
arch/powerpc/boot/dts/sbc8548-altflash.dts | 111 -----------
arch/powerpc/boot/dts/sbc8548-post.dtsi | 289 ----------------------------
arch/powerpc/boot/dts/sbc8548-pre.dtsi | 48 -----
arch/powerpc/boot/dts/sbc8548.dts | 106 ----------
arch/powerpc/boot/wrapper | 2 +-
arch/powerpc/configs/85xx/sbc8548_defconfig | 50 -----
arch/powerpc/configs/mpc85xx_base.config | 1 -
arch/powerpc/configs/mpc86xx_base.config | 1 -
arch/powerpc/configs/ppc6xx_defconfig | 1 -
arch/powerpc/platforms/85xx/Kconfig | 6 -
arch/powerpc/platforms/85xx/Makefile | 1 -
arch/powerpc/platforms/85xx/sbc8548.c | 134 -------------
arch/powerpc/platforms/86xx/Kconfig | 8 +-
arch/powerpc/platforms/86xx/Makefile | 1 -
arch/powerpc/platforms/86xx/sbc8641d.c | 87 ---------
18 files changed, 2 insertions(+), 1022 deletions(-)
delete mode 100644 arch/powerpc/boot/dts/fsl/sbc8641d.dts
delete mode 100644 arch/powerpc/boot/dts/sbc8548-altflash.dts
delete mode 100644 arch/powerpc/boot/dts/sbc8548-post.dtsi
delete mode 100644 arch/powerpc/boot/dts/sbc8548-pre.dtsi
delete mode 100644 arch/powerpc/boot/dts/sbc8548.dts
delete mode 100644 arch/powerpc/configs/85xx/sbc8548_defconfig
delete mode 100644 arch/powerpc/platforms/85xx/sbc8548.c
delete mode 100644 arch/powerpc/platforms/86xx/sbc8641d.c
^ permalink raw reply
* Re: [PATCH v2 1/3] powerpc/pseries: Parse control memory access error
From: Segher Boessenkool @ 2021-08-24 21:24 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, mikey, Ganesh Goudar, mahesh, npiggin
In-Reply-To: <87eeajcpmq.fsf@mpe.ellerman.id.au>
On Tue, Aug 24, 2021 at 04:39:57PM +1000, Michael Ellerman wrote:
> > + case MC_ERROR_CTRL_MEM_ACCESS_PTABLE_WALK:
> > + mce_err.u.ra_error_type =
> > + MCE_RA_ERROR_PAGE_TABLE_WALK_LOAD_STORE_FOREIGN;
>
> That name is ridiculously long, but I guess that's not your fault :)
> We can fix it up in a later patch.
It also has surprisingly little information content for the 47 chars
length it has :-) What does this even mean?!
Segher
^ permalink raw reply
* Re: [PATCH v2 RESEND] powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC
From: Paul Moore @ 2021-08-24 23:01 UTC (permalink / raw)
To: Christophe Leroy
Cc: linux-kernel, Eric Paris, linux-audit, Paul Mackerras,
linuxppc-dev
In-Reply-To: <5a2692b6-5077-21b4-8ebf-73b1c2b83a40@csgroup.eu>
On Tue, Aug 24, 2021 at 1:11 PM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
> Le 24/08/2021 à 16:47, Paul Moore a écrit :
> > On Tue, Aug 24, 2021 at 9:36 AM Christophe Leroy
> > <christophe.leroy@csgroup.eu> wrote:
> >>
> >> Commit e65e1fc2d24b ("[PATCH] syscall class hookup for all normal
> >> targets") added generic support for AUDIT but that didn't include
> >> support for bi-arch like powerpc.
> >>
> >> Commit 4b58841149dc ("audit: Add generic compat syscall support")
> >> added generic support for bi-arch.
> >>
> >> Convert powerpc to that bi-arch generic audit support.
> >>
> >> Cc: Paul Moore <paul@paul-moore.com>
> >> Cc: Eric Paris <eparis@redhat.com>
> >> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> >> ---
> >> Resending v2 with Audit people in Cc
> >>
> >> v2:
> >> - Missing 'git add' for arch/powerpc/include/asm/unistd32.h
> >> - Finalised commit description
> >> ---
> >> arch/powerpc/Kconfig | 5 +-
> >> arch/powerpc/include/asm/unistd32.h | 7 +++
> >> arch/powerpc/kernel/Makefile | 3 --
> >> arch/powerpc/kernel/audit.c | 84 -----------------------------
> >> arch/powerpc/kernel/compat_audit.c | 44 ---------------
> >> 5 files changed, 8 insertions(+), 135 deletions(-)
> >> create mode 100644 arch/powerpc/include/asm/unistd32.h
> >> delete mode 100644 arch/powerpc/kernel/audit.c
> >> delete mode 100644 arch/powerpc/kernel/compat_audit.c
> >
> > Can you explain, in detail please, the testing you have done to verify
> > this patch?
> >
>
> I built ppc64_defconfig and checked that the generated code is functionnaly equivalent.
>
> ppc32_classify_syscall() is exactly the same as audit_classify_compat_syscall() except that the
> later takes the syscall as second argument (ie in r4) whereas the former takes it as first argument
> (ie in r3).
>
> audit_classify_arch() and powerpc audit_classify_syscall() are slightly different between the
> powerpc version and the generic version because the powerpc version checks whether it is
> AUDIT_ARCH_PPC or not (ie value 20), while the generic one checks whether it has bit
> __AUDIT_ARCH_64BIT set or not (__AUDIT_ARCH_64BIT is the sign bit of a word), but taking into
> account that the abi is either AUDIT_ARCH_PPC, AUDIT_ARCH_PPC64 or AUDIT_ARCH_PPC64LE, the result is
> the same.
>
> If you are asking I guess you saw something wrong ?
I was asking because I didn't see any mention of testing, and when you
are enabling something significant like this it is nice to see that it
has been verified to work :)
While binary dumps and comparisons are nice, it is always good to see
verification from a test suite. I don't have access to the necessary
hardware to test this, but could you verify that the audit-testsuite
passes on your test system with your patches applied?
* https://github.com/linux-audit/audit-testsuite
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH] arch: vdso: remove if-conditionals of $(c-gettimeofday-y)
From: Palmer Dabbelt @ 2021-08-25 3:49 UTC (permalink / raw)
To: masahiroy
Cc: tsbogend, masahiroy, linuxppc-dev, linux-kernel, linux-mips,
Paul Walmsley, aou, paulus, luto, catalin.marinas, linux, tglx,
vincenzo.frascino, will, linux-riscv, linux-arm-kernel
In-Reply-To: <20210731055733.12332-1-masahiroy@kernel.org>
On Fri, 30 Jul 2021 22:57:33 PDT (-0700), masahiroy@kernel.org wrote:
> arm, arm64, mips, powerpc always select GENERIC_GETTIMEOFDAY, hence
> $(gettimeofday-y) never becomes empty.
>
> riscv conditionally selects GENERIC_GETTIMEOFDAY when MMU=y && 64BIT=y,
> but arch/riscv/kernel/vdso/vgettimeofday.o is built only under that
> condition. So, you can always define CFLAGS_vgettimeofday.o
>
> Remove all the meaningless conditionals.
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> ---
>
> arch/riscv/kernel/vdso/Makefile | 5 +----
Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
^ permalink raw reply
* [PATCH] powerpc/doc: Fix htmldocs errors
From: Aneesh Kumar K.V @ 2021-08-25 4:24 UTC (permalink / raw)
To: linuxppc-dev, mpe; +Cc: Aneesh Kumar K.V, Stephen Rothwell, Jonathan Corbet
Fix make htmldocs related errors with the newly added associativity.rst
doc file.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
Documentation/powerpc/associativity.rst | 29 +++++++++++++------------
Documentation/powerpc/index.rst | 1 +
2 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/Documentation/powerpc/associativity.rst b/Documentation/powerpc/associativity.rst
index 07e7dd3d6c87..4d01c7368561 100644
--- a/Documentation/powerpc/associativity.rst
+++ b/Documentation/powerpc/associativity.rst
@@ -1,6 +1,6 @@
============================
NUMA resource associativity
-=============================
+============================
Associativity represents the groupings of the various platform resources into
domains of substantially similar mean performance relative to resources outside
@@ -20,11 +20,11 @@ A value of 1 indicates the usage of Form 1 associativity. For Form 2 associativi
bit 2 of byte 5 in the "ibm,architecture-vec-5" property is used.
Form 0
------
+------
Form 0 associativity supports only two NUMA distances (LOCAL and REMOTE).
Form 1
------
+------
With Form 1 a combination of ibm,associativity-reference-points, and ibm,associativity
device tree properties are used to determine the NUMA distance between resource groups/domains.
@@ -78,17 +78,18 @@ numa-lookup-index-table.
For ex:
ibm,numa-lookup-index-table = <3 0 8 40>;
-ibm,numa-distace-table = <9>, /bits/ 8 < 10 20 80
- 20 10 160
- 80 160 10>;
- | 0 8 40
---|------------
- |
-0 | 10 20 80
- |
-8 | 20 10 160
- |
-40| 80 160 10
+ibm,numa-distace-table = <9>, /bits/ 8 < 10 20 80 20 10 160 80 160 10>;
+
+::
+
+ | 0 8 40
+ --|------------
+ |
+ 0 | 10 20 80
+ |
+ 8 | 20 10 160
+ |
+ 40| 80 160 10
A possible "ibm,associativity" property for resources in node 0, 8 and 40
diff --git a/Documentation/powerpc/index.rst b/Documentation/powerpc/index.rst
index bf5f1a2bdbdf..0f7d3c495693 100644
--- a/Documentation/powerpc/index.rst
+++ b/Documentation/powerpc/index.rst
@@ -7,6 +7,7 @@ powerpc
.. toctree::
:maxdepth: 1
+ associativity
booting
bootwrapper
cpu_families
--
2.31.1
^ permalink raw reply related
* Re: [PATCH 2/3] trace: refactor TRACE_IRQFLAGS_SUPPORT in Kconfig
From: Palmer Dabbelt @ 2021-08-25 3:49 UTC (permalink / raw)
To: masahiroy
Cc: mark.rutland, dalias, linux-sh, peterz, catalin.marinas,
linus.walleij, viresh.kumar, linux-kernel, James.Bottomley,
jcmvbkbc, guoren, linux-csky, hpa, sparclinux, linux-riscv,
deanbo422, will, ardb, paulus, anton.ivanov, jonas, linux-s390,
gor, ysato, krzysztof.kozlowski, yifeifz2, richard, masahiroy,
x86, linux, ley.foon.tan, borntraeger, mingo, geert, linux-parisc,
samitolvanen, u.kleine-koenig, shorne, linux-snps-arc, jdike,
linux-xtensa, aou, keescook, Arnd Bergmann, anshuman.khandual,
hca, linux-um, rostedt, stefan.kristiansson, openrisc, bp,
green.hu, Paul Walmsley, tglx, linux-arm-kernel, andreyknvl,
chris, monstr, tsbogend, bcain, nickhu, vgupta, npiggin,
linux-mips, davem, frederic, linux-hexagon, colin.king, akpm,
linuxppc-dev, deller, rppt
In-Reply-To: <20210731052233.4703-2-masahiroy@kernel.org>
On Fri, 30 Jul 2021 22:22:32 PDT (-0700), masahiroy@kernel.org wrote:
> Make architectures select TRACE_IRQFLAGS_SUPPORT instead of
> having many defines.
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> ---
>
> arch/riscv/Kconfig | 4 +---
Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
Thanks!
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc: Define and use MSR_RI only on non booke/40x
From: Michael Ellerman @ 2021-08-25 4:54 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras, npiggin
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <627ead32d40c840f9e8a329b60647b649eceb2aa.1629707037.git.christophe.leroy@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> 40x and BOOKE don't have MSR_RI.
>
> Define MSR_RI only for platforms where it exists. For the other ones,
> defines it as BUILD_BUG for C and do not define it for ASM.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> v3: Fixes kvm_emul.S and include <linux/bug.h> in <asm/reg.h>
> ---
> arch/powerpc/include/asm/reg.h | 5 +++++
> arch/powerpc/include/asm/reg_booke.h | 6 +++---
> arch/powerpc/kernel/head_32.h | 4 ++++
> arch/powerpc/kernel/kvm_emul.S | 13 +++++++++++++
> arch/powerpc/kernel/process.c | 2 +-
> arch/powerpc/lib/sstep.c | 2 +-
> 6 files changed, 27 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
> index be85cf156a1f..b270b570fb51 100644
> --- a/arch/powerpc/include/asm/reg.h
> +++ b/arch/powerpc/include/asm/reg.h
> @@ -109,7 +109,12 @@
> #ifndef MSR_PMM
> #define MSR_PMM __MASK(MSR_PMM_LG) /* Performance monitor */
> #endif
> +#if !defined(CONFIG_BOOKE) && !defined(CONFIG_40x)
> #define MSR_RI __MASK(MSR_RI_LG) /* Recoverable Exception */
This breaks 64-bit BookE, which is using MSR_RI in bookehv_interrupts.S.
eg. ppc64_book3e_allmodconfig gives:
arch/powerpc/kvm/bookehv_interrupts.S: Assembler messages:
arch/powerpc/kvm/bookehv_interrupts.S:221: Error: invalid operands (*ABS* and *UND* sections) for `|'
etc.
ISA v2.07B says MSR_RI is Book3S only, but looking at the e500mc manual
it does have bit 62 defined as RI.
I can fix it with:
+#if !(defined(CONFIG_BOOKE) && !defined(CONFIG_PPC_BOOK3E)) && !defined(CONFIG_40x)
#define MSR_RI __MASK(MSR_RI_LG) /* Recoverable Exception */
But that's getting really ugly, and we'd have to repeat it elsewhere.
I think we need a kconfig symbol that captures which platforms should
use MSR_RI, something like:
CONFIG PPC_MSR_RI
def_bool y
depends on !40x && (!BOOKE || PPC_BOOK3E)
Or maybe we should just define MSR_RI to 0 for platforms that don't use
it, to avoid so much ifdefing?
cheers
^ permalink raw reply
* Re: [PATCH v3 1/3] powerpc: Remove MSR_PR check in interrupt_exit_{user/kernel}_prepare()
From: Michael Ellerman @ 2021-08-25 5:27 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras, npiggin
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <385ead49ccb66a259b25fee3eebf0bd4094068f3.1629707037.git.christophe.leroy@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> In those hot functions that are called at every interrupt, any saved
> cycle is worth it.
>
> interrupt_exit_user_prepare() and interrupt_exit_kernel_prepare() are
> called from three places:
> - From entry_32.S
> - From interrupt_64.S
> - From interrupt_exit_user_restart() and interrupt_exit_kernel_restart()
>
> In entry_32.S, there are inambiguously called based on MSR_PR:
>
> interrupt_return:
> lwz r4,_MSR(r1)
> addi r3,r1,STACK_FRAME_OVERHEAD
> andi. r0,r4,MSR_PR
> beq .Lkernel_interrupt_return
> bl interrupt_exit_user_prepare
> ...
> .Lkernel_interrupt_return:
> bl interrupt_exit_kernel_prepare
>
> In interrupt_64.S, that's similar:
>
> interrupt_return_\srr\():
> ld r4,_MSR(r1)
> andi. r0,r4,MSR_PR
> beq interrupt_return_\srr\()_kernel
> interrupt_return_\srr\()_user: /* make backtraces match the _kernel variant */
> addi r3,r1,STACK_FRAME_OVERHEAD
> bl interrupt_exit_user_prepare
> ...
> interrupt_return_\srr\()_kernel:
> addi r3,r1,STACK_FRAME_OVERHEAD
> bl interrupt_exit_kernel_prepare
>
> In interrupt_exit_user_restart() and interrupt_exit_kernel_restart(),
> MSR_PR is verified respectively by BUG_ON(!user_mode(regs)) and
> BUG_ON(user_mode(regs)) prior to calling interrupt_exit_user_prepare()
> and interrupt_exit_kernel_prepare().
>
> The verification in interrupt_exit_user_prepare() and
> interrupt_exit_kernel_prepare() are therefore useless and can be removed.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> Acked-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/kernel/interrupt.c | 2 --
> 1 file changed, 2 deletions(-)
I'll pick this one up independent of the other two patches.
cheers
^ permalink raw reply
* Re: [PATCH v3 1/3] powerpc: Remove MSR_PR check in interrupt_exit_{user/kernel}_prepare()
From: Christophe Leroy @ 2021-08-25 5:45 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras, npiggin
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <87zgt6aybp.fsf@mpe.ellerman.id.au>
Le 25/08/2021 à 07:27, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>> In those hot functions that are called at every interrupt, any saved
>> cycle is worth it.
>>
>> interrupt_exit_user_prepare() and interrupt_exit_kernel_prepare() are
>> called from three places:
>> - From entry_32.S
>> - From interrupt_64.S
>> - From interrupt_exit_user_restart() and interrupt_exit_kernel_restart()
>>
>> In entry_32.S, there are inambiguously called based on MSR_PR:
>>
>> interrupt_return:
>> lwz r4,_MSR(r1)
>> addi r3,r1,STACK_FRAME_OVERHEAD
>> andi. r0,r4,MSR_PR
>> beq .Lkernel_interrupt_return
>> bl interrupt_exit_user_prepare
>> ...
>> .Lkernel_interrupt_return:
>> bl interrupt_exit_kernel_prepare
>>
>> In interrupt_64.S, that's similar:
>>
>> interrupt_return_\srr\():
>> ld r4,_MSR(r1)
>> andi. r0,r4,MSR_PR
>> beq interrupt_return_\srr\()_kernel
>> interrupt_return_\srr\()_user: /* make backtraces match the _kernel variant */
>> addi r3,r1,STACK_FRAME_OVERHEAD
>> bl interrupt_exit_user_prepare
>> ...
>> interrupt_return_\srr\()_kernel:
>> addi r3,r1,STACK_FRAME_OVERHEAD
>> bl interrupt_exit_kernel_prepare
>>
>> In interrupt_exit_user_restart() and interrupt_exit_kernel_restart(),
>> MSR_PR is verified respectively by BUG_ON(!user_mode(regs)) and
>> BUG_ON(user_mode(regs)) prior to calling interrupt_exit_user_prepare()
>> and interrupt_exit_kernel_prepare().
>>
>> The verification in interrupt_exit_user_prepare() and
>> interrupt_exit_kernel_prepare() are therefore useless and can be removed.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>> Acked-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/kernel/interrupt.c | 2 --
>> 1 file changed, 2 deletions(-)
>
> I'll pick this one up independent of the other two patches.
>
Second patch should be ok as well, no ?
Christophe
^ permalink raw reply
* [PATCH linux-next] drivers:smu: fix warning comparing pointer to 0
From: CGEL @ 2021-08-25 6:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jing Yangyang, Wang Wensheng, linux-kernel, Qinglang Miao,
linuxppc-dev, Zeal Robot
From: Jing Yangyang <jing.yangyang@zte.com.cn>
Fix the following coccicheck warning:
./drivers/macintosh/smu.c:1089: 11-12:
WARNING comparing pointer to 0, suggest !E
./drivers/macintosh/smu.c:1256:11-12:
WARNING comparing pointer to 0
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Jing Yangyang <jing.yangyang@zte.com.cn>
---
drivers/macintosh/smu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c
index 94fb63a..6cd0fef 100644
--- a/drivers/macintosh/smu.c
+++ b/drivers/macintosh/smu.c
@@ -1086,7 +1086,7 @@ static int smu_open(struct inode *inode, struct file *file)
unsigned long flags;
pp = kzalloc(sizeof(struct smu_private), GFP_KERNEL);
- if (pp == 0)
+ if (!pp)
return -ENOMEM;
spin_lock_init(&pp->lock);
pp->mode = smu_file_commands;
@@ -1253,7 +1253,7 @@ static __poll_t smu_fpoll(struct file *file, poll_table *wait)
__poll_t mask = 0;
unsigned long flags;
- if (pp == 0)
+ if (!pp)
return 0;
if (pp->mode == smu_file_commands) {
@@ -1276,7 +1276,7 @@ static int smu_release(struct inode *inode, struct file *file)
unsigned long flags;
unsigned int busy;
- if (pp == 0)
+ if (!pp)
return 0;
file->private_data = NULL;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v3 3/3] powerpc: Define and use MSR_RI only on non booke/40x
From: Christophe Leroy @ 2021-08-25 6:21 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras, npiggin
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <8735qyceev.fsf@mpe.ellerman.id.au>
Le 25/08/2021 à 06:54, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>> 40x and BOOKE don't have MSR_RI.
>>
>> Define MSR_RI only for platforms where it exists. For the other ones,
>> defines it as BUILD_BUG for C and do not define it for ASM.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>> ---
>> v3: Fixes kvm_emul.S and include <linux/bug.h> in <asm/reg.h>
>> ---
>> arch/powerpc/include/asm/reg.h | 5 +++++
>> arch/powerpc/include/asm/reg_booke.h | 6 +++---
>> arch/powerpc/kernel/head_32.h | 4 ++++
>> arch/powerpc/kernel/kvm_emul.S | 13 +++++++++++++
>> arch/powerpc/kernel/process.c | 2 +-
>> arch/powerpc/lib/sstep.c | 2 +-
>> 6 files changed, 27 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
>> index be85cf156a1f..b270b570fb51 100644
>> --- a/arch/powerpc/include/asm/reg.h
>> +++ b/arch/powerpc/include/asm/reg.h
>> @@ -109,7 +109,12 @@
>> #ifndef MSR_PMM
>> #define MSR_PMM __MASK(MSR_PMM_LG) /* Performance monitor */
>> #endif
>> +#if !defined(CONFIG_BOOKE) && !defined(CONFIG_40x)
>> #define MSR_RI __MASK(MSR_RI_LG) /* Recoverable Exception */
>
> This breaks 64-bit BookE, which is using MSR_RI in bookehv_interrupts.S.
>
> eg. ppc64_book3e_allmodconfig gives:
>
> arch/powerpc/kvm/bookehv_interrupts.S: Assembler messages:
> arch/powerpc/kvm/bookehv_interrupts.S:221: Error: invalid operands (*ABS* and *UND* sections) for `|'
> etc.
Oops, I missed that one. Should be easy to fix though as this file is dedicated to BOOKE we can just
remove MSR_RI from there.
>
> ISA v2.07B says MSR_RI is Book3S only, but looking at the e500mc manual
> it does have bit 62 defined as RI.
Oh !
So it makes the story different, even different than what we have in kernel today where everything
is more or less based on CONFIG_BOOKE or CONFIG_40x.
>
> I can fix it with:
>
> +#if !(defined(CONFIG_BOOKE) && !defined(CONFIG_PPC_BOOK3E)) && !defined(CONFIG_40x)
> #define MSR_RI __MASK(MSR_RI_LG) /* Recoverable Exception */
Why CONFIG_PPC_BOOK3E ? Shouldn't it be CONFIG_PPC_E500MC instead ?
>
>
> But that's getting really ugly, and we'd have to repeat it elsewhere.
>
> I think we need a kconfig symbol that captures which platforms should
> use MSR_RI, something like:
>
> CONFIG PPC_MSR_RI
> def_bool y
> depends on !40x && (!BOOKE || PPC_BOOK3E)
Yes I think that would be the best.
>
>
> Or maybe we should just define MSR_RI to 0 for platforms that don't use
> it, to avoid so much ifdefing?
>
Well, I tried to take the same approach as Ben in the original patch
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/61ad3646674e6bf541a8f7fb420cdf556d0b2152.camel@kernel.crashing.org/
but with a smoother approach for C files to avoid ifdefs there.
However for ASM it is different, we can't use tricks like BUILD_BUG. When we had MSR_RI completely
undefined on all booke it was rather easy, only a few #ifdefs needed in parts common to 3S and 3E.
But if we bring back MSR_RI on the e500mc that becomes more complex, and I agree with you too many
#ifdefs will be unfriendly.
On the other hand, setting MSR_RI to 0 will make all tests that check msr & MSR_RI fails during run.
Isn't it worse than what we have today ?
Maybe the way out is to carrefully look at the situations where e500mc uses MSR_RI, because
according to the reference manual it is limited to a few situations:
4.4 Recoverability and MSR[RI]
MSR[RI] is an MSR (and save/restore register) storage bit for compatibility with pre-Book E PowerPC
processors. When an interrupt occurs, the recoverable interrupt bit, MSR[RI] is unchanged by the
interrupt
mechanism when a new MSR is established; however, when a machine check, error report or NMI
interrupt occurs, MSR[RI] is cleared.
If used properly, RI determines whether an interrupt that is taken at the machine check interrupt
vector can
be safely returned from (that is, that architected state set by the interrupt mechanism has been
safely stored
by software). RI should be set by software when all MSR values are first established. When an interrupt
occurs that is taken at the machine check interrupt vector, software should set RI when it has
safely stored
MCSRR0 and MCSRR1. The associated MCSRR1 bit should be checked to determine whether the
interrupt occurred when another machine check interrupt was being processed and before state was
successfully saved. If MCSRR1[RI] is set, it is safe to return when processing is complete.
So, let's think about it.
By the way patch 2 of the series could go now, it doesn't introduces anything new, it only cleans up
things a bit.
Christophe
^ permalink raw reply
* [PATCH linux-next] powerpc:security: replace DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE
From: CGEL @ 2021-08-25 6:40 UTC (permalink / raw)
To: Michael Ellerman
Cc: Jing Yangyang, Alexey Kardashevskiy, Zeal Robot, Nicholas Piggin,
linux-kernel, Li Huafei, Paul Mackerras, linuxppc-dev
From: Jing Yangyang <jing.yangyang@zte.com.cn>
Fix the following coccicheck warning:
./arch/powerpc/kernel/security.c:807:0-23: WARNING:
fops_entry_flush should be defined with DEFINE_DEBUGFS_ATTRIBUTE
./arch/powerpc/kernel/security.c:781:0-23:WARNING:
fops_rfi_flush should be defined with DEFINE_DEBUGFS_ATTRIBUTE
./arch/powerpc/kernel/security.c:833:0-23:WARNING:
fops_uaccess_flush should be defined with DEFINE_DEBUGFS_ATTRIBUTE
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Jing Yangyang <jing.yangyang@zte.com.cn>
---
arch/powerpc/kernel/security.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index 1a99849..cf8ce24 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -778,7 +778,7 @@ static int rfi_flush_get(void *data, u64 *val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(fops_rfi_flush, rfi_flush_get, rfi_flush_set, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(fops_rfi_flush, rfi_flush_get, rfi_flush_set, "%llu\n");
static int entry_flush_set(void *data, u64 val)
{
@@ -804,7 +804,7 @@ static int entry_flush_get(void *data, u64 *val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(fops_entry_flush, entry_flush_get, entry_flush_set, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(fops_entry_flush, entry_flush_get, entry_flush_set, "%llu\n");
static int uaccess_flush_set(void *data, u64 val)
{
@@ -830,7 +830,7 @@ static int uaccess_flush_get(void *data, u64 *val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(fops_uaccess_flush, uaccess_flush_get, uaccess_flush_set, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(fops_uaccess_flush, uaccess_flush_get, uaccess_flush_set, "%llu\n");
static __init int rfi_flush_debugfs_init(void)
{
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH linux-next] powerpc:security: replace DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE
From: Christophe Leroy @ 2021-08-25 6:42 UTC (permalink / raw)
To: CGEL, Michael Ellerman
Cc: Jing Yangyang, Alexey Kardashevskiy, Zeal Robot, linux-kernel,
Li Huafei, Paul Mackerras, Nicholas Piggin, linuxppc-dev
In-Reply-To: <20210825064016.70421-1-deng.changcheng@zte.com.cn>
Hi,
Le 25/08/2021 à 08:40, CGEL a écrit :
> From: Jing Yangyang <jing.yangyang@zte.com.cn>
>
> Fix the following coccicheck warning:
> ./arch/powerpc/kernel/security.c:807:0-23: WARNING:
> fops_entry_flush should be defined with DEFINE_DEBUGFS_ATTRIBUTE
> ./arch/powerpc/kernel/security.c:781:0-23:WARNING:
> fops_rfi_flush should be defined with DEFINE_DEBUGFS_ATTRIBUTE
> ./arch/powerpc/kernel/security.c:833:0-23:WARNING:
> fops_uaccess_flush should be defined with DEFINE_DEBUGFS_ATTRIBUTE
Can you give a few more details why the suggestion from coccicheck is a good suggestion ?
Thanks
Christophe
>
> Reported-by: Zeal Robot <zealci@zte.com.cn>
> Signed-off-by: Jing Yangyang <jing.yangyang@zte.com.cn>
> ---
> arch/powerpc/kernel/security.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
> index 1a99849..cf8ce24 100644
> --- a/arch/powerpc/kernel/security.c
> +++ b/arch/powerpc/kernel/security.c
> @@ -778,7 +778,7 @@ static int rfi_flush_get(void *data, u64 *val)
> return 0;
> }
>
> -DEFINE_SIMPLE_ATTRIBUTE(fops_rfi_flush, rfi_flush_get, rfi_flush_set, "%llu\n");
> +DEFINE_DEBUGFS_ATTRIBUTE(fops_rfi_flush, rfi_flush_get, rfi_flush_set, "%llu\n");
>
> static int entry_flush_set(void *data, u64 val)
> {
> @@ -804,7 +804,7 @@ static int entry_flush_get(void *data, u64 *val)
> return 0;
> }
>
> -DEFINE_SIMPLE_ATTRIBUTE(fops_entry_flush, entry_flush_get, entry_flush_set, "%llu\n");
> +DEFINE_DEBUGFS_ATTRIBUTE(fops_entry_flush, entry_flush_get, entry_flush_set, "%llu\n");
>
> static int uaccess_flush_set(void *data, u64 val)
> {
> @@ -830,7 +830,7 @@ static int uaccess_flush_get(void *data, u64 *val)
> return 0;
> }
>
> -DEFINE_SIMPLE_ATTRIBUTE(fops_uaccess_flush, uaccess_flush_get, uaccess_flush_set, "%llu\n");
> +DEFINE_DEBUGFS_ATTRIBUTE(fops_uaccess_flush, uaccess_flush_get, uaccess_flush_set, "%llu\n");
>
> static __init int rfi_flush_debugfs_init(void)
> {
>
^ permalink raw reply
* [PATCH linux-next] power:pkeys: fix bugon.cocci warnings
From: CGEL @ 2021-08-25 6:42 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Sandipan Das, linuxppc-dev, linux-kernel
Cc: Zeal Robot, Jing Yangyang
From: Jing Yangyang <jing.yangyang@zte.com.cn>
Use BUG_ON instead of a if condition followed by BUG.
./arch/powerpc/include/asm/book3s/64/pkeys.h:21:2-5:WARNING
Use BUG_ON instead of if condition followed by BUG.
./arch/powerpc/include/asm/book3s/64/pkeys.h:14:2-5:WARNING
Use BUG_ON instead of if condition followed by BUG.
Generated by: scripts/coccinelle/misc/bugon.cocci
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Jing Yangyang <jing.yangyang@zte.com.cn>
---
arch/powerpc/include/asm/book3s/64/pkeys.h | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/pkeys.h b/arch/powerpc/include/asm/book3s/64/pkeys.h
index 5b17813..5f74f0c 100644
--- a/arch/powerpc/include/asm/book3s/64/pkeys.h
+++ b/arch/powerpc/include/asm/book3s/64/pkeys.h
@@ -10,15 +10,13 @@ static inline u64 vmflag_to_pte_pkey_bits(u64 vm_flags)
if (!mmu_has_feature(MMU_FTR_PKEY))
return 0x0UL;
- if (radix_enabled())
- BUG();
+ BUG_ON(radix_enabled());
return hash__vmflag_to_pte_pkey_bits(vm_flags);
}
static inline u16 pte_to_pkey_bits(u64 pteflags)
{
- if (radix_enabled())
- BUG();
+ BUG_ON(radix_enabled());
return hash__pte_to_pkey_bits(pteflags);
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v3 1/3] powerpc: Remove MSR_PR check in interrupt_exit_{user/kernel}_prepare()
From: Michael Ellerman @ 2021-08-25 6:56 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras, npiggin
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <f5f598a5-3830-ee21-aff5-cba06deeb959@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 25/08/2021 à 07:27, Michael Ellerman a écrit :
>> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>>> In those hot functions that are called at every interrupt, any saved
>>> cycle is worth it.
>>>
>>> interrupt_exit_user_prepare() and interrupt_exit_kernel_prepare() are
>>> called from three places:
>>> - From entry_32.S
>>> - From interrupt_64.S
>>> - From interrupt_exit_user_restart() and interrupt_exit_kernel_restart()
>>>
>>> In entry_32.S, there are inambiguously called based on MSR_PR:
>>>
>>> interrupt_return:
>>> lwz r4,_MSR(r1)
>>> addi r3,r1,STACK_FRAME_OVERHEAD
>>> andi. r0,r4,MSR_PR
>>> beq .Lkernel_interrupt_return
>>> bl interrupt_exit_user_prepare
>>> ...
>>> .Lkernel_interrupt_return:
>>> bl interrupt_exit_kernel_prepare
>>>
>>> In interrupt_64.S, that's similar:
>>>
>>> interrupt_return_\srr\():
>>> ld r4,_MSR(r1)
>>> andi. r0,r4,MSR_PR
>>> beq interrupt_return_\srr\()_kernel
>>> interrupt_return_\srr\()_user: /* make backtraces match the _kernel variant */
>>> addi r3,r1,STACK_FRAME_OVERHEAD
>>> bl interrupt_exit_user_prepare
>>> ...
>>> interrupt_return_\srr\()_kernel:
>>> addi r3,r1,STACK_FRAME_OVERHEAD
>>> bl interrupt_exit_kernel_prepare
>>>
>>> In interrupt_exit_user_restart() and interrupt_exit_kernel_restart(),
>>> MSR_PR is verified respectively by BUG_ON(!user_mode(regs)) and
>>> BUG_ON(user_mode(regs)) prior to calling interrupt_exit_user_prepare()
>>> and interrupt_exit_kernel_prepare().
>>>
>>> The verification in interrupt_exit_user_prepare() and
>>> interrupt_exit_kernel_prepare() are therefore useless and can be removed.
>>>
>>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>>> Acked-by: Nicholas Piggin <npiggin@gmail.com>
>>> ---
>>> arch/powerpc/kernel/interrupt.c | 2 --
>>> 1 file changed, 2 deletions(-)
>>
>> I'll pick this one up independent of the other two patches.
>
> Second patch should be ok as well, no ?
Yeah I guess.
I'm not sure if we'll want to keep cpu_has_msr_ri() if we have a
CONFIG_PPC_MSR_RI, but that's a pretty minor detail.
So yeah I'll take patch 2 as well.
cheers
^ permalink raw reply
* [PATCH] ASoC: imx-rpmsg: change dev_err to dev_err_probe for -EPROBE_DEFER
From: Shengjiu Wang @ 2021-08-25 7:14 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, broonie, perex, tiwai,
alsa-devel
Cc: linuxppc-dev, linux-kernel
Change dev_err to dev_err_probe for no need print error message
when defer probe happens.
Fixes: 39f8405c3e50 ("ASoC: imx-rpmsg: Add machine driver for audio base on rpmsg")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
sound/soc/fsl/imx-rpmsg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/imx-rpmsg.c b/sound/soc/fsl/imx-rpmsg.c
index f0cae8c59d54..f96fe4ff8425 100644
--- a/sound/soc/fsl/imx-rpmsg.c
+++ b/sound/soc/fsl/imx-rpmsg.c
@@ -125,7 +125,7 @@ static int imx_rpmsg_probe(struct platform_device *pdev)
snd_soc_card_set_drvdata(&data->card, data);
ret = devm_snd_soc_register_card(&pdev->dev, &data->card);
if (ret) {
- dev_err(&pdev->dev, "snd_soc_register_card failed (%d)\n", ret);
+ dev_err_probe(&pdev->dev, ret, "snd_soc_register_card failed\n");
goto fail;
}
--
2.17.1
^ permalink raw reply related
* [PATCH v4 1/2] powerpc/perf: Use PVR rather than oprofile field to determine CPU version
From: Christophe Leroy @ 2021-08-25 7:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
From: Rashmica Gupta <rashmica.g@gmail.com>
Currently the perf CPU backend drivers detect what CPU they're on using
cur_cpu_spec->oprofile_cpu_type.
Although that works, it's a bit crufty to be using oprofile related fields,
especially seeing as oprofile is more or less unused these days.
It also means perf is reliant on the fragile logic in setup_cpu_spec()
which detects when we're using a logical PVR and copies back the PMU
related fields from the raw CPU entry. So lets check the PVR directly.
Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
[chleroy: Added power10 and fixed checkpatch issues]
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Reviewed-and-tested-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Reviewed-and-tested-By: Kajol Jain <kjain@linux.ibm.com> [For 24x7 side changes]
---
v4:
- No change to the series
- Added additional Reviewed-by/Tested-by.
- Rebased
- Resending to get some CI result this time
---
arch/powerpc/perf/e500-pmu.c | 9 +++++----
arch/powerpc/perf/e6500-pmu.c | 5 +++--
arch/powerpc/perf/hv-24x7.c | 6 +++---
arch/powerpc/perf/mpc7450-pmu.c | 5 +++--
arch/powerpc/perf/power10-pmu.c | 6 ++----
arch/powerpc/perf/power5+-pmu.c | 6 +++---
arch/powerpc/perf/power5-pmu.c | 5 +++--
arch/powerpc/perf/power6-pmu.c | 5 +++--
arch/powerpc/perf/power7-pmu.c | 7 ++++---
arch/powerpc/perf/power8-pmu.c | 5 +++--
arch/powerpc/perf/power9-pmu.c | 4 +---
arch/powerpc/perf/ppc970-pmu.c | 7 ++++---
12 files changed, 37 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/perf/e500-pmu.c b/arch/powerpc/perf/e500-pmu.c
index a59c33bed32a..e3e1a68eb1d5 100644
--- a/arch/powerpc/perf/e500-pmu.c
+++ b/arch/powerpc/perf/e500-pmu.c
@@ -118,12 +118,13 @@ static struct fsl_emb_pmu e500_pmu = {
static int init_e500_pmu(void)
{
- if (!cur_cpu_spec->oprofile_cpu_type)
- return -ENODEV;
+ unsigned int pvr = mfspr(SPRN_PVR);
- if (!strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/e500mc"))
+ /* ec500mc */
+ if (PVR_VER(pvr) == PVR_VER_E500MC || PVR_VER(pvr) == PVR_VER_E5500)
num_events = 256;
- else if (strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/e500"))
+ /* e500 */
+ else if (PVR_VER(pvr) != PVR_VER_E500V1 && PVR_VER(pvr) != PVR_VER_E500V2)
return -ENODEV;
return register_fsl_emb_pmu(&e500_pmu);
diff --git a/arch/powerpc/perf/e6500-pmu.c b/arch/powerpc/perf/e6500-pmu.c
index 44ad65da82ed..bd779a2338f8 100644
--- a/arch/powerpc/perf/e6500-pmu.c
+++ b/arch/powerpc/perf/e6500-pmu.c
@@ -107,8 +107,9 @@ static struct fsl_emb_pmu e6500_pmu = {
static int init_e6500_pmu(void)
{
- if (!cur_cpu_spec->oprofile_cpu_type ||
- strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/e6500"))
+ unsigned int pvr = mfspr(SPRN_PVR);
+
+ if (PVR_VER(pvr) != PVR_VER_E6500)
return -ENODEV;
return register_fsl_emb_pmu(&e6500_pmu);
diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 1816f560a465..63e84075fd64 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -1718,16 +1718,16 @@ static int hv_24x7_init(void)
{
int r;
unsigned long hret;
+ unsigned int pvr = mfspr(SPRN_PVR);
struct hv_perf_caps caps;
if (!firmware_has_feature(FW_FEATURE_LPAR)) {
pr_debug("not a virtualized system, not enabling\n");
return -ENODEV;
- } else if (!cur_cpu_spec->oprofile_cpu_type)
- return -ENODEV;
+ }
/* POWER8 only supports v1, while POWER9 only supports v2. */
- if (!strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power8"))
+ if (PVR_VER(pvr) == PVR_POWER8)
interface_version = 1;
else {
interface_version = 2;
diff --git a/arch/powerpc/perf/mpc7450-pmu.c b/arch/powerpc/perf/mpc7450-pmu.c
index e39b15b79a83..552d51a925d3 100644
--- a/arch/powerpc/perf/mpc7450-pmu.c
+++ b/arch/powerpc/perf/mpc7450-pmu.c
@@ -417,8 +417,9 @@ struct power_pmu mpc7450_pmu = {
static int __init init_mpc7450_pmu(void)
{
- if (!cur_cpu_spec->oprofile_cpu_type ||
- strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/7450"))
+ unsigned int pvr = mfspr(SPRN_PVR);
+
+ if (PVR_VER(pvr) != PVR_7450)
return -ENODEV;
return register_power_pmu(&mpc7450_pmu);
diff --git a/arch/powerpc/perf/power10-pmu.c b/arch/powerpc/perf/power10-pmu.c
index f9d64c63bb4a..53b14deda088 100644
--- a/arch/powerpc/perf/power10-pmu.c
+++ b/arch/powerpc/perf/power10-pmu.c
@@ -579,12 +579,10 @@ int init_power10_pmu(void)
unsigned int pvr;
int rc;
- /* Comes from cpu_specs[] */
- if (!cur_cpu_spec->oprofile_cpu_type ||
- strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power10"))
+ pvr = mfspr(SPRN_PVR);
+ if (PVR_VER(pvr) != PVR_POWER10)
return -ENODEV;
- pvr = mfspr(SPRN_PVR);
/* Add the ppmu flag for power10 DD1 */
if ((PVR_CFG(pvr) == 1))
power10_pmu.flags |= PPMU_P10_DD1;
diff --git a/arch/powerpc/perf/power5+-pmu.c b/arch/powerpc/perf/power5+-pmu.c
index 18732267993a..a79eae40ef6d 100644
--- a/arch/powerpc/perf/power5+-pmu.c
+++ b/arch/powerpc/perf/power5+-pmu.c
@@ -679,9 +679,9 @@ static struct power_pmu power5p_pmu = {
int init_power5p_pmu(void)
{
- if (!cur_cpu_spec->oprofile_cpu_type ||
- (strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power5+")
- && strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power5++")))
+ unsigned int pvr = mfspr(SPRN_PVR);
+
+ if (PVR_VER(pvr) != PVR_POWER5p)
return -ENODEV;
return register_power_pmu(&power5p_pmu);
diff --git a/arch/powerpc/perf/power5-pmu.c b/arch/powerpc/perf/power5-pmu.c
index cb611c1e7abe..35a9d7f3b4b9 100644
--- a/arch/powerpc/perf/power5-pmu.c
+++ b/arch/powerpc/perf/power5-pmu.c
@@ -620,8 +620,9 @@ static struct power_pmu power5_pmu = {
int init_power5_pmu(void)
{
- if (!cur_cpu_spec->oprofile_cpu_type ||
- strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power5"))
+ unsigned int pvr = mfspr(SPRN_PVR);
+
+ if (PVR_VER(pvr) != PVR_POWER5)
return -ENODEV;
return register_power_pmu(&power5_pmu);
diff --git a/arch/powerpc/perf/power6-pmu.c b/arch/powerpc/perf/power6-pmu.c
index 69ef38216418..8aa220c712a7 100644
--- a/arch/powerpc/perf/power6-pmu.c
+++ b/arch/powerpc/perf/power6-pmu.c
@@ -541,8 +541,9 @@ static struct power_pmu power6_pmu = {
int init_power6_pmu(void)
{
- if (!cur_cpu_spec->oprofile_cpu_type ||
- strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power6"))
+ unsigned int pvr = mfspr(SPRN_PVR);
+
+ if (PVR_VER(pvr) != PVR_POWER6)
return -ENODEV;
return register_power_pmu(&power6_pmu);
diff --git a/arch/powerpc/perf/power7-pmu.c b/arch/powerpc/perf/power7-pmu.c
index 894c17f9a762..ca7373143b02 100644
--- a/arch/powerpc/perf/power7-pmu.c
+++ b/arch/powerpc/perf/power7-pmu.c
@@ -447,11 +447,12 @@ static struct power_pmu power7_pmu = {
int init_power7_pmu(void)
{
- if (!cur_cpu_spec->oprofile_cpu_type ||
- strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power7"))
+ unsigned int pvr = mfspr(SPRN_PVR);
+
+ if (PVR_VER(pvr) != PVR_POWER7 && PVR_VER(pvr) != PVR_POWER7p)
return -ENODEV;
- if (pvr_version_is(PVR_POWER7p))
+ if (PVR_VER(pvr) == PVR_POWER7p)
power7_pmu.flags |= PPMU_SIAR_VALID;
return register_power_pmu(&power7_pmu);
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index 5282e8415ddf..5a396ba8bf58 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -381,9 +381,10 @@ static struct power_pmu power8_pmu = {
int init_power8_pmu(void)
{
int rc;
+ unsigned int pvr = mfspr(SPRN_PVR);
- if (!cur_cpu_spec->oprofile_cpu_type ||
- strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power8"))
+ if (PVR_VER(pvr) != PVR_POWER8E && PVR_VER(pvr) != PVR_POWER8NVL &&
+ PVR_VER(pvr) != PVR_POWER8)
return -ENODEV;
rc = register_power_pmu(&power8_pmu);
diff --git a/arch/powerpc/perf/power9-pmu.c b/arch/powerpc/perf/power9-pmu.c
index ff3382140d7e..147767ca0039 100644
--- a/arch/powerpc/perf/power9-pmu.c
+++ b/arch/powerpc/perf/power9-pmu.c
@@ -457,9 +457,7 @@ int init_power9_pmu(void)
int rc = 0;
unsigned int pvr = mfspr(SPRN_PVR);
- /* Comes from cpu_specs[] */
- if (!cur_cpu_spec->oprofile_cpu_type ||
- strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power9"))
+ if (PVR_VER(pvr) != PVR_POWER9)
return -ENODEV;
/* Blacklist events */
diff --git a/arch/powerpc/perf/ppc970-pmu.c b/arch/powerpc/perf/ppc970-pmu.c
index 1f8263785286..39a0a4d7841c 100644
--- a/arch/powerpc/perf/ppc970-pmu.c
+++ b/arch/powerpc/perf/ppc970-pmu.c
@@ -491,9 +491,10 @@ static struct power_pmu ppc970_pmu = {
int init_ppc970_pmu(void)
{
- if (!cur_cpu_spec->oprofile_cpu_type ||
- (strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/970")
- && strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/970MP")))
+ unsigned int pvr = mfspr(SPRN_PVR);
+
+ if (PVR_VER(pvr) != PVR_970 && PVR_VER(pvr) != PVR_970MP &&
+ PVR_VER(pvr) != PVR_970FX && PVR_VER(pvr) != PVR_970GX)
return -ENODEV;
return register_power_pmu(&ppc970_pmu);
--
2.25.0
^ permalink raw reply related
* [PATCH v4 2/2] powerpc: Remove remaining parts of oprofile
From: Christophe Leroy @ 2021-08-25 7:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <8ea2d4065ec5a0137e5ad9b75773ed27c03bfc91.1629877436.git.christophe.leroy@csgroup.eu>
Commit 9850b6c69356 ("arch: powerpc: Remove oprofile") removed
oprofile.
Remove all remaining parts of it.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/powerpc/include/asm/cputable.h | 3 --
arch/powerpc/kernel/cputable.c | 66 +----------------------
arch/powerpc/kernel/dt_cpu_ftrs.c | 4 --
arch/powerpc/platforms/cell/spufs/spufs.h | 2 +-
4 files changed, 3 insertions(+), 72 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index e85c849214a2..850129d13d46 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -70,9 +70,6 @@ struct cpu_spec {
/* Used to restore cpu setup on secondary processors and at resume */
cpu_restore_t cpu_restore;
- /* Used by oprofile userspace to select the right counters */
- char *oprofile_cpu_type;
-
/* Name of processor class, for the ELF AT_PLATFORM entry */
char *platform;
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index ae0fdef0ac11..0fc812ac7519 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -149,7 +149,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.pmc_type = PPC_PMC_IBM,
.cpu_setup = __setup_cpu_ppc970,
.cpu_restore = __restore_cpu_ppc970,
- .oprofile_cpu_type = "ppc64/970",
.platform = "ppc970",
},
{ /* PPC970FX */
@@ -166,7 +165,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.pmc_type = PPC_PMC_IBM,
.cpu_setup = __setup_cpu_ppc970,
.cpu_restore = __restore_cpu_ppc970,
- .oprofile_cpu_type = "ppc64/970",
.platform = "ppc970",
},
{ /* PPC970MP DD1.0 - no DEEPNAP, use regular 970 init */
@@ -183,7 +181,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.pmc_type = PPC_PMC_IBM,
.cpu_setup = __setup_cpu_ppc970,
.cpu_restore = __restore_cpu_ppc970,
- .oprofile_cpu_type = "ppc64/970MP",
.platform = "ppc970",
},
{ /* PPC970MP */
@@ -200,7 +197,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.pmc_type = PPC_PMC_IBM,
.cpu_setup = __setup_cpu_ppc970MP,
.cpu_restore = __restore_cpu_ppc970,
- .oprofile_cpu_type = "ppc64/970MP",
.platform = "ppc970",
},
{ /* PPC970GX */
@@ -216,7 +212,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.num_pmcs = 8,
.pmc_type = PPC_PMC_IBM,
.cpu_setup = __setup_cpu_ppc970,
- .oprofile_cpu_type = "ppc64/970",
.platform = "ppc970",
},
{ /* Power5 GR */
@@ -230,7 +225,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize = 128,
.num_pmcs = 6,
.pmc_type = PPC_PMC_IBM,
- .oprofile_cpu_type = "ppc64/power5",
.platform = "power5",
},
{ /* Power5++ */
@@ -243,7 +237,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 6,
- .oprofile_cpu_type = "ppc64/power5++",
.platform = "power5+",
},
{ /* Power5 GS */
@@ -257,7 +250,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize = 128,
.num_pmcs = 6,
.pmc_type = PPC_PMC_IBM,
- .oprofile_cpu_type = "ppc64/power5+",
.platform = "power5+",
},
{ /* POWER6 in P5+ mode; 2.04-compliant processor */
@@ -269,7 +261,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.mmu_features = MMU_FTRS_POWER5,
.icache_bsize = 128,
.dcache_bsize = 128,
- .oprofile_cpu_type = "ppc64/ibm-compat-v1",
.platform = "power5+",
},
{ /* Power6 */
@@ -284,7 +275,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize = 128,
.num_pmcs = 6,
.pmc_type = PPC_PMC_IBM,
- .oprofile_cpu_type = "ppc64/power6",
.platform = "power6x",
},
{ /* 2.05-compliant processor, i.e. Power6 "architected" mode */
@@ -296,7 +286,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.mmu_features = MMU_FTRS_POWER6,
.icache_bsize = 128,
.dcache_bsize = 128,
- .oprofile_cpu_type = "ppc64/ibm-compat-v1",
.platform = "power6",
},
{ /* 2.06-compliant processor, i.e. Power7 "architected" mode */
@@ -309,7 +298,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.mmu_features = MMU_FTRS_POWER7,
.icache_bsize = 128,
.dcache_bsize = 128,
- .oprofile_cpu_type = "ppc64/ibm-compat-v1",
.cpu_setup = __setup_cpu_power7,
.cpu_restore = __restore_cpu_power7,
.machine_check_early = __machine_check_early_realmode_p7,
@@ -325,7 +313,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.mmu_features = MMU_FTRS_POWER8,
.icache_bsize = 128,
.dcache_bsize = 128,
- .oprofile_cpu_type = "ppc64/ibm-compat-v1",
.cpu_setup = __setup_cpu_power8,
.cpu_restore = __restore_cpu_power8,
.machine_check_early = __machine_check_early_realmode_p8,
@@ -341,7 +328,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.mmu_features = MMU_FTRS_POWER9,
.icache_bsize = 128,
.dcache_bsize = 128,
- .oprofile_cpu_type = "ppc64/ibm-compat-v1",
.cpu_setup = __setup_cpu_power9,
.cpu_restore = __restore_cpu_power9,
.platform = "power9",
@@ -356,7 +342,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.mmu_features = MMU_FTRS_POWER10,
.icache_bsize = 128,
.dcache_bsize = 128,
- .oprofile_cpu_type = "ppc64/ibm-compat-v1",
.cpu_setup = __setup_cpu_power10,
.cpu_restore = __restore_cpu_power10,
.platform = "power10",
@@ -373,7 +358,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize = 128,
.num_pmcs = 6,
.pmc_type = PPC_PMC_IBM,
- .oprofile_cpu_type = "ppc64/power7",
.cpu_setup = __setup_cpu_power7,
.cpu_restore = __restore_cpu_power7,
.machine_check_early = __machine_check_early_realmode_p7,
@@ -391,7 +375,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize = 128,
.num_pmcs = 6,
.pmc_type = PPC_PMC_IBM,
- .oprofile_cpu_type = "ppc64/power7",
.cpu_setup = __setup_cpu_power7,
.cpu_restore = __restore_cpu_power7,
.machine_check_early = __machine_check_early_realmode_p7,
@@ -409,7 +392,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize = 128,
.num_pmcs = 6,
.pmc_type = PPC_PMC_IBM,
- .oprofile_cpu_type = "ppc64/power8",
.cpu_setup = __setup_cpu_power8,
.cpu_restore = __restore_cpu_power8,
.machine_check_early = __machine_check_early_realmode_p8,
@@ -427,7 +409,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize = 128,
.num_pmcs = 6,
.pmc_type = PPC_PMC_IBM,
- .oprofile_cpu_type = "ppc64/power8",
.cpu_setup = __setup_cpu_power8,
.cpu_restore = __restore_cpu_power8,
.machine_check_early = __machine_check_early_realmode_p8,
@@ -445,7 +426,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize = 128,
.num_pmcs = 6,
.pmc_type = PPC_PMC_IBM,
- .oprofile_cpu_type = "ppc64/power8",
.cpu_setup = __setup_cpu_power8,
.cpu_restore = __restore_cpu_power8,
.machine_check_early = __machine_check_early_realmode_p8,
@@ -463,7 +443,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize = 128,
.num_pmcs = 6,
.pmc_type = PPC_PMC_IBM,
- .oprofile_cpu_type = "ppc64/power9",
.cpu_setup = __setup_cpu_power9,
.cpu_restore = __restore_cpu_power9,
.machine_check_early = __machine_check_early_realmode_p9,
@@ -481,7 +460,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize = 128,
.num_pmcs = 6,
.pmc_type = PPC_PMC_IBM,
- .oprofile_cpu_type = "ppc64/power9",
.cpu_setup = __setup_cpu_power9,
.cpu_restore = __restore_cpu_power9,
.machine_check_early = __machine_check_early_realmode_p9,
@@ -499,7 +477,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize = 128,
.num_pmcs = 6,
.pmc_type = PPC_PMC_IBM,
- .oprofile_cpu_type = "ppc64/power9",
.cpu_setup = __setup_cpu_power9,
.cpu_restore = __restore_cpu_power9,
.machine_check_early = __machine_check_early_realmode_p9,
@@ -517,7 +494,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize = 128,
.num_pmcs = 6,
.pmc_type = PPC_PMC_IBM,
- .oprofile_cpu_type = "ppc64/power10",
.cpu_setup = __setup_cpu_power10,
.cpu_restore = __restore_cpu_power10,
.machine_check_early = __machine_check_early_realmode_p10,
@@ -536,7 +512,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize = 128,
.num_pmcs = 4,
.pmc_type = PPC_PMC_IBM,
- .oprofile_cpu_type = "ppc64/cell-be",
.platform = "ppc-cell-be",
},
{ /* PA Semi PA6T */
@@ -552,7 +527,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.pmc_type = PPC_PMC_PA6T,
.cpu_setup = __setup_cpu_pa6t,
.cpu_restore = __restore_cpu_pa6t,
- .oprofile_cpu_type = "ppc64/pa6t",
.platform = "pa6t",
},
{ /* default match */
@@ -716,7 +690,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_setup = __setup_cpu_750,
.machine_check = machine_check_generic,
.platform = "ppc750",
- .oprofile_cpu_type = "ppc/750",
},
{ /* 745/755 */
.pvr_mask = 0xfffff000,
@@ -747,7 +720,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_setup = __setup_cpu_750,
.machine_check = machine_check_generic,
.platform = "ppc750",
- .oprofile_cpu_type = "ppc/750",
},
{ /* 750FX rev 2.0 must disable HID0[DPM] */
.pvr_mask = 0xffffffff,
@@ -763,7 +735,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_setup = __setup_cpu_750,
.machine_check = machine_check_generic,
.platform = "ppc750",
- .oprofile_cpu_type = "ppc/750",
},
{ /* 750FX (All revs except 2.0) */
.pvr_mask = 0xffff0000,
@@ -779,7 +750,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_setup = __setup_cpu_750fx,
.machine_check = machine_check_generic,
.platform = "ppc750",
- .oprofile_cpu_type = "ppc/750",
},
{ /* 750GX */
.pvr_mask = 0xffff0000,
@@ -795,7 +765,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_setup = __setup_cpu_750fx,
.machine_check = machine_check_generic,
.platform = "ppc750",
- .oprofile_cpu_type = "ppc/750",
},
{ /* 740/750 (L2CR bit need fixup for 740) */
.pvr_mask = 0xffff0000,
@@ -873,7 +842,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.num_pmcs = 6,
.pmc_type = PPC_PMC_G4,
.cpu_setup = __setup_cpu_745x,
- .oprofile_cpu_type = "ppc/7450",
.machine_check = machine_check_generic,
.platform = "ppc7450",
},
@@ -890,7 +858,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.num_pmcs = 6,
.pmc_type = PPC_PMC_G4,
.cpu_setup = __setup_cpu_745x,
- .oprofile_cpu_type = "ppc/7450",
.machine_check = machine_check_generic,
.platform = "ppc7450",
},
@@ -907,7 +874,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.num_pmcs = 6,
.pmc_type = PPC_PMC_G4,
.cpu_setup = __setup_cpu_745x,
- .oprofile_cpu_type = "ppc/7450",
.machine_check = machine_check_generic,
.platform = "ppc7450",
},
@@ -924,7 +890,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.num_pmcs = 6,
.pmc_type = PPC_PMC_G4,
.cpu_setup = __setup_cpu_745x,
- .oprofile_cpu_type = "ppc/7450",
.machine_check = machine_check_generic,
.platform = "ppc7450",
},
@@ -941,7 +906,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.num_pmcs = 6,
.pmc_type = PPC_PMC_G4,
.cpu_setup = __setup_cpu_745x,
- .oprofile_cpu_type = "ppc/7450",
.machine_check = machine_check_generic,
.platform = "ppc7450",
},
@@ -958,7 +922,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.num_pmcs = 6,
.pmc_type = PPC_PMC_G4,
.cpu_setup = __setup_cpu_745x,
- .oprofile_cpu_type = "ppc/7450",
.machine_check = machine_check_generic,
.platform = "ppc7450",
},
@@ -975,7 +938,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.num_pmcs = 6,
.pmc_type = PPC_PMC_G4,
.cpu_setup = __setup_cpu_745x,
- .oprofile_cpu_type = "ppc/7450",
.machine_check = machine_check_generic,
.platform = "ppc7450",
},
@@ -992,7 +954,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.num_pmcs = 6,
.pmc_type = PPC_PMC_G4,
.cpu_setup = __setup_cpu_745x,
- .oprofile_cpu_type = "ppc/7450",
.machine_check = machine_check_generic,
.platform = "ppc7450",
},
@@ -1008,7 +969,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.num_pmcs = 6,
.pmc_type = PPC_PMC_G4,
.cpu_setup = __setup_cpu_745x,
- .oprofile_cpu_type = "ppc/7450",
.machine_check = machine_check_generic,
.platform = "ppc7450",
},
@@ -1025,7 +985,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.num_pmcs = 6,
.pmc_type = PPC_PMC_G4,
.cpu_setup = __setup_cpu_745x,
- .oprofile_cpu_type = "ppc/7450",
.machine_check = machine_check_generic,
.platform = "ppc7450",
},
@@ -1042,7 +1001,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.num_pmcs = 6,
.pmc_type = PPC_PMC_G4,
.cpu_setup = __setup_cpu_745x,
- .oprofile_cpu_type = "ppc/7450",
.machine_check = machine_check_generic,
.platform = "ppc7450",
},
@@ -1154,7 +1112,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_setup = __setup_cpu_603,
.machine_check = machine_check_83xx,
.num_pmcs = 4,
- .oprofile_cpu_type = "ppc/e300",
.platform = "ppc603",
},
{ /* e300c4 (e300c1, plus one IU) */
@@ -1170,7 +1127,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_setup = __setup_cpu_603,
.machine_check = machine_check_83xx,
.num_pmcs = 4,
- .oprofile_cpu_type = "ppc/e300",
.platform = "ppc603",
},
#endif
@@ -1866,7 +1822,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.icache_bsize = 32,
.dcache_bsize = 32,
.num_pmcs = 4,
- .oprofile_cpu_type = "ppc/e500",
.cpu_setup = __setup_cpu_e500v1,
.machine_check = machine_check_e500,
.platform = "ppc8540",
@@ -1885,7 +1840,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.icache_bsize = 32,
.dcache_bsize = 32,
.num_pmcs = 4,
- .oprofile_cpu_type = "ppc/e500",
.cpu_setup = __setup_cpu_e500v2,
.machine_check = machine_check_e500,
.platform = "ppc8548",
@@ -1904,7 +1858,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.icache_bsize = 64,
.dcache_bsize = 64,
.num_pmcs = 4,
- .oprofile_cpu_type = "ppc/e500mc",
.cpu_setup = __setup_cpu_e500mc,
.machine_check = machine_check_e500mc,
.platform = "ppce500mc",
@@ -1925,7 +1878,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.icache_bsize = 64,
.dcache_bsize = 64,
.num_pmcs = 4,
- .oprofile_cpu_type = "ppc/e500mc",
.cpu_setup = __setup_cpu_e5500,
#ifndef CONFIG_PPC32
.cpu_restore = __restore_cpu_e5500,
@@ -1947,7 +1899,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.icache_bsize = 64,
.dcache_bsize = 64,
.num_pmcs = 6,
- .oprofile_cpu_type = "ppc/e6500",
.cpu_setup = __setup_cpu_e6500,
#ifndef CONFIG_PPC32
.cpu_restore = __restore_cpu_e6500,
@@ -2015,23 +1966,10 @@ static struct cpu_spec * __init setup_cpu_spec(unsigned long offset,
t->pmc_type = old.pmc_type;
/*
- * If we have passed through this logic once before and
- * have pulled the default case because the real PVR was
- * not found inside cpu_specs[], then we are possibly
- * running in compatibility mode. In that case, let the
- * oprofiler know which set of compatibility counters to
- * pull from by making sure the oprofile_cpu_type string
- * is set to that of compatibility mode. If the
- * oprofile_cpu_type already has a value, then we are
- * possibly overriding a real PVR with a logical one,
- * and, in that case, keep the current value for
- * oprofile_cpu_type. Futhermore, let's ensure that the
+ * Let's ensure that the
* fix for the PMAO bug is enabled on compatibility mode.
*/
- if (old.oprofile_cpu_type != NULL) {
- t->oprofile_cpu_type = old.oprofile_cpu_type;
- t->cpu_features |= old.cpu_features & CPU_FTR_PMAO_BUG;
- }
+ t->cpu_features |= old.cpu_features & CPU_FTR_PMAO_BUG;
}
*PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c b/arch/powerpc/kernel/dt_cpu_ftrs.c
index 358aee7c2d79..2bb1a5ca2cff 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -101,7 +101,6 @@ static struct cpu_spec __initdata base_cpu_spec = {
.dcache_bsize = 32, /* cache info init. */
.num_pmcs = 0,
.pmc_type = PPC_PMC_DEFAULT,
- .oprofile_cpu_type = NULL,
.cpu_setup = NULL,
.cpu_restore = __restore_cpu_cpufeatures,
.machine_check_early = NULL,
@@ -379,7 +378,6 @@ static int __init feat_enable_pmu_power8(struct dt_cpu_feature *f)
cur_cpu_spec->num_pmcs = 6;
cur_cpu_spec->pmc_type = PPC_PMC_IBM;
- cur_cpu_spec->oprofile_cpu_type = "ppc64/power8";
return 1;
}
@@ -415,7 +413,6 @@ static int __init feat_enable_pmu_power9(struct dt_cpu_feature *f)
cur_cpu_spec->num_pmcs = 6;
cur_cpu_spec->pmc_type = PPC_PMC_IBM;
- cur_cpu_spec->oprofile_cpu_type = "ppc64/power9";
return 1;
}
@@ -441,7 +438,6 @@ static int __init feat_enable_pmu_power10(struct dt_cpu_feature *f)
cur_cpu_spec->num_pmcs = 6;
cur_cpu_spec->pmc_type = PPC_PMC_IBM;
- cur_cpu_spec->oprofile_cpu_type = "ppc64/power10";
return 1;
}
diff --git a/arch/powerpc/platforms/cell/spufs/spufs.h b/arch/powerpc/platforms/cell/spufs/spufs.h
index afc1d6604d12..23c6799cfa5a 100644
--- a/arch/powerpc/platforms/cell/spufs/spufs.h
+++ b/arch/powerpc/platforms/cell/spufs/spufs.h
@@ -76,7 +76,7 @@ struct spu_context {
struct address_space *mss; /* 'mss' area mappings. */
struct address_space *psmap; /* 'psmap' area mappings. */
struct mutex mapping_lock;
- u64 object_id; /* user space pointer for oprofile */
+ u64 object_id; /* user space pointer for GNU Debugger */
enum { SPU_STATE_RUNNABLE, SPU_STATE_SAVED } state;
struct mutex state_mutex;
--
2.25.0
^ permalink raw reply related
* RE: [PATCH] powerpc/32: Don't use lmw/stmw for saving/restoring non volatile regs
From: David Laight @ 2021-08-25 8:42 UTC (permalink / raw)
To: 'Segher Boessenkool', Christophe Leroy
Cc: Paul Mackerras, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20210824152813.GG1583@gate.crashing.org>
From: Segher Boessenkool
> Sent: 24 August 2021 16:28
>
> On Tue, Aug 24, 2021 at 08:16:00AM -0500, Segher Boessenkool wrote:
> > On Tue, Aug 24, 2021 at 07:54:22AM +0200, Christophe Leroy wrote:
> > > >On mpccore both lmw and stmw are only N+1 btw. But the serialization
> > > >might cost another cycle here?
> > >
> > > That coherent on MPC8xx, that's only 2 cycles.
> > > But on the mpc832x which has a e300c2 core, it looks like I have 10 cycles
> > > difference. Is anything wrong ?
> >
> > I don't know that core very well, I'll have a look.
>
> So, I don't see any difference between e300c2 and e300c1 (which is 603
> basically, for this) that is significant here. The e300c2 has two
> integer units instead of just one, but it still has only one load/store
> unit, and I don't see anything else that could matter either. Huh.
Is the cpu as brain-damaged as the (old) strongarm (SA1100 etc)
where ldm/stm always took 1 clock to check each register bit
regardless of the number of registers to copy?
(IIRC it also took the same length of time when conditionally not
executed.)
If x86 had ever had ldm/stm then it would end up being a microcoded
instruction and take forever to decode.
Intel never managed to optimise 'loop' (dec %cx and jump nz).
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH] powerpc/32: Don't use lmw/stmw for saving/restoring non volatile regs
From: Christophe Leroy @ 2021-08-25 9:39 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <20210824131600.GF1583@gate.crashing.org>
Le 24/08/2021 à 15:16, Segher Boessenkool a écrit :
> Hi!
>
> On Tue, Aug 24, 2021 at 07:54:22AM +0200, Christophe Leroy wrote:
>> Le 23/08/2021 à 20:46, Segher Boessenkool a écrit :
>>> On Mon, Aug 23, 2021 at 03:29:12PM +0000, Christophe Leroy wrote:
>>>> Instructions lmw/stmw are interesting for functions that are rarely
>>>> used and not in the cache, because only one instruction is to be
>>>> copied into the instruction cache instead of 19. However those
>>>> instruction are less performant than 19x raw lwz/stw as they require
>>>> synchronisation plus one additional cycle.
>>>
>>> lmw takes N+2 cycles for loading N words on 603/604/750/7400, and N+3 on
>>> 7450. stmw takes N+1 cycles for storing N words on 603, N+2 on 604/750/
>>> 7400, and N+3 on 7450 (load latency is 3 instead of 2 on 7450).
>>>
>>> There is no synchronisation needed, although there is some serialisation,
>>> which of course doesn't mean much since there can be only 6 or 8 or so
>>> insns executing at once anyway.
>>
>> Yes I meant serialisation, isn't it the same as synchronisation ?
>
> Ha no, synchronisation are insns like sync and eieio :-) Synchronisation
> is architectural, serialisation is (mostly) not, it is a feature of the
> specific core.
>
>>> So, these insns are almost never slower, they can easily win cycles back
>>> because of the smaller code, too.
>>>
>>> What 32-bit core do you see where load/store multiple are more than a
>>> fraction of a cycle (per memory access) slower?
>>>
>>>> SAVE_NVGPRS / REST_NVGPRS are used in only a few places which are
>>>> mostly in interrupts entries/exits and in task switch so they are
>>>> likely already in the cache.
>>>
>>> Nothing is likely in the cache on the older cores (except in
>>> microbenchmarks), the caches are not big enough for that!
>>
>> Even syscall entries/exit pathes and/or most frequent interrupts entries
>> and interrupt exit ?
>
> It has to be measured. You are probably right for programs that use a
> lot of system calls, and (unmeasurably :-) ) wrong for those that don't.
>
> So that is a good argument: it speeds up some scenarios, and does not
> make any real impact on anything else.
>
> This also does not replace all {l,st}mw in the kernel, only those on
> interrupt paths. So it is not necessarily bad :-)
Yes exactly, I wanted to focus on interrupt paths which are the bottle neck.
So I take it that you finally don't disagree with the change.
By the way, it has to be noted that later versions of GCC do less and less use of lmw/stmw. See for
exemple show_user_instructions():
c0007114 <show_user_instructions>:
c0007114: 94 21 ff 50 stwu r1,-176(r1)
c0007118: 7d 80 00 26 mfcr r12
c000711c: 7c 08 02 a6 mflr r0
c0007120: 93 01 00 90 stw r24,144(r1)
c0007124: 93 21 00 94 stw r25,148(r1)
c0007128: 93 41 00 98 stw r26,152(r1)
c000712c: 93 61 00 9c stw r27,156(r1)
c0007130: 93 81 00 a0 stw r28,160(r1)
c0007134: 93 c1 00 a8 stw r30,168(r1)
c0007138: 91 81 00 8c stw r12,140(r1)
c000713c: 90 01 00 b4 stw r0,180(r1)
c0007140: 93 a1 00 a4 stw r29,164(r1)
c0007144: 93 e1 00 ac stw r31,172(r1)
...
c0007244: 80 01 00 b4 lwz r0,180(r1)
c0007248: 81 81 00 8c lwz r12,140(r1)
c000724c: 83 01 00 90 lwz r24,144(r1)
c0007250: 83 21 00 94 lwz r25,148(r1)
c0007254: 83 41 00 98 lwz r26,152(r1)
c0007258: 83 61 00 9c lwz r27,156(r1)
c000725c: 83 81 00 a0 lwz r28,160(r1)
c0007260: 83 a1 00 a4 lwz r29,164(r1)
c0007264: 83 c1 00 a8 lwz r30,168(r1)
c0007268: 83 e1 00 ac lwz r31,172(r1)
c000726c: 7c 08 03 a6 mtlr r0
c0007270: 7d 80 81 20 mtcrf 8,r12
c0007274: 38 21 00 b0 addi r1,r1,176
c0007278: 4e 80 00 20 blr
On older version (GCC 5.5 here) it used to be:
00000408 <show_user_instructions>:
408: 7c 08 02 a6 mflr r0
40c: 94 21 ff 40 stwu r1,-192(r1)
410: 7d 80 00 26 mfcr r12
414: be a1 00 94 stmw r21,148(r1)
418: 91 81 00 90 stw r12,144(r1)
41c: 90 01 00 c4 stw r0,196(r1)
...
504: 80 01 00 c4 lwz r0,196(r1)
508: 81 81 00 90 lwz r12,144(r1)
50c: 7c 08 03 a6 mtlr r0
510: ba a1 00 94 lmw r21,148(r1)
514: 7d 80 81 20 mtcrf 8,r12
518: 38 21 00 c0 addi r1,r1,192
51c: 4e 80 00 20 blr
Christophe
^ permalink raw reply
* Re: [PATCH] powerpc/doc: Fix htmldocs errors
From: Stephen Rothwell @ 2021-08-25 9:46 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, Jonathan Corbet
In-Reply-To: <20210825042447.106219-1-aneesh.kumar@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 784 bytes --]
Hi Aneesh,
On Wed, 25 Aug 2021 09:54:47 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote:
>
> Fix make htmldocs related errors with the newly added associativity.rst
> doc file.
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> Documentation/powerpc/associativity.rst | 29 +++++++++++++------------
> Documentation/powerpc/index.rst | 1 +
> 2 files changed, 16 insertions(+), 14 deletions(-)
This fixes all the warnings related to this file for me.
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au> # build test
Michael, it would be good if this could go in soon as without this
patch my "make htmldocs" run livelocks. :-(
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox