* Re: [PATCH v2 12/16] powerpc/powernv: export /proc/opalcore for analysing opal crashes
From: Hari Bathini @ 2019-05-09 4:46 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
Cc: Stewart Smith, Daniel Axtens, Mahesh J Salgaonkar, Vasant Hegde,
Ananth N Mavinakayanahalli
In-Reply-To: <1557274986.rnb0tqdbuc.astroid@bobo.none>
On 08/05/19 5:55 AM, Nicholas Piggin wrote:
> Hari Bathini's on April 16, 2019 8:35 pm:
>> From: Hari Bathini <hbathini@linux.vnet.ibm.com>
>>
>> Export /proc/opalcore file to analyze opal crashes. Since opalcore can
>> be generated independent of CONFIG_FA_DUMP support in kernel, add this
>> support under a new kernel config option CONFIG_OPAL_CORE. Also, avoid
>> code duplication by moving common code used for processing the register
>> state data to export /proc/vmcore and/or /proc/opalcore file(s).
> Can this go in /sys/firmware/opal/core or similar?
>
Sure. Will try to keep it that way..
- Hari
^ permalink raw reply
* Re: [PATCH v2 15/16] powernv/fadump: consider f/w load area
From: Hari Bathini @ 2019-05-09 4:50 UTC (permalink / raw)
To: mahesh
Cc: Ananth N Mavinakayanahalli, Mahesh J Salgaonkar, Nicholas Piggin,
linuxppc-dev, Vasant Hegde, Stewart Smith, Daniel Axtens
In-Reply-To: <20190507171331.p5wwzc3asvpkltxb@in.ibm.com>
On 07/05/19 10:43 PM, Mahesh J Salgaonkar wrote:
> On 2019-04-16 16:06:13 Tue, Hari Bathini wrote:
>> OPAL loads kernel & initrd at 512MB offset (256MB size), also exported
>> as ibm,opal/dump/fw-load-area. So, if boot memory size of FADump is
>> less than 768MB, kernel memory to be exported as '/proc/vmcore' would
>> be overwritten by f/w while loading kernel & initrd. To avoid such a
>> scenario, enforce a minimum boot memory size of 768MB on OPAL platform.
>>
>> Also, skip using FADump if a newer F/W version loads kernel & initrd
>> above 768MB.
>>
>> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
>> ---
>> arch/powerpc/kernel/fadump-common.h | 15 +++++++++++++--
>> arch/powerpc/kernel/fadump.c | 8 ++++++++
>> arch/powerpc/platforms/powernv/opal-fadump.c | 23 +++++++++++++++++++++++
>> 3 files changed, 44 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/fadump-common.h b/arch/powerpc/kernel/fadump-common.h
>> index 1bd3aeb..f59fdc7 100644
>> --- a/arch/powerpc/kernel/fadump-common.h
>> +++ b/arch/powerpc/kernel/fadump-common.h
>> @@ -24,14 +24,25 @@
>> #define RMA_END (ppc64_rma_size)
>>
>> /*
>> + * With kernel & initrd loaded at 512MB (with 256MB size), enforce a minimum
>> + * boot memory size of 768MB to ensure f/w loading kernel and initrd doesn't
>> + * mess with crash'ed kernel's memory during MPIPL.
>> + */
>> +#define OPAL_MIN_BOOT_MEM (0x30000000UL)
>> +
>> +/*
>> * On some Power systems where RMO is 128MB, it still requires minimum of
>> * 256MB for kernel to boot successfully. When kdump infrastructure is
>> * configured to save vmcore over network, we run into OOM issue while
>> * loading modules related to network setup. Hence we need additional 64M
>> * of memory to avoid OOM issue.
>> */
>> -#define MIN_BOOT_MEM (((RMA_END < (0x1UL << 28)) ? (0x1UL << 28) : RMA_END) \
>> - + (0x1UL << 26))
>> +#define PSERIES_MIN_BOOT_MEM (((RMA_END < (0x1UL << 28)) ? (0x1UL << 28) : \
>> + RMA_END) + (0x1UL << 26))
>> +
>> +#define MIN_BOOT_MEM ((fw_dump.fadump_platform == \
>> + FADUMP_PLATFORM_POWERNV) ? OPAL_MIN_BOOT_MEM : \
>> + PSERIES_MIN_BOOT_MEM)
> Can we hide this behind fadump_ops.get_bootmem_min() instead of common code
> doing platform check ?
>
>>
>> /* The upper limit percentage for user specified boot memory size (25%) */
>> #define MAX_BOOT_MEM_RATIO 4
>> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
>> index ba26169..3c3adc2 100644
>> --- a/arch/powerpc/kernel/fadump.c
>> +++ b/arch/powerpc/kernel/fadump.c
>> @@ -582,6 +582,14 @@ int __init fadump_reserve_mem(void)
>> ALIGN(fw_dump.boot_memory_size,
>> FADUMP_CMA_ALIGNMENT);
>> #endif
>> +
>> + if ((fw_dump.fadump_platform == FADUMP_PLATFORM_POWERNV) &&
>> + (fw_dump.boot_memory_size < OPAL_MIN_BOOT_MEM)) {
> and here too.. fadump_ops.validate_bootmem_size() ? push platform specific
> stuff behind fadump_ops.
Actually, it would be fine to make this check for both platforms.
So, fadump_ops.get_bootmem_min() callback can be used at both places, I guess..
- Hari
^ permalink raw reply
* [PATCH v2 2/5] powerpc/powernv: Remove dead SCOM access code
From: Andrew Donnellan @ 2019-05-09 5:11 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20190509051119.7694-1-ajd@linux.ibm.com>
Nothing is using scom_map_device() or scom_find_parent(). Remove them.
Also don't export scom_controller, there are no other users of it.
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
---
v1->v2:
- new patch
---
arch/powerpc/platforms/powernv/scom.c | 67 ---------------------------
arch/powerpc/platforms/powernv/scom.h | 27 -----------
2 files changed, 94 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/scom.c b/arch/powerpc/platforms/powernv/scom.c
index 50c019d2ef45..288580e5fdfe 100644
--- a/arch/powerpc/platforms/powernv/scom.c
+++ b/arch/powerpc/platforms/powernv/scom.c
@@ -28,73 +28,6 @@
#include "scom.h"
const struct scom_controller *scom_controller;
-EXPORT_SYMBOL_GPL(scom_controller);
-
-struct device_node *scom_find_parent(struct device_node *node)
-{
- struct device_node *par, *tmp;
- const u32 *p;
-
- for (par = of_node_get(node); par;) {
- if (of_get_property(par, "scom-controller", NULL))
- break;
- p = of_get_property(par, "scom-parent", NULL);
- tmp = par;
- if (p == NULL)
- par = of_get_parent(par);
- else
- par = of_find_node_by_phandle(*p);
- of_node_put(tmp);
- }
- return par;
-}
-EXPORT_SYMBOL_GPL(scom_find_parent);
-
-scom_map_t scom_map_device(struct device_node *dev, int index)
-{
- struct device_node *parent;
- unsigned int cells, size;
- const __be32 *prop, *sprop;
- u64 reg, cnt;
- scom_map_t ret;
-
- parent = scom_find_parent(dev);
-
- if (parent == NULL)
- return NULL;
-
- /*
- * We support "scom-reg" properties for adding scom registers
- * to a random device-tree node with an explicit scom-parent
- *
- * We also support the simple "reg" property if the device is
- * a direct child of a scom controller.
- *
- * In case both exist, "scom-reg" takes precedence.
- */
- prop = of_get_property(dev, "scom-reg", &size);
- sprop = of_get_property(parent, "#scom-cells", NULL);
- if (!prop && parent == dev->parent) {
- prop = of_get_property(dev, "reg", &size);
- sprop = of_get_property(parent, "#address-cells", NULL);
- }
- if (!prop)
- return NULL;
- cells = sprop ? be32_to_cpup(sprop) : 1;
- size >>= 2;
-
- if (index >= (size / (2*cells)))
- return NULL;
-
- reg = of_read_number(&prop[index * cells * 2], cells);
- cnt = of_read_number(&prop[index * cells * 2 + cells], cells);
-
- ret = scom_map(parent, reg, cnt);
- of_node_put(parent);
-
- return ret;
-}
-EXPORT_SYMBOL_GPL(scom_map_device);
#ifdef CONFIG_SCOM_DEBUGFS
struct scom_debug_entry {
diff --git a/arch/powerpc/platforms/powernv/scom.h b/arch/powerpc/platforms/powernv/scom.h
index b14fe0edf95b..2c72f7fc8726 100644
--- a/arch/powerpc/platforms/powernv/scom.h
+++ b/arch/powerpc/platforms/powernv/scom.h
@@ -88,33 +88,6 @@ static inline scom_map_t scom_map(struct device_node *ctrl_dev,
return scom_controller->map(ctrl_dev, reg, count);
}
-/**
- * scom_find_parent - Find the SCOM controller for a device
- * @dev: OF node of the device
- *
- * This is not meant for general usage, but in combination with
- * scom_map() allows to map registers not represented by the
- * device own scom-reg property. Useful for applying HW workarounds
- * on things not properly represented in the device-tree for example.
- */
-struct device_node *scom_find_parent(struct device_node *dev);
-
-
-/**
- * scom_map_device - Map a device's block of SCOM registers
- * @dev: OF node of the device
- * @index: Register bank index (index in "scom-reg" property)
- *
- * This function will use the device-tree binding for SCOM which
- * is to follow "scom-parent" properties until it finds a node with
- * a "scom-controller" property to find the controller. It will then
- * use the "scom-reg" property which is made of reg/count pairs,
- * each of them having a size defined by the controller's #scom-cells
- * property
- */
-extern scom_map_t scom_map_device(struct device_node *dev, int index);
-
-
/**
* scom_unmap - Unmap a block of SCOM registers
* @map: Result of scom_map is to be unmapped
--
2.20.1
^ permalink raw reply related
* [PATCH v2 1/5] powerpc/powernv: Move SCOM access code into powernv platform
From: Andrew Donnellan @ 2019-05-09 5:11 UTC (permalink / raw)
To: linuxppc-dev
The powernv platform is the only one that directly accesses SCOMs. Move the
support code to platforms/powernv, and get rid of the PPC_SCOM Kconfig
option, as SCOM support is always selected when compiling for powernv.
This also means that the Kconfig item for CONFIG_SCOM_DEBUGFS will actually
show up in menuconfig, as previously it was the only labelled option in
sysdev/Kconfig and wasn't actually in a menu.
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
---
v1->v2:
- move scom.h as well (mpe)
- add all the other patches in this series
---
arch/powerpc/platforms/powernv/Kconfig | 5 ++++-
arch/powerpc/platforms/powernv/Makefile | 2 +-
arch/powerpc/platforms/powernv/opal-xscom.c | 3 ++-
arch/powerpc/{sysdev => platforms/powernv}/scom.c | 3 ++-
.../{include/asm => platforms/powernv}/scom.h | 13 +++----------
arch/powerpc/sysdev/Kconfig | 7 -------
arch/powerpc/sysdev/Makefile | 2 --
7 files changed, 12 insertions(+), 23 deletions(-)
rename arch/powerpc/{sysdev => platforms/powernv}/scom.c (99%)
rename arch/powerpc/{include/asm => platforms/powernv}/scom.h (95%)
diff --git a/arch/powerpc/platforms/powernv/Kconfig b/arch/powerpc/platforms/powernv/Kconfig
index 850eee860cf2..938803eab0ad 100644
--- a/arch/powerpc/platforms/powernv/Kconfig
+++ b/arch/powerpc/platforms/powernv/Kconfig
@@ -12,7 +12,6 @@ config PPC_POWERNV
select EPAPR_BOOT
select PPC_INDIRECT_PIO
select PPC_UDBG_16550
- select PPC_SCOM
select ARCH_RANDOM
select CPU_FREQ
select PPC_DOORBELL
@@ -47,3 +46,7 @@ config PPC_VAS
VAS adapters are found in POWER9 based systems.
If unsure, say N.
+
+config SCOM_DEBUGFS
+ bool "Expose SCOM controllers via debugfs"
+ depends on DEBUG_FS
diff --git a/arch/powerpc/platforms/powernv/Makefile b/arch/powerpc/platforms/powernv/Makefile
index da2e99efbd04..4b1644150135 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -4,12 +4,12 @@ obj-y += idle.o opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
obj-y += rng.o opal-elog.o opal-dump.o opal-sysparam.o opal-sensor.o
obj-y += opal-msglog.o opal-hmi.o opal-power.o opal-irqchip.o
obj-y += opal-kmsg.o opal-powercap.o opal-psr.o opal-sensor-groups.o
+obj-y += opal-xscom.o scom.o
obj-$(CONFIG_SMP) += smp.o subcore.o subcore-asm.o
obj-$(CONFIG_PCI) += pci.o pci-ioda.o npu-dma.o pci-ioda-tce.o
obj-$(CONFIG_CXL_BASE) += pci-cxl.o
obj-$(CONFIG_EEH) += eeh-powernv.o
-obj-$(CONFIG_PPC_SCOM) += opal-xscom.o
obj-$(CONFIG_MEMORY_FAILURE) += opal-memory-errors.o
obj-$(CONFIG_OPAL_PRD) += opal-prd.o
obj-$(CONFIG_PERF_EVENTS) += opal-imc.o
diff --git a/arch/powerpc/platforms/powernv/opal-xscom.c b/arch/powerpc/platforms/powernv/opal-xscom.c
index 22d5e1110dbb..66337d92cb63 100644
--- a/arch/powerpc/platforms/powernv/opal-xscom.c
+++ b/arch/powerpc/platforms/powernv/opal-xscom.c
@@ -18,7 +18,8 @@
#include <asm/machdep.h>
#include <asm/firmware.h>
#include <asm/opal.h>
-#include <asm/scom.h>
+
+#include "scom.h"
/*
* We could probably fit that inside the scom_map_t
diff --git a/arch/powerpc/sysdev/scom.c b/arch/powerpc/platforms/powernv/scom.c
similarity index 99%
rename from arch/powerpc/sysdev/scom.c
rename to arch/powerpc/platforms/powernv/scom.c
index a707b24a7ddb..50c019d2ef45 100644
--- a/arch/powerpc/sysdev/scom.c
+++ b/arch/powerpc/platforms/powernv/scom.c
@@ -23,9 +23,10 @@
#include <linux/export.h>
#include <asm/debugfs.h>
#include <asm/prom.h>
-#include <asm/scom.h>
#include <linux/uaccess.h>
+#include "scom.h"
+
const struct scom_controller *scom_controller;
EXPORT_SYMBOL_GPL(scom_controller);
diff --git a/arch/powerpc/include/asm/scom.h b/arch/powerpc/platforms/powernv/scom.h
similarity index 95%
rename from arch/powerpc/include/asm/scom.h
rename to arch/powerpc/platforms/powernv/scom.h
index f5cde45b1161..b14fe0edf95b 100644
--- a/arch/powerpc/include/asm/scom.h
+++ b/arch/powerpc/platforms/powernv/scom.h
@@ -18,12 +18,8 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-#ifndef _ASM_POWERPC_SCOM_H
-#define _ASM_POWERPC_SCOM_H
-
-#ifdef __KERNEL__
-#ifndef __ASSEMBLY__
-#ifdef CONFIG_PPC_SCOM
+#ifndef _SCOM_H
+#define _SCOM_H
/*
* The SCOM bus is a sideband bus used for accessing various internal
@@ -161,7 +157,4 @@ static inline int scom_write(scom_map_t map, u64 reg, u64 value)
}
-#endif /* CONFIG_PPC_SCOM */
-#endif /* __ASSEMBLY__ */
-#endif /* __KERNEL__ */
-#endif /* _ASM_POWERPC_SCOM_H */
+#endif /* _SCOM_H */
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index e0dbec780fe9..7808d279ff1d 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -28,13 +28,6 @@ config PPC_MSI_BITMAP
source "arch/powerpc/sysdev/xics/Kconfig"
source "arch/powerpc/sysdev/xive/Kconfig"
-config PPC_SCOM
- bool
-
-config SCOM_DEBUGFS
- bool "Expose SCOM controllers via debugfs"
- depends on PPC_SCOM && DEBUG_FS
-
config GE_FPGA
bool
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index aaf23283ba0c..35d52d1d2fc0 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -51,8 +51,6 @@ ifdef CONFIG_SUSPEND
obj-$(CONFIG_PPC_BOOK3S_32) += 6xx-suspend.o
endif
-obj-$(CONFIG_PPC_SCOM) += scom.o
-
obj-$(CONFIG_PPC_EARLY_DEBUG_MEMCONS) += udbg_memcons.o
obj-$(CONFIG_PPC_XICS) += xics/
--
2.20.1
^ permalink raw reply related
* [PATCH v2 4/5] powerpc/powernv: Fix checkpatch warnings in opal-xscom.c
From: Andrew Donnellan @ 2019-05-09 5:11 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20190509051119.7694-1-ajd@linux.ibm.com>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
---
v1->v2:
- new patch
---
arch/powerpc/platforms/powernv/opal-xscom.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-xscom.c b/arch/powerpc/platforms/powernv/opal-xscom.c
index e16b0e346d7e..d9607376822c 100644
--- a/arch/powerpc/platforms/powernv/opal-xscom.c
+++ b/arch/powerpc/platforms/powernv/opal-xscom.c
@@ -95,7 +95,7 @@ static ssize_t scom_debug_read(struct file *filp, char __user *ubuf,
struct scom_debug_entry *ent = filp->private_data;
u64 __user *ubuf64 = (u64 __user *)ubuf;
loff_t off = *ppos;
- ssize_t done = 0;
+ ssize_t done = 0;
u64 reg, reg_base, reg_cnt, val;
int rc;
@@ -120,13 +120,13 @@ static ssize_t scom_debug_read(struct file *filp, char __user *ubuf,
return done;
}
-static ssize_t scom_debug_write(struct file* filp, const char __user *ubuf,
+static ssize_t scom_debug_write(struct file *filp, const char __user *ubuf,
size_t count, loff_t *ppos)
{
struct scom_debug_entry *ent = filp->private_data;
u64 __user *ubuf64 = (u64 __user *)ubuf;
loff_t off = *ppos;
- ssize_t done = 0;
+ ssize_t done = 0;
u64 reg, reg_base, reg_cnt, val;
int rc;
@@ -169,7 +169,7 @@ static int scom_debug_init_one(struct dentry *root, struct device_node *dn,
ent->chip = chip;
snprintf(ent->name, 16, "%08x", chip);
- ent->path.data = (void*)kasprintf(GFP_KERNEL, "%pOF", dn);
+ ent->path.data = (void *)kasprintf(GFP_KERNEL, "%pOF", dn);
ent->path.size = strlen((char *)ent->path.data);
dir = debugfs_create_dir(ent->name, root);
--
2.20.1
^ permalink raw reply related
* [PATCH v2 5/5] powerpc/configs: Disable SCOM_DEBUGFS in powernv_defconfig
From: Andrew Donnellan @ 2019-05-09 5:11 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20190509051119.7694-1-ajd@linux.ibm.com>
SCOM_DEBUGFS is really not needed for anything other than low-level
hardware debugging.
opal-prd uses its own interface (/dev/prd) for SCOM access, so it doesn't
need SCOM_DEBUGFS.
At some point in the future we'll introduce a debug config fragment where
this can go instead.
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
---
v1->v2:
- new patch
---
arch/powerpc/configs/powernv_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/configs/powernv_defconfig b/arch/powerpc/configs/powernv_defconfig
index ef2ef98d3f28..d5a6608cb2e0 100644
--- a/arch/powerpc/configs/powernv_defconfig
+++ b/arch/powerpc/configs/powernv_defconfig
@@ -38,7 +38,7 @@ CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_PARTITION_ADVANCED=y
-CONFIG_SCOM_DEBUGFS=y
+# CONFIG_SCOM_DEBUGFS is not set
CONFIG_OPAL_PRD=y
CONFIG_PPC_MEMTRACE=y
# CONFIG_PPC_PSERIES is not set
--
2.20.1
^ permalink raw reply related
* [PATCH v2 3/5] powerpc/powernv: Get rid of old scom_controller abstraction
From: Andrew Donnellan @ 2019-05-09 5:11 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20190509051119.7694-1-ajd@linux.ibm.com>
Once upon a time, the SCOM access code was used by the WSP platform as well
as powernv. Thus it made sense to have a generic SCOM access interface to
abstract between different platforms.
Now that it's just powernv, with no other platforms currently on the
horizon, let's rip out scom_controller and make everything much simpler and
more direct.
While we're here, fix up the comment block at the top and add a SPDX
header.
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
---
v1->v2:
- new patch
---
arch/powerpc/platforms/powernv/Makefile | 2 +-
arch/powerpc/platforms/powernv/opal-xscom.c | 215 +++++++++++++-------
arch/powerpc/platforms/powernv/scom.c | 170 ----------------
arch/powerpc/platforms/powernv/scom.h | 133 ------------
4 files changed, 143 insertions(+), 377 deletions(-)
delete mode 100644 arch/powerpc/platforms/powernv/scom.c
delete mode 100644 arch/powerpc/platforms/powernv/scom.h
diff --git a/arch/powerpc/platforms/powernv/Makefile b/arch/powerpc/platforms/powernv/Makefile
index 4b1644150135..69a3aefa905b 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -4,7 +4,6 @@ obj-y += idle.o opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
obj-y += rng.o opal-elog.o opal-dump.o opal-sysparam.o opal-sensor.o
obj-y += opal-msglog.o opal-hmi.o opal-power.o opal-irqchip.o
obj-y += opal-kmsg.o opal-powercap.o opal-psr.o opal-sensor-groups.o
-obj-y += opal-xscom.o scom.o
obj-$(CONFIG_SMP) += smp.o subcore.o subcore-asm.o
obj-$(CONFIG_PCI) += pci.o pci-ioda.o npu-dma.o pci-ioda-tce.o
@@ -16,3 +15,4 @@ obj-$(CONFIG_PERF_EVENTS) += opal-imc.o
obj-$(CONFIG_PPC_MEMTRACE) += memtrace.o
obj-$(CONFIG_PPC_VAS) += vas.o vas-window.o vas-debug.o
obj-$(CONFIG_OCXL_BASE) += ocxl.o
+obj-$(CONFIG_SCOM_DEBUGFS) += opal-xscom.o
diff --git a/arch/powerpc/platforms/powernv/opal-xscom.c b/arch/powerpc/platforms/powernv/opal-xscom.c
index 66337d92cb63..e16b0e346d7e 100644
--- a/arch/powerpc/platforms/powernv/opal-xscom.c
+++ b/arch/powerpc/platforms/powernv/opal-xscom.c
@@ -1,6 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0+
/*
- * PowerNV LPC bus handling.
+ * PowerNV SCOM bus debugfs interface
*
+ * Copyright 2010 Benjamin Herrenschmidt, IBM Corp
+ * <benh@kernel.crashing.org>
+ * and David Gibson, IBM Corporation.
* Copyright 2013 IBM Corp.
*
* This program is free software; you can redistribute it and/or
@@ -14,63 +18,13 @@
#include <linux/bug.h>
#include <linux/gfp.h>
#include <linux/slab.h>
+#include <linux/uaccess.h>
#include <asm/machdep.h>
#include <asm/firmware.h>
#include <asm/opal.h>
-
-#include "scom.h"
-
-/*
- * We could probably fit that inside the scom_map_t
- * which is a void* after all but it's really too ugly
- * so let's kmalloc it for now
- */
-struct opal_scom_map {
- uint32_t chip;
- uint64_t addr;
-};
-
-static scom_map_t opal_scom_map(struct device_node *dev, u64 reg, u64 count)
-{
- struct opal_scom_map *m;
- const __be32 *gcid;
-
- if (!of_get_property(dev, "scom-controller", NULL)) {
- pr_err("%s: device %pOF is not a SCOM controller\n",
- __func__, dev);
- return SCOM_MAP_INVALID;
- }
- gcid = of_get_property(dev, "ibm,chip-id", NULL);
- if (!gcid) {
- pr_err("%s: device %pOF has no ibm,chip-id\n",
- __func__, dev);
- return SCOM_MAP_INVALID;
- }
- m = kmalloc(sizeof(*m), GFP_KERNEL);
- if (!m)
- return NULL;
- m->chip = be32_to_cpup(gcid);
- m->addr = reg;
-
- return (scom_map_t)m;
-}
-
-static void opal_scom_unmap(scom_map_t map)
-{
- kfree(map);
-}
-
-static int opal_xscom_err_xlate(int64_t rc)
-{
- switch(rc) {
- case 0:
- return 0;
- /* Add more translations if necessary */
- default:
- return -EIO;
- }
-}
+#include <asm/debugfs.h>
+#include <asm/prom.h>
static u64 opal_scom_unmangle(u64 addr)
{
@@ -103,39 +57,154 @@ static u64 opal_scom_unmangle(u64 addr)
return addr;
}
-static int opal_scom_read(scom_map_t map, u64 reg, u64 *value)
+static int opal_scom_read(uint32_t chip, uint64_t addr, u64 reg, u64 *value)
{
- struct opal_scom_map *m = map;
int64_t rc;
__be64 v;
- reg = opal_scom_unmangle(m->addr + reg);
- rc = opal_xscom_read(m->chip, reg, (__be64 *)__pa(&v));
+ reg = opal_scom_unmangle(addr + reg);
+ rc = opal_xscom_read(chip, reg, (__be64 *)__pa(&v));
+ if (rc) {
+ *value = 0xfffffffffffffffful;
+ return -EIO;
+ }
*value = be64_to_cpu(v);
- return opal_xscom_err_xlate(rc);
+ return 0;
}
-static int opal_scom_write(scom_map_t map, u64 reg, u64 value)
+static int opal_scom_write(uint32_t chip, uint64_t addr, u64 reg, u64 value)
{
- struct opal_scom_map *m = map;
int64_t rc;
- reg = opal_scom_unmangle(m->addr + reg);
- rc = opal_xscom_write(m->chip, reg, value);
- return opal_xscom_err_xlate(rc);
+ reg = opal_scom_unmangle(addr + reg);
+ rc = opal_xscom_write(chip, reg, value);
+ if (rc)
+ return -EIO;
+ return 0;
+}
+
+struct scom_debug_entry {
+ u32 chip;
+ struct debugfs_blob_wrapper path;
+ char name[16];
+};
+
+static ssize_t scom_debug_read(struct file *filp, char __user *ubuf,
+ size_t count, loff_t *ppos)
+{
+ struct scom_debug_entry *ent = filp->private_data;
+ u64 __user *ubuf64 = (u64 __user *)ubuf;
+ loff_t off = *ppos;
+ ssize_t done = 0;
+ u64 reg, reg_base, reg_cnt, val;
+ int rc;
+
+ if (off < 0 || (off & 7) || (count & 7))
+ return -EINVAL;
+ reg_base = off >> 3;
+ reg_cnt = count >> 3;
+
+ for (reg = 0; reg < reg_cnt; reg++) {
+ rc = opal_scom_read(ent->chip, reg_base, reg, &val);
+ if (!rc)
+ rc = put_user(val, ubuf64);
+ if (rc) {
+ if (!done)
+ done = rc;
+ break;
+ }
+ ubuf64++;
+ *ppos += 8;
+ done += 8;
+ }
+ return done;
+}
+
+static ssize_t scom_debug_write(struct file* filp, const char __user *ubuf,
+ size_t count, loff_t *ppos)
+{
+ struct scom_debug_entry *ent = filp->private_data;
+ u64 __user *ubuf64 = (u64 __user *)ubuf;
+ loff_t off = *ppos;
+ ssize_t done = 0;
+ u64 reg, reg_base, reg_cnt, val;
+ int rc;
+
+ if (off < 0 || (off & 7) || (count & 7))
+ return -EINVAL;
+ reg_base = off >> 3;
+ reg_cnt = count >> 3;
+
+ for (reg = 0; reg < reg_cnt; reg++) {
+ rc = get_user(val, ubuf64);
+ if (!rc)
+ rc = opal_scom_write(ent->chip, reg_base, reg, val);
+ if (rc) {
+ if (!done)
+ done = rc;
+ break;
+ }
+ ubuf64++;
+ done += 8;
+ }
+ return done;
}
-static const struct scom_controller opal_scom_controller = {
- .map = opal_scom_map,
- .unmap = opal_scom_unmap,
- .read = opal_scom_read,
- .write = opal_scom_write
+static const struct file_operations scom_debug_fops = {
+ .read = scom_debug_read,
+ .write = scom_debug_write,
+ .open = simple_open,
+ .llseek = default_llseek,
};
-static int opal_xscom_init(void)
+static int scom_debug_init_one(struct dentry *root, struct device_node *dn,
+ int chip)
{
- if (firmware_has_feature(FW_FEATURE_OPAL))
- scom_init(&opal_scom_controller);
+ struct scom_debug_entry *ent;
+ struct dentry *dir;
+
+ ent = kzalloc(sizeof(*ent), GFP_KERNEL);
+ if (!ent)
+ return -ENOMEM;
+
+ ent->chip = chip;
+ snprintf(ent->name, 16, "%08x", chip);
+ ent->path.data = (void*)kasprintf(GFP_KERNEL, "%pOF", dn);
+ ent->path.size = strlen((char *)ent->path.data);
+
+ dir = debugfs_create_dir(ent->name, root);
+ if (!dir) {
+ kfree(ent->path.data);
+ kfree(ent);
+ return -1;
+ }
+
+ debugfs_create_blob("devspec", 0400, dir, &ent->path);
+ debugfs_create_file("access", 0600, dir, ent, &scom_debug_fops);
+
return 0;
}
-machine_arch_initcall(powernv, opal_xscom_init);
+
+static int scom_debug_init(void)
+{
+ struct device_node *dn;
+ struct dentry *root;
+ int chip, rc;
+
+ if (!firmware_has_feature(FW_FEATURE_OPAL))
+ return 0;
+
+ root = debugfs_create_dir("scom", powerpc_debugfs_root);
+ if (!root)
+ return -1;
+
+ rc = 0;
+ for_each_node_with_property(dn, "scom-controller") {
+ chip = of_get_ibm_chip_id(dn);
+ WARN_ON(chip == -1);
+ rc |= scom_debug_init_one(root, dn, chip);
+ }
+
+ return rc;
+}
+device_initcall(scom_debug_init);
diff --git a/arch/powerpc/platforms/powernv/scom.c b/arch/powerpc/platforms/powernv/scom.c
deleted file mode 100644
index 288580e5fdfe..000000000000
--- a/arch/powerpc/platforms/powernv/scom.c
+++ /dev/null
@@ -1,170 +0,0 @@
-/*
- * Copyright 2010 Benjamin Herrenschmidt, IBM Corp
- * <benh@kernel.crashing.org>
- * and David Gibson, IBM Corporation.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
- * the GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-#include <linux/kernel.h>
-#include <linux/slab.h>
-#include <linux/export.h>
-#include <asm/debugfs.h>
-#include <asm/prom.h>
-#include <linux/uaccess.h>
-
-#include "scom.h"
-
-const struct scom_controller *scom_controller;
-
-#ifdef CONFIG_SCOM_DEBUGFS
-struct scom_debug_entry {
- struct device_node *dn;
- struct debugfs_blob_wrapper path;
- char name[16];
-};
-
-static ssize_t scom_debug_read(struct file *filp, char __user *ubuf,
- size_t count, loff_t *ppos)
-{
- struct scom_debug_entry *ent = filp->private_data;
- u64 __user *ubuf64 = (u64 __user *)ubuf;
- loff_t off = *ppos;
- ssize_t done = 0;
- u64 reg, reg_cnt, val;
- scom_map_t map;
- int rc;
-
- if (off < 0 || (off & 7) || (count & 7))
- return -EINVAL;
- reg = off >> 3;
- reg_cnt = count >> 3;
-
- map = scom_map(ent->dn, reg, reg_cnt);
- if (!scom_map_ok(map))
- return -ENXIO;
-
- for (reg = 0; reg < reg_cnt; reg++) {
- rc = scom_read(map, reg, &val);
- if (!rc)
- rc = put_user(val, ubuf64);
- if (rc) {
- if (!done)
- done = rc;
- break;
- }
- ubuf64++;
- *ppos += 8;
- done += 8;
- }
- scom_unmap(map);
- return done;
-}
-
-static ssize_t scom_debug_write(struct file* filp, const char __user *ubuf,
- size_t count, loff_t *ppos)
-{
- struct scom_debug_entry *ent = filp->private_data;
- u64 __user *ubuf64 = (u64 __user *)ubuf;
- loff_t off = *ppos;
- ssize_t done = 0;
- u64 reg, reg_cnt, val;
- scom_map_t map;
- int rc;
-
- if (off < 0 || (off & 7) || (count & 7))
- return -EINVAL;
- reg = off >> 3;
- reg_cnt = count >> 3;
-
- map = scom_map(ent->dn, reg, reg_cnt);
- if (!scom_map_ok(map))
- return -ENXIO;
-
- for (reg = 0; reg < reg_cnt; reg++) {
- rc = get_user(val, ubuf64);
- if (!rc)
- rc = scom_write(map, reg, val);
- if (rc) {
- if (!done)
- done = rc;
- break;
- }
- ubuf64++;
- done += 8;
- }
- scom_unmap(map);
- return done;
-}
-
-static const struct file_operations scom_debug_fops = {
- .read = scom_debug_read,
- .write = scom_debug_write,
- .open = simple_open,
- .llseek = default_llseek,
-};
-
-static int scom_debug_init_one(struct dentry *root, struct device_node *dn,
- int i)
-{
- struct scom_debug_entry *ent;
- struct dentry *dir;
-
- ent = kzalloc(sizeof(*ent), GFP_KERNEL);
- if (!ent)
- return -ENOMEM;
-
- ent->dn = of_node_get(dn);
- snprintf(ent->name, 16, "%08x", i);
- ent->path.data = (void*)kasprintf(GFP_KERNEL, "%pOF", dn);
- ent->path.size = strlen((char *)ent->path.data);
-
- dir = debugfs_create_dir(ent->name, root);
- if (!dir) {
- of_node_put(dn);
- kfree(ent->path.data);
- kfree(ent);
- return -1;
- }
-
- debugfs_create_blob("devspec", 0400, dir, &ent->path);
- debugfs_create_file("access", 0600, dir, ent, &scom_debug_fops);
-
- return 0;
-}
-
-static int scom_debug_init(void)
-{
- struct device_node *dn;
- struct dentry *root;
- int i, rc;
-
- root = debugfs_create_dir("scom", powerpc_debugfs_root);
- if (!root)
- return -1;
-
- i = rc = 0;
- for_each_node_with_property(dn, "scom-controller") {
- int id = of_get_ibm_chip_id(dn);
- if (id == -1)
- id = i;
- rc |= scom_debug_init_one(root, dn, id);
- i++;
- }
-
- return rc;
-}
-device_initcall(scom_debug_init);
-#endif /* CONFIG_SCOM_DEBUGFS */
diff --git a/arch/powerpc/platforms/powernv/scom.h b/arch/powerpc/platforms/powernv/scom.h
deleted file mode 100644
index 2c72f7fc8726..000000000000
--- a/arch/powerpc/platforms/powernv/scom.h
+++ /dev/null
@@ -1,133 +0,0 @@
-/*
- * Copyright 2010 Benjamin Herrenschmidt, IBM Corp
- * <benh@kernel.crashing.org>
- * and David Gibson, IBM Corporation.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
- * the GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-#ifndef _SCOM_H
-#define _SCOM_H
-
-/*
- * The SCOM bus is a sideband bus used for accessing various internal
- * registers of the processor or the chipset. The implementation details
- * differ between processors and platforms, and the access method as
- * well.
- *
- * This API allows to "map" ranges of SCOM register numbers associated
- * with a given SCOM controller. The later must be represented by a
- * device node, though some implementations might support NULL if there
- * is no possible ambiguity
- *
- * Then, scom_read/scom_write can be used to accesses registers inside
- * that range. The argument passed is a register number relative to
- * the beginning of the range mapped.
- */
-
-typedef void *scom_map_t;
-
-/* Value for an invalid SCOM map */
-#define SCOM_MAP_INVALID (NULL)
-
-/* The scom_controller data structure is what the platform passes
- * to the core code in scom_init, it provides the actual implementation
- * of all the SCOM functions
- */
-struct scom_controller {
- scom_map_t (*map)(struct device_node *ctrl_dev, u64 reg, u64 count);
- void (*unmap)(scom_map_t map);
-
- int (*read)(scom_map_t map, u64 reg, u64 *value);
- int (*write)(scom_map_t map, u64 reg, u64 value);
-};
-
-extern const struct scom_controller *scom_controller;
-
-/**
- * scom_init - Initialize the SCOM backend, called by the platform
- * @controller: The platform SCOM controller
- */
-static inline void scom_init(const struct scom_controller *controller)
-{
- scom_controller = controller;
-}
-
-/**
- * scom_map_ok - Test is a SCOM mapping is successful
- * @map: The result of scom_map to test
- */
-static inline int scom_map_ok(scom_map_t map)
-{
- return map != SCOM_MAP_INVALID;
-}
-
-/**
- * scom_map - Map a block of SCOM registers
- * @ctrl_dev: Device node of the SCOM controller
- * some implementations allow NULL here
- * @reg: first SCOM register to map
- * @count: Number of SCOM registers to map
- */
-
-static inline scom_map_t scom_map(struct device_node *ctrl_dev,
- u64 reg, u64 count)
-{
- return scom_controller->map(ctrl_dev, reg, count);
-}
-
-/**
- * scom_unmap - Unmap a block of SCOM registers
- * @map: Result of scom_map is to be unmapped
- */
-static inline void scom_unmap(scom_map_t map)
-{
- if (scom_map_ok(map))
- scom_controller->unmap(map);
-}
-
-/**
- * scom_read - Read a SCOM register
- * @map: Result of scom_map
- * @reg: Register index within that map
- * @value: Updated with the value read
- *
- * Returns 0 (success) or a negative error code
- */
-static inline int scom_read(scom_map_t map, u64 reg, u64 *value)
-{
- int rc;
-
- rc = scom_controller->read(map, reg, value);
- if (rc)
- *value = 0xfffffffffffffffful;
- return rc;
-}
-
-/**
- * scom_write - Write to a SCOM register
- * @map: Result of scom_map
- * @reg: Register index within that map
- * @value: Value to write
- *
- * Returns 0 (success) or a negative error code
- */
-static inline int scom_write(scom_map_t map, u64 reg, u64 value)
-{
- return scom_controller->write(map, reg, value);
-}
-
-
-#endif /* _SCOM_H */
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] crypto: caam/jr - Remove extra memory barrier during job ring dequeue
From: Herbert Xu @ 2019-05-09 5:23 UTC (permalink / raw)
To: Horia Geanta
Cc: Aymen Sghaier, linux-crypto@vger.kernel.org, Vakul Garg,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <VI1PR0402MB34851F6AB9FE68A2322EB09E98340@VI1PR0402MB3485.eurprd04.prod.outlook.com>
On Thu, May 02, 2019 at 11:08:55AM +0000, Horia Geanta wrote:
>
> >> +
> >> static inline void wr_reg32(void __iomem *reg, u32 data)
> >> {
> >> if (caam_little_end)
> >
> > This crashes on my p5020ds. Did you test on powerpc?
> >
> > # first bad commit: [bbfcac5ff5f26aafa51935a62eb86b6eacfe8a49] crypto: caam/jr - Remove extra memory barrier during job ring dequeue
>
> Thanks for the report Michael.
>
> Any hint what would be the proper approach here - to have relaxed I/O accessors
> that would work both for ARM and PPC, and avoid ifdeffery etc.?
Since no fix has been found I'm reverting the commit in question.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 5/5] powerpc/configs: Disable SCOM_DEBUGFS in powernv_defconfig
From: Nicholas Piggin @ 2019-05-09 5:37 UTC (permalink / raw)
To: Andrew Donnellan, linuxppc-dev
In-Reply-To: <20190509051119.7694-5-ajd@linux.ibm.com>
Andrew Donnellan's on May 9, 2019 3:11 pm:
> SCOM_DEBUGFS is really not needed for anything other than low-level
> hardware debugging.
>
> opal-prd uses its own interface (/dev/prd) for SCOM access, so it doesn't
> need SCOM_DEBUGFS.
>
> At some point in the future we'll introduce a debug config fragment where
> this can go instead.
That doesn't really explain why you want to disable it. It is useful
for low level hardware debugging, I added it.
obscurity^Wsecurity?
>
> Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
> ---
> v1->v2:
> - new patch
> ---
> arch/powerpc/configs/powernv_defconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/configs/powernv_defconfig b/arch/powerpc/configs/powernv_defconfig
> index ef2ef98d3f28..d5a6608cb2e0 100644
> --- a/arch/powerpc/configs/powernv_defconfig
> +++ b/arch/powerpc/configs/powernv_defconfig
> @@ -38,7 +38,7 @@ CONFIG_MODULE_UNLOAD=y
> CONFIG_MODVERSIONS=y
> CONFIG_MODULE_SRCVERSION_ALL=y
> CONFIG_PARTITION_ADVANCED=y
> -CONFIG_SCOM_DEBUGFS=y
> +# CONFIG_SCOM_DEBUGFS is not set
> CONFIG_OPAL_PRD=y
> CONFIG_PPC_MEMTRACE=y
> # CONFIG_PPC_PSERIES is not set
> --
> 2.20.1
>
>
^ permalink raw reply
* Re: [PATCH v2 5/5] powerpc/configs: Disable SCOM_DEBUGFS in powernv_defconfig
From: Oliver @ 2019-05-09 5:53 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev, Andrew Donnellan
In-Reply-To: <1557380130.bkras9z1l5.astroid@bobo.none>
On Thu, May 9, 2019 at 3:38 PM Nicholas Piggin <npiggin@gmail.com> wrote:
>
> Andrew Donnellan's on May 9, 2019 3:11 pm:
> > SCOM_DEBUGFS is really not needed for anything other than low-level
> > hardware debugging.
> >
> > opal-prd uses its own interface (/dev/prd) for SCOM access, so it doesn't
> > need SCOM_DEBUGFS.
> >
> > At some point in the future we'll introduce a debug config fragment where
> > this can go instead.
>
> That doesn't really explain why you want to disable it. It is useful
> for low level hardware debugging, I added it.
>
> obscurity^Wsecurity?
Yeah... If you're building powernv_defconfig then the odds are pretty
high that you'll want scom access.
>
> >
> > Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
> > ---
> > v1->v2:
> > - new patch
> > ---
> > arch/powerpc/configs/powernv_defconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/configs/powernv_defconfig b/arch/powerpc/configs/powernv_defconfig
> > index ef2ef98d3f28..d5a6608cb2e0 100644
> > --- a/arch/powerpc/configs/powernv_defconfig
> > +++ b/arch/powerpc/configs/powernv_defconfig
> > @@ -38,7 +38,7 @@ CONFIG_MODULE_UNLOAD=y
> > CONFIG_MODVERSIONS=y
> > CONFIG_MODULE_SRCVERSION_ALL=y
> > CONFIG_PARTITION_ADVANCED=y
> > -CONFIG_SCOM_DEBUGFS=y
> > +# CONFIG_SCOM_DEBUGFS is not set
> > CONFIG_OPAL_PRD=y
> > CONFIG_PPC_MEMTRACE=y
> > # CONFIG_PPC_PSERIES is not set
> > --
> > 2.20.1
> >
> >
^ permalink raw reply
* Re: [PATCH v2 5/5] powerpc/configs: Disable SCOM_DEBUGFS in powernv_defconfig
From: Andrew Donnellan @ 2019-05-09 5:54 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <1557380130.bkras9z1l5.astroid@bobo.none>
On 9/5/19 3:37 pm, Nicholas Piggin wrote:
> Andrew Donnellan's on May 9, 2019 3:11 pm:
>> SCOM_DEBUGFS is really not needed for anything other than low-level
>> hardware debugging.
>>
>> opal-prd uses its own interface (/dev/prd) for SCOM access, so it doesn't
>> need SCOM_DEBUGFS.
>>
>> At some point in the future we'll introduce a debug config fragment where
>> this can go instead.
>
> That doesn't really explain why you want to disable it. It is useful
> for low level hardware debugging, I added it.
>
> obscurity^Wsecurity?
Mostly just a general feeling that it's not something we need to have by
default. Security-wise, PRD still provides SCOM access, though we are
going to look at how we can further lock that down. Shrinks the build by
only a few kilobytes...
mpe said he's planning on adding a debug.config where we can shift stuff
like this, and if/when we do that I would like to see this moved there,
but perhaps this patch can wait until then. I'll let mpe decide.
Andrew
>
>>
>> Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
>> ---
>> v1->v2:
>> - new patch
>> ---
>> arch/powerpc/configs/powernv_defconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/configs/powernv_defconfig b/arch/powerpc/configs/powernv_defconfig
>> index ef2ef98d3f28..d5a6608cb2e0 100644
>> --- a/arch/powerpc/configs/powernv_defconfig
>> +++ b/arch/powerpc/configs/powernv_defconfig
>> @@ -38,7 +38,7 @@ CONFIG_MODULE_UNLOAD=y
>> CONFIG_MODVERSIONS=y
>> CONFIG_MODULE_SRCVERSION_ALL=y
>> CONFIG_PARTITION_ADVANCED=y
>> -CONFIG_SCOM_DEBUGFS=y
>> +# CONFIG_SCOM_DEBUGFS is not set
>> CONFIG_OPAL_PRD=y
>> CONFIG_PPC_MEMTRACE=y
>> # CONFIG_PPC_PSERIES is not set
>> --
>> 2.20.1
>>
>>
>
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [next-20190507][powerpc] WARN kernel/cgroup/cgroup.c:6008 with LTP ptrace01 test case
From: Sachin Sant @ 2019-05-09 6:05 UTC (permalink / raw)
To: Roman Gushchin
Cc: Tejun Heo, linux-next@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, Oleg Nesterov
In-Reply-To: <20190508232338.GB1104@tower.DHCP.thefacebook.com>
[-- Attachment #1: Type: text/plain, Size: 3454 bytes --]
> On 09-May-2019, at 4:53 AM, Roman Gushchin <guro@fb.com> wrote:
>
> On Wed, May 08, 2019 at 03:06:30PM +0530, Sachin Sant wrote:
>> While running LTP tests(specifically ptrace01) following WARNING is observed
>> on POWER8 LPAR running next-20190507 built using 4K page size.
>>
>> [ 3969.979492] msgrcv04 (433) used greatest stack depth: 9328 bytes left
>> [ 3981.452911] madvise06 (515): drop_caches: 3
>> [ 4004.575752] WARNING: CPU: 5 PID: 721 at kernel/cgroup/cgroup.c:6008 cgroup_exit+0x2ac/0x2c0
>> [ 4004.575781] Modules linked in: overlay rpadlpar_io rpaphp iptable_mangle xt_MASQUERADE iptable_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 xt_tcpudp tun bridge stp llc kvm iptable_filter pseries_rng rng_core vmx_crypto ip_tables x_tables autofs4 [last unloaded: dummy_del_mod]
>> [ 4004.575837] CPU: 5 PID: 721 Comm: ptrace01 Tainted: G O 5.1.0-next-20190507-autotest #1
>> [ 4004.575846] NIP: c000000001b3026c LR: c000000001b30054 CTR: c000000001c9f020
>> [ 4004.575855] REGS: c000000171fff840 TRAP: 0700 Tainted: G O (5.1.0-next-20190507-autotest)
>> [ 4004.575863] MSR: 800000010282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]> CR: 44004824 XER: 20000000
>> [ 4004.575885] CFAR: c000000001b30078 IRQMASK: 1
>> [ 4004.575885] GPR00: c000000001b30054 c000000171fffad0 c000000003938700 c00000027b02fa18
>> [ 4004.575885] GPR04: c00000027b02fa00 0000000000000000 c000000003ae8700 00000000001c180a
>> [ 4004.575885] GPR08: 0000000000000001 0000000000000001 c000000003ae8700 0000000000000001
>> [ 4004.575885] GPR12: 0000000000004400 c00000001ec7ea80 c000000003a4d670 0000000000000009
>> [ 4004.575885] GPR16: 0000000000000000 0000000000040100 00000000418004fc 0000000008430000
>> [ 4004.575885] GPR20: 0000000000000009 0000000000000001 c0000001715e9200 c00000016d8f4d00
>> [ 4004.575885] GPR24: c000000171fffd90 0000000000000100 c000000168692478 c000000171fffb98
>> [ 4004.575885] GPR28: c000000168692400 c00000016d8f4d00 c0000000036420d0 c00000027b02fa00
>> [ 4004.575958] NIP [c000000001b3026c] cgroup_exit+0x2ac/0x2c0
>> [ 4004.575966] LR [c000000001b30054] cgroup_exit+0x94/0x2c0
>> [ 4004.575972] Call Trace:
>> [ 4004.575979] [c000000171fffad0] [c000000001b30054] cgroup_exit+0x94/0x2c0 (unreliable)
>> [ 4004.575990] [c000000171fffb30] [c0000000019cea98] do_exit+0x878/0x1ae0
>> [ 4004.575999] [c000000171fffc00] [c0000000019cfe4c] do_group_exit+0xac/0x1d0
>> [ 4004.576009] [c000000171fffc40] [c0000000019ed00c] get_signal+0x2bc/0x11c0
>> [ 4004.576019] [c000000171fffd30] [c000000001867b14] do_notify_resume+0x384/0x900
>> [ 4004.576029] [c000000171fffe20] [c00000000183e844] ret_from_except_lite+0x70/0x74
>> [ 4004.576037] Instruction dump:
>> [ 4004.576043] 314a0001 7d40492d 40c2fff4 3d42001b e92a7288 39290001 f92a7288 4bfffe5c
>> [ 4004.576056] 3d42001b e92a7258 39290001 f92a7258 <0fe00000> 4bfffe0c 4be91e45 60000000
>> [ 4004.576071] ---[ end trace 82a1a7c19005ebd6 ]—
>>
>> The WARN_ONCE was added by following commit
>> 96b9c592def5 ("cgroup: get rid of cgroup_freezer_frozen_exit()”).
>>
>> Reverting the patch helps avoid the warning.
>
> Hi Sachin!
>
> Thank you for the report!
>
> Can you, please, check that the patch at https://lkml.org/lkml/2019/5/8/938 <https://lkml.org/lkml/2019/5/8/938>
> solves the problem?
>
This patch fixes the problem for me.
Thanks
-Sachin
[-- Attachment #2: Type: text/html, Size: 10727 bytes --]
^ permalink raw reply
* Re: [PATCH v5 00/16] KVM: PPC: Book3S HV: add XIVE native exploitation mode
From: Cédric Le Goater @ 2019-05-09 6:34 UTC (permalink / raw)
To: Satheesh Rajendran
Cc: linuxppc-dev, Paul Mackerras, kvm, kvm-ppc, David Gibson
In-Reply-To: <827f230f-1b56-db89-be21-1b2dbd44ef08@kaod.org>
Satheesh,
>> Xive(both ic-mode=dual and ic-mode=xive) guest fails to boot with
>> guest memory > 64G, till 64G it boots fine.
>>
>> Note: xics(ic-mode=xics) guest with the same configuration boots fine
>
> Indeed. The guest hangs because IPIs are not correctly received. The guest
> sees the EQ page as being filled with zeroes and discards the interrupt
> whereas the host, KVM and QEMU, sees the correct entries.
>
> I haven't spotted anything bizarre from guest side. Do we have a 64GB
> frontier somewhere in KVM ?
The issue was an erroneous assignment of the EQ page address in QEMU.
I pushed the fix in my QEMU branch :
https://github.com/legoater/qemu/commits/xive-next
Thanks,
C.
^ permalink raw reply
* Re: Build failure in v4.4.y.queue (ppc:allmodconfig)
From: Greg Kroah-Hartman @ 2019-05-09 6:53 UTC (permalink / raw)
To: Guenter Roeck, Michael Ellerman; +Cc: linuxppc-dev, stable
In-Reply-To: <20190508202642.GA28212@roeck-us.net>
On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
> I see multiple instances of:
>
> arch/powerpc/kernel/exceptions-64s.S:839: Error:
> attempt to move .org backwards
>
> in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
>
> This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store
> forwarding barrier at kernel entry/exit"), which is part of a large patch
> series and can not easily be reverted.
>
> Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
Michael, I thought this patch series was supposed to fix ppc issues, not
add to them :)
Any ideas on what to do here?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 5/8] mm/memory_hotplug: Drop MHP_MEMBLOCK_API
From: David Hildenbrand @ 2019-05-09 7:05 UTC (permalink / raw)
To: osalvador, Dan Williams
Cc: linux-s390, Michal Hocko, linux-ia64, Pavel Tatashin, Linux-sh,
Mathieu Malaterre, Linux Kernel Mailing List, Wei Yang, Linux MM,
Qian Cai, Arun KS, Andrew Morton, linuxppc-dev, Joonsoo Kim
In-Reply-To: <1557356938.3028.35.camel@suse.com>
On 09.05.19 01:08, osalvador wrote:
> On Wed, 2019-05-08 at 09:39 +0200, David Hildenbrand wrote:
>> However I haven't really thought it through yet, smalles like that
>> could
>> as well just be handled by the caller of
>> arch_add_memory()/arch_remove_memory() eventually, passing it via
>> something like the altmap parameter.
>>
>> Let's leave it in place for now, we can talk about that once we have
>> new
>> patches from Oscar.
> Hi David,
>
> I plan to send a new patchset once this is and Dan's are merged,
> otherwise I will have a mayhem with the conflicts.
>
> I also plan/want to review this patchset, but time is tight this week.
>
Sure, take your time. I'll resend this patch set most probably tomorrow
or early next week. Cheers!
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH] [v2] x86/mpx: fix recursive munmap() corruption
From: Ingo Molnar @ 2019-05-09 8:31 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-arch, hjl.tools, mhocko, rguenther, richard, gxt, jdike,
x86, linux-um, linux-kernel, stable, luto, linux-mm, paulus,
yang.shi, akpm, linuxppc-dev, vbabka, anton.ivanov
In-Reply-To: <20190419194747.5E1AD6DC@viggo.jf.intel.com>
* Dave Hansen <dave.hansen@linux.intel.com> wrote:
> Reported-by: Richard Biener <rguenther@suse.de>
> Reported-by: H.J. Lu <hjl.tools@gmail.com>
> Fixes: dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap")
> Cc: Yang Shi <yang.shi@linux.alibaba.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: x86@kernel.org
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-mm@kvack.org
> Cc: stable@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-um@lists.infradead.org
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linux-arch@vger.kernel.org
> Cc: Guan Xuetao <gxt@pku.edu.cn>
> Cc: Jeff Dike <jdike@addtoit.com>
> Cc: Richard Weinberger <richard@nod.at>
> Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
I've also added your:
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Because I suppose you intended to sign off on it?
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH] powerpc: Fix compile issue with force DAWR
From: Christophe Leroy @ 2019-05-09 8:45 UTC (permalink / raw)
To: Michael Neuling, mpe; +Cc: linuxppc-dev
In-Reply-To: <20190508013047.12850-1-mikey@neuling.org>
Le 08/05/2019 à 03:30, Michael Neuling a écrit :
> If you compile with KVM but without CONFIG_HAVE_HW_BREAKPOINT you fail
> at linking with:
> arch/powerpc/kvm/book3s_hv_rmhandlers.o:(.text+0x708): undefined reference to `dawr_force_enable'
>
> This was caused by this recent patch:
> commit c1fe190c06723322f2dfac31d3b982c581e434ef
> Author: Michael Neuling <mikey@neuling.org>
> powerpc: Add force enable of DAWR on P9 option
I think you should use the standard commit format, checkpatch will tell you.
>
> This builds dawr_force_enable in always via a new file.
Do we really need a new file just for that ?
As far as I understand, it is always compiled in, so can't we use
another file like traps.o or setup-common.o or somewhere else ?
Or just put an ifdef in arch/powerpc/kvm/book3s_hv_rmhandlers.S ?
Because your fix will put dawr_force_enable on every build even the ones
who don't need it at all.
Christophe
>
> Signed-off-by: Michael Neuling <mikey@neuling.org> > ---
> arch/powerpc/kernel/Makefile | 2 +-
> arch/powerpc/kernel/dawr.c | 11 +++++++++++
> arch/powerpc/kernel/hw_breakpoint.c | 3 ---
> 3 files changed, 12 insertions(+), 4 deletions(-)
> create mode 100644 arch/powerpc/kernel/dawr.c
>
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index 0ea6c4aa3a..48a20ef5be 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -49,7 +49,7 @@ obj-y := cputable.o ptrace.o syscalls.o \
> signal.o sysfs.o cacheinfo.o time.o \
> prom.o traps.o setup-common.o \
> udbg.o misc.o io.o misc_$(BITS).o \
> - of_platform.o prom_parse.o
> + of_platform.o prom_parse.o dawr.o
> obj-$(CONFIG_PPC64) += setup_64.o sys_ppc32.o \
> signal_64.o ptrace32.o \
> paca.o nvram_64.o firmware.o
> diff --git a/arch/powerpc/kernel/dawr.c b/arch/powerpc/kernel/dawr.c
> new file mode 100644
> index 0000000000..ca343efd23
> --- /dev/null
> +++ b/arch/powerpc/kernel/dawr.c
> @@ -0,0 +1,11 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +//
> +// DAWR global variables
> +//
> +// Copyright 2019, Michael Neuling, IBM Corporation.
> +
> +#include <linux/types.h>
> +#include <linux/export.h>
> +
> +bool dawr_force_enable;
> +EXPORT_SYMBOL_GPL(dawr_force_enable);
> diff --git a/arch/powerpc/kernel/hw_breakpoint.c b/arch/powerpc/kernel/hw_breakpoint.c
> index da307dd93e..78a17454f4 100644
> --- a/arch/powerpc/kernel/hw_breakpoint.c
> +++ b/arch/powerpc/kernel/hw_breakpoint.c
> @@ -381,9 +381,6 @@ void hw_breakpoint_pmu_read(struct perf_event *bp)
> /* TODO */
> }
>
> -bool dawr_force_enable;
> -EXPORT_SYMBOL_GPL(dawr_force_enable);
> -
> static ssize_t dawr_write_file_bool(struct file *file,
> const char __user *user_buf,
> size_t count, loff_t *ppos)
>
^ permalink raw reply
* Re: Crashes in linux-next on powerpc with CONFIG_PPC_KUAP and CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG
From: Petr Mladek @ 2019-05-09 9:29 UTC (permalink / raw)
To: Michael Ellerman
Cc: linuxppc-dev, linux-kernel, Stephen Rothwell, Linus Torvalds
In-Reply-To: <87k1f2wc04.fsf@concordia.ellerman.id.au>
On Wed 2019-05-08 00:54:51, Michael Ellerman wrote:
> Hi folks,
>
> Just an FYI in case anyone else is seeing crashes very early in boot in
> linux-next with the above config options.
>
> The problem is the combination of some new code called via printk(),
> check_pointer() which calls probe_kernel_read(). That then calls
> allow_user_access() (PPC_KUAP) and that uses mmu_has_feature() too early
> (before we've patched features). With the JUMP_LABEL debug enabled that
> causes us to call printk() & dump_stack() and we end up recursing and
> overflowing the stack.
Sigh, the check_pointer() stuff is in Linus's tree now, see
the commit 3e5903eb9cff707301712 ("vsprintf: Prevent crash when
dereferencing invalid pointers").
> Because it happens so early you don't get any output, just an apparently
> dead system.
>
> The stack trace (which you don't see) is something like:
>
> ...
> dump_stack+0xdc
> probe_kernel_read+0x1a4
> check_pointer+0x58
> string+0x3c
> vsnprintf+0x1bc
> vscnprintf+0x20
> printk_safe_log_store+0x7c
> printk+0x40
> dump_stack_print_info+0xbc
> dump_stack+0x8
> probe_kernel_read+0x1a4
> probe_kernel_read+0x19c
> check_pointer+0x58
> string+0x3c
> vsnprintf+0x1bc
> vscnprintf+0x20
> vprintk_store+0x6c
> vprintk_emit+0xec
> vprintk_func+0xd4
> printk+0x40
> cpufeatures_process_feature+0xc8
> scan_cpufeatures_subnodes+0x380
> of_scan_flat_dt_subnodes+0xb4
> dt_cpu_ftrs_scan_callback+0x158
> of_scan_flat_dt+0xf0
> dt_cpu_ftrs_scan+0x3c
> early_init_devtree+0x360
> early_setup+0x9c
>
>
> The simple fix is to use early_mmu_has_feature() in allow_user_access(),
> but we'd rather not do that because it penalises all
> copy_to/from_users() for the life of the system with the cost of the
> runtime check vs the jump label. The irony is probe_kernel_read()
> shouldn't be allowing user access at all, because we're reading the
> kernel not userspace.
I have tried to find a lightweight way for a safe reading of unknown
kernel pointer. But I have not succeeded so far. I see only variants
with user access. The user access is handled in arch-specific code
and I do not see any variant without it.
I am not sure on which level it should get fixed.
Could you please send it to lkml to get a wider audience?
Best Regards,
Petr
> For now if you're hitting it just turn off
> CONFIG_PPC_KUAP and/or CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG.
>
> cheers
^ permalink raw reply
* Re: Build failure in v4.4.y.queue (ppc:allmodconfig)
From: Michal Suchánek @ 2019-05-09 9:49 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linuxppc-dev, stable, Guenter Roeck
In-Reply-To: <20190509065324.GA3864@kroah.com>
On Thu, 9 May 2019 08:53:24 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
> > I see multiple instances of:
> >
> > arch/powerpc/kernel/exceptions-64s.S:839: Error:
> > attempt to move .org backwards
> >
> > in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
> >
> > This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store
> > forwarding barrier at kernel entry/exit"), which is part of a large patch
> > series and can not easily be reverted.
> >
> > Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
>
> Michael, I thought this patch series was supposed to fix ppc issues, not
> add to them :)
>
> Any ideas on what to do here?
What exact code do you build?
In my source there the SLB relon handler starts just above this line and
a lot of out-ouf-line are handlers before. Moving some out-of-line
handlers below the parts with fixed location should fix the build error.
Thanks
Michal
^ permalink raw reply
* [Bug 203125] Kernel 5.1-rc1 fails to boot on a PowerMac G4 3,6: Caused by (from SRR1=141020): Transfer error ack signal
From: bugzilla-daemon @ 2019-05-09 10:05 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203125-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203125
Christophe Leroy (christophe.leroy@c-s.fr) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |christophe.leroy@c-s.fr
--- Comment #5 from Christophe Leroy (christophe.leroy@c-s.fr) ---
Apparently, MSR DR is not sent and DAR has value 0xc0090654, meaning that a
virt address tries to get accessed while in real mode.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [Bug 203125] Kernel 5.1-rc1 fails to boot on a PowerMac G4 3,6: Caused by (from SRR1=141020): Transfer error ack signal
From: Christophe Leroy @ 2019-05-09 10:22 UTC (permalink / raw)
To: bugzilla-daemon, linuxppc-dev
In-Reply-To: <bug-203125-206035-A0uW2ahLrr@https.bugzilla.kernel.org/>
On 05/09/2019 10:05 AM, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=203125
>
> Christophe Leroy (christophe.leroy@c-s.fr) changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |christophe.leroy@c-s.fr
>
> --- Comment #5 from Christophe Leroy (christophe.leroy@c-s.fr) ---
> Apparently, MSR DR is not sent and DAR has value 0xc0090654, meaning that a
> virt address tries to get accessed while in real mode.
>
Could you try the patch below:
diff --git a/arch/powerpc/mm/book3s32/hash_low.S
b/arch/powerpc/mm/book3s32/hash_low.S
index e27792d0b744..8366c2abeafc 100644
--- a/arch/powerpc/mm/book3s32/hash_low.S
+++ b/arch/powerpc/mm/book3s32/hash_low.S
@@ -539,7 +539,8 @@ _GLOBAL(flush_hash_pages)
#ifdef CONFIG_SMP
lis r9, (mmu_hash_lock - PAGE_OFFSET)@ha
addi r9, r9, (mmu_hash_lock - PAGE_OFFSET)@l
- lwz r8,TASK_CPU(r2)
+ tophys (r8, r2)
+ lwz r8, TASK_CPU(r8)
oris r8,r8,9
10: lwarx r0,0,r9
cmpi 0,r0,0
Christophe
^ permalink raw reply related
* [Bug 203125] Kernel 5.1-rc1 fails to boot on a PowerMac G4 3,6: Caused by (from SRR1=141020): Transfer error ack signal
From: bugzilla-daemon @ 2019-05-09 10:31 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203125-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203125
--- Comment #6 from Christophe Leroy (christophe.leroy@c-s.fr) ---
Try followin change:
diff --git a/arch/powerpc/mm/book3s32/hash_low.S
b/arch/powerpc/mm/book3s32/hash_low.S
index e27792d0b744..8366c2abeafc 100644
--- a/arch/powerpc/mm/book3s32/hash_low.S
+++ b/arch/powerpc/mm/book3s32/hash_low.S
@@ -539,7 +539,8 @@ _GLOBAL(flush_hash_pages)
#ifdef CONFIG_SMP
lis r9, (mmu_hash_lock - PAGE_OFFSET)@ha
addi r9, r9, (mmu_hash_lock - PAGE_OFFSET)@l
- lwz r8,TASK_CPU(r2)
+ tophys (r8, r2)
+ lwz r8, TASK_CPU(r8)
oris r8,r8,9
10: lwarx r0,0,r9
cmpi 0,r0,0
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply related
* [Bug 203125] Kernel 5.1-rc1 fails to boot on a PowerMac G4 3,6: Caused by (from SRR1=141020): Transfer error ack signal
From: bugzilla-daemon @ 2019-05-09 10:50 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203125-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203125
--- Comment #7 from Christophe Leroy (christophe.leroy@c-s.fr) ---
On 05/09/2019 10:05 AM, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=203125
>
> Christophe Leroy (christophe.leroy@c-s.fr) changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |christophe.leroy@c-s.fr
>
> --- Comment #5 from Christophe Leroy (christophe.leroy@c-s.fr) ---
> Apparently, MSR DR is not sent and DAR has value 0xc0090654, meaning that a
> virt address tries to get accessed while in real mode.
>
Could you try the patch below:
diff --git a/arch/powerpc/mm/book3s32/hash_low.S
b/arch/powerpc/mm/book3s32/hash_low.S
index e27792d0b744..8366c2abeafc 100644
--- a/arch/powerpc/mm/book3s32/hash_low.S
+++ b/arch/powerpc/mm/book3s32/hash_low.S
@@ -539,7 +539,8 @@ _GLOBAL(flush_hash_pages)
#ifdef CONFIG_SMP
lis r9, (mmu_hash_lock - PAGE_OFFSET)@ha
addi r9, r9, (mmu_hash_lock - PAGE_OFFSET)@l
- lwz r8,TASK_CPU(r2)
+ tophys (r8, r2)
+ lwz r8, TASK_CPU(r8)
oris r8,r8,9
10: lwarx r0,0,r9
cmpi 0,r0,0
Christophe
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply related
* Re: [PATCH] powerpc/ftrace: Enable C Version of recordmcount
From: Christophe Leroy @ 2019-05-09 11:27 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <87ef59wz8n.fsf@concordia.ellerman.id.au>
Le 08/05/2019 à 02:45, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>> Selects HAVE_C_RECORDMCOUNT to use the C version of the recordmcount
>> intead of the old Perl Version of recordmcount.
>>
>> This should improve build time. It also seems like the old Perl Version
>> misses some calls to _mcount that the C version finds.
>
> That would make this a bug fix possibly for stable even.
>
> Any more details on what the difference is, is it just some random
> subset of functions or some pattern?
I have not been able to identify any pattern. Will add a few details in
the 'issue' on github.
Christophe
>
> cheers
>
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index 2711aac24621..d87de4f9da61 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -180,6 +180,7 @@ config PPC
>> select HAVE_ARCH_NVRAM_OPS
>> select HAVE_ARCH_SECCOMP_FILTER
>> select HAVE_ARCH_TRACEHOOK
>> + select HAVE_C_RECORDMCOUNT
>> select HAVE_CBPF_JIT if !PPC64
>> select HAVE_STACKPROTECTOR if PPC64 && $(cc-option,-mstack-protector-guard=tls -mstack-protector-guard-reg=r13)
>> select HAVE_STACKPROTECTOR if PPC32 && $(cc-option,-mstack-protector-guard=tls -mstack-protector-guard-reg=r2)
>> --
>> 2.13.3
^ permalink raw reply
* [Bug 203125] Kernel 5.1-rc1 fails to boot on a PowerMac G4 3,6: Caused by (from SRR1=141020): Transfer error ack signal
From: bugzilla-daemon @ 2019-05-09 11:36 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203125-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203125
--- Comment #8 from Erhard F. (erhard_f@mailbox.org) ---
I tried to apply the patch on top of 5.1.0 but it did not work out 'cause there
is no arch/powerpc/mm/book3s32/hash_low.S. The correct file on my system seemed
arch/powerpc/mm/hash_low_32.S, but changing the path in the patch did not work
either.
What actually did work was manually applying your proposed change in
arch/powerpc/mm/book3s32/hash_low.S! Now the G4 boots up fine with 5.1.0 as it
did with 5.0.x.
Many thanks for the fix!
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ 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