* [PATCH] powerpc/xmon: Select CONSOLE_POLL for the 8xx
From: Christophe Leroy @ 2020-12-23 9:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <e4471bf81089252470efb3eed735d71a5b32adbd.1608716197.git.christophe.leroy@csgroup.eu>
Powerpc 8xx requires CONSOLE_POLL to get udbg_putc() and
udbg_getc() in CPM uart driver.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index b88900f4832f..ae084357994e 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -88,6 +88,7 @@ config PPC_IRQ_SOFT_MASK_DEBUG
config XMON
bool "Include xmon kernel debugger"
depends on DEBUG_KERNEL
+ select CONSOLE_POLL if SERIAL_CPM_CONSOLE
help
Include in-kernel hooks for the xmon kernel monitor/debugger.
Unless you are intending to debug the kernel, say N here.
--
2.25.0
^ permalink raw reply related
* [PATCH] tty: serial: cpm_uart: Add udbg support for enabling xmon
From: Christophe Leroy @ 2020-12-23 9:38 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, linux-serial; +Cc: linuxppc-dev, linux-kernel
In order to use xmon with powerpc 8xx, the serial driver
must provide udbg_putc() and udpb_getc().
Provide them via cpm_put_poll_char() and cpm_get_poll_char().
This requires CONFIG_CONSOLE_POLL.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
drivers/tty/serial/cpm_uart/cpm_uart_core.c | 40 ++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/cpm_uart/cpm_uart_core.c b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
index ba14ec5b9bc4..2920b9b602b3 100644
--- a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
@@ -1145,6 +1145,32 @@ static void cpm_put_poll_char(struct uart_port *port,
ch[0] = (char)c;
cpm_uart_early_write(pinfo, ch, 1, false);
}
+
+static struct uart_port *udbg_port;
+
+static void udbg_cpm_putc(char c)
+{
+ if (c == '\n')
+ cpm_put_poll_char(udbg_port, '\r');
+ cpm_put_poll_char(udbg_port, c);
+}
+
+static int udbg_cpm_getc_poll(void)
+{
+ int c = cpm_get_poll_char(udbg_port);
+
+ return c == NO_POLL_CHAR ? -1 : c;
+}
+
+static int udbg_cpm_getc(void)
+{
+ int c;
+
+ while ((c = udbg_cpm_getc_poll()) == -1)
+ cpu_relax();
+ return c;
+}
+
#endif /* CONFIG_CONSOLE_POLL */
static const struct uart_ops cpm_uart_pops = {
@@ -1251,7 +1277,10 @@ static int cpm_uart_init_port(struct device_node *np,
pinfo->gpios[i] = NULL;
#ifdef CONFIG_PPC_EARLY_DEBUG_CPM
- udbg_putc = NULL;
+#ifdef CONFIG_CONSOLE_POLL
+ if (!udbg_port)
+#endif
+ udbg_putc = NULL;
#endif
return cpm_uart_request_port(&pinfo->port);
@@ -1370,6 +1399,15 @@ static int __init cpm_uart_console_setup(struct console *co, char *options)
uart_set_options(port, co, baud, parity, bits, flow);
cpm_line_cr_cmd(pinfo, CPM_CR_RESTART_TX);
+#ifdef CONFIG_CONSOLE_POLL
+ if (!udbg_port) {
+ udbg_port = &pinfo->port;
+ udbg_putc = udbg_cpm_putc;
+ udbg_getc = udbg_cpm_getc;
+ udbg_getc_poll = udbg_cpm_getc_poll;
+ }
+#endif
+
return 0;
}
--
2.25.0
^ permalink raw reply related
* [PATCH] powerpc/xmon: Enable breakpoints on 8xx
From: Christophe Leroy @ 2020-12-23 9:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <e4471bf81089252470efb3eed735d71a5b32adbd.1608716197.git.christophe.leroy@csgroup.eu>
Since commit 4ad8622dc548 ("powerpc/8xx: Implement hw_breakpoint"),
8xx has breakpoints so there is no reason to opt breakpoint logic
out of xmon for the 8xx.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Fixes: 4ad8622dc548 ("powerpc/8xx: Implement hw_breakpoint")
---
arch/powerpc/xmon/xmon.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index dcd817ca2edf..cec432eb9189 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -1383,7 +1383,6 @@ static long check_bp_loc(unsigned long addr)
return 1;
}
-#ifndef CONFIG_PPC_8xx
static int find_free_data_bpt(void)
{
int i;
@@ -1395,7 +1394,6 @@ static int find_free_data_bpt(void)
printf("Couldn't find free breakpoint register\n");
return -1;
}
-#endif
static void print_data_bpts(void)
{
@@ -1435,7 +1433,6 @@ bpt_cmds(void)
cmd = inchar();
switch (cmd) {
-#ifndef CONFIG_PPC_8xx
static const char badaddr[] = "Only kernel addresses are permitted for breakpoints\n";
int mode;
case 'd': /* bd - hardware data breakpoint */
@@ -1497,7 +1494,6 @@ bpt_cmds(void)
force_enable_xmon();
}
break;
-#endif
case 'c':
if (!scanhex(&a)) {
--
2.25.0
^ permalink raw reply related
* Re: [PATCH] arch: consolidate pm_power_off callback
From: Geert Uytterhoeven @ 2020-12-23 10:37 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: Rich Felker, linux-ia64@vger.kernel.org, Linux-sh list,
open list:BROADCOM NVRAM DRIVER, James Bottomley, Max Filippov,
Paul Mackerras, linux-csky, H. Peter Anvin, linux-riscv,
Will Deacon, Thomas Gleixner, Jonas Bonn, linux-s390,
Stefano Stabellini, linux-c6x-dev, Yoshinori Sato,
open list:QUALCOMM HEXAGON..., Helge Deller,
the arch/x86 maintainers, Ley Foon Tan, Ingo Molnar,
Catalin Marinas, arcml, open list:TENSILICA XTENSA PORT (xtensa),
Linux PM list, Mark Salter, Aurelien Jacquiot, linux-m68k,
Openrisc, Borislav Petkov, Stafford Horne, Stefan Kristiansson,
Christian Brauner, Chris Zankel, Thomas Bogendoerfer, Parisc List,
linuxppc-dev, Linux Kernel Mailing List, alpha,
Enrico Weigelt, metux IT consult
In-Reply-To: <2f1d53e9-0dbb-78ef-22d5-ab230438ddf0@metux.net>
Hi Enrico,
On Tue, Dec 22, 2020 at 9:15 PM Enrico Weigelt, metux IT consult
<lkml@metux.net> wrote:
> On 22.12.20 19:54, Geert Uytterhoeven wrote:
> > On Tue, Dec 22, 2020 at 7:46 PM Enrico Weigelt, metux IT consult
> > <info@metux.net> wrote:
> >> Move the pm_power_off callback into one global place and also add an
> >> function for conditionally calling it (when not NULL), in order to remove
> >> code duplication in all individual archs.
> >>
> >> Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
> >
> > Thanks for your patch!
> >
> >> --- a/arch/alpha/kernel/process.c
> >> +++ b/arch/alpha/kernel/process.c
> >> @@ -43,12 +43,6 @@
> >> #include "proto.h"
> >> #include "pci_impl.h"
> >>
> >> -/*
> >> - * Power off function, if any
> >> - */
> >> -void (*pm_power_off)(void) = machine_power_off;
> >
> > Assignments like these are lost in the conversion.
>
> Yes, but this doesn't seem to be ever called anyways. (in arch/alpha)
> And, BTW, letting it point to machine_power_off() doesn't make much
> sense, since it's the arch's machine_power_off() function, who're
> calling pm_power_off().
>
> Actually, we could remove pm_power_off completely from here, assuming
> nobody would *build* any drivers that register themselves into
> pm_power_off.
>
> If you feel better with it, I could post a patch that just removes
> pm_power_off from arch/alpha.
This is not limited to alpha, there are similar initializations on
m68k, openrisc,
and s390.
If none of these are called, they can be removed, but you should mention
that in the patch description.
Thanks!
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 -next] misc: ocxl: use DEFINE_MUTEX (and mutex_init() had been too late)
From: Zheng Yongjun @ 2020-12-23 14:12 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: Zheng Yongjun
Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com>
---
drivers/misc/ocxl/file.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
index 4d1b44de1492..e70525eedaae 100644
--- a/drivers/misc/ocxl/file.c
+++ b/drivers/misc/ocxl/file.c
@@ -15,7 +15,7 @@
static dev_t ocxl_dev;
static struct class *ocxl_class;
-static struct mutex minors_idr_lock;
+static DEFINE_MUTEX(minors_idr_lock);
static struct idr minors_idr;
static struct ocxl_file_info *find_and_get_file_info(dev_t devno)
@@ -588,7 +588,6 @@ int ocxl_file_init(void)
{
int rc;
- mutex_init(&minors_idr_lock);
idr_init(&minors_idr);
rc = alloc_chrdev_region(&ocxl_dev, 0, OCXL_NUM_MINORS, "ocxl");
--
2.22.0
^ permalink raw reply related
* [PATCH -next] soc: fsl: qe: Use DEFINE_SPINLOCK() for spinlock
From: Zheng Yongjun @ 2020-12-23 14:14 UTC (permalink / raw)
To: qiang.zhao, leoyang.li, linuxppc-dev, linux-arm-kernel,
linux-kernel
Cc: Zheng Yongjun
spinlock can be initialized automatically with DEFINE_SPINLOCK()
rather than explicitly calling spin_lock_init().
Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com>
---
drivers/soc/fsl/qe/qe_common.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe_common.c b/drivers/soc/fsl/qe/qe_common.c
index 75075591f630..111a36be6983 100644
--- a/drivers/soc/fsl/qe/qe_common.c
+++ b/drivers/soc/fsl/qe/qe_common.c
@@ -26,7 +26,7 @@
#include <soc/fsl/qe/qe.h>
static struct gen_pool *muram_pool;
-static spinlock_t cpm_muram_lock;
+static DEFINE_SPINLOCK(cpm_muram_lock);
static u8 __iomem *muram_vbase;
static phys_addr_t muram_pbase;
@@ -54,7 +54,6 @@ int cpm_muram_init(void)
if (muram_pbase)
return 0;
- spin_lock_init(&cpm_muram_lock);
np = of_find_compatible_node(NULL, NULL, "fsl,cpm-muram-data");
if (!np) {
/* try legacy bindings */
--
2.22.0
^ permalink raw reply related
* [PATCH 2/2] powerpc/vdso64: remove meaningless vgettimeofday.o build rule
From: Masahiro Yamada @ 2020-12-23 17:11 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
linuxppc-dev
Cc: Catalin Marinas, Masahiro Yamada, linux-kernel, Nicholas Piggin,
Greentime Hu
In-Reply-To: <20201223171142.707053-1-masahiroy@kernel.org>
VDSO64 is only built for the 64-bit kernel, hence vgettimeofday.o is
built by the generic rule in scripts/Makefile.build.
This line does not provide anything useful.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---
arch/powerpc/kernel/vdso64/Makefile | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/kernel/vdso64/Makefile b/arch/powerpc/kernel/vdso64/Makefile
index b50b39fedf74..422addf394c7 100644
--- a/arch/powerpc/kernel/vdso64/Makefile
+++ b/arch/powerpc/kernel/vdso64/Makefile
@@ -32,8 +32,6 @@ asflags-y := -D__VDSO64__ -s
targets += vdso64.lds
CPPFLAGS_vdso64.lds += -P -C -U$(ARCH)
-$(obj)/vgettimeofday.o: %.o: %.c FORCE
-
# link rule for the .so file, .lds has to be first
$(obj)/vdso64.so.dbg: $(src)/vdso64.lds $(obj-vdso64) $(obj)/vgettimeofday.o FORCE
$(call if_changed,vdso64ld_and_check)
--
2.27.0
^ permalink raw reply related
* [PATCH 1/2] powerpc/vdso: fix unnecessary rebuilds of vgettimeofday.o
From: Masahiro Yamada @ 2020-12-23 17:11 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
linuxppc-dev
Cc: Ravi Bangoria, Masahiro Yamada, Nicholas Piggin, linux-kernel,
Oliver O'Halloran, Greentime Hu, Michal Suchanek,
Ard Biesheuvel, Daniel Axtens
vgettimeofday.o is unnecessarily rebuilt. Adding it to 'targets' is not
enough to fix the issue. Kbuild is correctly rebuilding it because the
command line is changed.
PowerPC builds each vdso directory twice; first in vdso_prepare to
generate vdso{32,64}-offsets.h, second as part of the ordinary build
process to embed vdso{32,64}.so.dbg into the kernel.
The problem shows up when CONFIG_PPC_WERROR=y due to the following line
in arch/powerpc/Kbuild:
subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
In the preparation stage, Kbuild directly visits the vdso directories,
hence it does not inherit subdir-ccflags-y. In the second descend,
Kbuild adds -Werror, which results in the command line flipping
with/without -Werror.
It implies a potential danger; if a more critical flag that would impact
the resulted vdso, the offsets recorded in the headers might be different
from real offsets in the embedded vdso images.
Removing the unneeded second descend solves the problem.
Link: https://lore.kernel.org/linuxppc-dev/87tuslxhry.fsf@mpe.ellerman.id.au/
Reported-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---
arch/powerpc/kernel/Makefile | 4 ++--
arch/powerpc/kernel/vdso32/Makefile | 5 +----
arch/powerpc/kernel/{vdso32 => }/vdso32_wrapper.S | 0
arch/powerpc/kernel/vdso64/Makefile | 6 +-----
arch/powerpc/kernel/{vdso64 => }/vdso64_wrapper.S | 0
5 files changed, 4 insertions(+), 11 deletions(-)
rename arch/powerpc/kernel/{vdso32 => }/vdso32_wrapper.S (100%)
rename arch/powerpc/kernel/{vdso64 => }/vdso64_wrapper.S (100%)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index fe2ef598e2ea..79ee7750937d 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -51,7 +51,7 @@ obj-y += ptrace/
obj-$(CONFIG_PPC64) += setup_64.o \
paca.o nvram_64.o note.o syscall_64.o
obj-$(CONFIG_COMPAT) += sys_ppc32.o signal_32.o
-obj-$(CONFIG_VDSO32) += vdso32/
+obj-$(CONFIG_VDSO32) += vdso32_wrapper.o
obj-$(CONFIG_PPC_WATCHDOG) += watchdog.o
obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
obj-$(CONFIG_PPC_DAWR) += dawr.o
@@ -60,7 +60,7 @@ obj-$(CONFIG_PPC_BOOK3S_64) += cpu_setup_power.o
obj-$(CONFIG_PPC_BOOK3S_64) += mce.o mce_power.o
obj-$(CONFIG_PPC_BOOK3E_64) += exceptions-64e.o idle_book3e.o
obj-$(CONFIG_PPC_BARRIER_NOSPEC) += security.o
-obj-$(CONFIG_PPC64) += vdso64/
+obj-$(CONFIG_PPC64) += vdso64_wrapper.o
obj-$(CONFIG_ALTIVEC) += vecemu.o
obj-$(CONFIG_PPC_BOOK3S_IDLE) += idle_book3s.o
procfs-y := proc_powerpc.o
diff --git a/arch/powerpc/kernel/vdso32/Makefile b/arch/powerpc/kernel/vdso32/Makefile
index 59aa2944ecae..42fc3de89b39 100644
--- a/arch/powerpc/kernel/vdso32/Makefile
+++ b/arch/powerpc/kernel/vdso32/Makefile
@@ -30,7 +30,7 @@ CC32FLAGS += -m32
KBUILD_CFLAGS := $(filter-out -mcmodel=medium,$(KBUILD_CFLAGS))
endif
-targets := $(obj-vdso32) vdso32.so.dbg
+targets := $(obj-vdso32) vdso32.so.dbg vgettimeofday.o
obj-vdso32 := $(addprefix $(obj)/, $(obj-vdso32))
GCOV_PROFILE := n
@@ -46,9 +46,6 @@ obj-y += vdso32_wrapper.o
targets += vdso32.lds
CPPFLAGS_vdso32.lds += -P -C -Upowerpc
-# Force dependency (incbin is bad)
-$(obj)/vdso32_wrapper.o : $(obj)/vdso32.so.dbg
-
# link rule for the .so file, .lds has to be first
$(obj)/vdso32.so.dbg: $(src)/vdso32.lds $(obj-vdso32) $(obj)/vgettimeofday.o FORCE
$(call if_changed,vdso32ld_and_check)
diff --git a/arch/powerpc/kernel/vdso32/vdso32_wrapper.S b/arch/powerpc/kernel/vdso32_wrapper.S
similarity index 100%
rename from arch/powerpc/kernel/vdso32/vdso32_wrapper.S
rename to arch/powerpc/kernel/vdso32_wrapper.S
diff --git a/arch/powerpc/kernel/vdso64/Makefile b/arch/powerpc/kernel/vdso64/Makefile
index d365810a689a..b50b39fedf74 100644
--- a/arch/powerpc/kernel/vdso64/Makefile
+++ b/arch/powerpc/kernel/vdso64/Makefile
@@ -17,7 +17,7 @@ endif
# Build rules
-targets := $(obj-vdso64) vdso64.so.dbg
+targets := $(obj-vdso64) vdso64.so.dbg vgettimeofday.o
obj-vdso64 := $(addprefix $(obj)/, $(obj-vdso64))
GCOV_PROFILE := n
@@ -29,15 +29,11 @@ ccflags-y := -shared -fno-common -fno-builtin -nostdlib \
-Wl,-soname=linux-vdso64.so.1 -Wl,--hash-style=both
asflags-y := -D__VDSO64__ -s
-obj-y += vdso64_wrapper.o
targets += vdso64.lds
CPPFLAGS_vdso64.lds += -P -C -U$(ARCH)
$(obj)/vgettimeofday.o: %.o: %.c FORCE
-# Force dependency (incbin is bad)
-$(obj)/vdso64_wrapper.o : $(obj)/vdso64.so.dbg
-
# link rule for the .so file, .lds has to be first
$(obj)/vdso64.so.dbg: $(src)/vdso64.lds $(obj-vdso64) $(obj)/vgettimeofday.o FORCE
$(call if_changed,vdso64ld_and_check)
diff --git a/arch/powerpc/kernel/vdso64/vdso64_wrapper.S b/arch/powerpc/kernel/vdso64_wrapper.S
similarity index 100%
rename from arch/powerpc/kernel/vdso64/vdso64_wrapper.S
rename to arch/powerpc/kernel/vdso64_wrapper.S
--
2.27.0
^ permalink raw reply related
* Re: [PATCH] powerpc/mm: Limit allocation of SWIOTLB on server machines
From: Ram Pai @ 2020-12-23 20:58 UTC (permalink / raw)
To: Thiago Jung Bauermann; +Cc: Satheesh Rajendran, linuxppc-dev, linux-kernel
In-Reply-To: <20201218062103.76102-1-bauerman@linux.ibm.com>
On Fri, Dec 18, 2020 at 03:21:03AM -0300, Thiago Jung Bauermann wrote:
> On server-class POWER machines, we don't need the SWIOTLB unless we're a
> secure VM. Nevertheless, if CONFIG_SWIOTLB is enabled we unconditionally
> allocate it.
>
> In most cases this is harmless, but on a few machine configurations (e.g.,
> POWER9 powernv systems with 4 GB area reserved for crashdump kernel) it can
> happen that memblock can't find a 64 MB chunk of memory for the SWIOTLB and
> fails with a scary-looking WARN_ONCE:
>
> ------------[ cut here ]------------
> memblock: bottom-up allocation failed, memory hotremove may be affected
> WARNING: CPU: 0 PID: 0 at mm/memblock.c:332 memblock_find_in_range_node+0x328/0x340
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0-rc2-orig+ #6
> NIP: c000000000442f38 LR: c000000000442f34 CTR: c0000000001e0080
> REGS: c000000001def900 TRAP: 0700 Not tainted (5.10.0-rc2-orig+)
> MSR: 9000000002021033 <SF,HV,VEC,ME,IR,DR,RI,LE> CR: 28022222 XER: 20040000
> CFAR: c00000000014b7b4 IRQMASK: 1
> GPR00: c000000000442f34 c000000001defba0 c000000001deff00 0000000000000047
> GPR04: 00000000ffff7fff c000000001def828 c000000001def820 0000000000000000
> GPR08: 0000001ffc3e0000 c000000001b75478 c000000001b75478 0000000000000001
> GPR12: 0000000000002000 c000000002030000 0000000000000000 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000002030000
> GPR20: 0000000000000000 0000000000010000 0000000000010000 c000000001defc10
> GPR24: c000000001defc08 c000000001c91868 c000000001defc18 c000000001c91890
> GPR28: 0000000000000000 ffffffffffffffff 0000000004000000 00000000ffffffff
> NIP [c000000000442f38] memblock_find_in_range_node+0x328/0x340
> LR [c000000000442f34] memblock_find_in_range_node+0x324/0x340
> Call Trace:
> [c000000001defba0] [c000000000442f34] memblock_find_in_range_node+0x324/0x340 (unreliable)
> [c000000001defc90] [c0000000015ac088] memblock_alloc_range_nid+0xec/0x1b0
> [c000000001defd40] [c0000000015ac1f8] memblock_alloc_internal+0xac/0x110
> [c000000001defda0] [c0000000015ac4d0] memblock_alloc_try_nid+0x94/0xcc
> [c000000001defe30] [c00000000159c3c8] swiotlb_init+0x78/0x104
> [c000000001defea0] [c00000000158378c] mem_init+0x4c/0x98
> [c000000001defec0] [c00000000157457c] start_kernel+0x714/0xac8
> [c000000001deff90] [c00000000000d244] start_here_common+0x1c/0x58
> Instruction dump:
> 2c230000 4182ffd4 ea610088 ea810090 4bfffe84 39200001 3d42fff4 3c62ff60
> 3863c560 992a8bfc 4bd0881d 60000000 <0fe00000> ea610088 4bfffd94 60000000
> random: get_random_bytes called from __warn+0x128/0x184 with crng_init=0
> ---[ end trace 0000000000000000 ]---
> software IO TLB: Cannot allocate buffer
>
> Unless this is a secure VM the message can actually be ignored, because the
> SWIOTLB isn't needed. Therefore, let's avoid the SWIOTLB in those cases.
The above warn_on is conveying a genuine warning. Should it be silenced?
>
> Fixes: eae9eec476d1 ("powerpc/pseries/svm: Allocate SWIOTLB buffer anywhere in memory")
> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
> ---
> arch/powerpc/mm/mem.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index afab328d0887..3af991844145 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -300,7 +300,8 @@ void __init mem_init(void)
> memblock_set_bottom_up(true);
> if (is_secure_guest())
> svm_swiotlb_init();
> - else
> + /* Server machines don't need SWIOTLB if they're not secure guests. */
> + else if (!machine_is(pseries) && !machine_is(powernv))
I can see powernv never needing SWIOTLB. But, pseries guests, I am not
so sure.
RP
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Limit allocation of SWIOTLB on server machines
From: Thiago Jung Bauermann @ 2020-12-24 0:06 UTC (permalink / raw)
To: Ram Pai; +Cc: Satheesh Rajendran, linuxppc-dev, linux-kernel
In-Reply-To: <20201223205838.GA4102@ram-ibm-com.ibm.com>
Hi Ram,
Thanks for reviewing this patch.
Ram Pai <linuxram@us.ibm.com> writes:
> On Fri, Dec 18, 2020 at 03:21:03AM -0300, Thiago Jung Bauermann wrote:
>> On server-class POWER machines, we don't need the SWIOTLB unless we're a
>> secure VM. Nevertheless, if CONFIG_SWIOTLB is enabled we unconditionally
>> allocate it.
>>
>> In most cases this is harmless, but on a few machine configurations (e.g.,
>> POWER9 powernv systems with 4 GB area reserved for crashdump kernel) it can
>> happen that memblock can't find a 64 MB chunk of memory for the SWIOTLB and
>> fails with a scary-looking WARN_ONCE:
>>
>> ------------[ cut here ]------------
>> memblock: bottom-up allocation failed, memory hotremove may be affected
>> WARNING: CPU: 0 PID: 0 at mm/memblock.c:332 memblock_find_in_range_node+0x328/0x340
>> Modules linked in:
>> CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0-rc2-orig+ #6
>> NIP: c000000000442f38 LR: c000000000442f34 CTR: c0000000001e0080
>> REGS: c000000001def900 TRAP: 0700 Not tainted (5.10.0-rc2-orig+)
>> MSR: 9000000002021033 <SF,HV,VEC,ME,IR,DR,RI,LE> CR: 28022222 XER: 20040000
>> CFAR: c00000000014b7b4 IRQMASK: 1
>> GPR00: c000000000442f34 c000000001defba0 c000000001deff00 0000000000000047
>> GPR04: 00000000ffff7fff c000000001def828 c000000001def820 0000000000000000
>> GPR08: 0000001ffc3e0000 c000000001b75478 c000000001b75478 0000000000000001
>> GPR12: 0000000000002000 c000000002030000 0000000000000000 0000000000000000
>> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000002030000
>> GPR20: 0000000000000000 0000000000010000 0000000000010000 c000000001defc10
>> GPR24: c000000001defc08 c000000001c91868 c000000001defc18 c000000001c91890
>> GPR28: 0000000000000000 ffffffffffffffff 0000000004000000 00000000ffffffff
>> NIP [c000000000442f38] memblock_find_in_range_node+0x328/0x340
>> LR [c000000000442f34] memblock_find_in_range_node+0x324/0x340
>> Call Trace:
>> [c000000001defba0] [c000000000442f34] memblock_find_in_range_node+0x324/0x340 (unreliable)
>> [c000000001defc90] [c0000000015ac088] memblock_alloc_range_nid+0xec/0x1b0
>> [c000000001defd40] [c0000000015ac1f8] memblock_alloc_internal+0xac/0x110
>> [c000000001defda0] [c0000000015ac4d0] memblock_alloc_try_nid+0x94/0xcc
>> [c000000001defe30] [c00000000159c3c8] swiotlb_init+0x78/0x104
>> [c000000001defea0] [c00000000158378c] mem_init+0x4c/0x98
>> [c000000001defec0] [c00000000157457c] start_kernel+0x714/0xac8
>> [c000000001deff90] [c00000000000d244] start_here_common+0x1c/0x58
>> Instruction dump:
>> 2c230000 4182ffd4 ea610088 ea810090 4bfffe84 39200001 3d42fff4 3c62ff60
>> 3863c560 992a8bfc 4bd0881d 60000000 <0fe00000> ea610088 4bfffd94 60000000
>> random: get_random_bytes called from __warn+0x128/0x184 with crng_init=0
>> ---[ end trace 0000000000000000 ]---
>> software IO TLB: Cannot allocate buffer
>>
>> Unless this is a secure VM the message can actually be ignored, because the
>> SWIOTLB isn't needed. Therefore, let's avoid the SWIOTLB in those cases.
>
> The above warn_on is conveying a genuine warning. Should it be silenced?
Not sure I understand your point. This patch doesn't silence the
warning, it avoids the problem it is warning about.
In any case, there's another patch being submitted upstream which
actually removes the warning by improving memblock's search for a free
memory region:
https://lore.kernel.org/lkml/20201217201214.3414100-2-guro@fb.com/
>>
>> Fixes: eae9eec476d1 ("powerpc/pseries/svm: Allocate SWIOTLB buffer anywhere in memory")
>> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
>> ---
>> arch/powerpc/mm/mem.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
>> index afab328d0887..3af991844145 100644
>> --- a/arch/powerpc/mm/mem.c
>> +++ b/arch/powerpc/mm/mem.c
>> @@ -300,7 +300,8 @@ void __init mem_init(void)
>> memblock_set_bottom_up(true);
>> if (is_secure_guest())
>> svm_swiotlb_init();
>> - else
>> + /* Server machines don't need SWIOTLB if they're not secure guests. */
>> + else if (!machine_is(pseries) && !machine_is(powernv))
>
> I can see powernv never needing SWIOTLB. But, pseries guests, I am not
> so sure.
We've just very recently enabled CONFIG_SWIOTLB on production pseries
kernel configs. So far it hasn't been needed except for SVMs.
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH] powerpc/32s: Fix RTAS machine check with VMAP stack
From: Michael Ellerman @ 2020-12-24 1:05 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <6ed0b74d-8d01-4a20-faed-891496fb77b4@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 22/12/2020 à 08:11, Christophe Leroy a écrit :
>> When we have VMAP stack, exception prolog 1 sets r1, not r11.
>
> But exception prolog 1 uses r1 to setup r1 when machine check happens in kernel.
> So r1 must be restored when the branch is not taken. See subsequent patch I just sent out.
OK. This is still on the tip of fixes, so I'll rewind it to drop this
commit, and then apply this and the fixup as one patch next week.
cheers
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-5.11-2 tag
From: Michael Ellerman @ 2020-12-24 1:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, clg, linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Linus,
Please pull some powerpc fixes for 5.11:
The following changes since commit 8a5be36b9303ae167468d4f5e1b3c090b9981396:
Merge tag 'powerpc-5.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux (2020-12-17 13:34:25 -0800)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.11-2
for you to fetch changes up to d5c243989fb0cb03c74d7340daca3b819f706ee7:
powerpc/32: Fix vmap stack - Properly set r1 before activating MMU on syscall too (2020-12-21 22:24:00 +1100)
- ------------------------------------------------------------------
powerpc fixes for 5.11 #2
Four commits fixing various things in the new C VDSO code.
One fix for a 32-bit VMAP stack bug.
Two minor build fixes.
Thanks to:
Cédric Le Goater, Christophe Leroy, Will Springer.
- ------------------------------------------------------------------
Christophe Leroy (2):
powerpc/time: Force inlining of get_tb()
powerpc/32: Fix vmap stack - Properly set r1 before activating MMU on syscall too
Cédric Le Goater (1):
powerpc/smp: Add __init to init_big_cores()
Michael Ellerman (4):
powerpc/boot: Fix build of dts/fsl
powerpc/vdso: Block R_PPC_REL24 relocations
powerpc/vdso: Don't pass 64-bit ABI cflags to 32-bit VDSO
powerpc/vdso: Fix DOTSYM for 32-bit LE VDSO
arch/powerpc/boot/Makefile | 2 ++
arch/powerpc/include/asm/ppc_asm.h | 7 +++++-
arch/powerpc/include/asm/vdso/timebase.h | 2 +-
arch/powerpc/kernel/head_32.h | 25 +++++++++++++-------
arch/powerpc/kernel/smp.c | 2 +-
arch/powerpc/kernel/vdso32/Makefile | 4 ++--
arch/powerpc/kernel/vdso64/Makefile | 2 +-
7 files changed, 29 insertions(+), 15 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAl/j9DYACgkQUevqPMjh
pYBjQQ/8CcfenT8pA9/vHqI/soyjASFrFtQLiHz1IrAJtzs1USnOrI9JhTYOsLlb
HoUBITMzHJx9TkcT5l06f+BdscNRuCoxn3QLzfBZZkAFHK2Rfn51xJ7Un+THyZzc
3jqtuzrfBaoq3Ccut7Y0QrfuGW6eV+Q26/JThZJBee/K6jzBucPV7ZA/xA4qpLyY
XxAnubSK/kMQixOOWeCqAgjcx8/CHe1rf7UhT2rWdLDoaUxq7UjIpbZlZ2r8YwiO
e7FbrWKps0o3RW5953mYhYyHpIKanJlnB2Hl90g/MBRuwDqcoiTeKuAQV/7fNWOx
eWRA2FfEFON+j4/3LEs6IN+OxSEoF/DkfBFnFogdbx4sv2uwrXwlWzDyRfWJJSNK
PHKdUXE7sST4U9QgCZ0Mn5vz6BvCLWRFTowP4VR//we+xSyYca0s56XnKGZvEV/F
dQ45aACT5EMjF1B/+AG725wf4ELKmxdJNXjLvrfuWuUsz5mt3Tl1Uh0pPmT3BD4B
M1evyjp7+noSCjHYTooBiVqJwM2begiGBM4pD0UqLHt4cl6xvGhUE/LckJKmsPxn
/WtXnXTg+/zBFO0NZ0s7UVcbO5sCpSVIRJ+cGL1AR/fWMSQBGxoH4JRJ4ov9rJGh
/usuFCwBJKpRJxLFhgi5TrSnfYpoH+svHDU4deytU6wWmnenrzA=
=V9FR
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Limit allocation of SWIOTLB on server machines
From: Ram Pai @ 2020-12-24 3:14 UTC (permalink / raw)
To: Thiago Jung Bauermann; +Cc: Satheesh Rajendran, linuxppc-dev, linux-kernel
In-Reply-To: <87o8ikukye.fsf@manicouagan.localdomain>
On Wed, Dec 23, 2020 at 09:06:01PM -0300, Thiago Jung Bauermann wrote:
>
> Hi Ram,
>
> Thanks for reviewing this patch.
>
> Ram Pai <linuxram@us.ibm.com> writes:
>
> > On Fri, Dec 18, 2020 at 03:21:03AM -0300, Thiago Jung Bauermann wrote:
> >> On server-class POWER machines, we don't need the SWIOTLB unless we're a
> >> secure VM. Nevertheless, if CONFIG_SWIOTLB is enabled we unconditionally
> >> allocate it.
> >>
> >> In most cases this is harmless, but on a few machine configurations (e.g.,
> >> POWER9 powernv systems with 4 GB area reserved for crashdump kernel) it can
> >> happen that memblock can't find a 64 MB chunk of memory for the SWIOTLB and
> >> fails with a scary-looking WARN_ONCE:
> >>
> >> ------------[ cut here ]------------
> >> memblock: bottom-up allocation failed, memory hotremove may be affected
> >> WARNING: CPU: 0 PID: 0 at mm/memblock.c:332 memblock_find_in_range_node+0x328/0x340
> >> Modules linked in:
> >> CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0-rc2-orig+ #6
> >> NIP: c000000000442f38 LR: c000000000442f34 CTR: c0000000001e0080
> >> REGS: c000000001def900 TRAP: 0700 Not tainted (5.10.0-rc2-orig+)
> >> MSR: 9000000002021033 <SF,HV,VEC,ME,IR,DR,RI,LE> CR: 28022222 XER: 20040000
> >> CFAR: c00000000014b7b4 IRQMASK: 1
> >> GPR00: c000000000442f34 c000000001defba0 c000000001deff00 0000000000000047
> >> GPR04: 00000000ffff7fff c000000001def828 c000000001def820 0000000000000000
> >> GPR08: 0000001ffc3e0000 c000000001b75478 c000000001b75478 0000000000000001
> >> GPR12: 0000000000002000 c000000002030000 0000000000000000 0000000000000000
> >> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000002030000
> >> GPR20: 0000000000000000 0000000000010000 0000000000010000 c000000001defc10
> >> GPR24: c000000001defc08 c000000001c91868 c000000001defc18 c000000001c91890
> >> GPR28: 0000000000000000 ffffffffffffffff 0000000004000000 00000000ffffffff
> >> NIP [c000000000442f38] memblock_find_in_range_node+0x328/0x340
> >> LR [c000000000442f34] memblock_find_in_range_node+0x324/0x340
> >> Call Trace:
> >> [c000000001defba0] [c000000000442f34] memblock_find_in_range_node+0x324/0x340 (unreliable)
> >> [c000000001defc90] [c0000000015ac088] memblock_alloc_range_nid+0xec/0x1b0
> >> [c000000001defd40] [c0000000015ac1f8] memblock_alloc_internal+0xac/0x110
> >> [c000000001defda0] [c0000000015ac4d0] memblock_alloc_try_nid+0x94/0xcc
> >> [c000000001defe30] [c00000000159c3c8] swiotlb_init+0x78/0x104
> >> [c000000001defea0] [c00000000158378c] mem_init+0x4c/0x98
> >> [c000000001defec0] [c00000000157457c] start_kernel+0x714/0xac8
> >> [c000000001deff90] [c00000000000d244] start_here_common+0x1c/0x58
> >> Instruction dump:
> >> 2c230000 4182ffd4 ea610088 ea810090 4bfffe84 39200001 3d42fff4 3c62ff60
> >> 3863c560 992a8bfc 4bd0881d 60000000 <0fe00000> ea610088 4bfffd94 60000000
> >> random: get_random_bytes called from __warn+0x128/0x184 with crng_init=0
> >> ---[ end trace 0000000000000000 ]---
> >> software IO TLB: Cannot allocate buffer
> >>
> >> Unless this is a secure VM the message can actually be ignored, because the
> >> SWIOTLB isn't needed. Therefore, let's avoid the SWIOTLB in those cases.
> >
> > The above warn_on is conveying a genuine warning. Should it be silenced?
>
> Not sure I understand your point. This patch doesn't silence the
> warning, it avoids the problem it is warning about.
Sorry, I should have explained it better. My point is...
If CONFIG_SWIOTLB is enabled, it means that the kernel is
promising the bounce buffering capability. I know, currently we
do not have any kernel subsystems that use bounce buffers on
non-secure-pseries-kernel or powernv-kernel. But that does not
mean, there wont be any. In case there is such a third-party
module needing bounce buffering, it wont be able to operate,
because of the proposed change in your patch.
Is that a good thing or a bad thing, I do not know. I will let
the experts opine.
RP
^ permalink raw reply
* [PATCH v2 -next] misc: ocxl: use DEFINE_MUTEX() for mutex lock
From: Zheng Yongjun @ 2020-12-24 13:24 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: fbarrat, gregkh, ajd, arnd, Zheng Yongjun
mutex lock can be initialized automatically with DEFINE_MUTEX()
rather than explicitly calling mutex_init().
Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com>
---
drivers/misc/ocxl/file.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
index 4d1b44de1492..e70525eedaae 100644
--- a/drivers/misc/ocxl/file.c
+++ b/drivers/misc/ocxl/file.c
@@ -15,7 +15,7 @@
static dev_t ocxl_dev;
static struct class *ocxl_class;
-static struct mutex minors_idr_lock;
+static DEFINE_MUTEX(minors_idr_lock);
static struct idr minors_idr;
static struct ocxl_file_info *find_and_get_file_info(dev_t devno)
@@ -588,7 +588,6 @@ int ocxl_file_init(void)
{
int rc;
- mutex_init(&minors_idr_lock);
idr_init(&minors_idr);
rc = alloc_chrdev_region(&ocxl_dev, 0, OCXL_NUM_MINORS, "ocxl");
--
2.22.0
^ permalink raw reply related
* [powerpc:fixes] BUILD SUCCESS d5c243989fb0cb03c74d7340daca3b819f706ee7
From: kernel test robot @ 2020-12-24 13:26 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes
branch HEAD: d5c243989fb0cb03c74d7340daca3b819f706ee7 powerpc/32: Fix vmap stack - Properly set r1 before activating MMU on syscall too
elapsed time: 4324m
configs tested: 148
configs skipped: 146
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
powerpc mpc866_ads_defconfig
i386 alldefconfig
parisc generic-32bit_defconfig
powerpc sequoia_defconfig
m68k amiga_defconfig
sh titan_defconfig
mips bmips_be_defconfig
arm h5000_defconfig
mips ip22_defconfig
powerpc mpc837x_rdb_defconfig
powerpc tqm8555_defconfig
arc tb10x_defconfig
xtensa common_defconfig
c6x evmc6474_defconfig
powerpc mpc834x_mds_defconfig
i386 allyesconfig
arc haps_hs_smp_defconfig
arm vf610m4_defconfig
xtensa defconfig
arm u300_defconfig
powerpc mpc834x_itx_defconfig
m68k q40_defconfig
m68k m5208evb_defconfig
arm pxa168_defconfig
powerpc icon_defconfig
powerpc ge_imp3a_defconfig
arm corgi_defconfig
powerpc xes_mpc85xx_defconfig
powerpc ppc40x_defconfig
nds32 allnoconfig
x86_64 alldefconfig
sparc sparc64_defconfig
m68k bvme6000_defconfig
arm prima2_defconfig
sparc alldefconfig
powerpc mpc7448_hpc2_defconfig
microblaze mmu_defconfig
sh sh7785lcr_32bit_defconfig
powerpc tqm8560_defconfig
powerpc sam440ep_defconfig
m68k mvme16x_defconfig
powerpc storcenter_defconfig
arm integrator_defconfig
sh espt_defconfig
arm realview_defconfig
s390 alldefconfig
powerpc canyonlands_defconfig
powerpc klondike_defconfig
powerpc cm5200_defconfig
arm colibri_pxa270_defconfig
xtensa alldefconfig
powerpc akebono_defconfig
mips maltaup_defconfig
arm u8500_defconfig
arm iop32x_defconfig
arc alldefconfig
mips fuloong2e_defconfig
powerpc mvme5100_defconfig
arm cns3420vb_defconfig
arm rpc_defconfig
arm palmz72_defconfig
powerpc mpc85xx_cds_defconfig
arm spear6xx_defconfig
arm zx_defconfig
mips loongson1c_defconfig
powerpc ppc64e_defconfig
sparc sparc32_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
nios2 defconfig
arc allyesconfig
c6x allyesconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a001-20201221
x86_64 randconfig-a006-20201221
x86_64 randconfig-a002-20201221
x86_64 randconfig-a004-20201221
x86_64 randconfig-a003-20201221
x86_64 randconfig-a005-20201221
i386 randconfig-a002-20201221
i386 randconfig-a005-20201221
i386 randconfig-a006-20201221
i386 randconfig-a004-20201221
i386 randconfig-a003-20201221
i386 randconfig-a001-20201221
i386 randconfig-a005-20201222
i386 randconfig-a002-20201222
i386 randconfig-a006-20201222
i386 randconfig-a004-20201222
i386 randconfig-a003-20201222
i386 randconfig-a001-20201222
i386 randconfig-a011-20201221
i386 randconfig-a016-20201221
i386 randconfig-a014-20201221
i386 randconfig-a012-20201221
i386 randconfig-a015-20201221
i386 randconfig-a013-20201221
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a015-20201221
x86_64 randconfig-a014-20201221
x86_64 randconfig-a016-20201221
x86_64 randconfig-a012-20201221
x86_64 randconfig-a013-20201221
x86_64 randconfig-a011-20201221
x86_64 randconfig-a001-20201222
x86_64 randconfig-a006-20201222
x86_64 randconfig-a002-20201222
x86_64 randconfig-a004-20201222
x86_64 randconfig-a003-20201222
x86_64 randconfig-a005-20201222
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: GIT kernel with the PowerPC updates 5.11-1 doesn't boot on a FSL P5040 board and in a virtual e5500 QEMU machine
From: Christian Zigotzky @ 2020-12-24 15:01 UTC (permalink / raw)
To: Michael Ellerman, Christophe Leroy, Denis Kirjanov
Cc: Darren Stevens, linuxppc-dev, R.T.Dickinson, mad skateman
In-Reply-To: <87lfdq6l03.fsf@mpe.ellerman.id.au>
On 22 December 2020 at 02:14pm, Michael Ellerman wrote:
> Christian Zigotzky <chzigotzky@xenosoft.de> writes:
> ...
>> Download: http://www.xenosoft.de/MintPPC32-X5000.tar.gz (md5sum:
>> b31c1c1ca1fcf5d4cdf110c4bce11654) The password for both 'root' and
>> 'mintppc' is 'mintppc'.
> ...
>> QEMU command without KVM on macOS Intel: qemu-system-ppc64 -M ppce500
>> -cpu e5500 -m 1024 -kernel uImage -drive
>> format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev
>> user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw
>> root=/dev/vda" -device virtio-vga -usb -device usb-ehci,id=ehci -device
>> usb-tablet -device virtio-keyboard-pci -smp 4 -vnc :1
> I was able to boot the above (on powerpc, but not using KVM), using my
> fixes branch.
>
> Please give that branch a test:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/log/?h=fixes
>
>
> cheers
Hello Michael,
I tested your fixes branch today and the kernel boots without any problems.
Thanks a lot for fixing the issue.
Merry Christmas,
Christian
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS 51774547e7f80f9111d85a65c8e14eb2d9ffcdf3
From: kernel test robot @ 2020-12-24 18:16 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: 51774547e7f80f9111d85a65c8e14eb2d9ffcdf3 Automatic merge of 'master' into merge (2020-12-24 12:17)
elapsed time: 957m
configs tested: 132
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
nds32 allnoconfig
m68k m5407c3_defconfig
openrisc defconfig
sh se7343_defconfig
mips maltasmvp_defconfig
arm colibri_pxa300_defconfig
arm hackkit_defconfig
sh alldefconfig
arm keystone_defconfig
arc nsimosci_hs_defconfig
arm jornada720_defconfig
c6x evmc6457_defconfig
mips maltasmvp_eva_defconfig
arm s3c6400_defconfig
arm cerfcube_defconfig
powerpc ge_imp3a_defconfig
arm corgi_defconfig
powerpc xes_mpc85xx_defconfig
powerpc ppc40x_defconfig
c6x evmc6474_defconfig
arc vdk_hs38_defconfig
arm pcm027_defconfig
arm mv78xx0_defconfig
riscv defconfig
arm trizeps4_defconfig
arm clps711x_defconfig
sh ap325rxa_defconfig
xtensa common_defconfig
arm multi_v4t_defconfig
xtensa alldefconfig
mips nlm_xlp_defconfig
arm zx_defconfig
powerpc taishan_defconfig
powerpc mpc83xx_defconfig
h8300 alldefconfig
powerpc mpc834x_mds_defconfig
sh se7705_defconfig
arm pxa3xx_defconfig
m68k mvme16x_defconfig
sh sh7763rdp_defconfig
sh espt_defconfig
arm pxa_defconfig
mips loongson1b_defconfig
sparc64 defconfig
arm tegra_defconfig
mips decstation_64_defconfig
alpha defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a001-20201223
x86_64 randconfig-a006-20201223
x86_64 randconfig-a002-20201223
x86_64 randconfig-a004-20201223
x86_64 randconfig-a003-20201223
x86_64 randconfig-a005-20201223
i386 randconfig-a005-20201224
i386 randconfig-a002-20201224
i386 randconfig-a006-20201224
i386 randconfig-a004-20201224
i386 randconfig-a003-20201224
i386 randconfig-a001-20201224
i386 randconfig-a002-20201223
i386 randconfig-a005-20201223
i386 randconfig-a006-20201223
i386 randconfig-a004-20201223
i386 randconfig-a003-20201223
i386 randconfig-a001-20201223
i386 randconfig-a011-20201223
i386 randconfig-a016-20201223
i386 randconfig-a014-20201223
i386 randconfig-a012-20201223
i386 randconfig-a015-20201223
i386 randconfig-a013-20201223
i386 randconfig-a016-20201224
i386 randconfig-a011-20201224
i386 randconfig-a012-20201224
i386 randconfig-a014-20201224
i386 randconfig-a015-20201224
i386 randconfig-a013-20201224
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a015-20201223
x86_64 randconfig-a014-20201223
x86_64 randconfig-a016-20201223
x86_64 randconfig-a012-20201223
x86_64 randconfig-a013-20201223
x86_64 randconfig-a011-20201223
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS b9b8c8d3b4101788dd2c9ff5137baf7801a8f563
From: kernel test robot @ 2020-12-24 18:16 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: b9b8c8d3b4101788dd2c9ff5137baf7801a8f563 powerpc/32s: Fix RTAS machine check with VMAP stack
elapsed time: 959m
configs tested: 53
configs skipped: 112
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
powerpc mpc7448_hpc2_defconfig
mips cu1830-neo_defconfig
m68k amcore_defconfig
arc tb10x_defconfig
powerpc tqm8540_defconfig
sh rsk7201_defconfig
powerpc adder875_defconfig
powerpc mpc832x_mds_defconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a001-20201223
x86_64 randconfig-a006-20201223
x86_64 randconfig-a002-20201223
x86_64 randconfig-a004-20201223
x86_64 randconfig-a003-20201223
x86_64 randconfig-a005-20201223
x86_64 randconfig-a015-20201224
x86_64 randconfig-a014-20201224
x86_64 randconfig-a016-20201224
x86_64 randconfig-a012-20201224
x86_64 randconfig-a013-20201224
x86_64 randconfig-a011-20201224
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a015-20201223
x86_64 randconfig-a014-20201223
x86_64 randconfig-a016-20201223
x86_64 randconfig-a012-20201223
x86_64 randconfig-a013-20201223
x86_64 randconfig-a011-20201223
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.11-2 tag
From: pr-tracker-bot @ 2020-12-24 22:15 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Linus Torvalds, clg, linux-kernel
In-Reply-To: <87ft3w6kc9.fsf@mpe.ellerman.id.au>
The pull request you sent on Thu, 24 Dec 2020 12:53:10 +1100:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.11-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9b3f7f1b841e91f0f0414525fa6edaaa2df33ccb
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v9 11/12] mm/vmalloc: Hugepage vmalloc mappings
From: Ding Tianhong @ 2020-12-25 7:58 UTC (permalink / raw)
To: Nicholas Piggin, linux-mm, Andrew Morton
Cc: linux-arch, linux-kernel, Christoph Hellwig, Zefan Li,
Jonathan Cameron, Rick Edgecombe, linuxppc-dev
In-Reply-To: <20201205065725.1286370-12-npiggin@gmail.com>
> +again:
> + size = PAGE_ALIGN(size);
> + area = __get_vm_area_node(size, align, VM_ALLOC | VM_UNINITIALIZED |
> vm_flags, start, end, node, gfp_mask, caller);
> if (!area)
> goto fail;
>
> - addr = __vmalloc_area_node(area, gfp_mask, prot, node);
> + addr = __vmalloc_area_node(area, gfp_mask, prot, shift, node);
> if (!addr)
> - return NULL;
> + goto fail;
>
> /*
> * In this function, newly allocated vm_struct has VM_UNINITIALIZED
> @@ -2788,8 +2878,19 @@ void *__vmalloc_node_range(unsigned long size, unsigned long align,
> return addr;
>
> fail:
> - warn_alloc(gfp_mask, NULL,
> + if (shift > PAGE_SHIFT) {
> + free_vm_area(area);
> + shift = PAGE_SHIFT;
> + align = real_align;
> + size = real_size;
> + goto again;
> + }
> +
Hi, Nicholas:
I met a problem like this:
[ 67.103584] ------------[ cut here ]------------
[ 67.103884] kernel BUG at vmalloc.c:2892!
[ 67.104387] Internal error: Oops - BUG: 0 [#1] SMP
[ 67.104942] Process insmod (pid: 1161, stack limit = 0x(____ptrval____))
[ 67.105356] CPU: 2 PID: 1161 Comm: insmod Tainted: G O 4.19.95+ #9
[ 67.105702] Hardware name: linux,dummy-virt (DT)
[ 67.106006] pstate: a0000005 (NzCv daif -PAN -UAO)
[ 67.106285] pc : free_vm_area+0x78/0x80
[ 67.106549] lr : free_vm_area+0x58/0x80
it looks like when __vmalloc_area_node failed, the area is already released, and the free_vm_area
will release the vm area again, so trigger the problem.
3405 ret = remove_vm_area(area->addr);
3406 BUG_ON(ret != area);
3407 kfree(area);
Ding
> + if (!area) {
> + /* Warn for area allocation, page allocations already warn */
> + warn_alloc(gfp_mask, NULL,
> "vmalloc: allocation failure: %lu bytes", real_size);
> + }
> return NULL;
> }
>
>
^ permalink raw reply
* [PATCH] genirq: Fix export of irq_to_desc() for powerpc KVM
From: Michael Ellerman @ 2020-12-25 11:30 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, tglx, linux-kernel
Commit 64a1b95bb9fe ("genirq: Restrict export of irq_to_desc()")
removed the export of irq_to_desc() unless powerpc KVM is being built,
because there is still a use of irq_to_desc() in modular code there.
However it used:
#ifdef CONFIG_KVM_BOOK3S_64_HV
Which doesn't work when that symbol is =m, leading to a build failure:
ERROR: modpost: "irq_to_desc" [arch/powerpc/kvm/kvm-hv.ko] undefined!
Fix it by checking for the definedness of the correct symbol which is
CONFIG_KVM_BOOK3S_64_HV_MODULE.
Fixes: 64a1b95bb9fe ("genirq: Restrict export of irq_to_desc()")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
kernel/irq/irqdesc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 3d0bc38a0bcf..cc1a09406c6e 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -352,7 +352,7 @@ struct irq_desc *irq_to_desc(unsigned int irq)
{
return radix_tree_lookup(&irq_desc_tree, irq);
}
-#ifdef CONFIG_KVM_BOOK3S_64_HV
+#ifdef CONFIG_KVM_BOOK3S_64_HV_MODULE
EXPORT_SYMBOL_GPL(irq_to_desc);
#endif
--
2.25.1
^ permalink raw reply related
* Regression for 32-bit ppc on PowerBook G4 Aluminum (bisected to commit d0e3fc69d00d)
From: Larry Finger @ 2020-12-26 3:42 UTC (permalink / raw)
To: Christophe LEROY; +Cc: Paul Mackerras, ppc-dev
Beginning with commit d0e3fc69d00d ("powerpc/vdso: Provide
__kernel_clock_gettime64() on vdso32"), my PowerBook G4 Aluminum fails to boot.
It stops pretty early in the boot.
I will be happy to test any patches, or provide any additional information.
Larry
^ permalink raw reply
* Re: [PATCH v3 03/19] powerpc: bad_page_fault, do_break get registers from regs
From: Nicholas Piggin @ 2020-12-26 8:19 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <312d3d14-329c-a0c9-89c4-e21d1f9e616d@csgroup.eu>
Excerpts from Christophe Leroy's message of December 23, 2020 12:42 am:
>
>
> Le 28/11/2020 à 15:40, Nicholas Piggin a écrit :
>> Similar to the previous patch this makes interrupt handler function
>> types more regular so they can be wrapped with the next patch.
>>
>> bad_page_fault and do_break are not performance critical.
>
> I partly took your changes into one of my series, in different order though.
>
> Please have a look at https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=221656 patches
> 4 to 7
Thanks, I had a look. Seems like the result is basically the same as my
series, so that's good if you like the end result now :)
> I think some of the changes are missing in your series, especially the changes in entry_32.S from
> patch 7.
Okay I could take them in. In your patch 7/15, why do you leave this
load of DSISR?
diff --git a/arch/powerpc/kernel/head_book3s_32.S b/arch/powerpc/kernel/head_book3s_32.S
index 15e6003fd3b8..0133a02d1d47 100644
--- a/arch/powerpc/kernel/head_book3s_32.S
+++ b/arch/powerpc/kernel/head_book3s_32.S
@@ -369,9 +369,9 @@ BEGIN_MMU_FTR_SECTION
END_MMU_FTR_SECTION_IFSET(MMU_FTR_HPTE_TABLE)
#endif
#endif /* CONFIG_VMAP_STACK */
-1: mr r4,r12
andis. r5,r9,DSISR_SRR1_MATCH_32S@h /* Filter relevant SRR1 bits */
- stw r4, _DAR(r11)
+ stw r12, _DAR(r11)
+ stw r5, _DSISR(r11)
EXC_XFER_LITE(0x400, handle_page_fault)
/* External interrupt */
@@ -693,7 +693,6 @@ handle_page_fault_tramp_1:
#ifdef CONFIG_VMAP_STACK
EXCEPTION_PROLOG_2 handle_dar_dsisr=1
#endif
- lwz r4, _DAR(r11)
lwz r5, _DSISR(r11)
^^^^^^^^^^^^^^^^^^^^^^
/* fall through */
handle_page_fault_tramp_2:
?
> Will see how our two series make their way into mainline, yours needs rebase anyway.
I have it rebased, just waiting for a bit after merge window to repost.
Would be good if mine can go first so I don't have to redo the 64s page
fault to C conversion again. AFAIKS after that you can just drop 4-7, no
conflicts? (after bugs are fixed)
Thanks,
Nick
^ permalink raw reply related
* Re: [PATCH v14 6/9] powerpc/vdso: Prepare for switching VDSO to generic C implementation.
From: Andreas Schwab @ 2020-12-26 9:49 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <20201126131006.2431205-6-mpe__7176.90246399201$1606398872$gmane$org@ellerman.id.au>
On Nov 27 2020, Michael Ellerman wrote:
> diff --git a/arch/powerpc/include/asm/vdso/gettimeofday.h b/arch/powerpc/include/asm/vdso/gettimeofday.h
> new file mode 100644
> index 000000000000..43dd1dc47c37
> --- /dev/null
> +++ b/arch/powerpc/include/asm/vdso/gettimeofday.h
> @@ -0,0 +1,187 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_POWERPC_VDSO_GETTIMEOFDAY_H
> +#define _ASM_POWERPC_VDSO_GETTIMEOFDAY_H
> +
> +#ifdef __ASSEMBLY__
> +
> +#include <asm/ppc_asm.h>
> +
> +/*
> + * The macros sets two stack frames, one for the caller and one for the callee
> + * because there are no requirement for the caller to set a stack frame when
> + * calling VDSO so it may have omitted to set one, especially on PPC64
> + */
> +
> +.macro cvdso_call funct
> + .cfi_startproc
> + PPC_STLU r1, -PPC_MIN_STKFRM(r1)
> + mflr r0
> + .cfi_register lr, r0
> + PPC_STLU r1, -PPC_MIN_STKFRM(r1)
> + PPC_STL r0, PPC_MIN_STKFRM + PPC_LR_STKOFF(r1)
> + get_datapage r5, r0
> + addi r5, r5, VDSO_DATA_OFFSET
> + bl DOTSYM(\funct)
> + PPC_LL r0, PPC_MIN_STKFRM + PPC_LR_STKOFF(r1)
> + cmpwi r3, 0
> + mtlr r0
> + .cfi_restore lr
> + addi r1, r1, 2 * PPC_MIN_STKFRM
> + crclr so
> + beqlr+
> + crset so
> + neg r3, r3
> + blr
> + .cfi_endproc
> +.endm
> +
> +.macro cvdso_call_time funct
> + .cfi_startproc
> + PPC_STLU r1, -PPC_MIN_STKFRM(r1)
> + mflr r0
> + .cfi_register lr, r0
> + PPC_STLU r1, -PPC_MIN_STKFRM(r1)
> + PPC_STL r0, PPC_MIN_STKFRM + PPC_LR_STKOFF(r1)
> + get_datapage r4, r0
> + addi r4, r4, VDSO_DATA_OFFSET
> + bl DOTSYM(\funct)
> + PPC_LL r0, PPC_MIN_STKFRM + PPC_LR_STKOFF(r1)
> + crclr so
> + mtlr r0
> + .cfi_restore lr
> + addi r1, r1, 2 * PPC_MIN_STKFRM
> + blr
> + .cfi_endproc
> +.endm
> +
> +#else
> +
> +#include <asm/vdso/timebase.h>
> +#include <asm/barrier.h>
> +#include <asm/unistd.h>
> +#include <uapi/linux/time.h>
> +
> +#define VDSO_HAS_CLOCK_GETRES 1
> +
> +#define VDSO_HAS_TIME 1
> +
> +static __always_inline int do_syscall_2(const unsigned long _r0, const unsigned long _r3,
> + const unsigned long _r4)
> +{
> + register long r0 asm("r0") = _r0;
> + register unsigned long r3 asm("r3") = _r3;
> + register unsigned long r4 asm("r4") = _r4;
> + register int ret asm ("r3");
> +
> + asm volatile(
> + " sc\n"
> + " bns+ 1f\n"
> + " neg %0, %0\n"
> + "1:\n"
> + : "=r" (ret), "+r" (r4), "+r" (r0)
> + : "r" (r3)
> + : "memory", "r5", "r6", "r7", "r8", "r9", "r10", "r11", "r12", "cr0", "ctr");
> +
> + return ret;
> +}
> +
> +static __always_inline
> +int gettimeofday_fallback(struct __kernel_old_timeval *_tv, struct timezone *_tz)
> +{
> + return do_syscall_2(__NR_gettimeofday, (unsigned long)_tv, (unsigned long)_tz);
> +}
> +
> +static __always_inline
> +int clock_gettime_fallback(clockid_t _clkid, struct __kernel_timespec *_ts)
> +{
> + return do_syscall_2(__NR_clock_gettime, _clkid, (unsigned long)_ts);
Doesn't that need to be __NR_clock_gettime64 for ppc32?
> +}
> +
> +static __always_inline
> +int clock_getres_fallback(clockid_t _clkid, struct __kernel_timespec *_ts)
> +{
> + return do_syscall_2(__NR_clock_getres, _clkid, (unsigned long)_ts);
And here __NR_clock_getres_time64?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH v3 03/19] powerpc: bad_page_fault, do_break get registers from regs
From: Nicholas Piggin @ 2020-12-26 10:58 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <1608970380.delquel806.astroid@bobo.none>
Excerpts from Nicholas Piggin's message of December 26, 2020 6:19 pm:
> Excerpts from Christophe Leroy's message of December 23, 2020 12:42 am:
>>
>>
>> Le 28/11/2020 à 15:40, Nicholas Piggin a écrit :
>>> Similar to the previous patch this makes interrupt handler function
>>> types more regular so they can be wrapped with the next patch.
>>>
>>> bad_page_fault and do_break are not performance critical.
>>
>> I partly took your changes into one of my series, in different order though.
>>
>> Please have a look at https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=221656 patches
>> 4 to 7
>
> Thanks, I had a look. Seems like the result is basically the same as my
> series, so that's good if you like the end result now :)
>
>> I think some of the changes are missing in your series, especially the changes in entry_32.S from
>> patch 7.
>
> Okay I could take them in. In your patch 7/15, why do you leave this
> load of DSISR?
>
> diff --git a/arch/powerpc/kernel/head_book3s_32.S b/arch/powerpc/kernel/head_book3s_32.S
> index 15e6003fd3b8..0133a02d1d47 100644
> --- a/arch/powerpc/kernel/head_book3s_32.S
> +++ b/arch/powerpc/kernel/head_book3s_32.S
> @@ -369,9 +369,9 @@ BEGIN_MMU_FTR_SECTION
> END_MMU_FTR_SECTION_IFSET(MMU_FTR_HPTE_TABLE)
> #endif
> #endif /* CONFIG_VMAP_STACK */
> -1: mr r4,r12
> andis. r5,r9,DSISR_SRR1_MATCH_32S@h /* Filter relevant SRR1 bits */
> - stw r4, _DAR(r11)
> + stw r12, _DAR(r11)
> + stw r5, _DSISR(r11)
> EXC_XFER_LITE(0x400, handle_page_fault)
>
> /* External interrupt */
> @@ -693,7 +693,6 @@ handle_page_fault_tramp_1:
> #ifdef CONFIG_VMAP_STACK
> EXCEPTION_PROLOG_2 handle_dar_dsisr=1
> #endif
> - lwz r4, _DAR(r11)
> lwz r5, _DSISR(r11)
> ^^^^^^^^^^^^^^^^^^^^^^
> /* fall through */
> handle_page_fault_tramp_2:
>
> ?
Ah never mind, this needs to come back after your DABR match move
patch, which you have earlier in the series. I confused myself.
I'll rebase my series on your patch 4 rather than have it squashed
in with other do_break stuff.
Thanks,
Nick
^ 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