* [PATCH v2 06/43] powerpc/40x: Reorder a few instructions in critical exception prolog
From: Christophe Leroy @ 2021-03-09 12:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, npiggin
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1615291471.git.christophe.leroy@csgroup.eu>
In order to ease preparation for CONFIG_VMAP_STACK, reorder
a few instruction, especially save r1 into stack frame earlier.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/head_40x.S | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S
index 067ae1302c1c..5b337bf49bcb 100644
--- a/arch/powerpc/kernel/head_40x.S
+++ b/arch/powerpc/kernel/head_40x.S
@@ -119,6 +119,9 @@ _ENTRY(saved_ksp_limit)
lwz r11,TASK_STACK-THREAD(r11) /* this thread's kernel stack */
1: addi r11,r11,THREAD_SIZE-INT_FRAME_SIZE /* Alloc an excpt frm */
tophys(r11,r11)
+ stw r1,GPR1(r11)
+ stw r1,0(r11)
+ tovirt(r1,r11)
stw r10,_CCR(r11) /* save various registers */
stw r12,GPR12(r11)
stw r9,GPR9(r11)
@@ -129,14 +132,11 @@ _ENTRY(saved_ksp_limit)
stw r10,GPR10(r11)
stw r12,GPR11(r11)
mfspr r12,SPRN_DEAR /* save DEAR and ESR in the frame */
- stw r12,_DEAR(r11) /* since they may have had stuff */
mfspr r9,SPRN_ESR /* in them at the point where the */
+ stw r12,_DEAR(r11) /* since they may have had stuff */
stw r9,_ESR(r11) /* exception was taken */
mfspr r12,SPRN_SRR2
- stw r1,GPR1(r11)
mfspr r9,SPRN_SRR3
- stw r1,0(r11)
- tovirt(r1,r11)
rlwinm r9,r9,0,14,12 /* clear MSR_WE (necessary?) */
stw r0,GPR0(r11)
lis r10, STACK_FRAME_REGS_MARKER@ha /* exception frame marker */
--
2.25.0
^ permalink raw reply related
* [PATCH v2 04/43] powerpc/40x: Change CRITICAL_EXCEPTION_PROLOG macro to a gas macro
From: Christophe Leroy @ 2021-03-09 12:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, npiggin
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1615291471.git.christophe.leroy@csgroup.eu>
Change CRITICAL_EXCEPTION_PROLOG macro to a gas macro to
remove the ugly ; and \ on each line.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/head_40x.S | 71 +++++++++++++++++-----------------
1 file changed, 36 insertions(+), 35 deletions(-)
diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S
index 383238a98f77..9cef423d574b 100644
--- a/arch/powerpc/kernel/head_40x.S
+++ b/arch/powerpc/kernel/head_40x.S
@@ -100,42 +100,43 @@ _ENTRY(saved_ksp_limit)
* Instead we use a couple of words of memory at low physical addresses.
* This is OK since we don't support SMP on these processors.
*/
-#define CRITICAL_EXCEPTION_PROLOG \
- stw r10,crit_r10@l(0); /* save two registers to work with */\
- stw r11,crit_r11@l(0); \
- mfcr r10; /* save CR in r10 for now */\
- mfspr r11,SPRN_SRR3; /* check whether user or kernel */\
- andi. r11,r11,MSR_PR; \
- lis r11,critirq_ctx@ha; \
- tophys(r11,r11); \
- lwz r11,critirq_ctx@l(r11); \
- beq 1f; \
- /* COMING FROM USER MODE */ \
- mfspr r11,SPRN_SPRG_THREAD; /* if from user, start at top of */\
- lwz r11,TASK_STACK-THREAD(r11); /* this thread's kernel stack */\
-1: addi r11,r11,THREAD_SIZE-INT_FRAME_SIZE; /* Alloc an excpt frm */\
- tophys(r11,r11); \
- stw r10,_CCR(r11); /* save various registers */\
- stw r12,GPR12(r11); \
- stw r9,GPR9(r11); \
- mflr r10; \
- stw r10,_LINK(r11); \
- mfspr r12,SPRN_DEAR; /* save DEAR and ESR in the frame */\
- stw r12,_DEAR(r11); /* since they may have had stuff */\
- mfspr r9,SPRN_ESR; /* in them at the point where the */\
- stw r9,_ESR(r11); /* exception was taken */\
- mfspr r12,SPRN_SRR2; \
- stw r1,GPR1(r11); \
- mfspr r9,SPRN_SRR3; \
- stw r1,0(r11); \
- tovirt(r1,r11); \
- rlwinm r9,r9,0,14,12; /* clear MSR_WE (necessary?) */\
- stw r0,GPR0(r11); \
- lis r10, STACK_FRAME_REGS_MARKER@ha; /* exception frame marker */\
- addi r10, r10, STACK_FRAME_REGS_MARKER@l; \
- stw r10, 8(r11); \
- SAVE_4GPRS(3, r11); \
+.macro CRITICAL_EXCEPTION_PROLOG
+ stw r10,crit_r10@l(0) /* save two registers to work with */
+ stw r11,crit_r11@l(0)
+ mfcr r10 /* save CR in r10 for now */
+ mfspr r11,SPRN_SRR3 /* check whether user or kernel */
+ andi. r11,r11,MSR_PR
+ lis r11,critirq_ctx@ha
+ tophys(r11,r11)
+ lwz r11,critirq_ctx@l(r11)
+ beq 1f
+ /* COMING FROM USER MODE */
+ mfspr r11,SPRN_SPRG_THREAD /* if from user, start at top of */
+ lwz r11,TASK_STACK-THREAD(r11) /* this thread's kernel stack */
+1: addi r11,r11,THREAD_SIZE-INT_FRAME_SIZE /* Alloc an excpt frm */
+ tophys(r11,r11)
+ stw r10,_CCR(r11) /* save various registers */
+ stw r12,GPR12(r11)
+ stw r9,GPR9(r11)
+ mflr r10
+ stw r10,_LINK(r11)
+ mfspr r12,SPRN_DEAR /* save DEAR and ESR in the frame */
+ stw r12,_DEAR(r11) /* since they may have had stuff */
+ mfspr r9,SPRN_ESR /* in them at the point where the */
+ stw r9,_ESR(r11) /* exception was taken */
+ mfspr r12,SPRN_SRR2
+ stw r1,GPR1(r11)
+ mfspr r9,SPRN_SRR3
+ stw r1,0(r11)
+ tovirt(r1,r11)
+ rlwinm r9,r9,0,14,12 /* clear MSR_WE (necessary?) */
+ stw r0,GPR0(r11)
+ lis r10, STACK_FRAME_REGS_MARKER@ha /* exception frame marker */
+ addi r10, r10, STACK_FRAME_REGS_MARKER@l
+ stw r10, 8(r11)
+ SAVE_4GPRS(3, r11)
SAVE_2GPRS(7, r11)
+.endm
/*
* State at this point:
--
2.25.0
^ permalink raw reply related
* [PATCH v2 03/43] powerpc/40x: Don't use SPRN_SPRG_SCRATCH0/1 in TLB miss handlers
From: Christophe Leroy @ 2021-03-09 12:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, npiggin
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1615291471.git.christophe.leroy@csgroup.eu>
SPRN_SPRG_SCRATCH5 is used to save SPRN_PID.
SPRN_SPRG_SCRATCH6 is already available.
SPRN_PID is only 8 bits. We have r12 that contains CR.
We only need to preserve CR0, so we have space available in r12
to save PID.
Keep PID in r12 and free up SPRN_SPRG_SCRATCH5.
Then In TLB miss handlers, instead of using SPRN_SPRG_SCRATCH0 and
SPRN_SPRG_SCRATCH1, use SPRN_SPRG_SCRATCH5 and SPRN_SPRG_SCRATCH6
to avoid future conflicts with normal exception prologs.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/head_40x.S | 39 ++++++++++++++++------------------
1 file changed, 18 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S
index 24724a7dad49..383238a98f77 100644
--- a/arch/powerpc/kernel/head_40x.S
+++ b/arch/powerpc/kernel/head_40x.S
@@ -249,13 +249,13 @@ _ENTRY(saved_ksp_limit)
* load TLB entries from the page table if they exist.
*/
START_EXCEPTION(0x1100, DTLBMiss)
- mtspr SPRN_SPRG_SCRATCH0, r10 /* Save some working registers */
- mtspr SPRN_SPRG_SCRATCH1, r11
+ mtspr SPRN_SPRG_SCRATCH5, r10 /* Save some working registers */
+ mtspr SPRN_SPRG_SCRATCH6, r11
mtspr SPRN_SPRG_SCRATCH3, r12
mtspr SPRN_SPRG_SCRATCH4, r9
mfcr r12
mfspr r9, SPRN_PID
- mtspr SPRN_SPRG_SCRATCH5, r9
+ rlwimi r12, r9, 0, 0xff
mfspr r10, SPRN_DEAR /* Get faulting address */
/* If we are faulting a kernel address, we have to use the
@@ -316,13 +316,12 @@ _ENTRY(saved_ksp_limit)
/* The bailout. Restore registers to pre-exception conditions
* and call the heavyweights to help us out.
*/
- mfspr r9, SPRN_SPRG_SCRATCH5
- mtspr SPRN_PID, r9
- mtcr r12
+ mtspr SPRN_PID, r12
+ mtcrf 0x80, r12
mfspr r9, SPRN_SPRG_SCRATCH4
mfspr r12, SPRN_SPRG_SCRATCH3
- mfspr r11, SPRN_SPRG_SCRATCH1
- mfspr r10, SPRN_SPRG_SCRATCH0
+ mfspr r11, SPRN_SPRG_SCRATCH6
+ mfspr r10, SPRN_SPRG_SCRATCH5
b DataStorage
/* 0x1200 - Instruction TLB Miss Exception
@@ -330,13 +329,13 @@ _ENTRY(saved_ksp_limit)
* registers and bailout to a different point.
*/
START_EXCEPTION(0x1200, ITLBMiss)
- mtspr SPRN_SPRG_SCRATCH0, r10 /* Save some working registers */
- mtspr SPRN_SPRG_SCRATCH1, r11
+ mtspr SPRN_SPRG_SCRATCH5, r10 /* Save some working registers */
+ mtspr SPRN_SPRG_SCRATCH6, r11
mtspr SPRN_SPRG_SCRATCH3, r12
mtspr SPRN_SPRG_SCRATCH4, r9
mfcr r12
mfspr r9, SPRN_PID
- mtspr SPRN_SPRG_SCRATCH5, r9
+ rlwimi r12, r9, 0, 0xff
mfspr r10, SPRN_SRR0 /* Get faulting address */
/* If we are faulting a kernel address, we have to use the
@@ -397,13 +396,12 @@ _ENTRY(saved_ksp_limit)
/* The bailout. Restore registers to pre-exception conditions
* and call the heavyweights to help us out.
*/
- mfspr r9, SPRN_SPRG_SCRATCH5
- mtspr SPRN_PID, r9
- mtcr r12
+ mtspr SPRN_PID, r12
+ mtcrf 0x80, r12
mfspr r9, SPRN_SPRG_SCRATCH4
mfspr r12, SPRN_SPRG_SCRATCH3
- mfspr r11, SPRN_SPRG_SCRATCH1
- mfspr r10, SPRN_SPRG_SCRATCH0
+ mfspr r11, SPRN_SPRG_SCRATCH6
+ mfspr r10, SPRN_SPRG_SCRATCH5
b InstructionAccess
EXCEPTION(0x1300, Trap_13, unknown_exception, EXC_XFER_STD)
@@ -543,13 +541,12 @@ finish_tlb_load:
/* Done...restore registers and get out of here.
*/
- mfspr r9, SPRN_SPRG_SCRATCH5
- mtspr SPRN_PID, r9
- mtcr r12
+ mtspr SPRN_PID, r12
+ mtcrf 0x80, r12
mfspr r9, SPRN_SPRG_SCRATCH4
mfspr r12, SPRN_SPRG_SCRATCH3
- mfspr r11, SPRN_SPRG_SCRATCH1
- mfspr r10, SPRN_SPRG_SCRATCH0
+ mfspr r11, SPRN_SPRG_SCRATCH6
+ mfspr r10, SPRN_SPRG_SCRATCH5
rfi /* Should sync shadow TLBs */
b . /* prevent prefetch past rfi */
--
2.25.0
^ permalink raw reply related
* [PATCH v2 01/43] powerpc/traps: unrecoverable_exception() is not an interrupt handler
From: Christophe Leroy @ 2021-03-09 12:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, npiggin
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1615291471.git.christophe.leroy@csgroup.eu>
unrecoverable_exception() is called from interrupt handlers or
after an interrupt handler has failed.
Make it a standard function to avoid doubling the actions
performed on interrupt entry (e.g.: user time accounting).
Fixes: 3a96570ffceb ("powerpc: convert interrupt handlers to use wrappers")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/include/asm/interrupt.h | 3 ++-
arch/powerpc/kernel/interrupt.c | 1 -
arch/powerpc/kernel/traps.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/interrupt.h b/arch/powerpc/include/asm/interrupt.h
index aedfba29e43a..e8d09a841373 100644
--- a/arch/powerpc/include/asm/interrupt.h
+++ b/arch/powerpc/include/asm/interrupt.h
@@ -410,7 +410,6 @@ DECLARE_INTERRUPT_HANDLER(altivec_assist_exception);
DECLARE_INTERRUPT_HANDLER(CacheLockingException);
DECLARE_INTERRUPT_HANDLER(SPEFloatingPointException);
DECLARE_INTERRUPT_HANDLER(SPEFloatingPointRoundException);
-DECLARE_INTERRUPT_HANDLER(unrecoverable_exception);
DECLARE_INTERRUPT_HANDLER(WatchdogException);
DECLARE_INTERRUPT_HANDLER(kernel_bad_stack);
@@ -437,6 +436,8 @@ DECLARE_INTERRUPT_HANDLER_NMI(hmi_exception_realmode);
DECLARE_INTERRUPT_HANDLER_ASYNC(TAUException);
+void unrecoverable_exception(struct pt_regs *regs);
+
void replay_system_reset(void);
void replay_soft_interrupts(void);
diff --git a/arch/powerpc/kernel/interrupt.c b/arch/powerpc/kernel/interrupt.c
index 398cd86b6ada..b8e7d25be31b 100644
--- a/arch/powerpc/kernel/interrupt.c
+++ b/arch/powerpc/kernel/interrupt.c
@@ -436,7 +436,6 @@ notrace unsigned long interrupt_exit_user_prepare(struct pt_regs *regs, unsigned
return ret;
}
-void unrecoverable_exception(struct pt_regs *regs);
void preempt_schedule_irq(void);
notrace unsigned long interrupt_exit_kernel_prepare(struct pt_regs *regs, unsigned long msr)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 1583fd1c6010..a44a30b0688c 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -2170,7 +2170,7 @@ DEFINE_INTERRUPT_HANDLER(SPEFloatingPointRoundException)
* in the MSR is 0. This indicates that SRR0/1 are live, and that
* we therefore lost state by taking this exception.
*/
-DEFINE_INTERRUPT_HANDLER(unrecoverable_exception)
+void unrecoverable_exception(struct pt_regs *regs)
{
pr_emerg("Unrecoverable exception %lx at %lx (msr=%lx)\n",
regs->trap, regs->nip, regs->msr);
--
2.25.0
^ permalink raw reply related
* [PATCH v2 00/43] powerpc/32: Switch to interrupt entry/exit in C
From: Christophe Leroy @ 2021-03-09 12:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, npiggin
Cc: linuxppc-dev, linux-kernel
This series aims at porting interrupt entry/exit in C on PPC32, using
the work already merged for PPC64.
First two patches are a fix and an optimisation of unrecoverable_exception() function.
Six following patches do minimal changes in 40x in order to be able to enable MMU
earlier in exception entry.
Second part of the series prepares and switches interrupt exit in C.
Third part moves more and more things in C, ending with KUAP management.
v2 is tested on 8xx and 83xx and qemu, and compile tested via kisskb.
Changes in v2:
- Two first patches are new.
- Mainly build fixes, nothing much new.
Christophe Leroy (43):
powerpc/traps: unrecoverable_exception() is not an interrupt handler
powerpc/traps: Declare unrecoverable_exception() as __noreturn
powerpc/40x: Don't use SPRN_SPRG_SCRATCH0/1 in TLB miss handlers
powerpc/40x: Change CRITICAL_EXCEPTION_PROLOG macro to a gas macro
powerpc/40x: Save SRR0/SRR1 and r10/r11 earlier in critical exception
powerpc/40x: Reorder a few instructions in critical exception prolog
powerpc/40x: Prepare for enabling MMU in critical exception prolog
powerpc/40x: Prepare normal exception handler for enabling MMU early
powerpc/32: Reconcile interrupts in C
powerpc/32: Entry cpu time accounting in C
powerpc/32: Handle bookE debugging in C in exception entry
powerpc/32: Use fast instruction to set MSR RI in exception prolog on
8xx
powerpc/32: Remove ksp_limit
powerpc/32: Always enable data translation in exception prolog
powerpc/32: Tag DAR in EXCEPTION_PROLOG_2 for the 8xx
powerpc/32: Enable instruction translation at the same time as data
translation
powerpc/32: Statically initialise first emergency context
powerpc/32: Add vmap_stack_overflow label inside the macro
powerpc/32: Use START_EXCEPTION() as much as possible
powerpc/32: Move exception prolog code into .text once MMU is back on
powerpc/32: Provide a name to exception prolog continuation in virtual
mode
powerpc/32: Refactor booke critical registers saving
powerpc/32: Perform normal function call in exception entry
powerpc/32: Always save non volatile registers on exception entry
powerpc/32: Replace ASM exception exit by C exception exit from ppc64
powerpc/32: Set regs parameter in r3 in transfer_to_handler
powerpc/32: Call bad_page_fault() from do_page_fault()
powerpc/64e: Call bad_page_fault() from do_page_fault()
powerpc/32: Save trap number on stack in exception prolog
powerpc/32: Add a prepare_transfer_to_handler macro for exception
prologs
powerpc/32: Only restore non volatile registers when required
powerpc/32: Dismantle EXC_XFER_STD/LITE/TEMPLATE
powerpc/32: Remove the xfer parameter in EXCEPTION() macro
powerpc/32: Refactor saving of volatile registers in exception prologs
powerpc/32: Save remaining registers in exception prolog
powerpc/32: Set current->thread.regs in C interrupt entry
powerpc/32: Return directly from power_save_ppc32_restore()
powerpc/32: Only use prepare_transfer_to_handler function on book3s/32
and e500
powerpc/32s: Move KUEP locking/unlocking in C
powerpc/64s: Make kuap_check_amr() and kuap_get_and_check_amr()
generic
powerpc/32s: Create C version of kuap save/restore/check helpers
powerpc/8xx: Create C version of kuap save/restore/check helpers
powerpc/32: Manage KUAP in C
arch/powerpc/include/asm/book3s/32/kup.h | 126 +--
arch/powerpc/include/asm/book3s/64/kup.h | 24 +-
arch/powerpc/include/asm/interrupt.h | 19 +-
arch/powerpc/include/asm/kup.h | 27 +-
arch/powerpc/include/asm/nohash/32/kup-8xx.h | 56 +-
arch/powerpc/include/asm/ppc_asm.h | 10 -
arch/powerpc/include/asm/processor.h | 6 +-
arch/powerpc/include/asm/ptrace.h | 6 +-
arch/powerpc/kernel/asm-offsets.c | 4 -
arch/powerpc/kernel/entry_32.S | 835 ++++---------------
arch/powerpc/kernel/exceptions-64e.S | 8 +-
arch/powerpc/kernel/fpu.S | 2 -
arch/powerpc/kernel/head_32.h | 195 ++---
arch/powerpc/kernel/head_40x.S | 271 +++---
arch/powerpc/kernel/head_44x.S | 10 +-
arch/powerpc/kernel/head_8xx.S | 151 ++--
arch/powerpc/kernel/head_book3s_32.S | 233 +++---
arch/powerpc/kernel/head_booke.h | 188 +++--
arch/powerpc/kernel/head_fsl_booke.S | 64 +-
arch/powerpc/kernel/idle_6xx.S | 14 +-
arch/powerpc/kernel/idle_e500.S | 14 +-
arch/powerpc/kernel/interrupt.c | 40 +-
arch/powerpc/kernel/irq.c | 2 +-
arch/powerpc/kernel/misc_32.S | 14 -
arch/powerpc/kernel/process.c | 6 +-
arch/powerpc/kernel/setup_32.c | 2 +-
arch/powerpc/kernel/traps.c | 15 +-
arch/powerpc/kernel/vector.S | 2 -
arch/powerpc/lib/sstep.c | 9 -
arch/powerpc/mm/book3s32/Makefile | 1 +
arch/powerpc/mm/book3s32/hash_low.S | 14 -
arch/powerpc/mm/book3s32/kuep.c | 38 +
arch/powerpc/mm/fault.c | 17 +-
33 files changed, 885 insertions(+), 1538 deletions(-)
create mode 100644 arch/powerpc/mm/book3s32/kuep.c
--
2.25.0
^ permalink raw reply
* [PATCH v2 02/43] powerpc/traps: Declare unrecoverable_exception() as __noreturn
From: Christophe Leroy @ 2021-03-09 12:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, npiggin
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1615291471.git.christophe.leroy@csgroup.eu>
unrecoverable_exception() is never expected to return, most callers
have an infiniteloop in case it returns.
Ensure it really never returns by terminating it with a BUG(), and
declare it __no_return.
It always GCC to really simplify functions calling it. In the exemple
below, it avoids the stack frame in the likely fast path and avoids
code duplication for the exit.
With this patch:
00000348 <interrupt_exit_kernel_prepare>:
348: 81 43 00 84 lwz r10,132(r3)
34c: 71 48 00 02 andi. r8,r10,2
350: 41 82 00 2c beq 37c <interrupt_exit_kernel_prepare+0x34>
354: 71 4a 40 00 andi. r10,r10,16384
358: 40 82 00 20 bne 378 <interrupt_exit_kernel_prepare+0x30>
35c: 80 62 00 70 lwz r3,112(r2)
360: 74 63 00 01 andis. r3,r3,1
364: 40 82 00 28 bne 38c <interrupt_exit_kernel_prepare+0x44>
368: 7d 40 00 a6 mfmsr r10
36c: 7c 11 13 a6 mtspr 81,r0
370: 7c 12 13 a6 mtspr 82,r0
374: 4e 80 00 20 blr
378: 48 00 00 00 b 378 <interrupt_exit_kernel_prepare+0x30>
37c: 94 21 ff f0 stwu r1,-16(r1)
380: 7c 08 02 a6 mflr r0
384: 90 01 00 14 stw r0,20(r1)
388: 48 00 00 01 bl 388 <interrupt_exit_kernel_prepare+0x40>
388: R_PPC_REL24 unrecoverable_exception
38c: 38 e2 00 70 addi r7,r2,112
390: 3d 00 00 01 lis r8,1
394: 7c c0 38 28 lwarx r6,0,r7
398: 7c c6 40 78 andc r6,r6,r8
39c: 7c c0 39 2d stwcx. r6,0,r7
3a0: 40 a2 ff f4 bne 394 <interrupt_exit_kernel_prepare+0x4c>
3a4: 38 60 00 01 li r3,1
3a8: 4b ff ff c0 b 368 <interrupt_exit_kernel_prepare+0x20>
Without this patch:
00000348 <interrupt_exit_kernel_prepare>:
348: 94 21 ff f0 stwu r1,-16(r1)
34c: 93 e1 00 0c stw r31,12(r1)
350: 7c 7f 1b 78 mr r31,r3
354: 81 23 00 84 lwz r9,132(r3)
358: 71 2a 00 02 andi. r10,r9,2
35c: 41 82 00 34 beq 390 <interrupt_exit_kernel_prepare+0x48>
360: 71 29 40 00 andi. r9,r9,16384
364: 40 82 00 28 bne 38c <interrupt_exit_kernel_prepare+0x44>
368: 80 62 00 70 lwz r3,112(r2)
36c: 74 63 00 01 andis. r3,r3,1
370: 40 82 00 3c bne 3ac <interrupt_exit_kernel_prepare+0x64>
374: 7d 20 00 a6 mfmsr r9
378: 7c 11 13 a6 mtspr 81,r0
37c: 7c 12 13 a6 mtspr 82,r0
380: 83 e1 00 0c lwz r31,12(r1)
384: 38 21 00 10 addi r1,r1,16
388: 4e 80 00 20 blr
38c: 48 00 00 00 b 38c <interrupt_exit_kernel_prepare+0x44>
390: 7c 08 02 a6 mflr r0
394: 90 01 00 14 stw r0,20(r1)
398: 48 00 00 01 bl 398 <interrupt_exit_kernel_prepare+0x50>
398: R_PPC_REL24 unrecoverable_exception
39c: 80 01 00 14 lwz r0,20(r1)
3a0: 81 3f 00 84 lwz r9,132(r31)
3a4: 7c 08 03 a6 mtlr r0
3a8: 4b ff ff b8 b 360 <interrupt_exit_kernel_prepare+0x18>
3ac: 39 02 00 70 addi r8,r2,112
3b0: 3d 40 00 01 lis r10,1
3b4: 7c e0 40 28 lwarx r7,0,r8
3b8: 7c e7 50 78 andc r7,r7,r10
3bc: 7c e0 41 2d stwcx. r7,0,r8
3c0: 40 a2 ff f4 bne 3b4 <interrupt_exit_kernel_prepare+0x6c>
3c4: 38 60 00 01 li r3,1
3c8: 4b ff ff ac b 374 <interrupt_exit_kernel_prepare+0x2c>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/include/asm/interrupt.h | 2 +-
arch/powerpc/kernel/traps.c | 6 +++++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/interrupt.h b/arch/powerpc/include/asm/interrupt.h
index e8d09a841373..232a4847f596 100644
--- a/arch/powerpc/include/asm/interrupt.h
+++ b/arch/powerpc/include/asm/interrupt.h
@@ -436,7 +436,7 @@ DECLARE_INTERRUPT_HANDLER_NMI(hmi_exception_realmode);
DECLARE_INTERRUPT_HANDLER_ASYNC(TAUException);
-void unrecoverable_exception(struct pt_regs *regs);
+void __noreturn unrecoverable_exception(struct pt_regs *regs);
void replay_system_reset(void);
void replay_soft_interrupts(void);
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index a44a30b0688c..d5c9d9ddd186 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -2170,11 +2170,15 @@ DEFINE_INTERRUPT_HANDLER(SPEFloatingPointRoundException)
* in the MSR is 0. This indicates that SRR0/1 are live, and that
* we therefore lost state by taking this exception.
*/
-void unrecoverable_exception(struct pt_regs *regs)
+void __noreturn unrecoverable_exception(struct pt_regs *regs)
{
pr_emerg("Unrecoverable exception %lx at %lx (msr=%lx)\n",
regs->trap, regs->nip, regs->msr);
die("Unrecoverable exception", regs, SIGABRT);
+ /* die() should not return */
+ WARN(true, "die() unexpectedly returned");
+ for (;;)
+ ;
}
#if defined(CONFIG_BOOKE_WDT) || defined(CONFIG_40x)
--
2.25.0
^ permalink raw reply related
* Re: [PATCH] powerpc/perf: Fix the threshold event selection for memory events in power10
From: Madhavan Srinivasan @ 2021-03-09 11:28 UTC (permalink / raw)
To: Athira Rajeev, mpe; +Cc: linuxppc-dev
In-Reply-To: <1614840015-1535-1-git-send-email-atrajeev@linux.vnet.ibm.com>
On 3/4/21 12:10 PM, Athira Rajeev wrote:
> Memory events (mem-loads and mem-stores) currently use the threshold
> event selection as issue to finish. Power10 supports issue to complete
> as part of thresholding which is more appropriate for mem-loads and
> mem-stores. Hence fix the event code for memory events to use issue
> to complete.
Changes looks fine to me.
Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
We should also CC stable to include this fix?
> Fixes: a64e697cef23 ("powerpc/perf: power10 Performance Monitoring support")
> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> ---
> arch/powerpc/perf/power10-events-list.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/perf/power10-events-list.h b/arch/powerpc/perf/power10-events-list.h
> index e45dafe818ed..93be7197d250 100644
> --- a/arch/powerpc/perf/power10-events-list.h
> +++ b/arch/powerpc/perf/power10-events-list.h
> @@ -75,5 +75,5 @@
> * thresh end (TE)
> */
>
> -EVENT(MEM_LOADS, 0x34340401e0);
> -EVENT(MEM_STORES, 0x343c0401e0);
> +EVENT(MEM_LOADS, 0x35340401e0);
> +EVENT(MEM_STORES, 0x353c0401e0);
^ permalink raw reply
* Re: [PATCH] powerpc/perf: Fix sampled instruction type for larx/stcx
From: Madhavan Srinivasan @ 2021-03-09 11:26 UTC (permalink / raw)
To: Athira Rajeev, mpe; +Cc: linuxppc-dev
In-Reply-To: <1614858937-1485-1-git-send-email-atrajeev@linux.vnet.ibm.com>
On 3/4/21 5:25 PM, Athira Rajeev wrote:
> Sampled Instruction Event Register (SIER) field [46:48]
> identifies the sampled instruction type. ISA v3.1 says value
> of 0b111 for this field as reserved, but in POWER10 it denotes
> LARX/STCX type which will hopefully be fixed in ISA v3.1 update.
>
> Patch fixes the functions to handle type value 7 for
> CPU_FTR_ARCH_31.
Changes looks fine to me.
Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
> Fixes: a64e697cef23 ("powerpc/perf: power10 Performance Monitoring support")
> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> ---
> arch/powerpc/perf/isa207-common.c | 30 +++++++++++++++++++++++++++---
> arch/powerpc/perf/isa207-common.h | 1 +
> 2 files changed, 28 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/perf/isa207-common.c b/arch/powerpc/perf/isa207-common.c
> index e4f577da33d8..754f904d8d69 100644
> --- a/arch/powerpc/perf/isa207-common.c
> +++ b/arch/powerpc/perf/isa207-common.c
> @@ -266,6 +266,8 @@ void isa207_get_mem_data_src(union perf_mem_data_src *dsrc, u32 flags,
> u32 sub_idx;
> u64 sier;
> u64 val;
> + u64 mmcra = mfspr(SPRN_MMCRA);
> + u32 op_type;
>
> /* Skip if no SIER support */
> if (!(flags & PPMU_HAS_SIER)) {
> @@ -275,12 +277,34 @@ void isa207_get_mem_data_src(union perf_mem_data_src *dsrc, u32 flags,
>
> sier = mfspr(SPRN_SIER);
> val = (sier & ISA207_SIER_TYPE_MASK) >> ISA207_SIER_TYPE_SHIFT;
> - if (val == 1 || val == 2) {
> + if (val == 1 || val == 2 || (val == 7 && cpu_has_feature(CPU_FTR_ARCH_31))) {
> idx = (sier & ISA207_SIER_LDST_MASK) >> ISA207_SIER_LDST_SHIFT;
> sub_idx = (sier & ISA207_SIER_DATA_SRC_MASK) >> ISA207_SIER_DATA_SRC_SHIFT;
>
> dsrc->val = isa207_find_source(idx, sub_idx);
> - dsrc->val |= (val == 1) ? P(OP, LOAD) : P(OP, STORE);
> + if (val == 7) {
> + /*
> + * Type 0b111 denotes either larx or stcx instruction. Use the
> + * MMCRA sampling bits [57:59] along with the type value
> + * to determine the exact instruction type. If the sampling
> + * criteria is neither load or store, set the type as default
> + * to NA.
> + */
> + op_type = (mmcra >> MMCRA_SAMP_ELIG_SHIFT) & MMCRA_SAMP_ELIG_MASK;
> + switch (op_type) {
> + case 5:
> + dsrc->val |= P(OP, LOAD);
> + break;
> + case 7:
> + dsrc->val |= P(OP, STORE);
> + break;
> + default:
> + dsrc->val |= P(OP, NA);
> + break;
> + }
> + } else {
> + dsrc->val |= (val == 1) ? P(OP, LOAD) : P(OP, STORE);
> + }
> }
> }
>
> @@ -295,7 +319,7 @@ void isa207_get_mem_weight(u64 *weight)
> if (cpu_has_feature(CPU_FTR_ARCH_31))
> mantissa = P10_MMCRA_THR_CTR_MANT(mmcra);
>
> - if (val == 0 || val == 7)
> + if (val == 0 || (val == 7 && !cpu_has_feature(CPU_FTR_ARCH_31)))
> *weight = 0;
> else
> *weight = mantissa << (2 * exp);
> diff --git a/arch/powerpc/perf/isa207-common.h b/arch/powerpc/perf/isa207-common.h
> index 1af0e8c97ac7..7b0242efe4b9 100644
> --- a/arch/powerpc/perf/isa207-common.h
> +++ b/arch/powerpc/perf/isa207-common.h
> @@ -220,6 +220,7 @@
> /* Bits in MMCRA for PowerISA v2.07 */
> #define MMCRA_SAMP_MODE_SHIFT 1
> #define MMCRA_SAMP_ELIG_SHIFT 4
> +#define MMCRA_SAMP_ELIG_MASK 7
> #define MMCRA_THR_CTL_SHIFT 8
> #define MMCRA_THR_SEL_SHIFT 16
> #define MMCRA_THR_CMP_SHIFT 32
^ permalink raw reply
* Re: [PATCH v4] powerpc/uprobes: Validation for prefixed instruction
From: Naveen N. Rao @ 2021-03-09 11:21 UTC (permalink / raw)
To: Michael Ellerman
Cc: Ravi Bangoria, jniethe5, oleg, rostedt, linux-kernel, paulus,
sandipan, naveen.n.rao, linuxppc-dev
In-Reply-To: <87ft14r6sa.fsf@mpe.ellerman.id.au>
On 2021/03/09 08:54PM, Michael Ellerman wrote:
> Ravi Bangoria <ravi.bangoria@linux.ibm.com> writes:
> > As per ISA 3.1, prefixed instruction should not cross 64-byte
> > boundary. So don't allow Uprobe on such prefixed instruction.
> >
> > There are two ways probed instruction is changed in mapped pages.
> > First, when Uprobe is activated, it searches for all the relevant
> > pages and replace instruction in them. In this case, if that probe
> > is on the 64-byte unaligned prefixed instruction, error out
> > directly. Second, when Uprobe is already active and user maps a
> > relevant page via mmap(), instruction is replaced via mmap() code
> > path. But because Uprobe is invalid, entire mmap() operation can
> > not be stopped. In this case just print an error and continue.
> >
> > Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
> > Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
>
> Do we have a Fixes: tag for this?
Since this is an additional check we are adding, I don't think we should
add a Fixes: tag. Nothing is broken per-se -- we're just adding more
checks to catch simple mistakes. Also, like Oleg pointed out, there are
still many other ways for users to shoot themselves in the foot with
uprobes and prefixed instructions, if they so desire.
However, if you still think we should add a Fixes: tag, we can perhaps
use the below commit since I didn't see any specific commit adding
support for prefixed instructions for uprobes:
Fixes: 650b55b707fdfa ("powerpc: Add prefixed instructions to
instruction data type")
>
> > ---
> > v3: https://lore.kernel.org/r/20210304050529.59391-1-ravi.bangoria@linux.ibm.com
> > v3->v4:
> > - CONFIG_PPC64 check was not required, remove it.
> > - Use SZ_ macros instead of hardcoded numbers.
> >
> > arch/powerpc/kernel/uprobes.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel/uprobes.c
> > index e8a63713e655..4cbfff6e94a3 100644
> > --- a/arch/powerpc/kernel/uprobes.c
> > +++ b/arch/powerpc/kernel/uprobes.c
> > @@ -41,6 +41,13 @@ int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe,
> > if (addr & 0x03)
> > return -EINVAL;
> >
> > + if (cpu_has_feature(CPU_FTR_ARCH_31) &&
> > + ppc_inst_prefixed(auprobe->insn) &&
> > + (addr & (SZ_64 - 4)) == SZ_64 - 4) {
> > + pr_info_ratelimited("Cannot register a uprobe on 64 byte unaligned prefixed instruction\n");
> > + return -EINVAL;
>
> I realise we already did the 0x03 check above, but I still think this
> would be clearer simply as:
>
> (addr & 0x3f == 60)
Indeed, I like the use of `60' there -- hex is overrated ;)
- Naveen
^ permalink raw reply
* Re: [PATCH] powerpc: Fix missing declaration of [en/dis]able_kernel_vsx()
From: Geert Uytterhoeven @ 2021-03-09 10:55 UTC (permalink / raw)
To: Christophe Leroy
Cc: Linux Kernel Mailing List, amd-gfx list, Paul Mackerras,
Alex Deucher, linuxppc-dev, Christian König
In-Reply-To: <b64111a3-df3f-bf59-20ce-0af57715ad53@csgroup.eu>
Hi Christophe,
On Tue, Mar 9, 2021 at 10:58 AM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
> Le 09/03/2021 à 10:16, Geert Uytterhoeven a écrit :
> > On Tue, Mar 9, 2021 at 9:52 AM Christophe Leroy
> > <christophe.leroy@csgroup.eu> wrote:
> >> Le 09/03/2021 à 09:45, Geert Uytterhoeven a écrit :
> >>> On Tue, Mar 9, 2021 at 9:39 AM Christophe Leroy
> >>> <christophe.leroy@csgroup.eu> wrote:
> >>>> Add stub instances of enable_kernel_vsx() and disable_kernel_vsx()
> >>>> when CONFIG_VSX is not set, to avoid following build failure.
> >>>>
> >>>> CC [M] drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.o
> >>>> In file included from ./drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:29,
> >>>> from ./drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:37,
> >>>> from drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:27:
> >>>> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c: In function 'dcn_bw_apply_registry_override':
> >>>> ./drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:64:3: error: implicit declaration of function 'enable_kernel_vsx'; did you mean 'enable_kernel_fp'? [-Werror=implicit-function-declaration]
> >>>> 64 | enable_kernel_vsx(); \
> >>>> | ^~~~~~~~~~~~~~~~~
> >>>> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:640:2: note: in expansion of macro 'DC_FP_START'
> >>>> 640 | DC_FP_START();
> >>>> | ^~~~~~~~~~~
> >>>> ./drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:75:3: error: implicit declaration of function 'disable_kernel_vsx'; did you mean 'disable_kernel_fp'? [-Werror=implicit-function-declaration]
> >>>> 75 | disable_kernel_vsx(); \
> >>>> | ^~~~~~~~~~~~~~~~~~
> >>>> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:676:2: note: in expansion of macro 'DC_FP_END'
> >>>> 676 | DC_FP_END();
> >>>> | ^~~~~~~~~
> >>>> cc1: some warnings being treated as errors
> >>>> make[5]: *** [drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.o] Error 1
> >>>>
> >>>> Fixes: 16a9dea110a6 ("amdgpu: Enable initial DCN support on POWER")
> >>>> Cc: stable@vger.kernel.org
> >>>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> >>>
> >>> Thanks for your patch!
> >>>
> >>>> --- a/arch/powerpc/include/asm/switch_to.h
> >>>> +++ b/arch/powerpc/include/asm/switch_to.h
> >>>> @@ -71,6 +71,16 @@ static inline void disable_kernel_vsx(void)
> >>>> {
> >>>> msr_check_and_clear(MSR_FP|MSR_VEC|MSR_VSX);
> >>>> }
> >>>> +#else
> >>>> +static inline void enable_kernel_vsx(void)
> >>>> +{
> >>>> + BUILD_BUG();
> >>>> +}
> >>>> +
> >>>> +static inline void disable_kernel_vsx(void)
> >>>> +{
> >>>> + BUILD_BUG();
> >>>> +}
> >>>> #endif
> >>>
> >>> I'm wondering how this is any better than the current situation: using
> >>> BUILD_BUG() will still cause a build failure?
> >>
> >> No it won't cause a failure. In drivers/gpu/drm/amd/display/dc/os_types.h you have:
> >>
> >> #define DC_FP_START() { \
> >> if (cpu_has_feature(CPU_FTR_VSX_COMP)) { \
> >> preempt_disable(); \
> >> enable_kernel_vsx(); \
> >> } else if (cpu_has_feature(CPU_FTR_ALTIVEC_COMP)) { \
> >> preempt_disable(); \
> >> enable_kernel_altivec(); \
> >> } else if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE)) { \
> >> preempt_disable(); \
> >> enable_kernel_fp(); \
> >> } \
> >>
> >> When CONFIG_VSX is not selected, cpu_has_feature(CPU_FTR_VSX_COMP) constant folds to 'false' so the
> >> call to enable_kernel_vsx() is discarded and the build succeeds.
> >
> > IC. So you might as well have an empty (dummy) function instead?
> >
>
> But with an empty function, you take the risk that one day, someone calls it without checking that
> CONFIG_VSX is selected. Here if someone does that, build will fail.
OK, convinced.
> Another solution is to declare a non static prototype of it, like __put_user_bad() for instance. In
> that case, the link will fail.
>
> I prefer the BUILD_BUG() approach as I find it cleaner and more explicit, and also because it breaks
> the build at compile time, you don't have to wait link time to catch the error.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] powerpc/64s: Use symbolic macros for function entry encoding
From: Naveen N. Rao @ 2021-03-09 10:42 UTC (permalink / raw)
To: Michael Ellerman; +Cc: naveen.n.rao, linuxppc-dev
In-Reply-To: <20210309071544.515303-1-mpe@ellerman.id.au>
On 2021/03/09 06:15PM, Michael Ellerman wrote:
> In ppc_function_entry() we look for a specific set of instructions by
> masking the instructions and comparing with a known value. Currently
> those known values are just literal hex values, and we recently
> discovered one of them was wrong.
>
> Instead construct the values using the existing constants we have for
> defining various fields of instructions.
>
> Suggested-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
> arch/powerpc/include/asm/code-patching.h | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
Thanks,
Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
- Naveen
^ permalink raw reply
* Re: [PATCH v2 7/8] powerpc/xive: Fix xmon command "dxi"
From: Greg Kurz @ 2021-03-09 10:23 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: linuxppc-dev, kernel test robot, Dan Carpenter
In-Reply-To: <20210303174857.1760393-8-clg@kaod.org>
On Wed, 3 Mar 2021 18:48:56 +0100
Cédric Le Goater <clg@kaod.org> wrote:
> When under xmon, the "dxi" command dumps the state of the XIVE
> interrupts. If an interrupt number is specified, only the state of
> the associated XIVE interrupt is dumped. This form of the command
> lacks an irq_data parameter which is nevertheless used by
> xmon_xive_get_irq_config(), leading to an xmon crash.
>
> Fix that by doing a lookup in the system IRQ mapping to query the IRQ
> descriptor data. Invalid interrupt numbers, or not belonging to the
> XIVE IRQ domain, OPAL event interrupt number for instance, should be
> caught by the previous query done at the firmware level.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Fixes: 97ef27507793 ("powerpc/xive: Fix xmon support on the PowerNV platform")
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
I've tested this in a KVM guest and it seems to do the job.
6:mon> dxi 1201
IRQ 0x00001201 : target=0xfffffc00 prio=ff lirq=0x0 flags= LH PQ=-Q
Bad HW irq numbers are filtered by the hypervisor:
6:mon> dxi bad
[ 696.390577] xive: H_INT_GET_SOURCE_CONFIG lisn=2989 failed -55
IRQ 0x00000bad : no config rc=-6
Note that this also allows to show IPIs:
6:mon> dxi 0
IRQ 0x00000000 : target=0x0 prio=06 lirq=0x10
This is a bit inconsistent with output of the 0-argument form of "dxi",
which filters them out for a reason that isn't obvious to me. No big
deal though, this should be addressed in another patch anyway.
Reviewed-and-tested-by: Greg Kurz <groug@kaod.org>
> arch/powerpc/sysdev/xive/common.c | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
> index f6b7b15bbb3a..8eefd152b947 100644
> --- a/arch/powerpc/sysdev/xive/common.c
> +++ b/arch/powerpc/sysdev/xive/common.c
> @@ -255,17 +255,20 @@ notrace void xmon_xive_do_dump(int cpu)
> xmon_printf("\n");
> }
>
> +static struct irq_data *xive_get_irq_data(u32 hw_irq)
> +{
> + unsigned int irq = irq_find_mapping(xive_irq_domain, hw_irq);
> +
> + return irq ? irq_get_irq_data(irq) : NULL;
> +}
> +
> int xmon_xive_get_irq_config(u32 hw_irq, struct irq_data *d)
> {
> - struct irq_chip *chip = irq_data_get_irq_chip(d);
> int rc;
> u32 target;
> u8 prio;
> u32 lirq;
>
> - if (!is_xive_irq(chip))
> - return -EINVAL;
> -
> rc = xive_ops->get_irq_config(hw_irq, &target, &prio, &lirq);
> if (rc) {
> xmon_printf("IRQ 0x%08x : no config rc=%d\n", hw_irq, rc);
> @@ -275,6 +278,9 @@ int xmon_xive_get_irq_config(u32 hw_irq, struct irq_data *d)
> xmon_printf("IRQ 0x%08x : target=0x%x prio=%02x lirq=0x%x ",
> hw_irq, target, prio, lirq);
>
> + if (!d)
> + d = xive_get_irq_data(hw_irq);
> +
> if (d) {
> struct xive_irq_data *xd = irq_data_get_irq_handler_data(d);
> u64 val = xive_esb_read(xd, XIVE_ESB_GET);
^ permalink raw reply
* Re: [PATCH 0/6] mm: some config cleanups
From: Heiko Carstens @ 2021-03-09 10:12 UTC (permalink / raw)
To: Anshuman Khandual
Cc: linux-s390, linux-ia64, linux-parisc, linux-sh, x86, linux-mips,
linux-kernel, linux-mm, linux-fsdevel, linux-riscv,
linux-snps-arc, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1615278790-18053-1-git-send-email-anshuman.khandual@arm.com>
On Tue, Mar 09, 2021 at 02:03:04PM +0530, Anshuman Khandual wrote:
> This series contains config cleanup patches which reduces code duplication
> across platforms and also improves maintainability. There is no functional
> change intended with this series. This has been boot tested on arm64 but
> only build tested on some other platforms.
>
> This applies on 5.12-rc2
>
> Cc: x86@kernel.org
> Cc: linux-ia64@vger.kernel.org
> Cc: linux-s390@vger.kernel.org
> Cc: linux-snps-arc@lists.infradead.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-mips@vger.kernel.org
> Cc: linux-parisc@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-riscv@lists.infradead.org
> Cc: linux-sh@vger.kernel.org
> Cc: linux-fsdevel@vger.kernel.org
> Cc: linux-mm@kvack.org
> Cc: linux-kernel@vger.kernel.org
>
> Anshuman Khandual (6):
> mm: Generalize ARCH_HAS_CACHE_LINE_SIZE
> mm: Generalize SYS_SUPPORTS_HUGETLBFS (rename as ARCH_SUPPORTS_HUGETLBFS)
> mm: Generalize ARCH_ENABLE_MEMORY_[HOTPLUG|HOTREMOVE]
> mm: Drop redundant ARCH_ENABLE_[HUGEPAGE|THP]_MIGRATION
> mm: Drop redundant ARCH_ENABLE_SPLIT_PMD_PTLOCK
> mm: Drop redundant HAVE_ARCH_TRANSPARENT_HUGEPAGE
>
> arch/arc/Kconfig | 9 ++------
> arch/arm/Kconfig | 10 ++-------
> arch/arm64/Kconfig | 30 ++++++--------------------
> arch/ia64/Kconfig | 8 ++-----
> arch/mips/Kconfig | 6 +-----
> arch/parisc/Kconfig | 5 +----
> arch/powerpc/Kconfig | 11 ++--------
> arch/powerpc/platforms/Kconfig.cputype | 16 +++++---------
> arch/riscv/Kconfig | 5 +----
> arch/s390/Kconfig | 12 +++--------
> arch/sh/Kconfig | 7 +++---
> arch/sh/mm/Kconfig | 8 -------
> arch/x86/Kconfig | 29 ++++++-------------------
> fs/Kconfig | 5 ++++-
> mm/Kconfig | 9 ++++++++
> 15 files changed, 48 insertions(+), 122 deletions(-)
for the s390 bits:
Acked-by: Heiko Carstens <hca@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH] powerpc: Fix missing declaration of [en/dis]able_kernel_vsx()
From: Christophe Leroy @ 2021-03-09 9:57 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux Kernel Mailing List, amd-gfx list, Paul Mackerras,
Alex Deucher, linuxppc-dev, Christian König
In-Reply-To: <CAMuHMdXM0qg23UN6VBqbb0Vm2bg3tRSM=OCD5r7U2K1brpnJAg@mail.gmail.com>
Le 09/03/2021 à 10:16, Geert Uytterhoeven a écrit :
> Hi Christophe,
>
> On Tue, Mar 9, 2021 at 9:52 AM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>> Le 09/03/2021 à 09:45, Geert Uytterhoeven a écrit :
>>> On Tue, Mar 9, 2021 at 9:39 AM Christophe Leroy
>>> <christophe.leroy@csgroup.eu> wrote:
>>>> Add stub instances of enable_kernel_vsx() and disable_kernel_vsx()
>>>> when CONFIG_VSX is not set, to avoid following build failure.
>>>>
>>>> CC [M] drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.o
>>>> In file included from ./drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:29,
>>>> from ./drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:37,
>>>> from drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:27:
>>>> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c: In function 'dcn_bw_apply_registry_override':
>>>> ./drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:64:3: error: implicit declaration of function 'enable_kernel_vsx'; did you mean 'enable_kernel_fp'? [-Werror=implicit-function-declaration]
>>>> 64 | enable_kernel_vsx(); \
>>>> | ^~~~~~~~~~~~~~~~~
>>>> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:640:2: note: in expansion of macro 'DC_FP_START'
>>>> 640 | DC_FP_START();
>>>> | ^~~~~~~~~~~
>>>> ./drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:75:3: error: implicit declaration of function 'disable_kernel_vsx'; did you mean 'disable_kernel_fp'? [-Werror=implicit-function-declaration]
>>>> 75 | disable_kernel_vsx(); \
>>>> | ^~~~~~~~~~~~~~~~~~
>>>> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:676:2: note: in expansion of macro 'DC_FP_END'
>>>> 676 | DC_FP_END();
>>>> | ^~~~~~~~~
>>>> cc1: some warnings being treated as errors
>>>> make[5]: *** [drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.o] Error 1
>>>>
>>>> Fixes: 16a9dea110a6 ("amdgpu: Enable initial DCN support on POWER")
>>>> Cc: stable@vger.kernel.org
>>>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>>>
>>> Thanks for your patch!
>>>
>>>> --- a/arch/powerpc/include/asm/switch_to.h
>>>> +++ b/arch/powerpc/include/asm/switch_to.h
>>>> @@ -71,6 +71,16 @@ static inline void disable_kernel_vsx(void)
>>>> {
>>>> msr_check_and_clear(MSR_FP|MSR_VEC|MSR_VSX);
>>>> }
>>>> +#else
>>>> +static inline void enable_kernel_vsx(void)
>>>> +{
>>>> + BUILD_BUG();
>>>> +}
>>>> +
>>>> +static inline void disable_kernel_vsx(void)
>>>> +{
>>>> + BUILD_BUG();
>>>> +}
>>>> #endif
>>>
>>> I'm wondering how this is any better than the current situation: using
>>> BUILD_BUG() will still cause a build failure?
>>
>> No it won't cause a failure. In drivers/gpu/drm/amd/display/dc/os_types.h you have:
>>
>> #define DC_FP_START() { \
>> if (cpu_has_feature(CPU_FTR_VSX_COMP)) { \
>> preempt_disable(); \
>> enable_kernel_vsx(); \
>> } else if (cpu_has_feature(CPU_FTR_ALTIVEC_COMP)) { \
>> preempt_disable(); \
>> enable_kernel_altivec(); \
>> } else if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE)) { \
>> preempt_disable(); \
>> enable_kernel_fp(); \
>> } \
>>
>> When CONFIG_VSX is not selected, cpu_has_feature(CPU_FTR_VSX_COMP) constant folds to 'false' so the
>> call to enable_kernel_vsx() is discarded and the build succeeds.
>
> IC. So you might as well have an empty (dummy) function instead?
>
But with an empty function, you take the risk that one day, someone calls it without checking that
CONFIG_VSX is selected. Here if someone does that, build will fail.
Another solution is to declare a non static prototype of it, like __put_user_bad() for instance. In
that case, the link will fail.
I prefer the BUILD_BUG() approach as I find it cleaner and more explicit, and also because it breaks
the build at compile time, you don't have to wait link time to catch the error.
Christophe
^ permalink raw reply
* Re: [PATCH v4] powerpc/uprobes: Validation for prefixed instruction
From: Michael Ellerman @ 2021-03-09 9:54 UTC (permalink / raw)
To: Ravi Bangoria
Cc: ravi.bangoria, jniethe5, oleg, rostedt, linux-kernel, paulus,
sandipan, naveen.n.rao, linuxppc-dev
In-Reply-To: <20210305115433.140769-1-ravi.bangoria@linux.ibm.com>
Ravi Bangoria <ravi.bangoria@linux.ibm.com> writes:
> As per ISA 3.1, prefixed instruction should not cross 64-byte
> boundary. So don't allow Uprobe on such prefixed instruction.
>
> There are two ways probed instruction is changed in mapped pages.
> First, when Uprobe is activated, it searches for all the relevant
> pages and replace instruction in them. In this case, if that probe
> is on the 64-byte unaligned prefixed instruction, error out
> directly. Second, when Uprobe is already active and user maps a
> relevant page via mmap(), instruction is replaced via mmap() code
> path. But because Uprobe is invalid, entire mmap() operation can
> not be stopped. In this case just print an error and continue.
>
> Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
> Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Do we have a Fixes: tag for this?
> ---
> v3: https://lore.kernel.org/r/20210304050529.59391-1-ravi.bangoria@linux.ibm.com
> v3->v4:
> - CONFIG_PPC64 check was not required, remove it.
> - Use SZ_ macros instead of hardcoded numbers.
>
> arch/powerpc/kernel/uprobes.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel/uprobes.c
> index e8a63713e655..4cbfff6e94a3 100644
> --- a/arch/powerpc/kernel/uprobes.c
> +++ b/arch/powerpc/kernel/uprobes.c
> @@ -41,6 +41,13 @@ int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe,
> if (addr & 0x03)
> return -EINVAL;
>
> + if (cpu_has_feature(CPU_FTR_ARCH_31) &&
> + ppc_inst_prefixed(auprobe->insn) &&
> + (addr & (SZ_64 - 4)) == SZ_64 - 4) {
> + pr_info_ratelimited("Cannot register a uprobe on 64 byte unaligned prefixed instruction\n");
> + return -EINVAL;
I realise we already did the 0x03 check above, but I still think this
would be clearer simply as:
(addr & 0x3f == 60)
cheers
^ permalink raw reply
* Re: [PATCH v2 4/8] powerpc/xive: Simplify xive_core_debug_show()
From: Greg Kurz @ 2021-03-09 9:42 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: linuxppc-dev
In-Reply-To: <20210309101339.1b1e2d4e@bahia.lan>
On Tue, 9 Mar 2021 10:13:39 +0100
Greg Kurz <groug@kaod.org> wrote:
> On Mon, 8 Mar 2021 19:11:11 +0100
> Cédric Le Goater <clg@kaod.org> wrote:
>
> > On 3/8/21 7:07 PM, Greg Kurz wrote:
> > > On Wed, 3 Mar 2021 18:48:53 +0100
> > > Cédric Le Goater <clg@kaod.org> wrote:
> > >
> > >> Now that the IPI interrupt has its own domain, the checks on the HW
> > >> interrupt number XIVE_IPI_HW_IRQ and on the chip can be replaced by a
> > >> check on the domain.
> > >>
> > >> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> > >> ---
> > >
> > > Shouldn't this have the following tags ?
> > >
> > > Reported-by: kernel test robot <lkp@intel.com>
> > > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> > > Fixes: 930914b7d528 ("powerpc/xive: Add a debugfs file to dump internal XIVE state")
> >
> > The next patch has because it removes the useless check on irq_data.
> >
>
> Ok I get it. This report isn't about an actual crash. Just a false
> positive because of the not needed check in the caller.
>
Hrm... I meant because of the check in xive_debug_show_irq(). On the
contrary, the check removed by this patch in xive_core_debug_show()
was rather an explicit hint that xive_debug_show_irq() couldn't be
called with d being NULL.
> > C.
> >
> > >
> > > Anyway,
> > >
> > > Reviewed-by: Greg Kurz <groug@kaod.org>
> > >
> > >> arch/powerpc/sysdev/xive/common.c | 18 ++++--------------
> > >> 1 file changed, 4 insertions(+), 14 deletions(-)
> > >>
> > >> diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
> > >> index 678680531d26..7581cb12bb53 100644
> > >> --- a/arch/powerpc/sysdev/xive/common.c
> > >> +++ b/arch/powerpc/sysdev/xive/common.c
> > >> @@ -1579,17 +1579,14 @@ static void xive_debug_show_cpu(struct seq_file *m, int cpu)
> > >> seq_puts(m, "\n");
> > >> }
> > >>
> > >> -static void xive_debug_show_irq(struct seq_file *m, u32 hw_irq, struct irq_data *d)
> > >> +static void xive_debug_show_irq(struct seq_file *m, struct irq_data *d)
> > >> {
> > >> - struct irq_chip *chip = irq_data_get_irq_chip(d);
> > >> + unsigned int hw_irq = (unsigned int)irqd_to_hwirq(d);
> > >> int rc;
> > >> u32 target;
> > >> u8 prio;
> > >> u32 lirq;
> > >>
> > >> - if (!is_xive_irq(chip))
> > >> - return;
> > >> -
> > >> rc = xive_ops->get_irq_config(hw_irq, &target, &prio, &lirq);
> > >> if (rc) {
> > >> seq_printf(m, "IRQ 0x%08x : no config rc=%d\n", hw_irq, rc);
> > >> @@ -1627,16 +1624,9 @@ static int xive_core_debug_show(struct seq_file *m, void *private)
> > >>
> > >> for_each_irq_desc(i, desc) {
> > >> struct irq_data *d = irq_desc_get_irq_data(desc);
> > >> - unsigned int hw_irq;
> > >> -
> > >> - if (!d)
> > >> - continue;
> > >> -
> > >> - hw_irq = (unsigned int)irqd_to_hwirq(d);
> > >>
> > >> - /* IPIs are special (HW number 0) */
> > >> - if (hw_irq != XIVE_IPI_HW_IRQ)
> > >> - xive_debug_show_irq(m, hw_irq, d);
> > >> + if (d->domain == xive_irq_domain)
> > >> + xive_debug_show_irq(m, d);
> > >> }
> > >> return 0;
> > >> }
> > >
> >
>
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/qspinlock: Use generic smp_cond_load_relaxed
From: Michal Suchánek @ 2021-03-09 9:39 UTC (permalink / raw)
To: Davidlohr Bueso
Cc: Davidlohr Bueso, peterz, will, linux-kernel, npiggin, mingo,
paulus, longman, linuxppc-dev
In-Reply-To: <20210309015950.27688-4-dave@stgolabs.net>
On Mon, Mar 08, 2021 at 05:59:50PM -0800, Davidlohr Bueso wrote:
> 49a7d46a06c3 (powerpc: Implement smp_cond_load_relaxed()) added
> busy-waiting pausing with a preferred SMT priority pattern, lowering
> the priority (reducing decode cycles) during the whole loop slowpath.
>
> However, data shows that while this pattern works well with simple
^^^^^^^^^^^^^^^^^^^^^^
> spinlocks, queued spinlocks benefit more being kept in medium priority,
> with a cpu_relax() instead, being a low+medium combo on powerpc.
...
>
> diff --git a/arch/powerpc/include/asm/barrier.h b/arch/powerpc/include/asm/barrier.h
> index aecfde829d5d..7ae29cfb06c0 100644
> --- a/arch/powerpc/include/asm/barrier.h
> +++ b/arch/powerpc/include/asm/barrier.h
> @@ -80,22 +80,6 @@ do { \
> ___p1; \
> })
>
> -#ifdef CONFIG_PPC64
Maybe it should be kept for the simple spinlock case then?
Thanks
Michal
> -#define smp_cond_load_relaxed(ptr, cond_expr) ({ \
> - typeof(ptr) __PTR = (ptr); \
> - __unqual_scalar_typeof(*ptr) VAL; \
> - VAL = READ_ONCE(*__PTR); \
> - if (unlikely(!(cond_expr))) { \
> - spin_begin(); \
> - do { \
> - VAL = READ_ONCE(*__PTR); \
> - } while (!(cond_expr)); \
> - spin_end(); \
> - } \
> - (typeof(*ptr))VAL; \
> -})
> -#endif
> -
> #ifdef CONFIG_PPC_BOOK3S_64
> #define NOSPEC_BARRIER_SLOT nop
> #elif defined(CONFIG_PPC_FSL_BOOK3E)
> --
> 2.26.2
>
^ permalink raw reply
* Re: [PATCH v2 5/8] powerpc/xive: Drop check on irq_data in xive_core_debug_show()
From: Greg Kurz @ 2021-03-09 9:18 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: linuxppc-dev, kernel test robot, Dan Carpenter
In-Reply-To: <20210303174857.1760393-6-clg@kaod.org>
On Wed, 3 Mar 2021 18:48:54 +0100
Cédric Le Goater <clg@kaod.org> wrote:
> When looping on IRQ descriptor, irq_data is always valid.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Fixes: 930914b7d528 ("powerpc/xive: Add a debugfs file to dump internal XIVE state")
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
Reviewed-by: Greg Kurz <groug@kaod.org>
> arch/powerpc/sysdev/xive/common.c | 21 ++++++++++-----------
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
> index 7581cb12bb53..60ebd6f4b31d 100644
> --- a/arch/powerpc/sysdev/xive/common.c
> +++ b/arch/powerpc/sysdev/xive/common.c
> @@ -1586,6 +1586,8 @@ static void xive_debug_show_irq(struct seq_file *m, struct irq_data *d)
> u32 target;
> u8 prio;
> u32 lirq;
> + struct xive_irq_data *xd;
> + u64 val;
>
> rc = xive_ops->get_irq_config(hw_irq, &target, &prio, &lirq);
> if (rc) {
> @@ -1596,17 +1598,14 @@ static void xive_debug_show_irq(struct seq_file *m, struct irq_data *d)
> seq_printf(m, "IRQ 0x%08x : target=0x%x prio=%02x lirq=0x%x ",
> hw_irq, target, prio, lirq);
>
> - if (d) {
> - struct xive_irq_data *xd = irq_data_get_irq_handler_data(d);
> - u64 val = xive_esb_read(xd, XIVE_ESB_GET);
> -
> - seq_printf(m, "flags=%c%c%c PQ=%c%c",
> - xd->flags & XIVE_IRQ_FLAG_STORE_EOI ? 'S' : ' ',
> - xd->flags & XIVE_IRQ_FLAG_LSI ? 'L' : ' ',
> - xd->flags & XIVE_IRQ_FLAG_H_INT_ESB ? 'H' : ' ',
> - val & XIVE_ESB_VAL_P ? 'P' : '-',
> - val & XIVE_ESB_VAL_Q ? 'Q' : '-');
> - }
> + xd = irq_data_get_irq_handler_data(d);
> + val = xive_esb_read(xd, XIVE_ESB_GET);
> + seq_printf(m, "flags=%c%c%c PQ=%c%c",
> + xd->flags & XIVE_IRQ_FLAG_STORE_EOI ? 'S' : ' ',
> + xd->flags & XIVE_IRQ_FLAG_LSI ? 'L' : ' ',
> + xd->flags & XIVE_IRQ_FLAG_H_INT_ESB ? 'H' : ' ',
> + val & XIVE_ESB_VAL_P ? 'P' : '-',
> + val & XIVE_ESB_VAL_Q ? 'Q' : '-');
> seq_puts(m, "\n");
> }
>
^ permalink raw reply
* Re: [PATCH v2 6/8] powerpc/xive: Simplify the dump of XIVE interrupts under xmon
From: Greg Kurz @ 2021-03-09 9:22 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: linuxppc-dev
In-Reply-To: <20210303174857.1760393-7-clg@kaod.org>
On Wed, 3 Mar 2021 18:48:55 +0100
Cédric Le Goater <clg@kaod.org> wrote:
> Move the xmon routine under XIVE subsystem and rework the loop on the
> interrupts taking into account the xive_irq_domain to filter out IPIs.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
Nice again ! :)
Reviewed-by: Greg Kurz <groug@kaod.org>
> arch/powerpc/include/asm/xive.h | 1 +
> arch/powerpc/sysdev/xive/common.c | 14 ++++++++++++++
> arch/powerpc/xmon/xmon.c | 28 ++--------------------------
> 3 files changed, 17 insertions(+), 26 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/xive.h b/arch/powerpc/include/asm/xive.h
> index 9a312b975ca8..aa094a8655b0 100644
> --- a/arch/powerpc/include/asm/xive.h
> +++ b/arch/powerpc/include/asm/xive.h
> @@ -102,6 +102,7 @@ void xive_flush_interrupt(void);
> /* xmon hook */
> void xmon_xive_do_dump(int cpu);
> int xmon_xive_get_irq_config(u32 hw_irq, struct irq_data *d);
> +void xmon_xive_get_irq_all(void);
>
> /* APIs used by KVM */
> u32 xive_native_default_eq_shift(void);
> diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
> index 60ebd6f4b31d..f6b7b15bbb3a 100644
> --- a/arch/powerpc/sysdev/xive/common.c
> +++ b/arch/powerpc/sysdev/xive/common.c
> @@ -291,6 +291,20 @@ int xmon_xive_get_irq_config(u32 hw_irq, struct irq_data *d)
> return 0;
> }
>
> +void xmon_xive_get_irq_all(void)
> +{
> + unsigned int i;
> + struct irq_desc *desc;
> +
> + for_each_irq_desc(i, desc) {
> + struct irq_data *d = irq_desc_get_irq_data(desc);
> + unsigned int hwirq = (unsigned int)irqd_to_hwirq(d);
> +
> + if (d->domain == xive_irq_domain)
> + xmon_xive_get_irq_config(hwirq, d);
> + }
> +}
> +
> #endif /* CONFIG_XMON */
>
> static unsigned int xive_get_irq(void)
> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> index 3fe37495f63d..80fbf8968f77 100644
> --- a/arch/powerpc/xmon/xmon.c
> +++ b/arch/powerpc/xmon/xmon.c
> @@ -2727,30 +2727,6 @@ static void dump_all_xives(void)
> dump_one_xive(cpu);
> }
>
> -static void dump_one_xive_irq(u32 num, struct irq_data *d)
> -{
> - xmon_xive_get_irq_config(num, d);
> -}
> -
> -static void dump_all_xive_irq(void)
> -{
> - unsigned int i;
> - struct irq_desc *desc;
> -
> - for_each_irq_desc(i, desc) {
> - struct irq_data *d = irq_desc_get_irq_data(desc);
> - unsigned int hwirq;
> -
> - if (!d)
> - continue;
> -
> - hwirq = (unsigned int)irqd_to_hwirq(d);
> - /* IPIs are special (HW number 0) */
> - if (hwirq)
> - dump_one_xive_irq(hwirq, d);
> - }
> -}
> -
> static void dump_xives(void)
> {
> unsigned long num;
> @@ -2767,9 +2743,9 @@ static void dump_xives(void)
> return;
> } else if (c == 'i') {
> if (scanhex(&num))
> - dump_one_xive_irq(num, NULL);
> + xmon_xive_get_irq_config(num, NULL);
> else
> - dump_all_xive_irq();
> + xmon_xive_get_irq_all();
> return;
> }
>
^ permalink raw reply
* Re: [PATCH] powerpc: Fix missing declaration of [en/dis]able_kernel_vsx()
From: Geert Uytterhoeven @ 2021-03-09 9:16 UTC (permalink / raw)
To: Christophe Leroy
Cc: Linux Kernel Mailing List, amd-gfx list, Paul Mackerras,
Alex Deucher, linuxppc-dev, Christian König
In-Reply-To: <b12f9128-790b-7d8b-5f3c-e0912f5bec0a@csgroup.eu>
Hi Christophe,
On Tue, Mar 9, 2021 at 9:52 AM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
> Le 09/03/2021 à 09:45, Geert Uytterhoeven a écrit :
> > On Tue, Mar 9, 2021 at 9:39 AM Christophe Leroy
> > <christophe.leroy@csgroup.eu> wrote:
> >> Add stub instances of enable_kernel_vsx() and disable_kernel_vsx()
> >> when CONFIG_VSX is not set, to avoid following build failure.
> >>
> >> CC [M] drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.o
> >> In file included from ./drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:29,
> >> from ./drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:37,
> >> from drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:27:
> >> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c: In function 'dcn_bw_apply_registry_override':
> >> ./drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:64:3: error: implicit declaration of function 'enable_kernel_vsx'; did you mean 'enable_kernel_fp'? [-Werror=implicit-function-declaration]
> >> 64 | enable_kernel_vsx(); \
> >> | ^~~~~~~~~~~~~~~~~
> >> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:640:2: note: in expansion of macro 'DC_FP_START'
> >> 640 | DC_FP_START();
> >> | ^~~~~~~~~~~
> >> ./drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:75:3: error: implicit declaration of function 'disable_kernel_vsx'; did you mean 'disable_kernel_fp'? [-Werror=implicit-function-declaration]
> >> 75 | disable_kernel_vsx(); \
> >> | ^~~~~~~~~~~~~~~~~~
> >> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:676:2: note: in expansion of macro 'DC_FP_END'
> >> 676 | DC_FP_END();
> >> | ^~~~~~~~~
> >> cc1: some warnings being treated as errors
> >> make[5]: *** [drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.o] Error 1
> >>
> >> Fixes: 16a9dea110a6 ("amdgpu: Enable initial DCN support on POWER")
> >> Cc: stable@vger.kernel.org
> >> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> >
> > Thanks for your patch!
> >
> >> --- a/arch/powerpc/include/asm/switch_to.h
> >> +++ b/arch/powerpc/include/asm/switch_to.h
> >> @@ -71,6 +71,16 @@ static inline void disable_kernel_vsx(void)
> >> {
> >> msr_check_and_clear(MSR_FP|MSR_VEC|MSR_VSX);
> >> }
> >> +#else
> >> +static inline void enable_kernel_vsx(void)
> >> +{
> >> + BUILD_BUG();
> >> +}
> >> +
> >> +static inline void disable_kernel_vsx(void)
> >> +{
> >> + BUILD_BUG();
> >> +}
> >> #endif
> >
> > I'm wondering how this is any better than the current situation: using
> > BUILD_BUG() will still cause a build failure?
>
> No it won't cause a failure. In drivers/gpu/drm/amd/display/dc/os_types.h you have:
>
> #define DC_FP_START() { \
> if (cpu_has_feature(CPU_FTR_VSX_COMP)) { \
> preempt_disable(); \
> enable_kernel_vsx(); \
> } else if (cpu_has_feature(CPU_FTR_ALTIVEC_COMP)) { \
> preempt_disable(); \
> enable_kernel_altivec(); \
> } else if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE)) { \
> preempt_disable(); \
> enable_kernel_fp(); \
> } \
>
> When CONFIG_VSX is not selected, cpu_has_feature(CPU_FTR_VSX_COMP) constant folds to 'false' so the
> call to enable_kernel_vsx() is discarded and the build succeeds.
IC. So you might as well have an empty (dummy) function instead?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 4/8] powerpc/xive: Simplify xive_core_debug_show()
From: Greg Kurz @ 2021-03-09 9:13 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: linuxppc-dev
In-Reply-To: <464b873b-b8d9-c656-fb72-365bfca9d8c6@kaod.org>
On Mon, 8 Mar 2021 19:11:11 +0100
Cédric Le Goater <clg@kaod.org> wrote:
> On 3/8/21 7:07 PM, Greg Kurz wrote:
> > On Wed, 3 Mar 2021 18:48:53 +0100
> > Cédric Le Goater <clg@kaod.org> wrote:
> >
> >> Now that the IPI interrupt has its own domain, the checks on the HW
> >> interrupt number XIVE_IPI_HW_IRQ and on the chip can be replaced by a
> >> check on the domain.
> >>
> >> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> >> ---
> >
> > Shouldn't this have the following tags ?
> >
> > Reported-by: kernel test robot <lkp@intel.com>
> > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> > Fixes: 930914b7d528 ("powerpc/xive: Add a debugfs file to dump internal XIVE state")
>
> The next patch has because it removes the useless check on irq_data.
>
Ok I get it. This report isn't about an actual crash. Just a false
positive because of the not needed check in the caller.
> C.
>
> >
> > Anyway,
> >
> > Reviewed-by: Greg Kurz <groug@kaod.org>
> >
> >> arch/powerpc/sysdev/xive/common.c | 18 ++++--------------
> >> 1 file changed, 4 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
> >> index 678680531d26..7581cb12bb53 100644
> >> --- a/arch/powerpc/sysdev/xive/common.c
> >> +++ b/arch/powerpc/sysdev/xive/common.c
> >> @@ -1579,17 +1579,14 @@ static void xive_debug_show_cpu(struct seq_file *m, int cpu)
> >> seq_puts(m, "\n");
> >> }
> >>
> >> -static void xive_debug_show_irq(struct seq_file *m, u32 hw_irq, struct irq_data *d)
> >> +static void xive_debug_show_irq(struct seq_file *m, struct irq_data *d)
> >> {
> >> - struct irq_chip *chip = irq_data_get_irq_chip(d);
> >> + unsigned int hw_irq = (unsigned int)irqd_to_hwirq(d);
> >> int rc;
> >> u32 target;
> >> u8 prio;
> >> u32 lirq;
> >>
> >> - if (!is_xive_irq(chip))
> >> - return;
> >> -
> >> rc = xive_ops->get_irq_config(hw_irq, &target, &prio, &lirq);
> >> if (rc) {
> >> seq_printf(m, "IRQ 0x%08x : no config rc=%d\n", hw_irq, rc);
> >> @@ -1627,16 +1624,9 @@ static int xive_core_debug_show(struct seq_file *m, void *private)
> >>
> >> for_each_irq_desc(i, desc) {
> >> struct irq_data *d = irq_desc_get_irq_data(desc);
> >> - unsigned int hw_irq;
> >> -
> >> - if (!d)
> >> - continue;
> >> -
> >> - hw_irq = (unsigned int)irqd_to_hwirq(d);
> >>
> >> - /* IPIs are special (HW number 0) */
> >> - if (hw_irq != XIVE_IPI_HW_IRQ)
> >> - xive_debug_show_irq(m, hw_irq, d);
> >> + if (d->domain == xive_irq_domain)
> >> + xive_debug_show_irq(m, d);
> >> }
> >> return 0;
> >> }
> >
>
^ permalink raw reply
* Re: [PATCH 0/6] mm: some config cleanups
From: Anshuman Khandual @ 2021-03-09 9:04 UTC (permalink / raw)
To: linux-mm
Cc: linux-s390, linux-ia64, linux-parisc, linux-sh, x86, linux-mips,
linux-kernel, linux-fsdevel, linux-riscv, linux-snps-arc,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <1615278790-18053-1-git-send-email-anshuman.khandual@arm.com>
On 3/9/21 2:03 PM, Anshuman Khandual wrote:
> This series contains config cleanup patches which reduces code duplication
> across platforms and also improves maintainability. There is no functional
> change intended with this series. This has been boot tested on arm64 but
> only build tested on some other platforms.
>
> This applies on 5.12-rc2
>
> Cc: x86@kernel.org
> Cc: linux-ia64@vger.kernel.org
> Cc: linux-s390@vger.kernel.org
> Cc: linux-snps-arc@lists.infradead.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-mips@vger.kernel.org
> Cc: linux-parisc@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-riscv@lists.infradead.org
> Cc: linux-sh@vger.kernel.org
> Cc: linux-fsdevel@vger.kernel.org
> Cc: linux-mm@kvack.org
> Cc: linux-kernel@vger.kernel.org
>
> Anshuman Khandual (6):
> mm: Generalize ARCH_HAS_CACHE_LINE_SIZE
> mm: Generalize SYS_SUPPORTS_HUGETLBFS (rename as ARCH_SUPPORTS_HUGETLBFS)
> mm: Generalize ARCH_ENABLE_MEMORY_[HOTPLUG|HOTREMOVE]
> mm: Drop redundant ARCH_ENABLE_[HUGEPAGE|THP]_MIGRATION
> mm: Drop redundant ARCH_ENABLE_SPLIT_PMD_PTLOCK
> mm: Drop redundant HAVE_ARCH_TRANSPARENT_HUGEPAGE
Again the same thing happened.
https://patchwork.kernel.org/project/linux-mm/list/?series=444393
https://lore.kernel.org/linux-mm/1615278790-18053-1-git-send-email-anshuman.khandual@arm.com/
From past experiences, this problem might be just related to many
entries on the CC list. But this time even dropped the --cc-cover
parameter which would have expanded the CC list on each individual
patches further, like last time.
If it helps, have hosted these six patches on v5.12-rc2
https://gitlab.arm.com/linux-arm/linux-anshuman/-/commits/mm/mm_config_cleanups/v1/
- Anshuman
^ permalink raw reply
* Re: [PATCH] powerpc: Fix missing declaration of [en/dis]able_kernel_vsx()
From: Christophe Leroy @ 2021-03-09 8:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux Kernel Mailing List, amd-gfx list, Paul Mackerras,
Alex Deucher, linuxppc-dev, Christian König
In-Reply-To: <CAMuHMdW0Cn1So8ckvhsT+N+p2hiPiksmCS32jzM0xCUYU4UAdQ@mail.gmail.com>
Le 09/03/2021 à 09:45, Geert Uytterhoeven a écrit :
> Hi Christophe,
>
> On Tue, Mar 9, 2021 at 9:39 AM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>> Add stub instances of enable_kernel_vsx() and disable_kernel_vsx()
>> when CONFIG_VSX is not set, to avoid following build failure.
>>
>> CC [M] drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.o
>> In file included from ./drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:29,
>> from ./drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:37,
>> from drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:27:
>> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c: In function 'dcn_bw_apply_registry_override':
>> ./drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:64:3: error: implicit declaration of function 'enable_kernel_vsx'; did you mean 'enable_kernel_fp'? [-Werror=implicit-function-declaration]
>> 64 | enable_kernel_vsx(); \
>> | ^~~~~~~~~~~~~~~~~
>> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:640:2: note: in expansion of macro 'DC_FP_START'
>> 640 | DC_FP_START();
>> | ^~~~~~~~~~~
>> ./drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:75:3: error: implicit declaration of function 'disable_kernel_vsx'; did you mean 'disable_kernel_fp'? [-Werror=implicit-function-declaration]
>> 75 | disable_kernel_vsx(); \
>> | ^~~~~~~~~~~~~~~~~~
>> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:676:2: note: in expansion of macro 'DC_FP_END'
>> 676 | DC_FP_END();
>> | ^~~~~~~~~
>> cc1: some warnings being treated as errors
>> make[5]: *** [drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.o] Error 1
>>
>> Fixes: 16a9dea110a6 ("amdgpu: Enable initial DCN support on POWER")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>
> Thanks for your patch!
>
>> --- a/arch/powerpc/include/asm/switch_to.h
>> +++ b/arch/powerpc/include/asm/switch_to.h
>> @@ -71,6 +71,16 @@ static inline void disable_kernel_vsx(void)
>> {
>> msr_check_and_clear(MSR_FP|MSR_VEC|MSR_VSX);
>> }
>> +#else
>> +static inline void enable_kernel_vsx(void)
>> +{
>> + BUILD_BUG();
>> +}
>> +
>> +static inline void disable_kernel_vsx(void)
>> +{
>> + BUILD_BUG();
>> +}
>> #endif
>
> I'm wondering how this is any better than the current situation: using
> BUILD_BUG() will still cause a build failure?
No it won't cause a failure. In drivers/gpu/drm/amd/display/dc/os_types.h you have:
#define DC_FP_START() { \
if (cpu_has_feature(CPU_FTR_VSX_COMP)) { \
preempt_disable(); \
enable_kernel_vsx(); \
} else if (cpu_has_feature(CPU_FTR_ALTIVEC_COMP)) { \
preempt_disable(); \
enable_kernel_altivec(); \
} else if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE)) { \
preempt_disable(); \
enable_kernel_fp(); \
} \
When CONFIG_VSX is not selected, cpu_has_feature(CPU_FTR_VSX_COMP) constant folds to 'false' so the
call to enable_kernel_vsx() is discarded and the build succeeds.
>
> What about adding "depends on !POWERPC || VSX" instead, to prevent
> the issue from happening in the first place?
CONFIG_VSX is not required as pointed by the DC_FP_START() macro above and the matching DC_FP_END()
macro.
>
> Gr{oetje,eeting}s,
>
> Geert
>
Christophe
^ permalink raw reply
* Re: [PATCH] powerpc: Fix missing declaration of [en/dis]able_kernel_vsx()
From: Geert Uytterhoeven @ 2021-03-09 8:45 UTC (permalink / raw)
To: Christophe Leroy
Cc: Linux Kernel Mailing List, amd-gfx list, Paul Mackerras,
Alex Deucher, linuxppc-dev, Christian König
In-Reply-To: <8d7d285a027e9d21f5ff7f850fa71a2655b0c4af.1615279170.git.christophe.leroy@csgroup.eu>
Hi Christophe,
On Tue, Mar 9, 2021 at 9:39 AM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
> Add stub instances of enable_kernel_vsx() and disable_kernel_vsx()
> when CONFIG_VSX is not set, to avoid following build failure.
>
> CC [M] drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.o
> In file included from ./drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:29,
> from ./drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:37,
> from drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:27:
> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c: In function 'dcn_bw_apply_registry_override':
> ./drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:64:3: error: implicit declaration of function 'enable_kernel_vsx'; did you mean 'enable_kernel_fp'? [-Werror=implicit-function-declaration]
> 64 | enable_kernel_vsx(); \
> | ^~~~~~~~~~~~~~~~~
> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:640:2: note: in expansion of macro 'DC_FP_START'
> 640 | DC_FP_START();
> | ^~~~~~~~~~~
> ./drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:75:3: error: implicit declaration of function 'disable_kernel_vsx'; did you mean 'disable_kernel_fp'? [-Werror=implicit-function-declaration]
> 75 | disable_kernel_vsx(); \
> | ^~~~~~~~~~~~~~~~~~
> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:676:2: note: in expansion of macro 'DC_FP_END'
> 676 | DC_FP_END();
> | ^~~~~~~~~
> cc1: some warnings being treated as errors
> make[5]: *** [drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.o] Error 1
>
> Fixes: 16a9dea110a6 ("amdgpu: Enable initial DCN support on POWER")
> Cc: stable@vger.kernel.org
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Thanks for your patch!
> --- a/arch/powerpc/include/asm/switch_to.h
> +++ b/arch/powerpc/include/asm/switch_to.h
> @@ -71,6 +71,16 @@ static inline void disable_kernel_vsx(void)
> {
> msr_check_and_clear(MSR_FP|MSR_VEC|MSR_VSX);
> }
> +#else
> +static inline void enable_kernel_vsx(void)
> +{
> + BUILD_BUG();
> +}
> +
> +static inline void disable_kernel_vsx(void)
> +{
> + BUILD_BUG();
> +}
> #endif
I'm wondering how this is any better than the current situation: using
BUILD_BUG() will still cause a build failure?
What about adding "depends on !POWERPC || VSX" instead, to prevent
the issue from happening in the first place?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] powerpc: Fix missing declaration of [en/dis]able_kernel_vsx()
From: Christophe Leroy @ 2021-03-09 8:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, geert
Cc: alexdeucher, linuxppc-dev, linux-kernel, amd-gfx,
christian.koenig
Add stub instances of enable_kernel_vsx() and disable_kernel_vsx()
when CONFIG_VSX is not set, to avoid following build failure.
CC [M] drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.o
In file included from ./drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:29,
from ./drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:37,
from drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:27:
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c: In function 'dcn_bw_apply_registry_override':
./drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:64:3: error: implicit declaration of function 'enable_kernel_vsx'; did you mean 'enable_kernel_fp'? [-Werror=implicit-function-declaration]
64 | enable_kernel_vsx(); \
| ^~~~~~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:640:2: note: in expansion of macro 'DC_FP_START'
640 | DC_FP_START();
| ^~~~~~~~~~~
./drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:75:3: error: implicit declaration of function 'disable_kernel_vsx'; did you mean 'disable_kernel_fp'? [-Werror=implicit-function-declaration]
75 | disable_kernel_vsx(); \
| ^~~~~~~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:676:2: note: in expansion of macro 'DC_FP_END'
676 | DC_FP_END();
| ^~~~~~~~~
cc1: some warnings being treated as errors
make[5]: *** [drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.o] Error 1
Fixes: 16a9dea110a6 ("amdgpu: Enable initial DCN support on POWER")
Cc: stable@vger.kernel.org
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/include/asm/switch_to.h | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/powerpc/include/asm/switch_to.h b/arch/powerpc/include/asm/switch_to.h
index fdab93428372..9d1fbd8be1c7 100644
--- a/arch/powerpc/include/asm/switch_to.h
+++ b/arch/powerpc/include/asm/switch_to.h
@@ -71,6 +71,16 @@ static inline void disable_kernel_vsx(void)
{
msr_check_and_clear(MSR_FP|MSR_VEC|MSR_VSX);
}
+#else
+static inline void enable_kernel_vsx(void)
+{
+ BUILD_BUG();
+}
+
+static inline void disable_kernel_vsx(void)
+{
+ BUILD_BUG();
+}
#endif
#ifdef CONFIG_SPE
--
2.25.0
^ permalink raw reply related
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